RMS pixel - arcsec conversion suggestion

[Chris Woodhouse]

This is one for the developers.

I know there are lots of conversations about the displayed RMS tracking errors and the rabbit hole it can create with users placing too much emphasis on the value without realising the effect of guiding interval and declination. I have a suggestion that might address the effect of declination.

I think I'm correct in stating that PHD2's RMS conversion between guider pixels and arc seconds is static, merely using the pixel scale to convert between the two for the readout.

Would it be useful to change the RA axis so that the conversion is:

Right Ascension RMS (arcsec)= RMS(pixel) x pixel scale x cos(DEC).  ?

In that way, it should reduce the RMS arcsec readout's sensitivity at higher declinations and give a better approximation of star appearance in the target exposures (in the presence of atmospheric seeing).

hope this helps

[Bruce Waddington]

I don't think we would want to do this for a number of reasons:

1.  The real-time display is reporting actual data, what PHD2 actually sees.  What you're talking about is part of analyzing and interpreting that data, something that should be done after the fact.

2.  The physical reality is that guiding *is* easier closer to the pole and guiding results are often better.  Why would we want to hide that?

3.  Not all of the RA movement is attributable to RA drive tracking error, so you can't apply a cos() adjustment to everything.  Things like seeing effects and shifts in payload don't scale predictably with pointing position.

4.  This wouldn't work at all for users of ST-4 guiding who don't have a mount connection.  So your suggestion would probably help to revive the myth that ST-4 guiding is more accurate than pulse-guiding.

5.  Making a change like this would trigger a high volume of complaints that PHD2 guiding had suddenly degraded because of a "bad" release

Regards,

Bruce

[Chris Woodhouse]

Fair enough. I try to help folks on several user forums for harmonic drives, who are all typically guiding sub-second and becoming frustrated and confused at the RMS metrics, because they are heavily influenced by seeing. I was trying to visualise a way to desensitise the RMS from atmospheric seeing, especially at high Dec. 

It occurs that if PHDLogviewer can examine a log file and extract the underlying tracking error, it might also be possible for PHD2 to do the opposite and give an atmospheric seeing metric.  I’m not sure if that has occurred, or if you even want to go there. From memory, I think metaguide might do this. 

Clear skies

Chris

[Brian Valente]

Hi Chris

>>> I try to help folks on several user forums

if you contact me directly I have something you might be interested in.

Brian

bvalente at gmail dot 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 visit https://groups.google.com/d/msgid/open-phd-guiding/a80c2bee-6b01-42b4-9da0-eace9c0e9ea6n%40googlegroups.com.

--

Brian 

Brian Valente

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

[Bruce Waddington]

For what you're talking about, I don't think there's any need to do something fancy.  People have a poor-man's seeing monitor sitting right in front of them - it's the graph of the Dec activity.  If the Dec min-move has been set to a reasonable value - for example by letting the Guiding Assistant make a recommendation using the same exposure times that will be used for guiding - then the rate of issuing Dec guide commands is likely to be in the 10-20% range.  So 80+% of the time, the Dec motor will be idle and all the other high-frequency Dec movement will be due to seeing.  If you want to eliminate Dec guiding altogether, you can re-run the GA or temporarily disable Dec guiding.  None of this has any sensitivity to Dec location, so all of this high-frequency activity is baked into the RA tracking data.

The LogViewer doesn't do anything special to deconvolve the effect of seeing.  The "raw" RA data is imply a calculation of the observed RA movement minus the issuance of guide corrections.  So the seeing signal is still in there.  When looking at the FFT analysis for estimating periodic error, the seeing signal will typically have been averaged over longer time periods so it has less impact on what you're trying to see.

Regards,

Bruce

[Chris Woodhouse]

That is very true, especially if the DEC guiding is turned off.
I often ask folks to turn off DEC corrections and watch the DEC RMS fall, proving they are potentially overcorrecting.