Hi,
I recently collected data (bat echolocation focus) from two AMs configured by the same laptop running firmware vs 1.4.4 and software vs 1.3.6. One device recorded continuously (config settings: fs 250kHz, Gain: Medium, Sleep dur: 0s, Rec dur: 10s, no filter, no thr), the other with the trig function activated (config settings: fs 250000 kHz, Gain: Medium, Sleep dur: 0s, Rec dur: 10s, Filter : HP 14.0kHz, Amplitude thr: 1024).
I used the Audiomoth config app to expand the triggered recordings and expected but did not find the two data sets to align in time. I have looked for a systematic delay or any kind of pattern by comparing the overall time stamp of several sets of the same call identified in the two data sets (continuous and padded trig data) but am not able to find anything consistent. I do, however, occasionally see transients in the expanded trig files in between two such matched call sets that I cannot retrace in the continuous data, which is why I am tentatively wondering if there's a bug somewhere. Within each separate file the temporal relationship between calls appears to be consistent, pointing to an issue at start/end of files rather than an error occuring for each padding.
I realize that it isn't possible to use a sleep setting of actual 0 s, and all triggered data recs are really 8 s, but the continuous data files are sometimes 8, sometimes 7 s long. However, if this was the only issue, than the change in delay would be consistent in one direction but that does not appear to be the case. The difference in overall time stamp between matched calls in the two data sets ranges from 170 ms to 1.8 s in the data I have compared so far.
Unfortunately I am also not able to backtrack to where the problem first arises as numerous recordings in the beginning of the period do not have any triggered data that I can match to the continuous files.
I've included a screenshot with waveform and spectrograms on top of 8 consecutive files (green dashed lines marking transition to next file) from the continuous data set and below from the expanded data triggered data files. Data (wav files) are included as well. I've marked 5 call pairs in each data set (#1-5 in the screenshot) but the distinct transients at the end of file 4 (after label 3) are not in the continuous data. The start time stamp for the first of the 8 files in each data set is the same (210442) and the second and second to last file of the continuous data are both 7 instead of 8 s in dur.
Any help on the matter would be greatly appreciated and test data happily contributed.
The accuracy of timestamps and time setting has been improved in the new versions of the Configuration App and the firmware which should resolve all the issues that you observed. The app will typically now set the time to about +/- 4ms accuracy and all timestamps at the start of the files are now precise to this accuracy (plus or minus an amount due to the drift of the individual clocks over time). The updated firmware measures how long the previous file opening took and incorporates that into its scheduling. it waits until the precise second transition to actually start recording, and will go back and correct the timestamp if takes the file longer than expected to open.