An Isolated USB to Serial Interface for the TenTec Orion

G4KNO
V1.0 18/11/09
V1.1 25/04/11

Motivation

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 wasn't there.

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 shack.

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 t_rise and t_fall 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 t_fall would be substantially worse than t_rise 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 CW stutter.

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 supposed isolation!

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 irrelevant.

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 inductance.

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!

Construction detail

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!

Parts availability

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.

Miscellaneous

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 works!

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:

RIGCONF=serial_handshake=None
RIGMODEL=1608
RIGSPEED=57600
RIGPORT=/dev/ttyUSB0

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 audio spectrum.

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 means that 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.