Hello, I am trying to decipher TV remotes, and whether or not there is a chip that I can buy which will decipher the code. I have considered setting up an IR reader with an oscilliscope to experimentally determine the code, but that seems like a lot of work, especially if there is a chip which will do the decoding for me. Does anyone know of such a chip? Any suggestions?
BrunoG wrote: > "flank" a =E9crit dans le message de news:
I have successfully built IR interfaces for both Samsung and Sony remotes. How do you interpret the database so that you could build a box to generate a code the receiving device will accept (I.E. it works) or 'listen' to the factory remote?
The Samsung remote (for a DLP TV) I worked with sends a total of 32 fixed width pulses (725 uS) with gaps of either 1.5mS or 450 uS. The whole sequence is prefixed by a 4.5 mS active pulse followed by 4.5 ms inactive, similar to a UART start bit. The Motorola 68HC908JK3 can listen and retransmit simultaneously in assembler but I wasn't able to figure out how to do the 38kHz modulation directly in software. I added a GAL to generate the 38kHz and 'modulate' (gate) the pulse string.
The 38Khz is connected to IRQ to synchronize the gating and provide the timing reference to count off pulse durations. The last 16 transitions are sent as an 8 bit group follower by the complement so if the data byte (#3) is $FE, the last byte (#4) is $01. The receive software counts 27 ticks as 725uS, 57 ticks for 1.5 mS and 17 ticks for 450uS with a noise tolerance of 9 ticks. After all 4 bytes are received, byte
1 must match byte 2 and byte 3 XORed to byte 4 must be $FF to be considered valid.
All the data is compared to a look up table of valid Samsung data before any action is taken.
Here is the file format description of the LIRC database :
to listen to a factory remote, you don't need to decipher it, but just store the length of pulses and spaces of a full frame, without trying to understand them. This will not work with some rare amplitude modulation remotes.
I use a PWM pin do to the carrier modulation during a pulse. the carrier detection is centered on 38Khz for most IR remote receivers, but tolerance is around +/- 2Khz. If the MCU internal PWM generator can't deliver the exact 38 Khz required, this should not be a problem if the frequency is within this range.
32 > > fixed width pulses (725 uS) with gaps of either 1.5mS or 450 uS. The > > whole sequence is prefixed by a 4.5 mS active pulse followed by
4.5 ms > > inactive, similar to a UART start bit. The Motorola 68HC908JK3 can > > listen and retransmit simultaneously in assembler but I wasn't able to > > figure out how to do the 38kHz modulation directly in software. I added > > a GAL to generate the 38kHz and 'modulate' (gate) the pulse string. >
What I was doing with the Samsung project was transcoding commands such that the channel change to the monitor gets duplicated to the set-top box. I also created a sequence of commands for input selection of the monitor. Since I covered the IR reader on the STB and mounted an IR LED there to be driven by my transcode box, I have to actually decode and verify the individual commands to take the proper action - mostly re-transmit as is, change the set ID codes or do nothing.
I doubt the tolerance is 2 kHz wide without serious sensitivity fall-off. My 38kHz ends up being 38095 Hz. 32MHz/15 in a 74F163 and the
2.133 MHz divided by 56 in a 22V10 GAL. Perfect 50/50 duty cycle and then gated to drive 2N7002 fets to run the IR LEDs. Thanks John Larkin for the FET info. This project was more than a re-broadcast of the IR.
To actually obtain the codes, I opened a cheapo remote and probed with a Tek TDS-3034 scope and printed the readings on a laser printer. This gave me precise number of cycles of transmitted 38kHz for the long/short delays and fixed 'on' pulse. To get ALL the Samsung codes, I used an IR receiver to the scope and printed out every button fro all the device types (vcr,dvd,stp,tv) . Problem with this is the pulse width is different from reader delays.
It also required a power-on detect circuit so that if you turn on one device manually, it will send power commands to the other until its on, too.