Forum Rule: Always post complete source code & details to reproduce any issue!
Page 5 of 5 FirstFirst ... 3 4 5
Results 101 to 120 of 120

Thread: Audio Recording / Logging to SD card --> microSoundRecorder

  1. #101
    Senior Member
    Join Date
    Jul 2014
    Posts
    1,875
    Quote Originally Posted by garthpaine View Post
    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?

  2. #102
    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

  3. #103
    Senior Member
    Join Date
    Jul 2014
    Posts
    1,875
    Quote Originally Posted by garthpaine View Post
    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)).

  4. #104
    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

  5. #105
    Senior Member
    Join Date
    Jul 2014
    Posts
    1,875
    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.

  6. #106
    Junior Member
    Join Date
    Sep 2018
    Posts
    2
    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

  7. #107
    Senior Member
    Join Date
    Jul 2014
    Posts
    1,875
    Quote Originally Posted by kylehoefer View Post

    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.

  8. #108
    Senior Member
    Join Date
    Jul 2014
    Posts
    1,875
    Quote Originally Posted by WMXZ View Post
    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)

  9. #109
    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 McDowell Project, Enclosures,FabLab_AME.zip

    I hope this might be of use to some of you

    Cheers, Garth

  10. #110
    Senior Member
    Join Date
    Jul 2014
    Posts
    1,875
    Quote Originally Posted by garthpaine View Post
    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 McDowell Project, Enclosures,FabLab_AME.zip

    I hope this might be of use to some of you

    Cheers, Garth
    Garth,
    mind to add some rendered pictures?

  11. #111
    Senior Member
    Join Date
    Jul 2014
    Posts
    1,875
    @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)

  12. #112
    Junior Member
    Join Date
    Mar 2018
    Posts
    8
    Quote Originally Posted by WMXZ View Post
    (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:
    Quote Originally Posted by Miles View Post
    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!)

  13. #113
    Senior Member
    Join Date
    Jul 2014
    Posts
    1,875
    Quote Originally Posted by Miles View Post
    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.

  14. #114
    Senior Member
    Join Date
    Jul 2014
    Posts
    1,875
    Quote Originally Posted by Miles View Post
    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.

  15. #115
    Junior Member
    Join Date
    Mar 2018
    Posts
    8
    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() {...}

  16. #116
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    6,829
    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();

  17. #117
    Senior Member
    Join Date
    Jul 2014
    Posts
    1,875
    Quote Originally Posted by Miles View Post
    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)

  18. #118
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    18,300
    I've added links to Walter's github repository and this thread in the Audio library's Recorder example.

    https://github.com/PaulStoffregen/Au...36b564445f3434

  19. #119
    Junior Member
    Join Date
    Sep 2018
    Posts
    2
    Quote Originally Posted by WMXZ View Post
    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.


    Click image for larger version. 

Name:	SoftestShotAnalysis.jpg 
Views:	3 
Size:	72.9 KB 
ID:	14814

    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 by kylehoefer; 09-25-2018 at 06:11 AM. Reason: Added Source

  20. #120
    Senior Member
    Join Date
    Jul 2014
    Posts
    1,875
    Quote Originally Posted by kylehoefer View Post
    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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •