I’m getting some problems when setting up a CD4051B multiplexer with 8 pots for a custom test cirtcuit of mine. I’ve quite some crosstalk from one channel to the next. It’s ok when those channels are for example volumes, but for a frequency pot, the previous read can influence the frequency pot read by something like a semi-tone when the pot is log-mapped over 20-10kHz for a frequency at around 500Hz.
We don’t have the BOM for the Daisy Field, but I guess it’s a CD4051B as well, and given the low power supply of 3V3, there should be a RON of around 500Ω, which for reasons I don’t fully understand for now, maybe because of some equivalent parasite capacitance of the ADC thus forming a RC filter, could make bad readings, that is the current reading is influenced by the tension of the previous reading.
Is this something the Daisy Field is also suffering from? Looking at the forum, it doesn’t seem at all, so I was wondering what could be wrong in my design.
My design is hosted here:
(I’ve removed the 1n cap to get to the semi-tone result, before it was even worse)
I had hoped that you would have received a response by now from someone with more Daisy experience than me. I don’t understand the software, but I do understand muxed ADC’s in microcontrollers.
It sounds to me like it is a settling time issue between setting the mux channel (both the 4051 and the internal mux) and the actual sampling for conversion. (The input capacitance of the ADC input is charged through the series resistance of the internal and external muxes. It needs several time-constants to wipe out the residual charge from the previous conversion in order to eliminate the crosstalk, down to the full precision of the ADC.)
That timing is probably buried somewhere in the layers of abstraction in the Daisy libraries. Since you are talking about quite a small crosstalk error, it may just be an oversight, since as you say, these analog inputs are mostly used for less precise controls like volume. Someone with actual Field hardware could easily try to replicate your results.
Bottom line, I don’t think it is your hardware. But I don’t know the software well enough to advise how to fix the problem.
Raphael, I should also mention that the RC time constant charging the ADC capacitance includes the resistance of the source connected to your external mux. If it is simply a pot, it will add the parallel combination of the two resistances of the the voltage divider. This is the case on the Patch schematic. So the added series resistance of a 10K pot will vary from 5K in the middle of rotation, to zero at either extreme.
Try placing your 1nF cap on the input of the 4051 mux, rather than the on its output. It might help, if not eliminate, the crosstalk error without any software changes.
Thanks so much from your reply. I guess the issue is a mix of software and hardware, and your hardware understanding (that I don’t have) can totally benefit my project.
So I copied my design from Mutable Instruments Tides, which is a quite renowed name in the music modular system projects. Still, the software set-up might be different, and I need to understand that as well.
In Mutable Instruments design, they have 100n caps on pots, pots connect to the multiplexer, and finally there is this 1n cap at the output of the mux. I just copied that, with not enough understanding. I’m a software engineer. Hardware engineering is another beast, that I’m trying to learn. My eurorack-blocks project is about learning (with me as the first student).
So coming back to the point, I was kinda of seeing the 4051 as with an ideal infinite impedance. So meaning the 100n cap between ground and the cursor on the pot would just filter out noise on those pots, but from what I understand, I should consider the full circuit somehow, and you are suggesting is that I can’t consider the 100n cap on the pot at the input of the mux as an influence somehow on reading other input channels?
One thing on the software side, I was thinking about, was: I’m not sure how it is working for now with a mux, but it seems there is a 32x oversampling, which probably means that the first sample is read really early. If I have already filtering on the hardware side, maybe that makes more sense to not have oversampling, and thus the value could be read far off when the address is set on the multiplexer. Just thinking out loud, I need to study that.
I can try to recreate what you’re experiencing on the Daisy Field I have here sometime this week. I haven’t personally experienced this, but I have also generally had much smaller frequency ranges mapped to the knobs (like midi notes 12-72 or so). So it could be something that’s just evaded my attention.
Depending on when you got started with libDaisy you might double check that you’re up to date on the latest code. I did rework the way the Mux ADCs are handled a month or two ago to be a bit more reliable after experiencing some issues (mostly to do with optimization causing issues, basically not strobing the GPIOs correctly which was causing noise-like reads that was essentially from a random channel every read).
The latest code resets the GPIO before starting up the ADC again. So as long as the settling time is sufficient you should be getting decent reads. The oversampling amount is also configurable. So you might try reducing that to see if that confirms you suspicions.
Once I’ve had a chance to run a comparable test on my Field I’ll have a bit more to say on the matter.
@shensley That sounds great! I have libdaisy as a git submodule dependency, and it looks at least I should first update it, and then look more into the options.
I’ll try that and report back. Thanks for the update!
I also will be interested in what @shensley finds about the Patch hardware. But, if you have 100n on all pots and 1n on the mux output, it will behave differently than the Patch, which has no caps on either side of the mux.
What will happen on your hardware is this: Immediately after the select lines on the 4051 are changed, the voltage from the previous channel still in the 1n cap will charge-share with the voltage on the 100n cap on the new channel pot through the 500ohm on-resistance of the switch. This will quickly introduce a one percent error in the voltage you want to measure. That time-constant is about 0.5us. Then that error is reduced as the pot resistance recharges the 100n cap to its proper value. This time constant is as high as 500us, depending on the position of the pot, if my math is correct. (.1uF * 5000ohm = 500us)
If the ADC sampling takes place after (or while) this charge-sharing happens, but before it has corrected itself, then the converted value will still exhibit some previous channel crosstalk. This tells me that you should nix the 1n cap on the mux output and keep the 100n cap on the pots. It would be better to do a some low-pass filtering on the converted value in software IMO.
So for now this is the setting I have, I removed the 1n cap and kept the 100n ones on the pots.
As you said, this really suggest I should investigate more on the software side of things.
I’ll report here, when I can understand more what’s going on, on the software part.
I took the time to look and the ADC electrical characteristics in the processor data sheet. Here are some snippets of the relevant section below. You are doing the right thing by keeping the impedance low with the 100n caps on pots.
@raf, I don’t think you have to dive into the sampling rate table just yet. I am sure that @shensley will tell you what is set in the default code in the libraries, and if you need/can to do anything different in your code.
TBH, I am trying to be as helpful as I can be on the stuff where I can contribute, because I am being kind of a dick elsewhere about my struggles with the development tools and documentation.
