Reading the remote control’s data
The common infrared remote controls (from televisions, decoders, video recorders, etc.) work by associating each pressed key to a binary code that is then sent serially (one bit at the time) by using different encodings (OOK, FSK, etc.) and by modulating the light emitted by the infrared transmitter with a certain carrier frequency (typically 36÷38 kHz) so to minimize the possibility to be disturbed by environmental light sources that (since they are “noises”) have continuous components instead, or “random” frequencies.
The modulation being used the most is certainly and by far the OOK (On-Off Keying, about which a large documentation can be found on the Internet) one. For each bit to send, the modulator/transmitter will check its value: if it’s 1 it will be sent by an infrared pulse train to the frequency of the carrier; if it is 0, on the other hand, the trasmitter will be turned off (or vice versa).
The receiver, on the other hand, is “attuned” so to recognize this impulse train only if it has a frequency corresponding to the carrier one, and to send a value as an input. The value will be ‘1’ (or ‘0’) if it is detected, and ‘0’ (or ‘1’) otherwise. Basically, the start signal can be found at the output, thus “cleaned” of the carrier frequency (thus called demodulated signal).
In our shield this demodulated signal can be found on the IR1 output, which is a receiver designed to operate with 38 kHz modulated signals. The figure shows the oscillogram of the signal detected (on the IR1 output) by a remote control for a television, and a “zoom in” made to detect the duration of the single bits.
At the software level, the sketch contains a “real time” section, in order to be able to acquire these signals and in addition to the implementation of the state machine we just described. That is to say, it has to be executed at very tight and regular time intervals, so to guarantee that the signal may be sampled and correctly reproduced, and without losing information. For such a reason that code has been embedded in an Interrupt Service Routine called by the microcontroller’s Timer1, whose simplified diagram (restricted to the acquisition part) can be seen in figure.
The time interval has been chosen so that it is short enough, in order to sample any signal that may come from the remote control, without “losing” information bits. Theory teaches that the (minimal) sampling frequency has to be equal to twice the input signal (in the case of a digital one this is true if the duty-cycle remains at about 50%, however). Relying on the wave forms, we decided to opt for a sampling period of 100 µs, which is certainly inferior to the analyzed data interval. During the learning phase (the flag ‘START_ACQ’ is active), for each sampling the input line status depending on IR1 is copied and memorized in one bit. Every eight samplings a new data byte of the Bitstream[] vector is created: it is a ‘long’ BUFDIM (a constant stated within the program) byte. Thus, the number of bits that we can memorize is equal to BUFDIM * 8 and the input signal duration may be up to 100µs * BUFDIM * 8. At present, we stated a 256 (BUFDIM) elements vector, thus the remote control’s working signal may last up to 200ms, which is more than enough, given that just a few tens of ms are needed in order to send a command. The remote control’s code, for example, is sent in just 60ms, and then repeated later (and until the button is kept pressed).
On the other hand, in the communication phase (the flag ‘SEND_IR’ is active) the BitStream[] vector is read bit by bit, in the same sequence it was written and at the same rate (100µs): thus the reproduced ‘bit stream’ will necessarily turn out to be identical to the one previously read. These bits are needed in order to turn on and off the PWM output of the T0 (Arduino’s D5) timer, which is programmed so to reproduce a square 38 kHz wave. And thus we will end up with a bit sequence that has been modulated at such a frequency, capable of driving the shield’s infrared diodes, by means of T1.
