We deployed 30 AudioMoth in 2019. 20 were hardware version 1.0.0, 10 hardware version 1.1.0. Firmware for all was 1.2.0, configuration app 1.1.5. The AM were setup to record 1 minute every 10 minutes. While working on analyzing the data we found some strange patterns. While the 10 AM hardware version 1.1.0 showed expected patterns birds being most active at dawn and dusk, 17 of the hardware version 1.0.0 AudioMoth showed 4 peeks during the day and we found recordings of birds and other diurnal species during the night and recordings of bats during the day. Also, for those AM, the time of the first recording did not correspond to the time of deployment (the recording dates were earlier than the actual deployment date, all AM were programmed several days before deployment and stored with the switch OFF). Digging deeper, the hypothesis is that somehow the real time clock was running 4 times slower. Time stamps (both file name and metadata) showed a 10 minute recording interval, but in real time the recording interval was actually 40 min. This might actually be the same issue that was reported here (in that case the AM were programmed every 30 min but recorded every 2 hours): https://www.openacousticdevices.info/support/configuration-support/wrong-filenames-time-not-matching
top of page
To test this feature, visit your live site.
2 Comments
bottom of page
Hi Alex, thanks a lot for the quick response. Your explanation perfectly fits our situation. I updated the firmeware right before programming all the AudioMoths, so the batteries would already have been inserted and there would not have been a reset. And I just checked and the update was indeed to 1.2.1 from some previous version. It is possible/likely that the newer version AudioMoth (1.1.0) were already on that firmeware and I did not update those, hence they had no issues. We also noticed that the recording time was correct and assumed that that was controlled by the oscillator, thanks for confirming that too.
It's great to have your explanation, as we have been scratching our heads trying to figure out how this could have happened, but I am also glad to know that is is not a hardware issue and we won't have any problems with these devices going forward. We will make sure to run future firmware updates without batteries.
Best, Mathias
Hi Mathias, Between firmware version 1.2.0 and 1.2.1 we updated the time handling routines and this change included a change to the rate of the internal real time clock. I think what has happened is that the AudioMoth was updated, most likely from 1.2.0 or earlier, to 1.2.1 or later, and was then configured and deployed, without powering down in between. We always recommend to reflash without batteries fitted so that this cycling of the power always happens. Without cycling the power the clock continued to run at the original rate which was slower by a factor of 4. You can see this effect in the attached video. I have updated from version 1.2.0 to 1.2.1 without cycling the power, and the clock in the Config App is running at 1/4 of normal speed. When I cycle the power and plug the AudioMoth back in, the clock is running correctly again.
Does that sound like what happened in this instance? The same effect would be apparent for a degrade in the firmware version that goes from 1.2.1 or later, to 1.2.0 or earlier, without cycling the power. However, in this instance the clock would be running 4 times faster, until the power cycle occurs.
Once the recording is running, the timings are controlled by the 48MHz quartz oscillator so the recordings are still at the correct sample rate and will be the correct duration. Given this x4 time factor, is it possible to reconstruct the intended timings? Alex