Audio Recording / Logging to SD card --> microSoundRecorder

@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:
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?
 
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.
 
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.
 
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=18DOv-s21JqBvt4veYWjhOI-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:

Clap audio snippet.png
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.
 
this is what I recorded with the code in the master branch:
https://drive.google.com/open?id=18DOv-s21JqBvt4veYWjhOI-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.
 
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
 
I successfully used the microSoundRecorder with SD cards of the following sizes:

- 2GB
- 8GB
-32GB
-64GB
 
@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
 
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
 
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=1Dohk1dVYTTJ2D3gAvbYVmnli3yg5uW9U
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!
 
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:
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
 
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.
 
I format my cards with windows build in formatter (I use up to 128GB) and accept default formatting
 
@dreggory

give a try the "_dev" branch (it should limit filesize to multiple of NCH)
Note: master branch is unchanged
 
@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/microSou...es,-current-consumption-and-battery-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
 
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=1nlo0soopKhsFsPQ2G3xiTPT6pzMdVDcc
 
Last edited:
@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!

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.
 
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.
 
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
 
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
 
Back
Top