I am encontering some problems using the i2s interface and wanted ask a few questions hoping someone could help me out. I am using the Jetson Orin Nano Devkit.
I am attempting to acquire data from a custom ICS52000 MEMS microphone array. I have checked the signals around the array’s PCB and everything seems to be working properly. Either way, the questions I had are regarding the interface configuration. As stated in the datasheet, the microphone outputs 24-bit frames, so I used the following commads to configure the interface after enabling the interface using jetson-io.py.
But when inputting the .wav file into audacity and configuring the input as 24-bit PCM I only get noise. I am unsure if the interface is configured properly. The questions I have are the following:
I assume I have to manually (with some code) unpad the data (from S32_LE to 24) (?)
Is there a recommended library to acquire the data directly from code instead using arecord?
Is my configuration correct according to the interface of the MEMS microphones? I have followed Audio Setup and Development with the following reasoning:
amixer -c APE cset name="ADMAIF1 Mux" I2S2
amixer -c APE cset name="I2S2 codec master mode" "cbs-cfs": configure as frame slave as explained in the " Multi-Channel (TDM) Capture" example in the docs linked above.
amixer -c APE cset name="I2S2 Client Channels" 5: number of microphones
amixer -c APE cset name="I2S2 Client Channels" 5: number of microphones
amixer -c APE cset name="I2S2 codec frame mode" "dsp-a": the datasheet explains that the interface needs a one cycle delay for the frame sync pulse, correctly working as tested with an osc note that the ringing and bad clock quality is due to bad meassurement techniques, I probed it later with appropiate technique and grounding and the signal is far more square, the image is to demonstrate the sync pulse properly aligns as configured. Also the image might not correspond to the number of mics and sampling frequency selected since I dont remember the configuration of the other params at the time of the capture.
amixer -c APE cset name="I2S2 FSYNC width" 300: pseudo-arbitrary selected to be able to visualize correctly.
* arecord -D hw:APE,0 -c 5 -r 16000 -f S32_LE -d 10 test4.wav
Thanks for your answer. I have localized an error in the interface I am trying to solve with some further configuration, it should be done by the end of the week. I will post my progress then. Regarding your comments, yes, I tried to open as 32 bit as well as 24 bit PCM (which is the supposed format). Below is the .wav file inside a .zip since the format is not supported in the forum. In any case its not very useful at the moment since I have to tackle the issue mentioned above.
I have fixed the commented issues (due to driving power problems), now this is fixed, I made sure the drivers have enough bandwidth and driving strength (including the data line). Im still having some problems regarding the data acquisition and I have some hints the problem might be in the interface configuration.
At the moment I don’t have a fancy oscilloscope, but if further debugging is needed I can try to get better captures. As you can see the clock has a nice shape and the WS/FS pulse rises in the falling edge of a clock cycle as requested in the datasheet (see my OP).
as you can see I have 6 mono channels. Below are the main questions/comments I have:
I have checked that the WS/FS/TDM pulse is being propagated with the appropiate time delay by each microphone.
I have (to the best of my ability with the tools I have at hand) checked that there is data at all times in the SD bus/line, but I am unable to check it’s correctness in the oscilloscope.
I am able to record the first channel with acceptable quality, but the second and third are just garbage and the rest are completely empty, while the hardware might be the one to blame, I have tested other platforms and I have simmilar issues; only being able to correclty acquire some channels.
Although it might be to small to see with a naked eye, I can’t see differences when changing the FSYNC width parameter.
The microphone datasheet asks for some delay between the first clock cycles and the first synchronization (WS/FS/TDM) pusle, while I dont think this is strictly necessary to record data in the long run (posterior cycles) it might solve the problem, however I dont know how to implement this delay directly. Is there a way I can force some delay between the first FS pusle and the first clock cycle?
