Log MPU-6050 MEMS values on multiple lines

[ellisvalentiner]

The number of comma separated values per line depends on the data type. I propose always writing three values per line: , , and . Data types with multiple values such as ACC, GYR, and MAG can be distinguished by a suffix (x, y, z). This is already done for GPS values (i.e. latitude and longitude) and could be done with the MEMS data as well. This would involve modifying logMEMSData to make multiple calls to logData (like is done with logGPSData).

[mikebolt]

This would make the files easier to parse, but it would also increase the filesize. It might also make the firmware a little bit slower. It's not a bad idea, but it is probably not the best solution for everyone's use case.

With that said, if the goal were to maximize processor and memory efficiency, then it should use a binary format.

[stanleyhuangyc]

Binary format has best efficiency but not convenient for human review unless there is a tool developed. As for comma separated values, basically that's just for saving some storage. Maybe the storage is not an issue now.

[dogmatic69]

Its better to have them together. Everything is limited on a micro controller, space, write speed, etc.

Currently each "value" is on a line, x/y/z is one "value". x without y or z is pointless. Why should these values be treated differently than any other value?

What ever you are processing on can figure out how to use the three fields. Tuple is pretty standard format for something like this.

[ellisvalentiner]

@dogmatic69 I think it's more important to just be consistent and ragged CSVs are discouraged by RFC 4180 (not that anyone adheres to it anyway)

Parsed NMEA GPS values are written to separate lines but could also be written to a single line with a comma delimiter. Latitude is not very useful without longitude, just as ACC x is not very useful without y or z. Why should parsing the ACC values be treated differently than parsing any other value? That is why should these lines have 5 columns when all others have only 3? Perhaps another delimiter (e.g. semicolon) could be used to separate these values so that there is a consistent number of comma separated fields on each line.

So far I've seen negligible change in file size and haven't seen any issues crop up due to firmware slow down (although I haven't done a proper benchmark either).

If the primary concern is limitations of the micro controller, then it would be useful to consider other changes (binary format, optimizations).