a few things about multi-star guiding

[Wei-Hao Wang]

Hi,

I absolutely like the multi-star guiding implemented in PHD2 in recent years.

It greatly reduces the chance for my mount to chase after occasional 

seeing spikes and improves the overall stability.  Here are a few situations

that I encountered or observed when I used the multi-star guide function.

They can be issues, or not at all.  I just throw them out here.

First, I feel there is room to increase the number of stars used for multi-star

guide.  By eye, I often see that there are many more suitable guide stars in

the image that are not picked by PHD2 for guiding.  I kind of wonder if 

allowing PHD2 to greatly increase the number of stars (when the guide image

actually allows) would help to further improve guiding.

Second, I often saw that PHD2 picks a main guide star (the box with 

cross-hair) that's very close to the image edge. Some times kind of too

close.  A large dither offset may move that star out of the FoV.  I am not

sure if this is a problem.  Maybe it's not.

Lastly, recently I encountered a funny situation.  Please see the attached

image.  You can see that PHD2 picks the diffraction spots of the bright

star as guide star.  In some sense, those diffraction spots should also 

move together with any tracking error, and therefore they can serve as 

guide stars.  From this point of view, picking those spots as guide stars

can still work.  On the other hand, those spots should respond to seeing

in a very synchronized way, i.e., they move together with the bright star.

So picking them as guide stars only improves the S/N, but does not 

have the advantage of averaging out seeing.  This must be a rare problem,

if it is a problem at all.  I am not sure if it can be solved, or if it is worthwhile

to put any effort into solving it.  Just provide this for your reference.

Thank you for the great work on continuously improving PHD2.

Cheers,

Wei-Hao

[Bruce Waddington]

Hi Wei-Hao, I’m glad the multi-star feature is working well for you.  I’ve responded to your questions below:

 

From: open-phd...@googlegroups.com [mailto:open-phd...@googlegroups.com] On Behalf Of Wei-Hao Wang
Sent: Tuesday, March 15, 2022 8:57 AM
To: Open PHD Guiding <open-phd...@googlegroups.com>
Subject: [open-phd-guiding] a few things about multi-star guiding

 

Hi,

 

I absolutely like the multi-star guiding implemented in PHD2 in recent years.

It greatly reduces the chance for my mount to chase after occasional 

seeing spikes and improves the overall stability.  Here are a few situations

that I encountered or observed when I used the multi-star guide function.

They can be issues, or not at all.  I just throw them out here.

 

First, I feel there is room to increase the number of stars used for multi-star

guide.  By eye, I often see that there are many more suitable guide stars in

the image that are not picked by PHD2 for guiding.  I kind of wonder if 

allowing PHD2 to greatly increase the number of stars (when the guide image

actually allows) would help to further improve guiding.

 

There is a cost/benefit aspect to this, something that had to be taken into account in the implementation.  There is a fixed CPU cost to finding stars in the image – it is strictly linear and there’s no opportunity for any economy of scale.  We have many users who run their imaging sessions with minimalist computing resources which is entirely reasonable and something we have to keep in mind.  Next, there is a diminishing return accrued by adding secondary stars.  The measurement error of each star is inversely proportional to its SNR and for that reason, the candidate list of guide stars is sorted in descending order by SNR.  For the same reason, the measurement contribution from each star is weighted by its SNR.  So we are always choosing the highest SNR stars in the list, the ones most likely to make a significant contribution.  As you add stars from the candidate list, you are usually getting increasingly dim stars whose contribution to the final result will diminish accordingly.  In the early alpha testing that we did, there was no cap on the number of stars used and users with wide-field setups would often have 50-60 secondary stars.  Analysis of the results showed there was essentially no benefit to using such long lists and, of course, there was a linear performance penalty.  The current cap on the number of stars is simply a judgment of where the costs are likely to outweigh the benefits.

 

Second, I often saw that PHD2 picks a main guide star (the box with 

cross-hair) that's very close to the image edge. Some times kind of too

close.  A large dither offset may move that star out of the FoV.  I am not

sure if this is a problem.  Maybe it's not.

 

This situation is handled and any dithering activity will avoid driving the primary star out of the field of view.  This machinery was already in place for single-star guiding.

 

Lastly, recently I encountered a funny situation.  Please see the attached

image.  You can see that PHD2 picks the diffraction spots of the bright

star as guide star.  In some sense, those diffraction spots should also 

move together with any tracking error, and therefore they can serve as 

guide stars.  From this point of view, picking those spots as guide stars

can still work.  On the other hand, those spots should respond to seeing

in a very synchronized way, i.e., they move together with the bright star.

So picking them as guide stars only improves the S/N, but does not 

have the advantage of averaging out seeing.  This must be a rare problem,

if it is a problem at all.  I am not sure if it can be solved, or if it is worthwhile

to put any effort into solving it.  Just provide this for your reference.

 

Good grief, what is that ?!?  Sirius? J  There are certainly a number of boundary conditions, this being one, where the auto-find results aren’t ideal.  This is one reason we left the option for doing single-star guiding.  We’re interested in finding ways to avoid these sorts of things but we don’t want to add a bunch of user interface mechanisms to do that.  Every time we add a control, we open the door to confusing people, making the software seem more complex, and falling victim to inadvertent bad settings.   We prefer to find ways we can quickly analyze the camera frame and avoid unwanted boundary conditions – but of course, that is a very tricky business given the huge range of equipment that’s out there.

 

Regards,

Bruce

 

Thank you for the great work on continuously improving PHD2.

 

Cheers,

Wei-Hao

 

 

 

 

--
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/8f806bd6-6444-4603-9a86-3416c2474457n%40googlegroups.com.

[Wei-Hao Wang]

Hi Bruce,

Thanks.  What you said make sense.

The bright star is Alnitak.  I was shooting horse head nebula at that time.  I kind of wonder if it is computationally

cost-effective to add a condition to avoid too many guide stars (like more than 3) from a small area (less than 1/10

of the FoV).  No matter they are artifacts produced by a bright star or not, because of the vicinity, they likely don't 

help to average out seeing (although they do help to improve S/N).  This may solve the problem.

Is it true that PHD2 re-evaluate the guide stars from time to time (or for every new exposure)?  Before guiding is

activated when I push the star button to auto-select guide stars, there is a very high chance for PHD2 to pick

those diffraction spots from Alnitak.  However, once guiding starts, sometimes I noticed that PHD2 changed

the set of guide stars.  And in those subsequently chosen guide stars, the diffraction spots around Alnitak were

often avoided by PHD2.  I observed this a few times, so this may be just a coincidence. 

About increasing the number of guide stars, one thing I often did is to push the auto-select button multiple

times before guiding to see what happens.  I sometimes find the auto-selection function end up with selection

very different sets of guide stars each time I push it (after a new exposure is taken).  What this suggests is that, 

at least in my guiding setup, the number of guide stars acceptable to the auto-selection function is actually larger 

than what it selects.  This is one of the reasons why I think there is room to increase the number of guide stars.

But of course, I understand that adding more stars will cost more computing resource, and it is very necessary

to keep the required CPU resource minimal.  I think the current implementation is a good compromise, as you said.

Cheers,

Wei-Hao