Patchy Clouds - Terrible Guiding - Could we have a poor rms alert?

[NY2KW]

Last night I was imaging from a remote site with NINA/PHD2. It became cloudy and not surprisingly there was a prolonged period of terrible guiding but it never stopped guiding.  So NINA chugged away and almost all my images were long star streaks.  From 23:44p – 04:23a there were Star lost - low SNR =293, Star lost - low mass = 88, Star lost - mass changed = 154 and  No star found= 24 with Total = 559 but guiding never stopped.  In spite of the long streaky stars or subs off target, NINA read the HFR as 1.9 -2.2 (which I don't understand). There was 3 short period of 'normal' guiding in this period.  I know there is a NINA plug-in called PHD2TOOLS that would allow triggers to stop guiding and recovery or end session but several others have said it is prone to crashing NINA and /or PHD2.   Is it reasonable to ask for some alert range within PHD2 that would either stop guiding or send an alert to NINA?

TIA, Jerry 

https://openphdguiding.org/logs/dl/PHD2_logs_VwXM.zip

[Bruce Waddington]

I think this is just another form of an old topic which is recovery from poor observing conditions.  Recovery belongs in the imaging application/session manager because that is the only place that has the context and all the necessary tools to do an effective job.  The role of PHD2 is to provide all the information necessary for an imaging application to know what's going on and make decisions about what to do - and that's what PHD2 does.  Applications can subscribe to a real-time broadcast of events which includes lost-star events (for any reason) and frame-by-frame details of guide star movement and corrections.  So PHD2 doesn't need to do anything new to 'alert' NINA,  that machinery is already in place.  Evidently, many of the session manager apps don't take advantage of this information which is unfortunate - but it's not a reason for PHD2 to further muddy the water by trying to take unilateral action on its own.  If the plug-in you're talking about doesn't work correctly, wouldn't it make more sense to address that?

Looking at the bigger picture, it sounds like you probably became very frustrated while trying to operate in conditions that were simply not good enough.  I know from experience that no amount of recovery logic is going to fix that.  <g>

Regards,

Bruce

[Jerry Stern]

Thanks Bruce.  Of course you’re right.  I later realized that NINA is receiving a real-time data stream from PHD2. I searched their API and found IGuiderMediator and next will look to see what it exposes.  Maybe I’ll write my own plug-in 😊

 

Jerry

--
You received this message because you are subscribed to the Google Groups "Open PHD Guiding" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-phd-guidi...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/open-phd-guiding/8472d321-a891-4de3-b65a-f9cc98a237b2n%40googlegroups.com.

[Dale Ghent]

Can you cite your source for PHD2 Tools plugin crashing "NINA and/or PHD2"? There are a lot of people in this hobby who say wild bs based purely on supposition and a complete lack of awareness of actual cause.

NINA itself has a built in "Restore Guiding" trigger that will always attempt to restart guiding if PHD2 is not actually guiding due to lost star or insufficient SNR - items that can also be adjusted in PHD2's own configuration so addressing this issue is not _purely_ a NINA thing. I've seen plenty of people turn knobs they shouldn't in blind attempts to solve a perceived problem and end up making things worse for themselves, whereupon blame is placed on anything but themselves.

-Dale

> --
> You received this message because you are subscribed to the Google
> Groups "Open PHD Guiding" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to open-phd-guidi...@googlegroups.com.
> To view this discussion visit

> https://groups.google.com/d/msgid/open-phd-guiding/71d80287-ae07-428e-90e7-46db52dca008n%40googlegroups.com
> <https://groups.google.com/d/msgid/open-phd-guiding/71d80287-ae07-428e-90e7-46db52dca008n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Brian Valente]

>>>  I know there is a NINA plug-in called PHD2TOOLS that would allow triggers to stop guiding and recovery or end session but several others have said it is prone to crashing NINA and /or PHD2. 

Jerry from your comments it sounds like you've maybe *heard* this but haven't tried the plugin yourself? 

To view this discussion visit https://groups.google.com/d/msgid/open-phd-guiding/09b2fda5-23c2-4cef-b648-4db11c0c9b9a%40app.fastmail.com.

--

Brian 

Brian Valente

astronomy portfolio https://www.astrobin.com/users/bvalente/ 

[Jerry Stern]

Hi Dale,

 

I heard from people in the Starfront Discord room who are respected as ‘veterans’ in AP, where this was discussed yesterday, so my gut reaction was to believe them.  Being a newbie at a remote site, I was reluctant to try things that may cause problems.  If you look at the PHD2 look I uploaded, PHD2 never stopped guiding for over 4 hours of crazy data so NINA could never “Restore Guiding” which I do have as a trigger.  I’m very new at this but it’s difficult to believe this would not be a relatively common scenario for remote imagers.  You are the Expert and if you say that PHD2Tools is stable – that’s a perfect solution and I will spread the news 😊

 

Best regards,

 

Jerry  

To view this discussion visit https://groups.google.com/d/msgid/open-phd-guiding/CAJa45i4qcMpk0%3DRbS5S%3DtcUSzV7PD--njp2DPZ7Fep-WnMxeGg%40mail.gmail.com.

[bw_m...@earthlink.net]

I think you need to slow down a bit here and work through things systematically.  I don’t see anyone, including Dale, saying there’s no problem and that everything is great.  I explained that your issue is not really in the purview of PHD2, but I haven’t said there isn’t a problem elsewhere. My interpretation of what Dale said is that he’s unaware of a problem like you’ve described and is dubious about it.  So to make any progress, you need to try using the appropriate software components for whatever you’re trying to do.  You need to do that yourself rather than just parroting something you heard on a forum.  If you run into problems, you should carefully document what you did and what happened and hopefully provide a repeatable test case that can help isolate the problem.  You should then communicate directly with whomever is responsible for the software – that would be this forum for PHD2 and presumably the NINA Discord for NINA or a NINA plug-in.   If you do all that and a problem is discovered and corrected, everyone benefits.  If there isn’t a problem but simply an operational error or a misunderstanding, then you benefit.  Either way, progress is made.

 

Bruce

--
You received this message because you are subscribed to a topic in the Google Groups "Open PHD Guiding" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/open-phd-guiding/FL6zVuscGaY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to open-phd-guidi...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/open-phd-guiding/000001dcffec%241031b4d0%2430951e70%24%40gmail.com.

[NY2KW]

One last question.  How long or how many consecutive image attempts with SNR=0 does PHD2 allow before stopping guiding?

BR,

Jerry

[Bruce Waddington]

Please take a look at the User Guide section on this subject:

https://openphdguiding.org/man-dev/Trouble_shooting.htm#Problems-_Lost_stars

Bruce

[Jerry Stern]

Bruce,

 

I did read that section earlier.  It implies that guiding should stop t some point …  “ As the elapsed time of the lost-star events grows, the mount will slowly drift off-target and a star that re-appears in the search region at a much later time is probably a different star.  In this case, PHD2 will resume guiding but the original astronomical target will no longer be centered and may not even be in the field of view.  Recovery from extended lost-star periods is the responsibility of the end-user or the imaging automation application, not PHD2”.

 

I want to confirm that is the case because the log I originally uploaded shows SNR=0 continuously for long periods and guiding was not stopped.  I’m just trying to get some clarity about this.

 

Thanks

Jerry

 

From: open-phd...@googlegroups.com <open-phd...@googlegroups.com> On Behalf Of Bruce Waddington

Sent: Thursday, June 25, 2026 9:40 PM
To: Open PHD Guiding <open-phd...@googlegroups.com>

--

You received this message because you are subscribed to the Google Groups "Open PHD Guiding" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-phd-guidi...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/open-phd-guiding/82214274-0abb-401f-994a-15fb0efd3c16n%40googlegroups.com.

[Bruce Waddington]

PHD2 will continue to take camera exposures and look for a star within the search region.  This will continue indefinitely unless the user or the session manager app tells it to either stop or auto-select another star.  PHD2 will not decide to stop on its own.  If and when a usable guide star shows up in the search region, PHD2 will start using it and resume issuing guide commands.  As pointed out in the lost-star description, this newly found star will often not be the original star because the scope and mount will have slowly drifted off-target.  I think the confusion is probably one of semantics.  During the time period in which no star is found, PHD2 is technically in a state of guiding but there are no guide commands being sent to the mount.   

Bruce

[Dale Ghent]

> On Jun 25, 2026, at 22:38, Bruce Waddington <bw_m...@earthlink.net> wrote:
>
> I think the confusion is probably one of semantics. During the time period in which no star is found, PHD2 is technically in a state of guiding but there are no guide commands being sent to the mount.

Yeah, about this....

I can't say that's at all the right thing to do. My impression of the concept of "actively guiding" means that PHD2 is in a state where it is able to competently assess drift through guide camera exposures and is sending corrections to the mount based on the information in those exposures. *Any* state where the PHD2 is unable to send corrections to the mount, for whatever root reason - low SNR, mount driver is disconnected, etc. - is quite definitely a state of "not guiding" and the API should reflect that.

Conceptually, from a client apps' perspective, PHD2 has one job: to guide and to do that to the best of its (configured) abilities. The client app should not need to know about the dirty details of SNR levels or have to micro-manage PHD2 beyond telling it when to start guiding and when to stop. If PHD2 encounters a problem in guiding, either at the outset or at some point during it (such as when clouds roll in), PHD2 should reflect this non-guiding state back to the client so that the client can react appropriately, such as suspending imaging. At that point, PHD2 should continue its best to reacquire sufficient guide stars in hopes to reestablish an actively-guiding state until it's told to stop guiding.

While this is a semantics issue, I think that puts the situation a little too lightly. NINA (or any other app controlling PHD2 through its Event API) is counting on PHD2 to Do The Right Thing in all questions related to the ins and outs of guiding. But these client apps need to know when that's able to be accomplished and when it's truly not. Can we consider changing PHD2's semantics around guiding state and status to more accurately reflect what it's doing (or not doing) at any given moment?

-Dale