I typically like to pick my own guide star, calibrate and get Phd going before starting a sequence in SGP, but it seems that SGP forces Phd to change to an auto selected guide star despite guiding already going. Is there a way to stop that behavior and use the guide star I’ve selected?
Sorry forgot to mention that I’m using the latest release of 2.4.
SGP simply tells PHD to start guiding and it’s up to PHD to figure out what that means. If that means selecting a new star then that’s PHD’s call.
Are you using an option in SGP that is causing guiding to stop prior to your sequence starting? Such as stopping auto guiding for auto focus or having SGP auto center?
Yes, PHD2 should keep guiding on your selected star unless something tells it to stop and then start again, like an automated target change or meridian flip. Could you post your PHD2 Debug Log and your SGP log so we can figure out what happened? (Also please let us know what time it happened so we know where to look in the logs)
I typically do this. Basically I just start PhD guiding with the star I want, then stop it and when PhD resumes under SGP control, it uses the same star.
Yes I do use stop auto guiding for auto focus and I do have SGP auto center before starting the seqeuence.
Sounds like phd is selecting a different star when it stops and restart. Is the original one even in frame after the auto center?
Seems that if you want to pick the star you’re going to need to remove some of the restarts. Essentially you have to pick between automation and control.
I’ve found phd to do a good job picking stars. I just let it do its thing.
Yes the original is still in the frame. In the past I found that Phd occasionally picked a saturated star and that is when I started picking them manually. I need to try again and see how it does.
Is it very close to where it was originally (like within 10 pixels)? I believe that’s the default search box for PHD.
PHD runs a PSF fit on the stars when it’s figuring out which to select. It should avoid saturated stars. Also remember that the display is stretched so what is perceived as saturated my not actually be. You’d have to look at the star profile to verify.
In PHD2 v2.4.0 we pretty much rewrote the star selection code. Before that it was prone to select hot pixels, saturated stars, or double stars. We believe it is much better now and effectively avoids all those pitfalls.
One thing the would be really helpful would be if you do find a case where PHD2 choses what appears to be a less than optimal guide star, please grab the frame and post it so we can evaluate it. It’s simple: File => Save Image.
Ultimately, for automation we rely on a robust star selection algorithm, so we need to know about cases where the algorithm breaks down so we can improve it.
Will do. Good to know about the re-write.
While we’re on the subject, I see the newest release has an option “square pixels” would you mind telling me what and when that’s used?
Just so other readers know, you are referring to an option for the SX Camera built-in driver. It applies to SX cameras that have non-square pixels: the Lodestar and Lodestar X2 (8.2 x 8.4 micron pixels).
Lodestar users who use the SX ASCOM driver already had an option in the ASCOM driver to square the pixels. Squaring the pixels means to interpolate the real camera data onto a logical array of square pixels.
Internally, PHD2 assumes square pixels. This comes into play when converting pixels to arc-seconds for display on the graph. Another case where it might matter would be if you were using a camera rotator and OAG: the calibration would change slightly as you rotate the guide camera. In practice, the Lodestar pixels are close enough to square that none of this really matters, but we wanted to provide the option for non-ASCOM users to choose.