[RadioTelescope] Stepping rates

[Andrew Williams]

On 11/10/2010 1:34 PM, Harry McNally wrote:

> Yes. Remembered that from your previous email. I'm pondering more what the
> maximum step rate is that the motors can deliver (torque-wise) although I
> presume that's pretty high when the dish is accelerated up to that limit.

You'll need to measure the maximum reasonable accelleration rates and 
slew speeds after the system is built, it'll depend on drivetrain 
friction, moment of inertia of the dish (and all rotating components in 
the drivetrain), etc. Too hard to bother trying to calculate...

> Impressive :)

What's really impressive is the way they allowed the Parkes telescope, 
with an azimuth/elevation drive to track objects in right-ascension and 
declination (curved paths across the sky) in the 50's, before computers...

In the exact centre of the az/el drive system, they had a small chamber 
with a dummy 'telescope' on an equatorial mount - one axis pointed to 
align with the Earth's polar axis (RA, or 'longitude' on the sky), the 
other at right angles (Dec, or 'latitude' on the sky). To track an 
object with an equatorial mount, you keep the Dec axis fixed, and rotate 
the RA axis at one revolution per day, to counteract the Earth's rotation.

That central equatorial 'dummy telescope' was first slewed to the 
desired target coordinates, and set tracking the object. Then the az/el 
drive of the dish was manually slewed to line up with the same 
direction, to within a few degrees. Once the position was close enough, 
they activated a servo link with a light beam and a set of photocells 
between the az/el drive on the dish and the tracking motion of the 
central equatorial mounted dummy telescope.

>> (BTW, I'd plan on cable-wrap limits in hardware, not software,
>> especially if you're going to allow a bit more than 360 degrees...)
>
> Ok. There are no limit switches that I can recall on the mount.

If there's an encoder, you could simply enforce not being able to pass 
through, say, 0 degrees azimuth, in either direction. That would be 
irritating, since if you were tracking an object, you'd have to break 
away and slew the long way round - there's no single azimuth value that 
you aren't going to want to 'track through' quite often (and 0 degrees, 
due north, is a really bad choice).

A better way would be to allow, say, 540 (or more) degrees of travel. If 
you slew to a new object, you calculate the direction to 'unwind' to the 
most central cable-wrap azimuth, but if tracking, you could continue in 
one direction for much longer.

The problem is that if your encoder only gives you azimuth angle, you 
need to keep track of cable-wrap boundaries by dead-reckoning, and 
guarantee storing that state between uses.

Without cable-wrap limit switches, I'd make sure you design some 
quick-release connectors in the middle of the cables (or at one end), so 
that if the software fails to keep track of state, it's an easy fix...

Andrew