Hi Sebastien. To jump to the bottom line, this is NOT a guiding or PHD2 problem. The key is to use the PHDLogViewer and look at closely at what happens when you get one of these big Dec excursions. Here’s just one example (Dec in green):
Time is on the x-axis and events occur sequentially on a left-to-right basis – always. The big excursion appeared starting at point 1. There was no guide command issued at this point – the corrections are shown by the green rectangles. The peak occurred at point 2, so something other than guiding caused the Dec axis to move. At point 3, there was a guide correction but it was simply in response to the big excursion – it was a downstream effect, not a cause of the problem, and it was in the opposite direction to the original problem. This sort of thing is a very common equipment problem and the straightforward analysis is discussed further starting on page 6 of this document: https://openphdguiding.org/tutorial-analyzing-phd2-guiding-results/
So things like min-move values and other PHD2 settings are irrelevant here – the problem was not caused by guiding. I also doubt it was the mount because the Dec motor is normally idle. The most common explanations are things like dragging cables or anything else that can create even a tiny tug on the guiding apparatus. Wind gusts can also do this but that’s probably something you would have been aware of Significant out-of-balance conditions, loose clutches and other things can also create these problems, it’s unfortunately a matter of trying to find what it is. In your case, these “large” Dec excursions represent only a 1-1.5 pixel unwanted movement of the guide camera which corresponds to about 9 microns – that’s less than 1/5 the thickness of a human hair. To further emphasize the point that this is not caused by guiding, here’s a view of a longer sequence where many of these excursions happened:
*All* of these excursions were toward the north yet there were zero north guide commands issued for the entire period – you can see that all the guide commands are in the south direction (down). So this isn’t a complicated problem – nothing to do with direction reversals, mount backlash, none of that.
Hope you can track it down quickly,
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/59f5657c-1c35-4fa7-8112-7c61fbacda4cn%40googlegroups.com.
Sorry Sebastien, I forgot to show one other “clincher”. Take a look at this guiding sequence here:
This shows another one of the large Dec excursions while guiding was completely disabled. So, not a guiding problem…
Bruce
"PHD2 is indeed commanding moves of 2 – 3 arc-seconds, all of them south. It is also sending many moves of single digit mSecs. There were 60 instances of :Ms1# in the one APCC log file. That’s calling for a move of ~ 0.015 arc-seconds. The screen below shows 11 move commands in a row, most or all of which were too small, followed by a ~2 arc-second move - :Ms130#."
Basically you have PHD set up to respond to every tiny error in such a way that no movement occurs for many cycles, which is then followed by a single large movement. This type of Dec algorithm was developed for mounts that had huge backlash where the mount does not respond to move commands in a timely way, and then finally PHD sends a large correction command in order to get the mount axis moving. That's when the spike occurs.
Apparently you have set up your Min and Max moves wrong as well as choosing the wrong algorithm for a precision mount. never should guiding software send 1 millisecond ( 0.015 arc sec) move commands because the mount basically will not move at all, or so slightly that it will never register in your guide star motion. You may even have set your guide speed wrong - it should always be left at 1x sidereal, never anything else.
See below.
From: open-phd...@googlegroups.com [mailto:open-phd...@googlegroups.com] On Behalf Of Sébastien Doré
Sent: Saturday, May 08, 2021 9:19
AM
To: open-phd...@googlegroups.com
Subject: Re: [open-phd-guiding]
Spikes in DEC guiding / PHD2 settings with absolute encoders mount
Hi Bruce,
Thanks for taking the time to go through my logs. Your explanation makes sense. But it leaves me scratching my head because Astro-Physics stated the following:
"PHD2 is indeed commanding moves of 2 – 3 arc-seconds, all of them south. It is also sending many moves of single digit mSecs. There were 60 instances of :Ms1# in the one APCC log file. That’s calling for a move of ~ 0.015 arc-seconds. The screen below shows 11 move commands in a row, most or all of which were too small, followed by a ~2 arc-second move - :Ms130#."
So what. If the mount doesn’t move, PHD2 doesn’t care. You can increase your min-move values to avoid this if you want, but it causes no harm. None of this has anything to do with the problem because they didn’t understand the temporal sequence and distinguish between cause and effect. That’s what I explained to you in my response.
Basically you have PHD set up to respond to every tiny error in such a way that no movement occurs for many cycles, which is then followed by a single large movement. This type of Dec algorithm was developed for mounts that had huge backlash where the mount does not respond to move commands in a timely way, and then finally PHD sends a large correction command in order to get the mount axis moving. That's when the spike occurs.
Sorry, their analysis is wrong. To give them a break, Howard said in his message he wasn’t an expert in PHD2 guiding. You weren’t using Resist-switch which is perhaps what they are talking about.
Apparently you have set up your Min and Max moves wrong as well as choosing the wrong algorithm for a precision mount. never should guiding software send 1 millisecond ( 0.015 arc sec) move commands because the mount basically will not move at all, or so slightly that it will never register in your guide star motion. You may even have set your guide speed wrong - it should always be left at 1x sidereal, never anything else.
No, again, a wrong analysis. You were using LowPass2, which is what they have previously recommended for their encoder mounts. That’s why PHD2 recommends it and it’s the right choice. PHD2 doesn’t care about the guide speed setting, that’s only used to compute a calibration step-size – the actual guide speed setting in the mount is reflected in the calibration results.
So who's right ? I'm a bit lost here... I'll forward your reply to them anyway to see what they have to say. (Looks like I'm playing ping-pong. ;-) )
I don’t plan to debate it with anyone but I stand by my analysis of your problem. Instead of playing ping-pong, you should probably figure out what’s causing your OTA to move in this way on its own. Someone said you were fiddling around with a dew shield and had wind gusts – that’s certainly a potential cause of the problem.
Bruce
BTW, you probably saw I had LowPass2 as my DEC guiding algo (which B. Valente, a contributor to both forums, confirmed was the right one to use with encoder mounts. Reading through PHD2 doc also confirmed that) so, even more head scratching...
At any rate, thanks for your help.
Sébastien
--
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/CANyf-tikL%3DStrzRqhxwL8VsOxTT5VKhzCF5HXgo0w7ykdst7tQ%40mail.gmail.com.
See below.
I’ve looked at section 16 and of course the situation is the same. If you’re trying to understand the big north excursions, you have to pay attention to the order in which things happened – cause and effect, cause and effect. If you mouse over the data points on the graph, it shows you the exact timestamps that apply. With regard to how the small guide pulses behave, you’re just micro-managing the algorithm, none of that has anything to do with your big excursion problems. All of the guide commands were ‘south’ – all your big excursions were ‘north’. Do you see that? For starters, you’ve got a really huge Dec drift rate in section 16, something like 3.6 arc-sec/minute. That’s why the guiding tends to fall behind and it’s also why all the guide commands were in one direction.
The ‘guide’ values show the RA and Dec pixel offsets that the guiding algorithm will try to correct for – not the same as the raw offset. The ‘Corr’ values show the lengths of the guide pulses, in units of milliseconds, that were sent to the mount. The star mass value is an internal measure of star-size. You can read about all of this in the manual, look in Trouble-shooting/Using the log files – but none of this has anything at all to do with your problem.
Bruce
From: open-phd...@googlegroups.com [mailto:open-phd...@googlegroups.com] On Behalf Of Sébastien Doré
Sent: Saturday, May 08, 2021 12:56
PM
To: Open PHD Guiding
Subject: Re: [open-phd-guiding]
Spikes in DEC guiding / PHD2 settings with absolute encoders mount
Hello again 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/9c14e550-a42a-4416-98a7-772381aed692n%40googlegroups.com.
If you’re trying to understand the big north excursions, you have to pay attention to the order in which things happened – cause and effect, cause and effect.
Sorry, no offense intended. I was concerned that we weren’t communicating very effectively and wanted to emphasize the point, which I think is critical to understanding your problem.
From: open-phd...@googlegroups.com [mailto:open-phd...@googlegroups.com] On Behalf Of Sébastien Doré
Sent: Saturday, May 08, 2021 5:01
PM
To: open-phd...@googlegroups.com
Subject: Re: [open-phd-guiding]
Spikes in DEC guiding / PHD2 settings with absolute encoders mount
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/CANyf-thkYtU6Msm7zNjLPdb-O94NSRuPVZ%2B%2BKwvKRR10ikkcyA%40mail.gmail.com.
Ok. I think you might want to take another look at the Dec balance as well. When you ran the Guiding Assistant at Dec = 28, you had a small amount of Dec drift, equivalent to a polar alignment error of 2 arc-min. But when you made a short GA run later at Dec=47, the drift rate was huge, equivalent to a polar alignment error of 20 arc-min. That doesn’t make sense, I really doubt that the mount moved that much. But it could happen if the Dec clutch was a bit loose or the OTA was very nose-heavy. You could test for this by running the GA with the scope pointing straight overhead then repeating the test with the scope pointing at around 50 degrees declination.
As far as the LowPass2 algorithm goes, it’s really intended for mounts that *only* drift in Dec because of polar alignment error. So it expects there to be a linear rate of drift that needs to be corrected. But when you get these large Dec excursions, that invalidates the calculated drift rate and the algorithm has to reset and start over. The same is basically true of the Z-Filter algorithm, neither is going to do very well when the scope is moving around this much. For the purpose of your testing, you could use Hysteresis for Dec (not Resist-Switch( and see what happens – I expect nothing would change. The guiding sequences also show a dependency on side-of-pier – the guide star deflections were toward the south when side of pier was west and toward the north when side of pier was east. That’s also consistent with a balance problem.
Hope they can help you track it down,
Bruce
From: open-phd...@googlegroups.com [mailto:open-phd...@googlegroups.com] On Behalf Of Sébastien Doré
Sent: Sunday, May 09, 2021 3:15 PM
To: open-phd...@googlegroups.com
Subject: Re: [open-phd-guiding]
Spikes in DEC guiding / PHD2 settings with absolute encoders mount
Don't worry, you emphasized enough... Moving on, AP mostly agrees with your analysis (which I shared), but are still not sure guiding can be entirely ruled out at this point. They may revisit their own recommendation of using the lowpass2 algorithm with their encoder mounts. They will also remote-in my Mach2 to see if they can diagnose further while axis are actually moving.
--
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/CANyf-tjF1bk2GoRxU52ZU1SDQ0uUTYaz8B83GuuiKQ2En1-x0g%40mail.gmail.com.
Hi Sebastien, see below…
From:
open-phd...@googlegroups.com [mailto:open-phd...@googlegroups.com] On Behalf Of Sébastien Doré
Sent: Monday, May 10, 2021 3:48 PM
To:
open-phd...@googlegroups.com
Subject: Re: [open-phd-guiding]
Spikes in DEC guiding / PHD2 settings with absolute encoders mount
I described in a previous post that the difference between the PA at the beginning and the end of the session was probably my fault, because I had removed/put back the dewshield (with some pulling/pushing force) to help with wind. That also add the side effect of unbalancing the OTA: when dewshield was off, OTA was back-heavy, when dewshield was back on, balance was most likely restored to original. So, unless my balance was off to begin with, which is possible (but I doubt it), the problem has to come from elsewhere since I had the problem until the end of the night.
As for the clutches, there are 4 of them on the DEC axis only (4 more on RA) and I am pretty sure they were very tight as I triple-check that sort of things before every run to make sure big and sudden temperature drops (common at my place in spring) do not virtually loosen clutches, knobs, whatever by the effect of metal contraction (It has happened to me in the past, but not with this mount).
In regard to the algorithm, I will try what you suggest (Hysterisis for DEC) next clear night I get. Thanks for that. I will also give a shot at MaximDL (trial version), which has no user-selectable algorithm apparently, for guiding and see if I get any different results. Of course, I'll make sure my balance is as near perfect as it can be, my PA as precise as possible and that everything is pretty tight. And thanks for the explanation about the behavior of the lowpass2 with big DEC excursions kinda resetting the algorithm.
If you want to try guiding just like MaximDL, it’s easy. Use the ‘Hysteresis’ algorithm and set the ‘hysteresis’ parameter to zero. Then the aggressiveness and min-move settings are all you have left, and that’s how MaximDL works. The terminology is even the same although MaximDL uses different units for these parameters. The more sophisticated algorithms in PHD2 are trying to filter out the seeing effects and issue guide commands only for what’s left.
About the hypothesis of lowpass2 being "the wrong approach" for an AP mount, from what I've been told, it had to do with the fact that the algorithm was "meant for mounts with significant backlash" which the Mach2 doesn't have. But don't quote me on that as I was not directly part of that discussion, so I can't say much more. You can possibly confirm / infirm that statement though.
No, that’s exactly backwards. LowPass2 is really focused on correcting for slow drift in Declination, the drift that’s caused by a reasonable amount of polar alignment error. When the guide star is bouncing around all over the place with un-commanded large displacements, LowPass2 will be slow to react. The same is true if the mount has a lot of Dec backlash so we don’t recommend it for those mounts. It’s the algorithm that’s recommended for systems that have low or no backlash and are very well-behaved in Dec, ones that don’t have these big displacement problems. We’ve seen it used effectively on a range of high-end mounts – Avalons, 10-Microns, Paramounts, etc. Often, those users are employing long guide exposure times, up to 10-seconds, because the inherent tracking error of the mount and the attached gear is so low. Until you can figure out where these abrupt excursions are coming from, the hysteresis algorithm will do a better job of reacting and restoring the guide star position.
Good luck,
Bruce
Regards,
Sébastien
--
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/CANyf-thk7FgywDE8eSEPJdX%2BKVHKvuiPFFCezvKvP98C8xZmAg%40mail.gmail.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/CANyf-thk7FgywDE8eSEPJdX%2BKVHKvuiPFFCezvKvP98C8xZmAg%40mail.gmail.com.
lowpass2 in the documentation says the exact opposite: https://openphdguiding.org/manual/?section=Guide_algorithms.htm