Akademisk Radioklubb

LA1K / LA1ARK / LA1UKA

Hamlib driver for Spid MD-01 and MD-02

A release candidate of hamlib 3.2 is out. When released, version 3.2 will be the first to contain our driver for the Spid MD-01 and MD-02 rotator controllers.

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!

3 Comments

  1. Cameron McKay

    June 5, 2019 at 01:09

    I’m looking at the SPID Hamlib library and its interface to GPredict. Generally, the SPID manuals appear to suggest that the rotator can only rotate -180deg from the ‘reset’ position and +540deg from the reset position, however the Rot2prog protocol appears to suggest it should be possible to command the rotator within the range of either -360 to 360 degrees or -180 to 540 degrees or possibly even 0 to 720 degrees. In your communications with Spid, were you able to categorically confirm this? The reasoning for my question is to address flip passes and azimuth rotator range within the rotator setup within Gpredict requires specific clarity around this matter and I don’t personally have access to the hardware to test this.

    • Norvald H. Ryeng

      June 5, 2019 at 20:28

      Hi Cameron,

      It’s been a few years since I wrote that backend, so I don’t remember exactly. I might have just copied those numbers from somewhere. It does indeed look a bit strange:

      $ rotctl -L -m 901
      […]
      min_az: “Minimum rotator azimuth in degrees”
      Default: -180, Value: -180.000000
      Range: -360.0..360.0, step 0.0
      max_az: “Maximum rotator azimuth in degrees”
      Default: 180, Value: 540.000000
      Range: -360.0..360.0, step 0.0
      min_el: “Minimum rotator elevation in degrees”
      Default: 0, Value: -20.000000
      Range: -90.0..180.0, step 0.0
      max_el: “Maximum rotator elevation in degrees”
      Default: 90, Value: 210.000000
      Range: -90.0..180.0, step 0.0
      […]

      So some of the values set for this rotator are out of range (I think the ranges are set by the hamlib rotator framework, not by the driver).

      Is there something in particular you want to test? I have access to all controllers.

      73 & best regards,

      Norvald, LA6YKA

      • Cameron McKay

        June 5, 2019 at 23:06

        Norvald,

        Thanks for your response. I’m in conversation with AlphaSpid at the moment however thanks for your offer to test. Once I’ve got the ‘official’ answer fom AlphaSpid, I’ll make any necessary changes to the HAMLIB backends. At the same time, I’m attempting to implement additional functionality into GPredict for users who have these rotators (in particular in the code for ‘flip passes’ which shouldn’t be necessary for AlphaSpid RAS rotators).

        73,

        Cameron – VK2CKP

Leave a Reply to Cameron McKay Cancel reply

Your email address will not be published.

*