Welcome, Guest. Please login or register.

Username: Password:

Author Topic: 0.5 arcsec/ustep limit  (Read 7030 times)

lowsfer

  • Jr. Member
  • **
  • Posts: 6
    • View Profile
0.5 arcsec/ustep limit
« on: April 17, 2015, 04:03:33 »

Hi guys,

Hopefully my AstroEQ is coming soon :)

I saw in the following post:

http://astroeq.co.uk/forum/index.php?topic=9.0

It's mentioned AstroEQ has a 0.5 arcsec/ustep limit. Why is there a limit?

The original motor/gear of my mount (Losmandy G11 S) gives 0.5 arcsec/fullstep resolution. I don't know whether it uses microsteps or not. Probably no I guess. With motors replaced I wanted to go beyond 0.5 arcsec/ustep because I heard that micro steps are not so accurate as full steps for most motors. For 15 arcsec/ustep sidereal rate, 0.5 arcsec/ustep doesn't require a very high control frequency. So probably it's not a hardware limit? Can I change it? I can accept it if that decreases the maximum achievable goto speed.

Many mounts today provides higher resolution than 0.5 arcsec/ustep, for example, iOptron CEM60 and SkyWatcher EQ8.

Regards,
Yao
« Last Edit: April 17, 2015, 04:59:50 by lowsfer »
Logged

TCWORLD

  • Administrator
  • *****
  • Posts: 809
    • View Profile
    • AstroEQ
Re: 0.5 arcsec/ustep limit
« Reply #1 on: April 17, 2015, 12:56:46 »

Its not really a hard set limit, you can in some gearing combinations go higher. The main issue is how fast the processor on AstroEQ is. It takes time to perform all of the commands in to motor routine (about 200 clock cycles, which was heavily optimised down from several thousand). There are two motors, which means that the repetition rate for the interrupt routines can't be any less than 400 clock cycles, otherwise it would never do anything but move the motors - commands from EQMOD would not be handled and the whole thing would crash.
IVal is what governs the repetition rate, which is why when you enter values into the configuration utility, if the resulting IVal is less than ~450, it will complain that it cannot support that configuration, specifically to avoid the situation where the repetition rate would be faster than the processor can handle.
In many cases it seems that if you go much beyond 0.5arcsec/ustep resolution, this limit is reached. However it is actually possible to get to resolutions of ~0.25arcsec/ustep for some combinations. It's hard to say which though as it is a minimisation problem with 4 independent variables.
Logged
Tom Carpenter (AstroEQ)

lowsfer

  • Jr. Member
  • **
  • Posts: 6
    • View Profile
Re: 0.5 arcsec/ustep limit
« Reply #2 on: April 18, 2015, 14:54:17 »

Hi Tom,

Thank you very much for the explanation. I see your point. But that's probably for very high gearbox reduction ratio and high speed, right?

I want to directly couple a 0.9degree/step (400steps/rev) NEMA23 motor to a 1/360 worm on Losmandy G11. I plan to use 1/32 microstep to get 0.28125 arcsec/ustep resolution.

For tracking, 1x sidereal is ~15arcsec/sec. Then sidereal tracking requires only 15/0.28125 = 53.33 usteps/sec. The 16MHz processor should be able to handle that easily, right?

I just checked your code in AstroEQ.cpp, I see you did disable microstep for GOTO. So I think 16MHz should be able to handle very high speed. In my case, 800x GOTO speed using full steps requires 53.33/32*800 = 1333.33 fullsteps/sec. With the 400circles/step processor cost you mentioned, that's only 400*1333.33 = 533.33 KHz, which is much lower than the 16MHz clock. Thus I think the processor should no be a limiting factor in my case, right?

Even if I add an 1/5.18 ratio gear box, the processor should still be OK I think. But if the gearbox ratio is sth like 1:120, I agree that's a big problem. But If we decrease the GOTO speed, it should still be possibly to make it work, right?


Regards,
Yao

Its not really a hard set limit, you can in some gearing combinations go higher. The main issue is how fast the processor on AstroEQ is. It takes time to perform all of the commands in to motor routine (about 200 clock cycles, which was heavily optimised down from several thousand). There are two motors, which means that the repetition rate for the interrupt routines can't be any less than 400 clock cycles, otherwise it would never do anything but move the motors - commands from EQMOD would not be handled and the whole thing would crash.
IVal is what governs the repetition rate, which is why when you enter values into the configuration utility, if the resulting IVal is less than ~450, it will complain that it cannot support that configuration, specifically to avoid the situation where the repetition rate would be faster than the processor can handle.
In many cases it seems that if you go much beyond 0.5arcsec/ustep resolution, this limit is reached. However it is actually possible to get to resolutions of ~0.25arcsec/ustep for some combinations. It's hard to say which though as it is a minimisation problem with 4 independent variables.
« Last Edit: April 18, 2015, 18:47:14 by lowsfer »
Logged

TCWORLD

  • Administrator
  • *****
  • Posts: 809
    • View Profile
    • AstroEQ
Re: 0.5 arcsec/ustep limit
« Reply #3 on: April 18, 2015, 21:58:38 »

When AstroEQ changes the step mode it doesn't affect the interrupt speed. All it does is change the mode of the stepper drivers and increments the internal encoders by 8 each step (as the steps are 8 times further). The actual base interrupt rate doesn't change.

The trouble is if the interrupt repetition rate is faster than it takes to process a step (even if you aren't stepping that often) it will cause an interrupt to be missed which would over time cause a drift in the speed as software counters would start losing counts. During tracking this would be very bad. Not every interrupt produces a microstep, but some do. So basically even though you aren't stepping that many steps per second, a second interrupt can never be allowed to occur while one is still in progress.

There are two more things to take note of.
The step pulses require a rising edge and a falling edge, which means that the effective clock rate of the CPU is 8MHz as that is the fastest it can do a rising edge then a falling edge. So that reduces the maximum rate to 266.66kHz in your calculation. Still quite large though, I agree.
But the final thing to remember is a matter of resolution. The MCU needs to be able to accurately pulse 1 revolution worth of microsteps in almost exactly 86164.0905 seconds, and the base value needs to be a high enough number to be able to achieve this - unless of course the gear ratios were designed so that it took a nice round number of motor revolutions per full axis revolution at the sidereal rate.

Interestingly, I didn't come up with the way that the interrupts are used - the base rate and divider, it's the same way that the Synscan devices do it. The reason I went with that approach rather than my original idea is that it is the way that the synscan protocol works. Both the device and EQMOD calculate the base interrupt rate, and then EQMOD sends a divider to turn it into the required speed. I had tried a different approach to doing it, but the trouble was it required converting the speed values EQMOD sent into clock periods which involved 1/x calculations to do it, which in turn made performing dec/acceleration difficult and resulting in inaccurate tracking speeds.

Now if I had been thinking back when I designed AstroEQ, I would have used probably 3 Microcontrollers - 1 for each motor axis, and 1 for the PC interface. That way the ones driving the motors would be completely dedicated to that task, so the IVal could be smaller meaning higher resolution.
« Last Edit: April 18, 2015, 22:04:45 by TCWORLD »
Logged
Tom Carpenter (AstroEQ)

TCWORLD

  • Administrator
  • *****
  • Posts: 809
    • View Profile
    • AstroEQ
Re: 0.5 arcsec/ustep limit
« Reply #4 on: April 18, 2015, 22:30:19 »

Having just looked back at the code to remind myself, I realise that I have been making a mistake in what I've been telling you.

IVal is not the interrupt base rate, it is the number of interrupts between steps at the sidereal rate.

The actual base rate is based on bVal (base Value). The number of clock cycles per interrupt is then Timer clock frequency (8MHz) divided by the bVal. For your ratios, the bVal is 16632, so there would be 1 interrupt every 481 clock cycles. This is above the 450 limit. So basically you won't have any problems getting a resolution of 0.281 arcsec/ustep.

It just so happens that the IVal is directly related to the bVal in that the calculation is:
bVal = (IVal*aVal/86164.0905)
Where the aVal is the number of microsteps per revolution.


Now that I look at that, I realise that the lower limit I chose for IVal is actually quite artificial as the limiting factor is actually the maximum value for IVal - because the larger that is, the more speed accuracy you want, and so the faster the interrupt rate! So actually, yes you can go to much higher resolutions at the cost of accuracy in speed for tracking rates other than sidereal. With a 3:1 gearbox you could possibly get 0.01arcsec/ustep resolution!

I need to go over the reasoning again, but I think that is something I hadn't actually realised before. Now what I need to do is work out how to properly apply the limits, and what impact it has on the accuracy of tracking.


Logged
Tom Carpenter (AstroEQ)

lowsfer

  • Jr. Member
  • **
  • Posts: 6
    • View Profile
Re: 0.5 arcsec/ustep limit
« Reply #5 on: April 19, 2015, 12:21:38 »

Hi Tom,

Thank you very much for the explanation. So the problem is that it needs high interruption frequency to give accurate timing. That makes sense.

About the hardware design, maybe we can use an external crystal/counter which triggers one interrupt pin when one ustep should happen. Then possibly we can get very high accuracy and resolution with high-frequency crystal and a large (e.g. 32-bit) counter? Since only one interruption is required for one ustep, we won't need high interruption frequency in this way.

I don't really know much about embedded device programming, maybe it's a stupid idea. :P

Regards,
Yao
Logged