How to interpret the Freematics data logging format

[klemens]

Hi,

I know there is an article about this topic under: http://freematics.com/pages/software/fr ... ng-format/, which I read again and again, but I don't get it. I got two questions.

First: There are supposed to be timestamps at the beginning of each entry telling me the offset in milliseconds since the "previous data entry". But what is that omnious "previous data entry"? Looking at the example data on the before mentioned page I get several accelerometer values with a timestamp of 0. So what is the meaning of that? Do they all occur simultaneously? How is that possible?

Second: How do I interpret the accelerometer values? What is the unit used? If I get -913 this probably is not m/s². If it is I am most likely dead already.

Here the example data set I am refering to for reference:

Code: Select all

#5506,10D,55
0,ACC,-913,18,528
0,GYR,-9,-22,17
111,104,0
0,ACC,-922,6,548
0,GYR,1,-27,17
30,111,16
0,ACC,-922,-9,513
0,GYR,-4,-36,24
29,10F,32
0,ACC,-927,14,573
0,GYR,-14,-11,16
8,UTC,2020520
0,DTE,200116
0,LAT,-33730629
0,LNG,151159065
0,ALT,16200
0,SPD,55
0,SAT,5
33,10C,0
0,ACC,-890,23,556
0,GYR,-7,5,20
30,10D,55
0,ACC,-926,25,592
0,GYR,-16,8,5
29,104,0
0,ACC,-946,-39,536
0,GYR,-5,-10,30
30,111,16
0,ACC,-861,33,469
0,GYR,-9,2,21
31,131,4260
0,ACC,-909,-49,543
0,GYR,-14,-3,10
8,UTC,2020540
0,LAT,-33730628
0,LNG,151159031
0,ALT,16240
0,SPD,55
0,SAT,5
61,10C,0

[stanley]

The timestamp value means the time since last data was retrieved. 0 means same time as last data. Hope that makes it clear.

[klemens]

So in the example data the first ACC entry was received at 5506, while the second was received 111 ms later, am I correct? If yes I think I got it.

For my second question. Could you please tell me what is the measuring unit for the acceleration values like -913, or how do I convert that value to get it in m/s² (meter per square second).

[klemens]

Ok. I got an example dataset directly from my FreematicsONE v4 which looks like:

Code: Select all

#6103,ACC,2,-1,109 0,ACC,2,-1,109 0,ACC,2,0,109 0,ACC,2,-1,109 0,ACC,1,0,110 0,ACC,2,-1,109 0,ACC,2,-1,109 0,ACC,2,-1,109 0,ACC,2,-1,109 0,ACC,2,-1,109 0,ACC,2,-1,109 0,ACC,2,-1,109 7728,UTC,7284200 0,LAT,51.025750 0,LNG,13.722881 0,ALT,179
#75831,ACC,2,0,109 0,ACC,2,-1,108 0,ACC,2,-1,110 0,ACC,2,-1,109 0,ACC,2,-1,109 0,ACC,2,-2,109 0,ACC,2,-1,110 0,ACC,2,-1,109 0,ACC,1,-1,109 0,ACC,2,-1,109 0,ACC,1,0,109 0,ACC,2,-1,110 7732,UTC,7295170 0,LAT,51.025763 0,LNG,13.723145 0,ALT,179
#145529,ACC,2,0,108 0,ACC,2,-1,110 0,ACC,2,-1,110 0,ACC,2,0,109 0,ACC,2,-1,109 0,ACC,2,0,109 0,ACC,3,0,108 0,ACC,2,-1,109 0,ACC,2,-1,108 0,ACC,2,-1,109 0,ACC,2,0,109 0,ACC,2,-1,109 7733,UTC,7310140 0,LAT,51.025672 0,LNG,13.722639 0,ALT,164
#215160,ACC,1,0,109 0,ACC,2,-1,108 0,ACC,2,-1,109 0,ACC,2,-1,109 0,ACC,2,0,109 0,ACC,2,-1,109 0,ACC,2,-1,109 0,ACC,1,-1,108 0,ACC,2,-1,109 0,ACC,2,-1,110 0,ACC,2,-1,109
#215160,ACC,3,-1,110 0,ACC,2,-1,110 0,ACC,2,-1,109 0,ACC,2,-1,110 0,ACC,3,0,109 0,ACC,2,-1,108 0,ACC,2,-1,109 0,ACC,2,-1,109 0,ACC,2,-1,109 0,ACC,2,-1,109 0,ACC,2,0,108 0,ACC,2,-1,108

It raises several questions:

1. Is the absolute timestamp really (as the documentation states) in seconds? As 2151160 are approximately 60 hours and I just started the device.
2. Why are there multiple ACC values all with a timestamp of '0'? I think it is impossible that the device was accelerated multiple times at the same instance of time.
3. And still there is the question of what does an acceleration of 109 in z direction mean? Since the device is lying flat on my desk, I assume it is approximately 9,81 m/s². But how do I convert that value? I would also be fine with a conversion to imperial units, if that is easier.

[mikebolt]

Hi klemens.

This excerpt from the data format page should answer your first question:

Time has two conditions. If it is a numeric value, it represents time in milliseconds elapsed since last data retrieved. For example, 10 indicates 10ms passed since last data is obtained, while 0 means the data has the same timestamp as last data (retrieved at the same time). If it begins with a # and followed by a numeric value, it represents the absolute time in milliseconds since the device starts working. For example, #5000 means it is 5 seconds since the device has been powered on or reset.

All timestamps, both absolute and relative, are in milliseconds. This means that your absolute timestamp of #215160 is actually 3 minutes and 35 seconds after the device started.

However, looking at your more recent data file, it seems like it doesn't follow the specification. There are multiple entries on a single line and your LAT and LNG values have decimal points in them, whereas the specification says that all values are integers. You should double-check which version of the data logger you have, and possibly re-flash it with the latest version.

It is also possible that you have encountered a bug. The timestamps are kind of strange. I am not sure why there would be multiple accelerometer samples in a single millisecond, then nothing until there's a GPS sample 7.7 seconds later.

For the record, I don't have any of these problems with the data collected from my FreematicsONE v4.

[mikebolt]

After some sleuthing I think I have figured out the answer to your third question (I needed to know the answer as well).

The accelerometer values are logged in the function logMEMSData in datalogger.ino:

Code: Select all

logData(PID_ACC, mems.value.x_accel / ACC_DATA_RATIO, mems.value.y_accel / ACC_DATA_RATIO, mems.value.z_accel / ACC_DATA_RATIO);

So it takes some values from mems.value and divides them by ACC_DATA_RATIO. From config.h, we find that ACC_DATA_RATIO = 160.

In datalogger.ino, the mems variable is declared as type MEMS_DATA. This type is defined in FreematicsONE.h. This struct is filled by the function memsRead in FreematicsONE.cpp. There's nothing fancy here. It just copies the values straight from the MEMS registers.

The accelerometer is part of the MPU-6050 board. I found a relevant datasheet that has a description of the accelerometer registers on page 29. Each acceleration value is a 16-bit signed integer. Depending on the value of AFS_SEL, these values have different units. The table on page 29 gives the units in LSB/g, or "least significant bit" per G of acceleration. By inverting these constants, we have four possible units for the *_accel values, from 1/2048 to 1/16384. I couldn't find any place in the code where the AFS_SEL bits were set, so I'm guessing they are at their default value. The document says that "The reset value is 0x00 for all registers other than [0x40 and 0x68]". So it's probably using the +/- 2g setting. This matches with my observations. During a stable section, my accelerometer data had values of about (-50, -5, 90). This has a magnitude of 103.0776. With the default sensitivity range, we can calculate the acceleration magnitude in G's:

Code: Select all

A = 103.0776 * 160 / 16384 = 1.0066

I am guessing 160 was chosen so that the units would be approximately 1/100th of 1G. In that case, 164 would be a better choice.

Anyway, the answer is that the units of the accelerometer values are 0.009765625 G's.

[AbhIoT]

Hi @mikebolt
Thanks for your explanation.
I understood your explanation till the point you said, "my accelerometer data had values of about (-50, -5, 90). This has a magnitude of 103.0776." ? How you come up with 103.0776 from those values ?

What I understood from you post and accelerometer datasheet: if (-50, -5, 90) are (X,Y,Z) values logged from inbuilt data logger firmware, then
acceleration at X axis = -50 *160(to correct approximation done in original code) * 9.81(value of g)/ 16384 in m/s^2
acceleration at Y axis = -5 *160(to correct approximation done in original code) * 9.81(value of g)/ 16384 in m/s^2
acceleration at Z axis = 90 *160(to correct approximation done in original code) * 9.81(value of g)/ 16384 in m/s^2

is this correct?
thanks!

[mikebolt]

Yes, that is the correct conversion for meters per second squared.

You can treat the X, Y, and Z values of the accelerometer as an acceleration vector. I was referring to the vector magnitude of the acceleration vector.

[AbhIoT]

Oh! gotcha.
thanks.
I am wondering why they did not perform this simple conversion in their sample code ? or not provide any explanation for division by 160!!

[stanley]

Please refer to this:
http://freematics.com/pages/software/fr ... ng-format/