Does pulses_get function have a 200 bit limitation when reading?
@robert-hh Any new ideas on why is this happening?
@Pesien See below: It was'nt a fix.
@robert-hh Thank you so much for the help, really. I'll try to understand how I can fix it tomorrow when I have some time.
Edit: Even though it was not a fix, thank you for your help. Also you confirmed me it was not my code only.
robert-hh last edited by robert-hh
@Pesien Digging a little bit further I found the place. It is indeed a limited number events, defined by line 59 of modpycom.c
rmt_driver_install(RMT_CHANNEL_0, 1000, 0);
1000 is the size of the ringbuffer, with 4 bytes per event.
So if you want more, increase that number and rebuild the firmware.
The hint for that is here: https://docs.espressif.com/projects/esp-idf/en/latest/api-reference/peripherals/rmt.html
Edit: Testing with a square wave generator returns 128 pulses, which is less than expected from the explanation above, but the same number you have seen.
Edit2: Increasing the number above does not change anything.
@Pesien OK. Looking at the code, the RMT collects pulses into a ringbuffer until a timeout occurs, and then the number of pulses which have been collected in the ringbuffer are returned. I could not really tell the size of the ringbuffer, but 200 looks strange. The example in you post has 128 entries, which looks more like a plausible number.
@robert-hh Thank you, but I don't see what kind of delay it's happening there. The sensor keeps sending bits and the function simply stops reading at 200 bits. Since it happens with different sensors and commands, and the timeout is set at 10000 us I can't see where that delay comes from, and how is it bigger than 10 ms.
I'm using this function because my project is to comunicate with SDI-12 sensors using only one GPIO pin. My teacher has it working with the UART and two pins, but reducing it to one GPIO pin only has several advantages as you might imagine.
Also, the pulses_get function is way more stable and precise than the interrupts and timers I was trying to use (with no results).
@Pesien pulses_get has no limitation in the number of pulses beside the RAM, which is used to store the results. You cannot even enforce a maximum number of pulses to be received. It stops receiving when a timeout happens. SO maybe after 200 pulses you have a short delay, which is detected as the timeout.
I wonder why you uses pulses_get instead of UART receive?
And yes, the documentations is wrong.
@Martinnn Thank you for answering, but as I said I'm new to programming (it's for college) and can't identify the issue there :(