ESP32 Forum

I am using the RMT to decode a Manchester data stream.

The messages do come in bursts but the worst case corner is 704 RMT events in a single message.

I have learned that the ringbuffer is only updated when the RMT idle condition is reached.
With this many RMT events I cannot wait for the idle before unloading the RMT memory and the ringbuffer is not helping me.

I see 3 possible solutions and would love an RMT expert to lend some advice.
1) Reduce the RMT Idle detect time so it will trigger on the manchester phase shifts. Then I apply hope as a strategy and hope the event blocks recorded in the ring buffer are seamless with no missing timing data between the idles.
2) I redesign the manchester parser to use the event block transitions as the bit transitions.
3) Ditch the RMT and use a timer to decode the manchester.

Thanks,

I think you can extend the memory up to 1024 records but in that case you can only use a single channel.

The datasheet says there are 512 records available in 8 blocks of 64, one block per channel by default. I am using 1 for the TX channel and 7 for the RX channel.
1024 records would be nice... just having a double buffer feeding the ringbuffer would be perfect.

512 x 32-bit values which equals 1024 x 16-bit entries/records.

Of course, I see that. I was using the language of the datasheet.
For the purposes of manchester, it takes two measurements to represent one transition which is either 1 bit or 1.5 bits.

I'm in the same boat as you. I'm trying to do some protocol decoding too. In my case there could be near a thousand bits in a single stream. To make it worse, I have two inputs as well. Of course, each bit is two RMT events - one positive signal event and one signal low event. You're right, it doesn't interrupt until you get an idle. This doesn't work for me at all. It seems kind of stupid to let the hardware buffer fill up and then ignore that and continue reading the bus all the while nothing is being written anywhere after the hardware fills up. It doesn't interrupt when the buffer fills - that really should be considered a hardware error.