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 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