ADC Pad Aliasing
Closed this issue · 11 comments
I'm testing out the pad ADC data, just using the example code that lights up the pads in response to pressure. I noticed while pressing a pad, another pad will light up slightly. It's always the pad 4 rows above, wrapping around to the next column if necessary. Is this a software bug or some hardware issue?
@dvhdr Any input on this? I noticed it's the sensor at index + 1 that's lighting up, which explains why it's the pad 4 rows above instead of an adjacent pad. Is this just a product of how the sensors are wired together? Like some kind of voltage sag that's causing the increase in measured signal on the pad at the next index? If it's a physical limitation I can try to write some alias removal code that finds the highest valued sensor and then subtracts a percentage of its signal from the sensor at index + 1, and so on for the rest of the pads. But it'd be nice to avoid that if it's an issue with how the HAL does the ADC scanning.
I noticed the same thing, initially wondering if it was crosstalk, and thought about a similar approach to what you've outlined. However, I later realized that the MCU being used has two ADCs and so now I'm figuring this is related to multiplexing the 64 pads through those two ADCs. At the firmware level I'd expect that the ADC readings along with knowledge of which pads are currently being scanned (multiplexed) would eliminate what we're seeing, so short of a bug in the code mapping these to the array that is exposed to us via the API I'm still at a bit of a loss.
Sorry we've been quiet on this one. I've reproduced it (and fixed my pressure->colour code in doing so). I'm awaiting a chat with of one of the original engineers to discuss - it's been a while!
Awesome! Thanks for continuing to drive this stuff forward.
Any further updates on this?
@dvhdr @whibble @joefocusrite -- Can we please get a status update? I get the feeling that this project has been abandoned, but it would be good to know Novation's intentions. I purchased the Launchpad Pro and found it to be totally unusable for my primary requirement as a synth controller due to pad sensitivity and premature note-off events. In hindsight I should have just got my money back immediately, but the open firmware looked promising as a way to workaround such shortcomings, so I waited (beyond the purchase return window). After a ton of playing with the firmware, I'm no longer confident that sensitivity can be meaningfully adjusted, but I won't know for certain until the aliasing issue is fixed (which sounds like the fix has been pending commit since Jan 31). It's going to be really disappointing if this hardware is useless to me, especially with the time invested in experimenting with fixes via the firmware.
I'm working on this now. We've made a bit of progress, though nothing we can share just yet.
OK, this is improved, but reveals another issue. Check out the https://github.com/dvhdr/launchpad-pro/tree/adc-improvements branch. We've increased the sample time between ADC channels, which was the cause of the crosstalk reported in this case. The result is much less noise and no crosstalk, which is nice. The risk is that it may subtly change the feel of your Launchpad.
There is another issue - noise on some pads - that I'll create a separate case for.