DEC oscillations on Mach-1

[Steve Winston]

This topic was touched on here and has been ongoing in CN mount and Y! AP forums.

I just updated the CN thread with the results of some testing I had done on my Mach1 (see here: https://www.cloudynights.com/topic/622947-mach1-dec-oscillations-our-experience/?p=8681874), but I'd like to get some input from the PHD2 team on what you think might be going on.

And to be clear:  I was deliberately trying to reproduce the reported "DEC oscillation" issue - it was not something I was seeing in my normal guiding logs.

You can see from the logs what my guide settings where, plus I did have the scope slightly camera heavy.  Also, critically, the problems only started happening after the mount had completed it meridian flip (in fact, the problems only started happening about an hour after the flip had completed)

I also had BLC enabled and in the first part of the graph (prior to meridian flip), it appears to be working fine.  After the flip, PHD2 for some reason increased the BLC pulse from ~350ms up to ~500ms.  Not sure why it did this and whether it accounts for the oscillations then seen in DEC.

Anyway, would really like to to get some input on what is going on here.

[Log files and some screen grabs of the graph attached.]

thanks!

Steve

[Steve Winston]

And as requested by a commentator on the CN thread let me clarify:  Mine is an older generation Mach-1 (2006) and does not have the newer spring-loaded work gears.

[bw_msgboard]

Hi Steve.  Just to start with a little kidding, this sounds a bit like “I drove my car into a ditch and I’d like to know why it won’t climb up the bank and get back on the road and why there’s water coming in under the doors.”  J

 

I don’t know whether driving into the ditch was intentional – maybe so – but let’s summarize how you got there:

 

1. You chose to guide close to the horizon.  Before the meridian flip, you had an altitude range of 24 degrees to 28 degrees.  After the meridian flip, you went from 28 degrees to well below 20 degrees, maybe even as low as 15 degrees.  Really?  At a 30 degree altitude, you’re working through 2x the atmosphere that you have at the zenith, so you’re going to be impacted by lots of seeing disturbance.  It also puts the OTA in a nearly horizontal orientation so dec imbalance becomes more important.
2. You did set up with some amount of imbalance in dec as part of your test.
3. All of the testing was done with 1-sec exposures, so the seeing effects are made even worse.
4. The Dec min move was much too low for this sort of situation.  Good dec guiding is characterized by relatively infrequent guide commands and even less frequent direction reversals.  That’s not what your log shows at all, so we can be pretty sure you were over-guiding in Dec for your observing conditions.  I would say the min-move needed to be much larger if you were serious about getting decent guiding.
5. You were issuing dec dither commands throughout the tests – nothing wrong with that – but this tends to make it harder for the system to stabilize when it’s already having trouble
6. You continued to use backlash compensation when it became clear the guiding was not stabilizing.

 

Ok, so all of that would lead me to expect the guiding performance to be poor – which it was.  But we can forge ahead and look at the details of what happened:

 

Here is a typical short sequence showing a few dec reversals when things were really going poorly:

 

 

It starts with a spontaneous large move of 2.5 arc-sec to the south (item 1), not caused by a guide command, but probably a seeing-induced move because of a 20-degree altitude.  Because of the small min-move, PHD2 issued a series of guide pulses to the north including the backlash comp pulse at the start (item 2).  The mount is slow to respond, so multiple pulses are issued.  But the mount eventually over-corrects and goes about 3 arc-sec too far (item 3).  Under normal guiding conditions, we generally interpret this pattern as coming from two things: 1) some amount of backlash and 2) some amount of static resistance (stiction).  The former causes a portion of the initial delay, the second causes the over-correction when the resistance is eventually overcome and the stored energy is released.  I think there are many things that can cause this and there’s no way for us to guess what the underlying problem is.  On the other hand, the argument can be made that *no* guide commands should have been issued for the initial 2.5 arc-sec displacement because it was seeing-induced and would have corrected itself.  In that case the whole problem might be nothing more than chasing the seeing.  I certainly wouldn’t try to draw any conclusions from this experiment.

 

To get good guiding, you want to stay away from these scenarios.  That means using guide parameters that result in few dec reversals and conservative generation of dec guide commands overall.  It’s quite possible that dec backlash compensation made this worse, which is why you should stop using it if you see this behavior.  Backlash compensation can’t correct for stiction because the behavior is unpredictable.  At best, it can handle simple backlash and try to avoid making the problem worse when stiction is present.  That’s why we added the upper and lower limits for the compensation adjustment – if you observe that 300ms works well in most situations, you can set the upper limit to 300ms.  Bottom line, backlash compensation is not a silver bullet and it won’t work for all mounts.  Many people have gotten good results with it on their gear which is why the feature is there.  But if it doesn’t work well for your mount, just don’t use it.

 

Hope this helps,

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.
For more options, visit https://groups.google.com/d/optout.

[Steve Winston]

Hi Bruce,

Thanks for the response!  In my defense, this was more a case of skirting the edge of the ditch rather than intentionally driving straight in ;)

I was imaging M8 in Sagittarius which unfortunately from my location (San Jose, CA) never gets (or stays) too high.  I set the mount up to start imaging around 11pm and keep going (through an automated meridian flip) until the run was finished, all driven by SGP, so I didn't actually see the deteriorating guiding results until the following morning when I looked at the logs (and the non-round stars in my images :)).  

The MinMo and BLC settings I used are what GA recommended - the GA reported backlash was around 330ms, and I assume this also plays into the MinMo recommendation?  Normally I would indeed increase the ceiling (usually to 0.20), but I decided to leave as is for this imaging run.

The interesting part for me was that even with these aggressive guide settings, guiding was good prior to, and for about an hour after, the meridian flip.  Seeing could be a factor due to the lower declination, but then again the RMS values for RA didn't change that much, so I don't think seeing accounts for it.  The orientation of scope could be the issue here - as it approached horizontal I guess it's not surprising to expect bounces in DEC, even with a camera heavy balance.

I'm hoping to have clear skies again tonight to repeat the run, but with less aggressive guide params.  I'll see how that goes.

Again, really appreciate your insights!  My goal is to try understand which specific guiding params or mount configuration can cause oscillations like this so whatever wisdom is learned can be shared with others who might report the same :)

thanks!

Steve

[Steve Winston]

Hi Bruce,

One additional question:  The BLC pulse increased later in the guiding session (automatically done by PHD2).  Wouldn't it have made more sense to reduce the pulse, given that the previous pulses were causing over-shoot and oscillations?  Why was the pulse increased in this case?

And as you suggest, I will try setting the max pulse limit to something equal to or less than my measured backlash, to see if that helps.

thanks!

Steve

[Steve Winston]

Ok, looking through the source code and at the debug logs for BLC, I guess the following happens:  

- When an initial BLC pulse(s) does not correct the DEC deviation, this is measured as an "under shoot" and the BLC pule is increased up to the max limit.

- Backlash is not measured across changes in N/S direction, so currently this is not counted as "over shoot"

- As a result, the current BLC algorithm doesn't see the oscillations in my graphs and so can;t account for them.

e.g. from my debug logs

00:50:02.442 00.000 2372 BLC: Oldest BLC event removed

00:50:02.442 00.000 2372 BLC: Dec direction reversal from North to South, backlash comp pulse of 540 applied

00:50:04.360 00.000 2372 BLC: History state: CurrMiss=1.02, AvgInitMiss=0.68, ShCount=10, LgCount=0, SticCount=0,  Deflections: 0=0.306597, 1:1.017670

00:50:04.360 00.000 2372 BLC: Under-shoot, no adjustment, waiting for more data

00:50:05.921 00.000 2372 BLC: History state: CurrMiss=0.54, AvgInitMiss=0.68, ShCount=10, LgCount=0, SticCount=0,  Deflections: 0=0.306597, 1:1.017670, 2:0.542594

00:50:05.921 00.000 2372 BLC: Under-shoot: nominal increase by 124, window closed

00:50:05.921 00.000 2372 BLC: Pulse increase limited by ceiling of 540

00:50:05.921 00.000 2372 BLC: Pulse adjusted to 540

00:50:07.561 00.000 2372 BLC: Oldest BLC event removed

00:50:07.561 00.000 2372 BLC: Dec direction reversal from South to North, backlash comp pulse of 540 applied

00:50:09.519 00.000 2372 BLC: History state: CurrMiss=1.09, AvgInitMiss=0.70, ShCount=10, LgCount=0, SticCount=0,  Deflections: 0=-0.330401, 1:1.094197

00:50:09.519 00.000 2372 BLC: Under-shoot, no adjustment, waiting for more data

00:50:11.144 00.000 2372 BLC: History state: CurrMiss=-0.04, AvgInitMiss=0.70, ShCount=10, LgCount=0, SticCount=0,  Deflections: 0=-0.330401, 1:1.094197, 2:-0.037755

00:50:11.145 00.001 2372 BLC: No correction, Miss < min_move, window closed

00:50:15.436 00.000 2372 BLC: Oldest BLC event removed

00:50:15.436 00.000 2372 BLC: Dec direction reversal from North to South, backlash comp pulse of 540 applied

Anyway, as you already suggested, I can try reducing the max BLC pulse length to try reduce the chance of over-shooting.

Steve

[bw_msgboard]

Hi Steve.

 

---

From: open-phd...@googlegroups.com [mailto:open-phd...@googlegroups.com] On Behalf Of Steve Winston
Sent: Wednesday, July 04, 2018 3:07 PM
To: Open PHD Guiding
Subject: Re: [open-phd-guiding] DEC oscillations on Mach-1

 

Hi Bruce,

 

Thanks for the response!  In my defense, this was more a case of skirting the edge of the ditch rather than intentionally driving straight in ;)

 

I was imaging M8 in Sagittarius which unfortunately from my location (San Jose, CA) never gets (or stays) too high.  I set the mount up to start imaging around 11pm and keep going (through an automated meridian flip) until the run was finished, all driven by SGP, so I didn't actually see the deteriorating guiding results until the following morning when I looked at the logs (and the non-round stars in my images :)).  

 

Ok, I understand imaging where you have to be. J  But this part of your sky is a miserable place to be doing experiments with guiding parameters…

 

The MinMo and BLC settings I used are what GA recommended - the GA reported backlash was around 330ms, and I assume this also plays into the MinMo recommendation?  Normally I would indeed increase the ceiling (usually to 0.20), but I decided to leave as is for this imaging run.

 

I didn’t see a GA run in the log – when did you do it?  The GA recommendations (which are starting points) are dependent on the sky position and the observing conditions for the night.  And the backlash comp pulse cannot be a constant value, that’s why the backlash comp features in the mount firmware don’t work well – and that’s why the PHD2 backlash comp function changes the value dynamically.  As the Dec gear wears over time, the backlash amount can change substantially from one part of the sky to another.  On my old AP mount, for example, the values can range from near-zero to about 400ms.  And I think it can also be affected by load balance and maybe other things as well.

 

The interesting part for me was that even with these aggressive guide settings, guiding was good prior to, and for about an hour after, the meridian flip.  Seeing could be a factor due to the lower declination, but then again the RMS values for RA didn't change that much, so I don't think seeing accounts for it.  The orientation of scope could be the issue here - as it approached horizontal I guess it's not surprising to expect bounces in DEC, even with a camera heavy balance.

 

Bad seeing can have less effect in RA because there’s no real penalty in reversing direction – that’s not the case in Dec.  If you are imaging at 20 degrees altitude, you will have seeing problems – period.

 

I'm hoping to have clear skies again tonight to repeat the run, but with less aggressive guide params.  I'll see how that goes.

 

If you’re going to be imaging in the same part of the sky, I think you should just try to get a decent image.  Guiding tests aren’t likely to be useful.

 

Again, really appreciate your insights!  My goal is to try understand which specific guiding params or mount configuration can cause oscillations like this so whatever wisdom is learned can be shared with others who might report the same :)

 

You should start by watching for over-aggressive guiding in Dec and frequent Dec reversals – then keep increasing the Dec min-move to get them under control.  Disable backlash compensation if you see problems.

 

thanks!

 

Steve

 

On Wednesday, July 4, 2018 at 1:47:11 PM UTC-7, Bruce Waddington wrote:

Hi Steve.  Just to start with a little kidding, this sounds a bit like “I drove my car into a ditch and I’d like to know why it won’t climb up the bank and get back on the road and why there’s water coming in under the doors.”  J

 

I don’t know whether driving into the ditch was intentional – maybe so – but let’s summarize how you got there:

 

1.      You chose to guide close to the horizon.  Before the meridian flip, you had an altitude range of 24 degrees to 28 degrees.  After the meridian flip, you went from 28 degrees to well below 20 degrees, maybe even as low as 15 degrees.  Really?  At a 30 degree altitude, you’re working through 2x the atmosphere that you have at the zenith, so you’re going to be impacted by lots of seeing disturbance.  It also puts the OTA in a nearly horizontal orientation so dec imbalance becomes more important.

2.      You did set up with some amount of imbalance in dec as part of your test.

3.      All of the testing was done with 1-sec exposures, so the seeing effects are made even worse.

4.      The Dec min move was much too low for this sort of situation.  Good dec guiding is characterized by relatively infrequent guide commands and even less frequent direction reversals.  That’s not what your log shows at all, so we can be pretty sure you were over-guiding in Dec for your observing conditions.  I would say the min-move needed to be much larger if you were serious about getting decent guiding.

5.      You were issuing dec dither commands throughout the tests – nothing wrong with that – but this tends to make it harder for the system to stabilize when it’s already having trouble

6.      You continued to use backlash compensation when it became clear the guiding was not stabilizing.

[bw_msgboard]

It’s not quite that simple.  The compensation algorithm is looking for an over-shoot on the next guide step after the backlash compensation pulse was sent.  If that still results in an under-shoot, the guide pulse *may* be increased based on recent history.  If you look at the data from your first hour after the meridian flip, the blc worked well – any problems you had came from the 2+ arc-sec spontaneous moves in Dec.  Later in the night, it was taking 2-3 additional pulses after the initial blc to restore the guide star, and the original moves were getting larger.  So how long should the compensation algorithm wait to see what to do?  2 more pulses, 3 more pulses, 15 seconds?  I don’t know how you could choose an evaluation window that’s going to work for all mounts under all circumstances.  Whatever the cause of your problem – chasing the seeing or mechanical resistance of some kind – the blc feature isn’t going to fix it.  As I said previously, if you’re going to be trying to guide down in the muck, just disable the blc.

 

Bruce

 

---

From: open-phd...@googlegroups.com [mailto:open-phd...@googlegroups.com] On Behalf Of Steve Winston

Sent: Wednesday, July 04, 2018 7:08 PM
To: Open PHD Guiding

--

[bw_msgboard]

Sorry, a correction – the evaluation window includes the next *2* corrections immediately after the backlash comp pulse is issued.  You’d think I could remember how this works… L

 

Bruce

 

---

[oliv deso]

Hello Guys

I really don't understand why you are keeping fighting with guiding DEC in both direction....

Especially at low altitude (noisy/seeing effect...and with camera heavy.). 

There is nothing spécial with the mach 1 about the DEC. The EQ8, EQ6 and many other wormshaft/gear equiped mounts.

My advice would be : guide as low rate as possible (decrease DEC agressivness) to damp seeing effect and guide in only one direction if you stay close to the mount.

If you operate in an atomated way (remote SGP or else), let the DEC in auto mode, but increase a little bit the minmov. 

-> The goal is to avoid correcting in both dirrection i.e. dealing with backlash

(besides 330ms is pretty short, I have to deal with 10s + with one remote EQ8...and depending of the mount position...so guiding in both DEC directions just does not make any sense with that mount. However guiding in 1 dec direction, results in lower than 0.3" rms and even 0.15" rms when the seeing is good)

Also, for low altitude targets, increase the exposure time. 5svor even 10s is not an problem for the mach1 and other AP mount. This is the benefit of having a good mount. 

this it the way I do since years, but fell free to do like you want. this is just a kindly advice to save your time.

my 2 cents...

Olivier

[Steve Winston]

Hi Bruce,

To answer your earlier question: I generally do calibration and GA while pointed close to the celestial equator and just West of the meridian.  I can try calibrating closer to the target location to see if that changes any of the GA recommendations. Would this alo potentially change other guiding parameters e.g. guide rates or drift?

ANyway, I did another run last night, this time imaging M16 to try stay out of the muck for a bit longer.  Logs are attached (initial calibration and close to 4 hours of guiding).

Some observations:

- GA again recommended MinMo settings of 0.10 in DEC.  Is this just based on the measured backlash or do other factors come into play?  I set MinMo to 0.20 for the guiding run.

- BLC max pulse was set to 300ms

- Similar to my previous logs, the initial guiding went well with RA and DEC RMS staying aligned, and looking at the graph there were no major excursions in DEC

- Once the mount did a meridian flip (around 12:40am), things went bad again

- Large excursions in DEC followed by the repeating South/North swings

- These swings started occurring immediately after the flip, and while M16 was still (relatively) high at 38 degrees and continued through the remainder of the imaging session.

- The pattern of the swings is highly consistent: Initial swing to the South followed by "bounce" to the North.  I couldn't find a single case of an excursion going North first, or two sequential excursions to the South - always a South/North pattern.

- Unlike my previous guiding session, the DEC excursions were fewer and further apart although the amplitude was the same).  Not sure if this was due to less aggressive DEC guiding settings, higher altitude of the target or maybe better seeing.

Given the issues only appear after the meridian flip, it does point to some mount related issue: either stiction, a balance issue in DEC, some cabling dragging etc.  Also, given the repeating and consistent South/North pattern, I don't think this is being triggered by seeing - if that was the case I would expect to see random South or North as the first move.

If the weather cooperates tonight I'll baby-sit it and try see what is going on.

thanks!

Steve

[Steve Winston]

Hi Oliver,

I am running automated via SGP and so have DEC guiding set to Auto.  If you look at the pattern I'm seeing in DEC you will see that it swings South and then North, so unfortunately guiding in only one direction will not work.

Fully agree that the goal is to minimize guiding input and to not chase the seeing.  Again though, if you look at my logs, the guiding setting I have used work well for the initial phase of the guide run and I only see issues after a meridian flip and later in the imaging session.

>However guiding in 1 dec direction, results in lower than 0.3" rms and even 0.15" rms when the seeing is good)

Those are impressive numbers :)  What is your seeing like when getting 0.3 rms?  What star FWHM numbers do you get?  And  do you use a large misalignment in PA to force DEC drift?

Steve

[Steve Winston]

One more data point:

Looking at the both the first and second sets of logs I posted, the measured DEC drift and PA error increase significantly after the meridian flip, going from 1.2'/1.4' before the flip to 9.5'/9.6' after the flip.  I guess this could only be caused by flexure in the mount or tripod? 

The larger PA error would trigger more frequent corrections in DEC, though I doubt they would fit the pattern I see in the logs of "sudden" excursions to the South.

[bw_msgboard]

Hi Steve.  I think you’ve maybe got something fairly basic wrong with your set-up – something in the guide assembly that’s moving around, cable problems, something like that.  Here’s an example of three large Dec excursions after the meridian flip:

 

 

In all three cases, there was no guiding being done at the time of the excursion, so the Dec motor wasn’t even running.  So I don’t see how this is likely to be either a guiding or a mount problem – more likely something that moves around or pulls after the meridian flip.

[Brian Valente]

(I debated whether to start a new thread on this or not so let me know if you feel it’s better to start a new one)

 

Interestingly I had a nearly identical experience the last few nights with the G11 – guide and debug log here:

https://www.dropbox.com/s/9usfczf3tdlj73k/PHD2_GuideLog_2018-07-04_195433.zip?dl=0

 

 

Short overview:

 

Guiding along nicely around 0.7” (once you remove the spikes that are from pausing during focus/reacquiring star)

 

 

With settling/reacquisition removed from analysis:

 

 

After meridian flip, completely different story esp. with DEC – what a mess!

 

 

 

I’m not proposing that there is an issue with PHD. I don’t know what is the issue

 

But I do find it’s interesting that we seem to share very similar symptoms across different mounts. I find it pretty unlikely that we both had cable snags, etc. that would result in exactly the same behavior, though I have seen stranger things, so I’m not ruling that out

 

 

Thanks

 

Brian

 

 

Brian Valente

Brianvalentephotography.com

[Steve Winston]

Ok, Brian, you're graph wins ;)

On the surface it does appear to be similar behavior, if a bit more extreme.  Are you automated or were you sitting with it when it happened?

And fwiw I have run my mount manually through a range of motions and didn't see anything close to a cable snag (or any of the cables even approaching "tight").  I will be babysitting it tonight (weather permitting) to try see what might be going on after the flip.

[Steve Winston]

Hi Bruce,

It's possible.  I'll take a closer look next guide session and try figure out what's going on.  thanks!

Steve

[bw_msgboard]

Hi Brian.  Well, yes, that is certainly a mess. L  In this case I think we can rule out any effects from backlash comp because you had a ceiling set at 100ms.  So you’re seeing the full effects of the large amount of backlash in the mount and probably considerable stiction as well.  So the initial blc of 100ms is just lost in the noise, there’s evidently many seconds of corrections needed to get the axis moving.  It seems to me that this whole mess got started with a huge deflection in both RA and Dec at 00:36.  The RA stabilized fairly quickly but you could make an argument that the Dec never recovered from the initial 7.5 a-s excursion.  I wonder what would have happened if you had simply stopped guiding and let things stabilize and then resumed.  Also, your situation looks a bit different to me because there are never any intervals where the dec is stabilized and no or few guide pulses are being generated.  Those (short) intervals of no guiding do show up in Steve’s log, but your log shows continuous guide pulses with no breaks.

 

I can’t say what’s going on with the mount here.  FWIW: when you do a meridian flip in the south, the Dec axis is probably going to rotate by as much as 180 degrees, so I think the worm wheel will be operating in a completely different section.  The backlash/stiction behavior there could be quite different from other areas of the gear, the ones you customarily operate in.

 

Bruce

 

---

[bw_msgboard]

Hi again Steve.  I realized I didn’t answer your first set of questions:

 

---

From: open-phd...@googlegroups.com [mailto:open-phd...@googlegroups.com] On Behalf Of Steve Winston

Sent: Thursday, July 05, 2018 8:29 AM

To: Open PHD Guiding
Subject: Re: FW: [open-phd-guiding] DEC oscillations on Mach-1

 

Hi Bruce,

 

To answer your earlier question: I generally do calibration and GA while pointed close to the celestial equator and just West of the meridian.  I can try calibrating closer to the target location to see if that changes any of the GA recommendations. Would this alo potentially change other guiding parameters e.g. guide rates or drift?

 

You always want to calibrate near the celestial equator but you can run the GA wherever you want, including close to your target Dec. The only benefit in doing that would be to get a different sampling of the seeing.  On that front, we have some concerns that the current GA estimates for min-moves are too aggressive and we’re experimenting with some changes in that area.  Looking at your GA run with the test code, it looks like a min-move of 0.3 might have been warranted.  That won’t block reaction to the big Dec moves of 1-1.5 pix but it could help to restrict the sequences of successive guide pulses. That said, I don’t think it would have much effect on your current problem.  

 

Just to come back to something I said to Brian, your situation looks very different from his.  Even though you can see these saw-tooth behaviors in Dec, the reversals are separated by 10-30 seconds of good tracking with few or zero guide pulses issued.  So the guiding was actually doing a pretty good job of recovering from each individual excursion without generating immediate over-shoots:

 

 

The real problem, I think, is why these big excursions are happening in the first place.

 

Bruce

 

 

[Steve Winston]

Thanks Bruce - agreed that the standard MinMoves are too optimistic.

>The real problem, I think, is why these big excursions are happening in the first place.

And fully agreed.  Unfortunately I'm clouded out tonight so it will have to wait for tomorrow night before I can do some more testing.

[Brian Valente]

Thanks for the feedback Bruce – here are a couple thoughts:

 

I don’t think it’s due to large backlash -

 

At higher backlash compensation values, the back-and-forth actually gets quite a bit worse if you can believe it. I’m talking high like 1500ms

(although GA reports that it could never finishes backlash compensation test check)

 

it’s a spring-loaded worm. I’ve spent quite a bit of time ensuring that part of the hardware is setup properly. so in theory there really shouldn’t be much backlash if at all

 

and I would expect to see something resembling this kind of behavior on the other side of the pier, so all these to me don’t point to large backlash (not ruling it out, just thinking through it here)

 

It’s possible there is some stiction

 

I have a working theory that spring-loaded worms don’t behave in the same way as non-spring loaded worms, and may respond differently as well.

 

One thought is that it may build up stiction on one side or the other and cause some of this behavior.

 

It’s nothing more than a notion right now, but I’m going to test a few things tonight and see how it goes

 

And again, the strange part is radically different results depending on one side of the pier or the other.

 

I have a few tests planned tonight, weather permitting.

 

Thanks

 

Brian

 

 

Brian Valente

Brianvalentephotography.com

 

[Steve Winston]

Hi Bruce,

One additional question while I'm waiting for clear skies :)

Looking in the debug logs I see the following kind of response after each guide correction:

22:53:03.747 00.036 12552 PulseGuide returned control before completion, sleep 356

Is this just because it's working asynchronously or is it pointing to a real problem with the mount not completing the requested move?

A more complete sequence looks like:

22:53:03.690 00.000 12552 BLC: Dec direction reversal from North to South, backlash comp pulse of 300 applied

22:53:03.690 00.000 12552 MoveAxis(S, 381, ABG)

22:53:03.690 00.000 12552 Guiding  Dir = 1, Dur = 381

22:53:03.710 00.020 12552 IsSlewing returns 0

22:53:03.711 00.001 12552 IsGuiding returns 0

22:53:03.747 00.036 12552 PulseGuide returned control before completion, sleep 356

22:53:04.104 00.357 12552 IsGuiding returns 1

22:53:04.104 00.000 12552 scope still moving after pulse duration time elapsed

22:53:04.145 00.041 12552 IsSlewing returns 0

22:53:04.146 00.001 12552 IsGuiding returns 0

22:53:04.146 00.000 12552 scope move finished after 381 + 54 ms

22:53:04.146 00.000 12552 Move returns status 0, amount 381

22:53:04.146 00.000 12552 move complete, result=0

thanks!

Steve

[bw_msgboard]

This is all normal.  The ASCOM standard allows either synchronous or asynchronous pulse-guiding – the AP ASCOM driver, like many others, does asynch.  So PHD2 has to figure it out which it is by waiting for the pulse-guide call to return and then seeing if “IsGuiding” is true.  If so, it then polls the mount until IsGuiding returns false.  Nothing to worry about.

[Steve Winston]

Ok - thanks!  I'll stop looking through the debug logs now ;)

[bw_msgboard]

Hi Brian.  I think you bring up a good point here.  I think we get into trouble when we try to apply mechanical labels to these events, which is what I was doing.  Since we’re working way up at an application level, all we can say with any accuracy is what the app did and what it saw in response.  Trying to take things down to the mechanical level is really just guess work.  I don’t think you can really diagnose the problem without opening up the gear system and doing hardware-level measurements of what happens when you reverse directions.

 

So let’s back up and summarize what we *can* say about what your mount was doing.  Picking a typical example, let’s see what was required to correct from a 5 px Dec deflection.  Using the measured calibration rate of 9.66 px/sec, the correction should have needed a pulse of 0.52 sec or 520ms.  But the data show it took 19.5 seconds, 19513 ms, before the guide star position was restored.  So something was seriously interfering with the mount’s ability to move the axis in the desired direction.  But of course the axis didn’t stop moving when the guide pulses stopped, it continued to swing to the north by a nearly equal amount.  And we can see these reversals are different from north-to-south vs south-to-north.  The north to south reversals show a sharp peak at the reversal point while the south to north reversals are flatter and more rounded. 

 

 

We have seen this sort of crazy behavior with a couple of other mounts that subsequently went back to the manufacturer.  In those cases, the verdict was that the gear system was way over-tightened and so much binding was occurring that any direction reversal became a nightmare of force building up in areas that were never intended to see such force.  No one was using terms like “stiction” in those cases, the terms were somewhat more demonstrative. J

 

You said again that you find it very strange that the behavior varies based on side-of-pier.  That was my point about the position of the worm gear – it’s changing substantially when you do a meridian flip at that pointing position.  Let’s suppose you had picked a particular point in the worm gear/worm wheel phase and did a perfect job of removing backlash.  What’s to say that is going to be equally perfect in all other positions?  We know the worm wheel teeth will have machining errors, the entire wheel may be out-of-round, the worm wheel may not be perfectly concentric with the shaft it turns, etc. I think those are some of the reasons that some amount of gap (backlash) is needed.  I know you have a spring-loaded worm which should help with these things but it can’t respond perfectly.

 

Have you talked to Losmandy about this latest series of events?  Maybe you should consider backing off on the mesh to see if the behavior changes.

 

Good luck,

[Brian Valente]

Hi Bruce

 

Clouds foiled me last night, so I couldn’t do some testing

 

I recognize what that data looks like to PHD – PHD is basically a response mechanism, not an instigator, right? so it’s not creating these oscillations, only trying to adjust when they arrive (or in the case of PPEC when PHD thinks it may arise).

 

And yes, I agree that kind of graph below typically indicates shows stiction, or huge backlash, or something outside the realm of PHD’s control, so certainly the software is only giving us a glimpse into what’s happening and we’re not trying to debug PHD here.

 

But was is confusing and troubling to me is that hardware should generally be repeatable. Given the same set of circumstances it should respond in more or less the same fashion.

 

Here the only difference seems to be side of pier, and yet the response is radically different. I have to test more to see if it is indeed side of pier-specific, or if it’s something about side of pier only after a meridian flip. The second option does not sound plausible, and yet that’s what it appears to be, but I need further testing to help isolate the repeatability.

[Steve Winston]

Ok - finally got some clear skies last night so I sat with the mount for some hours trying to figure out what is going on.  Initial calibration and the the main tracking logs are attached.

Exec. summary:

- The DEC excursions are not "triggered" by cable drag or anything "external" interfering with the mount

- Small MinMo (i.e. aggressive guiding) triggers more frequent oscillations.  

- Larger MinMo settings (i.e. "not guiding" in DEC most of the time) works a lot better, but can still occasionally result in large DEC oscillations

- Still have no idea of the root cause :) but my top two guesses right now would be:

1: Stiction in DEC resulting in initial delay and then over-correction by PHD2

2: Some weird feedback loop/bug in PHD2 guide pulses that only happen on one side of the meridian

Prep work:

- Completely tore down my imaging set-up (it's my "portable" rig, so good practice :)

- Re-did all cables to ensure no stress points or possibilities of snags

- Discovered some play in APs mount-pier adapter (high-precision rotating pier base).  Basically the two plates that the adapter is made from had some wiggle.  This was removed by tightening up two set-screws on on the side of the adapter.

- Re-balanced in DEC to only have a very slight camera heavy imbalance

- Removed some "wiggle" from the main cog in the DEC gear train

- Confirmed that there is no obvious "stiction" in DEC on either side of meridian by spinning gears by hand (APs recommended procedure for ensuring gears/worm are not too tight) 

Looking at the guide graph:

I started off with the same parameters I had used the previous night (MinMo = 0.20, BLC enabled and set to 300ms etc).  I imaged and guided on M16 with the scope on the West side of the meridian.  As before the initial guiding went without any problems.  

At 12:26am SGP did its automated meridian flip and within 2 minutes the DEC oscillations had started.  I let this run until about 12:40 before starting to change any of the settings

12:40: Disabled Backlash compensation.  Had no obvious effect - continued to see oscillations

12:46: Reduced MinMo from 0.20 to 0.10.  The more aggressive MinMo resulted in more frequent oscillations

12:55:  Increased MinMo to 0.40.  At this point I also removed the motor cover on DEC so I could watch what was happening! (hence the large excursions in DEC and RA at this point :).  With MinMo set to 0.40 however, guiding stays within the seeing limits and DEC oscillations disappear.

01:01: Reduced MinMo back down to 0.20.  

01:02: Reduced MinMo back down to 0.10.  Immediately start to see oscillations again

01:04: Increased MinMo back up to 0.30.  Oscillations stop

01:06: MinMo back down to 0.10.  Oscillations start again

01:08: MinMo back up to 0.30.  Oscillations stop etc

For the remainder of the graph I played about with a bunch of settings but without any improvement: 

- Log #3: Turned guiding off to determine drift direction, tried guiding South only, 

- Log #5: Switched to Hysteresis guide algorithm on DEC.  

For the last section of the log (#6) I switched the scope back to the West side (reverse Meridian flip) just to confirm that these issues were still not seen on the other side of the mount, and they were not.

As mentioned above, I had removed the motor cover so I could watch what was going on.  During the DEC excursions/corrections, I could clearly see the gears moving in response to PHD2 input.  As best I can tell there was no obvious stiction in the gears - they appeared to be moving freely.  To test this I stopped guiding for a short period, removed the power from the motor (needed to free up the servo motor), and could easily move the gears by hand - I couldn't feel any stiction or resistance.

Conclusions:

- With low aggression guiding settings (large MinMo), I don't see large DEC excursions or oscillations.  This tells me that the initial excursions are not being triggered by an external input like cable dragging or some weight shifting.  If it was an external input then it would not be influenced by the guide settings (which are just reactive).

- The oscillations are triggered only after PHD2 issues the initial corrective corrective guide pulse (e.g. due to seeing).  With aggressive MinMo, seeing more frequently triggers PHD2 guide corrections and this in turn results in more oscillations.
- The size of the triggering corrective guide pulse doesn't seem to matter:  I see oscillations with BLC enabled (large initial pulse) or BLC disabled (usually small initial guide pulse)

As mentioned at the start, the only guesses I have right now are:

1: Stiction in DEC resulting in initial delay and then over-correction by PHD2

2: Some weird feedback loop/bug in PHD2 guide pulses that only happen on one side of the meridian

As described above, I've done everything I can to try verify that it is not stiction (gears easily rotate using one finger, not resistance felt).  I think the only additional test I have left there would be to significantly loosen the DEC worm/gear mesh (at the cost of backlash).

The feedback bug also seems unlikely, but who knows ;)? I don't know how well correlated the guide plot and corrective pulse "pillars" are plotted in the graph, but even looking back through my previous graphs it appears that the "spike" in the DEC oscillations occurs in response to the first corrective guide pulse from PHD2 i.e. there's a (usually) small initial excursion, followed by corrective pulse, followed by much large DEC excursion in the wrong (opposite to the corrective pulse) direction!  But maybe that's just my imagination :)

Anyway - running out of ideas here :).  If you have any additional tests I could try to narrow this down that would be greatly appreciated.  And I can also make the full debug log available if that helps.

many thanks!!

Steve

[Brian Valente]

Steve i'm working on something similar, and for me i believe it boils down to stiction. I think PHD is doing what it's supposed to do, but the mount is not responding as it should. I don't know exactly what is the issue either for me, but i'll share as I progress

B

--
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.
For more options, visit https://groups.google.com/d/optout.

--

Brian 

Brian Valente

portfolio brianvalentephotography.com 

[bw_msgboard]

Hi guys.  FWIW, I don’t think these two problems are the same because the symptoms are quite different at the detailed level.  So I would be very careful about making this assumption until you’ve actually identified the root causes.

 

Just my 2-cents,

Bruce

 

---

From: open-phd...@googlegroups.com [mailto:open-phd...@googlegroups.com] On Behalf Of Brian Valente
Sent: Sunday, July 08, 2018 10:29 AM
To: Steve Winston
Cc: Open PHD Guiding
Subject: Re: FW: [open-phd-guiding] DEC oscillations on Mach-1

 

Steve i'm working on something similar, and for me i believe it boils down to stiction. I think PHD is doing what it's supposed to do, but the mount is not responding as it should. I don't know exactly what is the issue either for me, but i'll share as I progress

 

B

[Brian Valente]

agreed - Aside from my larger problems, I still think it's worth comparing notes because even when it was working well, i had dec oscillations on one side of the pier, so.... maybe similarities, maybe not

B

[bw_msgboard]

Hi Steve, sorry you’re having so much trouble with this.  I think we got off to a bad start with your original post which tied what you’re seeing to a bunch of other stuff that is quite likely unrelated  At the time you said you had created the problem intentionally, but now it seems you can’t make it go away. J  So I think we need to hit the reset button and trouble-shoot this in a systematic way.  That means stripping things back to the barest essentials and dedicating some “engineering time” with the scope.  That means no imaging, just manual control of the whole process, and execution of some more carefully crafted experiments.  I think we’re past the point of hoping to find a silver bullet that will make this all go away, so the first order of business is to find and eliminate the abrupt 2-4 arc-sec Dec moves you see after the meridian flip.  It’s quite possible there are two issues that ultimately need to be resolved: 1) what’s causing the big star excursions and 2) why the guiding doesn’t stabilize once they do occur.

 

I understand why you might reason that this could be some kind of PHD2 problem because of the meridian flip dependency.  So let me address that first.  The only thing PHD2 does at the time of a meridian flip is to mathematically flip the calibration data – that’s all.  That transform has been in place for as long as PHD2 has and when it doesn’t work, you get run-away guiding.  But in the interest of stripping things to their barest essentials, you can eliminate this – just force a new calibration after a meridian flip.

 

Looking back through all your posts, I don’t think we know what your physical guiding configuration is.  We know it’s a 514mm scope but is it a separate guide scope?  Or is it some kind of OAG assembly on your main scope?   Just to set a baseline, a 4 arc-sec excursion on your system translates to a 1.35 px displacement.  That will show up if the guide camera shifts by 10 microns – a human hair is something like 50 microns thick.  With a guide scope, this can be caused by a tiny shift in any of the myriad components of the assembly – camera, adapter tubes, focuser assembly, tube mounting rings, etc. etc.  You are likely to have a hard time seeing a 10 micron shift by just looking at things.  If you have threaded set-screws, especially the delrin-tipped ones used for some mounting rings, you will be vulnerable to this sort of thing.  It’s just something to keep in mind.  Why am I harping on this?  Because a meridian flip is a big deal in terms of the mechanics of the system.  The gravitational loading on all the components changes, the gear angle between the worm and the worm wheel changes, etc.  And the motion of the scope from one side to the other puts all these little mechanical interfaces and fastening points under a full range-of-motion test.  There are times when I wonder how any of this can ever work – but it does. J

 

So here’s what I suggest for doing some engineering tests:

1. Eliminate SGP, dithering, and anything to do with imaging.
2. Reset all of the PHD2 values to their defaults and don’t change them
3. Disable backlash compensation and leave it disabled.
4. Start the first test at a declination of -15 degrees Dec with the scope on the west side of the pier, about where you were last night
5. Run a calibration
6. Start a guiding sequence and let it run for 10 minutes.  Your data show that should be long enough to see the spikes.
7. Do a meridian flip to the same Dec and approximately the same hour angle from the meridian.  The scope should be on the east side, still pointing about 30-40 degrees above the horizon.
8. Do another calibration
9. Run a 10-minute guiding sequence, changing nothing.  Hopefully, the spikes will show up at this point.
10. Now repeat steps 4-9 but with the declination at your current latitude value – in other words, pointing nearly straight up with respect to north-south.
11. Then repeat steps 4-9 with the scope pointing to the north at an elevation about 40 degrees above the horizon.

 

Let us know what you see, we’ll try to help you interpret it.  If you’re using a separate guide scope, also send us a photo that shows the various attachment points.

 

Hope this helps,

Bruce

 

 

 

---

From: open-phd...@googlegroups.com [mailto:open-phd...@googlegroups.com] On Behalf Of Steve Winston
Sent: Sunday, July 08, 2018 9:01 AM
To: Open PHD Guiding
Subject: Re: FW: [open-phd-guiding] DEC oscillations on Mach-1

 

Ok - finally got some clear skies last night so I sat with the mount for some hours trying to figure out what is going on.  Initial calibration and the the main tracking logs are attached.

--

[Steve Winston]

Hi Bruce,

Yep was just thinking I should calibrate/guide independently on each side to what happens. 

Firstly, my setup is as follows:  TEC-140 + Riccardi x0.75 reducer + SBIG STF-8300 + SBIG OAG + Filter wheel.  Everything is threaded together, including directly to the focuser via a Precise Parts adapter.  Guide camera is the SBIG STi which is a potential weak spot in that it is held in place in the OAG using two delrin tipped screws.  That said, it's as tight and secure as I can make it and the USB cable from the guide camera is well secured after a small loop to prevent drag etc.

Given the excursions appear to be triggered by seeing even when DEC is not being actively guided (and can be "controlled" by changing the MinMo sensitivity), I guess I'm still skeptical it's anything moving in the imaging train, but you never know :)

I will certainly go through the steps below - the main reason I was keeping SGP in the picture is that it manages the meridian flip - I haven't actually found any other way to trigger the mount to perform a flip, other than manually moving it via the hand-controller (which is what I did at the end of last nights session to re-test with the scope on the East side of the mount)

Once question:  When doing a Meridian flip SGP (as best I can tell) issues a "pause" via the server interface to PHD2.  Is this equivalent to me hitting the Stop button?, which is what I will have to do during the manual flip.  The one big differene I can see is that doing a Stop also requires me to restart Looping, select guide star etc, and this is different from what SGP appears to be doing (although I guess after a flip it also needs to reacquire a new guide star, so maybe not so different).  I guess I just want to make sure that hitting Stop won;t cause PHD2 to dump data/information that it might be keeping/using based on a pause from SGP.

And thanks for explaining  what happens after the flip (PHD2 transforms the calibration data).  So all other "historical data" it may have gained during the previous hour+ guiding is wiped and it is basically starting fresh?

Will update you all after tonight's testing.

And once again, thanks for the awesome support in helping me debug this! :).

Steve 

[Brian Valente]

Steve

>> doing a Stop also requires me to restart Looping, select guide star etc, and this is different from what SGP appears to be doing

SGP meridian flip reacquires a guidestar and restarts guiding. I haven't had any issues on that, so whatever the mechanism, PHD<->SGP for meridian  flip connection seems to work fine here

B

[bw_msgboard]

Hi Steve, see below.

 

---

From: open-phd...@googlegroups.com [mailto:open-phd...@googlegroups.com] On Behalf Of Steve Winston
Sent: Sunday, July 08, 2018 12:04 PM
To: Open PHD Guiding
Subject: Re: FW: [open-phd-guiding] DEC oscillations on Mach-1

 

Hi Bruce,

 

Yep was just thinking I should calibrate/guide independently on each side to what happens. 

 

Firstly, my setup is as follows:  TEC-140 + Riccardi x0.75 reducer + SBIG STF-8300 + SBIG OAG + Filter wheel.  Everything is threaded together, including directly to the focuser via a Precise Parts adapter.  Guide camera is the SBIG STi which is a potential weak spot in that it is held in place in the OAG using two delrin tipped screws.  That said, it's as tight and secure as I can make it and the USB cable from the guide camera is well secured after a small loop to prevent drag etc.

 

Given the excursions appear to be triggered by seeing even when DEC is not being actively guided (and can be "controlled" by changing the MinMo sensitivity), I guess I'm still skeptical it's anything moving in the imaging train, but you never know :)

 

I will certainly go through the steps below - the main reason I was keeping SGP in the picture is that it manages the meridian flip - I haven't actually found any other way to trigger the mount to perform a flip, other than manually moving it via the hand-controller (which is what I did at the end of last nights session to re-test with the scope on the East side of the mount)

 

If you don’t have a planetarium program, you’ll have to slew with the hand-controller.  

 

Once question:  When doing a Meridian flip SGP (as best I can tell) issues a "pause" via the server interface to PHD2.  Is this equivalent to me hitting the Stop button?, which is what I will have to do during the manual flip.  The one big differene I can see is that doing a Stop also requires me to restart Looping, select guide star etc, and this is different from what SGP appears to be doing (although I guess after a flip it also needs to reacquire a new guide star, so maybe not so different).  I guess I just want to make sure that hitting Stop won;t cause PHD2 to dump data/information that it might be keeping/using based on a pause from SGP.

 

The ‘pause’ is different from ‘stop’ but not in any way that matters for your testing – there’s no way in the UI to trigger a ‘pause’.  There is no guiding history kept in this case so doing a manual stop, loop, auto-select, guide won’t result in any different state information.  As you say, the guide star has to be re-acquired from scratch and everything is reset.

 

And thanks for explaining  what happens after the flip (PHD2 transforms the calibration data).  So all other "historical data" it may have gained during the previous hour+ guiding is wiped and it is basically starting fresh?

 

Yes, that’s true for everything except PPEC, which is irrelevant to your situation.

 

Will update you all after tonight's testing.

 

And once again, thanks for the awesome support in helping me debug this! :).

 

You’re welcome.  But I’ll feel a lot better when we figure this out… J

 

Steve 

On Sunday, July 8, 2018 at 11:25:39 AM UTC-7, Bruce Waddington wrote:

Hi Steve, sorry you’re having so much trouble with this.  I think we got off to a bad start with your original post which tied what you’re seeing to a bunch of other stuff that is quite likely unrelated  At the time you said you had created the problem intentionally, but now it seems you can’t make it go away. J  So I think we need to hit the reset button and trouble-shoot this in a systematic way.  That means stripping things back to the barest essentials and dedicating some “engineering time” with the scope.  That means no imaging, just manual control of the whole process, and execution of some more carefully crafted experiments.  I think we’re past the point of hoping to find a silver bullet that will make this all go away, so the first order of business is to find and eliminate the abrupt 2-4 arc-sec Dec moves you see after the meridian flip.  It’s quite possible there are two issues that ultimately need to be resolved: 1) what’s causing the big star excursions and 2) why the guiding doesn’t stabilize once they do occur.

 

I understand why you might reason that this could be some kind of PHD2 problem because of the meridian flip dependency.  So let me address that first.  The only thing PHD2 does at the time of a meridian flip is to mathematically flip the calibration data – that’s all.  That transform has been in place for as long as PHD2 has and when it doesn’t work, you get run-away guiding.  But in the interest of stripping things to their barest essentials, you can eliminate this – just force a new calibration after a meridian flip.

 

Looking back through all your posts, I don’t think we know what your physical guiding configuration is.  We know it’s a 514mm scope but is it a separate guide scope?  Or is it some kind of OAG assembly on your main scope?   Just to set a baseline, a 4 arc-sec excursion on your system translates to a 1.35 px displacement.  That will show up if the guide camera shifts by 10 microns – a human hair is something like 50 microns thick.  With a guide scope, this can be caused by a tiny shift in any of the myriad components of the assembly – camera, adapter tubes, focuser assembly, tube mounting rings, etc. etc.  You are likely to have a hard time seeing a 10 micron shift by just looking at things.  If you have threaded set-screws, especially the delrin-tipped ones used for some mounting rings, you will be vulnerable to this sort of thing.  It’s just something to keep in mind.  Why am I harping on this?  Because a meridian flip is a big deal in terms of the mechanics of the system.  The gravitational loading on all the components changes, the gear angle between the worm and the worm wheel changes, etc.  And the motion of the scope from one side to the other puts all these little mechanical interfaces and fastening points under a full range-of-motion test.  There are times when I wonder how any of this can ever work – but it does. J

 

So here’s what I suggest for doing some engineering tests:

1.      Eliminate SGP, dithering, and anything to do with imaging.

2.      Reset all of the PHD2 values to their defaults and don’t change them

3.      Disable backlash compensation and leave it disabled.

4.      Start the first test at a declination of -15 degrees Dec with the scope on the west side of the pier, about where you were last night

5.      Run a calibration

6.      Start a guiding sequence and let it run for 10 minutes.  Your data show that should be long enough to see the spikes.

7.      Do a meridian flip to the same Dec and approximately the same hour angle from the meridian.  The scope should be on the east side, still pointing about 30-40 degrees above the horizon.

8.      Do another calibration

9.      Run a 10-minute guiding sequence, changing nothing.  Hopefully, the spikes will show up at this point.

10.  Now repeat steps 4-9 but with the declination at your current latitude value – in other words, pointing nearly straight up with respect to north-south.

11.  Then repeat steps 4-9 with the scope pointing to the north at an elevation about 40 degrees above the horizon.

[Steve Winston]

Hi Bruce,

Logs attached.

Couple of notes:

- I started with the scope on the East side of the mount (not the West side as you requested) as East is the side I'm seeing issues on.

- The first log (scope on East side) also includes a GA run, but the DEC oscillations are there and visible.

- Calibration with scope pointed North (log #7) failed (as expected...?) as there wasn't enough West movement 
- At the end of the logs I went back to the starting point with scope on the East side, re-did calibration (log #8) and let run for a couple of minutes (additional  to what you requested below).

thanks!

Steve

<span style='fon

[bw_msgboard]

Hi Steve, now I think we’re getting somewhere.  But I think we are missing some important data.  With the tests I had in mind, you should have ended up with 6 guiding sequences – in your cases last night, those would have been on both the east and west sides at Dec targets of around -10, 36, and then much higher.  I realize the northernmost position was no good, you were clear up by the pole and couldn’t calibrate (my mistake).  But that should have resulted in 4 guiding sequences and I only see 3.  The critical missing case is the one with the scope pointing straight up and running on the east side of the pier.  I think we need to fill in those missing holes.  These tests confirm that PHD2’s adjustment of the calibration for meridian flip works fine so there’s no need to keep re-calibrating.  So let’s try this:

 

1. Go to the straight-up position, west side of pier, do one good calibration, and let it run.  After it has guided for 10 minutes, do a GA run right in that position.  This will be your only calibration, let’s not waste any more time on those.
2. Flip the scope to the east side of the pier but don’t recalibrate.  Just guide for 10 minutes, then let the GA run in that position.
3. Slew to a Dec location of 60 degrees, west side of pier, no re-calibration.  Let it guide for 10 minutes, then let the GA run.
4. Flip to the east side, no re-calibration, let it guide, then let the GA run.

 

The GA run you did at 21:42 was quite helpful, that was good – and that’s why I’m asking for GA runs in the other locations.  I realize this is a PITA but I think it can help us understand what’s going on.

 

Regards,

--

[Steve Winston]

Thanks Bruce - and sorry, misunderstood what you were looking for.

I'll grab the rest of the data tonight.

- The DEC excursions are not "triggered" by cable drag or anything "external" interfering with the mount</p

[bw_msgboard]

If you want to continue to do some imaging to the south, once all the test data have been collected you could try this:  set your Dec min-move to 0.4 and increase your guide exposure to 2 secs.  Let’s see if that can help smooth things out.

 

Bruce

 

---

From: open-phd...@googlegroups.com [mailto:open-phd...@googlegroups.com] On Behalf Of Steve Winston
Sent: Monday, July 09, 2018 8:11 AM
To: Open PHD Guiding
Subject: Re: FW: [open-phd-guiding] DEC oscillations on Mach-1

 

Thanks Bruce - and sorry, misunderstood what you were looking for.

I'll grab the rest of the data tonight.

On Monday, July 9, 2018 at 7:58:58 AM UTC-7, Bruce Waddington wrote:

Hi Steve, now I think we’re getting somewhere.  But I think we are missing some important data.  With the tests I had in mind, you should have ended up with 6 guiding sequences – in your cases last night, those would have been on both the east and west sides at Dec targets of around -10, 36, and then much higher.  I realize the northernmost position was no good, you were clear up by the pole and couldn’t calibrate (my mistake).  But that should have resulted in 4 guiding sequences and I only see 3.  The critical missing case is the one with the scope pointing straight up and running on the east side of the pier.  I think we need to fill in those missing holes.  These tests confirm that PHD2’s adjustment of the calibration for meridian flip works fine so there’s no need to keep re-calibrating.  So let’s try this:

 

1.      Go to the straight-up position, west side of pier, do one good calibration, and let it run.  After it has guided for 10 minutes, do a GA run right in that position.  This will be your only calibration, let’s not waste any more time on those.

2.      Flip the scope to the east side of the pier but don’t recalibrate.  Just guide for 10 minutes, then let the GA run in that position.

3.      Slew to a Dec location of 60 degrees, west side of pier, no re-calibration.  Let it guide for 10 minutes, then let the GA run.

4.      Flip to the east side, no re-calibration, let it guide, then let the GA run.

--

[Steve Winston]

Hi Bruce,

Guide logs attached for the scenarios you outlined below.

Let me know if it's what you need or if you need additional logs.

thanks,

Steve

[Steve Winston]

And an additional question coming out of the discussion on the Y! AP GTO group:

Is the Peak Error reported in the Guiding Assistants results the absolute max error seen above or below the zero line? Or is it the max peak-2-peak value?

Not sure if you follow that forum at all, but the general conclusion from Roland is that MinMove should be set to 60-80% of the observed DEC peak.

Obviously PHD2 currently recommends a much more aggressive MinMove.

thanks!

Steve

[bw_msgboard]

If you hover the mouse over a *label* in the GA grid, you’ll see a tool-tip describing what the entry means.  In the case of the ‘Declination, peak’ entry, you’ll see:

 

"Maximum sample-sample deflection seen in declination."

 

 

Bruce

---

From: open-phd...@googlegroups.com [mailto:open-phd...@googlegroups.com] On Behalf Of Steve Winston
Sent: Tuesday, July 10, 2018 9:55 AM
To: Open PHD Guiding
Subject: Re: FW: [open-phd-guiding] DEC oscillations on Mach-1

 

And an additional question coming out of the discussion on the Y! AP GTO group:

 

Is the Peak Error reported in the Guiding Assistants results the absolute max error seen above or below the zero line? Or is it the max peak-2-peak value?

 

Not sure if you follow that forum at all, but the general conclusion from Roland is that MinMove should be set to 60-80% of the observed DEC peak.

 

Obviously PHD2 currently recommends a much more aggressive MinMove.

 

thanks!

 

Steve


On Monday, July 9, 2018 at 11:13:21 PM UTC-7, Steve Winston wrote:

Hi Bruce,

 

Guide logs attached for the scenarios you outlined below.

 

Let me know if it's what you need or if you need additional logs.

 

thanks,

 

Steve

On Monday, July 9, 2018 at 8:11:20 AM UTC-7, Steve Winston wrote:

Thanks Bruce - and sorry, misunderstood what you were looking for.

I'll grab the rest of the data tonight.

On Monday, July 9, 2018 at 7:58:58 AM UTC-7, Bruce Waddington wrote:

Hi Steve, now I think we’re getting somewhere.  But I think we are missing some important data.  With the tests I had in mind, you should have ended up with 6 guiding sequences – in your cases last night, those would have been on both the east and west sides at Dec targets of around -10, 36, and then much higher.  I realize the northernmost position was no good, you were clear up by the pole and couldn’t calibrate (my mistake).  But that should have resulted in 4 guiding sequences and I only see 3.  The critical missing case is the one with the scope pointing straight up and running on the east side of the pier.  I think we need to fill in those missing holes.  These tests confirm that PHD2’s adjustment of the calibration for meridian flip works fine so there’s no need to keep re-calibrating.  So let’s try this:

 

1.      Go to the straight-up position, west side of pier, do one good calibration, and let it run.  After it has guided for 10 minutes, do a GA run right in that position.  This will be your only calibration, let’s not waste any more time on those.

2.      Flip the scope to the east side of the pier but don’t recalibrate.  Just guide for 10 minutes, then let the GA run in that position.

3.      Slew to a Dec location of 60 degrees, west side of pier, no re-calibration.  Let it guide for 10 minutes, then let the GA run.

4.      Flip to the east side, no re-calibration, let it guide, then let the GA run.

--

[Steve Winston]

Thanks - so peak-to-peak then?

[bw_msgboard]

Well, maybe we can make do with this but perhaps you don’t see what we’re trying to accomplish.  To see how the guiding is affected by the loading and the side of pier, we wanted data that looks like this:

 

South, west-side

South, east-side

Straight up, west-side

Straight up, east-side

North, west-side

North, east-side

 

AFAIK, we’ve never seen any data in the north (highlighted below).  But as I say, maybe we can try to work with what we have, which is 4 out of the 6 desired pointing positions.

 

I think we also haven’t gotten a photo of your guide scope assembly and, in general terms, how you set up each night – on a solid surface, on a balcony, on a deck, etc.  The better we understand the complete picture, the more likely we’ll be able to understand what we see.

 

Bruce

 

---

From: open-phd...@googlegroups.com [mailto:open-phd...@googlegroups.com] On Behalf Of Steve Winston
Sent: Monday, July 09, 2018 11:13 PM
To: Open PHD Guiding
Subject: Re: FW: [open-phd-guiding] DEC oscillations on Mach-1

 

Hi Bruce,

 

Guide logs attached for the scenarios you outlined below.

 

Let me know if it's what you need or if you need additional logs.

 

thanks,

 

Steve

On Monday, July 9, 2018 at 8:11:20 AM UTC-7, Steve Winston wrote:

Thanks Bruce - and sorry, misunderstood what you were looking for.

I'll grab the rest of the data tonight.

On Monday, July 9, 2018 at 7:58:58 AM UTC-7, Bruce Waddington wrote:

Hi Steve, now I think we’re getting somewhere.  But I think we are missing some important data.  With the tests I had in mind, you should have ended up with 6 guiding sequences – in your cases last night, those would have been on both the east and west sides at Dec targets of around -10, 36, and then much higher.  I realize the northernmost position was no good, you were clear up by the pole and couldn’t calibrate (my mistake).  But that should have resulted in 4 guiding sequences and I only see 3.  The critical missing case is the one with the scope pointing straight up and running on the east side of the pier.  I think we need to fill in those missing holes.  These tests confirm that PHD2’s adjustment of the calibration for meridian flip works fine so there’s no need to keep re-calibrating.  So let’s try this:

 

1.      Go to the straight-up position, west side of pier, do one good calibration, and let it run.  After it has guided for 10 minutes, do a GA run right in that position.  This will be your only calibration, let’s not waste any more time on those.

2.      Flip the scope to the east side of the pier but don’t recalibrate.  Just guide for 10 minutes, then let the GA run in that position.

3.      Slew to a Dec location of 60 degrees, west side of pier, no re-calibration.  Let it guide for 10 minutes, then let the GA run.

4.      Flip to the east side, no re-calibration, let it guide, then let the GA run.

--

[Steve Winston]

>Slew to a Dec location of 60 degrees, west side of pier, no re-calibration.  Let it guide for 10 minutes, then let the GA run.

Sorry - didn't interpret this as requesting both South and North.  I'll grab that tonight.

re: setup - the mount is on an eagle tripod on a solid patio.  The set-up has been in place for a couple of weeks now - I don't dismantle/rebuild each night.  I have tweaked polar alignment on several nights.

If it helps I can grab all 6 scenarios tonight to make sure the data is consistent.

And I'll upload a pic once we hit half time in the France/Belgium match :)

4.      </spa

[Steve Winston]

[bw_msgboard]

There’s no need to repeat all of the tests – we’re just looking at east vs. west, at the same Dec positions on the same night.  To get the north tests, just re-use the calibration you already have, don’t re-calibrate at the northernmost position (something like Dec = 60).

 

Andy suggested another test we might run which shouldn’t take very long.  Slew back to the overhead position with the scope on the west side.  Start guiding and let things stabilize – again, no backlash compensation, just the settings we’ve been using for these tests.  Now we want to force some large Dec excursions to see how the mount responds.  You do this by using the Manual Guide tool:

 

 

Set the pulse duration field to 500.  With PHD2 guiding normally, click on the north button and try to get the guide star to move by 1-2 px.  If the backlash hasn’t been cleared, you may need to click it twice.  Once you see the guide star move by a decent amount, let the guiding stabilize– we want to see how things respond to the guide commands.  After things have stabilized, click the *south* button, probably just once, and watch for the guide star to move in the opposite direction by a sizable amount.  Let the guiding stabilize.  Repeat this alternate north/south manual guide pulsing a few times.  You want to see something that looks like this in the guiding graph (green is Dec on this system):

 

 

Once this is done, flip to the other side of the pier, still pointing nearly straight up, and repeat the process.  Again, the first manual guide pulse you do may not move the guide star enough depending on backlash.  But once you get the first one done, the alternative north/south guide pulses shouldn’t be affected by backlash.  On the east side, where you’re having trouble, be sure to let things run for at least 30 seconds after each manual pulse – we want to see if we can duplicate this slow-period back-and-forth motion on the axis.

 

Good luck,

--

[bw_msgboard]

Thanks for the pics.  Wow, that is sure one long lever arm on that system…

--

[Steve Winston]

Ok - I finally got to looking at my data from last night guiding at 2s and MinMove of 0.40.  It looks pretty good :)

One caveat being that this was imaging NGC7000, which is basically straight up from my location when it crosses the meridian, and that has been my least problematic orientation for the mount.  So, I'll repeat with those guide setting again tonight on M16 or M8 to see if it also has a positive result.

Another fun night ahead :)

[Bryan]

Steve

By any chance to do you have more counterweights?  More weights closer to the mount is better.

See A-P guidance at http://www.astro-physics.com/products/accessories/mounting_acc/Balance_to_Optimize_Guiding.pdf

Bryan

On Tuesday, July 10, 2018 at 12:54:27 PM UTC-6, Steve Winston wrote:

[Steve Winston]

Hi Bryan,

I do have additional weights and I might try them after this current round of testing.

Of course, I'm not seeing any issues in RA and I don't think the position of the weight is affecting DEC.

Steve

[Steve Winston]

Hi Bruce,

Here is the first log with the following:

Straight up, west-side

Straight up, east-side

South, west-side

South, east-side

North, west-side

North, east-side

I had to re-do two of the GA runs (in the first failure the selected star was too close to the edge and backlash failed, and in the second it PHD mistakenly switched to a hot pixel during backlash measurement which also caused it to fail.

If you need more/different data, let me know.

BTW: There were certainly some significant differences in PA, backlash and reported PE for the different positions.  Looking forward to hearing your analysis of what is going on.

Will work on the manual guiding logs now.

Steve

<p class=MsoNormal style='mso-margin-top-

[Steve Winston]

And here's the log with the manual guide pulses on West and East side of the mount.

Steve

[Eric Dreher]

I've been following this thread and its sister on CN.

I must've missed the guide log at ~.40 min/mo.  Did you try that yet?

[Steve Winston]

Hi Eric,

Yep I now have two imaging runs with MinMo set to 0.40.  Log from last night attached.

It does indeed seem to be behaving better - the overall RMS values aren't great (bad seeing, object pretty low) but RA and DEC are mostly aligned throughout the guiding session.

The only small caveat from last night's run is that M8 had already crossed the meridian when I started imaging, so there was no meridian flip during the session.  Still, the imaging was done with the scope on the East side of the mount which is my "problem" side when using a more aggressive MinMo.

Steve

[Steve Winston]

BTW: There are still a couple of spots in the log that look like the old DEC "oscillation" e.g. at the 3:00am mark.

And I've no idea what happened in RA at the 2:05am mark (15 arc-second spike!) - maybe a bat landed on the c/w ;)

I don't know if you have also been following the discussion on the Y! group.  If Ray's analysis is correct that this is some external factor like a strained cable, then the less aggressive MinMove settings are really just "hiding" the root problem, not solving it.

Steve

[bw_msgboard]

Thanks, Steve, this is quite useful.  I plan to spend the time tonight trying to pull this all together and tell you as much as I can.  The manual guide pulse test was quite interesting.  At the risk of driving you nuts, could you possibly repeat the manual-guide-pulse test at a southern pointing position?  Your southern position last night was around 7 degrees Dec, so that area would be fine.  I’d just like to see the manual pulse behavior at that pointing position to compare it with what you got last night pointing straight up.   

 

Thanks,

--

[Steve Winston]

Sure - I can grab the manual pulse log for South.  Should I just go ahead and grab North too while I'm at it :>?  That test doesn't take long.

Also, I was planning to overhaul my DEC worm/wheel today: remove the motor + worm housing, clean and re-grease everything, re-adjust the worm/wheel mesh.  I can put that off by a day if you would prefer the new data to be captured with the current DEC behavior.  Let me know!

and thanks!

Steve

[bw_msgboard]

For my purposes,  it would be best to hold off on the Dec overhaul for one more day if you don’t mind.  That way we reduce the number of free variables.  Doing the manual-guide-pulse test in the north would be great if you feel like doing an “extra credit” project.

--

[Steve Winston]

No problem - will hold off on the overhaul for a couple of days and will go for the extra credit :)

3.    &

[Steve Winston]

Hi Bruce,

Logs attached.  Definitely some interesting things going on when pointed North.

Steve

[Steve Winston]

BTW: DEC axis to focal plane is (very!) roughly 21 inches / 533mm.

[bw_msgboard]

Thanks, Steve, I think this should cover it.  I’ll try to get you a write-up by the end of the day.

--

[bw_msgboard]

Hi Steve.  I’m attaching my analysis of all the tests you submitted and hope that it can help you out.  At this point, I think I’ve gotten as much out of the data as I can and can’t hand you a silver bullet for a solution.  If you decide to pursue this directly with A-P, I think you now have a factual basis for the discussion.  I’m happy to answer questions, if needed, but I don’t think there’s any more I can do at this point.

 

Good luck with it,

--

[Steve Winston]

Hi Bruce,

First let me say a big thank you for taking the time and effort to analyze the data and put together this report - really appreciated!

There are a couple of recommendations in there I can try out and the analysis will be useful if I decide to take this further with AP.  I did the tear down of the mount today, cleaned and re-greased DEC and re-set the worm mesh, so I'll see if that has any impact.  I also noticed some mechanical play between the DEC and RA sections of the mount (grabbing the end of the c/w bar it is possible to move it up/down ever so slightly).  Not sure if this play between is having an impact , and if it is why it would only affect one side of the mount.  Something to discuss with AP I guess.

One question on the data I gathered last night.  In the last test sequence with the scope on the East side and pointing North, I noticed that when a guide pulse was issued for DEC, the RA graph moved (by a smaller amount) in the opposite direction on the graph.  This happened for each DEC guide pulse issued.  It seems that corrections in DEC  were having some torsional effect on RA.

As you know I had previously done an imaging run with MinMove set to 0.4 and last night I did a run set to 0.3 and the results looked good (again, this was for a high altitude target where DEC issues are reduced).  Anyway, it seems that with sufficiently relaxed guiding parameters I can avoid these issues.  As you point out in the report though, it's not actually getting at the root cause of the issues, which as an engineer bugs the hell out of me :).

One other question:  The MinMoves being suggested by GA continue to be on the "aggressive" side (in one of last nights calibration runs it suggested 0.10 for both DEC and RA).  Do you have any plans to look into this or do these settings generally work for other users / other mounts?  I know they are just suggestions and users will need to tweak them themselves, but certainly for beginners it might make more sense to err on the side of caution.

Overall I can't thank you guys enough for the support and the great tool you have made available for us - if you ever find yourselves in San Jose I owe you some beers! :)

thanks!

Steve

Hi Bruce,

<span sty

[bw_msgboard]

 

 

---

From: open-phd...@googlegroups.com [mailto:open-phd...@googlegroups.com] On Behalf Of Steve Winston
Sent: Thursday, July 12, 2018 10:40 PM
To: Open PHD Guiding
Subject: Re: FW: [open-phd-guiding] DEC oscillations on Mach-1

 

Hi Bruce,

 

First let me say a big thank you for taking the time and effort to analyze the data and put together this report - really appreciated!

 

There are a couple of recommendations in there I can try out and the analysis will be useful if I decide to take this further with AP.  I did the tear down of the mount today, cleaned and re-greased DEC and re-set the worm mesh, so I'll see if that has any impact.  I also noticed some mechanical play between the DEC and RA sections of the mount (grabbing the end of the c/w bar it is possible to move it up/down ever so slightly).  Not sure if this play between is having an impact , and if it is why it would only affect one side of the mount.  Something to discuss with AP I guess.

 

One question on the data I gathered last night.  In the last test sequence with the scope on the East side and pointing North, I noticed that when a guide pulse was issued for DEC, the RA graph moved (by a smaller amount) in the opposite direction on the graph.  This happened for each DEC guide pulse issued.  It seems that corrections in DEC  were having some torsional effect on RA.

 

This can happen, we’ve seen it on a few mounts.  In at least one case I know of, it was related to looseness in a bearing.  When we have seen it, it was causing guiding problems in RA.  I did see this in the test you’re talking about but it appears on both sides of the pier - and remember, these were sizable guide pulses.   Since none of this matched the symptoms of the problem you’re fighting, I didn’t want to deflect you. J

 

As you know I had previously done an imaging run with MinMove set to 0.4 and last night I did a run set to 0.3 and the results looked good (again, this was for a high altitude target where DEC issues are reduced).  Anyway, it seems that with sufficiently relaxed guiding parameters I can avoid these issues.  As you point out in the report though, it's not actually getting at the root cause of the issues, which as an engineer bugs the hell out of me :).

 

One other question:  The MinMoves being suggested by GA continue to be on the "aggressive" side (in one of last nights calibration runs it suggested 0.10 for both DEC and RA).  Do you have any plans to look into this or do these settings generally work for other users / other mounts?  I know they are just suggestions and users will need to tweak them themselves, but certainly for beginners it might make more sense to err on the side of caution.

 

Yes, we’re already working on it and it will appear in the 2.6.5 dev path.  It’s sometimes hard to maintain momentum when there’s a lot of forum support activity. J

 

Overall I can't thank you guys enough for the support and the great tool you have made available for us - if you ever find yourselves in San Jose I owe you some beers! :)

 

No problem, please let us know where you end up with all this.

 

Bruce

--

[Brian Valente]

Bruce

 

Following up this, I did manage to solve my problem and I’m guiding regularly around 0.6-0.7” which is fab. I have to run some more tests but there is some very unusual (yet repeatable) responsiveness with the spring-loaded worm I haven’t seen before.

 

 

Brian

 

portfolio https://www.brianvalentephotography.com/

 

From: bw_msgboard [mailto:bw_m...@earthlink.net]
Sent: Sunday, July 8, 2018 10:43 AM
To: 'Brian Valente' <bval...@gmail.com>; 'Steve Winston' <steve....@gmail.com>
Cc: 'Open PHD Guiding' <open-phd...@googlegroups.com>
Subject: RE: FW: [open-phd-guiding] DEC oscillations on Mach-1

 

Hi guys.  FWIW, I don’t think these two problems are the same because the symptoms are quite different at the detailed level.  So I would be very careful about making this assumption until you’ve actually identified the root causes.

 

Just my 2-cents,

Bruce

 

---

From: open-phd...@googlegroups.com [mailto:open-phd...@googlegroups.com] On Behalf Of Brian Valente
Sent: Sunday, July 08, 2018 10:29 AM
To: Steve Winston
Cc: Open PHD Guiding
Subject: Re: FW: [open-phd-guiding] DEC oscillations on Mach-1

 

Steve i'm working on something similar, and for me i believe it boils down to stiction. I think PHD is doing what it's supposed to do, but the mount is not responding as it should. I don't know exactly what is the issue either for me, but i'll share as I progress

 

B

 

On Sun, Jul 8, 2018 at 9:01 AM Steve Winston <steve....@gmail.com> wrote:

Ok - finally got some clear skies last night so I sat with the mount for some hours trying to figure out what is going on.  Initial calibration and the the main tracking logs are attached.

 

Exec. summary:

- The DEC excursions are not "triggered" by cable drag or anything "external" interfering with the mount

- Small MinMo (i.e. aggressive guiding) triggers more frequent oscillations.  

- Larger MinMo settings (i.e. "not guiding" in DEC most of the time) works a lot better, but can still occasionally result in large DEC oscillations

- Still have no idea of the root cause :) but my top two guesses right now would be:

1: Stiction in DEC resulting in initial delay and then over-correction by PHD2

2: Some weird feedback loop/bug in PHD2 guide pulses that only happen on one side of the meridian

 

 

Prep work:

- Completely tore down my imaging set-up (it's my "portable" rig, so good practice :)

- Re-did all cables to ensure no stress points or possibilities of snags

- Discovered some play in APs mount-pier adapter (high-precision rotating pier base).  Basically the two plates that the adapter is made from had some wiggle.  This was removed by tightening up two set-screws on on the side of the adapter.

- Re-balanced in DEC to only have a very slight camera heavy imbalance

- Removed some "wiggle" from the main cog in the DEC gear train

- Confirmed that there is no obvious "stiction" in DEC on either side of meridian by spinning gears by hand (APs recommended procedure for ensuring gears/worm are not too tight) 

 

Looking at the guide graph:

I started off with the same parameters I had used the previous night (MinMo = 0.20, BLC enabled and set to 300ms etc).  I imaged and guided on M16 with the scope on the West side of the meridian.  As before the initial guiding went without any problems.  

 

At 12:26am SGP did its automated meridian flip and within 2 minutes the DEC oscillations had started.  I let this run until about 12:40 before starting to change any of the settings

 

12:40: Disabled Backlash compensation.  Had no obvious effect - continued to see oscillations

12:46: Reduced MinMo from 0.20 to 0.10.  The more aggressive MinMo resulted in more frequent oscillations

12:55:  Increased MinMo to 0.40.  At this point I also removed the motor cover on DEC so I could watch what was happening! (hence the large excursions in DEC and RA at this point :).  With MinMo set to 0.40 however, guiding stays within the seeing limits and DEC oscillations disappear.

01:01: Reduced MinMo back down to 0.20.  

01:02: Reduced MinMo back down to 0.10.  Immediately start to see oscillations again

01:04: Increased MinMo back up to 0.30.  Oscillations stop

01:06: MinMo back down to 0.10.  Oscillations start again

01:08: MinMo back up to 0.30.  Oscillations stop etc

 

For the remainder of the graph I played about with a bunch of settings but without any improvement: 

- Log #3: Turned guiding off to determine drift direction, tried guiding South only, 

- Log #5: Switched to Hysteresis guide algorithm on DEC.  

 

For the last section of the log (#6) I switched the scope back to the West side (reverse Meridian flip) just to confirm that these issues were still not seen on the other side of the mount, and they were not.

 

As mentioned above, I had removed the motor cover so I could watch what was going on.  During the DEC excursions/corrections, I could clearly see the gears moving in response to PHD2 input.  As best I can tell there was no obvious stiction in the gears - they appeared to be moving freely.  To test this I stopped guiding for a short period, removed the power from the motor (needed to free up the servo motor), and could easily move the gears by hand - I couldn't feel any stiction or resistance.

 

Conclusions:

- With low aggression guiding settings (large MinMo), I don't see large DEC excursions or oscillations.  This tells me that the initial excursions are not being triggered by an external input like cable dragging or some weight shifting.  If it was an external input then it would not be influenced by the guide settings (which are just reactive).

- The oscillations are triggered only after PHD2 issues the initial corrective corrective guide pulse (e.g. due to seeing).  With aggressive MinMo, seeing more frequently triggers PHD2 guide corrections and this in turn results in more oscillations.
- The size of the triggering corrective guide pulse doesn't seem to matter:  I see oscillations with BLC enabled (large initial pulse) or BLC disabled (usually small initial guide pulse)

As mentioned at the start, the only guesses I have right now are:

1: Stiction in DEC resulting in initial delay and then over-correction by PHD2

2: Some weird feedback loop/bug in PHD2 guide pulses that only happen on one side of the meridian

 

As described above, I've done everything I can to try verify that it is not stiction (gears easily rotate using one finger, not resistance felt).  I think the only additional test I have left there would be to significantly loosen the DEC worm/gear mesh (at the cost of backlash).

The feedback bug also seems unlikely, but who knows ;)? I don't know how well correlated the guide plot and corrective pulse "pillars" are plotted in the graph, but even looking back through my previous graphs it appears that the "spike" in the DEC oscillations occurs in response to the first corrective guide pulse from PHD2 i.e. there's a (usually) small initial excursion, followed by corrective pulse, followed by much large DEC excursion in the wrong (opposite to the corrective pulse) direction!  But maybe that's just my imagination :)

 

Anyway - running out of ideas here :).  If you have any additional tests I could try to narrow this down that would be greatly appreciated.  And I can also make the full debug log available if that helps.

 

many thanks!!

 

Steve

On Friday, July 6, 2018 at 10:32:32 AM UTC-7, Steve Winston wrote:

Ok - thanks!  I'll stop looking through the debug logs now ;)

On Friday, July 6, 2018 at 10:07:39 AM UTC-7, Bruce Waddington wrote:

This is all normal.  The ASCOM standard allows either synchronous or asynchronous pulse-guiding – the AP ASCOM driver, like many others, does asynch.  So PHD2 has to figure it out which it is by waiting for the pulse-guide call to return and then seeing if “IsGuiding” is true.  If so, it then polls the mount until IsGuiding returns false.  Nothing to worry about.

 

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.
For more options, visit https://groups.google.com/d/optout.

 

--

Brian 

 

 

 

Brian Valente

portfolio brianvalentephotography.com 

[Steve Winston]

Hi Brian,

Great to hear. What did you do to resolve your issues?

Thanks!

Steve.