How to verify ASCOM dither?

[jellison]

I need a bit of advice on how to check whether dither using ASCOM is working correctly.  I have a Star Adventurer GTI tracking mount and BYE looks to be connecting to the tracker correctly as I can see the tracker data in the ASCOM Telescope window of BYE.  I turned on dither and set aggressiveness to 5, but to be honest I cannot really see much happening - the resulting series of images don't seem to show any more position deviation than what I normally see with this mount.  Are there any diagnostics that can help understand what is happening?  Thanks!

[astroman133]

You might get information from the BYE log files. You might also be able to see the RA seconds change a little bit over time.

I would expect that the dither movements are too small to see with your eye.

[jellison]

Extract of log copied below.  Maybe I'm interpreting it wrongly but it looks like at entry "2025-01-11 19:06:16,346" the dither is expected to be settled at RA(2.99568155) DEC(89.37071428) but the post dither values read are actually RA(2.99520878) DEC(89.37306809) (entry 2025-01-11 19:06:17,353).  These values are very close to the pre-dither values at the top of the log, suggesting that the dither didn't actually work?  I'm really not sure though - needs an expert eye.

 

2025-01-11 19:06:12,361 [23] INFO  - ASCOM dithering...
2025-01-11 19:06:12,361 [23] INFO  - ASCOM Dither is starting...
2025-01-11 19:06:12,373 [23] INFO  - PRE-DITHER Telescope RA(2.99527460) DEC(89.37308928)
2025-01-11 19:06:12,375 [23] DEBUG - Telescope current coordinates: (JNOW):
2025-01-11 19:06:12,375 [23] DEBUG - +-- RA : 02h 59m 43s  :::  2.995274602810
2025-01-11 19:06:12,375 [23] DEBUG - +-- DEC: +89  22' 23" :::  89.373089283200
2025-01-11 19:06:12,375 [23] DEBUG - Slewing to coordinates: (JNOW):
2025-01-11 19:06:12,375 [23] DEBUG - +-- RA : 02h 59m 45s  :::  2.995681547254
2025-01-11 19:06:12,375 [23] DEBUG - +-- DEC: +89  22' 15" :::  89.370714283200
2025-01-11 19:06:12,482 [ProcessCapture(Normal)] INFO  - Image resized to : Width 3896 Height 2596 Factor 1.442218798151
2025-01-11 19:06:12,780 [ExifRead(Normal)] INFO  - F:\Astro\Temp\Download\IMG_0009.CR2
2025-01-11 19:06:12,780 [ExifRead(Normal)] INFO  - ExifRead F:\Astro\Temp\Download\IMG_0009.CR2
2025-01-11 19:06:13,124 [DeleteFile(Normal)] INFO  - Try delete F:\Astro\Temp\exif_args_f95c77b3-6e2f-4374-bc2f-10e79090d53e.txt
2025-01-11 19:06:13,124 [DeleteFile(Normal)] INFO  - F:\Astro\Temp\exif_args_f95c77b3-6e2f-4374-bc2f-10e79090d53e.txt DELETED!!!
2025-01-11 19:06:13,124 [ExifWrite(Normal)] INFO  - F:\Astro\Temp\Download\IMG_0009.CR2
2025-01-11 19:06:13,124 [ExifWrite(Normal)] INFO  - Skip exif write due to user configured setting
2025-01-11 19:06:13,136 [MoveFile(Normal)] INFO  - Attempting to move file...
2025-01-11 19:06:13,136 [MoveFile(Normal)] INFO  - move: F:\Astro\Temp\Download\IMG_0009.CR2
2025-01-11 19:06:13,136 [MoveFile(Normal)] INFO  -   to: F:\Astro\LIGHT_1s_1600iso_f4-5_+14c_ra(2.99528)_dec(89.37309)_20250111-19h06m07s485ms.CR2
2025-01-11 19:06:13,136 [MoveFile(Normal)] INFO  - Try move F:\Astro\Temp\Download\IMG_0009.CR2
2025-01-11 19:06:13,136 [MoveFile(Normal)] INFO  - moved to F:\Astro\LIGHT_1s_1600iso_f4-5_+14c_ra(2.99528)_dec(89.37309)_20250111-19h06m07s485ms.CR2
2025-01-11 19:06:13,137 [25] INFO  - CameraPropertyChangedArgs fired: SensorTemperature    = '+14c'
2025-01-11 19:06:13,139 [25] INFO  - LIGHT_1s_1600iso_f4-5_+14c_ra(2.99528)_dec(89.37309)_20250111-19h06m07s485ms.CR2
2025-01-11 19:06:16,343 [23] INFO  - Slew to target complete.
2025-01-11 19:06:16,343 [23] INFO  - Telescope SynScan App Driver current properties.
2025-01-11 19:06:16,343 [23] INFO  - +--- Epoch                 : JNOW
2025-01-11 19:06:16,343 [23] INFO  - +--- RightAscension        : 2.995223888450 : 2h59m43s
2025-01-11 19:06:16,343 [23] INFO  - +--- Declination           : 89.373071674200 : 89 22'23"
2025-01-11 19:06:16,343 [23] INFO  - +--- Altitude              : 52.699385431100 : 52 41'58"
2025-01-11 19:06:16,343 [23] INFO  - +--- Azimuth               : 0.100167327151 : 00 06'01"
2025-01-11 19:06:16,343 [23] INFO  - +--- SiteLongitude         : 1.26169166667
2025-01-11 19:06:16,343 [23] INFO  - +--- SiteLatitude          : 52.0628083333
2025-01-11 19:06:16,343 [23] INFO  - +--- SiteElevation         : 0
2025-01-11 19:06:16,343 [23] INFO  - +--- IsParked              : False
2025-01-11 19:06:16,343 [23] INFO  - +--- IsHome                : False
2025-01-11 19:06:16,343 [23] INFO  - +--- IsTracking            : True
2025-01-11 19:06:16,346 [23] INFO  - Dither settled to RA(2.99568155) DEC(89.37071428)
2025-01-11 19:06:16,349 [23] INFO  - Difference of RA(0.00040694) DEC(-0.00237500)
2025-01-11 19:06:17,353 [23] INFO  - POST-DITHER Telescope RA(2.99520878) DEC(89.37306809)
2025-01-11 19:06:18,658 [23] INFO  - Temp folder:     F:\Astro\Temp
2025-01-11 19:06:18,658 [23] INFO  - Download folder: F:\Astro

[astroman133]

I can see very small changes to the RA value as a result of dithering, but I am not sure why you are testing dithering while pointing at the celestial north pole (Dec 90 degrees). At that point, all the lines of RA come together. You should test with the camera pointed away from the CNP. Try somewhere along the celestial equator.

[jellison]

Oh is dithering only applied to one axis?

[astroman133]

No, it is usually applied in both axes, but can be more difficult when the lines of RA converge at the poles.

[astroman133]

Also, I believe that some tracking mounts only support control of one axis, but I don't know about your mount.

[jellison]

Thanks, I'll do some more experiments.  It's a steep learning curve!

[jellison]

OK I'm pretty certain now that my mount is not responding to the target changes that BYE is giving to it when dithering.  Looking at the ASCOM logs it seems that BYE sends the new target with the following commands:

 

TargetRightAscensionSet,22.8363179285333
TargetDeclinationSet,-8.31747660886333 
SlewToTargetAsync 
 

I can see on my mount app that the GOTO is briefly invoked but then seems to be cancelled or ignored (not sure as the page only flashes up briefly on the screen).  But the RA and Dec are not changed at all.

I tried using another program to control the mount and this one worked but it uses a different command:

 

SlewToCoordinatesAsync,1.02144179797776,2.13454838359727

 

The mount app accepts these new coordinates and starts slewing as expected.

[astroman133]

The ASCOM command methods SlewToTargetAsync and SlewToCoordinatesAsync do exactly the same thing. In fact it is common that SlewToCoordinatesAsync calls SlewToTargetAsync under the covers to start the move.

I can only imagine that either there is a bug on the ASCOM driver that you are using, or BYE is using SlewToTargetAsync incorrectly by not setting the TargetRightAscension and TargetDeclination values beforehand.

[s3igell]

If you have Plate Solving setup and working accurately for this combo of Scope and Camera, you could compare Plate Solve Coordinates of before-after Shots.

[jellison]

Delving a little bit more into this mystery, I built a small ASCOM test app using the guidance on the ASCOM website.  I was able to command the mount to move either by setting the target coordinates and then slewing to that target, or by slewing directly to coordinates.  So I think this shows that the mount driver is responding correctly.  However, when BYE sends (apparently) the same commands, the mount does not respond.  The "Slewing" flag stays false when BYE sends the new dither coordinates.  

I'm at a bit of a loss now.  Also I noticed that in the log file BYE is requesting some parameters using commands that do not seem to appear in the ASCOM docs, e.g. "RightAscensionDeclinationGet".  After some harder googling it turns out that these commands appear in the Synscan app protocol (the app that my tracker uses) but I cannot test these commands in my app as they do not appear as methods or properties that I can use.  Any ASCOM experts can help me understand what's going on here?

 

[astroman133]

The ASCOM Initiative also has a tool that does a pretty thorough test of a driver to make sure that it conforms with the ASCOM specifications. It os a se[arate download from the ASCOM Standards web site. This can be used without having to write a program.

It will take one of the BYE developers to look at the code to see if there is a bug in how SlewToTarget is being called when doing ASCOM dithering.

[jellison]

Alright I think I understand what might be happening - it looks like the coordinate change has to be above a certain threshold for the mount to acknowledge them and the dither commands are not large enough to exceed this threshold.  Maybe there's a setting in the mount app config somewhere but I think BYE is innocent - it looks like a quirk of the mount.

Apologies for the wild goose chase!

[astroman133]

No problem with the wild goose chase. Thanks for letting us know what you discovered.

[admin]

Have you tried increasing the BYE dither aggressiveness parameter? The default is 2, set to 5 and see if the dither increases to something more acceptable for your setup.

Regards,

[jellison]

Yes I set it to 5 but it was still too small to trigger the mount to a new position.  I'm not sure of the exact figures but it looks like even with a dither of 5 I'm only seeing maybe 1arcsec of change in target RA/Dec, whereas I need maybe 15arcsec to get the 10-12 pixels movement I need.  In the end I came up with a workaround.  I made a small ASCOM app which listens for changes in target RA/Dec (those sent by BYE) and overrides with a larger change determined by the apps own dither parameter.  This seems to work OK.

[admin]

Interesting, almost looks like you would benefit from a 'scale' or 'multiplier' to the dither aggressiveness setting.

[jellison]

Yes, that would certainly help!