Making Your Own IrDA device
I have some old cell phones, PDAs and other whatnots kicking about. So here I am working on IrDA today as its almost impossible to find a PC with it built in like it was in the '90s or you have to buy an expensive USB dongle!
One could take the easy route and buy a all-in-one module that does it all like the one below or you could fashion your own one from discrete parts. Guess which route I am taking?
Its going to be exactly the same, with possibly the addition of noise because anything you make yourself is going to be a lot bigger than the all-in-one modules. However making it myself gives me the ability to choose light wavelength, response frequency of the signal as well as decoding signals that are maybe not even IrDA signals (remote controls for TVs, other beamed data, etc ). I havent explored the converse - tasking the all-in-one modules as an IR remote.
 |
| Courtesy of DigiKey - [ ZHX1820 @ Digikey ] |
I managed to get the slowest protocol, at around 9.6KHz, working with little trouble. However, I am finding it hard to find a photodiode, or photo transistor that meets the speeds and that is at a reasonable price for the faster protocols that run at 100KHz ~ 4MHz so I may come back to the all-in-one device later.
Photo diodes such as the Vishay BPW34 will run at 100ns rise/fall times, these cost around $1.00 each so a bit little expensive when you consider its also going to need capacitors, resistors, amplifiers and so on hooked onto it (see the making section below).
 |
| Courtesy of DigiKey - Vishay BPW34 @ DigiKey |
Beyond these there are newer standards that I have never seen and these achieve 16Mbps, 96Mbps, and somewhere in the GigaHertz range and I think signal noise is going to become a large part of making these things using discrete components myself. Certianly prototyping it on bread board is proabably going to go out the window pretty quickly!
IrDA is built around layerd protocols. It starts at the physical layer that described, well, the pysical aspects of the data transmission. Infra-red light, at a certain speed, the angle and distance you can 'see' it from and so on. Then it moves to a layer that negotiates the 'link' or basically how two devices communicate with each other, finding new devices, and negotiating speeds for transfer. Then above that is the 'management' of the data which basically says how the data is to be split up and maybe shared in different virtual channels (for example maybe sharing data between two applications). Beyond the 'management' layer are a many number of layers that can connect to the manager and ask for data - the one I am interested in is IrCOMM which simulates a good old serial port and lets me send text to my remote partner.
 |
| Courtesy of Wiki - IrDA Protocol Layers |
Physical Layer (IrPHY)
As the IrDA standard progressed the IrPHY saw many changes so there are at least 3 common speeds in the physical layer; SIR (Serial/Slow IR), MIR (Medium IR), FIR (Fast IR) and somtimes VFIR (Very Fast IR).SIR is 2400bps - 115.2Kbps, the light pulses are 3/16s of the entire bit width long - if you are running at 9600bps then your one-bit-width is 1/9600th of a second or 0.00014seconds (0.14ms, 104us), if you are runing at the fastest 115.2Kbps then you need 1/115.2K which is about 8.7uS. So now you see the needs for photo sensors that have pretty quick rise times.
The format of SIR pulses are basically a Start bit (light on) to let you know things are starting, 8 data bits (no light pulse=1, light pulse=0) and then a stop bit that is no light pulse but for the length of an entire bit. This makes it very easy to find the next data, or to wander off and get the timing wrong!
Negotiation for a new device to the party always starts at 9600bps SIR, so all devices MUST support this speed but they can then negotiate from there to go slower or faster.
 |
| SIR @ 115.2Kbps |
FIR then switches to 4Mbps and a new pulse encoding scheme called HDLC. These are small 4-bit chunks of light pulses, the format of the data is such that the pulses cant be confused as at these speeds noise and also power-drop becomes more of a challenge.
VFIR is then just a 16Mbps version of FIR, and they go beyond this but I have never seen any of these in real life.
The Link Protocol Layer (IrLAP)
For SIR and MIR the link discovery, and negotiation is very simple. Keep in mind, though, that IrDA is actually intended to allow many devices to be talking to a host (for example lots of phones talking to a printer). So it can become complex but for my needs I am going to just pick a 1-to-1 situation to simplify things.
An IrLAP host begins with a 'preable' to let everyone know its 'sniffing' for new devices. As you can see in the picture above it sends lots of pulses, then takes a pause. As you can see its 7 pulses to be exact; Start x 1, 0-bit x 6, 1-bit x 2 and a Stop x 1. Why seven? In terms of the PhotoDiode flashing this would look like ON x1, ON x 6, and then a long OFF (1-bit x2, and an OFF) and so you see the 7 pulses since photo diodes dont response to "no light".
In terms of data this is 00000011, but since the first bit you get is the highest order digit (MSb) then the actual pattern is the reverse of this; 11000000. In Hex this is 0xC0. This is significant at this is the BOF (start of a IrLAP frame value).
For the device discovery 'sniffing' stage you are goint to see 10 of these, then one more that either is a 0xC0 or an 0xFF and after this you get the following;
[ address | command nr | format ID | various data related to the format id | CRC | EOF ]
The address is going to be 0xFE+1 (1=command, and 0xFE means its a broadcast to everyone.)
The command number is always going to be 0x3F, "Discovery" mode command
The format ID is always going to be 0x01 (discovery information)
The format ID data will always be HOST Addres/ DEST 0xFFFF (broadcast) / Discovery=1 / Slot=1,2,3,4 / Version = 0 / CRC1 / CRC2 / EOF (0xC1)
These packets are repeated at a frequent interval until a response is seen.
There isnt much more reason to go deeply into the reply as there already is JIR, a Java Lite IR protocol stack on source forge and as long as you can see the first packet you can then hook up your microcontroller to JIR or a C/C++ port of JIR and go!
Implementing an IrDA transmitter/decoder diode set
Getting the final circuit to work was a struggle, this was to do with the Vishay BPW34 actually having a nasty frequency response at lower voltages with at least 10V being needed to 'see' 115Kbps. What I saw was most of my pulses were being 'glued' together as if being saturated out. I speculate the diode was acting as a sort of capacitor and holding onto its ON state, not discharging quick enough before the next light pulse came along again to turn it on.I hooked it up seperately to a 9V battery (6LR61) and got a lovely wave. Not much use as my microcontroller runs on 3V ~ 5V. I could 'step-down' the voltage but thats more complexity.
I then moved to a BPW85 which works at 5V and thinks were much better as my micro-controller is a 3.3 - 5v device.
Implementing the IrDA serial light pulse decoder
You can either implement this yourself through a counter scheme using something like the pseudo code below OR you can use a ready made chip such as the HSDL-7002 from Lite-On (SPI signal from your Microcontroller) or the MCP2122 from Microchip (UART signal from your Microcontroller)... To Be Continues
