An Icom IC736 to PC Interface

Andy Summers, G4KNO:

Summary

This article documents hardware functionality that provides an isolated interface between an Icom IC736 transceiver and a PC.

The interface was built to operate specifically with Writelog, although the interface is pretty much standard across the better known logging programs.

Likewise, other Icom transceivers probably have identical interfaces. I can’t vouch for this – I only own an IC736! Certainly the CI-V interfacing should be usable with other Icom radios.

The hardware provides the following features:

The following low resolution pictures show the hardware as I built it. The front panel is yet to be labelled (I’m still trying to find a good quality, inexpensive method). The shot of the innards clearly shows the split between analogue and digital ground planes.

Background

I had already built a simple non-isolated CI-V interface to allow frequency control and reporting to a logging program. It wasn’t until the Granta Contest Group bought a copy of Writelog that I realised it would be useful to use the sound card features that it provided, rather than rely on my MFJ Contest Voice Keyer.

The microphone interface in particular requires transformer isolation to avoid an earth loop, which can be responsible for hum and RFI problems. Ideally, there should be no DC earth connection between the transceiver and the PC so it was decided to go the whole way and create o fully isolated interfacing box – if possible (more on this later).

Writelog provides the option of CW keying on the DSR line of the same serial port to be used for CI-V interfacing. This results in a much neater arrangement compared to my old arrangement of keying via the LPT port.

The IC736 does not provide any means of monitoring the transmitted audio. This is inconvenient when you want to review recorded messages, particularly when recording them ‘on the fly’. It was therefore decided that optional relay switching of the sound card audio to the headphones would be useful.

All these features were to be built into one compact desktop unit.

Circuit description

There are two schematics, as hyperlinked below:

The main board uses header pin style connectors. These are connected to the front and back panel mounted components in a wiring harness style. This provides for easy disassembly if required.

Bills of Materials referencing UK distributors are also available:

The schematics were drawn retrospectively in Eagle, which is an integrated schematic/PCB layout application. Despite this, no Eagle generated PCB artwork is presently available. The original PCB artwork was done freehand using a permanent marker pen.

The CI-V interface uses a low voltage version of the popular MAX232 (IC3) to convert unipolar CMOS levels to bipolar RS232 levels. Transistors Q2 & Q4 and their associated circuitry are a direct copy of the ‘REMOTE’ interface in the IC736. Their task is to multiplex unidirectional signalling into bi-directional signalling. In theory, several Icom radios can be connected in parallel onto the same 2-wire interface and selectively communicated with by data addressing.

PC->TRx data at CMOS levels stimulates the light emitting diode in opto-isolator IC5, whose ground is returned to the PC (DGND). The photo-transistor’s emitter in IC5 is returned to TRx ground (AGND). The PC’s ground and the TRx’s ground can be at different potentials and it won’t have any operational effect. That’s the point of opto-isolation!

The same principle is used for TRx->PC data (IC4), but here we run into a problem. A +5V supply is required to be able to generate the CMOS levels expected by IC3. Additionally, IC3 needs a supply with which to generate the RS232 voltage levels to signal to the PC. If this +5V supply is derived from the radio it cannot be guaranteed to be +5V unless DGND is connected to AGND. This somewhat defeats the object of having any opto-isolation!

One possibility is to use the RS232 data and control signals to derive a low current power supply, but this requires a fully compliant RS232 PC interface, which often isn’t the case on laptops. I chose to separate out digital from analogue power and ground and provide jumper options to either connect DGND to AGND and take power from the radio, or keep them separate and take power from the sound card electret microphone supply. It is essential that the MAX232 operate down to 3V supply and consume little current, hence the use of the MAX3232. This feature has not yet been fully tested, as I’ve had no need to. I point this out because there is a risk that inadequate supply decoupling could result in RS232 signalling noise in the microphone connection.

The PC can control the TRx’s PTT line via the RS232 RTS line. In this instance a resistor and diode clamp is used to convert to suitable unipolar levels for opto-isolator IC6. Q1 buffers the output, providing a higher current carrying capacity. The connection to the TRx is switched to provide PTT inhibiting whilst recording messages.

A parallel PTT circuit is used to energise relay RL1. This switches the headphone audio from the Rx to the monitored Tx audio from the sound card when transmitting. Thus the outgoing message can be heard in the headphones. Again, a switch provides the option of no monitoring.

An identical interface is used to provide CW keying on the RS232 DSR line. This connects to the straight key jack on the IC736, leaving the iambic keyer jack free.

1:1 transformers intended for modem applications are used to provide isolation in the two audio paths. Writelog provides the feature (if supported by the sound card) of looping-back the microphone to line-out. This means the microphone need not be hardware switched between the sound card (for recording) and the TRx (for normal operating).

The transmitted audio at the TRx interface is routed to a TBA820M audio amplifier (IC2) via a volume control. This provides adjustable audio monitoring.

Note that the enclosure’s chassis is connected to analogue ground. The microphone jack must be isolated from chassis. In view of my use of a standard PC multimedia headset, the logical choice for the headset connections would be 3.5mm stereo jacks but the only isolated stereo jack sockets I could find were ¼". I therefore use 3.5mm to ¼" adaptors.

A local +5V regulator provides local analogue supply, derived from the IC736 +13.8V supply.

Bugs

So far, the only bug I’ve come across is associated with the sound card line-in levels with Writelog’s CW decoder. Writelog provides the option of two decoders when operating SO2R, implemented via the R & L audio channels. Since, for the time being, I’ve commoned R & L channels both decoders operate on the mono audio. With the two decoders running in Writelog the audio levels are fine. Curiously, with only one decoder running the audio level is low. I suspect this might be remedied by not commoning R & L channels, but I haven’t tried it yet.

Comments

If you have any comments, suggestions, or maybe you’ve copied some or all of the design, I’d be pleased to hear from you.

mailto:andy_summers@ntlworld.com