Following some problems with OAM and Guiding close to the meridian after a NINA Recenter descibed Hereunder, I ask Claude AI to help me to diagniose this.
My Problem :
Let's have a target before meridian and for which OAM slew using the classic West site of pier and we image for a while. My sequecer has a trigger for checking drift every 4 image and recenter if needed. If this recenter process occurs when the target come close to the meridian (for instance few minutes), OAM decided to flip and the recentering process finished East side of the Pier.
Unfortunately, guiding restart just afetr centering and when phd2 request side of pier, il is still West (and not East), therefore the RA guiding don't use the reversed calibration and guiding produce a worst result, drifting more than no guiding and loosing quickly the target.
I decide to wait for a while, and it seemed that pier side has been update when the target really pass the meridian (or a long delay but I have the feeling that this match meridian) and as phd2 has the correct side of pier, guiding become fine.
In this xcase, I was behind my screen for diagnotic so I stop guiding when it was wrong and start it when I saw pier side updated, but it could be a problem if guiding is not stopped during an automated sequence with nobody monitoring.
And we arrive at the following feature request that should be convenient for everybody (provided tha the code analysis made by Clause Ai is correct)
After analysing the source code of MeadeCommandProcessor.cpp, I found that no :GW# command is implemented in the firmware. Therefore the ASCOM driver must calculate SideOfPier from the reported RA coordinates, not from the physical stepper position. This causes a well-reproducible issue: after a physical flip, the ASCOM driver continues to report the old PierSide until the RA coordinates (as reported by the firmware via :GR#) have updated to reflect the new pointing position — which only happens once the mount reaches or passes the meridian in its internal calculation. Proposed fix: Implement :GW# in the firmware returning the physical pointing state based on the RA stepper position (positive = West side, negative = East side). This would allow the ASCOM driver to report an accurate and immediate PierSide after any flip.
Thanks
Following some problems with OAM and Guiding close to the meridian after a NINA Recenter descibed Hereunder, I ask Claude AI to help me to diagniose this.
My Problem :
And we arrive at the following feature request that should be convenient for everybody (provided tha the code analysis made by Clause Ai is correct)
After analysing the source code of MeadeCommandProcessor.cpp, I found that no :GW# command is implemented in the firmware. Therefore the ASCOM driver must calculate SideOfPier from the reported RA coordinates, not from the physical stepper position. This causes a well-reproducible issue: after a physical flip, the ASCOM driver continues to report the old PierSide until the RA coordinates (as reported by the firmware via :GR#) have updated to reflect the new pointing position — which only happens once the mount reaches or passes the meridian in its internal calculation. Proposed fix: Implement :GW# in the firmware returning the physical pointing state based on the RA stepper position (positive = West side, negative = East side). This would allow the ASCOM driver to report an accurate and immediate PierSide after any flip.Thanks