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.
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.
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..
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
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/ (https://code.google.com/p/open-phd-guiding/)
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 ;-)
Woooooshhhhhhh :o
Double wooshhhhh....
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!
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.
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
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?
Isn't this called PemPro?
:lol:
You sure
"PEMPro Version 2. With PEMPro Version 2 you can now correct your mounts periodic error"
Quote from: 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?
No - Because the 10.2 second period does not divide into the length of one worm gear rotation, PECPrep cannot correct it. Here, for completeness, is the comment I made on the other thread:
"Well I played with PECPrep until the clouds came over. Ultimately EQMOD's Periodic Error Correction is no different to any other PEC and so is a big disappointment. PECPrep itself is very powerful - it does a Fast Fourier Transform analysis to break down the periodic error into its component frequencies. This is very informative - it shows (in my case) the worm gear contributes about 30% of the error. The rest is due to other gears in the chain and it helpfully lists the frequencies associated with each gear. But EQMOD can't correct for the other gears in the chain because PECPrep can only generate a PEC file of exactly one worm rotation long.
Under such circumstances (i.e. where the majority of the periodic error is produced not by the worm gear), any approach that uses the information gleaned from a few worm cycles to produce a "one worm gear rotation" correction chart used for all future cycles, is doomed to failure. In fact it will actually amplify the periodic error a few cycles further on (but they don't tell you that in the small print!)."
Quote from: Rocket Pooch
do you know what cog is causing the problem.
I haven't go the info with me but I now find it is a common issue. Do a seach on EQ6 and 10.2 and you'll find discussions related to this exact issue and which gear causes it. losmandy has a similar problem with a 26 or 27sec cycle.
Mark there is a company in Germany called Gierlinger that make high quality gear and worm replacements for telescope mounts.
http://www.gierlinger.cc/
Might be worth researching them.
There is also aeroquest.
http://www.aeroquest-machining.com/
Another option would be to have all of the worms and gears taken out and lapped.
Hmm, surely the time is the primary cog, but I still don't understand the issue.
Quote from: Rocket Pooch
Hmm, surely the time is the primary cog, but I still don't understand the issue.
I don't fully understand the mechanical issue either. Maybe teeth not precisely manufactured or some kind of play between primary cog and next in chain. All I know is that it produces an oscillation of approx 1 arcsec amplitude according to PECPrep. Apparently caused by each successive tooth engaging and disengaging.
If you want a play, you can download the PHD logs here. EQ6 mount: guide cam had 5.2 micron pixels and focal length of guidescope 300mm.
http://www.markshelley.co.uk/webdisk/PHD_log_09Sep13_unguided.txt
http://www.markshelley.co.uk/webdisk/PHD_log_09Sep13_guided.txt
This is one of the reasons people do a belt drive mod (http://www.tavcso.hu/?o=termek&te=EQ6bord&n=en) on their Skywatcher mounts. Other suppliers are available! I've been tempted. Now I've replaced all the bearings with SKF fine tolerance ones (C1 - C2 is standard, C3 is wobbly) it may be the next improvement to be made.
Update - found this one. http://www.alphageek.co.uk/page22.html (http://www.alphageek.co.uk/page22.html) £110 for both axes. I suspect if you did this and replaced the worm and the big clutch gear bit with better made parts you may have most of a solution.
Surprised at how cheap that mod is
one of the tightest tolerances with gears is the distance between the centres. The involute shape (assuming that's the chosen profile (and I can think of no good reason why it would be anything else)) is a fantastic piece of design because done correctly the faces of the teeth do not move in relation to each other. But only if the gears mesh correctly.
If the hobbing tool was worn when the gear was cut, no amount of adjustment will fix it. If cost was less of a concern, helical gears help because there is no clear moment when one tooth engages and disengaged from the next.
My idea of adaptive PEC ran into lots of subtle problems of which the biggest 4 problems were:
1) Accounting for drift (which varies hour by hour)
2) Accounting for flexure (which also varies with the hourly position)
3) Pulsed guiding is not a good way of dealing with PE - the Variable Speed PEC built into EQMOD is far superior
4) Once the 10.2sec cycle is removed, there are lots of others that also need removing.
So I'm trying a new tack:
After 36 worm periods (1/5 of a sidereal day i.e. slightly less than 4.8 hours) all the gears (except the main ring which rotates only once every sidereal day) will be back in their starting position.
This gives a potential way forward using EQMOD's VS-PEC. But at present I can't persuade EQMOD to accept a 5 hour PEC file. It loads it and displays it but it repeatedly uses the first worm cycle of data from the file.
Maybe I need to define a custom mount within EQMOD that has a worm cycle of 36*50133.33 stepper motor steps instead of the EQ6 50133.33 steps.
Watch this space ...
Just a thought.
That sounds like a good idea but. and there is always a but.
How will you know that all your gears are in the correct starting positions before you start to correct the PEC.
by that i mean
at what point is position one? when every gear is in the correct starting position and all the backlash has been taken up,
not forgetting that you can unlock the clutch to move the mount away from the position of the main gear,
so there is no direct reference to position one and the position of the mount itself.
If you unlock the mount and move it 90 deg, the worm and gears have not changed so how do you know your gears are in the correct starting position is what im trying to say.
How much backlash (number of steps) will you need to account for whilst changing direction and is this repeatable.
As for the PEC file for EQ mod,
is there not a programmable interface for EQmod to allow you to send your own PEC corrections from your own software.
You might as well write your own to make use of your own PEC File and just leave EQMod to carry on with the guiding pulses
Mac.
The answer to all your points Mac is that if the mount is exclusively used via EQMOD and you always park the scope before switching off then EQMOD always knows the position of the Right Ascension worm since the mount is always under its full control and it counts pulses to the stepper motor. There also exists a "timestamp" button in EQMOD to allow it to correlate the start of a PE recording to the PE correction file that is generated from this recording - the PE correction file has 2 main columns - worm position (in steps) and RA correction in arcsecs.
Even if you unclutch the drives and swing the scope around, it still knows the worm position because they remain unchanged, so PEC can still work correctly.
I don't think there is a program interface giving fine control over the VS-PEC beyond adjusting phase and gain of a loaded PEC file.
BTW I did some calculations on the necessary accuracy of the teeth in the main RA ring gear. Assuming the ring gear is 15cm in diameter, then a 350nm error in the shape or position of a tooth will lead to a 1 arcsec deviation in RA tracking. Yes, 350nm, the wavelength of blue light!
It gives an idea of the engineering tolerances required to get good tracking.
I'm making progress on this. As usual, as in all things related to astro-imaging, there is a whole lot of misinformation out there.
The first point to clear up is that, contrary to popular belief, the 10.2 second period does actually divide into the worm period. When running at sidereal rate the worm gear has a rotation period of 478.689 seconds and the "single tooth period" is more accurately 10.185 which divides into it exactly 47x - i.e. the number of teeth on the gear driving the worm. A prime number! Why on earth? Let's not go down that path of questioning. The ring gear of 180 teeth is driven by the worm which is driven by the 47(!!!) tooth gear, which is driven by the 36 tooth transfer gear which is driven by the 12 tooth motor gear. Since each gear has its own imperfections this 12:47 ratio results in a non-repeatable PE graph. Here is an example of 4.5 worm cycles of my EQ6. Horizontal scale is seconds (of time) and the vertical is tracking error in arcseconds.
(http://www.markshelley.co.uk/webdisk/EQ6_PE1.jpg)
This was recorded by PERecorder using a webcam running at 10 frames/sec i.e. at a micro-level the spikes may well be related to the astronomical seeing rather than mechanical imperfections. The important thing to note is that the PE does not repeat from worm cycle to worm cycle. In fact it takes 36 rotations of the worm before the 12, 36 and 47 tooth gears are all back in their starting position. Who designs this stuff?
Why on earth? Let's not go down that path of questioning.
Now, the stepper motor has 200 steps per rotation which are further divided into 64 microsteps. Now since the final ring gear has 180 teeth it means then counting through the chain of gears it means there are precisely 9024000 microsteps per full rotation which takes 86164.091 seconds (the length of a sidereal day). So that is 104.7304 microsteps/second. Now EQMOD is very clever in that it keeps track of the microstep counter - as long as you go through the usual Park/Unpark shenanigans. And woe betide you if you suffer a power cut, a PC freeze-up or forget to Park/Unpark before exiting EQMOD. EQMOD has to then start afresh with a new starting count because the EQ6 mount has no idea of its gear positions.
Now, if you use PERecorder via EQMOD then it record your PE against the total microstep number. This is really clever. Here are two plots of PE I produced a few days apart (red line and blue line), simply by slewing the motors back to the same microstep count:
(http://www.markshelley.co.uk/webdisk/EQ6_PE2.jpg)
So even though the PE does not repeat from worm cycle to worm cycle, two PE charts do line up reasonably well if they both start at the same microstep count - because the gears are all back in the same position. So I produced a smoothed PEC chart from PERecorder (the yellow line) that I could use in EQMOD. The 10.185sec cycle is pretty obvious on the yellow line. And it shows that the same 10.185 cycle in the red and blue lines is also in sync.
But things fall apart when you try to use this PEC. EQMOD, PERecorder and PECPrep are all inconsistent in the way they actually produce and use PEC charts. We already know that a single worm cycle PEC chart will be useless because PE is inconsistent from cycle to cycle. So I created a multi worm period PEC chart and that didn't work properly either - guiding RMS error increased when PEC was switched on even when the mount was slewed back to the original microstep position. Tonight I found out why by delving into the EQMOD code. Although a PEC chart contains an accurate microstep counts, these are ignored most of the time by EQMOD in favour of a count of seconds that is also in the PEC file. But the count of seconds has been incorrectly generated by PERecorder i.e. instead of using 104.7304 microsteps/second it used a slightly different ratio which I haven't yet got to the bottom of.
To be continued ...
Compare it with these below, now the post rebuild looks is +-10 against (you can see where the cable caught just before I stopped capturing data and the drift) -17.5+7.5 pre re-build. You will see post re-build the graph is smoother, now I have another one knocking around if I can find it which is about +-7.5 post tuning the mount.
What changed my mount was the worm end bearings it had the ones with the metal bearing retainers in them, these were replaced with good quality ones and also I shimmed the mount correctly. I can guide a 2 meters no problem.
Mark, your mount looks rough as hell.
Post rebuild
(http://farm3.staticflickr.com/2225/2310141754_669f22d5c1_o.jpg)
Pre
(http://farm4.staticflickr.com/3179/2752997957_fcd25fbbeb_o.jpg)
Egger work fitted, which got pulled out
(http://farm3.staticflickr.com/2186/2753831740_936a00f781_o.jpg)
Mine seems to have a much stronger 122.22s cycle superimposed on my 478.69s worm cycle (122s is the rotation period of the motor pinion) and also my 10.185s cycle (tooth frequency) is quite pronounced.
If I had your graph I would be most happy.
Mark,
Have they changed the gearboxes back to the older ones? Your graph looks like the pre white mount.
http://www.beltingonline.com/heq6-belt-mod-drive-kit-12220?zenid=5nvuj2aleckrg7rv5q09sjj516
try that
Chris
Why don't you consider the belt drive mod?
Quote from: Rocket Pooch
Have they changed the gearboxes back to the older ones? Your graph looks like the pre white mount.
I've no idea whether the gearboxes have changed. But I do know my NEQ6 one is different to and substantially noisier than this EQ6 one.
Thanks for the belt link. I see it retains the 12:47 gear ratio. There's a good argument for installing a 12:48 belt kit as long as I never want to drive it from the handset again.
But before doing that I want to see how just far I can push the EQMOD PEC approach. I think I can get sub 0.5" RMS guiding using a carefully prepared PEC file that works around the limiting assumptions built into the coding of EQMOD's PEC routines.
Mark,
I was looking for this page last night, it has a set of EQ6 PE measurements and the measurement dates, you will see why I think they have changed something.
http://demeautis.christophe.free.fr/ep/eq6.htm
And here's a bit list
http://lambermont.dyndns.org/astro/pe.html
Yes, some of those pre-modification graphs look very similar to mine.
I've reached the end of the road now regarding PEC. Two successive PE charts are not sufficiently close to be able to apply any kind of useful PE correction. Here's a chart showing two successive runs of 6 worm cycles starting at exactly the same place (in terms of motor step count). Vertical axis is arcseconds, and horizontal axis is motor step count.
(http://www.markshelley.co.uk/webdisk/EQ6_PE3.jpg)
The graphs don't lie on top of one another. Here's a closer up view of 1 cycle:
(http://www.markshelley.co.uk/webdisk/EQ6_PE4.jpg)
In some places they line up but in others there is a slight lag. I'm sure the wobbly idler (transfer) gear is partly to blame. I've tried generating numerous PEC charts in a spreadsheet but simulation shows there would be almost no improvement in guiding performance.
So I now have an EQ6 belt kit on order. Thanks for the BeltingOnline link Chris!
To be honest I don't expect much (if any) difference in overall peak to peak periodic error since I can't imagine that the manufacturing tolerance on the toothed pulleys and toothed belts are precise enough. However I do expect that the superimposed 10.2 second gear tooth error will disappear and so the remaining periodic error will be much easier to guide out. If I get no improvement then at least this mod is reversible.
Wow! The belt kit has arrived already, despite the beltingonline website saying there is a lead time of at least 3 weeks on this kit.
I might be able to find time to fit it at the weekend and then begin testing.
I'm very interested to hear what difference this will make.
Quote from: Mike
I'm very interested to hear what difference this will make.
You and me both!