Auto select and dim stars

[Scott Badger]

I like to use auto-select to get multi-star guiding, but PHD2 often choses very dim stars, sometimes stars that don't even show on my screen. And even if the chosen star works to start, it's much more easily lost if some thin clouds pass through. Is there a way to have PHD2 choose brighter (but still not saturated) stars?

Thanks,

Scott

[Brian Valente]

Hi Scott

If you have examples of this in prior guidelogs, please upload them (using the built in log uploader utility)

In general you can increase the SNR for auto-find guidestars in the advanced settings dialog box (i.e., the brain tab)

Brian

--
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/634a7090-06aa-4f29-90e2-4a2d4f1e0bb5n%40googlegroups.com.

--

Brian 

Brian Valente

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

portfolio brianvalentephotography.com 

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

[bw_m...@earthlink.net]

You’re probably barking up the wrong tree here.  Auto-find always uses the brightest/best stars that are available.  If those happen to be dim, so be it.  The stuff you see on your display that looks better usually isn’t.  This assumes you have reasonable settings for saturation levels and Min-HFD values.  Depending on your setup, you may have to face the fact that some fields don’t have a great selection of suitable guide stars.

 

Bruce

--

[Scott Badger]

Thanks Brian, I'll try that! I had heard that you couldn't change the parameters of the auto-select function, but glad I checked here anyhow. And next time it comes up, I'll make a note of it so I can locate the event in the guide log.

Cheers,
Scott

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/wYadc5GCpmU/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/CAJa45i4595wLMCLtnZ4SjTy4bNDS2K6sxX-%2B54MoLG4x%3D7KDbg%40mail.gmail.com.

[Scott Badger]

Hi Bruce,

When it happens, there is almost always a brighter/higher SNR, but not saturated, star to choose. Maybe there are other parameters I'm not taking into account?.... But even if the dim star is, overall, the better star to use at the moment, where I live and image from there is always the chance of passing clouds and the brighter stars won't be lost as easily. Next time this comes up, I'll do a better job of documenting and will also provide the logs.

Cheers,
Scott

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/wYadc5GCpmU/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/004601d8cebe%2484a36b00%248dea4100%24%40earthlink.net.

[bw_m...@earthlink.net]

There are a bunch of other factors involved in auto-selection and I haven’t yet seen a case where auto-find made the wrong choices given those factors.  Send us a debug log file and we’ll tell you what’s wrong.  If you increase the minimum-SNR for auto-find, all you’re likely to accomplish is to trigger no-star-found failures rather than using available dim stars.

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

[Dana Tousley]

Been happening to me also.  Multiple times over the last few months.  Running from SGP and it auto selects a star with a peak value of 15 out of 255 when there's one nearby that's 150.  Can't even get through calibration without losing the star.

I try again on the same field and then it works.

[Bruce Waddington]

You need to send BOTH log files using this mechanism:

https://openphdguiding.org/getting-help/

Bruce

[Dana Tousley]

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

Sorry, but the acquisition laptop doesn't have all the fancy stuff like email and Google groups.  I barely give it internet access.  Some of the 'no guiding' logs could be because the laptop is having temperature issues and hangs when it's cold - currently shopping for a new laptop :(

Dim star selection has been a relatively common experience lately.  I'm using a WO Star 71 / QHY 183M with a QHY OAG / QHY 5LIIM.  I generally have a fair number of stars to choose from (lately been imaging in Cygnus).  It's only been the past few months that it's happened.  I've been using this combo with PHD2 for years.

[bw_m...@earthlink.net]

Thanks for sending the logs.  This is going to take some time to analyze and I want to do a good job of it.  So I may not get to it today (activities of daily life) but I will definitely get it done.

 

Bruce

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/e3c93c32-a735-49c0-81b4-c3b719e808d1n%40googlegroups.com.

[Bruce Waddington]

Hi Dana.  Attached is a detailed analysis of the auto-find results from your log of 9/22.  For each of the 10 auto-finds, I have summarized the outcome of the search and the reasons that one star was chosen as the primary and others were rejected.  Here's an overview of what I see from all this:

1.  There is a peculiar and substantial variation of quality between guide frames.  One frame used for auto-find may show nothing but dim, fuzzy areas while a subsequent frame shows a good star-field.  This is not something that PHD2 is doing, it is simply a reflection of the data being obtained from the camera.

2.  In several cases, the brightest objects in the field - the ones most obvious on the display - had saturated brightness values.  Because you're using an 8-bit camera. brightness values fall between 0 and 255 and the bottom of that range is "used up" by sky brightness and camera noise. 

3.  Most of your lost-star events occurred during calibration perhaps as a consequence of where the scope was pointing.  Why are you doing so many calibrations?  You got a good calibration early in the evening, you're using an ASCOM mount connection, why didn't you just keep using it?  Doing all these calibrations is just a waste of time.

4. You're only using 1-second guide camera exposures which can produce overly dim stars depending on the conditions.  You may need to increase this.  Since you're using SGP, you can use "auto" exposure times.  Just set the minimum and maximum exposure times you want in the Advanced Settings dialog along with the minimum SNR you want.  Auto-find will get the benefit of using the longest exposure time to find stars but then guiding will end up using the shortest exposure times that are sufficient to achieve your target SNR.

5. If you increase the minimum SNR for auto-find (Advanced Settings/Guiding tab), you can force PHD2 to use saturated stars - auto-find will do that before throwing up its hands and returning a no-star-found result.  But taking this approach will bite you if there are no bright stars in the field.  Guiding can work perfectly well with dim stars, but if you exclude them with a high SNR floor, you may find no stars at all.  Conversely, using saturated stars is likely to degrade your results.

I don't see anything wrong with how auto-find performed with your data after spending a couple of hours looking at it.  If you aren't convinced, you can use the 'Diagnostic image logging' features in PHD2, located on the Global tab of Advanced Settings.  There is an option there to save every image used for auto-find.  You can examine these images yourself and see what the field looks like - this may be a good way to trouble-shoot the big brightness variations you're sometimes getting.  You can also do the same analysis I did by opening the debug log file in a text editor and searching for "autofind called".  Following that log entry you will find a detailed account of every "something" that was located on the sensor, whether the 'something" proved to be a star, what its brightness and size properties were, where it was located on the sensor, whether or not it was too close to another recognizable star or the edge of the field, etc, etc, etc...

Good luck,

Bruce

[Chris Woodhouse]

I'm having a related but different problem. I am running the latest and using multistar guiding. I have recently had multiple instances where the auto-selected principal guidestar is saturated with a flat top. Changing the saturated parameters in the brain has no apparent effect. 

[bw_m...@earthlink.net]

PHD2 will choose a saturated star if there are no other alternatives.  The idea is that doing so is preferable to returning no-star-found and not guiding at all.  Since you’re following this thread, you can see how to analyze the auto-find results yourself.

 

Good luck,

Bruce

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/205330e6-760b-4979-9cd0-f46b39073500n%40googlegroups.com.

[Chris Woodhouse]

Hello Bruce - in this case I do not believe this is the case. I am using a quality guidescope and the multistar guiding is picking up on many stars, so the algorithm is not spoilt for choice. The target SNR is at the default value, so it is not trying to 'reach for the stars' either:)

During the experimentation, I also noted another behavior that is a bug of some kind on the peak value for saturation. I have a QHY178 guider and if I connect to it with the ASCOM driver, while it can produce star profiles with a peak of 65K, it is impossible to change the saturation detection value in the brain from 255. I can type in 65K and it just defaults back to 255. If I connect to the QHY with PHD2's own driver, I can set the 65K saturation setting. I shut PHD2 down and restarted and the behavior was reproducible.  Not sure if QHY is mis-reporting its bit depth or if PHD2 is confused. There is no obvious bit depth setting on the QHY ASCOM driver settings window.

[bw_m...@earthlink.net]

See below.

 

From: 'Chris Woodhouse' via Open PHD Guiding <open-phd...@googlegroups.com>
Sent: Saturday, October 1, 2022 3:30 AM
To: Open PHD Guiding <open-phd...@googlegroups.com>
Subject: Re: [open-phd-guiding] Auto select and dim stars

 

Hello Bruce - in this case I do not believe this is the case. I am using a quality guidescope and the multistar guiding is picking up on many stars, so the algorithm is not spoilt for choice. The target SNR is at the default value, so it is not trying to 'reach for the stars' either:)

 

I don’t know what to tell you.  You haven’t presented any evidence for this, you apparently haven’t looked in the log files yourself using the procedure I outlined, and you haven’t sent log files to me with an identification of the time period you’re unhappy about.  I have analyzed dozens of these things in past months and haven’t yet found a situation where the algorithm didn’t do what it was supposed to do.  I can’t do anything with “perceptions” about what is going on.

 

During the experimentation, I also noted another behavior that is a bug of some kind on the peak value for saturation. I have a QHY178 guider and if I connect to it with the ASCOM driver, while it can produce star profiles with a peak of 65K, it is impossible to change the saturation detection value in the brain from 255. I can type in 65K and it just defaults back to 255. If I connect to the QHY with PHD2's own driver, I can set the 65K saturation setting. I shut PHD2 down and restarted and the behavior was reproducible.  Not sure if QHY is mis-reporting its bit depth or if PHD2 is confused. There is no obvious bit depth setting on the QHY ASCOM driver settings window.

PHD2 does this when the driver reports the bit-depth is 8-bit.  This is probably a bug in the QHY ASCOM driver but same answer as always, you need to provide log files.

https://openphdguiding.org/getting-help/

 

Bruce

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/09eb9684-0f44-405b-9f43-f93cfa5cfa60n%40googlegroups.com.

[Chris Woodhouse]

Hello Bruce - evidence?.... well I'm certainly not making it up. My eyes were not deceiving me. :)

The debug log reported the ASCOM driver as 8-bits, but then went on to download images that were 16-bit. More than likely a QHY driver issue.

It seems to be one of those things - just booted up tonight and it has allowed me to enter 65K for the saturation value for the same QHY ASCOM driver and camera. These are the log files from when it was playing up.

I will monitor guiding tonight and copy the guidelogs here if it continues to find multiple stars to guide with, but chooses a saturated one to be the main one. I have used PHD and PHD2 since their birth and I have not noticed this before, so it could be just one of those random behaviors that occur and a cold reboot fixes.

kind regards

Chris Woodhouse FRAS

[Chris Woodhouse]

[Chris Woodhouse]

I'm guessing in the star selection algorithm that it should not choose a star that is saturated. If that initial exposure is just below, subsequent exposures may then saturate. I wonder (if it is already not a feature) that the peak value of the principal guide star should not be more than say 80% of the saturated value?

[Scott Badger]

As I've mentioned before, even when PHD2 chooses the optimal star, there are times when I may actually want a brighter, even somewhat saturated, star instead. Typically, between the start of the night and a couple wake-ups to check on things, I'm monitoring the scope about 2 hours of the 9 I can image right now, and where I live, no matter how clear the skies, clouds are always a possibility. When passing clouds occur, a brighter star can minimize the star lost time and keep the mount centered where an 'optimal' star may not. So......why not allow manual star selection and multi-star guiding?

Cheers,
Scott

[Jason Schella]

If you use N.I.N.A., it has a "center after drift" function that will automatically restart guiding and imaging after clouds.  It detects the drift,  recenters the image,  restarts guiding, and starts imaging again. 

Jason

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/7829aa49-5989-4eba-887d-c6996263fb36n%40googlegroups.com.

[Scott Badger]

Thanks Jason! I do use NINA and will check that setting, though I thought I had it enabled and still occasionally end up off center. or lose the target altogether. But I also have an issue between my mount (CEM70) and NINA where sometimes if things go awry and I platesolve to re-center, it misses by a few arcminutes. I then re-slew to the object and platesolve again without a problem. Anyhow, it's as if the drift somehow results in the target coordinates being altered.

[Jason Schella]

Hey Scott,

There is also a setting in NINA that lets you specify the tolerance for the plate solve.  I think the default is quite large and may account for the few arcmin difference (and it may be the setting is in pixels).  Mine in set to < 30".  I have a CEM120 (non-EC) and this setting works great for me.

Jason

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/29cd1629-e392-461e-9770-cff1e61e1171n%40googlegroups.com.