From: Kerry Clendinning
Subject: Serial IR experience
To: spcecdt@armory.com
Date: Mon, 19 Aug 96 16:49:26 CDT

I found the schematics for IR-to-serial and serial-to-IR devices some time ago, 
but had resisted taking on the project of building them because I no longer own
the kind of electronics equipment needed for this kind of thing.  But no
off the shelf products would do for what I want, so I finally broke down and 
bought the parts.  I found all the parts for the receiver unit first and was missing
one chip for the transmitter.  I built the receiver that night, about 4-5 hours,
laying it out on a generic project board.  It's 7 chips, a handful of discrete
components, and has just one adjustment to tune the IR carrier frequency.

After putting the whole thing together, I checked the power supply going to the
sockets for the chips, decided it looked okay, populated the board and plugged it
into my Mac.  From the beginning I could get a stream of serial data every time I
pressed a button on a remote control, so I assumed it worked.

The next night I came home with the other parts for the transmitter, which took
just two chips and seemed much more straightforward.  So I thought.  After 
construction, the transmitter would do nothing at all.  I checked and rechecked
wiring, but found nothing to explain the complete void of response from the
circuit.  Using my only sophisticated electronics tools--a DMM and audio inputs
to a portable stereo, which I actually use from time to time to LISTEN to signals--I 
eventually determined that the input stage expected higher voltages than the Macintosh
serial port outputs.  Fortunately, part of the receiver project was a MAX232 chip 
which compensated for the problem and eliminated two diodes, two resistors and a 
nand gate being used as an inverter.  (The design for the transmitter had come 
first, and didn't require actual RS232 levels, so the MAX232 wasn't necessary in
its circuitry, but is a welcom addition for anyone wanting to interface to a Mac.)

This injected a little more life into the circuitry.  At least when I sent serial
signals to it the first stage seemed to pass signals.  Trying to adjust either 
the one-shot or the modulation frequency didn't help the fact I still saw no
output whatsoever.  More guerilla debugging tactics led me to find that the
potentiometer in the one-shot circuit was not working--just an open circuit.
Fortunately I had a replacement 100K pot in the diminished but ever present parts 
bin.  Let there be light!  Now the circuit seemed to do something.  But what?
With the two potentiometers needing adjustment before the circuit could actually
work, there was no chance of seeing it control a VCR or CD player, let alone the
fact I had no software to generate the long strings of binary data which it 
takes to drive the thing.  The input from the receiver is, unfortunately, not the
same format as what needs to be sent to the transmitter.

So I set out to tune up the circuit.  The purpose of the one-shot is to detect
start-bits and delay until the data bit arrives.  It's really a rather ingenious
circuit.  You send a 7-bit serial word, with one start bit and one stop bit in 
the traditional sense.  But you add inside the 7-bit word two other start bits and
stop bits, leaving 3 bits for data.  Here's a pictorial:

            +ST+     +S3+     +S6+
            |  |     |  |     |  |
     -------+  +D1+  +  +D4+  +  +D7+  +---------
                  |  |     |  |     |  |
                  +S2+     +S5+     +SP+

ST and SP are the start and stop bits provided by the Computers's serial hardware, 
set to 7-bit, 1 stop-bit.  S2 and S5 are stop bits provided by the software sending 
to the device, and S3 and S6 are start bits of the same sort.  D1, D4 and D7, drawn 
at 0-level here, would be either + or - and contain data provided by the software 
to switch on or off the modulated IR signal.

Now, the simple little one-shot is all it takes to grab just the data bits out
of the string of serial characters, instead of requiring a UART or anything.  You
run the serial port at 3 times the resolution required by your remote control
with the densest pulse rate.

Well I reasoned out how to adjust the one-shot without a scope: send a stream of 
the serial words that signify zeros (control^R, 18, or 12h), and find where the 
potentiometer can be set so that no IR output is sent.  There were two such 
ranges -- the appropriate delay to read the data bits or an inappropriate 
location which was always finding the stop bits.  By sending a signal with 
one or more bits set (such as ^[, 27, or 1b) I was able to bring the one-shot 
into proper adjustment, I thought.

I assumed I could vary the one other setting--modulation frequency--until I got
a device to respond to an actual remote control code being sent, so I went on to
start constructing the string of bytes which would constitute a signal recognized
by one of my components.  The first thing I needed to do was calculate, or better
yet, empirically derive the rate which I needed to encode the string of bits that
would comprise the signal.

It seemed I should be able to generate a modulated square wave with a pretty simple
sequence sent to the serial port, a series of [ (5Bh) and ^R (12h), then sample it 
from the IR receiver, and be able to figure out from there how many serial pulses 
constitute each of the IR pulses read from an original remote control unit.

Well, when I started observing the square wave signals, the data seemed to indicate
the transmitter was not working well.  A square wave came back looking like this:

      Source      +-------+       +-------+
                  |       |       |       |
            ------+       +-------+       +-------

      Receiver:   +-----+ +-+     +-----+ +-+
                  |     | | |     |     | | |
            ------+     +-+ +-----+     +-+ +-----

I could only suspect that my adjustments of either the one-shot or the modulation
frequency had not been accurate enough.  Further attempts adjusting either 
potentiometer never help.  I finally got the bright idea to use another IR sampling
device I have called a VideoEdge to sample the signal sent out by the transmitter.  
This would eliminate one variable, the receiver unit.  Sure enough, the transmitter 
was actually working fine.  Oh no.  This meant the the receiver, a much more 
complicated circuit with 3 shift-registers, a counter, two flip-flops and 4 gates 
must be at fault.  I worked and worked with it, checking and rechecking wires, 
switching out components, and beginning to question the design.

One of my first suspicions had been that it might be a bit-ordering problem with
the shift registers or how I read the bits in the program on the Mac.  I couldn't
determine from the documentation and had missed a comment in the sample program
that made this clear.  The program included runs on SCO-unix, and rather than port
it, I was planning on a somewhat different approach on the Mac.  I later found that 
the example program indicated that the order was the same a the serial port which 
means, unbeknownst to me, that the low order bit is shifted out first.  If I turned 
around every 8-bit sample in the input from the receiver, it now indicated that the 
transmitter was indeed sending a square wave as directed.  Both units were working 
fine, and had been since initial construction!

Calibrating the one-shot was described above.  Calibrating the modulation frequency
of the transmitter was easy once I sampled a remote control and played it back, just
by maximizing the distance and accuracy.  Successfully sampling a remote required 
getting the baud rate adjustment on the receiver set correctly.  This can be done
by sending all 1's from the coarsely adjusted transmitter back to the receiver, and
adjusting the baud rate until all 1's (a constant stream of DEL characters) is
coming from the serial port.  Note that the receiver communicates with 8 bits, while
the transmitter communicates with 7 bits.  If you can't set one serial port to run
both ways simultaneously you'll probably have to use two different ones.

I chose 19.2K baud for both devices.  With both units working, my square-wave idea
did help figure out the empirical ratio for adjusting a sampled bit stream to send
it back to the transmitter.  It turns out to be 2/3.  The sampled pulse widths must 
be multiplied by 2/3 before converting to send out the transmitter.

I hope this experience may be of use to others trying to build the devices.  If you 
need pinouts or detailed information on the chips used to build the projects, check 
out Harris Semiconductor's page on the web:     http://www.harris.com/
(I'm not associated with Harris in any way, just found their website useful, and,
incidentally, used a few of their 59 cent flipflops.)

Kerry Clendinning
Unison Software