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!
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.
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
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
Hello,
I have a problem with the md-01 controller : everything is working as expected (with a ras rotor) except sometimes the controller is completely freezing (even on the lcd display). It is a major problem because the rotor continues to turn and the md01 must be turned on and off to stop it… Do you know where this can come from? I am using firmware v 1.2512 and hamlib v3.3
Thanks,
Hello Nicolas,
Sorry for the delay between question and answer, I just discover this site now, looking for help to drive my spid bigras/hr with stellarium…
I experienced exactly what you described. Intuitively I thought it could be an earthing problem with the control signals, the long cable that should be shielded and carries sensitive signals from the motion detectors. In the connection box on the antenna side, as I was testing the logic of the ground network, I found two GND points that had a residual difference of potential: not good! I bridged these two and no more bug!
Good luck!
For posterity: Nicolas also asked on the hamlib developer’s mailing list and got some answers there (from the author of this blog post, LA6YKA, among others). The email thread can be found here: https://sourceforge.net/p/hamlib/mailman/hamlib-developer/thread/d7294694-f1a5-1592-bb19-e33a83bdf576%40nimon.org/#msg36764907
Hi LA6YKA,
Hi mr.
I am an amateur astronomer and work with radio astronomy at Brorfelde Observatory in Denmark. I also have an MD-01 that freezes and runs very unstable. I have tried operation only with the arrow keys but the same error sequence. Freezer and often unstable in position. PstRotator is also used and when using the STOP / Park function that should get the antenna back to 0 position in the North of Az and El.
From RFHamdesign I have everything I need instruction and file. But also a WARNING about the update that can do more harm than good.
What is your experience with the update?
It is done with windows 10 via USB to RS232 on MD-01 should it cause difficulties?
We run a BIG/RAS/HR
Thanks for the help
With kind regards
john sommer ing. and HD-Informatics and account
Hi John,
It’s been a while since our previous firmware upgrade, so I don’t remember all the details, but a warning that it may cause harm is not unexpected. If you follow the instructions, you should still be fine. It’s common practice to give these warnings to scare people to not flash unless they know what they’re doing, and to make sure that they have read the instructions carefully.
We’ve flashed the MD-01 several times, and it has never been a problem.
You’re mentioning USB to RS-232. My rules of thumb when working with RS-232:
Avoid using a laptop if possible. The voltage requirement for RS-232 is a wide range, but some laptops deliver voltages in the low end, or even below the lower limit. If you must use a laptop, keep the charger connected the whole time. That usually increases the voltage delivered. If using a laptop, you’re probably using a USB attached serial port. Your laptop may have one USB port that has a battery symbol next to the USB symbol. Some people report that that is the best port to use. In any case, it won’t hurt to use that port.
If you’re using a desktop computer, prefer serial ports on the main board or attached via PCI over USB serial ports.
That, said, I think we’ve flashed our MD-01 from a laptop, maybe also without the charger connected. 🙂 Don’t worry, just follow the instructions. Test the communication link first. If you can send commands to the MD-01 over that serial port from that computer, you’re probably good to go. Good luck!
73 & best regards,
Norvald, LA6YKA
Hi Norvald, LA6YKA,
Thank you for information – now I´m more calm. It was useful knowing that you have updated several times without any problems!
I will give you a feedback when done! 🙂
Thank you
with kind regards
john s.
Hi all,
I have a SPID BIG-RAS HR using a MD-01. I’ve been having unstable movement issues, mainly in the AZ and a little bit in the EL.
As i’m interested in LEO satellite tracking, i need a clean and fluid track to minimise signal stepping.
I assume there is an optimal power/pulse and start/stop times based on the weight of the antenna.
– 1.9 mtr mesh dish from RF Ham Design
– VHF and UHF cross yagi’s
Can anyone suggest a some setting that have been proven to work for tracking (continual and/or 2 sec pulse movement).
Thanks
Derek