Rotator angle meaning for OAG - and sync

Sequence Generator
1

I haven’t been clear on how the rotator angle is being set and what it means.

I am using OAG and I want the rotator angle to indicate the exact angle of the OAG - independent of the image angle. So I can manually adjust its angle so it is exactly N/S and at that point use Manual Sync to set the value to be exactly zero - and I hope stay that way - assuming that calibration is stored with the Pyxis 2" rotator. I’m hoping that calibration ‘sticks’ and is the same after I shut down and start a new session.

From then on I want the angle in the rotator control to correspond to the true, calibrated OAG angle - independent of the image angle.

But I’m seeing odd numbers showing up in the fits header and in the rotator control. RIght now the Position value in the rotator control is 123.66 after I had done a Set Position of 124.0. That by itself is ok and it means I asked for 124.0 (oag angle) and got 123.66.

But the FITS header says the Image Angle is 123.66 and the camera rotator position angle is 126.27 - this is in an image captured during a sequence. The difference of about 3 degrees is about how far off the oag angle is from being calibrated to N/S.

I can provide logs - but this is largely a question of what these numbers mean and what sync does. I want to calibrate the rotator based on my own definition of what zero is - and from then on have that number stored in the fits header as the rotator angle. This lets me dial in oag angles accurately - and it lets me take flats at the exact angle the image was taken - all referenced by the OAG angle.

So what does sync do exactly - and how are the angles in the fits related to the values in the rotator control? Do the numbers get changed after doing a solve and sync? If so I wouldn’t want that to affect the rotator angle. It’s ok if it sets the Image Angle based on the plate solve - but I want the rotator angle to be set by the sync I did and nothing else.

Thanks,
Frank

2

Firstly, the ASCOM Rotator provides no ability to “sync”. So we handle this inside of SGP, from now on I’ll be referring to this internal angle, not what your rotator says.

When a plate solve occurs we update the sync angle for the rotator and update the offset from your actual rotator position. This allows us to store a meaningful angle with your sequence as well as have a reference point to use from the Framing and Mosaic Wizard.

We never change the actual rotator angle as we can’t (other than actually rotating it).

The value stored in your fits header will be the sky angle.

Hope that helps,
Jared

3

SGP writes two keyword records to the FITS header:

  • ANGLE - the sky angle Jared just described
  • POSANGLE - the “raw” rotator position as reported by the ASCOM driver

See this post.

Andy

4

When using a rotator with an OAG, there are two position angles involved. The “instrumental position angle” (internal, arbitrary position) and “sky position angle” (projected angle of the camera chip on the sky).

SGP assumes the rotator is sending its internal position angle (ASCOM requirement) and must setup mapping to the sky position angle that is reported by a plate solve and sync.

When you home your rotator, it will stop at some internal position reference (perhaps 0 degrees, perhaps not) and report that to SGP. After you do a solve and sync, SGP will then know how the mechanical position angle maps to that sky position angle. Then, when you need SGP to move the rotator, SGP will know how to send the correct move command to the rotator.

The rotator probably has control software independent of SGP and that software may be able to tell you what the internal angle is but I don’t see any value in that. The only issue is the sky position angle of the imaging chip / OAG chip.

It may be a waste of time trying to use the instrumental position angle to do anything. Take an image, plate solve and sync. SGP will then know what the camera angle is. You can then tell SGP to move the rotator to what ever sky position angle you want the camera in.

Note that your rotator’s ASCOM interface may have a “reverse direction” option. This may be needed if you tell SGP to move from 120 degrees to 140 degrees and after the move another plate solve shows the camera is at 100 degrees. The rotator moved the correct amount; just in the wrong direction.

Once SGP has sync’d the rotator’s position to the sky position, you must not use the rotator’s software to move the rotator – only use SGP.

For me, I have a field of view indicator showing the imaging chip and OAG chip setup in TheSky. I can move the FOVI to a position that puts the OAG chip on a bright star. TheSky tells me what that position is. After doing a plate solve and sync, I tell SGP (or let SGP do it automatically) to move the rotator to the position given to me by TheSky. The bright star ends up on the guide chip in PHD2 Guiding.

I spent a lot of time trying to get my Optec Gemini Focusing-Rotator to stay in sync with SGP but it just doesn’t because of the instrumental -vs- sky thing. So, I:

  1. Home the rotator (instrumental position 0)
  2. Attach the camera so I don’t get cord wrap
  3. Plate solve and sync in SGP
  4. Always use SGP to move the rotator to the required sky position angle.
  5. Set the reverse direction option
  6. Disable Home On Start so that the rotator stays in the last set position.

Charlie

1 Like
5

Hi Charlie, thanks for the good write-up.
I think the primary thing the instrumental position angle (POSANGLE FITS header) is good for is keeping track of what flats are needed. When I use the rotator to find a guide star, I let SGP rotate the camera at the meridian flip which changes POSANGLE by 180 degrees (but the sky angle, ANGLE, stays the same). I have separate flats for each POSANGLE.
Andy

6

Andy:

I see statements about taking flats to match the rotator position but I have never understood the reasoning for that. As far as I know, the two reasons for flats are to compensate for vignetting of the light path and to process out dust mots on the filters and CCD chamber cover glass.

However, as the camera rotates, the filters, the CCD chamber window and their attached dust mots rotate with the camera; that is, dust mot projection onto the imaging chip never changes. So, different sets of flats are not needed for that. The vignetting in the light path is round (symmetrical) so it does not change as the camera rotates. I suppose it could be possible for there to be an asymmetrical vignetting situation but I am hard pressed to see how.

I also saw a post saying you needed rotator based flats to compensate for the dust mots on the front of an APO lens and on the front of an SCT corrector plate. But dust mots in those locations are so far out of focus as to be immaterial.

So, why do people take sets of flats to match differing rotator positions?

Charlie

7

Hi-

It sounds like things are set up where the rotator angle is assumed to be directly associated with the Sky-Image angle - and in my case - and for people focused on OAG stars - the image angle is secondary. It is what it is - and everything is focused on setting the OAG angle accurately - and calibrating it well to the position angle of the guide sensor relative to the center of the image.

So for my imaging - both the image and the flats - I want the oag angle set exactly the way I want it.

My 2" Pyxis has a feature that allows calibrating the angle to the way it is installed - but I guess that isn’t exposed by ASCOM. But I thought that what the ‘sync’ button was for in SGP. That appears to be wrong - and somehow it is directly related to the position angle of the image.

I’m not clear if I can use the Pyxis utility to calibrate the rotator angle so that ascom and SGP are then working with the calibrated and exact oag angle - as set by me. I guess that is the raw rotator angle - and as long as I can always set it in sgp for imaging and flats - and it goes directly to that value - it would work ok.

But I would think there are others who use the rotator as I do - and the sync operation could be more generic and work for oag.

As for the question of flats - in theory the shadows don’t change for flats as you rotate the image train with the rotator - but the field illumination may not be exactly rotationally symmetric - so the theory may not hold.

Frank

8

Not having a rotator it’s completely possible that I’m missing something here. But it seems that the following would always be true:

  • Since sky angle and rotator angle are always linked going to the same sky angle would result in the same rotator angle.
  • Planetarium applications allow creating a FOV indicator with a pick off prism that can be set relative to the angle of your imaging chip. The angle of the imaging chip here is always specified in Sky Angle terms and can be entered directly into SGP.

So I guess I don’t understand why the sky angle implementation isn’t adequate here. It seems to my like it would be preferred as you could pick your targets before hand, and using a FOV indicator in your favorite planetarium application figure out the sky angle that places your pick off prism where it needs to be.

Jared

9

For oag imaging with a rotator, the two critical goals are 1) center the imaging camera on the target and 2) center the guide sensor on the selected guidestar. SGP is designed to center objects well (though my mount requires an alternative approach than sync/slew) but it apparently has no direct way to set the OAG angle - if that angle does not match the imaging camera exactly. In my case it is about 2.6 degrees off - which is fine for me because a slight error in the image angle doesn’t matter too much - but a slight error in the oag angle will miss the guidestar or leave it off center.

The holy grail for me is fully automated imaging of multiple targets with OAG and sct. I think that is perfectly achievable with sgp but for me it would require doing the center differently - as I have described in a feature request. But even without accurate centering, many users would like to specify the OAG angle accurately so the guide sensor lands on the guidestar by entering the rotator angle directly as read off a planetarium program used for framing the object. It has a real physical meaning - the PA of the guide sensor from the target - so it is natural to calibrate the rotator so the rotator angle matches the OAG PA angle. Because it is what you want to set when you go to the object.

SGP can already deduce exactly what the PA of the image is from a plate solve - and do it very accurately. But it has no way of knowing or deducing the OAG PA. The user needs to figure that out - and then sync the rotator to that angle. That only needs to be done once - and then you just set the rotator angle and the guide sensor will be in the right place.

This is common practice with OAG imaging, where the guidestar is pre-selected.

Frank

10

In looking at the log it appears that every plate solve causes SGP to sync the rotator to the measured image angle. I think everything would be fine if it just didn’t do that. And for many mounts, there is a desire for plate solves not to sync the mount RA/Dec either.

In this case the rotator ‘sync’ is internal to SGP and the rotator doesn’t see it. But for the mount, the sync is an ascom call and impacts the mount model. But it doesn’t work well for my mount - and other mounts also have issues.

But the rotator does have an explicit “Manual Sync” button - which I think is good. But what wasn’t clear to me is that that sync is over-ridden by plate solves.

So what I suggest is the following:

Allow an option for plate solves not to sync the rotator.

Allow an option for plate solves not to sync the mount

Provide a manual ‘sync’ button for the mount if the user does want the mount model changed.

Keep the existing ‘sync’ button for the rotator - and use it to calibrate either the oag angle or the image angle - it’s up to the user to sync to whatever he/she chooses.

And just like with the rotator, where a manual sync causes sgp to keep track of the rotator offset, allow an RA/Dec sync offset internal to sgp that allows it to solve/slew with any mount and converge accurately on the target - without altering the mount model.

Frank

11

Frank:

I’m sorry but I don’t understand your issue. As far as I can tell, SGP is managing the rotator properly. When I use my field of view indicator in TheSky, it shows both the imaging chip and the OAG chip. In the FOVI, the OAG chip is properly spaced and positioned with respect to the imaging chip. It doesn’t seem to me that the absolute positioning between the OAG chip and the camera chip is important but that might be where I am getting lost. The OAG chip is always at the same relative position to the imaging chip.

My challenge is to frame the target with the imaging chip and also get a bright star on the OAG chip. Imaging at 2400mm makes that a bit of a challenge for lots of targets. So, many times there must be a compromise between what I would like to do with the framing and what is necessary to do to get a usable guide star on the OAG chip.

But once I have made my positional decision, the ThySky gives me the sky position angle of the imaging chip that is needed to get the guide star on the OAG chip. I plate solve and sync so SGP knows the current sky position angle of the imaging chip and then I can give SGP the actual sky position angle (of the imaging chip) needed to put the OAG chip on the guide star. SGP moves the rotator to the specified sky position angle and everything is ready to go.

SGP does not need to understand what the sky position angle of the OAG chip is. Just tell SGP what the sky position angle of the imaging chip needs to be in order for the OAG chip to be positioned where you want it.

Charlie

12

Frank:

After posting, I realized that I am talking from the perspective of having the pick off prism / OAG chip at a fixed position relative to the imaging chip (QSI683wsg). If you are using a separate OAG arrangement (such as the Astrodon MMOAG), then you can mount the pick off prism / OAG chip in multiple positions relative to the imaging chip. This makes having an FOVI that matches the current OAG position a challenge and there does not have to be a consistent relationship between the imaging chip and OAG chip. But you can still tell SGP the sky position angle of the imaging chip that is needed to put the OAG chip where you want it.

Charlie

13

In my case I have a separate Hutech oag5 so the imaging sensor orientation could be anywhere relative to the OAG. But in my case I have the two nearly in line but not exactly - there will always be a slight offset.

For normal sgp usage there are features to help the user by making sure the rotator angle exactly matches the sky image angle. This is done with a manual sync feature and by syncing the images after plate solve. This is not at all necessary for an imaging session because you could figure out the angle of the image to the sky and then set your fovi at that angle and manually adjust it - but that would be annoying and it is completely natural just to have the rotator angle correspond to the important physical reference involved. And that’s what I am looking for, but for the oag angle.

I should never need to know or calculate the offset of the oag angle from the image angle because my calibration process involves setting the oag exacly N/S of the image center where I know its PA is zero - and then I tell SGP or the Pyxis “That is zero.” After that - the PA of the guide sensor on the fovi is exactly equal to the rotator angle. But unfortunately SGP doesn’t work that way.

I think there are others in this thread who operate the way I do so I’m not alone in this. It’s a very basic type of calibration done for many things, including a weight scale for example: you set it up so it should be reading zero and you say ‘zero it here’ - and from then on the measurement that is important to you is directly settable and readable.

And as for syncing the mount and the rotator - in both cases there are situations where you may or may not want the device itself to be altered and you want sgp to keep track of the zero offset. I’m saying both centering and rotator usage would be better if sgp could keep track of the offsets and adjust them as needed - without telling the device.

Frank

14

I did a new imaging session last night with 2.5.0.16 and took more care to look at the values shown in SGP. In this case I carefully set the OAG angle N/S and then used the Pyxis Rotator Control to calibrate the pyxis to exactly 0 degrees PA by using its “Set Current Sky PA” button. This is what I thought was equivalent in SGP but it is fundamentally different.

Using this feature in the Pyxis control permanently changes the meaning of the 0 in the Pyxis - and it applies that change in all ascom interactions. So from then on - the ‘raw’ angle value coming from the Pyxis is exactly what I want to set or read the current PA of the OAG. It is the true and accurate PA of the OAG sensor relative to the center of the imaging ccd as calibrated once by me.

But in SGP there is no way to set or even see the true ascom value coming from the rotator. I think when it first connects it shows it - but as soon as you do a solve/sync - you can no longer read what the ascom device is saying. This is particularly confusing since the rotator control has two values shown: Position, and Set Position. In fact those are the calibrated sky angles of the imaging sensor and not the rotator itself.

Fortunately the true ascom angle is stored in the fits header with saved images - but there is no way to know that angle without saving the file and then opening it and reading the header.

With a telescope mount, when you plate solve sgp does a sync of the mount so that the mount model itself changes and SGP will faithfully relay what the mount says it is pointing to - and that is different from what the plate solve says it is - and that is all fine. But for the rotator SGP is altering the value itself for a specific purpose that doesn’t apply to everyone - and it prevents the user from directly setting and reading the angle used by the device.

So I really think this should be changed - both the way the rotator functionality is described and how it behaves. None of this would seem needed for people doing mosaics with guidescope guiding - but oag work also relies on rotation and it needs to be done accurately - especially if the guidestar is to be found easily or during an automated imaging session.

Frank