[sdiy] AfterTouch - adding to Fatar synth Keybed ?

[rsdio at audiobanshee.com]

On Apr 6, 2016, at 3:22 PM, sleepy_dog at gmx.de wrote:
>> One thing is that they use analog multiplexor chips and a single ADC. So, you shouldn't really focus on processors with 32 ADC channels, or even processors with internal ADC. Quite often, custom designs like touch sensitivity might require an external ADC and mux. It's usually better to have the ADC chip on the same board as the sensors, so they share the exact same ground reference for lowest noise. Then use serial interconnects between boards to bring the data back to the main processor. Once you do that, it doesn't matter how many on-board ADC channels your MCU has.
> 
> well, it does not seem to be a restriction to use MCUs with 16..32 ADC channels, ST's ARM MCUs is throwing it at you for cheap.

No, it's not a restriction, but MCU chip packages with 32 ADC pins along with everything else usually cost a lot more than packages with only 18 pins total! When using the cheapest, smallest package, there simply aren't enough pins for that many ADC mux inputs. My point was that you shouldn't get tied down in selecting the MCU based upon the number of ADC channels, because you can generally get better performance with external ADC and mux options.


> I could do all that - keep them physically close to the action. For non-mass producing, MCUs that cost 2...3,- EUR where I need maybe 2..4 of them - or spread it out further and have it even closer with a greater number of smaller/cheaper MCUs with fewer channels, it doesn't make a difference. At least external ADCs I know aren't cheaper than such an MCU, not significantly anyway (speaking non-mass-producing).

The Microchip MCP3008 is only US$1.66 in the quantities that I can buy, and that's cheaper than a second MCU. Without repeating my comments about writing additional firmware, it's easier to add an ADC than add a MCU.


> So perhaps there is not really a point to have a dedicated ADC unless it has properties that would be really beneficial compared to using a bunch of MCUs?

True. There's nothing particularly wrong with an MCU that's on the same board as the analog signals being measured. However, ADC units that are inside an MCU package generally have more noise because of all the digital signals inside. An external ADC can get a lot better noise performance.


> I guess if something like anti-alias filter would be necessary in this setup, for every ADC channel, this looks different - but perhaps fingers modulating voice volume is not nearly as sensitive as introducing high energy audio rate alias into an audio signal? But if the MCU has enough power to scan its channels at a much higher rate than the finger movements, alias may not be a problem, I guess.

Scanning at a higher rate doesn't solve the aliasing problem. You have to have a low-pass filter somewhere, and most ADC setups do not have any filtering. High sample rates do allow you to have a simpler, lower-order low-pass filter than low sample rates. If your sensor already has bandwidth limits, an additional aliasing filter may not be necessary.


> I at least know that the switching of the internal ADCs works well enough, and that, if I do it myself with analog mux ICs, I might easily introduce switching noise / need to research more to properly guard against that, I guess.
> 
> Steve

Switching noise generally dies down after a fixed amount of time. So long as your firmware times the ADC operation so that it starts after the mux noise is finished, you're good. Note that internal MCU mux features for ADC still have the same switching noise, and there are usually constraints on how soon you can use the ADC after switching the channel. In other words, on-board peripherals do not automatically solve this issue for you.


>> The Ensoniq design even has a slave processor on the keyboard itself, which isn't a bad idea considering the complexity of poly-aftertouch.
>> 
>> I predict that the biggest challenge for polyphonic aftertouch would be calibration. Your hand-made solution will probably not be identical for every key, but if you can calibrate then that won't matter. The Ensoniq keyboards announce that the user should not touch the keyboard every time it is turned on, so that the system can calibrate the sensors.
> Yeah I had that problem in the back of my head, but not thought about it further. I'd store calibration data in the internal flash of the MCU(s). But perhaps having to record some correcting curve for every single key (say, if I can't get sensor plate size & position exactly the same for every key) sounds like quite a pain.
> I don't remember capacitor physics well enough, perhaps the function of proximity vs. capacitance has same curve *shape* even for differently sized & oriented plates, just the extreme values different? That would be easier then.

Capacitance is a complicated formula involving multiple variables like dielectric, area, and distance between the plates. However, if your design only varies the distance, then you can calibrate all sensors in the "key up" position and not need any further calibration. Distance is the only variable in the denominator of the formula for capacitance, so if it's the only variable changing then you have a simple calibration. As long as distance is linear, and not some double-hinged piano hammer remote extension soft of thing, you should be golden. If the area of the capacitive plates is changing, or the dielectric, then you'd have multiple variable changes and you might need multiple calibration points. It's probably easy to avoid that situation, though.

Brian Willoughby
Sound Consulting