To test this feature, visit your live site.

repeated SD card failures after extensive recordings

Dear AudioMoth community,

I am currently on fieldwork and I am using the AudioMoths for two different setups:

A long-term experiment lasting 3 days, with around 18 hours of recordings per day. This is repeated 3 times (so 9 days in total). All 16 AudioMoths are used. (finished experiment)
Daily experiments with 4hrs of recordings in the evening and 5 hrs in the evening. 14 AudioMoths were placed in cones to record one individual animal. (ongoing experiment)

For both these setups I require synchronised recordings, hence all AudioMoths have been flashed with the GPS Sync firmware. I have attached the SETTINGS.txt files for both setups.

I am currently doing the daily experiments and more and more AudioMoths keep showing up with SD-card failures or other forms of data loss. So far, 9/16 AudioMoths needed a replacement SD card. Of the AudioMoths with this issue, battery levels were generally good (>4.7 V). All AudioMoths are equipped with Energizer Ultimate Lithium batteries and Sandisk Extreme microSD card 64 GB. Temperatures inside the cone can get somewhat hot (< 34 C) as it is summer.

Does anyone have suggestions on what could be the problem? I am happy to replace the SD cards, but I'd like to know the root cause. My ideas of potential causes are:

My recording schedule during the long-term experiment is too extensive. The AudioMoth writes out files every 4-5 hours. Could this cause a strain on the SD-cards?
The AudioMoth get too hot inside the cones, which may harm the SD card or other processes.

Any help is appreciated.

6 comments

6 Comments

Alex Rogers

23h

Other users have reported high energy use from SanDisk cards made in Taiwan but this doesn't seem to be the problem here. It may be that the battery voltage is dropping significantly throughout the long recording as the GPS modules take quite a lot of current. Are these GPS hats with AA batteries? Reformatting the cards is always a good move as some operating systems will hide files rather than deleting them and AudioMoth isn't able to delete the hidden files whilst it is writing. This sometimes causes SD cards to become full and give SD card write errors while there is still apparently space left. It would be safer to make a sequence of short recordings. You can use sleep and record cycles within the recording period as long as the sleep period is longer than the recordingFixDuration. The recordingFixDuration is currently 900 seconds - 120 seconds should be sufficient to get a fix in warm start so you could record for 58 minutes and then sleep for 2 minutes. This would mean that the recordings are shorter and there is less likelihood of an SD card write error corrupting the entire period.

Depending on the accuracy you need, you might also be able to switch back to the standard AudioMoth firmware which now has more support for GPS synchronisation before and after each recording, and the ability to generate _SYNC.WAV file from the recorded GPS data. This will lessen the load on the batteries as the GPS module is not run throughout the recording. The recording will typically be synchronised to a few millisecond, rather than better than one microsecond, when using the AudioMoth-GPS-Sync firmware.

Edited

Malou B

23h

Replying to

Hi Alex!

I am using the AudioMoth GPS hat. This GPS hat is soldered onto the board, so there are no separate AA batteries for them.

I will try reformatting them. The ones I have reformatted seem to be doing well, but I will have to wait until tomorrow to see the final results. This could also explain why most SD cards are having problems suddenly (as file sizes reach above 64 GB).

Adding a sleep schedule has also been on my mind as a potential solution. Is there any benefit of using the sleep schedule over just scheduling 1-2 hrs recordings? I was a bit unsure how well the sleep schedule functions in combination with the GPS hat attachment.

Thank you so much for your help! I will definitely try your suggestions.

All the best, Malou

Alex Rogers

23h

Replying to

Yes, looking at your schedules it is easier not to use the sleep/record cycles. It's sometimes useful if you reach the 10 recording periods limit (e.g. you want 24 one-hour recordings per day). The recording duration of a couple of hours isn't particularly long so I wouldn't expect the batteries to be the issue. Possibly over a much longer period. Reformating is probably the first thing to check as that will definately cause the symptoms that you are seeing whereby the files are not closed correctly so end up with zero size.

Malou B

10h

Replying to

Ah, thank you. For these daily experiments, I will stick to my current schedule. When I start doing longer recordings again, I will reconsider my recording schedule. From my overnight experiment, it seems that reformatting might be the solution. Hidden files were taking up extra storage in some cases. I will reformat all my SD-cards and see whether it fixes the issues.

Alex Rogers

Hi, Can you describe what symptoms the SD-card failure shows? Not readable? Also what are the symptoms of data loss. Can you use the 'Summarise AudioMoth Files' tool in the Config App to generate a summary of a readable SD card? Are the SD cards the same? Can you check the location of manufacture that is printed in small writing on the back of the card. Alex

Malou B

24h

Replying to

Hi Alex!

I was able to open and read all faulty SD-cards. Often these files started with correct recordings, after which full or parts of recordings were missing. These partial recordings still contained readable audio files. When full recordings went missing, either no file or an empty .wav file was written out. The majority showed an SD-card error in the log.txt file (Recording stopped early due to an SD card write error).

I check before deploying the AudioMoths for any errors, but the lights were always showing the correct flash patterns. I have tried the summary file tool in the config, but it did not provide additional information so far. I have added two summary files of SD cards with problems. In cases where no correct recordings were made, the summary file only contains a header.

I cannot check each individual SD-card yet (I am testing whether reformatting helps and the working SD-cards are currently in the field), but the 7 "problem" SD-cards I was able to check, were made in China. I had to order in batches, but there seems to be no pattern in serial number to those showing problems.