This boils down to detecting whether the signal changed after a short (83,3333...ns) or a long (166,666...ns) delay.
With the Clock of 80 MHz a short delay should be 6,666... ticks and a long delay should be 13,333... ticks.
I would expect to see counts of 6 and 7 for a short signal and counts of 13 and 14 for a long signal.
However there is a high level of Jitter in the received values.
Below is an example of what the data looks like coming from the RMT.
- {{{6,1,7,0}}},
- {{{6,1,7,0}}},
- {{{6,1,12,0}}},
- {{{14,1,8,0}}},
- {{{7,1,7,0}}},
- {{{6,1,10,0}}},
- {{{15,1,8,0}}},
- {{{7,1,10,0}}},
- {{{15,1,9,0}}},
- {{{7,1,11,0}}},
- {{{10,1,6,0}}},
- {{{12,1,9,0}}},
- {{{7,1,11,0}}},
- {{{14,1,9,0}}},
- {{{6,1,11,0}}},
And even worse sometimes there is count of 10. 10 is exactly on the border between what can be considered long an short and is basically impossible to decode.
I am using the rmt-driver integrated in ESP-IDF.
Initialization looks like this:
- rmt_config_t config = RMT_DEFAULT_CONFIG_RX(CONFIG_EXAMPLE_RMT_RX_GPIO, RMT_RX_CHANNEL);
- config.rx_config.filter_ticks_thresh = 4;
- config.rx_config.filter_en = true;
- config.clk_div = 1;
- config.mem_block_num = 2;
- ESP_ERROR_CHECK(rmt_config(&config));
- ESP_ERROR_CHECK(rmt_driver_install(config.channel, 1000, 0));
Maybe someone in this forum has done something similar and figured out why there is that much Jitter in the received data. I am kind of at a loss. The APB-Clock should be fairly stable and the datastream looks almost perfect when viewed with a logic-analyzer or a scope.
PS: Sorry for any spelling/grammar mistakes, English is not my native language.