PHD2 Still Guiding When Cloudy

[Rick Boudah]

As can be seen in the screen shot , PHD2 is still continuing to guide when the clouds roll in. PHD2 is still calculating a peak and as you can see issuing huge guide pulses that push the mount way off the target. Just before the clouds the SNR was above 200 and it's below 20 with the clouds. Why isn't guiding disabled during these conditions. 

 

I'm using NINA and sometimes it can recover the initial target after the clouds have passed, but not always.

 

The mount is an Avalon M-Uno which the manufacture recommends Lowpass2 and faster updates. 

 

I've looked all through the brain configuration settings and can't find any way to stop this behavior.

I've lost track of the log file for this event but what would explain all of the guide pulses, and the software still thinking it has a star.

[bw_m...@earthlink.net]

We would need to see the log files to give you a full explanation.  If you use the recommended tools for uploading logs, it isn’t a problem to find the correct log files: https://openphdguiding.org/getting-help/

 

That said, I notice you haven’t bothered to use either a dark library or a bad-pix map so PHD2 is vulnerable to trying to guide on sensor noise, especially when there are really no stars available.  The behavior you’ve shown in the screenshot is consistent with trying to guide on a hot pixel or a clump of warm pixels.  I think NINA is quite capable of doing all-sky plate solves to recover from extended periods without guiding, so perhaps you haven’t configured that correctly.

 

Bruce

--
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 on the web visit https://groups.google.com/d/msgid/open-phd-guiding/95b6dec6-38b6-4ca9-b5b6-074e13fbee36n%40googlegroups.com.

[Rick Boudah]

Yes it's possible there was no dark library. I have since made one and will try again. Is there a settable lower threshold where no guiding will take place. As you can see in my screenshot the SNR was 18.5 and the false peak at 2228 counts. When it was guiding the peak was 50 to 60K and the SNR over 100. Here are the logs. The screenshot was from 7/27 at 1:55.

[Steve Winston]

It appears that guiding initially stopped at 1:51 am with the initial star loss event.  But it immediately started again, and I assume because it was cloudy, was never able to lock onto a star.

Did you manually re-start guiding at 1:51?  Or is Nina telling PHD2 to re-start guiding each time the star loss is reported?   It seems to me that once the star was lost, Nina (or whatever controlling s/w is being used) should go into some recovery mode, and at some point, give up trying to re-start guiding if no guide star can be found.

[Rick Boudah]

I don't think either I or NINA restarted the guiding. I'm just trying to get PHD2 to stop trying to guide on the noise either from the cloud or hot pixels. It looks like it's generating a stream of large guide pulses that send the mount running away. I have a Nina "center on drift" function but it needs a successful plate solve to re-center the target. The mount was once driven so far the scope was facing the ground. Hard to do a plate solve in that case. I've asked NINA folks if the actual mount position can be checked and if it goes to far off target to - stop guiding - slew to the target - restart guiding. 

I guess my main question is why is PHD2 generating any output with such low SNR and pixel values. It was previously operating with an SNR above 100 and star peaks of 50-60K counts. I would just like a simple threshold setting that no output pulses would occur below an certain SNR  value. 

Am I missing something that is key to PHD2's logic.

[bw_m...@earthlink.net]

Well, you’ve sent the wrong debug log file, it doesn’t match the guide log.  Let me say this one more time: to upload the correct log files, please follow the instructions here: https://openphdguiding.org/getting-help/

 

Pay attention to the dates and times of the logs – you want the ones that cover the period from 22:30 on July 26 to 01:51 on July 27.

 

Bruce

 

From: open-phd...@googlegroups.com <open-phd...@googlegroups.com> On Behalf Of Rick Boudah
Sent: Thursday, August 4, 2022 10:39 AM
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 on the web visit https://groups.google.com/d/msgid/open-phd-guiding/5ec1c6a4-dc59-490f-83ca-057d87387029n%40googlegroups.com.

[Rick Boudah]

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

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/005301d8a845%249fbe7aa0%24df3b6fe0%24%40earthlink.net.

[Bruce Waddington]

Ok, I think we can reconstruct what happened.  You were using no dark library or bad-pixel map and you had specified a saturation level of 255 ADU even though the guide camera is 16-bit and actually saturates at 65K+.  So you were discouraging PHD2 from using brighter stars while providing no help in avoiding hot pixels and other sensor noise.  Starting at about 01:50, your imaging app got nearly 30 advisory notifications of lost stars but at 01:51, it told PHD2 to stop and then restart guiding.  At this point, a clump of sensor noise was mistaken as a guide star because of the other problems and things went downhill from there.  The first thing to do is straighten out your parameters to help avoid this sort of problem and always run with at least a dark library.  Second, if you want to take more control over the range of stars you're willing to use, you can specify the minimum SNR that will be accepted for auto-find - that's on the Guiding tab of Advanced Settings.  You can also choose to use 'auto' exposure times and specify a minimum SNR there (Camera tab of Advanced Settings).  Be aware that PHD2 is quite capable of using stars with SNR values below 20 but if you are convinced those are too low for your setup you can choose a higher value.  When you do that, you have the potential risk of failing to find any suitable guide stars after a meridian flip or whenever guiding is restarted during the course of the night. 

Regards,

Bruce

[Brian Valente]

>>> Starting at about 01:50, your imaging app got nearly 30 advisory notifications of lost stars but at 01:51, it told PHD2 to stop and then restart guiding.  

at the risk of repeating possibly the obvious, i want to point out PHD does not determine what happens when there is a lost star event. The imaging app makes those decisions, so in this case it sounds like NINA did in fact instruct PHD to restart

Brian

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/2497e225-5f94-4f8f-a9ed-1c05e98ba540n%40googlegroups.com.

--

Brian 

Brian Valente

astro portfolio https://www.brianvalentephotography.com/astrophotography/

portfolio brianvalentephotography.com 

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

[Rick Boudah]

Yes I did notice the 8 bit issue and did change that already. Not sure how that got switched. I just remade my bad pixel map and will try again tonight with a higher minimum SNR and HFR setting. 

If NINA does request a restart and the SNR is not satisfied then guiding will not start.  How often does NINA make a new request. 

All these different software packages we use it's sometimes not clear who is doing what when things go wrong. Does PHD2 have a server log window to see messages going back and forth.

I wonder how I could simulate clouds to see the NINA + PHD2 reaction.

Thanks for the help. 

[bw_m...@earthlink.net]

There’s no “window” to show server traffic, the volume is typically too high for that to do you much good.  If you open a PHD2 debug log file, you can do a text-search on ‘evsrv’ and see the traffic.  It’s pretty self-explanatory but you can study the interface documentation on the Wiki server:

 

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

 

All of this is driven by the imaging app so it would probably make more sense to ask on that forum.

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/2745e179-2814-4f83-a869-334c5bcd8c2cn%40googlegroups.com.

[Rick Boudah]

Just to revisit this issue of PHD2 issuing large corrections when clouds roll in.

 The program still continues to find what it thinks is a star in what I can obviously see is noise.  There is no star displayed but the software is finding enough of a peak somewhere in the noise and as a result is issuing max corrections and driving the mount way off target. 

I've made a new BPM and dark library but still it appears the program is fooled by the random data the clouds seem to produce. 

How does the software detect the loss of a star and whether clouds are present.

Is there a floor that is continually calculated which pixels have to be above to be considered as a star. 

Can a limit be put in on the quantity of max corrections that can be issued over a period of time. I've now lowered the max pulse value to just larger than values I normally see during guiding.

Luckily when the clouds pass NINA can usually correct for the drift that PHD2 has caused.  

Rick