Forum Rule: Always post complete source code & details to reproduce any issue!
Page 3 of 5 FirstFirst 1 2 3 4 5 LastLast
Results 51 to 75 of 122

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

  1. #51
    Senior Member
    Join Date
    Jul 2014
    Posts
    1,912
    Quote Originally Posted by dreggory View Post
    I tried touching each mic to see what order they are in, and it looks like there is a problem of mixed tracks. I recorded myself saying the mic number, before touching each mic in order ("mic 1" *touch 1*, "mic 2" *touch 2*, "mic 3" *touch 3*, "mic 4" *touch 4*, "mic 5" *touch 5*).
    Here is the recorded audio:
    https://drive.google.com/open?id=1fq...pwomRa5ce7YrEK
    Will look into this over the weekend

  2. #52
    Senior Member
    Join Date
    Jul 2014
    Posts
    1,912
    @dreggory:
    Agree, the data look weird,
    did you start touching the mics when file started (i.e. first signal mic 1) or did you repeat 1 - 5, 1-5 and selected a file.
    As you say 'clean sequence', did you record with microSoundRecorder, or with Perdo's SW?
    Not clear how obvious cross-talk can happen at the digital side.
    I ordered me some ICS5200 boards, maybe with HW at hand debugging will be easier
    I saw the picture in other thread, did you improve layout?
    Last edited by WMXZ; 07-08-2018 at 08:28 AM.

  3. #53
    Senior Member
    Join Date
    Jul 2014
    Posts
    1,912
    Quote Originally Posted by WMXZ View Post
    Not clear how obvious cross-talk can happen at the digital side.
    I may have found a way to digitally multiplexing the data!
    OK, removed this source of error.
    @dreggory: could you try latest 'master' distribution on GitHub?

  4. #54
    Member
    Join Date
    Mar 2017
    Location
    Utah
    Posts
    55
    In the file called clean sequence, I didn't talk, I just swiped a card over each of the 5 mics (only once for each mic) in order. I named the file as such because it was the most obvious example when looking at the data. I will try the new code today.

  5. #55
    Hi all - I just wanted to check with you all about SD card size - I ran some tests with 32GB, 64GB and 128GB cards - the 32GB was the only card that produced files - I am assuming therefore that the larger cards are not readable by the Teensy? I have formatted them all in the terminal using the same command so the formats should be identical - I would appreciate advice as larger cards would be very welcome safeguard for longer periods of recordin.

  6. #56
    Member
    Join Date
    Mar 2017
    Location
    Utah
    Posts
    55
    I may have found a way to digitally multiplexing the data!
    OK, removed this source of error.
    @dreggory: could you try latest 'master' distribution on GitHub?
    this is what I recorded with the code in the master branch:
    https://drive.google.com/open?id=18D...jhOI-FsVkmJnCK
    but I wasn't able to get anything with "Import Audio" or multiple tries of "Import Raw" using different settings in Audacity.

    As an aside, I was wondering which 16 of the 24 bit values you are keeping from each mic. most significant, least significant or somewhere in between? my concern is how will decimal values like 200,000 (typical peak of a loud sound) be represented when most of the audio values tend to be around 25000 or so for talking, and 100's to 1000's for room noise. I don't think I mind really, but I just want to know what I'm loosing by reducing the values to 16 bit. To help everyone visualize this problem, here is a plot of me clapping my hands next to mic 2:

    Click image for larger version. 

Name:	Clap audio snippet.png 
Views:	13 
Size:	23.4 KB 
ID:	14155
    It would be sad to lose some of that small audio signal like room noise if the least significant bytes are lost. Also weird values would arise from discarding the most significant values (i.e. 8 bit 1011011 representing 155, if one significant bit were lost it would become 0011011 representing 27 which could result in nonsense waveforms, not to mention that the sign bit would be pushed out) so I'm curious to know what I'll be recording.

  7. #57
    Senior Member
    Join Date
    Jul 2014
    Posts
    1,912
    Quote Originally Posted by dreggory View Post
    this is what I recorded with the code in the master branch:
    https://drive.google.com/open?id=18D...jhOI-FsVkmJnCK
    but I wasn't able to get anything with "Import Audio" or multiple tries of "Import Raw" using different settings in Audacity.
    Maybe by merging the "_dev" branch to "master" (resolving conflicts) I screwed something up. Will check tonight
    (for practical reasons, I could not work from my own computer in the last month, so some inconsistencies were generated, that I have to resolve)
    As an aside, I was wondering which 16 of the 24 bit values you are keeping from each mic. most significant, least significant or somewhere in between? my concern is how will decimal values like 200,000 (typical peak of a loud sound) be represented when most of the audio values tend to be around 25000 or so for talking, and 100's to 1000's for room noise. I don't think I mind really, but I just want to know what I'm loosing by reducing the values to 16 bit. To help everyone visualize this problem, here is a plot of me clapping my hands next to mic 2:

    It would be sad to lose some of that small audio signal like room noise if the least significant bytes are lost. Also weird values would arise from discarding the most significant values (i.e. 8 bit 1011011 representing 155, if one significant bit were lost it would become 0011011 representing 27 which could result in nonsense waveforms, not to mention that the sign bit would be pushed out) so I'm curious to know what I'll be recording.
    There will be a parameter in the config file that allows individual settings of a digital gain, for all 32 bit I2S modes

    At the moment all data are shifted by 12 bit to the right and then the lower 16 bit are kept.
    Idea is to adjust shift so that background noise is just visible in power spectrum
    the 16 bit in the final data gives you then 96 dB dynamic range, this is good for most applications.

  8. #58
    Senior Member
    Join Date
    Jul 2014
    Posts
    1,912
    Quote Originally Posted by garthpaine View Post
    Hi all - I just wanted to check with you all about SD card size - I ran some tests with 32GB, 64GB and 128GB cards - the 32GB was the only card that produced files - I am assuming therefore that the larger cards are not readable by the Teensy? I have formatted them all in the terminal using the same command so the formats should be identical - I would appreciate advice as larger cards would be very welcome safeguard for longer periods of recordin.
    The microSoundRecorder should work with all sizes of SD cards

  9. #59
    Senior Member DD4WH's Avatar
    Join Date
    Oct 2015
    Location
    Central Europe
    Posts
    310
    I successfully used the microSoundRecorder with SD cards of the following sizes:

    - 2GB
    - 8GB
    -32GB
    -64GB

  10. #60
    Senior Member
    Join Date
    Jul 2014
    Posts
    1,912
    @dreggory,
    there where bad copies in that master.
    I hope the actual one is more correct.
    you can now change the number of bits shifted to the right in config.h

  11. #61
    Ok - thank you - just checking - I am formatting via the terminal on OSX as I understand the Disk Utility uses an incorrect MS-DOS(FAT) header - the terminal command I am using is the following where /dev/disk2 is the SD Card

    sudo diskutil eraseDisk FAT32 MCREC04 MBRFormat /dev/disk2.

    I would love to use 64 or larger as the battery does not seem to be a big issue on this system - which is wonderfully awesome!
    Thanks, Garth

  12. #62
    Member
    Join Date
    Mar 2017
    Location
    Utah
    Posts
    55
    At the moment all data are shifted by 12 bit to the right and then the lower 16 bit are kept.
    Idea is to adjust shift so that background noise is just visible in power spectrum
    the 16 bit in the final data gives you then 96 dB dynamic range, this is good for most applications.
    okay, you're right that is more than enough. I'm happy with that.

    So, I tried the latest Master, Success! Here are the results:
    https://drive.google.com/open?id=1Do...YVmnli3yg5uW9U
    I notice that Audacity has trouble sorting the order (if I import the same file multiple times it sometimes changes order), that will be annoying. Is there any way of helping Audacity to sort them properly by using the header?
    Anyway, high five to you! Excellent work! Thank you!

  13. #63
    Member
    Join Date
    Mar 2017
    Location
    Utah
    Posts
    55
    I think maybe the random ordering of the tracks is not Audacitys fault.
    Edit from thinking it was Audacitys fault to thinking, the code still needs something.
    I came to this conclusion after seeing the cross correlation delay relative to mic 1 for the three files where I rubbed the mics in sequence. Notice the delays are not consistent from file to file:
    Code:
    First row is time delay, second row is sample delay:
    file = TDM_2018_07_09_19_13_15.wav
    0.000000000000, 1.822625000000, 8.368604166667, -3.129416666667, -1.876291666667
    0.000000000000, 87486.000000000000, 401693.000000000000, -150212.000000000000, -90062.000000000000
    >> AudioShiftAndAverage
    
    file = TDM_2018_07_09_19_13_25.wav
    0.000000000000, 2.171062500000, 3.784187500000, 4.766208333333, -1.201833333333
    0.000000000000, 104211.000000000000, 181641.000000000000, 228778.000000000000, -57688.000000000000
    >> AudioShiftAndAverage
    
    file = TDM_2018_07_09_19_13_35.wav
    0.000000000000, -5.297083333333, -4.215916666667, -2.827104166667, -1.125062500000
    0.000000000000, -254260.000000000000, -202364.000000000000, -135701.000000000000, -54003.000000000000
    Why this is important to me: once I identify the tracks I can start my beamforming process. I need to shift the audio samples relative to each other in a very specific time shifts so that when I average the tracks into one mono track it will randomly filter out noise from every other location (I really need to know the order of the tracks).
    Last edited by dreggory; 07-10-2018 at 03:46 AM. Reason: Looked a little closer at the audio files and changed my mind

  14. #64
    does anyone have any further insight into the card formatting - I would love to get larger cards working.

    PS. I ran a 10000mAh battery on one mono setup and it ran for 6 days doing 120, 60, 180

  15. #65
    Senior Member
    Join Date
    Jul 2014
    Posts
    1,912
    Quote Originally Posted by dreggory View Post
    I think maybe the random ordering of the tracks is not Audacitys fault.
    Edit from thinking it was Audacitys fault to thinking, the code still needs something.
    I came to this conclusion after seeing the cross correlation delay relative to mic 1 for the three files where I rubbed the mics in sequence. Notice the delays are not consistent from file to file:
    Code:
    First row is time delay, second row is sample delay:
    file = TDM_2018_07_09_19_13_15.wav
    0.000000000000, 1.822625000000, 8.368604166667, -3.129416666667, -1.876291666667
    0.000000000000, 87486.000000000000, 401693.000000000000, -150212.000000000000, -90062.000000000000
    >> AudioShiftAndAverage
    
    file = TDM_2018_07_09_19_13_25.wav
    0.000000000000, 2.171062500000, 3.784187500000, 4.766208333333, -1.201833333333
    0.000000000000, 104211.000000000000, 181641.000000000000, 228778.000000000000, -57688.000000000000
    >> AudioShiftAndAverage
    
    file = TDM_2018_07_09_19_13_35.wav
    0.000000000000, -5.297083333333, -4.215916666667, -2.827104166667, -1.125062500000
    0.000000000000, -254260.000000000000, -202364.000000000000, -135701.000000000000, -54003.000000000000
    Why this is important to me: once I identify the tracks I can start my beamforming process. I need to shift the audio samples relative to each other in a very specific time shifts so that when I average the tracks into one mono track it will randomly filter out noise from every other location (I really need to know the order of the tracks).
    If you really using the same file (as indicated by the identical filename, then you Matlab/octave script has a bug (e.g. an index into the data that is not reset on startup)
    There is no way that data read in identical way from file are randomly oriented.

    Anyhow,
    As the program is written, it always writes full disk blocks (i.e. data length per file is N*512 -44 bytes) there is direct way to fit exactly multiple of 10 bytes into the data.
    What I can try to do is to limit the last record to a multiple of 10 bytes.

  16. #66
    Senior Member
    Join Date
    Jul 2014
    Posts
    1,912
    I format my cards with windows build in formatter (I use up to 128GB) and accept default formatting

  17. #67
    Senior Member
    Join Date
    Jul 2014
    Posts
    1,912
    @dreggory

    give a try the "_dev" branch (it should limit filesize to multiple of NCH)
    Note: master branch is unchanged

  18. #68
    Senior Member DD4WH's Avatar
    Join Date
    Oct 2015
    Location
    Central Europe
    Posts
    310
    @garth

    Could you give us some more information on your setup?

    * What kind of battery were you using? Did it contain a battery management system or was it just a plain battery?
    * Did you use the option #define SHORT_SLEEP? If yes, which short sleep interval did you use?
    * Did you use your schedule [120, 60, 180 . . .] for 24h or was it restricted to certain hours of the day?
    * What was the temperature/environmental condition? [batteries seem to run better on higher temperatures than under freezing conditions ;-)]

    This would help us interpret your result of six days run time. Also, if you could give that additional information and you agree with it, I would like to integrate your info into the WIKI.

    See also our prior measurements of power consumption and run time here: https://github.com/WMXZ-EU/microSoun...tery-life-time

    It seems that formatting SD cards under Linux is not really straight forward . . .

    I use SDFormatter under Windows for all my purposes (well, in fact, I really rarely use µSD card formatting at all, because all microSD cards I purchased up to now ran out-of-the-box for the microSoundRecorder: tested 2GB, 8GB, 32GB & 64GB).

    Have fun with the Teensy,

    Frank DD4WH

  19. #69
    Member
    Join Date
    Mar 2017
    Location
    Utah
    Posts
    55
    If you really using the same file (as indicated by the identical filename, then you Matlab/octave script has a bug (e.g. an index into the data that is not reset on startup)
    There is no way that data read in identical way from file are randomly oriented.
    I discovered that if you import audio vs import RAW in audacity, you get different orders (probably because I wasn't excluding the header when I imported RAW), but import Audio (using Audacity) always agrees with Octave audioread() I can read the same file multiple times for both and it doesn't change.
    -However, if I read file 1 vs file 2(using Audacity or Octave, doesn't matter) the mic order gets mixed between files (i.e. TDM_2018_07_09_19_13_15.wav versus TDM_2018_07_09_19_13_25.wav). This is a problem for what I'm doing so I need them to be consistent from file to file. I hope I explained myself better that time, apologies.
    give a try the "_dev" branch (it should limit filesize to multiple of NCH)
    Note: master branch is unchanged
    I'm testing that now...
    ...Using the "_dev" commit, I used import audio(from Audacity) and the first file has the mics appearing in this order: 34512, the second file has: 12345, and the third file has: 23451.
    The audio is good though, and the tracks are seperated, they just show up in different orders from file to file.
    here is the latest audio, I'm just sliding a newspaper across the mics in order (create file *touch mics in order* 12345, new file 12345, new file 12345 end):
    https://drive.google.com/open?id=1nl...xiTPT6pzMdVDcc
    Last edited by dreggory; 07-11-2018 at 02:30 AM. Reason: Grammar fix

  20. #70
    Senior Member
    Join Date
    Jul 2014
    Posts
    1,912
    @dreggory

    I tried to clean-up the filing operation in loop().
    Could you try latest '_dev' commit (I myself have no time to test)

  21. #71
    Member
    Join Date
    Mar 2017
    Location
    Utah
    Posts
    55
    Quote Originally Posted by WMXZ View Post
    @dreggory

    I tried to clean-up the filing operation in loop().
    Could you try latest '_dev' commit (I myself have no time to test)
    Done, it works perfectly. all things in order. Thank you so much!

  22. #72
    Senior Member
    Join Date
    Jul 2014
    Posts
    1,912
    Quote Originally Posted by dreggory View Post
    Done, it works perfectly. all things in order. Thank you so much!
    There was still a small bug in the transition from one file to the next, that should result in corrupted data.
    GitHub has now latest version.
    Thanks for testing.

  23. #73
    logging in your SD card sometimes being restricted when you put password on your card in other device and you still try to load SD card in another device. So this may be a reason for problem in logging in your SD card.

  24. #74
    hi Frank

    I am away from the system at the moment, but I was using a 10000mAH battery pack which I assume would have battery management in it as it is used for charging USB devices - I will check the make and model when I get home tomorrow and report back.

    The setting was'
    #define ACQ _I2S_32_MONO
    ACQ_Parameters_s acqParameters = { 120, 60, 180, 0, 12, 12, 24, 0, "Mc02"};
    #define ShortSleepDuration 60
    #define USE_ENVIRONMENTAL_SENSORS 0

    One MEMS mic is connected - no environmental sensors connected at this point.

    I don't understand the Short Sleep setting
    //#define SLEEP_SHORT

    I am unclear what this does

    On another challenge - with the code I downloaded last week, we get an issue which is when the device boots up it records 2 files OK - after that no additional files are recorded - this was also discovered to be a problem after the power/battery life test. My student has tried this again in the last few days and got a good recording for the first 2 60s files and then nothing - he also reports that when he then reconnects the Teensy to power it does not record again. Has anyone else had this issue?

    I will be back home tomorrow and will download the most recent version and try again. Could this be a setting I am overlooking or misunderstanding?

    Thanks, Garth

  25. #75
    Senior Member
    Join Date
    Jul 2014
    Posts
    1,912
    Quote Originally Posted by garthpaine View Post
    hi Frank

    I am away from the system at the moment, but I was using a 10000mAH battery pack which I assume would have battery management in it as it is used for charging USB devices - I will check the make and model when I get home tomorrow and report back.

    The setting was'
    #define ACQ _I2S_32_MONO
    ACQ_Parameters_s acqParameters = { 120, 60, 180, 0, 12, 12, 24, 0, "Mc02"};
    #define ShortSleepDuration 60
    #define USE_ENVIRONMENTAL_SENSORS 0

    One MEMS mic is connected - no environmental sensors connected at this point.

    I don't understand the Short Sleep setting
    //#define SLEEP_SHORT

    I am unclear what this does

    On another challenge - with the code I downloaded last week, we get an issue which is when the device boots up it records 2 files OK - after that no additional files are recorded - this was also discovered to be a problem after the power/battery life test. My student has tried this again in the last few days and got a good recording for the first 2 60s files and then nothing - he also reports that when he then reconnects the Teensy to power it does not record again. Has anyone else had this issue?

    I will be back home tomorrow and will download the most recent version and try again. Could this be a setting I am overlooking or misunderstanding?

    Thanks, Garth
    Garth
    the #define SLEEP_SHORT definition switches the code on that handles the frequent wakeups.
    in order to use this feature (to wake-up to keep powerbank running) you must uncomment this line.
    for testing, I would suggest to put ShortSleepDuration to a small value, say 10 s

    concerning the last issue.
    If the code is compiled with "#define DO_DEBUG 1" then setup may hang when no usb-serial is connected. Is now corrected.
    Even if you forget to set "#define DO_DEBUG 0", program will continue with setup when pin3 is left floating, or pulled high.
    if pin3 is grounded during wakeup (restart) then with "#define DO_DEBUG 1" setup() waits for usb-serial to be connected.

    if the code was compiled with "#define DO_DEBUG 0" and does not wake-up, then the powerbank went also to sleep during hibernate period

    on other issue:
    my tympan is somehow hold in customs (for 3 days now) according to USPS tracking without further information on why and how long.
    (seems to be an issue with USPS international shipping, as Fedex import was only 5 minutes)
    So tympan testing must wait

    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
  •