Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 9 of 9

Thread: Cheap ICS-52000 Microphone Array Board for TDM evaluation

  1. #1

    How to format TDM data from cheap ICS-52000 Microphone Array Board?

    Hi folks,

    I recently found a relatively cheap (not so much after shipping and custom fees to Europe) ICS-52000 Microphone Array Board. You can find it here. I have 2 of them daisy chained for a total of 8 Microphones.

    Click image for larger version. 

Name:	NW_AUD_ICS52000.png 
Views:	24 
Size:	62.8 KB 
ID:	12342

    I was planning to use this USB streamer which costed me more than 150$ after shipping and custom fees. However, after receiving it and checking myself the TDM specifications that were not clearly provided in the datasheet I've found it it's not compatible with the ICS-52000 microphones. Audio data is not shifted in the appropriate timing, so sad.

    Now, I do need a fast solution for evaluating the microphones, so here we have Teensy 3.6 (I'm lately planning to move to a SHARC DSP).

    I'm planning to simply record all 16x16-bit channels using tdm and queue objects (based on Recorder example) in a SD card (RAW format), to lately process the data into 8x32 bits channels using Matlab/Python.

    Ideally I was planning to be able to stream all 8x32 bits channel via a USB Audio Interface for real-time processing on Python using ASIO drivers, but I don't think this is an option with current usb object on Teensy.

    Can you foreseen any limitation or problems?

    I'll post my progress here, thank you,
    Pedro
    Last edited by Mr.Pedro; 12-31-2017 at 03:54 PM.

  2. #2
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    16,275
    Looks interesting. I ordered 2 of them. Don't know when I'll actually do anything with them, if ever...

  3. #3
    Quote Originally Posted by PaulStoffregen View Post
    Looks interesting. I ordered 2 of them. Don't know when I'll actually do anything with them, if ever...
    Happy new year but meanwhile...

    I'm trying to get 1 channel of 24 bits PCM Audio Data at 44.1KHz from 2 NW-AUD-ICS52000 boards connected in the same bus (8 Microphones) based on TDM and queue objects using a modified version of the Recorder example.

    Click image for larger version. 

Name:	abb50072634bbdd3a32fb5976e0b9d49.png 
Views:	5 
Size:	76.0 KB 
ID:	12481

    Code:
    // Record TDM input sound as raw data (16ch, Signed 16-bit PCM, 44.1kHz, little-endian) to a SD card.
    // Note: Need to modify format, mics align their 24 bit data to 32 bit slots, so half of the 16 bit
    // channels will end up being the 8 low bits, and 8 more zeros.
    //
    // Hardware:
    //   Pin  9 SCLK  (Output, 11.3 MHz, Checked)
    //   Pin 13 SDATA (Input, 11.3 Mbit/sec)
    //   Pin 23 FS    (Output, 44100 Hz, Checked)
    //
    // This example code is in the public domain.
    
    #include <Audio.h>
    #include <Wire.h>
    #include <SPI.h>
    #include <SD.h>
    #include <SerialFlash.h>
    
    // GUItool: begin automatically generated code
    AudioInputTDM            tdm1;           //xy=359,317
    //AudioRecordQueue         queue13;        //xy=620,615
    //AudioRecordQueue         queue14;        //xy=620,649
    //AudioRecordQueue         queue15;        //xy=620,682
    //AudioRecordQueue         queue12;        //xy=621,581
    //AudioRecordQueue         queue16;        //xy=622,716
    //AudioRecordQueue         queue9;         //xy=623,480
    //AudioRecordQueue         queue10;        //xy=623,514
    //AudioRecordQueue         queue11;        //xy=623,547
    //AudioRecordQueue         queue4;         //xy=624,315
    //AudioRecordQueue         queue5;         //xy=624,348
    //AudioRecordQueue         queue6;         //xy=624,381
    //AudioRecordQueue         queue7;         //xy=624,414
    //AudioRecordQueue         queue3;         //xy=625,281
    //AudioRecordQueue         queue8;         //xy=625,447
    AudioRecordQueue         queue2;         //xy=626,248
    AudioRecordQueue         queue1;         //xy=627,214
    AudioConnection          patchCord1(tdm1, 0, queue1, 0);
    AudioConnection          patchCord2(tdm1, 1, queue2, 0);
    //AudioConnection          patchCord3(tdm1, 2, queue3, 0);
    //AudioConnection          patchCord4(tdm1, 3, queue4, 0);
    //AudioConnection          patchCord5(tdm1, 4, queue5, 0);
    //AudioConnection          patchCord6(tdm1, 5, queue6, 0);
    //AudioConnection          patchCord7(tdm1, 6, queue7, 0);
    //AudioConnection          patchCord8(tdm1, 7, queue8, 0);
    //AudioConnection          patchCord9(tdm1, 8, queue9, 0);
    //AudioConnection          patchCord10(tdm1, 9, queue10, 0);
    //AudioConnection          patchCord11(tdm1, 10, queue11, 0);
    //AudioConnection          patchCord12(tdm1, 11, queue12, 0);
    //AudioConnection          patchCord13(tdm1, 12, queue13, 0);
    //AudioConnection          patchCord14(tdm1, 13, queue14, 0);
    //AudioConnection          patchCord15(tdm1, 14, queue15, 0);
    //AudioConnection          patchCord16(tdm1, 15, queue16, 0);
    AudioControlSGTL5000     sgtl5000_1;     //xy=369,479
    // GUItool: end automatically generated code
    
    // 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
    int choice = 0;
    int sample_number = 0;
    
    unsigned int tsamplemillis = 11000;
    
    String typeofsound;
    
    // The file where data is recorded
    File frec;
    
    void setup() {
      
      Serial.begin(9600);
    
      // 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();
    
      // 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);
        }
      }
    
      while(!Serial);
    
      Serial.println("Welcome to the beta version of Viband's TDM sound recorder, 11 second clips are going to be recorded, be \ncareful introducing a new type of sound already introduced since previous samples will be overwritten.");
      Serial.println("\nNote: SD Library uses short 8.3 names (12 characters). Filename (i.e baby/baby24) can't be longer.");
    }
    
    void loop() {
    
      if(choice==0){
      Serial.println("\nIntroduce new type of sound (i.e baby): ");
      while(!Serial.available());
      typeofsound = Serial.readString();
      sample_number = 0;
      record(typeofsound,sample_number);
      } else if(choice==1){
        sample_number++;
        record(typeofsound,sample_number);
      } else {
        //Do nothing
      }
    
      Serial.print("\nIntroduce 1 to take another sample or 0 to introduce a new type of sound: ");
      while(!Serial.available());
      choice = Serial.readString().toInt();
      Serial.println(choice);
        
    }
    
    void record(String type, int number){
      Serial.println("Recording " + type + String(number) + "...");
      elapsedMillis recordingTime = 0;
      String sname = type + number + ".RAW";
      String path = type + "/" + type + number + ".RAW";
      startRecording(sname, path, type);  
      while(recordingTime<tsamplemillis) continueRecording();
      stopRecording(); 
    }
    
    void startRecording(String sname, String path, String type) {
      
      int str_len = path.length()+1;
      char charpath[str_len];
      path.toCharArray(charpath,str_len);
    
      if (SD.exists(charpath)) {
        // 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(charpath);
      }
    
      str_len = type.length()+1;
      char chartype[str_len];
      type.toCharArray(chartype,str_len);
    
      if(!SD.exists(chartype)){
        SD.mkdir(chartype);
      }
      
      frec = SD.open(charpath, FILE_WRITE);
      if (frec) {
        Serial.println("File Open");
        queue1.begin();
        queue2.begin();
    //    queue3.begin();
    //    queue4.begin();
    //    queue5.begin();
    //    queue6.begin();
    //    queue7.begin();
    //    queue8.begin();
    //    queue9.begin();
    //    queue10.begin();
    //    queue11.begin();
    //    queue12.begin();
    //    queue13.begin();
    //    queue14.begin();
    //    queue15.begin();
    //    queue16.begin();
        mode = 1;
      }
    }
    
    void continueRecording() {
      if (queue1.available() >= 2 && queue2.available() >=2) {
        byte buffer[512];
        byte buffer1[256];
        byte buffer2[256];
        // 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(buffer1, queue1.readBuffer(), 256);
        memcpy(buffer2, queue2.readBuffer(), 256);
        queue1.freeBuffer();
        queue2.freeBuffer();
        int b = 0;
        for(int i = 0; i < 512; i += 2){
            buffer[i] = buffer1[b];
            buffer[i + 1] = buffer2[b];
            b++;
        }
        // write all 512 bytes to the SD card
        //elapsedMicros usec = 0;
        frec.write(buffer, 512);
        // 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("Finished recording.");
      queue1.end();
      queue2.end();
      queue1.clear();
      queue2.clear();
      frec.close();  
      mode = 0;
    }
    I'm using queue1 and queue2 to get the first 2x 16 bit objects which are supposed to contain the 24 bit audio data and 8 more zero in the 8 low bits.

    The way I'm interleaving the 2 queue objects when writing to the SD file is shown in the code:

    Code:
    void continueRecording() {
      if (queue1.available() >= 2 && queue2.available() >=2) {
        byte buffer[512];
        byte buffer1[256];
        byte buffer2[256];
        memcpy(buffer1, queue1.readBuffer(), 256);
        memcpy(buffer2, queue2.readBuffer(), 256);
        queue1.freeBuffer();
        queue2.freeBuffer();
        int b = 0;
        for(int i = 0; i < 512; i += 2){
            buffer[i] = buffer1[b];
            buffer[i + 1] = buffer2[b];
            b++;
        }
        frec.write(buffer, 512);
      }
    }
    I was expecting to obtain 32-bit sample which look (in hexadecimal) like this:
    XX XX XX 00

    However, using Sublime Text with Hexadecimal Encoding this is what I get:

    Click image for larger version. 

Name:	96b63031c59c4a6b9b35c0dd65dd6679.png 
Views:	10 
Size:	71.9 KB 
ID:	12482

    In comparison to a 16-bit PCM Audio Data Raw File obtained using Teensy Audio Board, an analog Microphone and Teensy Recorder example:

    Click image for larger version. 

Name:	aa3ce682d9dd1c2ee13647efe01a7828.png 
Views:	11 
Size:	69.0 KB 
ID:	12483

    1. How to interpret the 16-bit PCM Audio Data Raw File? (I can see a pattern of 8 data bits and 8 bits containing all zeros 00, or all 1s ff)
    2. How to interpret the 32-bit blocks from the TDM bus if they are correct?


    I want to use Python/Matlab to properly format the data to Signed 24-bit PCM Big/Little endian 1 channel mono to open with Audacity.

    3. How does this format (Signed 24-bit PCM Big/Little endian 1 channel mono) should look? (i.e 24-bit blocks of raw audio data or 32-bit blocks with 8 zeros in the low 8 bits) I would highly appreciate if someone can share a diagram of how the format should look like. I've not been able to find a good one.

    You can download the RAW files from here:
    https://drive.google.com/open?id=12G...XZg6tlekg5EODD

    Thanks all,
    Pedro
    Last edited by Mr.Pedro; 12-31-2017 at 03:53 PM.

  4. #4
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    16,275
    Quote Originally Posted by Mr.Pedro View Post
    Code:
    void continueRecording() {
      if (queue1.available() >= 2 && queue2.available() >=2) {
        byte buffer[512];
        byte buffer1[256];
        byte buffer2[256];
        memcpy(buffer1, queue1.readBuffer(), 256);
        memcpy(buffer2, queue2.readBuffer(), 256);
        queue1.freeBuffer();
        queue2.freeBuffer();
        int b = 0;
        for(int i = 0; i < 512; i += 2){
            buffer[i] = buffer1[b];
            buffer[i + 1] = buffer2[b];
            b++;
        }
        frec.write(buffer, 512);
      }
    }
    This code is probably not what you want. You're composing the output by interleaving 8 bit bytes from each of the 2 buffers. But those 2 buffers are 16 bit samples. Treating the data as bytes will result in the original 32 bit data (pairs of 16 bits) scrambled up in a rather odd way.

    You probably meant to create buffer1 and buffer2 like this:

    Code:
        uint16_t buffer1[128];
        uint16_t buffer2[128];
    Since you're creating 32 bit outputs back from the pairs of 16, the output buffer probably should be defined this way:

    Code:
        uint32_t buffer[128];
    Then you need to create a loop which reassembles the 32 bit data from each pair of 16 bit numbers, instead of just scrambling it all as interleaved bytes. Maybe like this:

    Code:
        for(int i = 0; i < 128; i ++){
            buffer[i] = (buffer1[i] << 16) | buffer2[i];
        }
    If this ends up with each word backwards, just swap buffer1 and buffer2 so buffer2's data ends up in the most significant half of each 32 bit word.

    Hope this all makes good sense?

  5. #5
    You are right, I missed with the buffer sizes.

    Now, I'm using the following code which just uses a pair of 16-bit buffers to directly write to the SD with the proper interleaving:
    Code:
    void continueRecording() {
      if (queue1.available() >= 2 && queue2.available() >=2) {
        uint16_t buffer1[128];
        uint16_t buffer2[128];
        memcpy(buffer1, queue1.readBuffer(), 256);
        memcpy(buffer2, queue2.readBuffer(), 256);
        queue1.freeBuffer();
        queue2.freeBuffer();
        for(int i = 0; i < 128; i ++){
            frec.write(buffer1[i]>>8);
            frec.write(buffer1[i]);
            frec.write(buffer2[i]>>8);
            frec.write(buffer2[i]);
        }
      }
    }
    When testing individually recording only buffer1 and buffer2 to ease the visualization I get:
    buffer1 contains either FFFX or 000X:
    Code:
    fffd fffe ffff fffe fffe fffe fffe ffff
    fffe fffe fffd fffe ffff ffff fffe fffe
    fffe fffe fffd fffd fffe fffe fffe fffe
    fffe fffe fffe ffff ffff ffff ffff ffff
    0000 0000 0000 0000 ffff 0000 ffff 0000
    0000 0001 0000 0001 0001 ffff 0000 0000
    0000 ffff 0000 0000 0000 0000 ffff 0001
    ffff 0000 0000 0000 0001 0000 0001 0000
    ffff ffff ffff 0000 0000 0001 0001 0001
    buffer2 contains either XX00 or XXc0:
    Code:
    33c0 6c00 1e00 3a00 9bc0 f600 adc0 5400
    23c0 5bc0 b5c0 37c0 c3c0 ac00 29c0 41c0
    e000 dbc0 fbc0 c5c0 d000 fc00 d5c0 2dc0
    9c00 89c0 3400 d000 dc00 17c0 d1c0 1a00
    3a00 2200 b9c0 fdc0 e7c0 6c00 2e00 e9c0
    8200 3000 edc0 dc00 7200 b000 6a00 49c0
    5e00 a600 cdc0 ffc0 d000 3c00 2200 3e00
    77c0 c600 4200 cc00 a5c0 61c0 ba00 e1c0
    61c0 bbc0 13c0 d200 21c0 8e00 f5c0 f200
    2dc0 2bc0 0400 d000 5200 f800 f600 adc0
    1. Are buffer1 and buffer2 correct?
    2. How should a single Signed 24-bit PCM sample look like?


    Again, referring to the original Recorder example and using an analog microphone I'm trying to understand Signed 16-bit PCM Raw Audio data format:
    Code:
    caff b1ff a0ff a2ff a7ff acff a4ff 9dff
    a7ff b7ff c9ff c4ff bbff bbff c9ff deff
    f6ff 1700 3800 4a00 5100 4b00 4100 3d00
    3000 2e00 2000 0100 e4ff daff daff d2ff
    d2ff cbff bbff b4ff b9ff b7ff bdff d2ff
    f1ff 1200 3500 4c00 5e00 6d00 7b00 8900
    8800 8b00 9900 9f00 9e00 9600 8000 6300
    4800 2200 0200 feff fcff 0c00 1600 2e00
    3800 3900 2600 1000 fcff e7ff cdff b7ff
    3. Shouldn't it contain 16 bits of data (i.e XXXX) instead of 8 bits of data and either FF or 00 (i.e XXFF or XX00)
    Last edited by Mr.Pedro; 01-04-2018 at 01:09 AM.

  6. #6
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    16,275
    Quote Originally Posted by Mr.Pedro View Post
    Again, referring to the original Recorder example and using an analog microphone I'm trying to understand Signed 16-bit PCM Raw Audio data format:
    Code:
    caff b1ff a0ff a2ff a7ff acff a4ff 9dff
    a7ff b7ff c9ff c4ff bbff bbff c9ff deff
    f6ff 1700 3800 4a00 5100 4b00 4100 3d00
    3000 2e00 2000 0100 e4ff daff daff d2ff
    d2ff cbff bbff b4ff b9ff b7ff bdff d2ff
    f1ff 1200 3500 4c00 5e00 6d00 7b00 8900
    8800 8b00 9900 9f00 9e00 9600 8000 6300
    4800 2200 0200 feff fcff 0c00 1600 2e00
    3800 3900 2600 1000 fcff e7ff cdff b7ff
    3. Shouldn't it contain 16 bits of data (i.e XXXX) instead of 8 bits of data and either FF or 00 (i.e XXFF or XX00)
    This looks "normal" for a very small signal, assuming whatever you're using to print the data as HEX is showing the bytes in the order they occur in the file (LSB first).

    9f00 -> 159

    a2ff -> -97

    Maybe if you turn up the mic gain, or just provide stronger sound input to the mic, you'll see 16 bit data spanning a wider numerical range?

  7. #7
    Quote Originally Posted by PaulStoffregen View Post
    This looks "normal" for a very small signal, assuming whatever you're using to print the data as HEX is showing the bytes in the order they occur in the file (LSB first).

    9f00 -> 159

    a2ff -> -97

    Maybe if you turn up the mic gain, or just provide stronger sound input to the mic, you'll see 16 bit data spanning a wider numerical range?
    Thank you for the note which has helped me understanding Raw Audio Format.

    Signed 24-bit little-endian PCM code:
    Code:
    void continueRecording() {
      if (queue1.available() >= 2 && queue2.available() >=2) {
        uint16_t buffer1[128];
        uint16_t buffer2[128];
        memcpy(buffer1, queue1.readBuffer(), 256);
        memcpy(buffer2, queue2.readBuffer(), 256);
        queue1.freeBuffer();
        queue2.freeBuffer();
        for(int i = 0; i < 128; i ++){
            frec.write(buffer2[i]>>8); // LSB
            frec.write(buffer1[i]); // Middle Byte
            frec.write(buffer1[i]>>8); // MSB       
            //frec.write(buffer2[i]); // Zeros
        }
      }
    }
    Beginning of RAW File example:
    Code:
    bc00 002d ffff 57ff ff42 0000 5cff ffb1
    ffff 6eff ff5f ffff eaff ff05 ffff dffe
    ffe0 ffff 34ff ff49 ffff f0ff fffb fdff
    08fe ff19 0000 5bff ff5c 0100 98ff ff69
    ffff 9afe ffe8 feff d9fe ffd4 feff b0fe
    ff85 feff b2fe ff7e ffff 4efe ff51 fcff
    46fd ffd9 feff f7fc ff90 fdff dbfd ff9c
    fdff 8ffe ffd3 fdff a1fc ffea ffff befd
    ff2b fdff 5efe ff40 feff 33ff ff70 fdff
    66fe ff3c fdff c8fe ff2d fdff fefd ff73
    fdff c2fd ff4d fcff d700 0050 fdff 51fe
    ffdd ffff 5ffe ff18 ffff e7ff ffba ffff
    1fff ff7b ffff 57fd ffcf feff 02fe ff14
    feff 9ffe ff1b fdff a2fd ffe3 feff abfd
    ffa8 fcff 20fd ff76 feff 75fe ff59 feff
    e5fe ff73 feff 82ff fff1 fdff fefe ff8b
    First sample: bc0000 = 188
    Second sample: 2d ffff = -211
    ...

    File data seems correct and matches the designed interleaving and writing, however, when importing using Audacity as Raw Data... Signed 24-bit PCM, Little-endian, 1 Channel (Mono), Sample rate: 44100 Hz, this is what I get:
    Click image for larger version. 

Name:	01e56d9d45791349b6a971d3a8e70552.jpg 
Views:	5 
Size:	53.3 KB 
ID:	12506

    Also, when writing only the LSB and the low 8 zero bits I don't always get 00 but it flips between 00 and c0:
    Code:
    63c0 6800 3bc0 7200 b600 5200 8200 47c0
    fe00 abc0 65c0 25c0 3200 8fc0 8000 37c0
    5bc0 f1c0 1fc0 8800 5800 b000 e1c0 3bc0
    fdc0 7bc0 63c0 5fc0 f9c0 3bc0 dbc0 7800
    87c0 65c0 0dc0 03c0 01c0 3800 a200 ae00
    fe00 b400 c9c0 9c00 4a00 9600 8c00 fe00
    79c0 0c00 b3c0 1dc0 a7c0 c9c0 5200 ce00
    3dc0 61c0 cdc0 be00 6000 17c0 91c0 5800
    aa00 2a00 55c0 25c0 e200 a1c0 7800 87c0
    1. Is my assumption about how Signed 24-bit PCM data should look like correct?

    PS. When increasing Audacity gain to +36dB it seems I can hear some of the knocks I'm doing in a bell, I'll continue checking this in case it's a microphone/microphone gain issue.
    Last edited by Mr.Pedro; 01-04-2018 at 02:12 PM.

  8. #8
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    16,275
    Maybe you should first concentrate on getting the hardware working and mic gain set appropriately?

    It's very easy to just put the DAC output on the design and route the 16 bit signal to also drive the DAC. Then you can connect the DAC to an amplifier and headphones or a speaker (which hopefully doesn't feed back into the mic - headphones are much safer) and listen to actually hear whether the audio is correct and the level is reasonable.

    Or you can put the USB output into your design and set Tools > USB Type to Audio, and then capture the 16 bit data with audacity. But I personally prefer getting a real analog signal and actually listening with headphones. There is much your ears can tell you instantly that gets lost in the complexity of viewing numbers and waveforms.

  9. #9
    Quote Originally Posted by PaulStoffregen View Post
    Maybe you should first concentrate on getting the hardware working and mic gain set appropriately?

    It's very easy to just put the DAC output on the design and route the 16 bit signal to also drive the DAC. Then you can connect the DAC to an amplifier and headphones or a speaker (which hopefully doesn't feed back into the mic - headphones are much safer) and listen to actually hear whether the audio is correct and the level is reasonable.

    Or you can put the USB output into your design and set Tools > USB Type to Audio, and then capture the 16 bit data with audacity. But I personally prefer getting a real analog signal and actually listening with headphones. There is much your ears can tell you instantly that gets lost in the complexity of viewing numbers and waveforms.
    You are right about the hardware test, upon my hardware availability I've tested USB output, capturing the 16 bit data with audacity, the result is similar. I need to increase gain to 36dB to be able to roughly identify really loud and close noises to the microphone.

    Also, I've read the Signed 24 bit little-endian PCM 44.1 KHz Raw File using Pyhton to ease the visualization of the analog signal and to perform frequency domain analysis to see if the signal contains data so that it's only a mic gain problem:
    Code:
    x, fs = sf.read(path, dtype='int32', channels=1, samplerate=44100, format='RAW', endian='LITTLE', subtype='PCM_24')
        x = x / 8388608
    [-1,1) Analog signal (note maximum value is 0.06):
    Click image for larger version. 

Name:	dfaa08e7de788ed9f27e0f54d8c36849.png 
Views:	16 
Size:	50.7 KB 
ID:	12520

    STFT (just noise, it should contain dominant frequencies at 2500, 5000, 7500Hz...):
    Click image for larger version. 

Name:	246ac1ee2e3857dfc735c19602ee22f0.png 
Views:	16 
Size:	382.3 KB 
ID:	12521

    I'm posting at invensense forum since I believe it's a microphone issue. I've also tried channel 2, same result.

    Thank you,
    Pedro
    Last edited by Mr.Pedro; 01-06-2018 at 03:54 PM.

Posting Permissions

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