I think they’re probably talking about the image scale – the resolution of the guide camera/guide scope in units of arc-sec/sec. The advice isn’t wrong but neither is it a requirement.
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/dd17bb66-c735-477a-ba93-2eb43470eaf0n%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/004501d89890%24a7f60360%24f7e20a20%24%40earthlink.net.
This is unfortunately a squishy discussion because there are so many free variables. But I can explain the basic idea behind the desire for a rule-of-thumb. From a guiding perspective, the goal is for the guided imaging system to be performance-limited by either mount performance or seeing, two things the guiding software can’t do much about. We don’t want performance to be limited by the guiding software. Assuming users haven’t chosen ridiculous guiding parameters and have gotten acceptable calibrations, the guiding should produce results that are limited by the accuracy of the centroid values of the guide stars. The centroid accuracy is proportional to SNR which depends on a bunch of things we have no control over – site conditions, sky conditions, accuracy of guide camera focus, etc. The empirical evidence across thousands of amateur setups and locations indicates that centroid accuracy is typically 0.1 px and as low as 0.05 px when multiple guide stars are available. If we take the value of 0.1 px and apply the image scale of the guiding system, we get a performance “floor” for guiding, and we want that floor to be well below the tracking errors that arise from mount mechanics and seeing. Then we have to consider what level of performance is needed by the main-scope imaging system based on its image scale. Now let’s take a ridiculous example, but one we’ve actually seen. Suppose the primary system image scale is 1 arc-sec/px and the guider is working with an image scale of 10 arc-sec/px. That means the likely centroid uncertainty of 0.1 px will translate to a guiding uncertainty of 1 arc-sec and thus to an expected performance floor of 1 px on the main system. It’s unlikely this would be even close to acceptable. It’s often easier to work in the reverse direction by knowing the image scale and the optical performance of your main system and deciding how much centroid uncertainty you can tolerate. You might want to be more conservative and use an expected uncertainty of 0.2px on the guiding system. You can see why there’s no “hard limit” here. The goal for having even the rough rule-of-thumb is to produce a result where the user would be highly unlikely to be limited by centroid accuracy, and the range of 3x to 4x does that.
You can see that this relationship between the two image scales would become increasingly important as the image scale of the main system increases (focal length increases or pixel size decreases). As it turns out though, the topic becomes moot at these finer image scales because differential flexure between the two scopes becomes the dominant source of error – not the centroid calculations. Once you drop below about 1 arc-sec/px on the main system, you are likely to be in a situation where you need to use an off-axis-guider.
Hope this makes some sense,
Bruce
From: open-phd...@googlegroups.com <open-phd...@googlegroups.com> On Behalf Of comp...@gmail.com
Sent: Saturday, July 16, 2022 12:35 AM
To: Open PHD Guiding <open-phd...@googlegroups.com>
--
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/db895289-1542-4cf0-a6eb-3c8821479580n%40googlegroups.com.
To Bruce,
As a waiter in a well known British Comedy once used to say.... Que???????
So many Questions, but first I must get what is for me a reasonable result with my guiding, then maybe I will ask some questions
This is a good place to learn, Thank you..
Chris S.
From: bw_m...@earthlink.net
Sent: 16 July 2022 19:53
To: open-phd...@googlegroups.com
Subject: RE: [open-phd-guiding] Re: Autoguider sampling versus Imaging sampling
This is unfortunately a squishy discussion because there are so many free variables. But I can explain the basic idea behind the desire for a rule-of-thumb. From a guiding perspective, the goal is for the guided imaging system to be performance-limited by either mount performance or seeing, two things the guiding software can’t do much about. We don’t want performance to be limited by the guiding software. Assuming users haven’t chosen ridiculous guiding parameters and have gotten acceptable calibrations, the guiding should produce results that are limited by the accuracy of the centroid values of the guide stars. The centroid accuracy is proportional to SNR which depends on a bunch of things we have no control over – site conditions, sky conditions, accuracy of guide camera focus, etc The empirical evidence across thousands of amateur setups and locations indicates that centroid accuracy is typically 0.1 px and as low as 0.05 px when multiple guide stars are available. If we take the value of 0.1 px and apply the image scale of the guiding system, we get a performance “floor” for guiding, and we want that floor to be well below the tracking errors that arise from mount mechanics and seeing. Then we have to consider what level of performance is needed by the main-scope imaging system based on its image scale. Now let’s take a ridiculous example, but one we’ve actually seen. Suppose the primary system image scale is 1 arc-sec/px and the guider is working with an image scale of 10 arc-sec/px. That means the likely centroid uncertainty of 0.1 px will translate to a guiding uncertainty of 1 arc-sec and thus to an expected performance floor of 1 px on the main system. It’s unlikely this would be even close to acceptable. It’s often easier to work in the reverse direction by knowing the image scale and the optical performance of your main system and deciding how much centroid uncertainty you can tolerate. You might want to be more conservative and use an expected uncertainty of 0.2px on the guiding system. You can see why there’s no “hard limit” here. The goal for having even the rough rule-of-thumb is to produce a result where the user would be highly unlikely to be limited by centroid accuracy, and the range of 3x to 4x does that.
To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/001601d89945%245a0e7640%240e2b62c0%24%40earthlink.net.
If I’m interpreting your initial comments correctly and you’re really trying to image at 1600mm focal length with a color camera that has 3.75 micron pixels, I don’t think you’ll be able to use a separate guide scope in any case. Since it’s a color camera, you can’t bin it which means your main system image scale will be less than 0.5 arc-sec/px. That puts you in a region where you will need an off-axis-guider. Otherwise, even with perfect guiding, you will have problems with differential flexure.
To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/56f85b0e-8041-44bd-8a8b-ce5b2a428f15n%40googlegroups.com.