Document the delta time between IMU readouts

[dylanmckay]

No description provided.

[mungewell]

Read the wiki here:
https://github.com/gusmanb/PSVRFramework/wiki

We spent quite a bit of time digging/reverse engineering/documenting this data... and you're free to re-use.

[dylanmckay]

Thanks @mungewell!

[m-7761]

I looked at this once. I remember seeing 200 samples per second, or an interval of 0.005 seconds. They are unwavering. I don't think this figure is mistaken. (I can easily check it. I would if I had the set out/on ATM. In fact, I'll make a note to...)

It's 2000/s, or 0.0005. This is inline with talk of the sample rate being 2 per 1/1000th of a second. It seems like a lot, compared to real-time frame rates.

[m-7761]

2000/s, or 0.0005

[dylanmckay]

Perfect, cheers @mick-p1982!

[dylanmckay]

To confirm, is this the delta time between the two sets of accelerometer and gyro readings within a single sensor frame, or is this the minimum delta time between any two successful reads on the sensor interface?

[m-7761]

It's the delta between the two samples packaged in each USB data packet, for example. It's typically like clockwork, although I have observed other values. Although I wouldn't be surprised if the other values were because the UDP buffer overflowed, possibly because of breaking into the program to debug it...

In that case you'd be missing many samples that were discarded by the UDP buffer (dropped datagrams) and so naturally the delta would reflect the difference between the two valid/available datagrams.

The timing is very precise. I don't know if temperature or other conditions could cause it to change. It may be so regular that it's only value is to recognize when data is lost.