I have a couple old analog rigs here in the shack, and I thought it’d be nice to remote them to the easy chair in the living room, or the dining room table, or the back porch deck. Just to complicate things, I decided that I couldn’t revert back to Windows to do this task, and additionally I wanted it to be at least *feasible* to use the remote radio capability from an internet connected place (like a hotel in another state).
Immediately, I determined that most of the ready made gear for this purpose is Windows oriented. So, I’d have to homebrew. Amazingly, I think I can put almost all of the functionality in software! The only hardward will be the two relays and the driver board (just an NPN transistor for each relay might suffice).
The first thing I did was to set up the UDP internet streaming protocol program. I used a program from this site:
It compiles to only 18k bytes. That’s less than the readme files of most streaming servers! It uses Opus, the new and upcoming audio codec from the Xiph people, open source audio advocates, birthed in 2012. It’s said to best MP3 and its friends on most quarters, including the all important internet latency issue. Everything inside of the dark green panel is Pi based software, excepting for the Cirrus card. I’m not including that as “hardware” for the project because I have it for SDR and other things (music) already.
I have seen products for remote CW op, but they most often rely on using keyboard codes, partly to avoid the latency issues between dots and dits. However; listening to Youtube videos all the time (put some up myself) – I realized that if the bandwidth is anywhere close to sufficient, the CW latency issues could be handled by special low latency codecs for audio. I decided that the whole thing could just be streaming audio – including the rig control! What a simplification that would be.
For a couple days, I’ve used one Pi (at the Alda 103), and another (my homemade tablet Pi that I carry around) – to listen to the streamed Alda audio (mostly SSB, but some CW) as I work around the house. It’s quite excellent.
The UDP streamer is something anyone can try, whether they are intending to use any remote functions or not. On Ubuntu 14, the process is simple. I just download the tarball package from the link shown (GPL license), unpack it, and then install dependencies, which are (approximately):
- sudo apt-get install build-essential libao4 libao-common libasound2-dev libdaemon libopus-dev libortp-dev libsndfile1 pulseaudio pavucontrol
Then I go into the directory where the files were unpacked and type “make” – and if there are any errors then I know it’s probably that I have missed installing a dependency package. The error message should always give a hint as to which is missing.
The result of the compilation should be “rx” and “tx” executables – each weighing in at 18 kbytes. Lilliputian by my standards!
Then on the receiver (in my case the portable homemade tablet) – i simply type ./rx. It sits and waits for a (UDP) transmitter to call. Then, on the transmitter side (UDP packets, not RF!) – I type:
- ./tx -h 172.16.1.36 -p 1350 -b 128 -r 48000
This means “transmit the audio to 172.16.1.36 (the tablet) on port 1350, using a 128k bitrate, and 48k sample rate”. On a home subnet, this results in very nice quality audio.
Running the pavucontrol application (pulse control app) – I can see the following in the recording tab:
- ALSA Plugin [tx] application
I can associate that entry with any capture or playback device that I want. I associated it with the “line-in” selection. On the receiver, running pavucontrol shows this in the playback tab:
- ALSA Plugin [rx] application
I can associate that entry with any sound card output I want. I selected the “line-out” selection from the drop down combo box. That plays my Alda 103 CW/SSB audio out to the speaker on the homemade tablet. Note that while I’m using Pi based computers, any computer can do this part of the plan (i386, amd64, etc).
Note: the author does not have a recent, applicable formal background in circuit building, or battery related issues, so this is presented as the work of a hobbyist, and is not meant for duplication by others. Readers should look elsewhere for design advice and info.
Xiph and Opus are at https://www.xiph.org/ – and have no association with this author or site. Likewise, the TRX program is developed by its author at the indicated link, and has no affiliation with this site or author. Raspberry Pi is a trademark of the Raspberry Pi Foundation, and this author and site has no affiliation with them.