Input resistance/impedance of GPIOs in AnalogIn Mode?

#1

Hi there,

I hope some hardware specialists are still around here.
I am planning to use some of the GPIO analog ins as low frequency / band width <<1,5kHz audio ins. The frequency limitation is no problem.
Of course, I would put some second order LP-filters in front of the GPIO in order to avoid aliasing. I suppose 3kHz is the respective sampling rate.
Thus, I have a few questions.

  • Does this seen feasible at all? I plan to use 6 additional low frequency (but audio) ins.
  • What is the input impedance in analog-in mode? I suppose roughly 100k, according to this thread. https://sebiik.github.io/community.axoloti.com.backup/t/what-is-the-adc-input-impedance-for-connecting-sensors/1773/4. Correct?
  • Are the GPIOs biased to a certain voltage level, e.g. VDDA/2? Could this be done by software, or just simply do the biasing by two resistors?
  • I plan to protect the GPIO ins by simply using antiparallel NIR IR LEDs with 850nm wavelength. They have a suitable forward voltage of around roughly 1,45V, connected against a capacitor buffered VDDA/2 voltage. Feasible solution?
    (Of course I could also use a 1/4 MPC6004 OPA per input, but I like the idea ...)

Thanks in advance!

#2

Feasible yes but it's going to sound twice as "bad" as a narrowband telephone. Which may be what you want.

Not sure even though I worked with the STM32F4 datasheet and reference manual a lot, but if the master himself writes it it must be true.

They're not biased. Biasing using two resistors usually is a solution though not very stable.

Not sure, this is beyond my skills.

All of this sounds like a lot of work with quite some side effects to achieve something that would be stable and predictable with some MCP600x? I don't know really.

#3

Thank you, Sebastian!

I already simulated the below 1,5kHz for my application by some high order LPFs, and it seems to be sufficient.

I will most probably use some MCP600x. Currently I'd like to use them only for getting a higher input impedance for external sensors.
Or also a second stage of MPCs for a Sallen-Key LP for the anti-aliasing.
What ist the typical frequency I should choose for the filter, just half of the sampling frequency or even less?
Or even a higher order than the 2 of the Sallen-Key?

I would also like to model the schematic in SPICE. However, I am not sure, how to model the input audio signals.
Could I import sample tables into SPICE?

Any additional hints or comments?

#4

If you have a 2-pole Sallen-Key this should be sufficient. I am guessing you'll have aliasing but it would not be bad-sounding. At this sample rate anything will be crunchy really?

Not sure seems like SPICE is not made for this. Falstad circuitjs is basic but does have some "audio" functions and FFT. Do you want to simulate inputs? Then a sawtooth wave should be just fine, change the frequency between some points you consider useful and look at the results

#5

The thing that would worry me in this scenario, apart from the limited bandwidth, is that it will be hard to get exact timing of the sampling point of the GPIO pins. Normally an audio ADC is driven by some form of stable clock, and the digital output is then buffered in such a way that the CPU access the data in bursts (in the Axoloti case 16 samples). But the point I'm trying to make is that the actual point in time where the sample is taken is very accurately controlled by the clock supplied to the ADC chip. But if you're sampling GPIO pins using the CPU, the timing will essentially depend on various interrupt latencies and delays in the code path which will result in the sampling point jittering quite severely, resulting in noticeable artifacts in the sound.

#6

Thanks ricard! That's a thought I suppressed up to now :slight_smile:
I wonder, how much relativ or absolute jitter I should expect here.

So as far as I roughly remember, the order of code execution depends on the position of the modules in the GUI.
If I would try to position them smarlty, and maybe, "write code" that is time-wise quite "linear", could it help?

I maybe just give it a try and hear what it sounds like.

I suppose a relative jitter of let's say 10% would also shift frequencies accordingly. Of course, it would also change the waveform's shape. Or depending on the point of view, bring in some higher frequency noise that is actually not present.

I suppose, this approach would suffer from the same potential problem, or doesn't it?

#7

Yes, the further to the top left of patch an object is located, the earlier it is run, which would help, but there's still the actual latency from the time the timer interrupt hits until the interrupt routine starts its execution, and there are also other things that the Axo OS does before calling the user code, which might vary in execution time, I don't know.

But do give it a try. Normally you don't need a lot of latency to degrade the audio, but your sampling rate is also pretty low, so perhaps it will be acceptable.

The reference to the other thread, were you specifically referring to setting up a specific timer interrupt and associated thread in order to get more accurate sampling intervals, or hooking into the Axo DSP thread? I think that that would be an improvement over having it in the patcher, but I still think there will be quite a lot of jitter.