Burst Mode Gap Measurement

[achronoxx]

Does the Burst Mode gap measurement have a time limit?

I've been experimenting with Burst Mode and it seems the gap timer has a max limit and wraps around.

I know my bursts are ~40sec apart, but the gap measurement reports ~10 to 12sec apart.

The test I ran was sampling at 400kHz, and the signal was ~100kHz. Burst data was 20k samples, and max samples set to 130,000

I suspect the limitation is due to counting samples since last burst, and this is overflowing a counter that causes it to wrap???

As an alternative, can you take a timestamp and then calculated elapsed time when next trigger occurs?

Andrew

[gusmanb]

Does the Burst Mode gap measurement have a time limit?

Yes, and it is around 40 secs.

I've been experimenting with Burst Mode and it seems the gap timer has a max limit and wraps around.

I know my bursts are ~40sec apart, but the gap measurement reports ~10 to 12sec apart.

The test I ran was sampling at 400kHz, and the signal was ~100kHz. Burst data was 20k samples, and max samples set to 130,000

I suspect the limitation is due to counting samples since last burst, and this is overflowing a counter that causes it to wrap???

As an alternative, can you take a timestamp and then calculated elapsed time when next trigger occurs?

I use the internal tick counter, the wrap around you see is precisely that, the tick counter overflowing. There is no timestamp beyond this, when you must have a real timestamp using only the pico an interrupt must be configured so each time the counter overflows you increment another counter and thus you can track a "real" timestamp. The problem here is how tight the code is in order to track small gaps,
I have set a NMI (even regular INTs are not suitable for it) whenever a burst is completed and then inside the interrupt handler I have time only to copy the counter and reset it, anything beyond that would mess completelly the measurement, I even had to move the code from flash to RAM in order to avoid the flash' wait states, so you can imagine how tight the code is... Also having interrupts happening when the overflow happens would mess even more the measurements, the pico W for example is not recommended to be used with the burst measurement as it will introduce a lot of jitter in fast signals, the regular pico is steady in the range of 5-10ns, meanwhile the W because the interrupts that happen and the code being on the flash can have "random" delays of up to 600ns.

Andrew

[achronoxx]

Thanks for the explanation - it makes sense.

Note that I did a little more testing, and it seems the counter wraps at ~21.5 sec, not 40sec that you mentioned above. I'm not sure if this means there is some other issue???

Is there enough execution time to set a flag to indicate that the counter overflowed? This would let the user know they cannot trust the measurement.

This is a useful feature, but I think it may be a good idea to mention this limitation in the documentation.

Thanks again!
Andrew