GPIO 29 used in example

[jimtal001]

In your example you used GPIO29 for serial data (SD) connection to the INMP441 Mic. I am interested to know why you choose this particular pin since (from what I understand) it's not recommended since it is the VSYS pin.

[biemster]

On the rp2040-zero which I used for this, that pin was just in the right spot to solder it dead bug style (I also did not know it is the VSYS pin..)

[jimtal001]

Good to know. Thank you. I thought you were using the RP Pico.

…

On Wed, Mar 27, 2024, 09:06 biemster ***@***.***> wrote: On the rp2040-zero which I used for this, that pin was just in the right spot to solder it dead bug style (I also did not know it is the VSYS pin..) — Reply to this email directly, view it on GitHub <#2 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB5LB7RH7K7UERFMJPENXDTY2K76FAVCNFSM6AAAAABFK6E4DWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMRSHA3DCMJXGY> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[jimtal001]

I have been testing your example code using an RP Pico W on a windows pc. I have changed the I2S pins to:
#define SCK 11 // clock pin
#define WS 12 // needs to be SCK +1
#define SD 13 // Serial Data Pin, used on different board
The code appears to run without issue however I am not sure about the output. As the data is passed to the terminal in VS Code and a log is generated. Next, I import this log file into Audacity as a raw file. Then it is necessary to set several import parameters: encoding, byte order, channels, sample rate. I've tried most of the settings but none result in any reasonable output (e.g. 32 bit,BE,1,16000). I have not changed the settings in your code, and I have tried several INMP441 Mics with same result.
Attached is a sample of the output with me counting and silent background. Any suggestions would be appreciated!
COM6_2024_03_27.11.12.03.309.txt

[biemster]

I'm not sure what VS Code is doing in the terminal, but you need to convert the hex in the log to bytes. I use xxd -r -p for that as you could read in the code, but some python like the following should work too:

#!/usr/bin/env python
audiobuf = bytearray()
with open('COM6_2024_03_27.11.12.03.309.txt') as f:
	for line in f:
		audiobuf += bytes.fromhex(line)

with open('counting.wav', 'wb') as f:
	f.write(audiobuf)

When I tried either xxd or the above code I did not get any audible sound though, although it seems that there is something happening through the noise.

[biemster]

It's been a while since I worked on this, and my tests are on a since then decommissioned machine.

[jimtal001]

Thanks for your help. Just for reference I verified my mics are good by running Arduino code to record audio to SD card and replayed the audio on my PC as wav file. Speech quality was good. I noticed that you have the setting for STEREO, I tried MONO, with same results. From what I can understand in your code, the output (individual line in log file) sent to the terminal should be a 32 bit *signed* integer in hex format or do I need to combine four of the 8 bit hex values to get the 32 bit value? Jim

…

On Wed, Mar 27, 2024, 13:40 biemster ***@***.***> wrote: It's been a while since I worked on this, and my tests are on a since then decommissioned machine. — Reply to this email directly, view it on GitHub <#2 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB5LB7XGA5KALUVSDDERJFTY2MABLAVCNFSM6AAAAABFK6E4DWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMRTGY4DANJZGI> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[biemster]

I'm not sure what's the issue on your side. I've captured a small log from the serial port:
hijim.log

and when I convert that with the bit of python I wrote above I can play the resulting wav file using aplay jim.wav -r 16000 -c1 -fS32_BE just fine.

[jimtal001]

Thanks for helping me and generating the log file. I will use it to understand the data conversion and also dig deeper to find the issue. Best Regards Jim

…

On Wed, Mar 27, 2024 at 4:01 PM biemster ***@***.***> wrote: I'm not sure what's the issue on your side. I've captured a small log from the serial port: hijim.log <https://github.com/biemster/pico-serialmic/files/14781123/hijim.log> and when I convert that with the bit of python I wrote above I can play the resulting wav file using aplay jim.wav -r 16000 -c1 -fS32_BE just fine. — Reply to this email directly, view it on GitHub <#2 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB5LB7S4RRJBEQ7KYXH2UG3Y2MQRDAVCNFSM6AAAAABFK6E4DWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMRTHE4DAOJTGA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[jimtal001]

I have resolved one issue. I changed SCK, WS and SD pins on the Pico W and recording improved significantly for the audio format of MONO format only (one I2S microphone connected). Perhaps I was getting interference on the pins from the WIFI module???

Next Issue: To play the audio clearly (recorded at 16K Hz) I have to set the wav file rate to 8K Hz.

• Important Observation -
• Recording 10 seconds of audio results in approximately 1/2 the expected number of samples, i.e. I expect to receive ~ 10*16000 samples but I end up with ~1/2 that number. Perhaps its serial related???

A log file is attached for ~10+ sec recording. The log file is of signed integer 32 samples.
Also, I've attached some python code (plot_raw.txt) which plots the audio and produces a wav file for this data. Maybe it would be useful?

Settings: Format=MONO (single I2S microphone connected), BPS=32, RATE=16000.

COM6_2024_03_29.07.20.59.705_mono_10sec.txt

plot_raw.txt