Retrieving data

When sampling starts, the logger opens a new binary data file on the SD card. Data files are created in sequence, DATA0000.BIN, DATA0001.BIN, DATA0002.BIN, etc. The first available filename is used when entering sample mode.

There are matlab and python scripts for parsing the binary data, in the software/matlab and software/freebird directories.

A sample binary data file (truncated to just a few casts), is here

##Binary format details For reasons of memory and CPU efficiency, all data is written to the SD card in 512-byte blocks. Each block has a header:

• 4 byte, unsigned, little-endian, integer "unixtime" giving seconds since the unix epoch (1970-01-01 00:00:00)
• 2 byte, unsigned, little-endian, integer "ticks" giving sub-second real time clock ticks (e.g. 1/1024ths of a second, see ticks_per_second below)
• 1 byte unsigned "frame_count" gives the number of data records in this block
• 1 byte unsigned "flags"

The LSB of flags determines the block type, where 0 indicates data and 1 text. The next bit (0x02) is set when there was a data overrun (samples could not be written to the SD card fast enough). This hasn't been an issue in testing so far, but would indicate that the SD card is too low quality for the requested sample rate and log_imu settings.

The timestamp, from unixtime and ticks, reflects when the first sample of the block was recorded.

Interpreting the structure and timing of data blocks requires parsing the text blocks at the beginning of the file. Text blocks contain regular ASCII text following the header, with C-style null-termination. The first blocks of the BIN file include the same text as if you typed info at the serial prompt. Of interest to parsing the rest of the file are the lines for frame_format, ticks_per_second and sample_rate_hz.

• ticks_per_second should be 1024, providing the scaling to go from ticks to fractions of a second in the timestamp.
• sample_rate_hz is what it sounds like, and is needed here because there is only one timestamp per block, but up to 250 samples in that block.
• frame_format describes how the measured data are encoded. It follows the python/numpy syntax for dtypes.

A sample frame_format might be:

frame_format: [('counts','<i2'),('imu_a','<i2',3),('imu_g','<i2',3),('imu_m','<i2',3),]

This is what you'd expect to see if logging the IMU, otherwise it would just be [('counts','<i2'),]. <i2 indicates that the values are signed, 16-bit little-endian integers.

counts is the ADC reading, based on a 4.096V scale, such that Vadc=4.096*counts/32768.

The IMU fields are each 3-vectors, with a=accelerometer, g=gyroscope, and m=magnetometer. The gyro and magnetometer both tend to have significant offsets, and the magnetometer needs a priori calibration. For details see the Arduino code, the MPU9150 datasheet, and the python support code.