Why is ROT_PA essentially the same as PA?

Planewave alt-az telescope (latitude ~40 N) controlled by ACP. I'm new to ACP and alt-az mounts.

Looking at an image set starting at an altitude of 40, hitting 65 (at transit) and concluding at 53. At the beginning of the run both the PA and ROT_PA are 360. The PA slowly increases at 3 arcminutes per minute over the course of the run and... so does the the ROT_PA? The question is why isn't the "mechanical position" of the rotator rotating more significantly over the wide alt-az range, or why is it essentially the same as the PA? This is true in other runs when the PA isn't linear.

Off the top of my little head, I'd expect ROT_PA to be changing significantly while the PA is held constant.

To be fair, this isn't strictly an ACP question as I see the same effective keyword behavior in another alt-az Planewave controlled by NINA, though I didn't notice the issue then as the NINA controlled mount has significantly less overall drift.

Jesse

At my level, all rotations are equatorial. I have zero visibility into the derotation process needed to present the user with an equatorial coordinate system. And trust me I don't want it!! It is properly part of the low level mount/derotator process. ROT_PA is the mechanical rotator angle already transformed to equatorial coordinates. What I see is a rotator on the back of an equatorially mounted scope. I hope this makes sense.

I cogitated on your reply during my daily jog and came up with ROT_PA is the PA the rotator thinks the (solved) image should have. Open loop it's fingers crossed that they agree (ROT_PA = PA) and closed loop the difference is an error that's fed back to the rotator controller. That's all well and good, but I'm interested in the rotator's internal rotation angle (which should be changing over the course of an imaging run) and not whether it's managing to keep a fixed PA across an imaging run. So...

It also dawned on me to look at the ASCOM iRotatorV3 properties to see what's there (which I should have done before posting). So there's Position and MechanicalPosition. Alas the explanation for those isn't that clear to me, but my guess is that ROT_PA is reporting Position. I'm not even sure MechanicalPosition is what I want since it might be simply be Position + [fixed offset].

Why do I want the rotator's internal angle? Because my understanding is that the flat field rotates with that and if it does, I want to know how the little dust donuts e.g. rotate over the course of an image run.

Thanks,

ROT_PA is the Mechanical position. In your ACP logs you will see

Imager sky position angle is xxx deg.
Rotator mech. position angle is yyy deg.

ROT_PA is the latter number, yyy, the derotated mech angle. Use this for flat fielding. If they are the same, then your (derotated) rotator happens to index at 0 against the equatorial coordinates system ([fixed-offset] = 0). ACP will handle rotators that have any [fixed offset]. And the [fixed offset] never changes, it is at the derotated side of the rotator.

If you need access to the "raw" angle (for example to handle vignetting in the primary optics) you'll need to get that from PlaneWave. Welcome to the world of imaging on an alt-az mounted scope. You also have no access to the max-rotation-speed area around the zenith, and depending on the model, long "slew" times while the derotator catches up to the fast slews of the scope, particularly near the zenith. ACP sees slew completion when all three axes arrive at the requested equatorial coordinates. Most astronomers eventually re-mount the scope on an equatorial "wedge" or equivalent.

Hi Jesse,

Just some thoughts....

Typically, a filter wheel is in close proximity to the camera sensor, so that those dust donuts are usually small in size and are the ones you're trying to accommodate for with flat fielding. Typically, the camera and filter wheel rotates together. If that's true for you, then the donuts should not move with respect to the image as the rotation angle changes. Maybe there are second-order effects cause by imprecise optical axis alignment combined with flexure.

The other serious problem is, as Bob mentioned, vignetting. In that case, the camera and filter wheel will likely be rotating with respect to the various "stops" that cause vignetting, which would then be difficult to flat-field away.

I have a Meade Classic, which I bought long ago without a wedge but with a derotator. The derotator worked fine, but I only used it for a year or so. It was cumbersome anyway and difficult to use for those high-elevation images near zenith. I subsequently build a wedge and remounted the Meade on it.

Quote:

---

Originally Posted by Dick Berg

Typically, the camera and filter wheel rotate together.

---

Ah, bless you. I think that clears up some of the confusion I was having. -Jesse

Quote:

---

Originally Posted by Bob Denny

ROT_PA is the Mechanical position. ROT_PA is the latter number, yyy, the derotated mech angle. Use this for flat fielding.

---

Um, okay? So if ROT_PA doesn't change over the course of a run spanning a large alt-az range then the rotator doesn't rotate?

My view of the rotator doesn't rotate unless I rotate it. Under the covers, the derotator is turning. I see a rotator that is referenced to the equatorial coordinate system. I'm not sure how else to explain this. If I ask for some PA both the mech and sky angles stay the same all across the sky. It's like it's mounted equatorially. The PlaneWave control system creates this illusion. Maybe the PlaneWave creates an illusion where the mech and sky angles are always equal ([fixed-offset] = 0).

Quote:

---

Originally Posted by Bob Denny

the derotator is turning

---

So I guess my question at this point is whether the flat vignetting pattern in front of the rotator (e.g. the pattern created due to the OTA) rotates with the "derotator" or holds steady with the PA over the course of a set of images with varying alt-az?

My thinking is that it would rotate with the derotator, whereas flat patterns behind the rotator, (in my case patterns due to dust on filter and sensor windows) hold steady with the PA (per Dick Berg's comment). I suppose at this point the question is more hypothetical as ideally any OTA patterns would be (de)rotationally invariant such that I wouldn't need to worry my pretty little head, or lacking (de)rotational invariance simply try to stay close to the center cause they ain't much else one can do.

I'm no expert so I'll defer to those here who worry about such things. I just provide the tools.