Audio Recording / Logging to SD card --> microSoundRecorder

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
Garth,
there were really 2 shipping attempts: USPS to Italy failed in customs (Tympan returned to US) and UPS to Germany (overall 1 week).
In both cases, custom complained on missing shipping documents. in the USPS case custom is also interface between USPS and Italian postal system, so effectively nobody cared to obtain the necessary documentation and after a month held in custom package returned. Anyhow, international shipping needs special skills (documentation). Strange, Digikey's UPS shipping passes German custom in 5 minutes and Italian custom in a day or so, therefore international shipping must be possible.


Concerning the external triggered acquisition, there is a potential problem.
It is easy when Teensy is running and only snippets are archived, which is similar to what is already implemented: data driven logging.
If you also wanted to save battery power, there are a couple of options
- hibernate as now: this needs restart (could be RTC , /RESET, or other LLWU pins)
- sleep at higher level: needs code to reactivate acquisition

actual hibernate is lowest consumption. Other mode consume more.

also, any shutdown of acquisition inhibits recording before event, and may also need a couple of seconds to switch on acquisition.

So question is: is power consumption critical, is pre-trigger recording important?
 
Hi Walter

Thanks for your kind consideration of this feature.

The top priority for this mode would be - pre-triggred recording and immediate response. Of course power consumption is critical too but secondary to the first 2 considerations in this mode

It is designed to capture the environmental context in which a wildlife picture is taken. For instance we want to know about communities of Mule dear which do not cross the road, which is causing a separation of gene pools. The Mule dear are photographed quite often and I would like to know what the activity on the road is when the dear are captured on wildlife cameras close to the road, so that we might get a fuller picture of the conditions that prevent them crossing the road. We are also likely to use this in Costa Rica looking at some other issues related to context when animals are present in the photographs.

Much obliged to you for your generosity

Kind regards, Garth
 
The top priority for this mode would be - pre-triggred recording and immediate response. Of course power consumption is critical too but secondary to the first 2 considerations in this mode

OK, this can be done, do you have a pin you wanted to add an external trigger, how do you want the trigger (falling/rising edge?)
Note that more than half the memory size (100 kB) should not be allocated for pre-trigger (25 kS for stereo i.e. 0.5 s at 50 kHz)
I recall you wanted also regular noise samples recorded, right?

BTW, I find the Tympan a really nice system for logging.

Garth, if you get it working, maybe you could provide some info on application for the WIKI, (and note on tympan blog (I saw your entry)).
 
Hi Walter

Wonderful - thank you. I am using the environmental sensing boards (not the light at this stage, but possibly later) so am not concerned about the pin used - any free pin would be fine. I guess the voltage increases on the light sensitive resistor rises with the presence of light so it would need to be a rising edge trigger – but I must admit I am not an expert on the electronics

I was thinking this would be analog - I would keep it simple
https://www.sparkfun.com/products/9088

or this
https://www.sparkfun.com/products/8688

But others might have a better suggestion

Yes, in addition to this function I would want to maintain the normal logging function which I currently have set up to record 2, 4 minute files every 10 minutes from 3 AM to midday and midday to midnight.

Thanks, Garth
 
OK,
I will look into it.
One thing I should say, I only modified the code to get it running, I have NOT yet checked if data quality is OK, in particular if sampling rates are OK.
So, if recording sound strange, simply tell me.

BTW, at the moment only the top 16 bit are used. not sure if the codec is better than that.
 
Hi all,

I'm currently working on a project (with @garthpaine) using Teensy 3.6 to build a gunshot detection & location system for an anti-poaching initiative in Costa Rica. I have seen a few other threads regarding systems with similar goals, however because this is in the beginning stage I am using the singular MEMS mic setup for initial "shot detection only" tests. Along with this I am also using the microSoundRecorder code as a starting point, so I felt it more fitting to post here. (Thanks so much @WMXZ for sharing this code as it has helped me learn backwards in regards to what code is causing what outcomes)

My goals for testing are as follows...

1. Monitor amplitude peak vector, subtracting mean background amplitude from a reference frame captured say every 10 minutes (we will do this as it is rainforest and the ambient amplitude will vary greatly during 24 hrs).

2. Upon threshold of ambient amplitude being passed, run 1024 FFT.

3. Use FFT to calculate spectral centroid vector over a period of a ~10 frame buffer (sample rate dependent, hoping 96k will be a possibility.) – we are looking for the amplitude and spectral centroid vectors to have rapid change in opposite directions

4. Calculate the angle or length of the amplitude or loudness vector and the spectral centroid vector

5. If the amplitude vector is sufficiently steep (long) and the spectral centroid vector is also very steep in the opposite direction
ie. If they are greater than a set threshold (ie. Acceleration)

6. Write a text file to the SD card containing an array of the amplitude & SC values in the buffer.

7. Write that buffered bit of audio on the SD card as well so verification of the shot can be made through playback after. This will allow me to take a single system in the field and feed it some test shots from varying distances and locations.

8. Send message to central server using IoT low powered radio indicating listening device number and shot detected – triangulation will be done on a PC which will then send an SMS to security staff


- My question is: Given the audio stream is present – can you suggest how I can insert the amplitude change function, FFT function and associated vector functions in this code?
- I am also very open to any input on how you think the workflow could be improved?

I think the microSoundRecorder is a good base as it already does all the MEM handling and SD file writing, and can be scheduled. I see there is also a thresholding function which could be called perhaps when the vectors are above threshold of rate of change.

Being fairly new to C I am struggling with where exactly to begin this process in the code itself, and any/all input would be very much appreciated. Thank you all so much!

Kyle :)
 
I'm currently working on a project (with @garthpaine) using Teensy 3.6 to build a gunshot detection & location system for an anti-poaching initiative in Costa Rica.

Kyle,
I really like your application.

I should be possible to extend the existing recorder SW to do the processing you wanted to do, or even more.

The items under 2 - 4, while I think I understand what you are meaning, needs more reading from my side. Do have some papers in mind that describe the processing?

Concerning programming (or understanding the code), you always can contact me at walter (at) wmxz.eu. I would be delighted to help your project.
 
OK,
I will look into it.
One thing I should say, I only modified the code to get it running, I have NOT yet checked if data quality is OK, in particular if sampling rates are OK.
So, if recording sound strange, simply tell me.

BTW, at the moment only the top 16 bit are used. not sure if the codec is better than that.

As a follow on,
I'm digging into the AIC3206 manual to adjust sampling and bit's
(Guess, as of now tympan mode works only if sampling is chosen to be 44.1 kHz)
 
Hi Everyone - I mentioned that we had designed a case for the microSoundRecorder that can be 3D printed. The design work was done for me by Shahabedin Sagheb <ssagheb@asu.edu> who looks after such things in our fabrication lab. We have 18 of these cases in operation and they seem to be holding up well.

Source folder: Design files in SolidWorks
Print Folder: STL files ready to be 3D printed (we used Dimension 1200es 3D printer with 0.01 inch layer thickness, using ABS)
here is a .zip file including all the required files including the design View attachment McDowell Project, Enclosures,FabLab_AME.zip

I hope this might be of use to some of you

Cheers, Garth
 
Hi Everyone - I mentioned that we had designed a case for the microSoundRecorder that can be 3D printed. The design work was done for me by Shahabedin Sagheb <ssagheb@asu.edu> who looks after such things in our fabrication lab. We have 18 of these cases in operation and they seem to be holding up well.

Source folder: Design files in SolidWorks
Print Folder: STL files ready to be 3D printed (we used Dimension 1200es 3D printer with 0.01 inch layer thickness, using ABS)
here is a .zip file including all the required files including the design View attachment 14769

I hope this might be of use to some of you

Cheers, Garth
Garth,
mind to add some rendered pictures?
 
@Garth
Tympan code roughly works (listened to recorded wav file)
remaining issues:
- Noise levels are not similar
- an isolated "failed to go to read page" error (page 0 reg 67)
 
(code is under microSoundRecorder_dev)
Walter,
Where does the Teensy 3.6 start running code from after it wakes from sleep? Does it run as if it just started up from total power off? Or is the program counter saved, so it resumes program execution where it left off? In other words, after setWakeupCallandSleep(nsec) is called from setup() or loop(), which subsequently calls gotoSleep(), what is executed next when the Teensy wakes up?


I ask because I noticed you added
Code:
#if ((ACQ == _I2S) || (ACQ == _I2S_QUAD) || (ACQ == _I2S_32) || (ACQ == _I2S_32_MONO) || (ACQ == _I2S_TYMPAN) || (ACQ == _I2S_TDM))
    I2S_startClock();
#endif
after the call from myAPP.cpp to setWakeupCallandSleep(nsec) in your dev branch as part of your Tympan related edits, and it made me wonder how all had worked before this addition. I may be missing something, but where in the code was the I2S clock started before the above portion was added in setup() and loop()?




Also, an update:
I looked into this further, and as long as I have three microphones connected in any fashion, the RXD0 pin 13 LED goes out.
_I2S_QUAD mode recording actually works just fine with three ICS-43434 microphones! (with fix in #91). It turns out my particular hardware setup was to blame. I have each mic connected via a 5 foot long Cat6 (ethernet) cable, with a 100 ohm resistor between BCLK and GND on the mic end to mitigate clock ringing. A 100 ohm resistor was chosen since the characteristic impedance of a Cat6 cable is 100 ohms. Unfortunately, while two mics can be connected like this (Left and Right channels on RXD0) and it works nicely, adding a third mic with 100 ohm resistor (on RXD1) weakens the clock signal too much (checked on oscilloscope) and the mics stop sending audio data. This explains the pin 13 RXD0 LED going out. The twisted pairs of the Cat6 cable reduce interference (I paired GND with each signal line), despite I2S being designed to only work on a PCB trace up to 6 inches long according to the protocol specification. I could get three microphones to work together over Cat6 cables with a 220 ohm resistor on one of the three mics instead, but at the high cost of prominent low frequency digital noise and jitter from the weak clock signal. So I'll just be using two microphones with _I2S_32 mode at 44.1 kHz to have clean audio. (Hopefully these notes help someone else out later!)
 
Walter,
Where does the Teensy 3.6 start running code from after it wakes from sleep? Does it run as if it just started up from total power off? Or is the program counter saved, so it resumes program execution where it left off? In other words, after setWakeupCallandSleep(nsec) is called from setup() or loop(), which subsequently calls gotoSleep(), what is executed next when the Teensy wakes up?

As of now, using VLLS0 for hibernating, asm("wfi") does not return; but Teensy is rebooted (similar to power toggle)
The lines you quote are in preparation to a less deep hibernation, in case I will ever have time, to implement that, but for a flexible hibernation, better to use duff's snooze library.
 
Also, an update:

_I2S_QUAD mode recording actually works just fine with three ICS-43434 microphones! (with fix in #91). It turns out my particular hardware setup was to blame. I have each mic connected via a 5 foot long Cat6 (ethernet) cable, with a 100 ohm resistor between BCLK and GND on the mic end to mitigate clock ringing. A 100 ohm resistor was chosen since the characteristic impedance of a Cat6 cable is 100 ohms. Unfortunately, while two mics can be connected like this (Left and Right channels on RXD0) and it works nicely, adding a third mic with 100 ohm resistor (on RXD1) weakens the clock signal too much (checked on oscilloscope) and the mics stop sending audio data. This explains the pin 13 RXD0 LED going out. The twisted pairs of the Cat6 cable reduce interference (I paired GND with each signal line), despite I2S being designed to only work on a PCB trace up to 6 inches long according to the protocol specification. I could get three microphones to work together over Cat6 cables with a 220 ohm resistor on one of the three mics instead, but at the high cost of prominent low frequency digital noise and jitter from the weak clock signal. So I'll just be using two microphones with _I2S_32 mode at 44.1 kHz to have clean audio. (Hopefully these notes help someone else out later!)

Great, so this is solved.
 
Walter,
Thanks for clearing that up!

I'm curious, what is the extern "C" for in front of setup() and loop() in myAPP.cpp? Are any of the libraries used in this project written in C?
Code:
extern "C" void setup() {...}
extern "C" void loop() {...}
 
In the core ...\hardware\teensy\avr\cores\teensy3\main.cpp you'll see this code.

Code:
extern "C" int main(void)
{

The Core startup and processor init code is 'c'.

That main() is called from ...\hardware\teensy\avr\cores\teensy3\mk20dx128.c:
Code:
	startup_late_hook();
	main();
 
Walter,
Thanks for clearing that up!

I'm curious, what is the extern "C" for in front of setup() and loop() in myAPP.cpp? Are any of the libraries used in this project written in C?
Code:
extern "C" void setup() {...}
extern "C" void loop() {...}

These declarations are necessary, as setup and loop are called from a 'C' language file, and setup and loop are implemented in a C++ file.
Also this is a consequence that I'm not using ino files, where the Arduino pre-compiler handles all this and more.
( As I prefer not to let Arduino interfere with my programming, the ino file is empty and all is done in C/C++ programming)
 
Kyle,

The items under 2 - 4, while I think I understand what you are meaning, needs more reading from my side. Do have some papers in mind that describe the processing?

Walter,
Thanks so much for your response and being so generous!

In regards to items 2 - 4 on that list, it is sort of what Garth and I discussed as the "new" detection methods we have not seen used extensively in other gun detection projects.

With that being said there weren't too many papers I found relating specifically to that technique, however a few I think were the most useful are...

"Evaluation of Gunshot Detection Algorithms" Alfonso Chacón-Rodríguez

"IMPROVING EFFICIENCY AND RELIABILITY OF GUNSHOT DETECTION SYSTEMS" Talal Ahmed

This is a project I found calculating time-of-arrival differences using Teensy, although it doesn't go too much in depth with the spectral detection processing itself :)
MicLoc - Rural Hacker

Lastly and the most important, a very similar system. Section 2.4 of this article goes in to great detail, I'm just reading it now myself!
AudioMoth: Evaluation of a smart open acoustic device for monitoring biodiversity and the environment

_____________________________________________________

We have run a few tests in Sonic Visualizer using gunshot recordings I have collected in the field, (unfortunately just here in the desert, not rainforest yet), and I can show you these to help describe exactly what is happening as well. Let me know if this is helpful at all :)

Below is a graph containing the audio of a very distant, hardly audible gunshot recorded at 96k.

We have two sets of processing defined here, the first is the orange line representing "Loudness." This is extracting the loudness of the signal from its spectrum at a window size of 1024, a window increment of 1024, and using a Hann window shape. We can see a jump in loudness from 0.0 - 0.1 sec, as this is where the shot is.

The second is the purple line, representing the Spectral Centroid of the signal. The parameters are the same - 1024 window size and window increment, and Hann window shape. We see a jump in the opposite direction here as the center of mass of the spectrum drops due to the subsonic gunshot. The drop from Bin 1 to Bin 2 in this graph is about a 1300Hz difference, dropping from ~3000Hz to ~1700Hz once the shot reaches the mic.


SoftestShotAnalysis.jpg

Although the graph shows after the gunshot that these values can be a little unpredictable, it was evident through our tests that (3) it is the correlation between the rapid amplitude rise and spectral centroid drop at the same time from which we can determine what is a shot vs any another loud sound. The point made in (4, 5) is to calculate the angle of those values from bin to bin in the graph to distinguish an acceleration in both parameters.

I'll leave it at that for now, but I just wanted to explain what we have this far!

Once again thanks for your time,
Kyle
 
Last edited:
We have two sets of processing defined here, the first is the orange line representing "Loudness." This is extracting the loudness of the signal from its spectrum at a window size of 1024, a window increment of 1024, and using a Hann window shape. We can see a jump in loudness from 0.0 - 0.1 sec, as this is where the shot is.

The second is the purple line, representing the Spectral Centroid of the signal. The parameters are the same - 1024 window size and window increment, and Hann window shape. We see a jump in the opposite direction here as the center of mass of the spectrum drops due to the subsonic gunshot. The drop from Bin 1 to Bin 2 in this graph is about a 1300Hz difference, dropping from ~3000Hz to ~1700Hz once the shot reaches the mic.

Kyle,
would you mind to send me the file snippets and algorithm (even it is not matlab, python) you used to generate the figures to the e-mail given in the other post?

As this is may be novel algorithm, maybe we keep detail initially off-line.

If you could tell me what type of microphones you plan to use, I can adapt code
Walter
 
Hello! Thank you very much for publishing this, it has helped me a lot. I'm testing the program with a Teensy 3.6 and an Aquarian hydrophone stuck in a glass of water. The AudioSield input is MIC and I use a 2GB SD card.

The software that you had posted modified it to work in the following way:

When you enter each of the following 4 letters by keyboard, four actions occur:

If 'r' is pressed, it starts recording.
If 'q' is pressed, recording stops.
If 'p' is pressed, the file that has been recorded is played.
If 's' is pressed, playback stops.

The modified program works correctly, but it has some imperfection. The recorded sound, when played, sounds slowed, that is, slower. I can solve this by reducing the size of the buffer, instead of 256-512, I put it to 64-128. However, this drastically decreases the quality of the audio file. Could anyone guide me so that the quality and speed of the sound are adequate? I just need to know what methods and parameters to use for audio correction.

I attach an image of the hydrophone and the code I am using.

nueve.jpeg

Code:
// Record sound as raw data to a SD card, and play it back.
//
// Requires the audio shield:
//   http://www.pjrc.com/store/teensy3_audio.html
//
// Three pushbuttons need to be connected:
//   Record Button: pin 0 to GND
//   Stop Button:   pin 1 to GND
//   Play Button:   pin 2 to GND
//
// This example code is in the public domain.

#include <Bounce.h>
#include <Audio.h>
#include <Wire.h>
#include <SPI.h>
#include <SD.h>
#include <SerialFlash.h>

// GUItool: begin automatically generated code
AudioInputI2S            i2s2;           //xy=105,63
AudioAnalyzePeak         peak1;          //xy=278,108
AudioRecordQueue         queue;         //xy=281,63
AudioPlaySdRaw           playRaw1;       //xy=302,157
AudioOutputI2S           i2s1;           //xy=470,120
AudioConnection          patchCord1(i2s2, 0, queue, 0);
AudioConnection          patchCord2(i2s2, 0, peak1, 0);
AudioConnection          patchCord3(playRaw1, 0, i2s1, 0);
AudioConnection          patchCord4(playRaw1, 0, i2s1, 1);
AudioControlSGTL5000     sgtl5000_1;     //xy=265,212
// GUItool: end automatically generated code

// For a stereo recording version, see this forum thread:
// https://forum.pjrc.com/threads/46150?p=158388&viewfull=1#post158388

// A much more advanced sound recording and data logging project:
// https://github.com/WMXZ-EU/microSoundRecorder
// https://github.com/WMXZ-EU/microSoundRecorder/wiki/Hardware-setup
// https://forum.pjrc.com/threads/52175?p=185386&viewfull=1#post185386


// which input on the audio shield will be used?
// const int myInput = AUDIO_INPUT_LINEIN;
const int myInput = AUDIO_INPUT_MIC;
const int buf = 64;


// Use these with the Teensy Audio Shield
#define SDCARD_CS_PIN    10
#define SDCARD_MOSI_PIN  7
#define SDCARD_SCK_PIN   14

// Use these with the Teensy 3.5 & 3.6 SD card
//#define SDCARD_CS_PIN    BUILTIN_SDCARD
//#define SDCARD_MOSI_PIN  11  // not actually used
//#define SDCARD_SCK_PIN   13  // not actually used

// Use these for the SD+Wiz820 or other adaptors
//#define SDCARD_CS_PIN    4
//#define SDCARD_MOSI_PIN  11
//#define SDCARD_SCK_PIN   13


// Remember which mode we're doing
int mode = 0;  // 0=stopped, 1=recording, 2=playing
char c;

// The file where data is recorded
File frec;

void setup() {
  // Configure the pushbutton pins
  pinMode(0, INPUT_PULLUP);
  pinMode(1, INPUT_PULLUP);
  pinMode(2, INPUT_PULLUP);

  // Audio connections require memory, and the record queue
  // uses this memory to buffer incoming audio.
  AudioMemory(60);

  // Enable the audio shield, select input, and enable output
  sgtl5000_1.enable();
  sgtl5000_1.inputSelect(myInput);
  sgtl5000_1.volume(0.25);

  // Initialize the SD card
  SPI.setMOSI(SDCARD_MOSI_PIN);
  SPI.setSCK(SDCARD_SCK_PIN);
  if (!(SD.begin(SDCARD_CS_PIN))) {
    // stop here if no SD card, but print a message
    while (1) {
      Serial.println("Unable to access the SD card");
      delay(500);
    }
  }
}


void loop() {
  c = Serial.read();
  if (mode == 0){
    if (c == 'r') {
      startRecording();
    }
  }
  if (mode == 1) {
    //Serial.println("x");
    continueRecording();
    if (c == 'q') {
      stopRecording();
    }
  }
  if (mode == 0){
    if (c == 'p') {
      startPlaying();
    }
  }
  if (mode == 2) {
    //Serial.println("y");
    continuePlaying();
    if (c == 's') {
      stopPlaying();
    }
  }
  if (myInput == AUDIO_INPUT_MIC) adjustMicLevel();
}


void startRecording() {
  Serial.println("startRecording");
  if (SD.exists("RECORD.RAW")) {
    // The SD library writes new data to the end of the
    // file, so to start a new recording, the old file
    // must be deleted before new data is written.
    SD.remove("RECORD.RAW");
  }
  frec = SD.open("RECORD.RAW", FILE_WRITE);
  if (frec) {
    queue.begin();
    mode = 1;
  }
}

void continueRecording() {
    byte buffer[2*buf];
    // Fetch 2 blocks from the audio library and copy
    // into a 512 byte buffer.  The Arduino SD library
    // is most efficient when full 512 byte sector size
    // writes are used.
    memcpy(buffer, queue.readBuffer(), buf);
    queue.freeBuffer();
    memcpy(buffer+buf, queue.readBuffer(), buf);
    queue.freeBuffer();
    // write all 512 bytes to the SD card
    elapsedMicros usec = 0;
    frec.write(buffer, 2*buf);
    // Uncomment these lines to see how long SD writes
    // are taking.  A pair of audio blocks arrives every
    // 5802 microseconds, so hopefully most of the writes
    // take well under 5802 us.  Some will take more, as
    // the SD library also must write to the FAT tables
    // and the SD card controller manages media erase and
    // wear leveling.  The queue1 object can buffer
    // approximately 301700 us of audio, to allow time
    // for occasional high SD card latency, as long as
    // the average write time is under 5802 us.
    // Serial.print("SD write, us=");
    // Serial.println(usec);
}

void stopRecording() {
  Serial.println("stopRecording");
  queue.end();
  if (mode == 1) {
    while (queue.available() > 0) {
      frec.write((byte*)queue.readBuffer(), 256);
      queue.freeBuffer();
    }
    frec.close();
  }
  mode = 0;
}


void startPlaying() {
  Serial.println("startPlaying");
  playRaw1.play("RECORD.RAW");
  mode = 2;
}

void continuePlaying() {
  if (!playRaw1.isPlaying()) {
    playRaw1.stop();
    mode = 0;
  }
}

void stopPlaying() {
  Serial.println("stopPlaying");
  if (mode == 2) playRaw1.stop();
  mode = 0;
}

void adjustMicLevel() {
  // TODO: read the peak1 object and adjust sgtl5000_1.micGain()
  // if anyone gets this working, please submit a github pull request :-)
  sgtl5000_1.micGain(32);
}
 
Hello! Thank you very much for publishing this, it has helped me a lot. I'm testing the program with a Teensy 3.6 and an Aquarian hydrophone stuck in a glass of water. The AudioSield input is MIC and I use a 2GB SD card.

The software that you had posted modified it to work in the following way:

When you enter each of the following 4 letters by keyboard, four actions occur:

If 'r' is pressed, it starts recording.
If 'q' is pressed, recording stops.
If 'p' is pressed, the file that has been recorded is played.
If 's' is pressed, playback stops.

The modified program works correctly, but it has some imperfection. The recorded sound, when played, sounds slowed, that is, slower. I can solve this by reducing the size of the buffer, instead of 256-512, I put it to 64-128. However, this drastically decreases the quality of the audio file. Could anyone guide me so that the quality and speed of the sound are adequate? I just need to know what methods and parameters to use for audio correction.

It seems you are not using the microSoundRecorder code (subject of this thread).
 
Hi Walter,
Not sure if you are still monitoring this thread but i have a newbie question for you about your microSoundRecorder. I have been thinking of making a field sound recorder for wolf vocalizations ever since I went to a wolf conference and a group had research on captive wolf vocalizations. In these recordings they could count individuals and even determine position of an individual in the pack based on vocalizations (apparently subordinates make different sounds). I would love to make a field recorder for the wild wolves we study in Minnesota, USA. I do a lot of Arduino projects but have never ventured into Teensy. I stumbled upon your program when I discovered that most Arduinos are not up to the task of sound recording. I have read through all your information many times and feel it is up to the challenge or close to. So getting to my actual question I am wondering if a Teensy 3.6 running the microSoundRecorder would be a good option for the following project specifications? And if you could give a short shopping list if it is?
- 4 microphone setup (I2S) - Plan would be to have one microphone in each cardinal direction (N, S, E and W). Program would sample sound from all four directions but only record to SD card from the microphone with the best sound signal. If I could record in the file name the cardinal direction it would allow me to get a rough fix on where the pack is vocalizing from.
- Lithium-ion powered - at least a month of run time - Teensy would sleep all day but be actively listening at night and record on a sound trigger. I am thinking I could add a solar panel with charge controller so it could top off the battery during the day.

Shopping List
- Teensy 3.6 (or would something else work better?)
- 4 I2S microphones (is there directional ones you would suggest or do you like the ICS43434 even though I assume it is omnidirectional? If omnidirectional I can just put some sound insulation behind each.)
- 2 audio boards for Teensy
- Large Li-Ion battery and solar panel with charge controller
- Shielded wire for microphone connections

Thanks for any information you could share.
SCOTT
 
Shopping List
- Teensy 3.6 (or would something else work better?)
- 4 I2S microphones (is there directional ones you would suggest or do you like the ICS43434 even though I assume it is omnidirectional? If omnidirectional I can just put some sound insulation behind each.)
- 2 audio boards for Teensy
- Large Li-Ion battery and solar panel with charge controller
- Shielded wire for microphone connections

Thanks for any information you could share.
SCOTT
If you use I2S microphones, you do not need audioboard, but can connect directly to T3.6.
the I2S mics I know are omni, so, in order to obtain directionality you could get you some plexi parabol screens, if you prefer HW.
I prefer to record all 4 mics and to determine direction by estimating the time delay between microphones
 
Back
Top