How to reject a bad star profile after it was already selected?

[Linwood Ferguson]

I've got a partly cloudy night and using NINA's resume guiding trigger, I am having PHD2 restart many times tonight.

One thing that has happened repeatedly is that PHD2 loses a star, time passes, NINA restarts it but it's still partly cloudy, but thin enough it picks a star and is guiding.

Then the clouds clear, and the acceptable star, previously attenuated, is massively over-saturated, with a huge flat top. 

PHD2 clearly won't pick that star, but it appears (from watching) that it won't reject it once it is guiding.  Yet if it's too large and saturated it guides poorly, worse perhaps than not being there. 

Is there a way to tell PHD2 to reject a currently selected star if it saturates too badly? 

Yes, obviously this fixes itself if it clears, eventually the sequence will stop and restart guiding to focus or something, but that might waste a lot of subs.  Putting in frequent stop/starts just in case wastes a lot of time.

Linwood

[bw_m...@earthlink.net]

No, there’s no mechanism in PHD2 for doing this.  By design, star-finding operations are always initiated and controlled by the imaging application.  That said, I have trouble seeing why this is a high priority problem.  If you’re trying to guide through clouds, you’re also imaging through clouds which strikes me as a lot of wasted time in the first place. In any case, the imaging apps are told about the SNR and saturation state of the primary star for every guide exposure so they can do whatever they want in terms of optimization.

 

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/ca13f088-2376-43d5-bebd-5c04f383a65fn%40googlegroups.com.

[Linwood Ferguson]

Well, I didn't say it was a high priority, I just asked if there was a way to do it.  Sorry about a dumb question.

But to be fair, it's not that clouds may continue. I typically stop to focus only every 60-90 minutes or so while imaging, otherwise once it is guiding it just keeps guiding. So if it has a bad choice of star, it's going to hang with it for a long time unless the clouds do come back hard and it loses the star. 

But ... never mind.

Linwood

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/cEwDEENR5pg/unsubscribe.
To unsubscribe from this group and all its topics, 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/007701d90f64%24af3a4c80%240daee580%24%40earthlink.net.

[dpdal...@aol.com]

Rick,

Another rude answer from Bruce. I like that the guy (Linwood) says....never mind.

Bruce needs a vacation!!

Dan

https://groups.google.com/d/msgid/open-phd-guiding/CAP3twjuvcdDyMg_E%3DkgRAadZvTTNZ7_TO3G2MAFVXh8s%3DoUbtg%40mail.gmail.com

.

[Brian Valente]

Bruce may have been terse, but I would hardly call that rude. He offered relevant details and took the conversation a step back to point out that if guiding is having issues due to clouds, your imaging likely isn't going to result in much either. It's easy to lose sight of the big picture when we all want guiding to be the thing that 'fixes it'. 

We get a lot of questions regarding guiding through cloud cover, recovery during clouds etc. Bruce has pointed out many times (and here as well) that this is really for the imaging app to decide. 

He volunteers his time to personally answer thousands of questions for a free software program that he develops, enhances, and maintains.  It's rare a question goes unanswered. We all get the benefit of his time and expertise. Since you are here reading this I assume you benefit from it as well. 

Maybe what would help Bruce more than a vacation is more help from people like you to answer questions, and you could add a more positive message. 

You could be that change Dan

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/138366038.2970501.1670991683869%40mail.yahoo.com.

--

Brian 

Brian Valente

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

portfolio brianvalentephotography.com 

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

[dpdal...@aol.com]

Point taken. I will do my best.

Thank you.

Dan

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/CAJa45i6RQD7ST1_6i5ChMiGQZvH%3D%3DydJoW58D1gS6YqMy8mDeQ%40mail.gmail.com.

[Brian Valente]

Thanks Dan

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/255123678.2979668.1670993488840%40mail.yahoo.com.

[Chris Woodhouse]

The observation that Linwood has is not too dissimilar to mine - but in my case, when PHD2 finds a guidestar, it sometimes picks one that is already saturated. (I'm assuming it is PHD2 that selects the guidestar, not the capture application.)

Logically, it is within PHD2's own control, to realize the issue and pick another. It cannot be ignorant of the potential saturation, regardless of any brain setting, as PHD2 reports the peak intensity of the star (65K) on each exposure. The bizarre thing is that I'm doing multistar guiding and it could just as easily deselect it and choose another. 

I have not, as yet, looked at the source, but one potential solution would be to have the star selection logic avoid stars of say >55K peak intensity and, in the process of guiding, if a star does start getting brighter (often seen as the focus improves with temperature drift), to change horses during multistar guiding?

Hope that helps

[Linwood Ferguson]

My (over) reaction to the first comment was mostly based on the "high priority" dig.  I just didn't see that I conveyed that sense in my question.

However, I do want to elaborate on this a bit.  I can see the argument that the calling application is responsible for stopping and starting guiding to get a new star, but I do not think that's the whole case - there's the decision to make, but there is also the quality evaluation. PHD2 is in a position (with various options available for configuration) to make a quality assessment on the star, far better than the calling application can I would think.

I have a relatively low saturation threshold set (55k vs 65k) and it would never pick these bad stars, but it happily maintains them. Even that is a bit of a blunt instrument; I can get good guiding on a slightly saturated star, one with a small flat top -- but when that flat top is 14 pixels wide, not so much.  I haven't dug into the API, so maybe all the raw data is visible to the application, but I still think that a quality assessment is more in the PHD2 province than the application.

I tried to figure out how to use star mass for this, but that is both deprecated, and I think too blunt of an instrument as it's symmetric (think 75% down is really 400% up to return). 

Regardless, I appreciate all the feedback, and sorry if I managed to step into a oft repeated and annoying theme. 

Linwood

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/d0171ea1-3052-450a-88da-8eaf690f1569n%40googlegroups.com.

[David Kerber]

I actually think this is a reasonable request, for PHD to be able to shift guide stars if the one it started with becomes saturated after guiding starts. I have had this happen to me when I stay on the same target for an extended period of time: when relatively low in the east (but still high enough to get good results), the guide star isn't saturated, but as it gets higher in the sky, it becomes so. The air drying out and the transparency improving as the night goes on can cause this too.

I agree that it wouldn't be a high priority, but I would call it a nice-to-have optional setting.

Thanks!

Dave

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/d0171ea1-3052-450a-88da-8eaf690f1569n%40googlegroups.com.

[Linwood Ferguson]

Bruce, in your reply earlier you said the "saturation state of the primary star" is provided to the application. I was working with a NINA developer on this subject and neither of us can find it.  We see star mass and SNR, but it is not obvious (at least to us) how to get saturation state from that.  The image is there, we could do some kind of analysis of the image, but that seems redundant to what PHD2 has done.  If the info is in the events returned to the application, could I beg a hint where to look? 

Linwood

[Bruce Waddington]

It’s one of the “ErrorCode” values in each of the GuideStep events that are sent to PHD2 clients.  The enumeration of the ErrorCode values is here:

 

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

 

Regards,

Bruce

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/83de9d98-ed55-49b2-aa34-7f909ad2114fn%40googlegroups.com.

[Linwood Ferguson]

Thank you Bruce.  See it now.  Sadly we (well, the author involved) was going to do this as a plugin and that's not readily visible from there (NINA architectural issue).  Looking for alternatives in NINA.

I will still offer the observation that including this somewhere in PHD2 native might be widely useful.  I sat through a few hours on two different nights with high clouds.  NINA does a fine job of recovering from clouds, and stops and restarts guiding and re-centers, but often the stars are clear enough to plate solve, focus and guide but still brightening as the clouds clear.  I repeatedly ended up with a massive flat topped star which, at the time selected, was a perfect sharp peak.  I suspect this is more common than we may think with un-attended imaging.  Yes, I see how each session manager application can handle it themselves.  But I am just suggesting it might be a desirable feature for PHD2 as well, not to necessarily spontaneously pick a different star, but maybe to optionally force a 'star lost' condition on sufficient saturation.  All the session managers are likely to already recover from PHD guiding loss.   Well, maybe... I just assume so. NINA does.   Though frankly picking a different star (wth the possibility of it moving slightly) is likely more accurate than guiding on a star that's flat across most of the image.

Anyway... long winded way to say "thanks".  Found it now. 

Linwood

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/cEwDEENR5pg/unsubscribe.
To unsubscribe from this group and all its topics, 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/005401d94b25%24e79bc980%24b6d35c80%24%40earthlink.net.

[Bruce Waddington]

Ok, could you send me matching guide and debug log files for a session when this happened.  If you can identify an approximate time period when you became aware of saturation, that would make it easier for me.  You may already have the log files but if not, you can capture them the next time.  I really need to be able to look at the statistics to see what’s going on.  I can understand why it could happen occasionally but I’m not getting why it happens as often as you say.  It makes me wonder if something else is amiss.  That said, I will look at your data with an open mind.

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/CAP3twjsRyNZWdm%2B2MdSsUmz-0Eis%2BRPxsU%2BJu_ARSS_GCHQTTg%40mail.gmail.com.

[Linwood Ferguson]

So maybe I found one.  My memory is poor when wide awake, but even worse remembering half asleep periods at night.

Let me first say this: This does not happen often in an absolute sense because I do not image often when it is cloudy, I just keep the telescope inside. But there are nights predicted to be clear where clouds move in.  In THOSE cases this can be frequent. The issue is that it is "sticky".  If it happens, and if your sequence is one that rarely stops and starts guiding, then once guiding stars on a rising star signal there is (currently) no process to fix it.  It just gets worse and stays. 

I agree that (as an example) NINA could fix it. For architectural reasons this is not going well as a plugin. That is not your problem, and I appreciate the pointer. But I still offer the observation that when this happens, it is a problem for all session managers in a similar fashion, and it MIGHT be better if PHD2 were the one to address it since it has all the information. Anyway... end of lobbying rant.... 

I have uploaded a log from one night (with debug) here: https://drive.google.com/file/d/1JhKhbevQTcnlTfYvTFgSDmJOhS_h5Cqh/view?usp=share_link

Unfortunately lacking images it is a bit hard to recall what happened, and I do not see that PHD2 log viewer will show peak, but it does show SNR and Mass so using that as a proxy.... 

Early in the evening it was going well, but clouds moved in (guessing from the logs) around 9:51pm. 

At 21:57 you can see guiding restarted with low SNR and mass, but by around 21:59 and even more by 22:02 the star mass had dramatically grown, and you can see guiding went to crap.  I THINK that was a period where the star went saturated. 

I restarted at 22:06 and clouds moved back in killing off guiding by the end of that period. 

The next, starting at 22:41 is more difficult to interpret, and I think clouds were crossing continually when guiding went nuts there. 

There's another case at 23:56 where it started low and went way high, maybe saturated, though in this case guiding did not go bad until clouds came back in a few minutes later.  So it's a sign of increasing signal, if not a case where it mattered since they came back. 

By around 00:42 the clouds were mostly gone. 

Thank you for any insights. 

Linwood

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/003801d94be5%24b8fa84c0%242aef8e40%24%40earthlink.net.