I2S Pins and Registers

[lrdewaal]

The page for the ADC has great explanation and an example on how to interact with the ADC.
There is however absolutely nothing available on how to use the I2S pins, nor what registers to use to do it yourself. I want to attach an I2S MEMS Microphone (SPH0645) to the XU4,
but find myself unable to achieve this as there is no documentation on how to use the I2S pins. Any help would be greatly appreciated!

[mctom]

Hi,
I don't think XU4 has I2S input, just output.

[lrdewaal]

Hi,
I don't think XU4 has I2S input, just output.

That would be very unfortunate, essentially this limits the user to analog mics using the ADC or USB mics?

[mctom]

Well, I admit I haven't heard of anyone needing an I2S input on an SBC before.
Yes, I guess those are the two options that you have. ADC is only 10 bit as far as I can remember so it's not suitable for high fidelity audio input either. And sampling jitter will be a serious issue.

You can use any sound adapter via USB, even higher end equipment. Unless your point is to have it compact.

What are you building?

[lrdewaal]

I am working on a data-collecting drone, and in particular I wanted to attach a microphone to be able to collect wildlife audio after the drone had landed, so compactness and low-power is indeed a requirement.
Im circumventing the I2S issue by using an analog microphone (SPU041LR5H) and the ADC. And while the ADC claims to be able to reach 600 ksps (kilo samples per second??) = 600 KHz sampling,
I can get up to about 116 KHz only. I adapted the ADC C-code example to use a single ADC channel.
The audio doesn't need to be high fidelity, but it does need high sampling fequencies to be able to record sounds from eg. bats.

[mctom]

Ah! Very interesting!

Well I fear you may have gotten a few things wrong already.
First of all, XU4 is not really a low power machine - mind you, it has a cooling fan on it for a reason. You could have picked something different for your project, such as C4 or N2L. The latter also has a fan on it, but you could configure it for low power operation so the fan would not be needed anymore. I mean, yeah, you could do the same with XU4 too...
XU4 also has 1.8V logic level pins, which is generally hard to interface with anything, unless you got a shifter shield for it.

Secondly, since you want to record ultrasonic sounds, no typical audio interface would work anyway - I2S, or analog audio, they are typically limited to 48kHz, or 192kHz in some high end audiophile scams.

Your mic is characterized only up to 80kHz - I thought bats are higher pitched than that?

I believe this code may be optimized to achieve higher sampling rate. Everything that is inside the while() loop can be precalculated instead of doing it every time, for example. The process may run with negative niceness, and so on.
But then again, you must be forgetting these samples are not guaranteed to be equally spaced in time - you'll get a ton of nasty artifacts which will render your recordings useless.

If I were doing this project, I would definitely look into using an external 300kHz ADC with parallel output, provide a steady clock from SBC (PWM output would be fine), and read data from it using a lot of GPIOs, preferably from a single bank, so they could be accessed with a single memory read.

Most ODROIDs are able to work with GPIOs well above 10MHz - see here: viewtopic.php?f=215&t=45507&p=357803&hi ... le#p357803
Can't say the same about XU4 because I haven't tried it.

[odroid]

The maximum speed of the I2S interface in the Exynos SoC is limited at 96KHz for 24bit hifi audio applications.
It seems to be quite far from your target sample rate.

[lrdewaal]

Thank you for your reply!

First of all, XU4 is not really a low power machine - mind you, it has a cooling fan on it for a reason.

I had no choice in the board, someone else on the team decided on the board to use for the drone control software (which is using some advanced techniques with ML and AI so it needs the processing power). So if I can save any power I should, to preserve flight time.

XU4 also has 1.8V logic level pins, which is generally hard to interface with anything, unless you got a shifter shield for it.

Yeah I noticed this too, the mic functions now but the gain is now extremely low.

Your mic is characterized only up to 80kHz - I thought bats are higher pitched than that?

It depends on the species, many produce echolocation calls around 40-50 KHz meaning a sampling rate of 100 KHz would already catch quite a lot. The frequency response curve from the datasheet goes up to 80 KHz but the microphone is able to handle higher sampling rates, though with its drawbacks (aliasing, distortion, etc etc). An example is the TeensyBat project which uses it with sampling rates up to 384 KHz. I am simply aiming for a sample rate as high as possible, and if its above 100 KHz bats should be "audible".

But then again, you must be forgetting these samples are not guaranteed to be equally spaced in time - you'll get a ton of nasty artifacts which will render your recordings useless.

Yeah I thought of this as well. I did some tests but the sampling rate stays fairly constant around 116 KHz (measured using the linux realtime clocks so take the accuracy of this number as you will).
Using some simple sound generator doing a sweep it manages to record things albeit not if the noises are too soft.

If I were doing this project, I would definitely look into using an external 300kHz ADC with parallel output

Yeah I've been thinking about this too, since the Odroid ADC is not only noisy and not capable of maintaining high sampling rates reliably, but the samples are only 12 bits which could be a lot better.
Time is not on my side and I need to deliver a working piece of hardware and software by next week to my teammate.

Are there any ADC components you could recommend? It may not be possible for me to buy and implement it in time, but I find this topic interesting regardless and would like to try it out.

[mctom]

Yeah I noticed this too, the mic functions now but the gain is now extremely low.

Turn up the preamp's gain then. You did implement a preamp, right? That's what the mic's datasheet said, IIRC.

So if I can save any power I should, to preserve flight time.

CPU underclocking is the answer. It really is a game changer. Also you may want to disable LAN.

Are there any ADC components you could recommend?

I visited mouser.com, went into ADC section, and filtered them accordingly:
Output type - parallel
Analog and digital voltages - 1.8V (or ranges including 1.8V)
Sampling rate - above 300kHz
Resolution - 12 bit or more

Here's the cheapest one:
https://www.mouser.pl/ProductDetail/Ana ... zRbg%3D%3D
And this price explains why you're so unhappy with ADC built into Samsung Exynos mobile phone SoC.

You could mount it on a QFN breakout board and connect to XU4 directly with wires. No level shifting involved as it works at 1.8V no problem.
It supports at least 20MSps, but you may not be able to capture that data so quick with raw GPIO. That's not their intended purpose after all.

since the Odroid ADC is not only noisy and not capable of maintaining high sampling rates reliably,

So I'm guessing you already have optimized your code?
I would try adjusting C_TIME so you average two consecutive samples. The maximum sampling rate will still be 300kHz, but the noise floor will drop by a few dB.

Time is not on my side and I need to deliver a working piece of hardware and software by next week to my teammate.

I'm sorry to hear you were made into doing a scientific project in one week. The task is not trivial and I'd definitely bring that into the attention of the team manager or leader.
Seriously, downplaying the complexity of electronics engineering is the worst.

But yes, given everything you've said so far I would do the following:
- Find out why the input signal amplitude is so low (if you could present the schematics I think I can help)
- Maximize ADC sampling rate by optimizing the code for the fastest execution possible

[mad_ady]

If running time-sensitive code, make sure to pin it to the big cores and use pefformance governor. This reduces scheduling variability.