Allow different +RA and -RA rates in Feature Tracking

[admin]

Hi Mike,

if you get any clear skies, give the new 4.1.12066 version a try with the option to enable the pre-release features. If that is done correctly then you should see a log message containing this text when starting calibration

Code: Select all

Using new mount guiding for calibration/movement (offset of mount positions)

This option measures the mount movement by reading the difference between mount co-ordinates before and after the movement. Previous versions used 'sum of movement times multiplied by movement rate'. I had initially avoided using the co-ordinates as I was worried that the potential delays in reporting the co-ordinates would cause issues, but it looks like the lack of a uniform response to movement commands may be a bigger one.

The new code will handle calibration while tracking for EQ mounts (the various different lunar/solar/sidereal tracking rates are close enough to each other to not have to worry about the differences). It will also cope with calibration for AltAz mounts while tracking or while stationary (non-tracking). I couldn't see a use case for the EQ mount while not tracking so didn't worry about that (someone will prove me wrong, no doubt!)

I've tried the new code with a Skywatcher NEQ6 via GreenSwampServer and an iOptron SkyHunter via iOptron Commander. Both calibrate, although there are delays to co-ordinate reporting that mean that the lines are not perfect when looking at individual points, but are fairly linear at the high level view.

cheers,

Robin

[Borodog]

Thanks, Robin. Will test ASAP.

[Borodog]

Robin,

Got my GP back from being relubed and was able to test Feature Tracking calibration last night using the prerelease option. Calibration went without a hitch. It did take quite a while watching the scatter plot to then translate that calibration into settings that did not leave the Moon jumping all over the place. But I eventually did, so all is well.

I have to say that it does seem like Feature Tracking is "chasing the seeing" because of the frequency with which it is taking measurements. I think the results might be smoother if the samples were averaged over a few seconds to get the calculated correction magnitude.

Mike

[admin]

Hi Mike,

glad to hear that the calibration with the new option worked for you. Did you by any chance try the old way too (be interesting to find out if the mount rebuild helped that option or not)?

For the chasing the seeing, I seem to recall from previous posts that you were keen on having the dead zone setting dialled down very low - in general a larger value for that would prevent chasing the seeing because it would mean that a reasonable drift would have to build up before SharpCap took corrective action. I guess some sort of time averaging would have the same effect though.

cheers,

Robin

[Borodog]

Robin,

Yes, I would like to have the dead zone as small as possible. The other night I believe I ultimately settled on 25 pixels, but I'd prefer it to be less than 10. But then the noise in the samples becomes significant; when a sample breaks out of the dead zone, SharpCap wakes up and issues a large correction based on the offending sample, which itself has a lot of noise. This resulted in a lot of "chattering", bouncing around back and forth around (0,0), forcing me to use the larger dead zone than I would prefer in order to make the noise small compared to the correction. If the samples were smoothed you should be able to use a much smaller dead zone.

Mike