Weird IR protocol

I seem to have run into yet another weird IR protocol. It’s for a Pre-Roku TCL television.

leader = 4ms pulse, 4ms space
1 = 0.5ms pulse, 2ms space
0 = 0.5ms pulse, 1ms space

=== Power Button
leader 1 1 1 1 0 0 1 0 1 0 1 0 0 0 0 0 1 1 0 1 0 1 0 1 9.4 ms
leader 1 1 1 1 0 0 1 0 1 0 1 0 0 0 0 0 1 1 0 1 0 1 0 1 9.4 ms
leader 1 1 1 1 0 0 1 0 1 0 1 0 0 0 0 0 1 1 0 1 0 1 0 1
=== Power Button
leader 1 1 1 1 0 0 1 0 1 0 1 0 0 0 0 0 1 1 0 1 0 1 0 1 9.4 ms
leader 1 1 1 1 0 0 1 0 1 0 1 0 0 0 0 0 1 1 0 1 0 1 0 1 

=== VolUp
leader 1 1 1 1 0 0 1 0 1 1 1 1 0 0 0 0 1 1 0 1 0 0 0 0 9.3 ms
leader 1 1 1 1 0 0 1 0 1 1 1 1 0 0 0 0 1 1 0 1 0 0 0 0 9.3 ms
leader 1 1 1 1 0 0 1 0 1 1 1 1 0 0 0 0 1 1 0 1 0 0 0 0
=== VolUp
leader 1 1 1 1 0 0 1 0 1 1 1 1 0 0 0 0 1 1 0 1 0 0 0 0 9.3 ms
leader 1 1 1 1 0 0 1 0 1 1 1 1 0 0 0 0 1 1 0 1 0 0 0 0 9.3 ms
leader 1 1 1 1 0 0 1 0 1 1 1 1 0 0 0 0 1 1 0 1 0 0 0 0
=== VolDn
leader 1 1 1 1 0 0 1 0 1 1 1 0 0 0 0 0 1 1 0 1 0 0 0 1 9.3 ms
leader 1 1 1 1 0 0 1 0 1 1 1 0 0 0 0 0 1 1 0 1 0 0 0 1 9.3 ms
leader 1 1 1 1 0 0 1 0 1 1 1 0 0 0 0 0 1 1 0 1 0 0 0 1
=== VolDn
leader 1 1 1 1 0 0 1 0 1 1 1 0 0 0 0 0 1 1 0 1 0 0 0 1 9.3 ms
leader 1 1 1 1 0 0 1 0 1 1 1 0 0 0 0 0 1 1 0 1 0 0 0 1 9.3 ms
leader 1 1 1 1 0 0 1 0 1 1 1 0 0 0 0 0 1 1 0 1 0 0 0 1 


=== Power Button
0xf2a0d5
=== VolUp
0xf2f0d0
=== VolDn
0xf2e0d1

Has anyone seen a protocol like this? If not, how would I go about writing a new protocol engine?

DM me for a Sigrok (PulseView) session (12KiB) with the received data. It seems I’m not allowed to attach it here.

Doesn’t look weird at all to me, just custom 24bit NEC protocol.
You can easily work with that as raw signal (or maybe pronto).
What you need to do with that?

What he said^^

Judging by your previous (and only other) post, you’re familiar with ESPHome.
Grab a board, hook up an IR receiver, then set it to dump: all.

It’ll tell you what codecs your remote is using without having to rely on guesswork based on your oscilloscope.
Bonus: you’ll be able to use that data directly in ESPHome if/when you need to send it to your device if you hook up an IR Emitter.

1 Like

I did that. The only protocols it dumped were raw and pronto. It did spit out a beo4, but that wasn’t correct and didn’t work.

I want to control the TV from an IR transmitter. The recorded pronto and raw pulses didn’t work. I guessed that the dump was wrong necause there was an error about the routine taking too long.

If the error said something like “Components should block for at most…” then it’s just a warning which is safe to ignore.

Try again with pronto or raw.

Post the raw dump here.
How is your transmitter?

- remote_transmitter.transmit_pronto:
            data: "0000 0068 0019 0000 00A0 00A0 0014 0050 0014 0050 0014 0050 0014 0050 0014 0028 0 0014 0050 0014 0028 0014 0050 0014 0028 0014 0050 0014 0028 0 0014 0028 0 0014 0028 0014 0050 0014 0050 0014 0028 0014 0050 0014 0028 0014 0050 0014 0028 0014 0050"

This does not work for my TV. I generated it from the logic analyzer trace of the ir receiver on my board.

Dumped receive is

[19:14:26.455][I][remote.pronto:231]: Received Pronto: data=
[19:14:26.463][I][remote.pronto:233]: 0000 006D 0068 0000 0099 0099 0014 004D 0014 004D 0014 004D 0014 004D 0014 0026 0014 0026 0014 004C 0014 0026 0014 004D 0013 0026 0014 004D 0014 0026 0014 0026 0014 0026 0014 0026 0014 0026 0014 004D 0014 004D 0014 0026 0014 004D 
[19:14:27.635][I][remote.pronto:233]: 0014 0027 0013 004D 0014 0026 0014 004E 0012 0156 0099 0099 0013 004E 0014 004D 0014 004D 0014 004D 0014 0026 0014 0026 0014 004D 0014 0026 0014 004D 0014 0026 0014 004D 0014 0026 0014 0026 0014 0026 0014 0027 0013 0027 0013 004E 
[19:14:27.635][I][remote.pronto:233]: 0013 004D 0014 0026 0014 004E 0013 0026 0014 004D 0014 0026 0014 004E 0011 0157 0099 0099 0014 004C 0014 004E 0013 004E 0013 004D 0014 0027 0013 0026 0014 004D 0014 0026 0014 004E 0013 0026 0014 004D 0014 0026 0014 0026 0014 0026 
[19:14:27.635][I][remote.pronto:233]: 0014 0026 0014 0026 0013 004E 0014 004C 0014 0026 0014 004E 0013 0026 0013 004F 0013 0027 0012 004E 0012 0157 0099 0099 0014 004D 0014 004E 0013 004D 0014 004D 0013 0027 0014 0026 0013 004E 0014 0027 0013 004E 0013 0026 0014 004E 
[19:14:27.635][I][remote.pronto:233]: 0013 0026 0014 0026 0013 0028 0013 0026 0014 0027 0013 004D 0014 004D 0014 0027 0013 004E 0013 0026 0014 004C 0014 0026 0014 004D 0012 0181

Not sure if this will help, but some time ago I captured a series of Pronto codes for a device I am now controlling with ESPHome. (Three banks of Louvres)

One thing that helped me with the codes was this site:

The main thing I got from this site after a copy/paste of my captured Pronto Codes was a statistical analysis. It gave the ‘Averaged zero’ and ‘Averaged one’ values. I used these to ‘tune up’ the raw values I had originally captured.

Here is an example of a code I captured and fed into the analysis site. (Please keep in mind it is an RF code not IR, but same principle should apply)

I took Pronto for ‘Close 3’ operation

0000 006D 0029 0000 0169 0029 0051 0052 0052 0051 0052 0051 0052 0052 0052 0029 0029 0053 0029 0028 0029 0029 0052 0051 0029 0028 002B 0029 0029 0028 0052 0051 0052 0053 0052 0029 0029 0052 0029 0029 0053 0051 0052 0051 0052 0053 0029 0029 0029 0029 0052 0029 0029 0053 0052 0029 0028 0029 0028 0029 0029 0029 002A 0052 0052 0029 0029 0051 0029 0029 0029 0029 0029 0029 0028 0029 0052 0052 0029 0029 0053 0029 0029 0029 0029 0181

This was converted to RAW with above web site (sensus)

0, 109, 41, 0, 9493, 1078, 2130, 2156, 2156, 2130, 2156, 2130, 2156, 2156, 2156, 1078, 1078, 2183, 1078, 1052, 1078, 1078, 2156, 2130, 1078, 1052, 1131, 1078, 1078, 1052, 2156, 2130, 2156, 2183, 2156, 1078, 1078, 2156, 1078, 1078, 2183, 2130, 2156, 2130, 2156, 2183, 1078, 1078, 1078, 1078, 2156, 1078, 1078, 2183, 2156, 1078, 1052, 1078, 1052, 1078, 1078, 1078, 1104, 2156, 2156, 1078, 1078, 2130, 1078, 1078, 1078, 1078, 1078, 1078, 1052, 1078, 2156, 2156, 1078, 1078, 2183, 1078, 1078, 1078, 1078, 10124

Multiple command bursts identified.
Header: 9493 / Ptrail: none / Gap: 10124 / Full analysis below.

Pronto header removed /highest: 10124 / smallest: 1052 / Count: 47 / Second pass zero count: 47 / Values: 82 / Averaged zero: 1076 Averaged one: 2155 / 1st header found at pos. 0 / Header: 9493 @pos. 0 / Sequences: 1 - positions: 0,81 /

/ Zeros: 47 / Ones: 33 - * Sequence 0: Binary length: 80 / Rough command: 7fc8 607c + 9f84 c032 + 190
1078,2130,2156,2156,2130,2156,2130,2156,2156,2156,1078,1078,2183,1078,1052,1078,1078,2156,2130,1078,1052,1131,1078,1078,1052,2156,2130,2156,2183,2156,1078,1078,2156,1078,1078,2183,2130,2156,2130,2156,2183,1078,1078,1078,1078,2156,1078,1078,2183,2156,1078,1052,1078,1052,1078,1078,1078,1104,2156,2156,1078,1078,2130,1078,1078,1078,1078,1078,1078,1052,1078,2156,2156,1078,1078,2183,1078,1078,1078,1078
Binary: 01111111110010000110000001111100100111111000010011000000001100100000000110010000
No bi-bits encoding found.

In ESPHome I created a substitution like this:

rf_3_c: 0000 006D 0029 0000 0169 0029 0052 0052 0052 0052 0052 0052 0052 0052 0052
0029 0029 0052 0029 0029 0029 0029 0052 0052 0029 0029 0029 0029 0029 0029
0052 0052 0052 0052 0052 0029 0029 0052 0029 0029 0052 0052 0052 0052 0052
0052 0029 0029 0029 0029 0052 0029 0029 0052 0052 0029 0029 0029 0029 0029
0029 0029 0029 0052 0052 0029 0029 0052 0029 0029 0029 0029 0029 0029 0029
0029 0052 0052 0029 0029 0052 0029 0029 0029 0029 0181

As you can see this code has been ‘tuned’. Notice values are now 0029 or 0052, compared with the original captured values.

Hope this helps a little.

Post the Raw dump so we can see what you really receive.

Based on your timings on OP, the syntax for volume up should be:

- remote_transmitter.transmit_raw:
          code: [4000, -4000, 500, -2000, 500, -2000, 500, -2000, 500, -2000, 500, -1000, 500, -1000, 500, -2000, 500, -1000, 500, -2000, 500, -2000, 500, -2000, 500, -2000, 500, -1000, 500, -1000, 500, -1000, 500, -1000, 500, -2000, 500, -2000, 500, -1000, 500, -2000, 500, -1000, 500, -1000, 500, -1000, 500, -1000,  500]
          carrier_frequency: 38kHz
          repeat:
            times: 3
            wait_time: 9.3ms

That looks incredibly helpful! I’ll be trying that shortly.

1 Like