Looking over the circuit board of a Roku Premiere 4620X ("Cooper") I saw a lot of things that might be fun to play with but require more skill than I have at the moment. But that's fine, every electronics hobbyist has to start somewhere, so I'm going to start small with the infrared remote control subsystem.

Consumer infrared (IR) is not standardized, and signals may be sent on several different wavelengths. Since I want to play with the Roku RC108 remote control unit, I needed to remove the infrared receiver of its corresponding Premiere 4620X in order to guarantee I have a matching set. This is a small surface-mount device protected by a small metal shield that I could fold out of the way.

Once the shield was out of the way, I could turn on the Roku and probe its pins with my voltmeter to determine the power supply pin (constant 3.3V) the ground pin, and the signal pin (mostly 3.3V but would drop as I sent signals with the remote.) I then removed this receiver with my soldering iron and connect this tiny part to a set of 0.1" spacing headers so I could play with it on a breadboard.

In this picture, from top to bottom the pins are:

  • Ground
  • (Not connected)
  • Power 3.3V
  • (Not connected)
  • Active-low signal

I installed it on a breadboard with an ESP32, flashed with ESPHome which is my current favorite way to explore things. In this case, ESPHome has a Remote Receiver component that has decoders for many popular infrared protocols. What if we don't know which decoder to use? That's fine, we can set the dump parameter to all which will try every decoder all at once. For this experiment I chose an ESP32 because the of its dedicated remote control (RMT) peripheral for accurate timing while decoding signals. After I get something up and running, I might see if it works on an ESP8266 without the RMT peripheral.

With dump parameter set to all listening to a Roku RC108, I got hits from the JVC, LG, and NEC decoders. And occasionally I would get a RAW message when none of them could understand the signal. If I hold the [up] button, I get one instance of:

[18:55:50][D][remote.jvc:049]: Received JVC: data=0x5743
[18:55:50][D][remote.lg:054]: Received LG: data=0x57439867, nbits=32
[18:55:50][D][remote.nec:070]: Received NEC: address=0xC2EA, command=0xE619

But just the first one. All following hits look like this, and they repeat for as long as I held down the [up] button.

[18:55:50][D][remote.jvc:049]: Received JVC: data=0x5743
[18:55:50][D][remote.lg:054]: Received LG: data=0x57439966, nbits=32
[18:55:50][D][remote.nec:070]: Received NEC: address=0xC2EA, command=0x6699

Then if I press the [down] button on the remote, the first interpreted signal became:

[18:55:52][D][remote.jvc:049]: Received JVC: data=0x5743
[18:55:52][D][remote.lg:054]: Received LG: data=0x5743CC33, nbits=32
[18:55:52][D][remote.nec:070]: Received NEC: address=0xC2EA, command=0xCC33

Then it would repeat the following for as long as [down] was held:

[18:55:53][D][remote.jvc:049]: Received JVC: data=0x5743
[18:55:53][D][remote.lg:054]: Received LG: data=0x5743CD32, nbits=32
[18:55:53][D][remote.nec:070]: Received NEC: address=0xC2EA, command=0x4CB3

Looking at this, it looks like JVC is overeager and doesn't actually understand the protocol as it failed to differentiate up from down. That leaves LG and NEC decoders. To find out which is closer to the Roku protocol, I started tightening the tolerance parameter from its default of 25%. When I have it tightened to 10%, only the NEC decoder returned results. Even better, each button returns a repeatable and consistent number that is different from all of the others. Even if Roku isn't actually using a NEC protocol, using the NEC decoder is good enough to understand all its buttons. I used the NEC decoder to generate this lookup table.

Roku Remote Button Decoded Command
Back 0x19E6
Home 0x7C83
Up 0x6699
Left 0x619E
OK 0x55AA
Right 0x52AD
Down 0x4CB3
Instant Replay 0x07F8
Options 0x1EE1
Rewind 0x4BB4
Pause 0x33CC
Fast Forward 0x2AD5
Netflix 0x34CB
Sling 0x58A7
Hulu 0x32CD
Vudu 0x7788

I think I got lucky this time with the NEC decoder. I had another infrared remote control in my pile of electronics (JVC RM-RK52) and none of the ESPHome decoders could decipher it, just RAW data all the time. Alternatively, it's possible that remote is on a different infrared wavelength and thus this particular receiver is only picking up fringe gibberish. I'll put the JVC remote back in the pile until I am in the mood to dig deeper, because right now I want to quickly play with this salvaged infrared system.