Important changes to forums and questions
All forums and questions are now archived. To start a new conversation or read the latest updates go to forums.mbed.com.
9 years, 11 months ago. This question has been closed. Reason: Opinion based - no single answer
Sampling ADS1298 and logging to SD card
I'm trying to sample SPI ADC (ADS1298) and log it to an SD card. At the moment i'm sampling 96bits of data via SPI on interrupt at 500Hz, and buffering to a circular buffer. After 250 samples I write to the SD card. Everything seems to work well except every so often I seem to lose some samples and my data gets out of sync (See lines 9 and 10).
ADC data - HEX
C00000 000000 002424 01 01 15 C00000 000000 0022A9 01 01 15 C00000 000000 002113 01 00 17 C00000 000000 001F7E 01 00 17 C00000 000000 001DE6 01 00 17 C00000 000000 001C56 01 00 17 C00000 000000 001ADA 01 00 16 C00000 000000 001962 01 00 16 C00000 000000 0017D2 01 00 16 4C0100 16C000 000000 00 00 0F 490100 16C000 000000 00 00 0F
It appears as though the issue is caused by overheads from the SPI, I'm using chan's fs. If I remove the SPI ADC and just buffer fixed data and write that to the SD card I have no issue. The ADC and the SD card are on two different SPI buffers, operating at 20MHz for the ADC and 12.5MHz for SD Card.
Any suggestions as to what could be causing my issue?
The first column is always meant to be C00000 which is the status of the ADC, the second column is always 000000 as I am not using that channel, the 3rd column is one channel of the ADC, and the 4th column is unrelated to the ADC but is written to the buffer and SD card at the same time. So in lines 10 and 11 it has been shifted 4bytes to the right.
I interrupt on the ADC data ready pin, sample the data and then write to the buffer. In my main I wait until I have >250 samples and then write to the SD card. Because opening and closing the file was slowing things down a lot, I open the file once and then f_sync at the end of every block write.
From that I think it would be the overheads, however I then added an index to the end of every sample to see how many samples I was missing, this index was added to the end of every write to the buffer, and would increment within the interrupt. From the index I lost between 5-15 samples with no regularity. But my issue is, I was able to complete the sampling of the ADC, write to the buffer and increment the index, how did I lose the samples?
Also, the ADC will only give me data if I send it SPI commands, which will always start with C00000, so to obtain 4C0100 as in line 10 but still obtain C000 00 later in the same row suggests to me that something has happened to my data after I have sampled, not that I have missed sampling or that the sampling process was corrupted.
Does this help in trying to work out the cause? As an aside, would CSV be faster to write to than TXT with space delimiting?
I don't know exactly what I should see in that data, but if you think the overhead is the issue, try what happens with a slower speed.
Some more info on how you implemented it wouldn't hurt either. SD writes are quite slow, could it be that that simply is taking too muchtime? Do to the samples you lose correspond with SD writes?
posted by Erik - 03 Jun 2014The first column is always meant to be C00000 which is the status of the ADC, the second column is always 000000 as I am not using that channel, the 3rd column is one channel of the ADC, and the 4th column is unrelated to the ADC but is written to the buffer and SD card at the same time. So in lines 10 and 11 it has been shifted 4bytes to the right.
I interrupt on the ADC data ready pin, sample the data and then write to the buffer. In my main I wait until I have >250 samples and then write to the SD card. Because opening and closing the file was slowing things down a lot, I open the file once and then f_sync at the end of every block write.
From that I think it would be the overheads, however I then added an index to the end of every sample to see how many samples I was missing, this index was added to the end of every write to the buffer, and would increment within the interrupt. From the index I lost between 5-15 samples with no regularity. But my issue is, I was able to complete the sampling of the ADC, write to the buffer and increment the index, how did I lose the samples?
Also, the ADC will only give me data if I send it SPI commands, which will always start with C00000, so to obtain 4C0100 as in line 10 but still obtain C000 00 later in the same row suggests to me that something has happened to my data after I have sampled, not that I have missed sampling or that the sampling process was corrupted.
Does this help in trying to work out the cause? As an aside, would CSV be faster to write to than TXT with space delimiting?
posted by Andrew Cook 04 Jun 2014