The remote control combines functionality for the set top box and for the TV.
Set Top Box : 36kHz
- Numerical buttons (for selecting channels) : 1, 3, 7
- 1 button : green : subtitles on/off
Reverse engineering CISCO IR Protocol
The output of the TSOP1736 receiver had quite some jitter on it, so I measured the pulses directly on the IR-diode of the remote control.
Later I compared the output of the IR-diode to the output of the TSOP1736 receiver. The receiver simply acts too slow. It needs at least 10 pulses per burst, while RCMM only sends six.
Data pulses are sent out at a rate of 36kHz. That corresponds to a pulse period of 27.5µs.
Capturing the signals has been done using a Saleae Logic Analyzer.
The CISCO ISB6030 set top box uses pulse distance coding. The protocol is very similar to the Philips RCMM protocol. The 32-bit version is also called Nokia32.
Header
- 16 pulses : 16 x 27.5µs = 441µs
- 10 pulses pause : 10 x 27.5µs = 275µs
Data pulses
Always 6 pulses, followed by a predefined pause length. The data is encoded in the pause lengths. We notice that there are four different pause lengths used. So we can assume that each length encodes two bits. The bit encoding found on SB-projects is added here as a reference.
- 10 pulses pause : 10 x 27.5µs = 275µs --> 00
- 16 pulses pause : 16 x 27.5µs = 440µs --> 01
- 22 pulses pause : 22 x 27.5µs = 605µs --> 10
- 28 pulses pause : 28 x 27.5µs = 770µs --> 11
Packet
A packet is comprised of a header, followed by 17 pulse trains. So 32 bits are being encoded. The 17th pulse train is only there to show the pause length after the 16th pulse train.
Following keys have been decoded:
- key subtitles on/off : 0x22C0263C
- key 1 : 0x22C02601
- key 3 : 0x22C02603
- key 7 : 0x22C02607
The last 20 bits of the measured codes of the numerical keys correspond to data published here.
Generating RCMM
[Rafi Khan's] IR-remote library served as a starting point. The RCMM protocol has been added. This library implements timings using delays. For a slow 8MHz controller, this leads to noticeable jitter on the timing of data bursts. The receiver doesn't always react to the packets.
The solution is to use the Timer2 COMPB interrupt instead. It required some rework of the IR library, but the work pays off. The generated pulse timing shows less error than the original one.
Remark the active high signal polarity. When pin 3 of the Arduino is high, the IR LED must be on.
Double key press avoidance
The packet lasts about 10ms. Every 100ms, the packet is repeated. On the standard remote the packet is repeated as long as the button is pressed.
If more than 4 packets are sent, which equates to holding the button down longer than 0.3s, the receiver will interpret this as a double button press.
Older people don't tend to be that fast, so on our remote only 4 packets will be sent out when a key is pressed. If you keep holding the button down, after 2.5s the four packet sequence will be repeated. The 2.5s delay is needed to avoid that the receiver interprets this prolonged button press as a double button press.
When you intentionally want a double button press, lift your finger and press again. Lifting your finger from the button will disable the 2.5s delay.
Samsung TV : 38kHz
- TV on/off (decoder remains always on)
- 2 buttons : volume up/down
Samsung IR protocol
More info about this protocol can be found here.
Decoding needed buttons
Connecting TSOP1736 to Arduino Pro Mini. Loading "IRrecvDumpV2" from the examples directory.
- key TV on/off : 0xE0E040BF
- key volume up : 0xE0E0E01F
- key volume down : 0xE0E0D02F
Double key press avoidance
This is not much of an issue for controlling the on/off of a TV-set. It takes several seconds for the TV to turn on. Turning the TV off also takes a while. Sending a sequence of four packets seems to do well.
Sending a sequence of 10 packets (pushing the button for more than a second) equally works well. There are no false turn on/off sequences.
Controlling the volume buttons causes no unwanted "double press" issue. These button controls are designed to control the volume of the TV-set in a more or less continuous way. Sending 9 packets at a 10Hz rate causes the volume to drop 5 steps. Sending 9 packets at a 5Hz rate causes the volume to drop 9 steps. It might seem counter intuitive, but decreasing packet rate increases the volume change rate.
Let's stick to the 10Hz packet rate for volume control. The 5Hz rate will adjust the sound volume too fast for older people.
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.