Hi everyone,
We're running an acoustic project that records evolving periods : periods are night from sunset to sunrise and are changing every day.
We are therefore looking at 1) how to implement the sun almanac/recording periods into the firmware code (the only way to do so I believe) and 2) determine daily energy consumption and daily recording size for multiple combinations of settings (sample rate, sleep duration, recording duration, period length, gain).
I have looked at lifeDisplay.js in the Configuration App code (https://github.com/OpenAcousticDevices/AudioMoth-Configuration-App) to get the mathematics behind the forecasts that the Configuration App gives us:
Daily energy consumption
Daily energy consumption = (totalRecLength * configuration.current / 3600) +[(86400 - totalRecLength) * sleepEnergy / 3600]
totalRecLength equals [(completeRecCount*recLength)+truncatedRecTime] and is computed by the getDailyCounts function, and sleep.energy=0.1 .
Now I can't find configuration.current: where is it initialised and how is it computed?
Daily recording size
Single recording file size = configuration.sampleRate / configuration.sampleRateDivider * 2 * recLength
recLength is the length in minutes of a recording period (parseInt(recordingDurationInput.value, 10)). And again I can't get my head around the configuration bit: configuration.sampleRate and configuration.sampleRateDivider. Where are they initialised, what are their values and how are they computed?
Thanks for the help and above all thanks for the Audiomoth that allows us to do so much more.
Hi Alex,
We're looking forward to trying the new WAV file approach in the field when the firmware is released. It's good to know that the SD card can be pulled out without resetting the recorder configuration.
Many thanks to the team for improving the firmware, adding new functions and keeping us updated, and good luck to Peter with the Ph.D.
Hi Hugo, We can definitely do after sunset to before sunrise as well - we'll figure out some way so that the list of options doesn't explode.
We're hoping to get this out at the end of October - Peter is back on the project full-time from the start of October.
You can currently take the SD card out in the middle of a recording and it will pick up again on the next scheduled recording.
We won't support MP3 as there are some licensing limitations. However, we going to have a volume based compression algorithm in the next firmware release that will avoid writing blocks of the file to the SD card if the volume is below a threshold. The resulting file is still a WAV file and can be played normally, and can be expanded out to the correct length with all the silent periods inserted.
All of this should be in the real firmware release, along with an updated Configuration App, and then we'll use the AudioMoth Labs site for quick variants of firmware. The aim here is to make it easy for users to configure the binary file from the AudioMoth Labs website, rather than have to support multiple versions of the Configuration App for more specialised versions of the firmware.
Hi Alex,
Thanks for the update, that is great news. If I understand well, the user will have the choice between the three options. For our project option 2) would fit our needs, although best if we can record from some specified time after sunset to some specified time before sunrise. This would permit recording periods within the night. Unless the specified time can be negative and interpreted as after sunset or before sunrise (-20 minutes before sunset being 20 minutes after sunset)?
Precision wise, sunrise/sunset times rounded to the nearest minute would be best and would optimise battery life and SD card capacity. However I guess this is project and goals dependent.
I reckon you are making substantial changes to the firmware :
- would you have a broad timeline for the release of this firmware?
- you mentioned the possibility of pulling the SD card and putting it back in with the recording continuing as planned at the next scheduled recording (https://www.openacousticdevices.info/support/sd-card-support/large-cards), will that be included in that firmware?
- the limiting factor is currently the SD card capacity as we can use higher capacity external powerbanks (https://www.openacousticdevices.info/support/device-support/powering-using-external-usb-powerbank), will there be an MP3 encoding option in this firmware?
Also you mentioned the 'AudioMoth Labs' on another post (https://www.openacousticdevices.info/support/configuration-support/programming-to-adjust-for-sset-and-sris-change-each-day), is it still being considered?
There's a nice description from NOAA of how to calculate sunset and sunrise times here - https://www.esrl.noaa.gov/gmd/grad/solcalc/solareqns.PDF
Hi Hugo,
We're probably going to implement the sunrise/sunset tracking code in the next version of the standard firmware. Our current implementation would chose between:
1) One recording period from some specified time before sunrise to some specified time after sunset (recording during the day).
2) One recording period from some specified time before sunset to some specified time after sunrise (recording during the night).
3) Two recording periods with individually specified times before and after both sunrise and sunset (recording around sunrise and sunset).
We would also allow the sunrise / sunset times to be rounded to some specified precision (e.g. 1 minute, 5 minutes, 15 minutes, etc).
You would enter the longitude and latitude of the deployment site when the device was configured.
Would this address you application's needs?
Alex
Hi Peter,
Thanks a lot for the help, I managed to rewrite a routine (from your C code to an R script) forecasting consumptions and file sizes for a given period, sample rate, sleep duration and recording duration.
Your documentation on the microphone settings and how they define the configuration bit also helped : https://github.com/OpenAcousticDevices/AudioMoth-Project/wiki/Microphone-Settings
Hi Hugo,
Great that you're working on extending the code we provided. I'll happily explain a bit about where those values come from.
configuration.current is defined here:
https://github.com/OpenAcousticDevices/AudioMoth-Configuration-App/blob/master/app.js#L39
The configuration which is chosen from this array varies depending on the sample rate (the higher the sample rate the greater the current). The same is true for configuration.sampleRate and configuration.sampleRateDivider.
lifeDisplay.js is given this array then selects the appropriate configuration from it here:
https://github.com/OpenAcousticDevices/AudioMoth-Configuration-App/blob/master/lifeDisplay.js#L120
Peter
The Open Acoustic Devices team