Opto-isolated level converter RS232 to TTL (and vice-versa)

Plenty of today's microcontrollers have UART abilities to communicate with a computer's serial port via software protocol, which is basically RxD and TxD line to be broadcast. Usually, the microcontroller's I/O ports are TTL-style with unipolar 0V/5V voltage levels, while RS232 specifications require bipolar pulses about +/-12V. Standard solutions like MC1488/1489 or MAX232 may be provide little protective features...
Now here's my proposal on RS232-to-TTL conversion with optoelectronic separation, not to be confused with those ultrasimple one-coupler-per-line-crap, published elsewhere! This concept performs real bipolar signal processing and regeneration, according to EIA-232 specifications!
Circuit | Details | Parts| PCB | Remarks | Index

Isolating RS232-TTL couplerPic.1:
  • Signal conversion from RS232 level to TTL/CMOS logic levels
  • Electrically isolated via optocouplers
  • Up to 57.600 bps with cheap standard components
  • No additional voltage nor complicated converter technology needed at the DTE-side!
  • Safety-replacement for MAX232-designs


    Circuit



    Pic.2: Rugged optoelectronic converter RS232 to TTL



    Circuit Details

    Serial Interfacing
    Starting from the DTE-connector X1 (9-pin D-SUB, female), we find RTS+CTS and DTR+DCD+DSR directly connected to each other. By that, the stupid DTE "believes", it's connected to an external serial device that is always ready to receive fresh data (sometimes referred to as a "RS232-masturbator-bridge"). Thus, serial connection can be established in pure software protocols (e.g. Xon/Xoff), as well as some originary hardware modes will work as well. Most of all, there are still only RxD and TxD signal lines to be connected with the DCE device.

    One main objective for my RS232-TTL-Converter was to provide RxD-input ot DTE-side with real bipolar data, according to EIA232-specifications, without additional power supply. In fact, DTE must deliver positive and negative auxiliary voltages, needed for RxD-regeneration, by itself. (To me, additional DC/DC-converters or power supplies didn't make sense for cost- and some technical reasons, too.) So, are these requisites all contradictory? "Not necessarily!"
    As a favourable "side effect" from the DTR+DCD+DSR interconnection, DTR-output is set to a "logical-0" (or "Mark") state immediately after the respective serial port was opened. This positive voltage is "tapped" by D1 to recharge an electrolytic capacitor C1, that could be seen as a small battery. (In addition to DTR, positive levels of TxD are also utilized by the way of D2; this is mainly to improve load balance on TxD.)
    To gain some negative voltage, we have to take TxD-output, which drops to -12V in idle state (stop-bit condition) - and while transmitting "logical-1"s, thus charging C2 via D3 to a negative auxiliary charge. Unfortunately, when transmitting "logical-0"s, TxD will rise to +12V, and worse energy balance for that negative auxiliary voltage. Yet, in many realworld configuration of hardware and protocols, this proposed method of gaining auxiliary voltages works pretty well!

    Transmit TxD  to TxD-TTL (µC input)
    Depending on the actual state of TxD, there is always one of two antiparallel transmit-LEDs in PC1/PC2 active. Thus, at TTL-side, only one phototransitor becomes conductive at the time. It triggers either the "set" or "reset" input of a discretely wired R/S-flipflop (IC1a/b). On the output we now have clean, sharp-edged digital pulses. Regenerated TxD-TTL is led to the output line (pin 2 of X2: TxD-TTL).

    Receiving RxD  from  RxD-TTL (µC  output)
    Switching either positive voltage with PC3 or negative voltage with PC4 directly to the RxD-input recreates a bipolar data signal for RxD. At the TTL side, logic levels coming from the controller (pin 3 of X2: RxD-TTL) are buffered and inverted by IC1c and once again by IC1d to drive transmitting-LEDs in PC3/PC4 in push-pull mode.

    Power supply
    This is +5V connected to Pin 1 (GND) and Pin 4 (+5V) of X2. The source should comply with basic TTL requirements. Power consumption on the TTL-system of the RS232TTL coupler is about 20mA.

    Parts

    Capacitors

    C1,C2		220µF/16V (electrolyte)
    C3		47µF/10V 
    C4		100nF ceramic


    Resistors

    R1, R2, R3	330 
    R4,R5		2k2
    R6,R7		220


    Semiconductors

    D1,D2,D3	1N4148 
    		(Alternatively BAT46 shottky for less voltage loss)

    D4		1N4001 (protection from false polarity, optional)

    PC1-4		CNY 17-I 

    IC1		74LS00 (4x NAND - sorry, MUST be LSTTL!)


    Other Material

    9-pol. D-SUB female for direct soldering (see layout)
    3x DIL14 IC-socket
    circuit board 65 x 40 mm


    PCB

    Below is my layout suggestion for Isolated RS232-TTL-Converter as a module. Should be no hassle to build on a veroboard, but take care of the D-SUB-pinning which is in fact no 2.54mm grid...
    I strongly recommend the use of high quality sockets for all semiconductors.

    Bild 3a/b: RS232TTL  - Layout and site plan @ 200dpi
     

    Remarks

    Measuring the voltage level at plus pole on C1 and minus on C2 against serial GND should indicate something around +6...12 Volts resp. -6...12V against serial GND (see Pic. 2), when serial port was opened by regular software.

    Testing with Scope on the following signals: Regenerated RxD at RS232-site. It should not "underrun" +/- 6 Volts while data is received from the TTL-side (as mentioned before, minimum shift would be +/-3V). Other interesting measure points are the collectors at PC1/PC2. When DTE transmits data, you should see a ground-referred, "almost digital" pulses. Due to the finite steepness of the photocouplers, the signal might get softer with higher transfer speed - nothing to worry about, since the following RS-Flipflop will always regenerate some sharp-edged, debounced digital waveform for TxDTTL, as long as the input was reasonably symmetric.

    Functional testing is really quite simple. Connect the RS232TTL to the computer's RS232, connect TTL site with stabilized 5V supply, and short-circuit TxDTTL with RxDTTL. This "loopback" will receive every character coming from TxD and immediately send them back to the computer via RxD; by way of all the optocouplers, signal regeneration and driver stuff.
    Get your terminal programme running and choose, for a start, some slower baudrate at the designated COM-port, switch to software protocolled transmission (Xon/Xoff) and turn off the local echo. If loopback works, any character entered at the keyboard should be reflected on the terminal screen immediately (not at hyper-terminal...), foremost with no transmission errors. Increase baud setting to check for the highest transmission rate possible on that specific hardware. Loopback should work with a CNY17-1 up to 57.600 bps.

    Other couplers...
    As many photocouplers in DIL6 outline have the same pin assignments, this circuit seems to work well with many couplers of approximately 50%...200% of CTR. You may try to use some: 4N25, 4N36, CNX62, CNX83, MOC3012. To keep symmetry, always two identical optocouplers should be used for every channel.

    Considerations
    In a regular serial communications environment, some negative voltage can be drawn only from TxD-line, which is, at least in idle state, delivering permanent negative voltage. Unfortunately, the moment as TxD begins to transmit some data, there will be positive voltage pulses, that certainly affect negative voltage gain...
    In a worst-case scenario, when TxD transmits longer sequences of logical zeros, interrupted only by the obligatory start-bits (1/10 duty cycle in 8-N-1), C2's charge may not be refreshed sufficiently. Additionally, if the microcontroller decides to reply with lots of logical 1's (much negative voltage demand for RxD!), then unfortunetely C2 could not deliver any more and transmission may be interrupted in such a situation.
    Being aware of that, I performed some comprehensive test-driving on that circuit. I built two identical RS232-TTL-couplers and cross-connected them (RxDTTL#1 goes to TxDTTL#2, and vice-versa). With that crossconnection (null-modem-style), several transmission modes were tested by means of interlink and filelink coupling, involving some variety of old and new RS232-cards, onboard, on-ISA and on PCI-card.
    To cut it short: 57.600 bps was no problem under several transfer modes and different streaming modes.
    Seems, that some of the software controlled RS232-communication schemes are basically half-duplex, so C2 could recover at least when TxD is idle. Additionally, IC1 does a pretty good job in signal recovery.



    Links

    Datasheet CNY17-X

    Overview RS232

    Complete RS232 coupling, the hard way...


     © 2004/2005 Julien Thomas - revision: 12/2005