Reply To: Time Scale

[Andrey]

Hi Caleb,

Thank you for quick response.

I agree that transmission rates could drop, but they cannot drop as much as I noticed before. Two months ago I did work with the approximately the same device not from CH Robotics, but I was able to read (say the same 20 bytes as for AD = 0x59) from it at rates about 250 Hz without any problems. Yes, there are could be delay due to transmission, but it is consistent and does not increase with frequency increasing. I also agree that delay in transmission will be no zero mean. And I have it about 0.2 ms.

Strongly saying, with 115200 b/s = 14400 B/s it is completely possible to transmit 20 bytes (AD = 0x59 packet) * 100 Hz = 2000 B/s. It consume only 10% of a channel.

UM7 provide me with DREG_ACCEL_TIME. Assuming that the time in DREG_ACCEL_TIME is the internal time at which UM7 read data from sensors, and, assuming that UM7 does it with the same frequency as set for transmitting data, the values of time (for instance for the 100 Hz) should looks that:
1 packet. Time: 00.0 ms. (Yes, UM7 send it as seconds).
2 packet. Time: 10.0 ms.
3 packet. Time: 20.0 ms.
4 packet. Time: 30.0 ms.
5 packet. Time: 40.0 ms.
6 packet. Time: 50.0 ms.
and so on…

However, in fact, they are not like this. They looks approx like that:
1 packet. Time: 00.7 ms.
2 packet. Time: 10.2 ms.
3 packet. Time: 21.2 ms.
4 packet. Time: 30.4 ms.
5 packet. Time: 40.5 ms.
6 packet. Time: 50.2 ms.

And they are shifted when they should not be if the internal timer works exactly at 100 Hz. Strongly saying, yes, they cannot be absolutely 10 20 30 and so on, they might have some noise but it cannot be comparable to 1 ms and on average it should be zero. Therefore, I expect to see something like this:
1 packet. Time: 00.00007 ms.
2 packet. Time: 10.00002 ms.
3 packet. Time: 19.00089 ms.
4 packet. Time: 30.00004 ms.
5 packet. Time: 39.000405 ms.
6 packet. Time: 50.000452 ms.

Transmission frequency is out of this business. These time values are came from UM7.