When it comes to sound card “digital” interfaces for HF, there is absolutely no shortage of devices and opinions on how to get the job done. From an all in one solution like a RigBlaster or Signalink to various kits on eBay; there are a ton of options for transmitting blips, bloops, deedles, and other noises that come out as data on the other end. I, however, decided to go the DIY route for a couple of reasons:
- I already know how to build stuff
- less expensive than pre-made options
- satisfaction of DIY
- extra satisfaction of knowing it actually does something
- having a device work how I intend it
- I’m a ham, dammit!
Dubbed “Generic Sandwich Cookie” after someone noticed my junk bin pot resembled a trademarked sandwich cookie; it is actually a bit fancier than what’s actually required to accomplish the task and is really nothing more than an independent clone/modification of a design that’s been duplicated just about everywhere. Versions of this circuit are even printed in the ARRL Operators Manual on the chapter dealing with digital modes.
The first version of this was built in August of 2015 using a combination of parts ordered for the project and anything I had in the junk bin. Building circuits in an RF environment was new to me, so there was some trial-and-error as well as a couple of modifications made before it reached a point of “working comfortably”. Long-term lessons would revolve around the linear aspect of a 4N25.
The interface itself can be thought of two separate circuits, one entirely passive and one entirely active. Isolation for the audio is entirely passive, relying on just two transformers, an RF bypass capacitor, and a potentiometer. The main purpose of the transformers is to provide good DC isolation between your rig and your sound interface. I found that even with ferrites and shielding, I would get RF feedback if I did not provide a bypass capacitor.
The active part of the circuitry is powered by your serial port and rig and consists of a 4N25 optoisolator, a diode, a couple of capacitors, and a resistor. An optoisolator is a device that contains an IR LED and a phototransistor; in a sealed DIP package. The LED is driven directly from the RTS line of a serial port, in my case a CH340 based dongle, with R1 providing the current limiting and C2 providing some RF bypass. The phototransistor side consists of another RF bypass cap as well as a diode to prevent damage from any inductive kickback. Turning on the LED causes photons to build a charge at the exposed base-collector junction. Amplified by the current gain, it causes the rig’s (usually) positive PTT potential to flow to the ground; hopefully pulling it low enough to cause PTT to trigger. (More on that later)
Dealing with COM ports on Windows using a USB dongle has not been the nightmare so many OM said it would be. The barrage of statements I heard about changing COM ports must have been the result of always unplugging it. On both Windows 7 and currently on Windows 10 my COM ports only change if the device gets plugged into a different USB port (or the case of a complete system failure and OS reinstallation). Even this has the effect of each USB port having a specific COM port assigned to it.
Issues To Look Out For
Remember that transistors are actually linear devices, and a phototransistor is no exception. When I first built my interface, I ballparked a 470k resistor in series with the LED to provide the usual current protection. While this worked, my PTT line was not being fully dropped to ground and the rig would occasionally do some funny things like try to transmit on any frequency. However, when it was connected to an IC-728, it would not kick in to transmit at all. After verifying that the interface still worked with my 725 and that I could make the 728 transmit from the data port, I discovered the PTT line wasn’t being pulled all the way “low”. Reducing the value of the current-limit resistor solved this, as it allowed the IR LED to burn brighter giving a higher base voltage. Since the overall voltage/current you’ll get from a dongle may vary brand to brand, you may need to play with this value to get it to work for you. Buy a couple of 4N25s and a socket; it will make life easier if you accidentally burn one out.
600:600 ohm communication transformers are very common for this application, largely becuase they could be salvaged from many things and are cheap. However, most of these were designed with a limited audio bandwidth for telephone use. This can be an issue with some modes where you don’t touch your VFO and largely rely on audio frequency to control where you transmit. You can get wider bandwidth transformers in different impedences; which I don’t think really matters for the type of audio circuits we’re dealing with; but they do substantially raise the cost.
As I’m not trying to push data and just need the RTS trigger, the cheap Chinese CH340 based dongle has worked for me just as well as if I bought a $20 one. Windows 10 automatically detected and installed the proper driver for it as well. I did have some issues with reliably holding the RTS line using my motherboard’s USB ports, but this was rectified by using a USB3 port on a PCI-E card and has so far just been isolated to occuring with this motherboard. The real issue with them is they typically come with absolute garbage for shielding and cause massive amounts of QRM when plugged in. The cheap one I bought that came with a transparent cable clearly showed just thin foil and a handful of woven strands providing a shield; except it wasn’t connected to anything on either side of the cable! I solved this by carefully slicing the rubber that encased the module and removing it, but breaking what looked like a capacitor. It turned out to be the 12mHZ non-can crystal for the USB controller. Thankfully the board was designed to actually take a can, and I liberated one from a Baofeng programming cable. I soldered a much better quality USB cable on to the module that provided adequate shielding; and all of it’s QRM disappeared entirely.