HEQ5 Pro tracking improvement

[lux eterna]

Hi all,

I have been using this with my standalone Nexguide for more than 2 years now, so about time to tell the world... I guess it would work the same with any ST4 connected autoguider.
It is not intended to be critical of the HEQ5 Pro, I just love it. I guess things like these takes place in many mounts except the most expensive ones. This is a story of what often happens when a stepper motor is driven with microstepping.

It started during collimation of my Meade LX200-ACF and I was inspecting a star with maximum digital zoom. I noticed that the star was "dancing", or jumping, very very little in RA at a regular pace. Later I found out that the stepper motor does not have a 100% linear motion during tracking :

I took this as a challenge, and also a opportunity to learn something about using a Arduino microcontroller. I also got a reason to get myself a (very cheap, usb type) oscilloscope. This immediately showed me that there is a voltage spike on each of the two stepper coils, that could act as a trigger for the Arduino to send a pre-defined pulse train on the ST4 port (the probe was connected via a high ohm resistor directly over the stepper coils). Designing that pulse train was later done by trail and error.

The below oscilloscope image is in fact two images (one for each coil), combined to one in PS. Time between a blue and a yellow spike is approx 600 ms (which corresponds to the dancing star that I estimated to be 0.5 sec). 

The above cirquit allows for the guider to have priority over the Arduino (via the two diodes to the right of the Arduino). I have set the HEQ5 guide speed to 1.0 (fastest) in order to minimize the pulse length of the guider, so it will free up more time for the Arduino pulses.
The "inpins" (#2 & 5) have no active role in this "RA fix", these are only used for monitoring the guide pulses which serves two purposes: 1) I can have a "clouds alarm" (= no active guide pulses) 2) I have programmed the RA fix to be active only when the guide pulses are active - this is because the RA fix could disturb the stepper motor during slewing (and guide pulses immediately stop when I start slewing so I use that for on / off switching). 

The pictures below show my first version which was built in under the hood of the HEQ5, but later I have included an intervalometer etc and put most of it externally (just the dual trigger devices are left internal).

 

Now things move smoother :

At last some live testing. The first image is during a manual slew in DEC (slowest possible) just to show the RA behaviour like in an oscilloscope. Of course no guiding here. The second is with guiding, while turning on or off this RA speed correction fix.

Having used this for a long time now, I think it needs good seeing to make any difference. But if that is the case, the autoguider will be less disturbed by the rather fast (0.6 sec) RA wobbling, and the result is clearly noticeable.

Ragnar

[vlaiv]

Very interesting. I have not noticed anything similar on my mount.

I wonder what sort of error could we be talking here?

You say that pulse happens every 0.5-0.6 seconds? Let's see what that corresponds to.

If I'm not mistaken, Heq5 has 64 micro steps per step, and one micro step is 0.143617 arc seconds. Sidereal rate is 15.041, right? This means that every second, we have 15.041 / 0.143617 = ~104.73 micro steps.

Interestingly enough - in 0.6s we have about ~62.83 micro steps. I bet that this period is actually 64 micro steps and that you see what happens on a full step.

Next thing that I would be interested in is how much absolute error there could be from such a motion. Since we have seen that it is indeed about 0.6s period - in that time frame, mount moves 9 arc seconds. From what I can see on the first video you posted - it looks like mount is going faster in one cycle than it ought to and then slows down in last 10-20%. Maybe it is doing what your oscilloscope is showing - in one "step cycle" maybe it is following sort of sine curve? I'm not sure how we could model this without precise measurement - like having a timed video against millimeter paper or something.

In any case, let's go with some very simple error model. Let's say that speed of mount is 20% larger than it should be and then it slows down. It is larger for 80% of time. In 0.48s it is moving at 18"/s instead of 15"/s. What sort of error could we expect?

0.48s * (18"/s - 15"/s) = 1.44

That is very large error and that should be easily noticed as oscillation by people guiding at 1s.

Have you tried measuring actual error from DEC drift experiment and pixel scale?

[lux eterna]

It is very easy to see if your mount has this behaviour or not. Just attach a long paper or plastic index to the RA drive like I did. No need to measure, you can see just by looking at it. I think you are right, this happens each 64 micro steps (= each full step).

(EDIT:  posted by mistake, continued writing again... )

I found interesting explanation HERE (under "Limits of Microstepping").

Ragnar

 

Edited April 15, 2020 by lux eterna
mistake

[pete_l]

1 hour ago, lux eterna said:

I found interesting explanation HERE (under "Limits of Microstepping").

Interesting stuff.

So we have two issues with steppers: the lack of torque in microsteps, where competing currents hold the armature between "natural" full steps - and inherent non-linearity in the motor's response. Possibly due to only having approximate sin() / cos() values, but more likely due to the  properties of the permanent magnet: hysteresis and whatnot.
It might be illuminating to see how your mount responds to more or less OTA balancing.

[lux eterna]

1 hour ago, pete_l said:

Interesting stuff.

So we have two issues with steppers: the lack of torque in microsteps, where competing currents hold the armature between "natural" full steps - and inherent non-linearity in the motor's response. Possibly due to only having approximate sin() / cos() values, but more likely due to the  properties of the permanent magnet: hysteresis and whatnot.
It might be illuminating to see how your mount responds to more or less OTA balancing.

Yes, it´s the mismatch between the driver´s implementation of cos / sin functions relative to the physical properties of the motor mechanics. So different motors can behave differently with the same driver.

There is a some unlinearity (as seen in the video) even with zero load in RA, and I have not seen any change at all under load (holding a finger against the pulley).

Ragnar

[CedricTheBrave]

This is indeed very interesting. 

would this cause what looks like a star vibrating?

I posted a question a short while ago about my HEQ5pro. I don't usually use it for visual but while checking focus i noticed that the star i was looking at was indeed vibrating and this could account for my struggle to get sharp images with my setup!

[lux eterna]

6 hours ago, CedricTheBrave said:

This is indeed very interesting. 

would this cause what looks like a star vibrating?

I posted a question a short while ago about my HEQ5pro. I don't usually use it for visual but while checking focus i noticed that the star i was looking at was indeed vibrating and this could account for my struggle to get sharp images with my setup!

Hi Cedric,

Interesting you have a HEQ5 Pro and a D7000, just like me. I can tell that if you can get the D7000 modded it gets very sensitive for H-alpha, I like that.

Vibrating star, no I would not call it vibrating from the issue described above. It´s more like jumping, bouncing or dancing. Only If you can notice a very small (it´s hard to see, you need good seeing otherwise the atmosphere will overwhelm this) and very rythmic (0.6 second interval) "jumping" in RA only, then you have spotted it. And as I said, I can bet my bottom Swedish Krona that other mounts in the same price range have similar behaviour. I do get sharp images with my mount, even before making this fix, it´s just a tad better now - but only when seeing is good (otherwise it makes no difference at all).

Ragnar