VSDSP Forum

Hello and thanks for your time,

For a few years now I have had a device working well recording good quality high frequency data to SD card, and another device which as been recording low frequency data to multiple SD cards based on your 8 SD daughter board you put the designs up for a few years ago(viewtopic.php?t=2160)

Recently I have been tasked with making a high frequency recorder that can be deployed for months at a time. I started by designed a PCB based on the HiRes BOB v2. As I always do i prototyped it up on Vero board. There were loads of write failures, I realised I was using the old SDSD driver so updated it to SDSD23 but with this little bit of script to select the correct SD card.

This makes it better, it is recording, but I am still getting completely random errors for 'Write', 'Read' and 'Multiple Block Write'. I have been trying to solve them over the past week and just keep going round in circles. So on another BOB I ran my code, obviously without the code above to select the SD card and there are no problems at all. I am using high quality fast SD cards, formatted to Fat32.

So, this leads me to think that the problem is likely to be caused by the maelstrom of wires I have between the breakout boards, multiplexer and sd card.

before I go ahead and order the PCBS could you possibly confirm a few things?
a) using the above design for multiple SD cards had been tried with the VS23S040?
b) could having a suboptimal routing of wires be the cause of the seemigly random errors?

Thanks again

Rob

What kind of completely random errors you get? Are the functions returning error codes, or the data just ends up being garbage?

Some wav files are fine. I haven't scrutinised them for dropped samples, but they seem ok.
there are some files that are not actually saved correctly. These tend to have garbage file names and are usually 1kb in size.
Sometimes after it crashes the SD card will not open on windows and will need formatting.

Then the errors shown in the terminal window are

E'Write'
E'Data Fail'
E'Read'
E'Multiple block write'

I did have a text file that was being written as well, however I removed this for the time being and this removal seemed to reduce the amount of E'Multiple block write' being displayed, however I am not sure. There doesn't seem to be a pattern to it and I am formatting the the SD card between each test. I am waiting on delivery of some new SD cards in case I damaged them with all this testing, but they seem ok.

Thank very much

Rob

Hi,

If the wire spaghetti isn't the cause, one thing to think is that there is correct pull-up/pull-down resistors.

VS1005 and VS23S are pulling the 8-bit bus to opposite directions. Also there should be external regulator and pull-ups for SD card.

I like to use 10 k and it is usually enough to make things work.

Thank you so much for this. For the purpose of prototyping this thing up I used the multiple SD board I built years ago. Of course this doesn't have the 47k pull-up resistors on it as they are on the developer board, and not on the BoB.

I will as stick them in, and any more that I may have missed, hope for and improvement, then put on to my PCB design.

Thanks again, this has saved a lot of wasted time.

RLee wrote: ↑Tue 2024-11-26 16:30 Some wav files are fine. I haven't scrutinised them for dropped samples, but they seem ok.
there are some files that are not actually saved correctly. These tend to have garbage file names and are usually 1kb in size.
Sometimes after it crashes the SD card will not open on windows and will need formatting.

Pasi and Hannu have already given you good hints, but as the author of the HiRes Recorder software, here are a few words of how the recorder software works internally.

1) Before recording, the HiRes Recorder finds the longest consecutive empty block there exists on the SD Card. On an empty card, this is the full card, but on a (maliciously) fragmented card, this can be surprisingly much smaller than the full card.

2) When recording is started, the Recorder writes a placeholder WAV file header, then up to about 2 GB of audio data. If the recording is still going on, then every roughly 2 GB, a new WAV header is output, for reasons coming up later. It writes directory to the device instead of going through our file system handler. Thus, no FAT file entries are created. This ensures that the SD Card writing goes as smoothly as possible and that not a single audio sample is lost. (This is a long and wild story and I'm not going there now. Suffice to say that writing audio to consecutive blocks causes by far the least timing issues on an SD Card.)

3) When recording is stopped (either by pushing stop or by end of space on SD Card), the file entries are created one by one. At the same time, the WAV header of each file is modified to reflect the actual size of the file.

If something goes wrong between points 2 and 3, or during point 3, the file entries may be created incorrectly, and I could imagine the results being approximately the random results what you have described. Actually, technically there is still the chance that the actual audio data is (mostly) there, but without FAT file handles pointing to correct locations, accessing them would require a special tool. Something that would actually not be that impossible to write for Linux (something like cat /dev/sdc | hiresrecsavetool) but that I couldn't write to Windows if my life depended on it.

Kind regards,
- Henrik