Ben Ryves 2007 for MaxCoderz.
This is the user manual for the Infrared library, not the bundled program 'Infrared'. For information about the program, see the Infrared manual.
Download the latest version.
Infrared signals are sent by transmitting timed bursts of infrared light modulated at a particular frequency.
This library generates a 38kHz carrier - this is the frequency used by the SIRCS protocol (Sony).
A remote control will transmit a burst of IR followed by silence for each bit. It is the length of the burst and the silence that is important.
For example, with SIRCS, to send a '0' the remote sends 0.6mS of 38kHz modulated IR followed by 0.6mS of silence; to send a '1' the remote sends 1.2mS of IR followed by 0.6mS of silence.
As well as this pattern for each bit, the signal will typically have a start bit - a long IR burst followed by silence (2.4mS then 0.6mS for SIRCS) - that is transmitted before anything else.
Different manufacturers use different command word lengths and different time bases. Providing a specialised library for each would be a very time consuming task!
Following my work on a SIRCS-only library, I've written this general purpose library.
Rather than focus on a particular protocol, it can (at the most basic level) record and play back ("stupidly") raw IR signals. That is, it can log the delays between the IR bursts and silences, and then play them back out.
This works very well, but results in huge logs! On top of this is provided a way to compress and decompress the logs to and from a simple stream of bits. You need to provide a protocol descriptor, which details timing information for a protocol, to be able to use this functions.
The descriptor follows the following format, and is usually 16 bytes long.
|Byte||Flags||If the least significant bit set it indicates that the protocol uses a start bit.||.db %00000001|
|Byte||Word Length||How many bits of data follow the start bit (if present).||.db 43|
|Word||Signal Length||How long the complete signal is.||.dw 4320|
|Word, Word||'0' Bit Timing||Timing for a '0' bit.||.dw 20, 20|
|Word, Word||'1' Bit Timing||Timing for a '1' bit.||.dw 20, 60|
|Word, Word||Start Bit Timing||Timing for the start bit.||.dw 360, 120|
All times are in 38kHz cycles. To calculate the length, multiply the time (in mS) by 38; so 0.5mS becomes 19.
Bit timings are made up of two values; the first specifies how long the burst of modulated IR output should be, the second is the length of the delay until the next one.
The space saved by using such a descriptor is substantial - the above would only use 6 bytes per command on top of the 16 byte descriptor; uncompressed each command would take up 177 bytes - which is unacceptable!
For the transmitter, you need the following parts:
|Infrared LED||SFH 484 or SFH 485|
The receiver is more complex, and requires the following parts:
|Infrared Module||HRM538BB5100 (38kHz)|
The circuit layout is as follows. It has been presented as a suggestion; check the datasheets for your parts and adjust the layout or ratings of components to suit.
If you have already constructed a PS/2 adapter for your calculator, you can plug the components into that instead (viewed from the PS/2 socket):
To test this library I rounded up all of the remote controls I could lay my hands on.
I have tested the library with the following devices (with which it works):
The library doesn't work with the following devices:
There are two notable limitations in this library (neither apply when you're using the raw recording and playback functions, however).
The first involves signals with an irregular pattern of bits. Here's an example from a Daewoo television:
As well as clearly defined start, 0 and 1 bit patterns, you can see there's an extra long gap roughly in the middle of the data stream.
The library can't cope with that sort of thing, and will end up rounding to the closest regular value, which when played back will probably not work.
Another problem is remotes that do not repeat the entire signal whilst the button is held down, and instead send a special repeat pattern.
The side-effect of this appears to be that buttons that should only be handled once (such as power buttons or channel up/down buttons) and handled multiple times, so the device skips up and down channels quickly or switches on then immediately off again.
The easiest way to work out why something isn't working is to look at the signals sent by the infrared remote control on an oscilloscope.
Such an expensive piece of kit is probably beyond the budgets of most people reading this, so a good alternative is the humble PC sound card.
Here I'm measuring the length of the start of a start bit. Try and use as high a sample rate as possible.
Using this method you can compare the results of the DecipherProtocol function with reality, and see that it's getting the timing right.
Ideally check the output of the calculator with the output of the IR remote rather than trying to use the absolute timing values reported.