I encountered a possible bug while using the chime feature of the Rainforest Connection "Companion" app to set the time on an AudioMoth today.
I had just configured the AudioMoth a couple hours before, but it was jostled and lost its set time. I used the app to set the time. After that, I changed the AudioMoth to USB/OFF mode and plugged it into my laptop to check that the time was set correctly. The config app showed that the time was late by 2 hours (displaying 17:44 UTC instead of 19:44 UTC). I am in Eastern timezone, UTC-4:00. I tested the AudioMoth by removing the batteries and attempting to use the app again, and this behavior happened again once or twice, then stopped happening.
Subsequently I have reproduced this problem and gotten a variety of incorrect times, including roughly 2 min, 20 min, 35 min, 40 min, more than an hour, etc.
Has anyone encountered this or could think of a reason it could be happening? One possible source could be some very high frequency sound in our lab space aliasing down into the audible frequencies and messing with the app chime.
Hi Tessa, The fix for the time bug will be coming out on the Google Play Store over the next few hours. Alex
Hi Tessa, Yes, we reproduced this. The time it sets seems to be the time that the app is opened, rather than the time you press the button. That will explain the increasing offset. The workflow is also quite complicated in that it isn't really described in the app what the tone is doing, or that you need to switch to CUSTOM whilst the tone is actually playing. I think many users will have just replaced the batteries and it will go to acoustic mode by itself anyway without them realising what is actually happening here. Alex
Alex, thanks for the explanation on the differences between the apps and the three ways to enter acoustic mode. (That RFCx deployment ID feature is great, too!)
Yes, it does look like the time error corresponds to the time the app was opened, so that may solve that mystery.
Could the time error you see correspond to the time when the app was opened or started, rather than the time the button was pressed?
That's very strange. I'll let them know and put them in touch with you.
Yes, the 'acoustic mode' is indicated by a solid red and flashing green LED. The AudioMoth will only listen for the tone when in acoustic mode.
They will enter acoustic mode automatically on switching to CUSTOM if the time has not be set. You can also enable the 'Always require acoustic chime on switching to CUSTOM' option in the Config App which makes them enter acoustic mode every time, even if the time has already been set. The third way to switch to acoustic mode is to play a special tone whilst switching to CUSTOM. This is what the RFCx app is doing. It is also playing a different tone as it is also setting a 'deployment ID' in addition to the time. This deployment ID gets written into the file headers so that uploaded files can be linked back to the time and location of deployment. I'll follow up with RFCx also about the time setting as that seems strange.
Hi Alex,
Sorry for the slow reply--was out deploying AudioMoths last week!
I just downloaded and tried the Android AudioMoth app several times. The time set on the AudioMoth when I plugged it into the computer was correct every time. So, it seems this error is isolated to the RFCx Companion app. I reinstalled the Companion app today, tried it on a different AudioMoth, and encountered the same problem. (The devices are keeping time normally when plugged in to the computer.)
Another question--I noticed that the Companion app seems to switch the AudioMoth into a "listening mode" (indicated by solid red LED + flashing green LED) when the AudioMoth is switched from USB/OFF mode into CUSTOM mode while a long tone is playing.
I had been testing the Companion app in a room full of already-programmed AudioMoths that were turned to CUSTOM mode. When I encountered the time setting bug, I was worried that the chime would have incorrectly reset the time on all of the AudioMoths in the room. After I experimented with the app a little bit more, I found that it seemed the AudioMoths can only be programmed by chime when they are in the solid red LED + flashing green LED mode. Is that true, or are there any other modes in which the AudioMoth time could be reprogrammed by chime? The chime pattern used by the two apps is different; does this behavior vary by app?
On a related note, the Android AudioMoth app doesn't seem to have a similar behavior where it switches the AudioMoth into the chime-listening mode. Is it true that the AudioMoth app would only be able to set the time on the AudioMoth if (1) the AudioMoth lost time due to loss of batteries, or (2) the AudioMoth was configured with the "Always require acoustic chime on switching to CUSTOM" option? Just want to be sure I understand these correctly. Thanks!
I’ll test the app today myself also.
I don’t think it can be the interference as the chance of a bit error satisfying the CRC error check is vanishingly small.
Did you check that the devices are keeping time normally in the Config or Time app? That would be another possibility.
Does the same thing happen with the Android version of the AudioMoth app?
Hi Alex,
- Does it generate lots of failed attempts to set the time? The time setting process has succeeded (continuous red light turned off) on the first try all except for one time. That one time, the time setting "took" after another attempt at the chime.
- Did this happen on just one device? This happened on 3-4 devices. Something went wrong on all of the devices I tried the acoustic chime on.
Hi Tessa, The time is protected by a error check so I think it's unlikely that the background noise is causing the problem. Does it generate lots of failed attempts to set the time? One possibility is a bug in the setting the time within the tone but it's strange that it isn't consistent. Another, possibility is that your AudioMoth isn't keeping time correctly. Did this happen on just one device? If you set the time on the Configuration App or the Time App, and check it later in the same app, is the elapsed time correct over a couple of hours? Alex