PPI time stamp accuracy problem

[Cedric Honnet]

Hi all!

I've been working on a firmware to timestamp GPIO events using PPI in nRF52, and it works:

github.com/HiveTracker/firmware (more context: hivetracker.github.io)

So first off, thanks for those who participate in this great forum, it helped a lot for this project (timer sync trick + feasibility question).

...but now there's a surprising accuracy problem, and maybe some of you have suggestions.

Apparently, GPIO events are sampled at 16MHz by the PPI, so the timestamps should not have more than 62.5 ns errors.

But in the following picture, you can see an example where a pulse width is measured, the value is printed on a serial port, and there is a 200 ns error (= 0.2 ms = 21.31 us - 21.11 us). 

Would anyone happen to have a clue about why this PPI timestamp is so inaccurate?

If it can help, here is the repo that was used to do this test: github.com/HiveTracker/PPI

Thanks a lot!!

Cedric ;)

Notes:

- this measure was done at 100 MHz with a Saleae logic analyser, so it should be good

- the GPIO are not initialized in low accuracy mode (they use the same configuration as for the high_accuracy mode)

- the microseconds conversion is computed as a float so it should not be a problem

- the cables are fairly short so the electronic system should not be the problem

[Susheel Nuguru]

Very interesting. Can you please attach a minimalistic project to reproduce this. I cannot access the github page.

Maybe you are doing some casting conversions to be able to print that value onto serial port and loosing some accuracy in the conversion?? This seems like a long shot, I would like to reproduce this and see.

My other theory is that it is possible that the chain of peripherals this event goes through by the time it gets latched in the timer capture register might be long and takes more than one PPI cycle to reach there.

 

[Cedric Honnet]

Hi Aryan!

Thanks a lot for your answer!

You'll find below another example with a 54 us error (= 3294 us - 3240 us), and the code is attached.

Hardware: this test was done with a TS4231 photodiode, and signals generated by HTC vive base stations.

Software: the tool chain used is on github, but it should not be very different to what you use.

If needed, there's also a signal_generator folder to simulate fairly similar pulses.

Thanks again!!

Cedric :)

6355.PPI.zip

[Susheel Nuguru]

sorry for the late reply, I have done some basic tests to check time delays between events from PPI -> TIMER->GPIOTE and still see a maximum of 1 tick error from the event source to the toggle. I believe in your setup you are exercising more peripherals? I cannot test your code as I do not have that photodiode to test with. 21 us see way off from what it needs to be.

[Cedric Honnet]

Hi,

Thanks a lot for your help!

Could you share the link of your repository?

It looks like our configurations are different: GPIOTE -> PPI -> TIMER

(The idea is to trigger timer captures to measure GPIO pulse widths)

Thanks again !!

[Susheel Nuguru]

I normally should have taken some snapshots, Not in a habit of saving all my desk test setups in a repository. 

But the setup looks more like the code in this thread. I instead used TIMER->CC to be 1 instead of 2.

In any case, the difference should not be as big as you see in your tests. That is more than 300 PPI sample clock ticks, which cannot be true for any of our systems that depend on PPI to work.

 

 

[Cedric Honnet]

Alright, hanks for the link anyway ;)