Using the ESP32 RMT Peripheal to decode the SONY protocol

[emklaus]

Has anybody used the RMT to read codes from a SONY remote?
I'm trying to modify the example code that uses the NEC protocol but I'm stuck on defining the leading symbol.
It appears the RMT is designed to work with symbols that have 2 parts / transitions.
The NEC has a 9ms "AGC Pulse" followed by a 4.5ms space. These are followed by the bit codes
However, the SONY protocol has only a single 2.4ms "AGC Pulse" followed by the bit codes.
(sorry, I have an image but don't know how to insert it)
Seems like whatever I try the encoder reads the 1st half of the 1st bit symbol as the 2nd part of the leading symbol.
So everything is off by 1 transition. Here's what I used for the leading code RMT symbol constructor:

Code: Select all

    // construct the leading code and ending code with RMT symbol format
    sony_encoder->sony_leading_symbol = (rmt_symbol_word_t) {
        .level0 = 1,
        .duration0 = 2400 * config->resolution / 1000000,
        .level1 = 0,
        .duration1 = 0x7FFF,
    };

What's the proper way (if any) to tell the RMT to NOT expect the "level1" transition?
(I've also tried defining both level0 & level1 as "1" logic state with a 1200us duration. But no difference)
Anybody else tried this?
Thanks

[MicroController]

Random result from the internet:

The start burst is always 2.4ms wide, followed by a standard space of 0.6ms

I.o.w., bits don't start with a space.

[emklaus]

"The start burst is always 2.4ms wide, followed by a standard space of 0.6ms"
I've encountered post that imply this as well but I don't believe it to be true.
I've written code that doesn't use the RMT peripheral but instead uses GPIO interrupts & timers to receive & measure the
burst stream. The results don't have a space following the leading burst.

However it seems I didn't fully understand the example code.
The code snippet I posted that configures the leading symbol only applies to RMT TRANSMISSION.
The receiver apparently just collects what it sees. (but I still could be missing something there...)
I added some code that shifts the symbol values up by 1/2 a symbol and from there I can decode them correctly.

Problem solved (I think...)
Thanks