Hello, for the purpose of my study I need to have the AudioMoths start at a specific date a couple of days after I place them. I understand that this will be implemented in a future update, but unfortunately I do not have the time to wait for that one. I'm therefore trying to hardcode the starting date into the firmware. I'm currently trying to make it so that when the default switch is triggered it will wait for the set date and then start recording. However, it just starts recording normally. I suspect it has something to do with the configured start date of the recorder (1970) but I'm not sure. If someone would point out where my code is going wrong I would greatly appreciate it!
PS: when I try to flash the firmware it always crashes once, then I have to restart it in boot mode, after which it does work. Is there a fix for this?
Here is my piece of code:
if (switchPosition != *previousSwitchPosition) {
if (switchPosition == AM_SWITCH_DEFAULT) {
time_t current_time;
struct tm * timeinfo;
/* These are the values of my planned recording time */
int target_year = 2019, target_month = 12, target_day = 12;
int target_hour = 14, target_minute = 50, target_second = 0;
/* Get the current time */
time ( ¤t_time );
timeinfo = localtime(¤t_time);
timeinfo->tm_year = target_year;
timeinfo->tm_mon = target_month;
timeinfo->tm_mday = target_day;
timeinfo->tm_hour = target_hour;
timeinfo->tm_min = target_minute;
timeinfo->tm_sec = target_second;
/*This converts it to something that difftime can work with */
time_t scheduled_time = mktime ( timeinfo );
*timeOfNextRecording = current_time + difftime(scheduled_time, current_time );
*durationOfNextRecording = 60;
} else {
/* Determine starting time and duration of next recording */
scheduleRecording(currentTime, timeOfNextRecording, durationOfNextRecording);
}
}
Kind regards,
Yannick
top of page
To test this feature, visit your live site.
Hardcode starting date
Hardcode starting date
17 comments
Like
17 Comments
bottom of page
Great. Thanks for letting us know.
Yes, I was just wondering if recording for 5 mins every 30 minutes every day would be significantly different in terms of the end application from recording for 10 minutes every 30 minutes every other day? Both would half the data requirements and the first one could be done immediately in the configuration app, but you may have another requirement?
On the configuration app?
I'm already using the sleeping duration to define periods of 10 min recording every 30 min between 10 pm and 5 am. I'm not recording during the whole night.
So the sleeping duration is 20 min between every recording period, but I don't think I can use it to define a 40-ish hour sleeping duration between two nights also.
Could you not just reduce the duty cycle by sleeping for longer between recordings?
Yeah, I think it will work this way. The objective is only to save space on the SD cards I have, by recording less between each card switch.
The easiest quick change would be to make it only record on either even or odd days of the year. Would that be useful?
Are you helping with custom code, @Alex Rogers ? I'm trying to have my AM recording only every two night, instead of every night, so I'm looking for modifiying the code but I don't really know how to do this.
Rest of the parameters should be doable with the config app.
We hope to have this out in a couple of months. However, it is very easy for us to produce a custom version of the firmware with all your settings incorporated. You can then put those on the devices and just set the time on each AudioMoth when you deploy with the Time-App. You don't need a modified configuration app in this case.
Hey everyone,
I have been waiting for this update to the configuration app as well. We have about 250 AudioMoths that we will be deploying at more than 120 locations across roughly 10,000km2 this spring, and having the ability to program them to all turn on on the same day would make subsequent data analysis exponentially cleaner. It generally takes us well over a month to reach every site, and by then the batteries on the first AudioMoths deployed are dead (running 8 hrs/day = mean of 31.7 days). If I can sync them all up, I won't have to model the temporal variation between sites, and additionally I could deploy 2 AudioMoths per site, with one scheduled to begin data collection as the first one died, effectively resulting in a continuous 2 month window of data collection.
While I am not super familiar with the programming language or code used to build the configuration app, I can learn it and run the code that Alex and his team have provided here and on GitHub if necessary (Which has been extremely helpful and generous by the way). I just wanted to check and see if I should go that route, or if there may be an update coming out soon that will will include this feature.
Thank you for all you do!
Trent
I got it working, thank you very much! As a follow-up question, do you perhaps know what the device's battery consumption rate is during sleep mode?
Yannick
Thank you for your response. I have done as you said but still the LEDs both flash when I set the switch to custom. The SD card is inserted and the time set with the application. Do I leave the rest of the scheduleRecording unaltered? And do I have to change anything in configSettings? My code:
Yannick
If you add the following code -
- beneath the check for no activeStartStopPeriods in the scheduleRecording function you'll be able to use your AudioMoth as normal in CUSTOM mode - setting all the settings - but it won't make any recordings before 14/12/2019 00:00.
You can add a check for an date beyond which you want to stop making recordings and set -
*timeOfNextRecording = UINT32_MAX;
- as per the case where no active recording periods are set.
Note also that the C time libraries works in years from 1900 rather than from 1970. The calendar year is 1900 + time->tm_year.
The easiest place to add this code is inside the -
scheduleRecording(uint32_t currentTime, uint32_t *timeOfNextRecording, uint32_t *durationOfNextRecording)
- function. If set 'timeToStartRecording' to the UNIX time at 00:00 on the day that you want to start recording, you can then either use the existing code to calculate the time if the current time is greater than timeToStartRecording, or return timeToStartRecording + SECONDS_IN_MINUTE * period[0].startMinute to tell AudioMoth that the next recording is the first recording period on the day of timeToStartRecording.