Support for more rotator features

[quentinmit]

I noticed a couple of limitations that prevent using remoteRotator with our rotors:

• Support <1° precision (important for e.g. EME work); azimuth/elevation appear to currently be represented by integers.
• Support for continuous rotation rotors; it looks like you can't avoid specifying an azimuthStop.
• Support for velocity commands.
• Support for brake on/off as a separate command (i.e. the full set of possible states for each axis are "position servo", "velocity servo", "brake", and "coast"). This could also be represented as "velocity servo with velocity=0" and not have a separate state, but maybe there are some rotors for which that is different.

Not all rotors support all of these options, of course, but we have rotors that need some combination of each of them.

Not knowing about remoteRotator, we also implemented our own rotator library in Go, at https://github.com/w1xm/rci_interface/blob/master/rci/rci.go, if you'd like to see how we solved these problems.

[dh1tw]

Hey @quentinmit,

implementing a new rotator in remoteRotator is actually quite straight forward. The implementation only has to satisfy the Rotator interface. The file you mentioned is already pretty close.

Support for <1° precision Agreed, we could change the types from int to float64. Supporting a higher precision in azimuth and elevation makes sense.

Velocity & Brake IMHO features like velocity and brake on/off should be handled in the implementation or the physical rotator controller and not being exposed to the user in the GUI. I haven't come across an actual case where controlling the velocity and brake manually would have been really required. Can you please elaborate on why it is necessary at your station?

Continuous rotation The only antenna rotators I've come across so far have a fixed turning radius, eg 0°-360° or 0°-450°. I'm wondering how you physically route your cables to support continuous rotation? I couldn't find any infos on your Sigmet RCI rotor.

On a side note you might want to check out K3NG's open source rotator firmware in case you have to implement your own rotor controller.

[quentinmit]

Velocity & Brake

There's two use cases for velocity control.

One is to implement the traditional CW/CCW interface, where pressing the button sets velocity = +/- n °/s and releasing the button stops motion. That, I think, applies to every rotator.

The other is that, with continuous rotation, we can do applications like radioastronomy or radar by setting a fixed azimuth velocity. We've had great success doing passive radar using beacons and airplanes.

Also, running the rotor in continuous rotation for a few minutes at the start of the day gets the oil flowing and helps lubricate the geartrain :)

As for ability to control brakes, when your antenna weighs hundreds of pounds and has significant inertia, you really need the ability to apply the brake quickly, especially for elevation where there's a hard stop. We already have a couple dents in our dish from elevation velocity excursions. ;) (Yes, there are software safety limits and hardware interlocks with limit switches, but inertia can overcome them.)

For our SCR-584 rotator and RCI rotor controller, the brakes are actually electronic brakes, so "braking" is done by driving the motors in reverse. This causes a lot of stress on the geartrain, so it's not something we want to do in normal operation - the normal "stop" should be at a coast. We use braking when we need to do an emergency stop. Also, though it's not relevant for this particular rotator, brakes are important to resist uneven wind loading.

Continuous rotation

Technically the Sigmet RCI is a generic rotor controller, not a rotator; in our station it's controlling an SCR-584 rotator. If you're curious you can read the RCI manual and the SCR-584 service manual.

The short answer, though, is that power and RF are routed through sliprings. The rotator has integral slip rings (page 9 of the PDF/page 244 of the original service manual) to carry low-frequency power; in our application we have our PAs mounted on the moving portion of the antenna, so the sliprings carry 28V DC for the PA, 12V DC for preamps, 24VDC for relays and Modbus low-speed serial for sequencing. And we have a special RF slipring that carries RF signals (something like this, although we have an old military surplus one from a different manufacturer). Because our PAs and preamps are mounted on the antenna itself, the RF slipring doesn't have to carry much RF power.

Open source rotator firmware

Very interesting; we would in fact like to replace our rotator controller, though that firmware doesn't look directly applicable. I'm not sure if it supports continuous rotation, and it definitely looks like it doesn't support our position sensors - we have both pulse tachometers for velocity sensing and selsyns for absolute position sensing. The RCI takes care of fusing these two sensors together into the control loop.

Incidentally, you're welcome to check out our (read-only) web interface at http://w1xm-radar-1.mit.edu:8502/ and http://w1xm-radar-1.mit.edu:8502/dashboard.html if you want any ideas.

[quentinmit]

Ping?

[quentinmit]

Bump?