I use the Starlight Xpress AO and did not see anything which will run that (Maxim DL, for example). I looked at PH2, and it doesn’t have any such options. Do you have anything I can use to run the AO.
SGP won’t run it directly. I thought PHD2 was working on adding support for it a while back. Potentially through the SGP API Guider. But I honestly can’t recall where that was left off.
It is not supported directly by SGP nor should it be. It is a guiding device and therefore is supported by PhD. I have used one for several years with a Lodestar X2 guide camera and QSI imaging camera. I used this combo because Andy Glasso actually had this equipment when he was programming PhD, as I recall.
I thought the “Camera” setting is the IMAGING camera, not the autoguideing camera??!! I have “Camera” set as my ZWO 6200 and set the AO setting to SX-AO.
With PHD2 how do you differentiate the guiding vs imaging camera???
Or is PHD2 ONLY for autoguiding? In which case I guess I need to find a way to differentiate IMAGING vs AUTOGUIDING camera in SGP, which I can figure out how to do.
Yes, PHD2 is ONLY for autoguiding. SGP will take care of the imaging camera and PHD2 will handle the guide camera.
You do not need to specify the imaging camera in PhD, just the guide camera. Conversely, you do not need to specify the guide camera in SGP, just the imaging camera. In SGP you just select Phd as the guide program and all guiding related matters are done by PhD, including selecting the guide camera and AO (if any). The only guide related settings in SGP are those that tell PHD what to do during certain SGP controlled events. Below is typical but will change with the system.
Question: Near the bottom of the Target Settings, it states: “Rotate camera to ___ degrees +/_ 180. Is that the “position angle”(true astronomical angle of the target) or the reported angle from the rotator (what my rotator shows, which is not astronomically correct) . I am thinking it’s the latter, but am not certain. I can’t clarify that with the documentation.
If you have a plate solver connected then it is the Sky Angle. If you do not have a plate solver then we have no way of knowing what the sky angle is so then we have to just default to using the rotator angle…which is typically not very useful.
We will plate solve with pinpoint. The angle reported by the rotator is NOT the sky position angle. I use the RCOS TCC. So I am guessing the program will move it to the proper Position Angle, based on the plate solve. And therefore I should use the actual position angle . Correct?
The ASCOM interface always returns the rotator’s mechanical position angle. It is up to the imaging program to convert between the camera’s sky position angle and the rotator’s mechanical position angle.
After a plate solve, SGP knows the camera’s sky position angle. If the camera needs to move +28 degrees, SGP just needs to command the rotator to move +28 degrees from its current position. It is up to the ASCOM driver to move the rotator such that cord wrap is avoided.
True but if your rotator is set up the way it should be, it should be close. Not all rotators can be set up properly and the TCC is kind of ancient (speaking as someone who used to own one) so in that case, probably not.
Yes, SGP will calculate an internal offset for the rotator after the plate solve and then everything in SGP will be shown as based off of the sky angle vs what the rotator is stating. So if you pull up the rotator control in SGP you’ll see that the value displayed in SGP and the value on the ASCOM driver are not actually the same. SGP reports sky angle when possible as the rotator angle is generally not useful.