Figure 1: Approximate tone decoder IC circuit
When I was visualizing this project, I immediately thought of those cheapie tone encoder/decoder chips, that you can get from online electronics supply houses for a buck each. But then …
I realized … I’ve got a Pi2, GPIO, and some nice DTMF libraries for C++. Who needs hardware?
OK, I’ll need to have a watchdog or two, to pull the switch if the controlling Pi goes AWOL. Those should be external and physical. And – I’ll probably build the keyboard based CW capability into the system for the case where conditions make it manditory. But mostly – the idea is to be able to use a straight key or my nice Bencher paddle, so that I don’t bore my fellow CW afficonados with bland, colorless CW from a machine.
The software DTMF would be used in two places. First, it would BE the CW, in that the internal DTMF encoder/decoder could take the audio CW signal directly from the Linux sound system, which in turn would have gotten it from the TRX Opus program, which in turn should have recovered it from that tablet operating in a foreign land – via UDP – subsequently passing a logic state to the appropriate GPIO pin via the WiringPi GPIO API. Whew! Then, the relay driver and fast 5V mechanical (or solid state?) relay could key the Alda 103 keying input circuit. Secondly, the DTMF could be used for rig control. A code could be devised to relatively easily provide 8 bits of data (256 possibilities without even muxing) – of control to the rig.
Rig control tones could be relatively long (allowing for the samples that must be taken) – and for the Alda’s physically keyed input, an alternate means to “decode” the CW borne of the DTMF could be devised – one that didn’t require much sampling and would therefore be the quicker fox.
The CW tones would be returned to the foreign node, as effected by the keyed output, such that the operator could hear what was actually sent, if desired. On the receiver end, those “actually sent from the relay” CW notes could be decoded to text, so that the latency would not affect the ability to make sense of the sidetone while sending. There will be latency, but mostly it should occur “as a block” – similar to the delay for curse words in broadcast stations, but shorter.
A DTMF keep-alive tone could be transmitted as well, to interact with a second watchdog, so as to return to a known safe state, or power down if necessary.
The receiver would use the same software DTMF, the same UDP streaming software, the same GPIO. In the case of the receiver GPIO, it would take the keyed input from the paddle or straight key, if a built-in keyer were to be included, or from an external keyer if not.
The Opus codec is very interesting. It (apparently) derives partially from the SILK algorithm (of Skype fame) – and another low latency codec algorithm called CELT. Opus switches back and forth between these (or some combination therof) as latency conditions warrant.
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 connection with that.
WB8LZR 