Reply To: Time Scale

[Andrey]

Dear Caleb,

Ok. Now it is clear.

So in this case the frequency rates that is set via CREG_COM_RATES* has just no sense. It is not reliable at all. UM7 has a small chance to hit an exact moment when it is necessary to send data. It will always has a delay that is exactly that I have in my experiments. This delay (caused by the step 3 – read sensors, update states) will affects the real frequency at which the packets are transmitted and the real frequency will always less than the desired. That is why the transmission rate is differs from the desired one. Moreover, since the transmitted packet takes the last available sensor data and the time of the collecting data not fixed (in terms of time scale) than that is why I got such big difference between time values in two consequent packet.

Again that means that CREG_COM_RATES* just has no sense. For a 50Hz it could be fine that the delay of 0.3ms cause drop in frequency up to 1-2 Hz, but for 100Hz and more it will drop it significantly. Like I have for 200Hz that is in real about 163 Hz.

Is there any ways to avoid it? If I cancel any UM7 cyclic output by setting all rates them to zero and, then work with UM7 as follows: send command asking UM7 to send me back data and read response. In this case, yes, I have to realize timing to send periodically commands to UM7 by myself. However, without cyclic output, will UM7 immediately read sensors, compute states and send data to me on demand (when I ask to do it)?