Rotator, Acquire Star, Positioning, and Guiding Issues

[Jim McMillan]

Hi Andy,

Forgive me for being slow, but I think I need help understanding your analysis.

Assuming:

1) a GEM
2) no offset between the camera and rotator
3) object in eastern sky

Then by definition, RawPA = ActualPA

(FYI, Bob uses the terms rotator PA = sky PA in the documentation.)

The direction the rotator must rotate when the ActualPA increases depends on how many mirrors your imaging system has. With an even number of mirrors, the rotator needs to rotate counterclockwise. With an odd number of mirrors, the rotator must rotate clockwise. Since most of us either have 0 mirrors (refractor) or 2 mirrors (SCT), the rotator must rotate counterclockwise to increase PA. (I think this is where your analysis might go astray - or I just don't understand it.) Therefore, for all objects in the eastern sky, for all PA's, ActualPA = RawPA. FYI, for a 2" Pyxis, this means you must check "reverse" in the rotator setup. I'm pretty sure Optec changes this in the 3" Pyxis, so "reverse" should be unchecked.

When the GEM flips, the OTA orientation changes by 180 degrees. So to keep the same ActualPA, the camera orientation, and thus the RawPA, must change by 180 degrees. Therefore, for all objects in the western sky, ActualPA = RawPA +/- 180.

Since this thread started because of guiding problems, perhaps I should ask whether you've got that sorted. If not, perhaps the above explanation with help you. Also, note that all guider calibrations need to be done with a star in the eastern sky, "pier flip" unchecked in MaxIm, and MaxIm telescope control disconnected (e.g. ACP manages the status of "pier flip", not MaxIm). If this is not done exactly this way, ACP will end up adjusting the camera guide angle by 180 degrees. The effect is that guiding works when using MaxIm standalone, but once ACP adjusts the camera guider angle during an automated run, guiding no longer works. (This is all caused by ACP's interpretation of the sense of "pier flip" and whether to adjust the camera guider angle by 180 or not. That's why you have to calibrated your guider exactly as I described above so that ACP can correctly managed the sense of "pier flip".)

FWIW.

Jim

[andyschlei]

Jim,

Thanks for the reply.

First, the guiding problems only occur when ACP does not handle a change in the rotator position properly. If the guider position is close to where calibration was done, it works fine. If not, guiding fails until the guider is re-calibrated.

Your formula that RawPA = ActualPa only is correct if the rotator's zero point is exactly aligned with actual position alignment. This is rarely true, and ACP should be able to correct for a difference. The ACP log entries even speak about this difference. Don't you agree?

In addition, in my case, RawPA and ActualPa move in opposite directions. The formulae provided were not abstract, but were the result of actual measurement of rotator behavior. I wasn't describing an abstract, I was describing the actual. Those formulae could be used in software to adjust and predict rotator position.

I didn't look at counterclockwise vs. clockwise. That's not measurable since I don't know the reference point for the statement. Actual PA and Raw PA are. And I'm sitting in my warm room, not looking at the scope. This is for remote control, after all.

Your comment about "reverse" might be the key to the problem. It is clear from my measurements that my RawPA goes opposite to the ActualPA. If I can stand another night of testing, and get it in before my 60 days runs out, I'll try that change.

There are two key anomalous behaviors:

1. On each alignment run, ACP decides to move the rotation to some weird location.
2. There is a total failure to adjust the guider calibration in Maxim to reflect the revised alignment.

Both of these could be due to the fact that ACP can't handle the direction that the Pyxis is passing to ACP, or that the ACP is expecting the "reverse" flag to be checked.

BTW, on all "pier flip" comments, all work was done looking to the east, except for the work verifying the formulae.

Thanks for your response and please forgive me if at any point I was testy. I am just trying to be clear.

-Andy

[Jim McMillan]

Hi Andy,

Your formula that RawPA = ActualPa only is correct if the rotator's zero point is exactly aligned with actual position alignment. This is rarely true, and ACP should be able to correct for a difference. The ACP log entries even speak about this difference. Don't you agree?

Your statement is correct on both counts. However, conceptually it's a lot easier to think about this assuming there is no offset. ACP does indeed deal with this automatically.

In addition, in my case, RawPA and ActualPa move in opposite directions.

If this is what's actually happening, there is something wrong.

I didn't look at counterclockwise vs. clockwise. That's not measurable since I don't know the reference point for the statement.

Conceptually you are rotating the sky clockwise to increase PA. To see that same effect on your image, you must rotate your camera counterclockwise (from a position behind the camera). Again, this rotation direction is affected by the number of mirrors in your system.

And I'm sitting in my warm room, not looking at the scope. This is for remote control, after all.

Knowing the rotation direction of your rotator is absolutely necessary to get this right. Of course, once set correctly, you never have to worry about it again.

Your comment about "reverse" might be the key to the problem. It is clear from my measurements that my RawPA goes opposite to the ActualPA. If I can stand another night of testing, and get it in before my 60 days runs out, I'll try that change.

I'd bet this is the problem. If your setup has 0 or 2 mirrors (I don't think I know for sure) and you are using a Pyxis 2", I'm 100% sure you need to check "reverse". If it's not checked, that's the problem.

There are two key anomalous behaviors:

1. On each alignment run, ACP decides to move the rotation to some weird location.
2. There is a total failure to adjust the guider calibration in Maxim to reflect the revised alignment.

#1 happens because the rotator is going the wrong way. Say you want a sky PA of 315. If the rotation direction is backwards, the rotator will go to rotator PA of 45 (and indeed, a sky PA of 45 as well). Assuming no offset, the FOV of your guider is now 90 degrees from where you want it to be.

#2 happens because ACP expects the rotator to be where it's supposed to be, not where it is. So, the guiding angle given to MaxIm doesn't work.

Both of these could be due to the fact that ACP can't handle the direction that the Pyxis is passing to ACP, or that the ACP is expecting the "reverse" flag to be checked.

I think I'd say it this way: by definition (assuming no offset), for objects in the east, ACP expects the sky PA to equal the rotator PA. It's up to the user to make sure this is the case via getting the rotation direction correct. If this condition is not true, then it won't work correctly.

Thanks for your response and please forgive me if at any point I was testy. I am just trying to be clear.

No apologies necessary. Just check reverse and enjoy using ACP!

Jim

[andyschlei]

Jim,

I'd bet this is the problem. If your setup has 0 or 2 mirrors (I don't think I know for sure) and you are using a Pyxis 2", I'm 100% sure you need to check "reverse". If it's not checked, that's the problem.

I've got an ST-10 on an NP-101. So that's no mirrors. I think we've found my configuration mistake.

I hope I'm not too tired tonight to get things setup when I get to the observatory (traffic will determine that). In any case I can check it on Saturday.

Thanks,

--Andy

[Bob Denny]

Wow, Jim!!! Thanks for helping Andy. I think you nailed it. I apologize for being so busy and getting a bit behind.

[andyschlei]

Jim,

You really did nail it. I had some sort of error trying to get to the ASCOM control for the Pyxis in the Rotator Controller, but I was able to get to it through Maxim and change the checkbox to reverse. That solved the core problem. Thanks for your help.

Now I still have a quibble. On my test run, it went to M33, checked positioning, moved and rotated, and started the first exposure. This exposure was not centered. After the first exposure, it corrected the centering and a that point it was perfect. I would think that an additional check exposure before assuming you are centered would be a good idea. But that's a suggestion, not a bug.

BTW, it does turn out that my first post was correct. I had an incorrect setting in the configuration. And now I've found it.

Thanks,

--Andy