Record continuously for 10h?

Ah, well spotted! I couldn't understand how the files could be the wrong length and yet still start at the correct time if there was no warning message about shutting the file prematurely due to a low battery voltage. There is no way for the file to close early without this message. There is also a FAT32 file size limit of 4GB due to the use of a 32-bit integer in the file size description. This has been a potential bug from the very first versions of the firmware but hasn't shown up before as previously it was very hard to make continuous recordings this size - you had to manually edit the record and sleep durations. Now that you can just disable the sleep/record cycle it's very easy. We'll have to think about how to fix this. In the short-term I guess it can just have to be a warning in the configuration app if we detect that this condition will be exceeded. We can at least make the firmware limit the maximum size of the WAV files that it generates to just under 4GB so that the files are closed correctly.

@Adrien

Alex was barking up the wrong tree regarding your original problem!

The real issue is that the length of the data chunk in a wave file is saved as a 32bit integer, which imposes a limit of 4GB - which corresponds to just over 1hr33min at a sample rate of 384kHz.

The AudioMoth will happily continue to stuff samples into the file beyond this limit but when it comes to write the header the maximum data size it can record is limited to only 4GB. The actual size recorded will depend on how the firmware handles overrun of the 32bit integer and is likely to be very much smaller than 4GB. My experience suggests that it resets to zero, so that the recorded data size will be the actual amount of data in the file modulo 4GB, however the numbers you posted suggest that the actual situation may be more complex.

If you check the sizes of the your files from the other night I predict that they will be 16,200,001 and 10,800,001KB (corresponding to 6 and 4hr).

So whilst all the data is actually present in the files, a sound editing application will only recognise the amount of data encoded in the 32bit integer written by the AudioMoth. If you import as raw PCM data then the software will generally do better and recognise 4GB. However the full amount of data can be recovered if you divide the files into chunks each containing less than 4GB of samples and either fix the headers or import the files separately as raw PCM.

You should be able to record files up to 90min long at 384kHz rising to over 2hr if you sample at 256kHz.

EDIT: If you need to rescue data by dividing over-large files then GSplit is a good tool for the job: www.gdgsoft.com/gsplit/

It tries to work to a fixed schedule rather than just recording for X seconds and then sleeping for Y seconds so that recording times across multiple days are the same if you switch to CUSTOM whilst already within a recording period. This means that if you set something like recording for 295 seconds and sleep for 5 seconds, you always get recordings that start on round 5 minutes (e.g. 00:05, 00:10, etc). This breaks down if there isn't enough time to open and close the files within the specified sleep period. In this case it does the best it can to keep up with the schedule.

Yes, this is the same issue as before. If you set the sleep period to 0 seconds the AudioMoth does not have enough time to close and open the file between each recording. It is running behind schedule and so reduces the recording length to try to keep on track. It normally takes about 2 seconds to close and open the next file - sometimes longer depending on the SD card, how many files are on the card, and whether it has been reformatted before use - so we normally recommend not using a sleep period of less than 5 seconds. If you use 295 seconds record and 5 seconds sleep, you lose a bit more time overall, but the AudioMoth has enough time to keep to the original schedule and all the files start at the correct time and have the correct length.

Another question @Alex, I'm sorry I take advantage of it during the tests. If necessary, I create a new post:

Continuing my question from yesterday (firmware 1.4.1), continuous recording in 300 sec file works perfectly, thank you again!

Simply I have slight discrepancies between the files (nothing very important), here is the test carried out:

You can see that after two files of 5 min, the files go to a duration of 4 min and 58 sec.

Do you have any information on this?

Thanks again Alex!

The battery voltage is measured at the start of the recording and the voltage will drop whilst recording at high sample rates as the continuous load is quite high. The timezone explains to two files. Does the comment say that the file was stopped as the voltage was too low? Once the recording is started the supply voltage to the processor is continually measured and recording will be stopped if it falls too low.

Thank you very much for your response Alex.

Here is the config file:

Device ID                       : 243B1F055B1F279B

Firmware                        : AudioMoth-Firmware-Basic (1.4.1)

Time zone                       : UTC+2

Sample rate (Hz)                : 384000

Gain                            : Medium

Sleep duration (s)              : -

Recording duration (s)          : -

Active recording periods        : 2

Recording period 1              : 00:00 - 04:00 (UTC)

Recording period 2              : 18:00 - 24:00 (UTC)

Earliest recording time         : ---------- --:--:--

Latest recording time           : ---------- --:--:--

Filter                          : -

Amplitude threshold             : -

Enable LED                      : true

Enable low-voltage cutoff       : true

Enable battery level indication : true

Here is the battery level for each file:

- first (8:00 p.m. to 10:58 p.m): 4.2V

- second (2:00 a.m. to 2:51 a.m): 4.2V

It's quite strange, after posting this message, I configured my audiomoth for continuous recording with 3600sec of recording and 0 sec of sleep duration. The displayed battery level was 4.4V and the recording worked perfectly overnight.

Thank you again for your help.

Strange. Can you post the CONFIG.TXT file that was on the SD card to confirm the configuration that was set on the device.

Also, if you can access the comments in the WAV header, it will report the battery voltage and say whether that was the reason that it stopped the recording.

I think this is because the battery ran down and the AudioMoth stopped the recording early. The comment in the WAV file header will confirm this. The two files result because the internally all the schedules run on UTC and stop and start at 00:00 UTC. If you are in UTC+2 the AudioMoth would have tried again to start the recording at 02:00 am, recorded for about an hour and then stopped early again due to a low battery voltage. Again the WAV file header will confirm this. The UTC 00:00 start and stop is a bit of a hold-over from earlier versions of the firmware and configuration app when we didn't support local time. At some point we might have to drop this backwards compatibility with how earlier versions worked but I think in the short time we can improve the configuration app to show the correct two recording periods when using local time.