At LA1K, we’ve been using a wide range of Spid rotators and rotator controllers for a decade. We’re satisfied enough with them that we bought the MD-01 for our 1-10 GHz project even though there was no driver we could use (it comes with a Windows driver, but we were planning to use it from Linux). Spid has been accommodating with documentation in the past, which is how we’ve been able to write the other Spid drivers in hamlib, so we were optimistic about getting it to work.
The driver implementation was even easier than we thought. We first thought that we’d have to implement a brand new protocol, but it turned out the MD-01 protocol is still just vaporware. The device actually only supports the Spid Rot2Prog (or Rot1Prog) protocol, and we’ve implemented that in hamlib before. After making that discovery, we just turned on the MD-01 and set it up with hamlib rotator model 901 (Rot2Prog). Of course, it failed in fun and exciting ways.
It turned out that, yes, it speaks the Rot2Prog protocol, but not the exact same way that Rot2Prog does. While the original Rot2Prog doesn’t send a response to the
set_position command (the command that makes the rotator rotate to a given position), the MD-01 will respond with its current position. Hamlib rotator drivers, at least those we’ve looked at, aren’t very forgiving when it comes to controllers sending more data than hamlib expects. There is no clearing of input buffers at the beginning of a command, so if it gets out of sync, it will disturb communication until you close and reopen the connection. Once we figured out that little quirk and implemented that behavior in the driver, it worked perfectly!
Until it didn’t …
It turned out there was a bug in the MD-01 firmware that made the controller drop commands, rotate the antenna to a different position than we requested, and generally behave in a way that made it completely useless for our purposes. The bug was triggered if commands were sent to the MD-01 too fast. If we staggered the commands, there was no problem. We worked with Spid to resolve that issue, but that is a different story. Suffice it to say, Spid has released a new version of the firmware (1.2507) that contains a bug fix.
MD-01 and MD-02 extend the Rot2Prog protocol with commands to move the rotator clockwise, counterclockwise, up and down without setting a target azimuth or elevation. The hamlib driver also supports these commands, in addition to the go to position, get position and stop commands.
So if you have an MD-01 or MD-02: Upgrade to firmware 1.2507 or greater, upgrade to hamlib 3.2, run
rotctl -m 903, lean back and enjoy!