Hi Anthony. Andy didn’t put that in the LogViewer, probably because he and I both think it’s essentially useless. We’ve been analyzing 500-700 logs per year for many years now and have never needed that statistic. It’s really a carry-over from PHD1 and the LogViewer provides much better tools for understanding your RA tracking performance. For example, if you want to know if the guiding is “one-sided”, you can use the apparent drift calculations for that. For real-time use, the Guiding Assistant is a better option for estimating a min-move, and fiddling around with aggressiveness on-the-fly is quite often a waste of time. So I wonder about the advice you were given, I honestly don’t know how the RA Osc number can be used effectively.
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/8d53819c-26dc-4be6-9e9e-347566a83f9fn%40googlegroups.com.
Hi Anthony. I don’t want to say much about this guy’s specific advice because it’s context-free and I don’t have any data to support or reject it. I will say that anecdotal comments made on social media without context or qualification are likely to be useless. But let’s come back to your original question – why don’t we use RA-Osc as an important metric and why isn’t it shown in the LogViewer. Let’s assume you’re looking at your RA tracking performance, you aren’t happy with it, and you’d like to see if it can be improved. That’s the sort of thing we discuss on this forum all the time. We know that apparent RA tracking (what you see on the graph) is affected by all of these things:
This is probably not a complete list, it’s just what comes to mind. So how likely is it that a simple metric like RA-oscillation can distill all of these interacting factors and provide an important insight? I’d think it’s just about zero and that’s why we don’t need it. I would say that RA tracking performance is determined by the mount mechanics in over 95% of the cases we analyze – not by guiding parameters when those parameters are at or close to their default settings. By the way, this list also applies to whether one person’s experience is applicable to anyone else – this is the “context” I was talking about.
Perhaps another thing that’s behind your question is an assumption that you can probably improve your tracking performance by squinting at a graph or a number in real-time and making adjustments to the guiding parameters that will produce a lasting improvement. I think that’s pretty unlikely. The min-move settings are the only parameters I would consider adjusting in this way, which is part of the advice you were given. The idea there is to avoid chasing the seeing, which is a reasonable goal. But a more reliable metric for that – other than re-running the Guiding Assistant - is to look at the Dec guiding to see how much guiding activity you’re getting there and how often you’re getting reversals *in Dec* - not in RA. If you’re getting a lot of Dec guiding activity – e.g. 50% - you’re probably chasing the seeing and are using min-moves that are too low. Those are reasonable adjustments to make because they don’t have side-effects that are then hard to see. Adjusting the aggressiveness, however, does have side-effects – it means you can trigger under-correction in the steepest sections of your mount’s uncorrected periodic error curve and your results will be worse – and that will be nearly impossible to see in real-time.
If you haven’t seen it, here’s another view of trying to adjust things on the fly – scroll down to the appendix section labeled “Fooled by Randomness”
https://openphdguiding.org/tutorial-analyzing-phd2-guiding-results/
Hope this helps,
To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/5348f4b0-d62f-455e-be48-88ce8777db3an%40googlegroups.com.
Hi Anthony, see below.
From: open-phd...@googlegroups.com [mailto:open-phd...@googlegroups.com] On Behalf Of anthonyq...@gmail.com
Sent: Sunday, January 31, 2021
11:31 AM
To: Open PHD Guiding
Subject: Re: [open-phd-guiding] RA
Osc in Log Viewer?
Bruce-
Thanks for the thorough response!
Your advice on Minmo is reassuring because I had arrived at that approach which has been effective. (Up Minmo if seeing degrades based upon volatility of the Dec corrections.) I arrived at this solution by following the lead of Guiding Assistant. I noted how much higher Minmo was on nights with less stable seeing than on nights with more still skies.
I think you have a good approach with this.
As I had mentioned, I really haven't been having issues, but I had been
questioning my Agressiveness setting because I think I set it arbitrarily a
long time ago and left it. So that leaves one question:
How do I determine appropriate aggressiveness for RA and Dec, or Predictive and
Reactive weight for RA in PPEC? (I am assuming Predictive and Reactive weight
are somewhat analogous to Aggressiveness?) If this is addressed somewhere in
the literature, just affirm that and I'll go searching...
With the hysteresis algorithm, the default setting of 70% is recommended and I can’t recall seeing a guide log where there was any clear reason to change it. People who make large changes to this are probably just trying to cover up a mechanical problem and people who make small adjustments are possibly fooling themselves. With the PPEC algorithm, I think it’s a different story but it isn’t the sort of thing you can adjust on-the-fly. The default weights (which are like aggressiveness) are good places to start. Beyond that, you would need to analyze how effective PPEC is in reducing the size of the various periodic error frequencies. If you can see that the algorithm is dialed in to the frequencies you’re worried about, you might increase the reactive weight value. All of this requires some careful analysis in the LogViewer, looking at a variety of pointing positions over multiple nights.
I am pretty far past the
tweaking-in-the-moment-all-the-time-to-see-what-happens phase that is addressed
by the "Fooled by randomness". I mostly just get guiding going and
cross my fingers for stable atmosphere, with Minmo adjustments if appropriate,
(and if I remember...)
Sounds good. If you aspire to doing automated imaging, you probably aren’t going to be watching this stuff anyway, and there will be some nights or parts of nights where the seeing deteriorates and trying to do high-resolution imaging becomes futile. Of course, if you’re doing LRGB imaging, those can be good times to just pile on the color data.
Bruce
Thanks again!
-Anthony
On Saturday, January 30, 2021 at 10:28:20 AM UTC-7 bw_m...@earthlink.net wrote:
Hi Anthony. I don’t want to say much about this guy’s specific advice because it’s context-free and I don’t have any data to support or reject it. I will say that anecdotal comments made on social media without context or qualification are likely to be useless. But let’s come back to your original question – why don’t we use RA-Osc as an important metric and why isn’t it shown in the LogViewer. Let’s assume you’re looking at your RA tracking performance, you aren’t happy with it, and you’d like to see if it can be improved. That’s the sort of thing we discuss on this forum all the time. We know that apparent RA tracking (what you see on the graph) is affected by all of these things:
1. Image scale
2. Exposure time
3. Seeing conditions – both high-level atmospheric seeing and local convection and air flow around the scope and the site
4. Choice of guide algorithm
5. Min-move setting
6. Quality of the calibration and whether the calibration accurately reflects the current orientation of the hardware
7. Mount mechanics
a. Properties of the uncorrected periodic error in the RA drive – both frequency and amplitude
b. Use of periodic error correction and the quality of the periodic error curve
c. Gear roughness
d. Mount imbalance
e. RA drift from flexure or polar alignment error
f. Rigidity of the guiding assembly
To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/1a82a438-9c02-4750-baf1-0058ee662ab1n%40googlegroups.com.
Hi Richard. I’m sorry if you feel misled. I’m familiar with this part of the documentation because I wrote it – 7 years ago. At the time, it was a description of a feature that was invented in PHD1 when there was no application awareness of image scale, no guiding assistant, no way to recommend scale-specific min-move values, etc.. Things have changed and our understanding of best guiding practices has evolved, that’s the nature of the hobby. With the level of end-user support we do and the need to upgrade the documentation to reflect new features, it’s difficult to find time to go back and revise old Help content that no longer reflects current best practices. I will make sure this part of the manual is strongly edited before the next release.
Bruce
To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/fcf46a2c-8a9d-43c2-b353-35d36d904e97n%40googlegroups.com.
I wouldn’t go that far Bruce, I’m OK and understand.
Not the first time I’ve taken a path that’s not quite right.
Appreciate the efforts and support from you guys.
To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/389E4583BD5B4BABAC4D161FBA444985%40HomeDesktop.
Thanks, Richard, no worries…
Bruce