Meridian Flip / Camera rotation not updating position angle


It appears that when SGP rotates the camera 180 degrees as part of a meridian flip, it does not update the rotator’s internal position angle after the flip is performed.

That is, if imaging at a position angle of 246 degrees prior to the meridian flip, the rotator’s internal position angle should be reset to 246 degrees after the flip is completed. Otherwise the rotator will have the wrong internal position angle and that will mess up subsequent rotations.

In a recent test (v2.4.2.8?), my rotator was set to 122 degrees while imaging east of the meridian. After the flip, I looked at the rotator control software (external to SGP) and the rotator was showing 302 degrees and SGP was showing 122 degrees.

It is possible that this is an issue with the rotator software but wanted to bring it to your attention.



I thought we did this… I’ll check the code. Your new angle after the flip should be ~66 degrees. When we sync the mount, we should also sync the rotator to the new PA. This would mean that whatever your rotator is showing is now 66 degrees… they won’t ever match.


I just took a quick look at the code… everywhere we sync the scope position (based on successful solve), we also sync the rotator… I can’t find a condition in which this occurs. We would need logs or a more exhaustive set of steps for reproduction.


I’m not even sure what that means. ASCOM rotators have a position index that can be read and modified via the methods that move the rotator, but they have no notion of being synced to the sky as mounts do. From the ASCOM documentation:

the rotator does not need to (and in general will not) report the true Equatorial Position Angle, as the attached imager may not be precisely aligned with the rotator’s indexing. It is up to the client to determine any offset between mechanical rotator position angle and the true Equatorial Position Angle of the imager, and compensate for any difference.

This makes sense because the external software can only display the rotator index position, and has no knowledge of the camera angle on the celestial sphere. SGP on the other hand always displays true camera angle on the sky as determined by plate solve.

SGP writes the rotator index position to each captured image in the FITS header POSANGLE. I believe if you look at the POSANGLE image header you will find that it agrees with the value shown in your rotator software.

SGP also records the true camera angle in the ANGLE FITS header.


Rotator angle meaning for OAG - and sync

This is SGPro’s own internal syncing method. Because ASCOM does not offer a way to sync rotator PA with any sort of reality like 15 degrees East of North (or whatever), SGPro keeps track of this internally and “syncs” your PA to a rotational position in the sky. It is nothing more than a map… a reading of 300 PA means that you are 15 degrees east of north or whatever…

We took this to heart and implemented our own sync mechanism as described above.

When you flip the mount and do not move the rotator, SGPro will “sync” the current rotator PA to reality…


Well, I may be very confused. I am using one of the Optec Gemini rotators, which is supported by Optec’s ASCOM driver. The Optec control software (Gemini Commander) allows me to correlate the current “instrumental” PA (that is, internal hardware PA) with some sky PA. So, I take a focus frame and plate solve (PlateSolve2). I then take the reported sky PA and enter that value into the Gemini software. SGP shows that value also but I think it comes from the plate solve and not from the Gemini software (ASCOM).

I assumed that from that point on, I can rotate the camera (using Gemini software) to any sky PA I need to make the OAG find the guide star I have selected in TheSky6 software. If I move the rotator via the Gemini Software, SGP seems to see that movement.

When a German Equatorial mount does a meridian flip, the sky is rotated by 180 degrees but the resulting sky PA after the flip stays the same. That is, a frame plate solved to show a sky PA of 250 degrees when imaging east of the meridian would plate solve the same when pointing west of the meridian if and only if the camera is rotated 180 degrees.

So, does SGP expect to always get the internal, instrumental PA from the rotator and then SGP figures out how to map that instrumental PA to the plate solved sky PA? I thought SGP expected to get sky PA from the rotator and then just use that info as is.

How does the sky PA as shown for the FOV indicator in TheSky6 match up with the sky PA reported by PlateSolve2? I have always assumed they were the same.



The simplest way I can explain this is to say that SGPro knows nothing about your rotator except its mechanical position in degrees. SGPro will map that position to a sky angle expressed in degrees east of north (upon solving). That’s really all there is to it. We have no expectation that getting the position from the rotator is anything other than some arbitrary positional information about a mechanical device. Like the ASCOM docs say, it s the consuming client’s (SGPro’s) responsibility to interpret what this means.

If your rotator has a mechanical position of 15 degrees and you solve at 90 degrees east of north, then we “sync” your rotator to that position (15 degrees PA = 90 degrees east of north). After a flip, your sky angle is now 270 degrees east of north, but your rotator’s mechanical position is still 15 degrees. After the solve comes back from the other side of the meridian, this new view of the sky is taken into account and “synced” (now 15 degrees PA = 270 degrees east of north).


SGP cannot expect to get a sky angle from the rotator since ASCOM does not offer that. All ASCOM offers is a device position angle that may or may not be associated with the actual sky angle. SGP cannot assume anything about that angle, so it maintains its own device-angle-sky-angle offset (this is the sync Ken was talking about). In your case the device angle equals the sky angle on one side of the meridian because you told the rotator ASCOM driver about the sky angle. Once you meridian flip, the rotator’s sky angle is off by 180 degrees versus the true camera angle. The rotator does not know about the meridian flip! It still thinks it is pointing the other way.

To put it another way, there are several angles involved:

a) raw rotator index value - the value read from the rotator’s encoders. Let’s call this RAW_ANGLE.
b) rotator sky position offset. When you click the SkyPos button in the ascom driver and enter a sky pos number, the driver computes SKY_OFFSET = sky pos - RAW_ANGLE.
This allows the driver to report sky position unless you meridian flip
c) rotator position [POSANGLE] - the position angle reported by the rotator ascom driver. this is POSANGLE = RAW_ANGLE + SKY_OFFSET. This is what SGP gets when it asks the rotator for the current position. It only matches the true sky position before the meridian flip. After the meridian flip it is off by 180 degrees since it reports the same number after the meridian flip (the rotator itself has not moved, RAW_ANGLE, POSANGLE, and SKY_OFFSET are unchanged).
d) SGP’s camera angle. The true camera angle found by plate solving. This changes by 180 degrees after a pier flip.

… so the plate solved angle and TheSky6 will be the same before the pier flip, then differ by 180 degrees after the pier flip.

Hope that helps,


Ken and Andy:

Thanks for the expanded explanation. I now have a better understanding of how this stuff interacts. I had just assumed it was the rotator’s responsibility to report an accurate sky PA to the controlling software.



That would be awesome…unfortunately it is not the case so we have to fake it in SGP :frowning:

I brought this up in the ASCOM group over 2 years ago