Why Does My Multi-Star Guiding Turn Off?

[Pict...@earthlink.net]

I have posted about this before, but since then, new and improved versions of PHD2 have been released.  I am currently using 2.6.9 dev 4.  I have watched the following behavior enough to be convinced that it is not a fluke.

First, let me set the context.  

1) I am invoking PHD2 via PHD Broker calls.

2) I have Multi-Star selected in Advanced Settings.

3) Because of 1) I never select the guide star, nor do I invoke Auto-Select.  The guiding is invoked by the PHD Broker.

4) I am using an SX-AOLF device

5) Because of 4) I have the guider exposure time set to Auto.

What I see is that as soon as guiding is begun, a primary star is selected and multiple secondary stars are selected.  There may be as many as 8 secondary stars selected, but regardless, the guiding immediately thereafter reverts to a single [primary] star.  Always.

Hopefully the information below will provide clues why this is happening.

The debug log entry says, "GuiderMultiStar::AutoSelect enter".  It also gives the list of MultiStar selections.  After exiting the stabilization period and updating star positions after the lock position change, the log reports an error: "coordinates are invalid".  Then, one by one the MultiStars are removed each time reporting the following:

"Error thrown from C:\cygwin\home\agalasso\projects\phd2\star.cpp:173->coordinates are invalid

Star:Find returns 0(7), X=xxx,.00,Y=yyy.00 ,Mass=0, SNR=0.0, Peak=ppp, HFD=0.0

MultiStar:#1 removed after lock position change"

where the repeat characters above (xxx, yyy, & ppp) vary, but everything else is fixed.

This sequence then ends with:

"MultiStar: no secondary stars found after lock position change"

There are also a series of error messages of the form:

"Error thrown from C:\cygwin\home\agalasso\projects\phd2\guider_multistar.cpp:979 ->UpdateCurrentPosition():newStar not found"

Similar to the above "CheckDistance" errors are also interspersed.

When I go to a new target the whole sequence above repeats.

I would really like to use MultiStar guiding, but the above happens without exception.  It happens regardless of target.  It happens immediately after the first image showing both the primary star (square indicator) and secondary stars (circular indicators).

So, my questions are:

A) Am I missing a setting somewhere or a checkbox?

B) What am I doing (or not doing) to cause the invalid coordinate and other errors?

 How can I enable MultiStar guiding to work in my system?

Thanks for any help you can provide.

Manning B

[Pict...@earthlink.net]

I posted this a couple of days ago and haven't seen any reply, so I'll ask a couple of additional questions.

Andy Galasso, your name is in some of the error messages I posted in the original message so I presume you can answer questions about them.  Specifically, what is it that leads to "invalid coordinates"?  This seems to be occurring internally to PHD2's actions.  So, how does that condition arise?  This is in the context of multi-star guiding because it is followed immediately by "MultiStar:#1 removed after lock position change".  When the MultiStar selections are originally listed, coordinates are given for them and they do not appear to be unusual in any respect yet we have this error message that the coordinates are invalid.

Also, in the entry --

"Star:Find returns 0(7), X=xxx,.00,Y=yyy.00 ,Mass=0, SNR=0.0, Peak=ppp, HFD=0.0"

how can the Mass, SNR, and HFD all be exactly zero (0)?  That appears suspicious to me because even the background is going to have some signal.

Thank you in advance for your reply.

Manning B

[Brian Valente]

Hi Manning

i can't answer all your questions, but regarding this part:

>>>What I see is that as soon as guiding is begun, a primary star is selected and multiple secondary stars are selected.  There may be as many as 8 secondary stars selected, but regardless, the guiding immediately thereafter reverts to a single [primary] star.  

Multi-star doesn't quite work that way. it always starts guiding with a single star. the "multiple secondary stars selected" does not start guiding on them. I do not know exactly what this means, but i suspect it may identify candidate second stars. I think PHD evaluates the secondary stars and adds them as they pass muster. they are also removed if they no longer qualify

the information bar at the bottom will tell you the number of stars it's currently using to guide and the total possible stars for multi-star

i hope that helps some

--
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/71e89cd7-2891-4035-8250-27143674f291n%40googlegroups.com.

--

Brian 

Brian Valente

portfolio brianvalentephotography.com 

[Bruce Waddington]

I think the reason neither Andy nor I have responded is that you didn’t provide the necessary log data.  You have posted questions dozens of times on the forum so I’m surprised you didn’t understand that.  We’re not going to explain all the entries that appear in the debug log file but if you submit the correct data and identify a specific event that concerns you, we will explain what happened.

 

Bruce

--

[Pict...@earthlink.net]

Thank you, Bruce, for your reply.  Of course,  you may have the log data.  I did think you might want to request the log data, but I waited to hear what, if anything, you  specifically  wanted because I thought perhaps it would save you work if I provided background information and pointed to specific entries in the log that could allow you to address those specific issues versus sending you log files and asking, "What went wrong?"  In other words, I thought I was being helpful, but it appears not.

 Perhaps it is a matter of perspective.  In any case, I identified the events of concern in my original post.  I look forward to your explanations of what happened.  

 I have uploaded the Debug and Guide Logs.  Here is the  link.  

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

I don't know if you also want the PHD Broker Log,  or any other logs.  Please advise if you do.

 Thank you,

Manning B

[Bruce Waddington]

Hi Manning.  You’re using sub-frames on your camera exposures with a size of 35x35 pixels.  The auto-select algorithm uses the full frame to locate the stars, but the sub-frame rectangle is always relative to the primary guide star.  There’s no choice about that, the camera will only return a single, rectangular region of interest.  So all the secondary stars will be “lost” because they don’t reside in that region.  If you want to use multiple stars for guiding, you will have to discontinue use of sub-frames.

 

Regards,

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/45b67edc-d41b-42d8-8aa0-be46ee411865n%40googlegroups.com.

[Pict...@earthlink.net]

Bruce, thank you for your reply.  It may be worthwhile to include in the Help documentation the interplay between sub-frames and multi-star guiding.  A search of the current PHD2 Help documentation only turns up this:

"Just remember that an overly large search region also increases the likelihood that multiple stars will live within its boundaries, which could lead to guiding problems. [emphasis added]"  I think this text probably probably predates the addition of multi-star guiding.  

A search of posts to the PHD2 forum also did not turn up any references to attempts to use both multi-star guiding and subframes.

It may be obvious to everyone else that subframes may cause multi-star guiding to fail, but it was not obvious to me.  This is an example of why I try to understand the logic of how the program works and why I ask questions such as I included in my original post.  You did not comment on those questions, but I  infer from your latest reply that the program logic requires that the coordinates of any [secondary] stars outside of the subframe are "invalid" and that the program logic also sets the SNR, Mass, and HFD to zero (0).  Maybe if I had dug deeper into the Debug Log I could have found that subframes were the problem, but I just did not understand how the coordinates could be "invalid".

I don't know how you keep up with answering all the questions posted on the forum; it seems to me like it would be a full-time job.  Thus, I prefer not to bother the program authors if I can figure out something by myself so I try to go as far as I can in finding the answers and then ask for help if I get stuck.  

I will try not using subframes and see how it goes.

Thanks again,

Manning B

[Bruce Waddington]

Hi Manning.  Yes, the documentation should make this point explicit.  In the initial implementation of multi-star, I automatically disabled the feature if sub-frames were used.  But disabling the option confused a lot of people so I removed that.  I hoped that the interaction with sub-frames would be somewhat obvious but I guess it’s not.  With sub-frames enabled, the real-time display is showing only a very small rectangle somewhere in the image display window – so any stars that don’t lie within that rectangle are never seen by PHD2. 

 

The debug log file is a developer tool so it may contain all sorts of things that only make sense if you’re familiar with the code.  You were looking at a number of internal exception messages that are useful to us but not to the casual reader.  That’s why we don’t push users toward looking at the debug log file in most cases.  I understand your desire to be independent but you will be significantly constrained in understanding things at the debug log level unless you are familiar with the code.  We *always* want to see log files when people have questions.  If it turns out that we don’t need the log data, it doesn’t matter, it’s no-harm-no-foul.  That’s why we implemented the upload and log storage facility on our web site.  In general, I think it’s best if you pose the question – at a user and operational level -  along with the log files and let us do the analysis first. 

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/8d6b392f-d5f4-405c-8430-b14fe994890dn%40googlegroups.com.

[Pict...@earthlink.net]

Hi Bruce,

I used multi-star guiding last night with Subframes turned off.  Indeed, multi-star guiding continued to be operational.  That was good news, and from my very limited experience with it, multi-star guiding seemed to significantly mitigate seeing effects.  That was very good news.  I think last night was probably, in fact, the first time I have actually been able to use multi-star guiding.

I did discover one additional aspect of multi-star guiding I had not foreseen.  And, I have a question about it.

Since I use an AO device, I set the guider exposure to "Auto".  One particular target last night revealed a consequence of using Auto that is, I think, important to note.  My range of Auto exposures is 0.2 seconds to 4.0 seconds.  I have found that for single star guiding (all I have been able to use until last night) that range worked well for me.  One of my targets last night had a brighter star which PHD2 auto-selected.  The SNR was about 130.  Multi-star guiding began with several secondary stars.  With the exposure set to Auto, the guider begins with a longer exposure and then progressively reduces the exposure until either the minimum exposure or minimum SNR is reached.  Sometimes a "Star Lost" event will occur with the shorter exposure.  When that happens, the exposure will be reset to a longer value, the guide star will be reacquired, and guiding will resume.

What I observed last night is that as the exposure duration is reduced because it is set to Auto, secondary guide stars are lost.  I presume some threshold is reached of SNR, HFD,  or something else and the secondary star no longer meets the criteria for selection and it is dropped.  What I did not realize would happen is that unlike primary guide stars which are reacquired when the exposure duration is increased because that is how Auto works, it appears secondary stars are not reacquired.  It appears that once they are removed, they are permanently removed and will only be "reacquired" if guiding is actually stopped and restarted.  

Is my understanding correct?

I found that if I stopped guiding, restarted looping, and re-auto-selected the guide star, then the secondary guide stars would be reacquired.  I also found that if I changed the guider exposure duration from Auto to a fixed value, then the secondary guide stars would not be removed.

Does my interpretation seem correct?

If so, then I am not sure that Auto exposure can be practicably be used with Multi-Star guiding.

So, finally, if my inferences are correct, is it a deliberate design decision not to "reacquire" secondary guide stars?  What happens if even with a fixed exposure value the primary guide star is "lost" or if the secondary guide stars are "lost"?  Will the secondary guide stars be [irretrievably] "lost" as well?  Could secondary stars be "reacquired" also, or would that be a bad design choice?  

If I have misunderstood how multi-star guiding works in the situation I have tried to describe, please explain so that I can better understand how to use it.  Hopefully the scenarios I have tried to describe are not confusing.  It does seem like multi-star guiding can be very helpful.

Thank you,

Manning B

[Bruce Waddington]

Here are some short answers so I don’t have to get into the innards of the algorithm

 

1.       Secondary stars are populated only as a result of an Auto-select, and they are subject to the same qualification conditions as the primary star – SNR, min-HFD, etc.  Auto-select  is a fairly expensive action with some side-effects so it isn’t done automatically unless you have manually changed the multi-star option from false to true while guiding is active.

2.       Secondary stars can be dropped for many reasons, including low-SNR.  In most cases, their removal occurs only after multiple consecutive failures to meet the qualification conditions.

3.       Auto exposure is still useful but you have to use a more sensible minimum exposure time.  Even with an AO, sub-second exposure times are more likely to chase seeing than to mitigate it.  If you set a lower boundary of 1 second, you will probably see fewer dropped secondary stars.  You have to make your own trade-offs between having multiple stars and letting the mount go too long between guide corrections.

4.       Loss of the primary star is handled the same as always.  The list of guide stars is sorted by SNR and the primary star is nearly always the “best” star. 

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/7097cd90-3dd6-4856-a8b6-2b411e1de6b6n%40googlegroups.com.

[Pict...@earthlink.net]

Thanks for replying, Bruce, with explanations of how multi-star works.  Subsequent to my post I did find that a "star lost" of the primary star did not imply the secondary star would be removed.  That was surprising, but reassuring.  When the primary star was "lost" and then reacquired, so was the secondary star.

I am inclined to agree with you about  a compromise on Auto exposure and Multi-Star guiding.  If I am imaging in a star rich region, there can be lots of secondary stars and it is advantageous to use as many as possible.  At a F.L. of ~2000 mm and using an ONAG and Lodestar X2 there are other times when I am lucky to find a single guide star.  In fact, it is not uncommon for me to have to use the movable ONAG stage to move the Lodestar around to find a guide star.  In those cases it *may* be helpful for me to use as short a guide exposure as possible.  In my locale, sometimes the seeing is manifest primarily by movement of the guide star; sometimes by distortion of the guide star; and in the worst case by both in which case imaging is nearly futile.

Thanks again,

Manning B