EQ6, PHD and the 10.2 sec period

[MarkS]

Instead of continuing the hijack of Chris's thread I'm starting a fresh one here.

Last night I ran PECPrep to analyse the guiding errors causing the elongated stars on my EQ6 which was using PHD and pulsed guiding through EQMOD.

Once PHD was clibrated and logging switched on, I used PECPrep to analyse Periodic Error with the guiding pulses switched OFF. PECPrep indicated that one of the biggest contributions to the total PE was the teeth on the stepper drive transfer which has a period of 10.2 seconds.

So then I used PECPrep to analyse Periodic Error with the guiding pulses switched ON.  PECPREP then showed that this same 10.2 second period was by far the biggest contribution to the residual guiding error.

I was using a 1 second integration time on the guide cam and the default PHD hysteresis/aggressiveness settings (whatever values they are).   

From a mathematical point of view (control loops, lag, feedback etc) it is very interesting to discover that the guiding could not, or would not, correct an important contributor to the periodic error.

This high amplitude 10.2 sec period may be just a feature of my mount, maybe not.  But since PECPrep lists the exact cause of this frequency I imagine that it is very common for EQ6 users.  I'll try my NEQ6 mount and see if I find the same issue.

Maybe a particular combination of PHD settings can correct for this.  Maybe a PHD source code change can be applied but I would need to first understand the existing logic.

In any case I see this as an interesting result and an interesting challenge to fix it.  At long focal lengths, my stars will be the better for it.

[Ivor]

I shall follow this thread with interest as its an area I need to spend more time on. I was advised a while ago to use a 2 sec integration time on the EQ6 as it isn't responsive enough to cope with less; certainly a variable to play with.

[JohnP]

Mark why don't you try posing these questions direct to the authors of PHD I'm sure with their deep understanding of the coding of the prog they will be able to assist you. I also look forward to following your findings as it looks like i am also going down eq6, pulseguide & PHD2 route..

[Rocket Pooch]

What I would do is measure the PE and plot a graph 1st so you can see if you have smooth PE or rough PE for a few worm periods, if on visual inspection its all over the shop you have a build issue.  The issues are all well documented and easy to fix.

The issue with looking at the finest detail in this context of PEC analysis is its going to get you off on a tangent, with these mounts you will get I think 4 gear cycles on analysis, some of these will be noisy.  

However a well adjusted mount is ok, for example if you put that thing Jim bought on an EQ6 you can pretty much drive the mount down to sub arc second without guiding, with the existing the gears and motors, so there's no real design issue with an EQ6.

What I found with my EQ6, remember me and Mike had the 1st batch in the UK, was the build quality was an issue so I have to spend some time to get the PE to a smooth sign wave, then I could guide at most FL.

Have a look at this its interesting http://stargazerslounge.com/topic/119826-eq6-belt-drive-modification/page__st__80

[The Thing]

PHD2 is open source, you can get the code, it's a tidied up version of 1.14.x https://code.google.com/p/open-phd-guiding/

[MarkS]

Agreed, what Jim has, Telescope Drive Master is an interesting idea but look at its performance on an EQ6:
http://www.telescopehouse.com/acatalog/info_0721000.html

Very interestingly, the resulting graph is dominated by the same 10.2 second oscillation that is annoying me.  Maybe the corrections are not being applied sufficently frequently?  TDM on the EQ6 would work really well for short to medium focal lengths but maybe not good enough for imaging at 1500mm.

I've taken a look at the PHD code - it's algorithm is very straightforward.  I've also performed a spreadsheet simulation of the algorithm which shows me that PHD guiding speed needs to be 0.5 second or preferably 0.25 second to remove this 10.2sec oscillation.  However, at that guiding speed you end up "chasing the seeing" and the net result is that guiding performance actually gets worse (at least on the average turbulent night around here).

Anyway, I believe it's perfectly feasible to add a module to PHD that monitors the guiding accuracy, performs a Discrete Fourier Transform (but not an FFT) to identify the 10.2sec oscillation (this would need approx 60 seconds of data) and then start sending periodic error corrections every half second to cancel it out.  It would then continue to monitor the guiding to check the cancellation is working, and if not, recompute an adjustment to the phase and amplitude of the corrections - this would be a continual process.  Once the corrections are being applied, the guiding speed could be reduced to 2 seconds or maybe more.

This is all straightforward stuff.  In fact, so straightforward that I can't believe it hasn't been tried before.  And I guess the result must have been a failure otherwise it would already be available out there somewhere.

So, if it was a failure, then almost certainly it was because of what Chris said - the first thing to do is to perform some serious maintenance on the internals of the EQ6 otherwise there are simply too many residual random spikes and oscillations that will still wreck guiding even with the 10.2 second cycle removed. 

I still fancy giving it a go though - it appeals to my mathematical curiousity

[mickw]

Woooooshhhhhhh 

[JohnP]

Double wooshhhhh....

[MarkS]

Come on you guys, it's easy:
A mount has regular repeating errors in tracking called periodic error caused by inadequate manufacturing tolerances. 
Some of this tracking error happens too fast for the guiding to cope with and standard PEC (periodic error correction) can't correct it either.
So the idea is to correct it using a different method. 
The only bit that's slightly clever is that I believe it is possible to do this "automagically" inside the guiding software itself.

I also think that my idea won't work because otherwise people far cleverer than me would already have done it.

But I'm going to try anyway!

[Rocket Pooch]

AA5 has both a bad seeing and high frequency guiding algorithms in the code selectable.

I'd still however would like to see the spike, do you know what cog is causing the problem.

[JohnP]

Mark - I understand what you are saying the bits that wooosshhhed over my head were:

I've also performed a spreadsheet simulation of the algorithm which shows me that PHD guiding speed needs to be 0.5 second or preferably 0.25 second to remove this 10.2sec oscillation.

feasible to add a module to PHD that monitors the guiding accuracy, performs a Discrete Fourier Transform (but not an FFT) to identify the 10.2sec oscillation (this would need approx 60 seconds of data) and then start sending periodic error corrections every half second to cancel it out.  I

[Mike]

If a model of the oscillations can be carefully recorded can this not be applied along with the guiding corrections (i.e. deducted from the guiding corrections)? Would this not be just what PEC is doing though?

[Rocket Pooch]

Isn't this called PemPro?

[The Thing]

Isn't this called PemPro?

No.

[Rocket Pooch]

 

You sure

"PEMPro Version 2. With PEMPro Version 2 you can now correct your mounts periodic error"