Re: Anyone using Orbitals plug in for NINA to track comets using AP mount via APCC

Dale Ghent

I think this situation boils down to the impressions one gets when programming against a model, and you believe that model to be correct and it turns out it is not!

George has a non-AP mount and, naturally, created the Orbitals plugin using it. It uses standard ASCOM interfaces to set custom RA and Dec tracking rates, which I explained the guts of in a previous mail here. Each mount driver should implement these customer tracking rate interfaces in accordance with the ASCOM spec, but it *appears* a few of them actually do not implement the property correctly.

But, after talking about it with Ray and doing some testing on my A-P mounts, the A-P ASCOM driver *does* implement it (RightAscensionRate) correctly. The A-P driver's implementation of them is only a quirk in that it seems to be perhaps one of the few that correctly implement it!

So this means that there is a possibility that we have a situation where the test systems were wrong, which led the logic in Orbitals down the wrong path because the wrong logic works fine on those mounts, but clearly does not work fine when applied to mounts that do implement it correctly. Couple this with problems tracking mainly coming from A-P mount users, the situation additionally gave the impression that the A-P ASCOM driver was in the wrong, which it turns out that it's actually the opposite.

RightAscensionRate and DeclinationRate, the two mount dirver properties that are used by an application to control the custom movement rate of each axis, are not often used by imaging apps. So it may be that wrong driver implementations coupled with a lack of use of them across mount users have not already surfaced any implementation problems with them. This isn't the first time we've encountered this issue where ASCOM drivers wrongly implement an obscure property and the error is not realized until someone, usually us (heh), comes along and starts using it in a major way. Stamping out the confusion regarding SideOfPier amongst different mount vendors was also a undertaking we did. I'm about to use DestinationSideIfPier() in a major way in an upcoming plugin so I'm going to brace for issues with that.

Anyway, the status now is: George is removing the "quirks" option in the Orbitals plugin and the calculations it enabled will be the normal calculation for RA tracking rate. Any other mount vendors' drivers that are discovered to have issues with this correct calculation will be contacted and, hopefully, corrected. It's unclear right now how extensive this is, which requires more testing of the correct calculations across a lot of mount makes and models. And, of course, sorry for all the confusion! It should come as no surprise that Ray's implementation in the A-P driver is correct!


On Jan 29, 2023, at 08:37, Ray Gralak <iogroups@...> wrote:

Hi Jim,

FYI, the source of the problem with Orbitals and APCC has been tentatively resolved. The tracking rate should
now agree and be corrected but you will need to upgrade to the latest Orbitals plug in then go into the plugin
options and set Quirks mode to “Astrophysics”.
That's interesting that the Orbitals author has an Astro-Physics "Quirks mode" in his plugin.

He contacted me last night with a "bug report" that the AP V2 driver's RightAscensionRate property is using incorrect units. After several emails, I proved to the author that the driver uses the correct units. So, the bug was in his Orbitals plugin and not the AP V2 driver. And, "Quirks Mode" should probably be called "ASCOM", as this is not specific to the AP-V2 driver.


Join { to automatically receive all group messages.