Close

IR measurements

A project log for tv-remote-elderly

Christmas gift for my 90+ granny: TV remote with big buttons

christoph-tackChristoph Tack 02/17/2019 at 11:290 Comments

The remote control combines functionality for the set top box and for the TV.

Set Top Box : 36kHz

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.

Capture showing why the TSOP1736 is useless for decoding RCMM.
The TSOP94336 does a better job in decoding RCMM.

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

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.

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.

Capture of a single packet showing the header followed by 17 pulse trains

Following keys have been decoded:

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.

Using Arduino Pro Mini 3V3 to generate the sequence.

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

Samsung IR protocol

As expected, the TSOP94336 also performs well in decoding the Samsung protocol.
The packet lasts about 60ms.  Every 100ms, the packet is repeated as long as the button is pressed.

More info about this protocol can be found here.

Decoding needed buttons

Connecting TSOP1736 to Arduino Pro Mini.  Loading "IRrecvDumpV2" from the examples directory. 

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