I have noticed that PHD2 (with recent versions, currently using ver 2.6) is guiding on really really faint stars. It is insisting on using a star that is not saturated. This makes complete sense from the point of view that it can calculate a better centroid using a non-saturated star. However, this seems to be causing a real problem for me, and seems to be very different from earlier versions of PHD2 (maybe).
The problem is the guide star is so faint, it frequently loses track of the star, which forces SGP to restart the current image after it reacquires the star.
How is this different from prior versions of PHD2? Well, there is a complicating factor here for me. I recently changed guide cameras from a Lodestar X2 (8.6 micron pixels) to a ZWO ASI120MM (3.75 micron pixels). Also I think my focus with the ZWO is better than I ever had with the Lodestar X2. Although the Lodestar is much more sensitive than the ZWO, i am getting many more pinpoint stars than I ever did with the Lodestar.
So I have only noticed what seems to me to be a change in PHD2s choice of guide stars since shifting to the ZWO.
In any case, how can I get PHD2 to choose more saturated stars so that it does not keep losing track of the guide star.
Or can PHD2 be instructed to automatically shift to a new guide star, if it loses track of the current one? Hopefully without notifying SGP that it has halted guiding.
I’ll stand with you on this too, doesn’t always pick a really faint star but it does all too often. Had this
yesterday using PHD2 and the ‘Simulator’ camera option, as you said, a few times, the star it picked
from the simulated field was so faint that the image screen kept flashing red. Next time it picked one
of the brighter ones which I would have expected, I had the imaging rate set at 1.0 sec’s for the record.
At least with it doing it using the Simulator it will be easy to reproduce instead of anyone trying to blame
it on your guide cam or your settings.
Sorry guys, I can’t help without supporting data. We need log files and one or more FITS images (PHD2 menu: File => Save Image) where you believe PHD2 chooses the wrong guide star.
I seem to be getting this all the time now with PHD picking an extremely faint guide star . When I try to choose a brighter guide star, PHD goes into the recovery mode and keeps trying to select the same star. I’m sure that I have all the log info but not sure at what time this was all happening.
Next time out I will make a note of when things start to go south and take an image when PHD chooses a very faint guide star.
Got Log file for PHD2 picking an extremely dim star and a .fits capture of the image, just got to let SG Pro’s sequence complete and I’ll load them up…
PHD2 was using the Camera option: Simulator, On-Camera and once SGP had opened and connected said kit I changed the 'Camera Exposure Duration from 1sec to 2 sec and off it went.
So here is an image snapshot of PHD2’s camera window, the rather large red arrow points to the star PHD auto selected when SG P was forcing a re-Calibration to begin guiding as the sequence started:
Here is the PHD2 Log file which accompanied the Sequence Run:
And, Here is the SGP Log file JUST in case it may be relevant (NOTE: SGP Log may not be completely complete due to the fact that I added to this thread before disconnecting and closing SGP…Sorry):
Just wondering, but is the fact that PHD is tracking on a dimmer star really a problem? I know PHD will attempt to fit the start to a PSF curve. This means that it will try to make sure that the star has a well formed centroid and looks more like /\ rather than like /TTTTT\
Most of what looks like bright stars on the screen to us are going to be oversaturated and have tops like mesas rather than like peaks.
If it’s losing the star that could be an issue but I’ve found that I generally get better guiding on well formed, unsaturated stars than I do on bright, saturated stars.
It would be pretty cool if PHD could track multiple stars and compute an average motion based on 3+ stars and use that for the actual correction. Also if one drops then you still have others. I have no practical experience saying that would actually work better but it sounds like something fun to experiment with You could even calculate rotation and polar misalignment real time (maybe?)
I have had a lost star experience several times and they had a nice /\ to begin with, maybe the dim stars are a little to close to the random noise around them, just a hunch as I know nothing…But Andy Does
I started this thread because it was a problem I have noticed occationally when I happen to be watching PHD2 tracking. The problem is it sometimes loses track of the star and cannot recover it. This forces SGP into recovery mode and an entire sequence of centering the target is then performed. Plus you lose the image it was working on.
In the limited testing I have done where I just start PHD2 tracking so I can pick my own star, I have not noticed any consistent difference in the RMS error values. PHD2 usually picks a star with my setup that has an SNR around 30. When I pick one with SNR ~= 45 it tells me it is saturated, but I have never then seen it lose the star, and I get the same tracking errors.
The idea of tracking several stars at the same time is excellent and would completely solve this problem. An alternative that might be easier to implement and might be almost as good, would be for PHD2 to immediately pick another guide star and forge ahead without any interruption in the guiding.
Anecdotes like this help us become aware of a potential issue. Great. But we cannot diagnose it or do anything to improve it without the supporting data. Specifically, we need a PHD2 debug log and guide log and a .fit image (File => Save Image in phd2).
@Andy, I am at a loss as to why my logs would be of any help to you. This must happen to every user from time to time. Both PHD2 and SGP are behaving exactly as I expect them to, and corrrectly. This is normal behavior. If PHD2 loses the guide star and cannot reacquire it, then it quits guiding and this forces SGP into recovery mode and loss of current image. That’s the way they are supposed to work, under the current design. How is a log of this happening going to help? Last time I tried to create a fits image at that point, it crashed SGP, so I am reluctant to try again. Recovery mode is better than a crash.
I must be missing something here.
I am just saying that this happens more frequently for me than it would if PHD2 chose a slightly saturated star. What I have found is it normally chooses a star with SNR around 30. Under observing conditions that are not perfect and I see this happening frequently, choosing a star with SNR around 45-50 eliminated the problem.
Ideally PHD2 will just instantly shift to a new star if it loses the first one. Then there is no need to adjust its rules.
I found this jpg I made of PHD2 when it lost the star.
My goal for PHD2 is that it should automatically select the best guide star in the field. Hearing that you had to manually choose a better star indicates that PHD2 is not handling your camera/scope/focal length/star field as well as it should. Chances are if it is not working for you, then it is not working for others with similar guide configurations either. If I can get the logs and a fits image then I can evaluate why PHD2 chose the star that it did and potentially improve the star finder algorithm. We have a collection of FITs images that we have gathered from a wide range of PHD2 users, and we can add your image to the collection to ensure that future versions of PHD2 continue to choose the optimal star in your FOV.
Sorry to hear you had an SGP crash. I don’t think we have enough data to establish cause and effect here. I can’t imagine how saving an image in PHD2 could result in SGP crashing. The only way we can establish a link between the two events (if there is one) would be to look at the PHD2 debug log and SGP log from the time of the crash. Any chance you still have the logs?
I implemented a multi-star guiding algorithm into PHDv2 a couple of years ago. It used the centroid of several stars as its guiding point. That is the only way I could figure out to account for all of the sources of motion: RA periodic error, dec drift, field rotation, and seeing. So, it still wouldn’t work if you lost a start.
My results were that, if you had multiple stars that were all near the same SNR, and that SNR was the highest that was useful for guiding, then guiding would improve 10 to 20 percent. But, if you mixed in lower SNR stars with a high SNR star, your guiding was worse than it would have been with the single high SNR star. I kind of abandoned the idea when I got a new camera and got busy with other stuff. Since then, both the development environment and the base classes that I was using to identify stars in PHD2 have changed and my code no longer works. I do plan to try again some day, but I will be a while.
When I first started this, I tried to figure out a way to implement what Jared is suggesting, average the independent corrections from several stars, but could not find a way to remove the movement due to field rotation (which we do not want to correct on) from the process. My math is just not that good!
Seems to me this approach is making it more complicated than it needs to be. Why not make it simpler with the following:
keep track of several stars, but only use the best star for guiding. This gives the 10-20% improvement, and for the actual guiding is identical to what you are doing now.
The other stars are backups. If the best star gets lost, shift automatically to the next best star that is still viable.
This approach should be much easier to code. Your current code I would not think would be changed, except on a lost star failure there would be a new branch.
I think the crash was could easily have been a random event, very possibly caused by my clicking somewhere I did not expect to. I was running remotely from Colorado and my observatory is in NM, so there is some display delay. But at that point I quit trying to create a fits of the screen. don’t think I can find the log.
If you have been guiding on one star, and then switch to another, you will have a new lock point. It’s back to the issue of being able to separate out the motions for which you need to correct (PE, dec drift) from those that you do not (seeing, field rotation). Field rotation will always be around the guide star. If you switch guide stars during guiding, you either start guiding on a star that has already rotated or de-rotate your field by going back to the position that the new star was when guiding started. Either way, you now have a new lock position that does not correspond to the previous one.
That’s why I chose to use the centroid–rotation will be around it and doesn’t show up in guiding–just like when you guide on a star.
You could even calculate rotation and polar misalignment real time (maybe?)
