PulseIn accuracy?

[dmcomm]

Firmware

Adafruit CircuitPython 7.0.0-alpha.3-433-g5a4a80336 on 2021-06-25; Raspberry Pi Pico with rp2040

Code/REPL

import board
import pwmio
import pulseio
import time

pwmOut = pwmio.PWMOut(board.GP0, frequency=5000, duty_cycle=0x8000)
pulsesIn = pulseio.PulseIn(board.GP1, maxlen=100)
#GP0 and GP1 are connected by a resistor

results = []
while True:
    pulsesIn.clear()
    for i in range(20):
        while len(pulsesIn) == 0:
            pass
        results.append(pulsesIn.popleft())
    print(results, "during")
    results = []
    time.sleep(5)
    
    pulsesIn.clear()
    while len(pulsesIn) < 20:
        pass
    for i in range(20):
        results.append(pulsesIn.popleft())
    print(results, "after")
    results = []
    time.sleep(5)

Behavior

[99, 99, 99, 99, 99, 42, 99, 50, 86, 90, 62, 98, 70, 42, 78, 82, 54, 90, 30, 66] during
[99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99] after
[99, 61, 65, 37, 73, 45, 49, 53, 89, 93, 65, 37, 73, 45, 49, 85, 57, 61, 33, 37] during
[99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99] after
[99, 25, 61, 97, 37, 73, 77, 49, 85, 89, 29, 97, 69, 41, 77, 49, 85, 57, 93, 65] during
[99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99] after

Description

Doing some things while PulseIn is measuring degrades the accuracy. The above shows a particularly bad example. I'm unsure if there is a bug here, or whether this is just a case of "if you want microsecond accuracy, you'll have to be gentle with it". But if the latter, this would be a documentation request for "how do you know what to avoid?"

It's puzzling that the durations are always on the short side. That suggests a delay is getting inserted between checking the current pulse duration and starting the timer for the next one, which doesn't seem like it should happen.

[tannewt]

@DavePutz Any thoughts?

[DavePutz]

I think what you are looking at here is a timing issue. As stated in the documentation; pulsein.len() "Returns the number of pulse durations currently stored.". So, since your example is constantly streaming pulses, there will be times when you check the len() and get less than the maxlen you have specified. I don't believe this is an issue with accuracy; just an issue with calling popleft() before the maxlen pulses have been received. If you replace the "pass" in your first loop with a "time.sleep(.001)" then you will see the values for 'during' equal 99 as well.

…

On Mon, Jun 28, 2021 at 5:43 PM Scott Shawcroft ***@***.***> wrote: @DavePutz <https://github.com/DavePutz> Any thoughts? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#4932 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFNJKEW4O3U44FZJOFGOLTDTVD3ILANCNFSM47MLYSIA> .

[dmcomm]

Thanks for your reply. The maxlen isn't relevant here as long as it's at least 20. But indeed, more testing suggests the accuracy issue in this example is caused by calling popleft() before the desired number of pulses is reached (20 in this case). In other words, calling popleft() reduces the measured duration of the pulse currently in progress.

(I initially didn't think it was that because I had another example which seemed to work; but really the other example was introducing a delay that prevented the issue.)

I stopped doing that in my real program, which gave a big improvement, but something else is still upsetting it and I haven't managed to isolate that yet.

[dmcomm]

If I understand right, PulseIn is streaming 1-bit samples from a PIO at 1MHz with a 128-bit buffer, so that has to be serviced at least every 128us or it will lose some. (And that's why disrupted measurements are always on the short side.)

Theoretically, would it be a good thing if the PIO did more of the work? Is the PIO program size a concern?

[tannewt]

Having PIO do more work is one way to handle it. The other would be to DMA out of the PIO into memory so the buffer is larger. (We might do this already.)

[dmcomm]

Supposing the PIO pushed on edges instead of every 32us, we don't actually gain much on fast protocols because it's wasting most of the bits. So not as helpful as I first thought.

I don't think PulseIn is doing DMA currently.

[dmcomm]

circuitpython/ports/raspberrypi/common-hal/pulseio/PulseIn.c

Line 128 in 58fdf9e

rxfifo = pio_sm_get_blocking(self->state_machine.pio, self->state_machine.state_machine);

Would I be right in thinking that interrupts don't stack? So it only has 32us to respond? And that could be solved by fetching all of them rather than just the one?

Also if FIFO Join is possible here, that doubles it again.

[tannewt]

The interrupt routine should be entered a subsequent time if the fifo is still full after the first get. This has a bit of cost instead of having a loop here but its pretty minor.

rp2pio_statemachine_construct should do a FIFO join automatically.

What protocols need this tight of timing? I don't know of one.

[dmcomm]

Ah, the interrupt fires if the FIFO is full? In that case looping won't help much and neither will the length.

Edit: Looks like it's a status interrupt on nonempty, so no issue there.

[dmcomm]

What protocols need this tight of timing? I don't know of one.

I don't know much about serious protocols and which ones might be affected by losing a few tens of microseconds. I guess nobody will be doing IrDA in PulseIO. There's this? http://www.numericana.com/answer/ir.htm#455

I'm in a club for reverse-engineering toys that communicate with each other. One of our members is also making a new toy with a Pi Pico and CircuitPython, and hopes to interface with some existing ones. After we talked about that, I looked at the API docs and said "PulseIO looks good for this". I'm using PIO for some of the outputs now, which turned out to be fairly easy, but input in PIO is a lot more painful.