SharpCap Forums

I have noticed some odd guide star selection problems in SharpCap when guiding with PHD2. The more I have automated image capture using sequences, the more noticeable the problems have become.

My scope is an 11" Celestron with an off axis guider. I always run the scope at F10, so the guide field is pretty small. Here is the sequence code that I usually use to start guiding, including error handling when guiding fails to start the fist time. Not sure why this occasionally happens, but a retry seems to do the trick unless something has really gone wrong (hardware connections, etc). Note that it doesn't try to launch PHD2 unless the initial guiding connect fails, which almost always means PHD2 is not running yet. It seems that the GUIDING CONNECT operation will cause PHD2 to connect to the last hardware it used (camera and mount), which is convenient.

# if it connect fails, it tries a second time after launching PHD2
# if PHD2 is already running this will result in an error dialog from PHD2,
# but at least we gave it a shot
DEF SUB RetryConnectAfterStartingPHD2
RUN "C:\Program Files (x86)\PHDGuiding2\phd2.exe" WITH PARAMS "" WAIT False
COUNTDOWN FOR 5 SHOWING "Waiting for PHD2 to connect to mount and camera..."
RETRY ERRORS UP TO 4 TIMES
GUIDING CONNECT ABORT False
END RETRY ERRORS
END SUB

DEF SUB GuidingConnectandStart
IGNORE ERRORS FROM ONERROR RUN RetryConnectAfterStartingPHD2
GUIDING CONNECT ABORT False
END IGNORE ERRORS
GOSUB GuidingStart
END SUB

# Start guiding:
# This will get automatically PHD2 to also automatically connect to the mount and guide camera
# if they aren't already.
DEF SUB GuidingStart
SET PLATESOLVE/FOCUS SETTINGS EXPOSURE 6
SHOW NOTIFICATION "Waiting for guiding to be active..." COLOUR Amber DURATION 30
IGNORE ERRORS FROM ONERROR RUN \"GuidingStartFailure\"
GUIDING START
GUIDING WAIT
SHOW NOTIFICATION "Waiting for guiding to be active...guiding is now active with no errors" COLOUR Green DURATION 30
END IGNORE ERRORS
WAIT FOR FRAME
END SET
END SUB

#begin guiding:
GOSUB GuidingConnectandStart

Note that the GuidingStartFailure subroutine called if guiding doesn't start is omitted here as it rarely gets called. Its only activated if I am unlucky enough that the guiding field is in a star desert where there are no stars bright enough for guiding.

Now all this works reliably for the first target of the night. After I do a meridian flip in my automation or go to another completely new target and my sequence automation starts guiding gaain, I would expect PHD2 to pick a new guide star with a high SNR. Instead, I see that PHD2 will do one of two things:
1) Report star lost and it selects a new guide star with a good SNR.
2) Selects a guide star in the guide field close to where the previous imaging target's guide star was located in the previous guide field. If this star has an SNR below the minimum I have set in PHD2, it selects it anyway. I have to intervene and manually select a new star when this occurs due to PHD2 frequently losing its chosen dim star when it attempts to guide on it. This makes automation not so automated, so I can't nap through a meridian flip.

BOTTOM LINE:
My interpretation of these observed behaviors is that after a slew, the previous guide star is not cleared in PHD2. It looks like the PHD2 server API does have support for forcing PHD2 to deselect the current guide star. I don't know if this PHD2 function is not reliable, or if SharpCap is not using it. It seems that if SharpCap detects a new target, or the same target, but finds that the scope is now pointing at it from the opposite side of the pier, it should tell PHD2 to clear the previous guide star.

I understand that deciding when there is a "new target" and PHD2 needs to select a new guide star may be a bit challenging to implement. The whole point of using the PHD Server is to allow SharpCap to be agnostic about how guiding is performed. SharpCap has no idea how big a slew will result in a new guide field. I guess PHD2 itself is in a similar predicament as to when the target has changed. However, unlike SharpCap, it knows how big the guide field is, so it should know when there is a whole new guide field, or a meridian flip has occurred, and thus the previous guide star is gone for good.

If it is difficult for SharpCap to detect when the old guide star should be deselected, maybe you could add a sequencer command that sends the "Clear guide star" command to the guiding application.

An extra note: PHD2 docs says "Stop Guiding when mount slews" should always be checked, but it was unchecked in my PHD2 config for some reason. I thought this might be causing the problems I was observing, so I turned it on. Unfortunately, this didn't seem to help at all.

Hi,

OK, I think I can have a fairly good guess at what is happening here...

SharpCap's start guiding procedure works like this (with PHD2)

* Check for hardware connected in PHD2, connect default hardware if not already connected
* Check for camera looping, start camera looping if needed
* Check to see if a star is selected - tell PHD2 to select a star if no star selected
* Request a guiding start (which will calibrate if required).

So, I suspect that sometimes after the meridian flip, PHD2 will find a star near enough to the previous position to latch onto it. That will mean that SharpCap will see that PHD2 has a star selected and won't bother asking it to select a new star, and you hit the problem. On other tries, either there will be no star near enough to get picked up, or a nearby star will be selected then lost, leading to the 'find_star' command being sent by SharpCap and a new, valid star gets selected.

I just had a look at the PHD2 documentation for the API that SharpCap uses (https://github.com/OpenPHDGuiding/phd2/ ... Monitoring), but I didn't spot any way to clear/forget the guide star in the 'Available Methods' section. Was that the API you were looking at?

cheers,

Robin

This doesn't just happen after meridian flips. Even in the case where you go to a totally new target and starting guiding from within SharpCap, PHD2 tries to find the same guide star, even though you are pointing at a totally different location in the sky!

Wow, I just noticed this is page says its the "old" way of talking to PHD2:

https://github.com/OpenPHDGuiding/phd2/ ... rInterface

MSG_DESELECT would seem to be the command to send using this older API.

I guessing you are using the newer API, which I must be this one (?):

https://github.com/OpenPHDGuiding/phd2/ ... Monitoring

and it doesn't seem to have an equivalent to MSG_DESELECT, of course. Maybe when pointing at a clearly new target in the sky or a meridian flip is detected to have occurred, SharpCap can call the "find_star" method to force it to look for a new star, even if PHD2 is in the "star found" state.

Hi,

thanks for confirming - I hadn't been looking at the old messaging system, since SharpCap has always used the new one. It does look like there is no equivalent, but maybe FindStar is the right way to go - I think I will have to test.

I can see the attraction of doing something differently after a flip has occurred, but the guiding control and mount control parts of SharpCap are quite separate, and making one know about the other is liable to cause issues. Hopefully there is a better way!

cheers,

Robin

Since I use an OAG on a GEM, the guide camera field is guaranteed to be completely different before and after a meridian flip. I guess its the same situation if you have an auxiliary guide scope on your scope.

If SharpCap guiding records the sky coordinates and the side of pier at the time a guide star is acquired when guiding is started, maybe that might be enough to decide at the next start of guiding whether to invoke the find_star method again. Invoking find_star every time guiding is started might be annoying in cases where you had to manually change the initial auto-selected guide star when guiding started (e.g. sometimes PHD2 will pick a close double star, which I think is probably a bad idea).

Now that I look at the API again, there is a get_pixel_scale and get_camera_frame_size method, so combined with the getting the star lock position, it should indeed possible to determine how much movement will take the guide star out of the guide field even when a meridian flip has not been performed.

Hi,

yes, I'm still a bit stuck on this one - I can easily force a find star every time, but that's wrong (as you say) because someone might have picked the star manually. While I can read the star SNR, making a judgement call based on it is tricky, since there is no clear threshold value that would be correct for everyone - I don't think I can read the SNR threshold out of PHD...

I wonder if I can get notification or find out that PHD considers the star to be low SNR and then trigger a find_star? Even that approach is troublesome, as it is the right thing to do in this circumstance, but not if there is scattered cloud that pushes down the SNR of the guide star briefly...

cheers,

Robin

I'm a little unclear as to why the guiding code can't look at the mount sky position. Is there a use case for SharpCap where it is connected to a PHD2 guiding server, but not connected to the mount being guiding?

If this is not an issue, I can't think of a way of solving the problem without capturing the mount pointing position at the start of guiding. Then using get_pixel_scale, get_camera_frame_size and possibly get_search_region and get_lock_position to determine how far the mount has to have moved for the last guide star to be outside of the guide field (or maybe just outside the guide star search region - there is definitely an argument to made for using this than the full guide frame). There are StarSelected and LockPositionSet messages, so maybe SharpCap could use these to monitor if the user manually selects a new guide star.

As soon as the last guide star is definitely outside of the field of view, but no new StarSelected messages are received (indicating the user has manually selected a guide star after the slew) by SharpCap after slewing to a new target, it seems to me that it would be a safe bet that SharpCap should call the find_star method to force a new selection.

After a plate solve, a previously selected guide star might move outside the search region, and then PHD2 would try using a different guide star. I think maybe it may detect guide star loss better if multi-star guiding mode is enabled. If PHD2 is in single star guide mode or PHD2 is in multiple stars guide mode but only detects one suitable star in the field, PHD2 probably needs some help not just picking the random star that happens to now be in the previous search region in the guide field. This is probably the best argument for using the search region size rather than the guide field size I mentioned above.

It seems me that PHD2 must expect a client scope control app using the PHD2 server for automation to take care knowing when new guide stars need to be selected, otherwise it wouldn't exhibit this annoying behaviour we are puzzling over.

Hope my ramblings make some sort of sense. I am sure I don't have a good feel for the full problem space here, since in my mind I am trying to generalize from the my own specific case. A long focal length with an OAG guide camera is not going to have the same set of problems that a shorter focal length auxiliary guide scope setup will have, that is for sure.

Hi,

the trouble really is that selecting a guide star (or not selecting one) is a PHD2 concept and doesn't apply necessarily to other guiding tools (The MGEN3 has no need to do this - you just tell it to start guiding and it gets on with it). The same applies to other PHD2 concepts like looping and connecting the hardware... The main part of SharpCap doesn't need (or want) to know about those PHD2 only things - it just wants to be able to ask the guiding to start and the detailed PHD (or MGEN) related code inside SharpCap takes care of *how* to get the guiding going.

Right now, it's the main code in SharpCap that knows about things like whether a mount is connected and whether it has flipped over the meridian, but that code has no knowledge of PHD2 and its need to find a new star under some circumstances. Making the main code aware of PHD2's oddnesses is a big no-no from a software design point of view - it puts code that needs to know about PHD2 in several different places and makes everything harder to maintain in the future.

Making the PHD2 code know about the mount is also a bit of a software design blunder (but probably not as big as the one above). Probably the best comprimise is to have some way that the PHD2 code can get notified if the mount changes side of pier (but not any other information about it), but even that has some complexities in the implementation.

That's the sort of situation I've arrived at after thinking about this for a bit, but I'm still not sure that there isn't an even more elegant/simple solution that I just haven't thought of yet - it feels like there ought to be - so I'm not making any changes for this just yet.

cheers,

Robin

admin wrote: Fri Sep 20, 2024 9:58 am Making the PHD2 code know about the mount is also a bit of a software design blunder (but probably not as big as the one above). Probably the best comprimise is to have some way that the PHD2 code can get notified if the mount changes side of pier (but not any other information about it), but even that has some complexities in the implementation.

Understood. I figured it was something like that, as this is the way to make a code base brittle and thus easily broken in the future.

It seems to me that SharpCap's PHD2 specific code doesn't need to receive events from the mount code when a meridian flip occurs or slews occur. The SharpCap's PHD2 code just needs to capture the mount pointing state when certain PHD2 specific events are received or after it sends certain commands to PHD2. Then, when PHD2 guide begins, SharpCap's PHD2 code can decide whether the current mount pointing state has changed enough from the last mount state it previously saved is large enough to warrant issuing the find_star command prior to commanding PHD2 to star guiding. This should hide all the PHD2 specific stuff within the SharpCap PHD2 code. The remaining problem then is deciding how much of a change in mount pointing position is the slew limit and if there is a difference between the behavior of single star and multi-star guiding in PHD2 that affects how large that slew limit should be for triggering re-sending the find_star command.

Hi,

yes, I am pretty much thinking that the events is the way to go - it might be also interesting in future for other things to take action on being notified of a slew happening (live stack might prompt to reset, etc)

cheers,

Robin