EQ6 Belt Mod (Belting Online)

[MarkS]

Hi Chris,

Last night with a 600mm fl guidescope I was getting 0.24 pixels RMS error on the QHY5 guidecam (post mod).

Multiplying this up to a 1.4m fl equivalent that would have given me 0.56 pixels RMS.   I was purposely guiding on a star close to 0 Declination and the seeing was not at all good.  If instead, I was guiding on a star higher in the sky, I would (of course) have got a smaller figure in terms of RMS pixels.

My goal was to reduce the amount of star bloat when imaging at longer focal lengths - so if I could reduce the RMS guiding error to well below the RMS seeing then I'd be happy.  I reckon I've just about achieved that now but I need to try an imaging run to check.

I understand the shimming issue but what do you mean by the "proper" end bearings?  I assume you mean the worm bearings?  What is "proper"?

Mark

[Rocket Pooch]

Hi,

Yes worm bearings, something like the link below the temperature resistant ones not the £3 ones which look the same but go all wobbly when the temperature drops which causes an odd noise when slewing.

http://simplybearings.co.uk/shop/p7313/SKF+6082RSHC3GJN+Sealed+High+Temp+Deep+Groove+Ball+Bearing+8x22x7mm/product_info.html

Chris

[MarkS]

By more careful analysis I've identifed another frequency component running at more or less exactly 8x the tooth frequency i.e. a period of 1.27 seconds (=10.18/8).  The only explanation I can think of is that there are step down gears within the body of the motor itself.

This isn't a sampling artifact because I'm sampling PE at 10 frames/sec - so a period of 1.27 seconds is easily identifiable.  It has a peak to peak of 0.5 arcsec.

Does anyone know if this is the case - i.e. is it likely there at least one additional gear within the motor body?

In any case, it has a very interesting implication for guiding - for optimal guiding the guide camera should be run with an integration period of 1.27 seconds - to integrate exactly over this period to prevent "false" guiding corrections being issued.

If it's not caused by an internal gear then maybe it is an artifact caused by the microstepping - each motor step is subdivided into 64 microsteps.

[Mike]

Does anyone know if this is the case - i.e. is it likely there at least one additional gear within the motor body?

Highly unlikely Mark. They look like standard cheap 1.8 degree stepper motors to me. It's more likely a micro-stepping issue as the motor isn't turning smoothly but jumping along each tiny step.

[The Thing]

Does anyone know if this is the case - i.e. is it likely there at least one additional gear within the motor body?

Highly unlikely Mark. They look like standard cheap 1.8 degree stepper motors to me. It's more likely a micro-stepping issue as the motor isn't turning smoothly but jumping along each tiny step.

There was a guy on the eqmod forum asking about replacing the stepper with a more accurate one (2x steps per rev) and how that would affect EQMOD - could it be accommodated. http://groups.yahoo.com/neo/groups/EQMOD/conversations/topics/37492

[Mike]

It's certainly possible to replace them with better resolution motors, you'd just need to modify the EQMOD settings accordingly and ensure they work with the existing circuitry. Though if the circuit is doing standard 1/8th micro-stepping it should work with any motor with the same amount of coils.

[Rocket Pooch]

This isn't a sampling artifact because I'm sampling PE at 10 frames/sec - so a period of 1.27 seconds is easily identifiable.  It has a peak to peak of 0.5 arcsec.

You don't want to be doing that sampling rate, guiding subs should be 1-2 seconds to average out seeing, or you will try to over correct for seeing.

[MarkS]

The 10 frames/sec is done by PERecorder for PE analysis - I wouldn't use it for guiding

It's because PERecorder only uses a webcam.

[Rocket Pooch]

Same thing the stars will be subject to seeing.

[MarkS]

Same thing the stars will be subject to seeing.

That's right - the seeing caused a lot of jitter in my PE charts but averaging adjacent samples removes most of this.

The reason for using PERecorder is that it indexes PE against EQASCOM motor position count.  This will allow me to unleash Part II of my fiendish plan - to produce a PEC file accurate enough to remove most of the 10.2 second period.

[Mike]

This will allow me to unleash Part II of my fiendish plan.....

Mwuuhhhaaaahhaaaaaa!!!

[JohnP]

shame that mad professor doesn't look like Mark....

[RobertM]

It doesn't now 

[RobertM]

Mark,

Have you got any further with this ?

Robert

[MarkS]

Yes and no.  Unfortunately I've been a bit busy recently for one reason or another.

I did produce a PEC file for the correction and the first night I tried it my guiding was down to .08 pixels at 300mm i.e. around 0.3 arcsecs.  The next time I tried it the PEC file made no difference and there was a lot of jitter - guiding was .16 pixels at 300mm.  I'm not yet sure of the cause of the variability.  In any case, I'm planning on replacing the worm bearings next - probably the weekend after uDSC.

I think the belt has bedded down a bit now - the PE graph below shows much less amplitude of the 122sec period of the motor pinion than straight after the conversion:


Here's part of the PEC file I used:


It contains the 479 sec worm, the 122 sec pinion and the 10.2 sec tooth frequency.  The whole PEC file contains 12 worm cycles because the pattern repeats every 12 cycles now the 36 tooth transfer gear no longer exists.  I had to do some jiggery pokery to allow EQMOD to accept this non-standard file.

The worm cycle is not sinusoidal (on my mount) but has quite a definite hump shape.  On that basic hump shape the 122 second and 10.2 second periods are superimposed.

So much to do and too little time to do it!

Mark