Dithering in RA & DEC direction at the same time is not possible

[han-k59]

While developing a modification for the CCDCiel internal guider we noticed the following:

RA & DEC dither pulse commands are executed sequential. First the RA then DEC dither pulse is processed.

1) This is less efficient. Dithering take longer then possible and exposure time is lost. 2) Duration is difficult to predict for our dither algorithm since EQASCOM can process the commands in parallel 3) It is not ASCOM compliant.

"If the mount cannot have simultaneous PulseGuide operations in both RightAscension and Declination, it must throw InvalidOperationException when the overlapping operation is attempted."

https://ascom-standards.org/newdocs/telescope.html#Telescope.PulseGuide

The old EQAscom does RA, DEC dithering in parallel so it is not a limitation of the HEQ5 mount.

Is it possible to change this?

Thanks, Han

If send pulse of 10 seconds in Dec an Ra in sequence, we see from the time the PulseGuide() method return immediately so the two are really send at the same time to GSS. 2024-08-24T14:58:41.363 1: start pulse 1 2024-08-24T14:58:41.368 1: start pulse 2 2024-08-24T14:58:41.371 1: end

[Principia4834]

Han, thanks for raising the issue. I expect that Rob will come back on your question about the timing of RA and Dec pulse dithering. Making dithering more efficient and predictable looks like a good goal although I don't know how difficult that is - the SkyWatcher mounts do support independent motion in Ra and Dec axes which GSS uses for slewing and tracking. We have been reviewing the pulse guiding code and have been looking at some changes but these have not been released yet.

I've included some additional background below - I see that you are active on the ASCOM developer forum so I hope this helps.

GSS is built to and is compliant with (tested against ASCOM ConformU) ASCOM Telescope V3 interface standard documented here https://ascom-standards.org/Help/Developer/html/T_ASCOM_DeviceInterface_ITelescopeV3.htm. The issue link goes to the draft V4 standard. Although ASCOM Platform 7 enables the V4 Telescope standard the platform does not mandate it and is intended to be binary backwards compatible with all devices implementing the V3 Telescope standard.

The GSS developers reviewed the V3 and V4 Pulse Guide specifications again when the first Platform 7 release candidate was released and found that there is an inconsistency in the V3 and V4 ASCOM standards. The V4 statements for PulseGuide() are:

Asynchronous: The method returns as soon the pulse-guiding operation has been successfully started, with IsPulseGuiding property True. However, you may find that IsPulseGuiding is False when you get around to checking it if the ‘pulse’ is short. This is still a success if you get False back and not an exception. See Asynchronous Operations in ASCOM If the mount cannot have simultaneous PulseGuide operations in both RightAscension and Declination, it must throw InvalidOperationException when the overlapping operation is attempted.

The V3 standard says:

This method returns immediately if the hardware is capable of back-to-back moves e.g. dual-axis moves. For hardware not having dual-axis capability, the method returns only after the move has completed The IsPulseGuiding property must be True during pulse-guiding. The PulseGuide()method may throw an InvalidValueException if called when an incompatible command is already underway e.g. a slew is in progress.

In summary V3 PulseGuide() can be synchronous returning only when pulse guiding has finished whereas in V4 PulseGuide() must be asynchronous. V3 must throw InvalidValueException if there is a problem whereas V4 must throw InvalidOperationException. These may be breaking changes in ASCOM for some applications. The GSS development team had deferred raising this issue but I will now post on the ASCOM developers forum.

AndyW (GSS team member working on beta updates for Alt / Az and Polar mount support)

[pchev]

Hello Andy, I am also developing CCDciel with Han.

OK to clarify that with ASCOM, V4 can make application not prepared for that to crash.

We not specifically want V4 compatibility in GSS, it is easy to use one or the other by checking InterfaceVersion. But I think the current behavior is not fully V3 compliant. For V3 we have: "For hardware not having dual-axis capability, the method returns only after the move has completed" But GSS return immediately despite it not do the second move until the move on the first axis is completed. This make the program to timeout when waiting for IsPulseGuiding=False when two large pulse are send in a row as in the example above.

Sure I probably not want you make the PulseGuide() method to not return until the move is complete (what V3 expect in this case) because this is totally again the asynchronous mode promoted now by ASCOM.

It will be wonderful if you can make GSS to run the pulse in two direction simultaneously, has the hardware is capable of.

Patrick

[Principia4834]

Bonjour Patrick Merci pour votre réponse. Je répondrai en anglais - plus facile pour moi!

I think you're correct about V3 compliance even though it passes the extended ASCOM ConformU pulse guide tests. ConformU only tests one axis at a time - I'll suggest to the ASCOM team that they change the tests.

I have a code change that which correctly moves both axes together but we'll need to test it fully before we release it in a beta version update. This should support asynchronous dual axis operation for the V3 Telescope interface so you don't have to check the interface version.

I have built a Telescope V4 compliant version of Green Swamp Server but we won't release any updates until ASCOM Platform 7 is fully released and proven to be stable - we are being very cautious.

The ASCOM goal of fully asynchronous operation is good - especially with the increasing uptake of Alpaca.

Cordialement Andy

[han-k59]

Andy,

Thanks for looking into this. Can you share an executable with the fix for field testing here? We are an in a crucial testing phase of the CCDCiel internal guider and our implementation should work with GSS.

Thanks, Han

[Principia4834]

Han, You'll probably have seen that I made two pull requests this morning which include fixes for this issue and for issue #73. Rob is the owner of the GSS repository so he will be the one to make a new beta release. He is copied in on all the issue updates. Andy

[Principia4834]

Han, Patrick Please check you emails for updates Andy

[han-k59]

Hi Andy,

Thanks for the alpha version.

This evening i could test it under clear skies. CCDCiel parallel dithering works now fine with this GSS version. So I'm happy :).

Partrick is also doing some testing so wait for his response.

Han

[pchev]

Hi,

Thank you! this is also good for me. I tested with unreasonably large dither simultaneously on both axis and it work fine, no more timeout in the program.

Patrick

[Principia4834]

Han, Patrick Thanks for the feedback. We will release a public beta version when we have completed all of our testing and made sure that asynchronous cancellations work in all cases Andy

[Principia4834]

Han, Patrick Rob has released V1.0.8.6 https://github.com/rmorgan001/GSServer/releases/tag/v1.0.8.6 which includes the fix for simultaneous RA and Dec pulse guiding. The notes detail other changes that are included. Andy