In Which Jarrett Builds

Instead of a TV at home, I use a projector. It’s on my ceiling, with the buttons inaccessible. The remote for it also isn’t really working anymore. Problem.

There’s nothing on the remote control’s PCB except for an obscure microcontroller (TTR013), IR LED and driving transistors, and some carbon contacts for the buttons. The intermittent operation is not the contacts deteriorating, and the microcontroller is getting power, so troubleshooting opportunities are limited.

 

But, the internet is a wonderful place, and someone has just straight up recorded the exact remote control I need and posted it up on Github.

The config file is here, but they also have the raw recordings. Apparently it’s a config file for a Linux IR transmitter driver called LIRC. The config documentation is here.

 

It’s pretty straightforward, so I set out to duplicate the waveform using the RMT peripheral of the ESP32. The RMT peripheral is an arbitrary waveform generator, and one of the typical use-cases is an IR transmitter. Perfect.

My final code is here. The From my reading of the LIRC docs, the relevant config data is this:

 

header 9077 4504
one 602 1622
zero 602 511
ptrail 604
gap 108167

begin codes
ON 0x000CF20D

 

Where a binary 1 is denoted by an on-pulse of 602 microseconds and then an off-pulse of 1622 microseconds. Similarly for 0, it’s 602-on and 511-off.

The code for ON uses that sequence to write out 0x000CF20D.

 

The whole packet starts with the header sequence (9077-on, 4504-off) then 0x000CF20D, then the tail/gap sequence (604-on, 108167-off). Seems straightforward.

 

I put the ESP32 on an oscilloscope to make sure the RMT was doing what I wanted it to do.

 

It seems to be! But this is more of a logic analyser task, so I pulled that out. The waveform looked exactly as I expected, so I tested it out with an IR LED.

 

 

And it didn’t work at all. Nuts.

By connecting the remote control to the logic analyser and powering it with a nice bench power supply, I was sometimes able to get output data. Enough to grab a capture after several minutes of mashing the carbon contacts with a brass standoff.

Here’s the full waveform:

It’s worth noting that the waveform is inverted from the actual LED current, due to measuring at the LED with low-side switching. Don’t worry about it too much, just invert the logic.

Sigrok can export the waveform in a Value Change Dump format, which looked good enough for my purposes. Then I wrote a python script to convert VCD files into the RMT packet format.

It looked good, with the exception of some glitches caused by the RMT not being able to handle very long delays, relative to the fast switching. This strategy still didn’t work on my project.

Speaking of fast switching, let’s investigate that further. Abandoning the Github config files so quickly didn’t sit quite right with me. It was too perfect.

Going back to my capture of the remote, here’s a binary 1:

 

Here’s a 0:

 

And then here’s the header, along with the data portion:

 

And the header with the whole data portion:

 

It does look right. But why was this so different from the Github repo?

Well, obviously this has a carrier wave that I totally blew by.

 

Wow, okay. Back to the LIRC documentation. There is a frequency option that specifies carrier wave, and defaults to 38kHz. So, it’s not in the config, because it’s set by default, and is one line in the documentation. No wonder I missed it.

Honestly, my brutish Python script that specifies all of changing values is probably good enough, but it feels wrong to use a 1500-line lookup table instead of a fixed carrier frequency and 15 lines of actual data. The RMT peripheral made it incredibly easy to fix up.

The end result looks really good, but let’s compare with the captured data again.

Keeping in mind that the data to be sent is 0x000CF20D, I’ve annotated the capture:

 

And it looks mostly good, except… What’s that block at the end?

I can’t find anything in the original config or documentation for the config that would explain that last block. That will remain a mystery for now.

 

Anyway, it was about this time that I got suspicious of the ancient IR LEDs that were in my parts bin. If I cranked the current, they looked visibly blue, which, obviously is the wrong side of the spectrum when I’m looking for IR LEDs. I grabbed a spectrometer and measured it – Yep, that’s not right.

After combing through my parts bin, I found another IR LED and measured it: 815nm. Still not right. I was fortunately able to juuust barely be able to measure the wavelength, though.

Looks like a very broad band 815nm, if the peak stretches all the way to 750nm.

I’m pretty sure I’m looking for a 940nm LED, so some more combing and I found an IR proximity sensor. I don’t have a datasheet, but pointing a TV remote at it triggered the on-board red LED, so I knew it was simpatico.

A quick hack-job later, and I drove the LED directly from the ESP32. My projector turned on, without any further changes to my code. And it successfully turned off the projector, too.

So that’s how I controlled my home entertainment setup with an IR proximity sensor.

 

Sometime in the middle of this journey, I hooked up the LA to a little 315MHz receiver module and triggered my garage door remote. I won’t be posting the waveforms here, but minor modifications to my Python script and code worked out of the box to clone the remote. That whole process took about 15 minutes, so it was a nice and useful diversion. Because it’s attached to an ESP32, I can now trigger my garage door over the internet. From anywhere in the world! Very, very remotely.

 

This whole project is very specific to my needs, but it could be helpful to others. There is now a pipeline for converting LIRC config files into ESP32 RMT outputs. I doubt I’ll ever do this again, but, just for giggles, here’s a GPT-assisted script that will do it:

Run this with python esp32_convert_lirc_to_rmt.py config.conf --output main.c

It will generate a main.c file that should just compile and have the ESP32 happily spitting out valid data.