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!

/dale