Logging problem...

[dft5215]

I'm having problems with recording data to SD card. I've borrowed (for evaluation purposes) a unit from your UK distributor but I'm getting strange results for logged data.

For the record I'm running the latest firmware with the default configuration and no scripts running on the device.
The card is recording a series of data files (many of which are zero bytes) rather than a single file covering the whole of the time history between start/stop button presses. The majority of the files are fragments of the CSV history, so aren't readable by the PC software due to the absence (I presume - I've not delved into the code) of the first line header.

I tried a second card - one that I now communicates happily with microcontrollers as I've used it for a similar logging task before (and at higher output rates) - and that just threw the red light LED when I tried to record.

It looks suspiciously like a write time problem, i.e. not enough time to write the data to the card before the next lot of data comes ready.

Am I doing something wrong?

[andylaurence]

When you say "default configuration", have you actually enabled logging on any channels? If so, what rate are you logging at? How are you starting the logging?

[dft5215]

Logging standard GPS values at 10 Hz and accelerometers/gyro at 30 Hz. Starting with the button on the front of the device. I'm getting data, it's just that it's coming in fits and starts (the largest file thus far is 512 kb long) and interim files don't necessarily start with the header and thus get dumped by the PC software. Some files are zero bytes.

I'm far too lazy/time poor to try and work out from the GPS values exactly what data I'm losing and/or stitch the files together. I simply want to be able to have a single log file for a run (this is for an on-road driver behaviour program rather than track work) that I can pull the numbers I need out of.

[andylaurence]

Have you opened the files to see what data you have? Is LED1 showing GPS activity (10 times/second according to the guide)? Does LED2 flash when you press the button? I'm not sure if LED3 shows error states yet.

[dft5215]

I had done the idiot checks - I get the right sort of lights. As I said, I have data, save for the problem that instead of a single file, I get lots of them, some of which are slightly malformed in that some come in part way through a line of CSV and don't have the appropriate header at first line. Most files are less than a minute or two in length out of 40 minutes of logging or so.

I've even looked at the code on Github to see if I can spot anything glaring... there's nothing obvious there as a bug in the code which would cause the error (and to be fair the multitude of satisfied customers would suggest that there's nothing wrong in the code) but I have an understanding of why I'm getting the multiplicity of files - something is triggering the 'error recovery' part of the file writing code. I now just need to work out what in my system is causing that. Most obvious suspect is the SD cards I've tried themselves, so I'm now trying a third one (one that happily logs a lot more CSV data at higher rates in another bit of kit I use, although I don't know if that's via SPI or the 4 bit interface because I've not opened the box to have a look at what's in there).

[dft5215]

3rd card seems to have worked. Clearly not all SPI behaviour is the same. Might be worth putting something in the notes for future use. It might also be worth seeing if there's a way of testing card data rates or double buffering the input into the Sd card. puts() isn't the most efficient way of sending data

[brentp]

Thanks for the update. We've tested with a big pile of SD cards, but anyone who's worked with them knows that not all support the MMC spec very well. most of it is fairly laughable.

The interface is SPI on RCP, not 4 wire, BTW.