EQ6, PHD and the 10.2 sec period

[MarkS]

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

[MarkS]

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.

[Mike]

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.

[Rocket Pooch]

Hmm, surely the time is the primary cog, but I still don't understand the issue.

[MarkS]

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

[The Thing]

This is one of the reasons people do a belt drive mod 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 £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.

[mickw]

Surprised at how cheap that mod is

[Ian]

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.

[MarkS]

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

[Mac]

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.

[MarkS]

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.

[MarkS]

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.



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:



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

[Rocket Pooch]

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



Pre



Egger work fitted, which got pulled out

[MarkS]

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.

[Rocket Pooch]

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