I'm told they are looking to speed up saving in a future
I really wonder why Xensr have selected that kind of file format structure they did and if using current format how to optimize. It really does not support proper writing method of time-based stream data in my opinion.
Current format (I've reverse-engineered Xensr file):
- header section
- imu-data section
- gps-data section
- event-data section (jumps with jump data)
- text summary-data section
So writing like this means it must be written in sequel because all IMU-data must be cached and in the end of session written to flash at once. Then same for GPS-data and event-data.
Other option would have been constant streams with different packet type very similar to "transport stream" what your digital TV receives, video-stream, audio-stream, epg-stream, closed captions-stream, all interleaved together. With this approach Xensr could write block to flash when block is ready (write single block aka old-fashioned-sector at time to save battery and write wear). And if battery power goes to zero or system crashes you loose only some seconds of data instead for all session. Closing session would be instant and opening new session as well.
[Atom refers to a basic block of data - single stored value structure like timestamp, longitude, latitude, speed, gps alt, visible satellites. Imu atom would have timestamp,gx,gy,gz,rx,ry,rz,ax,ay,az,euler angles or quarternions, sx, sy, sz or anything what is calculated by IMU-unit on the fly.]
header
imu-"atom"
imu-"atom"
gps-"atom"
imu-"atom"
event-"atom"
imu-"atom"
gps-"atom"
...