An Isolated USB to Serial Interface for the TenTec Orion
I had previously built an isolated serial interface for my Icom IC736,
but I sold this radio when I bought an Orion for my 40th birthday. This
interface wasn't appropriate for the Orion which requires an RS232
interface as opposed to the Icom C-IV interface. For some time I
continued with this old interface providing just PTT & CW control
together with just a conventional serial cable between the PC and the
Orion, i.e. with no galvanic isolation between the two. It worked OK in
the home shack so the incentive to sort out a new isolated interface just
The incentive came when I operated in the 2007 SSB Field Day. I had
decided that taking a laptop would be simpler than taking the home
desktop PC so I 'borrowed' my work laptop and installed N1MM. Of
course, it didn't have a serial interface. No problem - I bought a USB
to serial converter, which worked fine - but I didn't test it with
full RF power. On the day I discovered that RF travelling down the coax
outer was sufficient to crash communications between N1MM and the USB
to serial converter. I'm still not sure whether the converter was being
crashed or that communications were disrupted and that N1MM wasn't
robust to this situation. Despite extensive efforts with ground stakes
and ferrites I was unable to solve the problem on the day. It was then that I
resolved to build an isolated interface to make sure this didn't happen
again. Especially since the future was likely to be USB in the home
In addition, I had never been completely happy with the old Icom
interface because true galvanic isolation requires separated power
supplies powering the electronics either side of the opto-isolation. On
the radio side you can generally use a supply from the radio, but on
the PC side a supply isn't easily available. USB provides an answer to
this problem because it can supply 5V. So this was a further incentive
to re-work the previous design.
Some inspiration and some problems
Because I was finding it difficult getting round to building this
project, in a moment of weakness I enquired about an SB1000 device
Martyn Lynch & Son was selling that appeared to do what I wanted.
At that time I was considering switching to Linux in the shack, so I
wanted to know which USB device was used so that I could be sure it was
compatible. Martyn Lynch kindly sent me the circuit diagram. From it I
found that it wasn't really suitable for my needs. Whilst it had a DB9
connector, that carried RTS/DTR and audio signals. The actual RS232
signalling exited via a 3.5mm stereo jack socket, and they weren't
true RS232 levels.
What I did find as useful information from it was that it used a Silicon Labs CP2102 'USB to UART bridge ', TLP521
opto-couplers and that it used a DC-DC converter to provide a
galvanically isolated supply to the radio-side electronics from the USB
5V. The latter would be very convenient because no supply cables would
then be necessary from the radio. Subsequently, I found N5BIA's website
where his 'IsoCat' design uses a MAX253 and transformer to do the same
thing. I decided to follow this approach as a bit of research showed
that these parts were readily available.
Which USB converter chip?
I've already mentioned that the SB1000 used a CP2102, which does claim
to be Linux compatible. N5BIA used an FT232BM device and some
research showed that these devices were also compatible and more easily
available in the UK. The USB to serial converter I had previously
bought was also found to be using the FT232R chip and I confirmed it
worked OK with Linux. The clincher came when I discovered the UM232R
development module, obtainable from Farnell.
I didn't really want to have to get into dead-bug construction with a
28-pin SSOP package, and this module solves that problem by providing a
module that fits a standard 24-pin DIP socket.
Speed is of the essence!It was decided that the easiest way of ensuring correct RS232 levels to the Orion would be to use one of the MAX232 variants.
I agonised for some time over which opto-couplers I would use, and in
the end figured that surely the ones used in the SB1000 circuit diagram
would be good enough? These TLP521 devices are very convenient because
they're simple (no transistor base bias required), and can be obtained
as quad-packs. How wrong I was!
The prototype was breadboarded, I shan't give the circuit here, to
verify operation. It didn't work; or at least I couldn't get N1MM on a
Windows laptop to talk to the Orion. To diagnose the problem I ran Putty
on two PC's and joined their serial ports via a homemade 2/3 swap
serial cable. It's then possible to set the baud rate and send tty
messages across the serial cable. Once I confirmed that worked, I
instead used the prototype USB to serial converter at one end. I
discovered that it did work, just that it could only communicate at up
to around 5kBaud. The Orion needs to operate at 57.6kbaud, and this
cannot be altered. This is unusual for an Amateur transceiver. Speeds
of 1.2k/2.4k/4.8kbaud are more usual.
I took the prototype to work with me so I could get a scope on it and
see where the problem was. It was the opto-couplers. The following
diagram describes the problem.
The transistor is wired as a pull-up, so that when it conducts the
load sees a low resistance to supply. But when the transistor is
turned-off the load is connected to ground via the resistor. The
relative time constants trise and tfall
depend on these resistances, the load resistance, and the capacitance
at this node. Usually, the resistor has much greater resistance than
the on-resistance of the transistor, so tfall would be substantially worse than trise in this circuit. In my prototype, at high baud rates the signal couldn't get to zero before the next data bit came along.
Of course, the resistor value could be reduced to increase speed, but
this means that more transistor current is required to pull-up and this
is prohibitively large at the speed required by the Orion. The better
option is to use push-pull transistors, i.e. one to pull-up and the
other to pull-down. It turns out that devices exist that solve this
problem. I ended up using some Fairchild 'optoplanar' high-speed
logic-to-logic opto-couplers. These are available with either CMOS or
TTL output levels. Since the MAX232 wants TTL levels the decision was
made for me.
Using the new opto-couplers I was able to demonstrate serial
communications between two PC's at up to approximately 400kbaud. A
healthy margin. In fact the speed is now limited by the MAX232 rather
than the opto-coupler.
The final circuit
The final circuit is shown below, which in the end was quite simple.
The MAX253 basically generates a square-wave signal into the
transformer from the USB 5V supply. This is then full-wave rectified
and smoothed to provide the galvanically isolated supply for the
MAX232. Power FETs are used to provide PTT switching on RTS and CW
keying on DTR.
CTS and RTS at the DB9 connector are wired to the MAX232 and
looped-back on the TTL logic side. As far as the Orion is concerned
it's always clear to send if a request to send is sent. DTR is
permanently pulled-up. TXD should idle at -12V and pulse to +12V with
data. Conversely, at the UM232R RTS/CTS and DTR/DSR are not looped-back
because they cause continual interrupts to be serviced that could cause
In case you saw version 1.0 of this project, version 1.1 solves some
EMI issues. Two problems came to light: I was getting interference from
the unit on 10m & 15m, and it was prone to crashing when
transmitting on 10m with antennas close to the shack. So much for the
The majority of the 10m interference turned out to be due to the USB
lead radiating directly into the antenna, and the reciprocal of this
effect was the cause of the crashing. USB connections comprise supply,
ground, and differential data wires within a separate outer shield.
Conventionally, the shield is connected to ground at one end only,
normally the PC or hub end. On the UM232R the shield is not connected
to ground. I found that doing so completely killed the interference on
10m, and it didn't crash anymore when transmitting. This means there must
be a significant common-mode route to the USB data signals. Either the
differential USB signals aren't very differential, or data is getting
onto the supply/ground wires. This problem isn't confined to my
isolated interface either. I built a Winkeyer USB from a kit (which
uses the same FT232R device) and this also causes me interference on
10m because the shield isn't connected at the Winkeyer end. The
rationale for not connecting the shield is apparently to avoid earth
loops via other USB peripheral devices, but in this instance we're
actively trying to break the loop from DC upwards, so this is
The remainder of the interference was caused by the switching power
supply. The first change was to ground pin 3 on the MAX253, which
causes the switching frequency to drop to about 200kHz. This helps
reduce the level on 10/15m because higher harmonics are required to get
there. Next a 10n capacitor was added across the output of the MAX253
into the transformer. This rounds the edges enough to have a
significant effect on 10m harmonic level. The down-side is that the
voltage output drops to 4.5V, but this is still sufficient for the
MAX232. Finally, the biggest improvement, and the only way of
completely eliminating 15m interference is to insert a common-mode
choke between the smoothed switcher supply and the radio side. I
confirmed that differential choking alone didn't work, even in the
ground lead. As 'belt & braces', a 10n capacitor is added across
the output to form a differential-mode filter against the leakage
I'm sure that at least some of the interference issues I was seeing was
due to my use of a Windom antenna, which inherently has issues with
keeping the feeder from radiating. If the feeder radiates then all of
the earthy side of the radio can radiate or receive signals. It's
obviously then more important (and more difficult) to isolate the PC
from the radio at RF. At least I now know that I have very good
isolation across this interface. It's completely bomb-proof and
interference free now with any antenna.
In case you were wondering what I used to draw the schematic, I used "gschem", part of the gEDA
suite of tools for PCB design. As far as I'm aware these are Linux
only. Maybe one day I will create a 'proper' PCB for the design!
The photo below shows the construction. The board was some prototyping
material that Mark (G4AXX) gave me to try. It's basically plain tinned
copper clad on one side and a 0.1" pitch square land areas on the
other. You can see the cut in the top-side ground-plane to separate the
radio ground from the computer ground.
I removed the USB connector from the UM232R module and soldered a USB
lead directly to the UM232R PCB. A cable gland keeps the cable in
place. It was actually quite tricky finding one the right size. I
eventually found one at Rapid Electronics.
I could have simply made a cut-out in the box to allow a USB lead to
mate with the existing UM232R USB connector, but the connector shield
must be isolated from the enclosure. The final arrangement owes as much
to the V1.0 design than anything else.
The astute will see where I located the original opto-coupler devices!
Since I built this isolated interface Firchild has discontinued
manufacture of the 74OL600x devices, which is a real shame. A possible
alternative might be the Isocom H11L1 available from Rapid Electronics.
It would be necessary to add inverters to the RTS/DTR outputs from the
UM232R (or re-program the UM232R internal EEPROM to invert these
signals). I stress that I haven't tried these parts, so I can't vouch
for their effectiveness. Let me know if you've tried them, or have
found a better alternative.
It's been pointed out to me that the Orion uses hardware flow control,
i.e. RTS/CTS, and that my interface doesn't. Initially I was sceptical
that the Orion's UART actually
used hardware flow control, but RTS/CTS are wired all the way through
to the processor. That doesn't necessarily mean it is used by the
firmware, but it's difficult to argue against it. Nonetheless, this
interface does work. It's
also necessary to discard hardware flow control if you want to do PTT
and CW through a single USB/serial port. That's also frowned upon by
some because there is then contention on RTS & DTR. The purists say
you should use a separate serial port. Again, all I can say is that it
I've used this interface successfully with N1MM on a Windows laptop and
a desktop, and with TLF on a desktop running Fedora 11-14. Unfortunately,
it doesn't work with CQRLog on the same Fedora desktop, despite the
fact that both it and TLF use hamlib. By default hamlib uses hardware
flow control for the Orion, which needs to be changed to "None" for it
to work. In TLF set the following in the local logcfg.dat file:
You can test hamlib using the rigctl utility that comes with hamlib. Use the following command:
rigctl -r /dev/ttyUSB0 -m 1608 -C serial_handshake=None -C rts_state=OFF -C dtr_state=OFF
type "f" and you'll get the current frequency.
I think CQRLog doesn't honour the hamlib settings it thinks its making
if you try to turn hardware flow control off. It's the only
explanation, but I can't get any interest from the authors.
I use cwdaemon with TLF for CW. In which case you need to run the following as root prior to starting TLF.
cwdaemon -d ttyUSB0
What about some audio?
My previous Icom serial interface also included audio routing and
isolation in the same box. I decided to move away from this
'all-in-one' philosophy, having already experienced compatibility
issues upon changing rig. I now had an isolated serial interface, but
what about other connectivity?
An 'audio isolation' box was built as shown in the schematic and photo below.
Two stereo 3.5mm jack sockets provide four audio channels, which are
all isolated via four 600 Ohm 1:1 transformers, and exit via a common-mode choke using an 8-pin
DIN connector. Thus, the chassis is at 3.5mm jack ground potential and
the ground at the DIN connector is isolated from it. I also RF
decoupled all channels to local ground using 10nF on the PC side. Tests showed that this did not noticeably restrict the
Four channels theoretically allows this box to be used for SO2R;
transmit audio being directed to radio A/B via the stereo L/R, and
recording of both radio receiver's supported. In my setup I join both
mic channels together in the cable to the Orion AUX socket and also
connect L/R AUX-OUT to the sound card, i.e. SO2V setup.
Isolation transformers on their own won't necessarily sort out RF
feedback problems. The inter-winding capacitance of the transformers
RF will go straight across. You could use Faraday shielded
transformers, but I even doubt they would help that much. The main
purpose of transformer isolation is to avoid hum inducing earth loops.
Series inductance is the best weapon to discourage RF flowing that path
to ground, e.g. by winding cables onto ferrites, and this is exactly
the function of the common-mode choke. It's the equivalent of many,
many clip-on ferrites, but at a fraction of the cost.