| ??? 12/17/02 15:09 Read: times |
#34597 - RE: IR Protocol Discussion |
First I could suggest that you take apart a remote control and attach an oscilloscope across the transmitter LED. The waveform there will represent the exact transmit waveform including the carrier frequency which is typically on the range of 24 to 48KHz. [The two most common carrier frequencies are 36 and 38 KHz].
The next instructive lesson is to connect up an IR receiver module. Simply use a battery pack with 3 or 4 alkaline cells in series to power the IR receiver with 4.5V or 6V. [Some modules also require a pullup resistor on the output to the +V]. An oscilloscope on the output will show the received IR waveform from an active transmitter, but with the carrier stripped out. If you run this test the IR receiver module can be a 36 or 38KHz type and it will successfully show the IR from transmitters of other carrier frequencies if the transmitter is only about a meter away. [It is also worth noting that if you put a transmitter directly in front of a receiver module that the receiver module may see too much signal and not be able to decode it properly]. There are a number of IR protocols in use in the industry. A protocol is an established set of IR modulation frequencies, bit level timing, bit level encoding representation, data sequence format, and error detection scheme implemented. Within a protocol the keys from a particular remote control are encoded with verying binary bit patterns. It is the job of a receiver / decoder to detect the timing of the frames that represent a particular protocol, validate the timing as in a valid range, then find out the bits in the sequence, validate the bit sequence via whatever errror detection scheme may be present, and finally determine the actual binary code for the key that was pressed. Key repeats work in two different ways that I have seen. Most remote controls will repeat the transmission of the IR when a key is kept pressed at an approximate rate of 10 Hz. The simpler remote control protocols will just send the same IR packets over and over at the 10 times per second. Other protocols have been designed to conserve battery life and so will send the normal protocol for the key when it is first pressed and will follow that with a much shorter code that represents a key again code. This shorter code is repeated as long as the key is held down. [One protocol I have seen takes about 45 milliseconds to send the normal protocol for a key while the repeat code takes about 15 milliseconds. So the repeat code takes about 1/3 the power of a regular protocol burst at the transmitter ... thus conserving the battery]. There are some remotes that are used interactively with a user interface on a TV or video system where the remote moves a cursor around. On some of these the typical 10 Hz key repeat rate is too slow so I have seen IR protocols that operate up to 40 Hz rate to permit smoother and faster cursor operation at the TV or Video system. It is possible to encounter remote controls that implement two different protocols. One at a 10 Hz rate to support the regular keys and a second protocol to support the "arrow keys". I have studied IR protocols a number of different times and become familiar with at least 11 different protocol styles. Some of the most popular types are the Philips RC5 style, the SONY style, and the NEC style. Each protocol has its advantages and disadvantages. The RC5 style is probably the most robust protocol, particulary if the receiver/detector algorithm is designed carefully. Note that simpler algorithms to decode IR in microcontroller firmware may be less tolerant of IR transmission errors and thus give a poorer recovery of detected transmissions. The most robust detection algorithms will attempt to validate pulse widths received from the IR receiver module with a range of valid timings. Each protocol style will have different requirements in this regard. It can also lead to a more robust detection algorithm if the timing is detected in a way to track accumulated timing error within one transmission sequence. I have found for example that detecting RC5 with a robust algorithm like this can extend the transmission range by more than 25 or 35%!!!. The reason this is important is that the IR signals from the transmitter to the IR detector output can vary considerably. IR bounce (i.e. multi path to the receiver), 50 or 60 Hz disturbance from flourscent lights, battery level in the transmitter, and receiver module performance can all effect the timing of the pulses. I have done some interesting tests using a 2 channel DSO to monitor the LED signal in a remote transmitter at tbe same time of looking at an IR detector module output. Doing this it is possible to learn a lot about the disturbances and distortions that can happen. [Sometimes I would wonder how IR remotes can work as good as they do !!!]. I can talk more about particular parts of this subject if you have more detailed questions. Note that there is a plethora of information on the web about IR remotes. Just go to google.com and do a search on IR remote control and you will see what I mean. Although note that you will have to do a lot of filtering of information since a lot of it is of questionable quality!!! I hope this has helped. Michael Karas |
| Topic | Author | Date |
| learning remote again - sorry | 01/01/70 00:00 | |
| RE: learning remote again - sorry | 01/01/70 00:00 | |
| RE: learning remote again - sorry | 01/01/70 00:00 | |
| RE: learning remote again - satish | 01/01/70 00:00 | |
| RE: IR Protocol Discussion | 01/01/70 00:00 | |
| RE: learning remote again - Erik | 01/01/70 00:00 | |
RE: learning remote again - Satish | 01/01/70 00:00 |



