©2019 Open Acoustic Devices

Sep 21, 2018

WAV headers with non-recognisable AudioMoth ID

2 comments

Dear friends,

 

We have used a number of devices (26) in a field experiment, and after tagging all resulting files automatically with a code routine, I've realised that the file headers of all them contain the same AudioMoth ID, which does not correspond to any of the devices we have.

 

I attach a screenshot of the header of a random file as shown in Audacity. No matter which software/recording I use to read them the ID in the message is always the same (whereas the rest of the details, such as date, gain or battery seem to be consistent):

The device ID we keep getting in all files is: 0FE081F80FE081F0

 

Any idea of why we don't get the real ID of the devices in the header? It would be a very convenient feature to help us tag every recording with a unique code.

 

Many thanks!

Sep 21, 2018

Hi, Yes, this was a bug in an earlier version of the firmware. We'll be releasing a new version of the firmware next week which fixes this. The new version also adds longer human readable file names with the time stamp, and the possibility of querying the firmware version in the configuration app. Alex

New Posts
  • Hi, I have purchased an AudioMoth to detect the ultrasonic sound emitted by bats. And I would like to know how can I detect i) count number of bats ii) bats' flying direction. I am doing a project to contextualize bat data through different actuators of Arduino. Using LEDs, speakers, motors, etc to visualize bat data. For example, if frequency = 45kHz, LED will light up; if more bats, the motor will spin faster, etc. How can I do that? And can I transfer the data live, and wireless, using a raspberry pi and upload it to the cloud? Again, how can I achieve that? Finally, is there any guide to manipulating the bat ultrasonic wav. file to human audible sound or visualize through spectrogram? Any tutorial for that? I am trying to use Adobe Audition. Many Thanks!
  • Hello, we deployed AMs with 64GB cards (formatted to FAT32 with a Mac) and 3 x eneloop 1900mAh AA batteries. Calculated they should last ~8-9 weeks at our recording schedule. Have just found that the first 8 we retrieved all ceased recording within a day of each other, 4 weeks after deployment. The cards only have 19GB of data each, so probably not a card issue. Individual testing of AA batteries pre- and post-deployment showed average voltage of 1.34 each prior, and now each AM had at least one battery with voltage as low as 0.06-0.21V (but others up to 1.14V). Stumped, as a colleague had the same set- up with a slightly longer daily recording schedule and longer deployment, with no issues. Am I right in thinking: 1) there is some critical minimum threshold in battery voltage, below which the AMs won’t work, despite our calculations they should have lasted twice as long? 2) if we decrease the amount of data collected per day they would last longer, and 3) does ticking or unticking the ‘enable low battery cut-off’ box in the configuration app make any difference to this? 4) is there a large error around the mAh drawdown prediction on the app that could explain our predicted vs actual data collection period?
  • Hi, in all my recordings there's a "clicking" noise (26-28kHz). This is an issue that I had before with some recordings but now the noise is louder and it is present in all recordings. The batteries are Energizer AA (new) and the SD card is the SanDisk Extreme 32GB. Is there Anything I can do to make the "clicking" noise disappear?
Before posting, be sure to check the FAQ.