What is "Drift Limiting Exposure"? (as calculated by the Guiding Assistant)

[Mike M]

I searched for an answer to this Q on both this forum and Google generally but couldn't find an answer. If one is out there, please point me to it!

I'd also like to know more about the specifics of how the other Guiding Assistant parameters (such as, and especially, hi freq star motion) are computed.

OK, see how one Q turns into many? Another one: there are references to using GA to estimate atmospheric seeing - exactly how is that done? Which GA parameter(s) are used to do this? Does this relate to the afore mentioned Hi Freq star motion?

Finally, since it is better to judge performance in arc-sec rather than pixels, would it make sense to change PHD's MnMo settings to be in units of arc-sec rather than pixels as is now? I find myself converting pixels to arc-sec before I make adjustments to this parameter...

Absolutely awesome program Andy et al, much appreciated!

Thank you,

Mike

[Andy Galasso]

Hi Mike,

You may not have noticed that you can hover the mouse over any of the labels in the Guiding Assistant to see a description.

The description for Drift-limiting exposure says "Exposure time to keep maximum RA drift below the recommended min-move level". To elaborate on that... In general, long exposures are better to average out seeing, but if the exposures are too long, then RA tracking error can cause star elongation.  PHD2 looks at the RA tracking curve and determines the longest exposure that is short enough to keep up with the RA error and keep the RA guide error below the min-motion threshold (min-motion based on the measured high frequency (seeing-induced) motion.)

High frequency star motion is determined by passing the series of offsets through a high-pass filter so the number represents the contribution of seeing, but not of RA periodic error or of Declination drift. (source code here)

Finally, since it is better to judge performance in arc-sec rather than pixels, would it make sense to change PHD's MnMo settings to be in units of arc-sec rather than pixels as is now? I find myself converting pixels to arc-sec before I make adjustments to this parameter...

PHD2 does not require users to specify the parameters needed to convert pixels to arc-seconds (guide scope focal length and guide camera pixel size), so we do not always have the information available to do the conversion.  If we changed the settings to be in arc-seconds, we'd need to find a way to also support entering the value in pixels.  If you can think of a way to do that without cluttering up the interface, we're open to suggestions.

Andy

[Bruce Waddington]

In the spirit of "too much information", I'll some to what Andy already said.  In my experience, the drift-limiting exposure stat is one of the noisiest ones in the GA grid.  If you're working with fine image scales, it's easy for seeing to exacerbate what appears to be a steep section in the RA tracking curve - it's hard to filter this out completely.  So I think the drift-limited exposure time is often overly pessimistic in these situations - I know that for my own set-up, I can get excellent guiding results with exposures substantially longer.  It would probably be better for you to look at the RA tracking behavior of your mount over several worm cycles and identify the steepest portions that recur and how long they last.  That might give you a fairer estimate of how long a guide exposure you can tolerate.

 

The references to using the GA as a gauge of seeing are ok as long as you remember that we're not measuring the seeing in the traditional sense - not like a seeing monitor.  What it tries to measure is the random "jitter" that PHD2 sees as it measures the position of the guide star from frame to frame.  This is actually a good number, something that directly affects how the guiding will behave.  So it's usually well-correlated with seeing but not a direct measure of it.

 

The Min-Mo setting can be argued at length. :-)  First, it's inherently an outlier because it's in units of pixels while everything else is in units of time or percentage.  I can't recall anything on the *input* side of guiding that talks about arc-sec - we like to use arc-sec on the *output* side of things to show results that are translatable across equipment.  In fact, the input specifications all map directly to how the algorithms perform - what you're keying in are the things that directly control the algorithms, no translation required.  Personally, I think that's a good thing.  Finally, use of a pixel value for Min-Mo makes sense when you consider the low end of the setting range.  At some point, you may pass the level of accuracy in the centroid algorithm, which is conservatively good to 0.1px in most situations.  That's an easy number to remember, but thinking about it in terms of arc-sec probably doesn't make much sense. This is a fairly likely occurrence for people who guide with very coarse image scales.  So when you add all this to the issue of complexity in the UI, you can probably see why we haven't fooled with it. :-)

 

Have fun,

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.
For more options, visit https://groups.google.com/d/optout.