Audio Recording / Logging to SD card --> microSoundRecorder

[DD4WH]

Hi Garth,

Walter has already answered your questions, he was faster than me .

One additional thing:

* I do not recommend the use of USB power banks any more
* the #define SLEEP_SHORT with the according ShortSleepDuration works for some types of power banks, but some power banks do not wake up, because the current from the Teensy is still too low
* I purchased an ANKER PowerCore 13000 about a year ago, it works very well and wakes up, BUT then I purchased exactly the same model again a few weeks ago, and it looks exactly the same from the outside, but that does not work at all and is not waking up . . . seems they radically changed the battery management system

So, I now soldered battery holders to all my prototypes (3 x AA batteries = 3.6 to 4.5 Volts depending on your battery type, connected to Vin and GND) and I do not use power banks for recording any more. This has two additional advantages:

* much more reliable
* current draw is drastically reduced, because it seems that a significant proportion of the current drawn was consumed by the power bank alone, and not the Teensy
* AA batteries can be purchased everywhere worldwide, even in remote areas in the tropics and can be taken with you and help a lot if you do not have the means to recharge your power bank
* for longer periods, you could even use C or D battery types to allow for several weeks of unattended recording

I also put this information into the WIKI:

https://github.com/WMXZ-EU/microSou...es,-current-consumption-and-battery-life-time

Frank

 

[DD4WH]

Filtering of supply voltage for microphones

It is vitally important to filter the supply voltage for the mics you are attaching to the microSoundRecorder.

Test with digital mic ICS43434 (which has a maximum achievable SNR of 65dB):

* I took the supply voltage directly from the Teensy 3.3Volt pin. --> leads to low frequency noise in the range 15 to 250Hz. Measured SNR of my recording is about 50dB.

* I took the supply voltage from the Teensy 3.3Volt pin, a 100µF electrolyt cap to AGND and a series resistor of 1000 Ohms. This RC filter has a lowpass cutoff for the supply voltage of 1.6Hz, so suppression is 20dB at 16Hz and 40dB at 160 Hz etc. The measured SNR of my recording with the RC-filtered supply voltage: 65dB ! Goal is thus achieved: I can record everything the mic is able to pick up and that means, the noise generated by the Teensy is lower than the internal mic noise.

So, with a very easy supply voltage RC filter, you can achieve a massive increase in SNR with your mic.

Keep an eye on the max current you need: with 3.3Volts and 1000 Ohm resistor, you achieve a maximum current of 3.3mA, which is more than enough for that mic (current of 0.5mA max), but you will not be able to supply a preamp with that current ;-).

Have fun with the microSoundRecorder,

Frank DD4WH

 

[garthpaine]

Thank you for this information. We have just built 12 units to deploy next week and I did not do this, so I will look for the noise in those recordings. When we get a chance we will retrofit the units and so I ask if you could clarify the circuit. As I understand it the capacitor is connected between the +3.3 V pin and ground and then the resistor is soldered to the leg of the capacitor that was connected to 3.3 V and is then connected to the supply cable for voltage to the microphone. Is that correct?

 

[garthpaine]

Dear all

Thank you so much for the wonderful software and all of your support. We have put together 12 mono units which we will deploy in the field next week. We will connect them to 6AH LiPo batteries, which in the future we will add a small solar panel and charging circuit to. I am currently testing one system connected to a 14Ah Bytech power bank (BY-PB-14-K00-BK) which has been working fine and turning on and off with the sleep function. I started this test running last week and it is still running with the battery indicator showing perhaps half the batter life used. I will report on the total runtime when the battery is exhausted.

On another note I have also had success using 128 GB cards and so we will equip all of the recorders this way. These recorders will run 24 hours recording 2, 2 minute files and then sleeping for 60 seconds throughout the 24 hours.
ACQ_Parameters_s acqParameters = { 240, 120, 300, 0, 12, 12, 24, 0, "Mc12"};

The field recording system will be Velcro to the side of an wildlife camera and contained inside the steel security case with a hole for the microphone so that they are tamperproof. This project is looking at how road noise propagates into a large nature reserve and also at play noise across the reserve. We plan to deploy another 12 recorders over the course of the next year to bring the total to 24. These last 12 recorders will have custom-designed cases so once we have designed 3D printable cases for them I will share the design.

I have one additional feature request. It would be useful if I could put a light-sensitive resistor over the flash of the wildlife camera and trigger a recording that would capture both the buffered audio and then perhaps 3 to 5 minutes post trigger (this could be in the config) to a file with a separate title – for instance with trigger or wildlife in the name. I would imagine this would not be too difficult to do if we were to use analog pins the voltage from the light-sensitive resistor would spike when the flash goes off. I guess it would need a separate function though which could interrupt the scheduled recording, closing the file and produce a new file associated with the camera trigger. The system would then go back to the scheduled recording. I would welcome thoughts about this.

Once again thank you all for your support, Cheers, Garth

 

[DD4WH]

Hi Garth,

looks good!

For your project goal "road noise", it would be vitally important to have the power supply filtering:
* road noise will mainly be low frequency noise
* without the power supply filtering, the recordings have considerably low frequency noise in the range 20Hz to 400Hz, so this noise could override/adds to your recorded road noise
* so my suggestion would be to filter the supply voltage from the Teensy

the capacitor is connected between the +3.3 V pin and ground and then the resistor is soldered to the leg of the capacitor that was connected to 3.3 V and is then connected to the supply cable for voltage to the microphone. Is that correct?

Exactly!

Good luck and good results with your project!

Frank DD4WH

 

[WMXZ]

I have one additional feature request. It would be useful if I could put a light-sensitive resistor over the flash of the wildlife camera and trigger a recording that would capture both the buffered audio and then perhaps 3 to 5 minutes post trigger (this could be in the config) to a file with a separate title – for instance with trigger or wildlife in the name. I would imagine this would not be too difficult to do if we were to use analog pins the voltage from the light-sensitive resistor would spike when the flash goes off. I guess it would need a separate function though which could interrupt the scheduled recording, closing the file and produce a new file associated with the camera trigger. The system would then go back to the scheduled recording. I would welcome thoughts about this.

Garth,
great project and I hope you tell us how it went.

concerning the request, I try to understand the functionality:
the wildlife camera takes a picture using a flash, a light-sensitive resistor intercepts flash generates a signal, that could be used to used to extend recording, right?
implementation should be not a big deal.

BTW: my tympan is still on hold in customs (9 days, now)

 

[WMXZ]

implementation should be not a big deal.

Only difficult is, when camera flash occurs during hibernate.
for the time being, the hibernate mode switches all off and only restarts on RTC alarm.
If one does not sleep as deep as hibernate, maybe system could be woken up by a compare pin.
This sleep mode will not save as much energy than complete hibernate, but maybe sufficient

 

[garthpaine]

Thanks for looking at this - sorry for the delay in response...

Yes camera flash would generate signal through LSR - this voltage would be used to trigger a special recording - preferably with a different name to the scheduled recording - ie "trigger_date_time" or "Camera_Date_time"... something like that - ie, the prefix would change to indicate it was a camera triggered recording.

So this would need to interrupt a scheduled recording if underway and then capture the buffers + 5min or so into one file.
The recorder would return to scheduled record on next schedule

re hibernate - I guess it would be dependent on how much power difference there was - currently I am only hibernating for one minute out of every 5.

Thanks as always for taking time to consider this.

ps. In am happy to send you my Tympan of that would help although there is no hurry at the moment

Cheers, Garth

 

[DD4WH]

Here is a version of the microSoundRecorder combining audio logging and environmental logging to SD card.

Features:

* mono digital mic ICS43434 (65dB SNR !)
* temperature logging with BME280
* air pressure logging with BME280
* humidity logging with BME280
* light intensity logging with BH1750

It works with the original version of Walters code from his github.

Left under Teensy: backup Lithium battery CR1220 for real time clock
centre: electrolytic cap 100µF and mic breakout board with ICS43434 digital mic
upper right: BH1750 light sensor breakout board
lower right: BME280 breakout board with temperature, pressure, humidity sensor on one board

Connections of the BME280 and BH1750 to the Teensy can be found here (and also details on the specific boards used):

https://github.com/WMXZ-EU/microSou...ging-[temperature,-humidity,-pressure,-light]

All the best,

Frank DD4WH

 

[JBeale]

I am curious how that mic performs in outdoor 24/7 recording situations. I have previously done that kind of ambient recording using a sensitive electret mic claiming 80 dB-A SNR http://www.puiaudio.com/pdf/AOM-5024L-HD-R.pdf but I sealed it into a tube with dessicant and a finger-cot diaphragm to even out the humidity level to a long-term average. Otherwise you may get failure due to humidity and condensation at night. However, the use of a membrane caused the frequency response to suffer.

 

[DD4WH]

It is meant to be used inside a plastic bag which acts as an outdoor case ;-).

You are probably right that it would be wise to put something inside the bag to soak up humidity.

Did you measure how frequency response suffered? I am interested in bird, frog, grasshopper and cricket audio, so I am not sure whether a thin plastic bag really does make a difference !?

 

[garthpaine]

This group has been such a huge help and offered wonderful code and advice - so I thought I would share some images of the 14 we have in the field at the moment - we built in the capacitor and resistor into the signal path in a way that makes them robust I hope - under heat shrink, and the board is covered in heat shrink then both ends have another layer over the various circuitry so they are a bit weather proofed - we are designing and building cases which should simplify things in the coming month - some very thin double sided tape is attached to the camera housing where there is a Hoel and the microphone fitted with a wind sock - the tape keeps it in place over the hole in the case and stops water and dust coming directly in there. These are all retrofitted to wildlife cameras in the field so we use that case as added protection and against vandalism. We have some BME280 boards and hope to test that out in the coming weeks. They are running on 6Ah LiPo batteries - a future development is to add a solar circuit to keep the batteries alive longer

 

[JBeale]

Ah, ok the plastic bag serves to prevent direct exposure. In my case I did not test before/after on the same element, but looking at the spectrogram output the higher frequencies were definitely attenuated in the signal from the mic after the final install, which I suspect had to do with some sound absorption from the latex membrane I used, plus the windscreen over that. Just something to be aware of.

 

[garthpaine]

Hi everyone

I just noticed in one of the pictures that is uploaded on github, that Kaleidoscope pro is being used for analysis. I'm also looking to use it as we have hundreds of hours of recordings and are thinking about trying to automate some of the identification and tagging process. When looking at their video I noticed that in Kaleidoscope pro 5, they use a metadata structure called GUANO metadata format, and I wondered how hard it would be to add metadata to the header of the recording file on the field recorder project? I was thinking for instance that I know the exact GPS location of each recorder, the name of the preserve or national Park the recorder is in, the type of microphone, the type of battery and of course all of the technical details such as sample rate, mono or stereo, bit depth and microphone type, time and date. I was wondering if these could be added in the config file and then written into the header of each audio file as metadata in the GUANO format.

of course I have no idea how much work this is or whether it is of interest to anybody else – I just wanted to share that I thought this would be very useful addition to analysis workflows

 

[DD4WH]

Hi Garth,

probably you mean my uploaded photo that I produced with the free version of Kaleidoscope.

I have not used the Pro version (which is quite expensive!), so I cannot comment on that from my own experience.

Kaleidoscope (free version) worked perfectly for me in discriminating recordings containing bat calls from those that do not contain bat calls. That is superb and saves a lot of time! Also you can very quickly jump between spectrograms of the different recordings. This is all possible with the free version.

Automatic ID of bat species (does Kaleidoscope Pro contain birds??? I did not notice that . . .) is only possible with the Pro version. I read a lot of reviews and a lot of scientific papers on comparing automatic ID of bat species with different software products. To be honest, however, Kaleidoscope was not always the top scorer in its ID capabilities . . .

Try Google Scholar with a quick search "automatic ID bat species".

Very good results can be achieved with the open source programs BatClassify and Tadarida (by Yves Bas), however only with clean recordings with high SNR.

The best results I personally have seen in automatic ID of bat species come from the closed source bcAdmin in combination with the open source batIdent in combination with the Batcorder hardware by Ecoobs, but that is surely the high end solution (in both: ID results AND price ;-))

If you are interested in birds or identifying your own sounds, you may also consider the statistical open source software R with the package monitoR. That is a really cool solution, if you dare to learn R.

Also have a look at the links HERE in our WIKI:

https://github.com/WMXZ-EU/microSoundRecorder/wiki/(Bio)Acoustic-resources

All the best,

Frank DD4WH

 

[Miles]

Teensy 3.6 with THREE ICS-43434 digital microphones

At the moment it has been tested in the following configurations:

• Teensy 3.6. & two ICS43434 digital microphones (STEREO)
• Teensy 3.6. & one ICS43434 digital microphone (MONO)

Other configurations (untested) include:
[...]

• Audio board I2S Quad input

Hi Walter (@WMXZ),

Thank you so much for this great project! I was able to successfully record .wav files using two ICS-43434 microphones with a Teensy 3.6 and it sounds excellent.

Now, I was hoping to use this to record from three ICS-43434 microphones with Teensy 3.6 (no audio board): two microphones in stereo on RX pin 13 and one in mono on RX pin 38 (left channel). I tried turning on _I2S_QUAD in config.h (line 49) from a freshly downloaded copy of the project, but it didn't compile.

#define ACQ   _I2S_QUAD  // selected acquisition interface  //<<<======>>>

The errors led me to this section of the definitions towards the top of myAPP.cpp line 170:

/*-------------------------- (quad channel) -----------------------------*/
#elif ACQ == _I2S_QUAD      // not yet modified for event detections and delays
  #define NCH 4
  
  #include "input_i2s_quad.h"
  AudioInputI2SQuad     acq;
  
  #define MQ (M_QUEU/NCH)
  #include "m_queue.h"
  mRecordQueue<MQ> *queue = new mRecordQueue<MQ> [NCH];

  AudioConnection     patchCord1(acq,0, queue[0],0);
  AudioConnection     patchCord2(acq,1, queue[1],0);
  AudioConnection     patchCord3(acq,2, queue[2],0);
  AudioConnection     patchCord4(acq,3, queue[3],0);

I noticed that the similar section for the (working) I2S_32 stereo had a lowercase mq definition and the queue definition was different, so changing the middle portion of the above to

  #define mq (M_QUEU/NCH) // <-- CHANGED
  #include "m_queue.h"
  mRecordQueue<mq> queue[NCH]; // <-- CHANGED

allowed it to compile. Hopefully this is all that is needed to be changed?


The main issue I'm having is when I connect a third microphone using pin 38 for RX/microphone_serial_data_out (after everything working with two microphones on RX pin 13), the Teensy's LED (i.e. pin 13: I2S RX) goes out, and comes back once I remove the third microphone. It doesn't matter which microphone, since switching out a previously working one to be the third mic on pin 38 does not work. The moment I disconnect the mic on RX pin 38, everything works nicely with the remaining two mics on RX pin 13.

What could I try to make this work with more than two I2S microphones?

Thank you,
Miles

 

[Miles]

Teensy 3.6 with THREE ICS-43434 digital microphones: Further Investigation

The main issue I'm having is when I connect a third microphone using pin 38 for RX/microphone_serial_data_out (after everything working with two microphones on RX pin 13), the Teensy's LED (i.e. pin 13: I2S RX) goes out, and comes back once I remove the third microphone. It doesn't matter which microphone, since switching out a previously working one to be the third mic on pin 38 does not work. The moment I disconnect the mic on RX pin 38, everything works nicely with the remaining two mics on RX pin 13.

I looked into this further, and as long as I have three microphones connected in any fashion, the RXD0 pin 13 LED goes out. I have two left-channel and one right channel ICS-43434 microphones. The RXD0 light goes out, as though no audio data is being received by the Teensy in both of the two possible combinations:

• One Left-channel and one Right-channel mic into RXD0 (pin 13), and one Left-channel mic into RXD1 (pin 38)
• Two Left-channel mics into RXD0 (pin 13) and one Right-channel mic into RXD1 (pin 38) --[Yes, this would sound terrible with mixing the Left-channels]

And indeed, no audio is recorded when all three mics are connected. As soon as I disconnect ANY ONE mic in either combination, the RXD0 (pin 13) LED comes on and I get audio in the respective channels.

This behavior of the RXD0 (pin 13) LED also holds true when using a simple sketch that just initializes things without recording:

#include <Audio.h>

AudioInputI2SQuad        i2s_quad1;

void setup(){}
void loop(){}

I also see the same recording behavior when using the USB output into Audacity with the following sketch:

#include <Audio.h>

AudioInputI2SQuad        i2s_quad1;
AudioOutputUSB           usb1;
AudioConnection          patchCord1(i2s_quad1, 0, usb1, 0);    // Overlapping Left-channel if patchCord3 is also connected
AudioConnection          patchCord2(i2s_quad1, 1, usb1, 1);
AudioConnection          patchCord3(i2s_quad1, 2, usb1, 0);    // Overlapping Left-channel if patchCord1 is also connected
 // AudioConnection          patchCord4(i2s_quad1, 3, usb1, 1);

void setup()
{
    AudioMemory(512);
}

void loop(){}

With both connection setups, I get no signal at all until I disconnect the Left-channel mic on RXD0 (pin 13). Even with two Left-channel mics mixing either at the I2S level or the USB output level (when the Right-channel mic is disconnected), I still get audio, it's just bad and "crunchy" sounding.

Another interesting thing I noticed: immediately after I connect power to the Teensy, the RXD0 (pin 13) LED comes on for half a second with the above sketch when all three mics are plugged in, and then shuts off. It's as though something is detecting all three mics and disabling some part of I2S.

I really hope there is some way I can record with three I2S microphones at once. Even one after the next would be fine too.

Miles

 

[WMXZ]

I noticed that the similar section for the (working) I2S_32 stereo had a lowercase mq definition and the queue definition was different, so changing the middle portion of the above to

  #define mq (M_QUEU/NCH) // <-- CHANGED
  #include "m_queue.h"
  mRecordQueue<mq> queue[NCH]; // <-- CHANGED

allowed it to compile. Hopefully this is all that is needed to be changed?

this was a left over, and minor case should be correct (there is a template definition with MQ)

 

[WMXZ]

I looked into this further, and as long as I have three microphones connected in any fashion, the RXD0 pin 13 LED goes out.

this may be related with the fact that the I2S_Quad is still 16 bit only. but the microphone is 32 bit.

BTW, there are only 2 or 4 channels possible, obviously you can play with AudioConnection to select the channels you wand, but as you know channels are interlaced
e.g. (L1,L2,R1,R2)

Concerning 4 channels 32 bit, I can only look into the issue in about 3 weeks time, when I have access to 4 Micros.

If you wanted to use more than 4 microphones you could use TDM protocol (may need special microphones)

 

[Miles]

BTW, there are only 2 or 4 channels possible, obviously you can play with AudioConnection to select the channels you want, but as you know channels are interlaced e.g. (L1,L2,R1,R2)

How might I go about recording on RXD0 (pin 13) in stereo and then switching to record on RXD1 (pin 38) in stereo? Is it possible to set AudioConnection to select which RXD pin to use?

this may be related with the fact that the I2S_Quad is still 16 bit only. but the microphone is 32 bit.

Was the 16-bit I2S_QUAD mode tested with other microphones? Also, does that relate to the ICS-43434 datasheet calling them 24-bits: what about the extra 8 bits?

Concerning 4 channels 32 bit, I can only look into the issue in about 3 weeks time, when I have access to 4 Micros.

I would rather use 4 channels 16 bit, especially if it reduces file size.

Thanks,
Miles

 

[WMXZ]

As far as I understand the I2SQuad update function correctly

AudioConnection     patchCord1(acq,0, queue[0],0);
  AudioConnection     patchCord3(acq,2, queue[1],0);

access only RXD0
and

 AudioConnection     patchCord2(acq,1, queue[0],0);
  AudioConnection     patchCord4(acq,3, queue[1],0);

access RXD1
but experimenting is better as believing

 

[Miles]

I'll give it a try, thanks.

Is there a way to use I2S 16 bit or I2S_32 (or even I2S_MONO) to record from RXD1? Or can RXD1 only be used by I2SQUAD?

 

[WMXZ]

you can use the RXD1 instead of RXD0 by changing the code in I2S_32.h, about line 79 and 81

 

[WMXZ]

ps. In am happy to send you my Tympan of that would help although there is no hurry at the moment

Cheers, Garth

Garth, got today my own Tympan (finally)
could update the microSoundRecorder to work on Tympan.
Tympan code is not optimized (there are a lot of delays to setup codec, which could be improved)

Anyhow, it is working now and it gives you something to play (code is under microSoundRecorder_dev)

Walter

 

[garthpaine]

Hi Walter

I can't believe it got stuck in customs so long - amazing.... also thanks for investing in one - I would have sent you mine, but as you can see it is a neat package and a good quality I/O - I am actually in residence at ZKM in Karlsruhe for the next couple of months and do have mine with me so will test it out - thanks so much.

I wonder when you have a chance would it be possible to add the trigger function so I can add a light sensitive resistor to the flash of a wildlife camera and extend recording if going and or start recording if not? I am hoping to use this feature in a project synchronized with wildlife cameras in the new year.

Cheers, Garth