Spikes in DEC guiding / PHD2 settings with absolute encoders mount

[Sébastien Doré]

Hello,

I'm new here and looking for help with my new mount (with absolute encoders on both axis - AP Mach2). I must say I'm not that knowledgable with PHD2 settings.

I've posted my mount and guide logs to AP's forum (guide logs here as I had some spikes in my DEC graph and was worried about the working order of the mount.

After some analysis from their end and them working with me on some mount internal settings, they suggested my PHD2 settings were not optimal for a mount with absolute encoders and recommended to post here to get help with that. So, here I am. (I'll post their analysis in the next message.)

While looking at the guiding logs, please note that for about 1.5 hours (at the beginning), the mount was unbalanced in DEC as I had removed the dewshield to help with wind gusts. Doing so, my PA (initially at 2.3') also went off. When I put it back, I sent it farther off so it had become about 20' at the end of the session. But DEC balance had been restored.

More details:

• Using Version 2.6.9dev5 (to benefit from multi-star guiding)
  
• Setup is an EdgeHD 800 reduced to 1400mm F/7 with OAG
• Guiding image scale was 0.85"/px at the beginning of session and 1.7 at the end (I tried binning 2x2)
• I calibrated the nearest I could from the meridian/celestial equator
• I checked the "precision encoder" checkbox when I made my profile
• Guide speed was set to 1.0X as recommended by AP
• I ack'ed any suggestion from the Guiding Assistant
• I ran a PA drift align at the beginning of session

Thanks for any help with this. 

Sébastien

[Sébastien Doré]

Here's Astro-Physics analysis:

------------------------------------------------------------------------

Hi Sebastien,

Howard has been going thru your log files and discovered some problems with your PHD setup:

"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.

I would suggest that you go to the PHD group and let someone there analyze your log files and look at your settings. I am not an expert when it comes to PHD, I have only a rudimentary knowledge, so it would be est to ask the users on that group to help you. I know that the Mach2 will guide extremely well with your setup, even if you have some small unbalance. I put a 3000mm focal length 10" Mak-Cass on my observatory Mach2 last night and guiding was smooth and slick as snail snot on a door handle. I even set it purposely out of balance and still it guided the same.

And thanks to Howard here who sifted thru your log files and spotted the discrepancies.

Roland Christen

Astro-Physics Inc.

-------------------------------------------------------

To be continued in the next message

[Sébastien Doré]

AP's analysis continues

--------------------------------------------------

Basically the way RA guiding happens is the same as a non-encoder mount, except that the guide software doesn't have to fight a periodic error. So the guide pulses can be sent at a slower cadence. (cadence is not equal to guide star exposure).

Declination is definitely different in an Astro-Physics encoder mount. Reversal backlash is gone, so that a 1 arc sec command in the reverse direction will cause the axis to move 1 arc sec in that reverse direction. A non-encoder mount sometimes needs many 1 arc sec move commands before the Dec axis actually reverses direction. That's because the motor shaft must move a significant rotational distance (number of arc seconds) in reverse before the worm wheel begins to move. It could be 5 arc seconds, or 10 or even more on some mounts. It all depends how tight the gearing is and the clearances in the reduction gears or the amount a belt stretches in a belt drive mount. It's never zero in any mount.

There is a caveat however for the 1 arc sec reversal in an encoder mount. The encoder does not eliminate the actual mechanical delay, or the distance it takes for the reversal to happen. The motor shaft still needs to move 5 or 10 arc seconds at the 1x rate, but the encoder makes that happen automatically after only one move command. It means that any move command in Dec might take a second of time if it is a reversal move, rather than being instant. Therefore the best way to guide in Dec is to let the axis settle for a second or two before taking another guide exposure and sending another guide pulse. Too fast cadence will cause the tracking to be less accurate than it could be. Adding a 2 second delay between guide exposures is a good way to to keep the Dec axis stable and prevent hunting and chasing the seeing.

It would even be better if PHD would wait 1 second after a move command before actually taking the exposure of the guide star so that the axis has a chance to reverse and fully settle. But perhaps that is not in the cards at this time. Maxim DL does insert a small delay of that size after issuing a guide command, and so I have found that it will guide very accurately even at the longest focal lengths.

Rolando

----------------------------------------

End of analysis

Let me know if you need something else.

Sébastien

Le vendredi 7 mai 2021 à 14 h 04 min 04 s UTC-4, Sébastien Doré a écrit :

[bw_msgboard]

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.

[bw_msgboard]

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

 

---

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/EC06FE97F1B7408E87A5AB849F4F41DD%40HomeDesktop.

[mj.w...@gmail.com]

Hi Sebastien 

I'm not one of the experts, but I think you had already diagnosed the problem yourself:

"I had removed the dewshield to help with wind gusts."

 I also noted:

"Doing so, my PA (initially at 2.3') also went off. When I put it back, I sent it farther off".

I'm struggling to understand why Dec balance would affect your PA, unless something in your setup is very loose ?

Michael

Wiltshire UK

[Sébastien Doré]

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#."

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. 

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. ;-) )

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

[bw_msgboard]

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.

[Sébastien Doré]

Hi Michael,

Thank you for taking the time to reply. 

I should have added a bit more context. The wind gusts were only present at the very beginning of the session. After a while, wind literally falled to zero. But the spikes remained... So when I removed and then added my dewshield, I unadvertedly created and then fixed a DEC imbalance (which impaired my guiding performance - drift) and affected my PA by pulling-out / pushing-in the dewshield (with moderate force).

DEC balance was an hypothesis to explain why my overall guiding was "less than expected", let's put it that way. I know I should not complain with sub 1arc-sec guiding, but it seemed abnormal to me to get excellent performance for several seconds/minutes in a row (<0.5"), and then a large excursion in DEC which happened periodically (although not always exactly at a same period).

Bad PA was another hypothesis to explain why the guide pulses were always in the same direction.

I put that upfront here because I thought it should be taken into consideration when looking at the logs but it might have introduced more confusion than anything. The thing to remember is that for the second half of the session, the DEC (and RA) balance was good, PA was off (about 20' from NCP), and large spikes were periodically occuring in DEC.

Hope that clarifies... CS!

Sébastien

[Sébastien Doré]

Bruce,

My apologies, I should have been clearer. The quotes from AP in my last message weren't in response to your analysis, so please take no offense from them. It was their analysis of the problem at the best of their knowledge with PHD2 guiding (which, as you stated, they recognized weren't experts in). And it was the very reason why they sent me here. (Those quotes were included in my 3 first messages as reference.) So sorry about that.

That being clarified, regarding for the wind and dewshield, these were fixed by the second half of the session. The spikes weren't...

Also for reference, there is no cable snag possible with my setup since all cables are connected to the NUC piggybacked on the OTA. Only power and USB to the mount goes to connectors embedded into the DEC baseplate and then through the mount to the bottom. See picture below. 

Finally, please forgive me if I take some time to reply sometimes and if I use weird/unappropriate expressions, English is not my native language.

Regards,

Sébastien

Le sam. 8 mai 2021, à 12 h 52, bw_msgboard <bw_m...@earthlink.net> a écrit :

See below.

[Sébastien Doré]

Hello again Bruce,

[If you haven't already, please read my previous message before this one.]

If you don't mind, could you please take a quick look at section 16 (starting at 00:58:09) of my guide logs and let me know if your conclusions would be the same as before. 

From what I'm seeing with the log viewer in that section, I feel like the description that Astro-Physics made kind of correspond to what I see (small moves, then nothing even if DEC is drifting away, then large move) but I'm certainly no better than both you and them at interpreting that graph. I agree with you though that the large pulses seem to occur after the large excursions therefore are the effect and not the cause as you pointed out...

The signification of the values reported for each guide frame at the top are not entirely clear to me either (difference between "guide" and "corr" coordinates, "m" value = starmass ?). If you wouldn't mind to enlight me, that would help.

Regards,

Sébastien

[bw_msgboard]

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.

[Sébastien Doré]

Bruce,

 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.  

Don't bother writing twice the same thing, I can read. Thanks for the addtionnal information.

Sébastien

[bw_msgboard]

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.

[Sébastien Doré]

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.

Sébastien

[bw_msgboard]

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.

[Sébastien Doré]

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. 

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.

Regards,

Sébastien

[bw_msgboard]

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.

[Brian Valente]

>>>, 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.

lowpass2 in the documentation says the exact opposite: https://openphdguiding.org/manual/?section=Guide_algorithms.htm 

The LowPass2 algorithm is a variation of the original LowPass algorithm with somewhat different behavior.  It also maintains a history of guiding corrections, but the next correction is simply a linear extension of the commands that have come before it (i.e. a slope calculation).  This continues until a significant change in direction is seen, at which point the history is cleared.  The algorithm has two adjustable properties: minimum-move and aggressiveness.  Minimum-move has the same effect as it does in the other guide algorithms, and aggressiveness (percentage) is a way of further dampening the size of the guide corrections. LowPass2 is a very conservative, high-impedance algorithm that may be a good choice for users with good seeing conditions and well-behaved mounts with little or no declination backlash.  It is the recommended algorithm for mounts that have high-precision encoders on the two axes.

--

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.

--

Brian 

Brian Valente

portfolio brianvalentephotography.com 

[Sébastien Doré]

lowpass2 in the documentation says the exact opposite: https://openphdguiding.org/manual/?section=Guide_algorithms.htm 

Thanks for confirming/reaffirming this, gents. That was also my understanding from reading the manual. Sorry that I might have brought up any confusion here.

Regards,

Sébastien