duplicated sensor records

trekwh · ‎12-30-2015

I was logging, through usb, overnight data from FRDM-FXS-Multi2-B with FRDM-k64F board, and noticed that quite frequent duplicated records for the same epoch, see below (bold epoch numbers),

pl. comment, thanks,

2604.076,Acc+Mag+Gyro,Aerospace,0.6,0.6,123.2,-0.013,0.016,1.037,-7.2,-9.8,34.9,0.30,5.00,-0.05,0.4749,-0.0022,0.0079,0.8800,0.25,0.10,-0.05,0.001,0.002,-0.039,-21.4,-56.4,-38.8,1.000,1.000,1.000,0.000,0.000,0.000,205,7.8,30.4,69.8,-0.00190,-0.00003,0.00000,-0.00213,-0.00043,-0.00057,-0.00010,0.00000,0.00000,0.00000,0.00000,0.00000,0.042,4.880,0.001,69.84,-77.294,24.50

2604.116,Acc+Mag+Gyro,Aerospace,0.6,0.6,123.2,-0.013,0.016,1.037,-7.2,-9.8,34.9,0.30,5.00,-0.05,0.4749,-0.0022,0.0079,0.8800,0.25,0.10,-0.05,0.001,0.002,-0.039,-21.4,-56.4,-38.8,1.000,1.000,1.000,0.000,0.000,0.000,205,7.8,30.4,69.8,-0.00190,-0.00003,0.00000,-0.00213,-0.00043,-0.00057,-0.00010,0.00000,0.00000,0.00000,0.00000,0.00000,0.042,4.880,0.001,69.84,-77.293,24.50

2604.116,Acc+Mag+Gyro,Aerospace,0.6,0.6,123.2,-0.014,0.014,1.041,-6.8,-10.6,34.1,-0.35,5.55,-0.10,0.4750,-0.0022,0.0079,0.8800,-0.40,0.65,-0.10,0.001,0.002,-0.039,-21.4,-56.4,-38.8,1.000,1.000,1.000,0.000,0.000,0.000,205,7.8,30.4,69.8,-0.00190,-0.00003,0.00000,-0.00213,-0.00043,-0.00057,-0.00010,0.00000,0.00000,0.00000,0.00000,0.00000,0.042,4.880,0.001,69.84,-77.293,24.50

2604.116,Acc+Mag+Gyro,Aerospace,0.6,0.6,123.2,-0.014,0.014,1.041,-6.8,-10.6,34.1,-0.35,5.55,-0.10,0.4750,-0.0022,0.0079,0.8800,-0.40,0.65,-0.10,0.001,0.002,-0.039,-21.4,-56.4,-38.8,1.000,1.000,1.000,0.000,0.000,0.000,205,7.8,30.4,69.8,-0.00190,-0.00003,0.00000,-0.00213,-0.00043,-0.00057,-0.00010,0.00000,0.00000,0.00000,0.00000,0.00000,0.042,4.880,0.001,69.84,-77.293,24.50

2604.356,Acc+Mag+Gyro,Aerospace,0.6,0.6,123.2,-0.013,0.014,1.040,-7.0,-10.6,32.8,0.05,4.40,-0.10,0.4750,-0.0022,0.0078,0.8799,0.00,-0.40,-0.10,0.002,0.002,-0.038,-21.4,-56.4,-38.8,1.000,1.000,1.000,0.000,0.000,0.000,205,7.8,30.4,69.8,0.00047,-0.00163,0.00000,0.00403,0.00410,0.00207,0.00000,-0.00007,0.00000,0.00003,0.00003,0.00000,0.042,4.880,0.001,69.79,-77.300,24.50

2604.356,Acc+Mag+Gyro,Aerospace,0.6,0.6,123.2,-0.013,0.015,1.038,-6.7,-10.7,33.9,0.05,4.40,-0.10,0.4750,-0.0022,0.0078,0.8799,0.00,-0.40,-0.10,0.002,0.002,-0.038,-21.4,-56.4,-38.8,1.000,1.000,1.000,0.000,0.000,0.000,205,7.8,30.4,69.8,0.00047,-0.00163,0.00000,0.00403,0.00410,0.00207,0.00000,-0.00007,0.00000,0.00003,0.00003,0.00000,0.042,4.880,0.001,69.79,-77.300,24.50

2604.396,Acc+Mag+Gyro,Aerospace,0.6,0.6,123.2,-0.013,0.015,1.038,-6.7,-10.7,33.9,0.05,4.40,-0.10,0.4750,-0.0022,0.0078,0.8799,0.00,-0.40,-0.10,0.002,0.002,-0.038,-21.4,-56.4,-38.8,1.000,1.000,1.000,0.000,0.000,0.000,205,7.8,30.4,69.8,0.00047,-0.00163,0.00000,0.00403,0.00410,0.00207,0.00000,-0.00007,0.00000,0.00003,0.00003,0.00000,0.042,4.880,0.001,69.79,-77.300,24.50

2604.396,Acc+Mag+Gyro,Aerospace,0.6,0.6,123.2,-0.014,0.017,1.041,-7.2,-10.8,35.0,0.00,4.65,0.00,0.4751,-0.0022,0.0079,0.8799,0.00,-0.15,0.00,0.002,0.002,-0.039,-21.4,-56.4,-38.8,1.000,1.000,1.000,0.000,0.000,0.000,205,7.8,30.4,69.8,-0.00053,-0.00073,0.00000,0.00493,0.00840,0.00353,0.00000,-0.00003,0.00000,0.00003,0.00007,0.00003,0.042,4.880,0.001,69.78,-77.300,24.50

2604.636,Acc+Mag+Gyro,Aerospace,0.6,0.6,123.2,-0.013,0.013,1.042,-7.1,-9.8,35.3,0.05,5.15,0.25,0.4751,-0.0021,0.0081,0.8799,0.00,0.30,0.20,0.002,0.002,-0.040,-21.4,-56.4,-38.8,1.000,1.000,1.000,0.000,0.000,0.000,205,7.8,30.4,69.8,-0.00140,-0.00013,0.00000,0.00120,0.00403,0.00143,-0.00007,0.00000,0.00000,0.00000,0.00003,0.00000,0.042,4.880,0.001,69.77,-77.334,24.50

michaelestanley · ‎01-04-2016

Trek,

I assume you are logging using the Sensor Fusion Toolbox for Windows and standard K64F build? Which software version were you using? And the board was not moving during the test?

We may just be seeing the result of limited precision in the time stamp variable, with data good otherwise. If you can respond to the questions above, we'll take a look at it.

Thanks,

Mike

trekwh · ‎01-04-2016

I was using the standard K64F build downloaded fresh from NXP webiste in late Dec 2015. The snesor fusion toolbox for windows has a build date of 11 Sep 2015. The board was stationary throughout the test.

I think by default, the record is 25Hz, which is 0.04sec interval, looking at the first two epochs, 2604.076, 2604.116, which is exactly 0.04, however then it output 6 idential time epochs and the time tag jumps to 2604.356, perhaps the cpu is overwhelmed with 9axis kalman filter task?

thanks.

markpedley · ‎01-05-2016

The problem is not at the Kinetis end. All the supported Kinetis MCUs run all the algorithms in parallel with time to spare even on the low end processors like the KL25Z. The K64F is high end with a floating point unit and is being stressed at less than 10% of its compute capacity.

The problem arises at the PC Windows end but is only really a minor annoyance in my opinion. I've just captured the following On Time stamps on the log file:

2824.92

2825.04

2825.08

2825.12

The correct interval at 25Hz is 40ms or 0.04s. Whenever you see the On Time stamp sticking it is associated with a larger time stamp gap immediately beforehand. In the sequence above the gaps between records are 0.12, 0, 0, 0.4, 0.4s. So it's self correcting and the On Time doesn't accumulate an error with time.

The root cause is that Windows is not a real time operating system and doesn't guarantee a response time. In the example above, Windows only activated its serial port callback when three groups of packets had been received and processed them all at once. The serial port activities and data logging activities are in different threads which also adds a certain lack of determinism.

I'll try to find a workaround for the next release.

duplicated sensor records

duplicated sensor records

SensorFusion