Open bitglue opened 7 years ago
From what you're asking for it sounds like you mean “implement the server side”, or more unambiguously, emulate rigctld
.
I'm tempted to emulate some radio's serial protocol instead of rigctld
, because the rigctld protocol is rather complex (elaborate text output in some cases, multiple forms of commands) and irregular (inconsistent naming of things). However, that would be unwise since it would potentially lead to the client assuming we have that particular radio's limitations. And it wouldn't be expected to be served over TCP instead of a serial device, so that wouldn't work anyway.
Right, server. Derp.
I think 98% of the usefulness of the rigctl protocol could come from implementing 2% of it. Namely, changing frequency, and keying the transmitter. I know this because it's about all the SoftRock rigctld backend supports, and it's served all my needs so far.
If you're going to emulate a serial protocol, then you might as well just implement a hamlib backend instead.
I wrote a rigctld implementation in Python at https://github.com/w1xm/gnuradio/blob/master/dsheen/ssb_transceiver/rigctld.py that you might be able to use as a starting point. (It controls a GRC flowgraph, not ShinySDR, but that's abstracted away so you could probably adapt it to ShinySDR fairly easily.)
I'd like to be able to use fldigi or wsjt-x with my SDR. These programs support hamlib, and I can get them to control the SoftRock directly (set frequency, tx/rx, etc) and run a trivial gnuradio program to turn the SoftRock into effectively a USB radio.
Far cooler though would be using shinysdr as the radio. If shinysdr supported the client side of the hamlib protocol, then I could configure fldigi, wsjt-x, et. al. to control a receiver within shinysdr, which in turn controls the actual radio. This way I can have multiple receivers, continue to have a wide, non-crappy waterfall, etc.