Reply To: Time Scale

[Andrey]

Dear Caleb,

I think I have approximately the same behavior of UM7 as Jason mentioned.

I have is UM7-LT with U71C firmware, connected with Pololu USB-to-Serial Adapter (based on CP2102). TX, RX, GND, Vin are connected and 3.3V is not. It is a long story how I came up with it, but the result is that in my opinion, at least my UM7 does not works correctly with rates. Let me explain what I mean.

Typically, and I think you will agree with me, that if it stated that a device is working at 100Hz that implies that:
1) with that frequency (strongly saying at least with that) MCR on the device reading current values from sensors;
2) with that frequency it transmits collected data to the logging end in a some type of packet.

In other words, and I underline this, the time between two measures (measures from sensor) have to be 10 ms (with 100Hz frequency).

If time at which the data from sensors acquired is available for user, it implies that the difference between two measures (time value recovered from two consequent packets, let’s call it DT) has to be the same 10 ms. Yes, strongly saying due to conversion to double and precision of MCR those 10 ms could have some stochastic addition, but the variation of it definitely has to be much less than 1 ms and the mean of such noise has to be zero.

What I have… PC: win 10 x32 and laptop with the same OS. I am trying to collect raw accels data with AD = 0x59. It will arrive as a batch packet where the third batch is a single floating representing DREG_ACCEL_RAW_TIME. Having in a row a number of such values, we can compute the difference between each consequent combination of time values. Having this, we can compute an average frequency at which (according to the UM7’s internal timer) accels measurements were done. Taking time values from the first and last packets, and the total number of received packets, we can compute an average frequency of receiving (transmitting) packets.

And here is the problem. Below in a table values of a desired frequency and the average frequency of measurements that I computed from the obtained time values. Average transmitting frequency is almost equals to what I have form frequency of measurements, so I do not place it here.
50 Hz ===== ~48 Hz
100 Hz ===== ~94 Hz
150 Hz ===== ~121 Hz
200 Hz ===== ~163 Hz
250 Hz ===== ~192 Hz.

Those results are consistent but differs a little bit from run to run. In addition, the computed DTs are not right on average, they are shifted up to 2 ms (instead of being zero mean), that is actually results frequency drop.

An additional observation I made that changing frequency by 1 or 2 Hz in CHR Serial Interface does not change observed frequency when the data is collected. As an example. If I set 100 Hz and collect data, the frequencies that I compute will be around 94 Hz. Now, if I change to 101 or 102 or … 105 or 95 or 96 in the the interval about +/- 5 Hz the computed frequencies will stay at the same 94 Hz. However, If I change to 110 (more than 5-7), than they will change significantly to ~102 Hz.

Converting DREG_ACCEL_RAW_TIME from 4 bytes to float is correct, otherwise, it will have a look of a complete mess. There are no bad packets, which check sums are wrong. No other data (including health packet) transmitted from UM7 at this time (no health packet). Its communication settings are set correctly with baud rate 115200 (did also tests with 25600 – result is the same). Nothing else (at least what depends on user activity) in windows is not consuming system resources. All this done with my program written in C++/Qt5.5.

In order to exclude any coding mistake I used CHR Serial Interface, did the same setup to UM7 and log incoming date from Log tab in CHR Serial Interface. Then, I wrote a code in Matlab that takes log file and parse it with matlab and did the same computations as before. The check sum was also verifies. And the results are the same.

My considerations are following.
1) If something will be wrong with connecting UM7 to Pololu and PC, or any communication problems will results in a massive mess in incoming data, but I definitely not at this point. By the way, I tried also much shorted usbB to usbA cable, but the results we the same. Pololu adapted should not affect it.
2) With effects related to the speed of communication, any problems should not show up at low frequencies, say 100 Hz (it is a pretty easy to communicate at such frequency). However, we definitely see frequency drop at 50 Hz and lower. So, this also not the cause of a problem.
3) The conversion from 4 uchar bytes to float is completely correct, I check it programmatically.
4) Since the average DT is consistent that implies that there are no missed packets at windows serial port buffer.

For me it looks like UM7 does not work on internal timer events or the frequency that we set from CHR Serial Interface internally transformed incorrectly.

So, do you have any ideas what is going on? I can send you the matlab code that does before mentioned stuff with the logs obtained from CHR Serial Interface. It produces some graphs, so maybe they might to understand that I wrote here…

Sorry for the long post, but I want to point out all details in order to solve the problem. Thank you in advance!

Andrey