I have received two Audiomoths from round 3. Lovely designs and simple configuration. However, after some tests, I am annoyed by two common issues in the recordings. 1. I have quite plenty of destroyed signals of bat calls even with intermediate amplitude levels (usually <30%, low frequency noises included); 2. have gaps in some recordings, usually happened when recordings are destroyed a lot by the low frequency noises (at this case, the amplitude level are primary 70-100%). However, it also happened occasionally with low amplitude levels. I attached screenshots of the example here. [configuration: intermediate gain, 192 or 384k sampling rate, duty cycle: 3s on/12s off or 60s on/300s off, led light on/off] [detector setting-up: either in zip bag or not, height of detector 1-1.5m, weather generally humid, in some cases raining but the bag remind dry inside, temperature 80-90 F] . Many thanks first!
Performing oversampling while the data is in the low 12 bits is operationally easier since it minimizes overflow when adding values. If the data is in the high 12 bits then oversampling will reduce the noise within that range but the low four bits will always be zero and you do not get the benefit if the noise level is low. Adjusting the data to be in the highest bits can therefore be done after the oversampling. It is advantageous to ensure that overloaded signals are hard clipped to the maximum value so that it is always possible to identify any FSD value as having been clipped. If the overflow wraps round it becomes much more confusing and difficult to identify areas of overload other than by observing spectral anomalies.
So, at the moment the firmware preserves the hardware derived precision, no matter what level of software oversampling is specified. This means that since we do not use any hardware oversampling in the current configurations, the precision is always 12 bits. As the sampling rate decreases, the software oversampling gradually reduces the noise in the lower bits of the sample, but is stays at 12 bits overall.
I'm not sure that this is the best strategy so we might update this. It would seem better to just provide as many bits of precision as is available up to a maximum of 16 and then start right shifting to maintain a maximum of 16 bits. This has the disadvantage that the range of the raw sample values changes with sample rate which is what we were trying to avoid in the current strategy.
Another option is to always provide 16 bits by left shifting samples with less precision. This maintains the range but gives samples with no data in the lower bits. I'm not sure which is better.
I‘ll have a look when I’m back in the office. We switched from hardware to software oversampling at one point so maybe this bit of code isn’t working as intended now. Do you know which version of the firmware you have installed?
Interesting, but nevertheless, recording bats at 384ksps I get more harmonic content than I would expect at very modest levels and severe introduction of 2dn and third harmonics (of Soprano Pipistrelles at 55kHz) with severe aliasing introducing 'inverted' copies of the pulses. This occurs at waveform amplitudes of 10% of FSD. If the true data was in the lower 12 bits of the 16-bit word this is exactly what I would expect. If the data is right justified in the word it becomes harder to explain why the waveform is so low in amplitude, although clipping in digitisation is a complex process because the resultant data does not saturate at the maximum digitisation level (as would be the case with analogue clipping) but wraps round to appear as smaller values again (i.e. FSD+5 does not result in a value of FSD but of 5). Oversampling of course does nothing to reduce clipping, but just reduces the noise level improving the signal to noise ratio.
We shift the bits to the left whenever there are fewer than 16 bits of precision, and drop the bits on the right whenever there are more than 16 bits of precision, so as much as possible the amplitude should be the same at all sample rates.
For all the sample rates we actually sample at either 256kHz or 384kHz and we collect 12 bits of data. We then oversample to achieve the lower sample rates. This means at 32kHz and 48kHz we have 15 bits of precision. At 8kHz we have 17 bits of precision on the device and then drop the least significant bit when we write to the 16 bit WAV file.
Also you do have to remember that the AudioMoth is only sampling at 12-bit (at least at 192/384ksps, you get 1 extra bit at 96ksps) but the data is stored as 16-bit so that your 100%scale on the waveform applies to 16-bit data. Clipping and distortion leading to aliasing takes place at 6.25% on that scale - i.e. a reading of 4096 compared to your 100% of 65536. It is best to use the lowest gain setting which is still enough to show the noise level but gives the greatest headroom for the louder signals.
awesome!
Yes, we have an update coming which supports 256kHz sampling and also local time settings. Should be out in a couple of weeks.
Hi Alex, many thanks for the instant response. I'll get faster cards for my next test. Regarding the 2nd problem, we do have species use very high frequency in the study sites (up to 250 kHz), although this is not the case in the example sent. However, in my experiences, we often missed bat sounds with frequency > 120 kHz even using very sensitive microphones. So I am wondering it is possibly that you can add more options of sample rate in the firmware, e.g. 250 kHz for bat calls up to 125 kHz, to allow people recording pitch calls but reduce the oversampling issue? Thanks again :)
Hi Joe,
The SanDisk Ultra won't be fast enough for recording at 192 and 384kHz sample rates. Although the stated transfer rate is sufficient, we only use the 1-bit protocol to so don't reach the full rate, and different cards have different write latency which causes the AudioMoth buffer to overflow. The best card is a SanDisk Extreme (not PLUS or PRO) - see the guide here https://www.openacousticdevices.info/sd-card-guide.
The first recording might be suffering from the SD card not keeping up but it sounds mainly like rain fall directly onto the device which is saturating the microphone due to the large impulses.
The second recording looks good to me. The sampling rate is probably too high for the frequencies that you are interested in. The device always oversamples at 384 kHz and then sums samples together if you request a slower rate (i.e. 192 kHz is achieved by sampling at 384 kHz and adding two samples together to give the value written to the SD card). As there is no anti-alias filter on the front-end so this oversampling has the effect of an anti-alias filter suppressing frequencies higher than half the requested sample rate. It also means that the recording quality increases at lower sampling rates.
I've applied the oversampling routine to the recording you sent reducing the effective sample rate from 384kHz to 128kHz. The random noise is greatly reduced. Using the SanDisk Extreme card would probably also remove the coherent SD card writing noise.
Alex
Alex
The 2nd file is not so ok to me since the bat calls are destroyed, and a lot pseudo-harmonics presents. In my previous experience, this issue is common only when the bats were too close to the mic and the mic cannot handle the loud sounds from the animals since the waves exceed the limits of 16 bits. Once again, many thanks for your kind supports.
Hi Alex, here it is. the package says the speed is 100mb/90mb for write and read
Hi, Have you tested the devices by making recordings of yourself speaking at a normal volume with the devices sitting on a desk in front of you? This should generate clean recordings. The bottom of the two recordings looks fine - there is some low frequency noise but this could be removed with a high-pass filter if necessary. The top recordings looks strange as it is saturating the microphone and there is a very strong 8kHz component. This might be the SD card struggling to keep up with the recording. Can you confirm the exact make and model of the SD cards that you are using (preferably send a photo of the SD card) and can you send me the files for these two examples - alex.rogers@cs.ox.ac.uk. Alex