A DIY hybrid piano without ADCs (purely digital sensors)

Great news! As of Pico SDK version 2.1.1 rp2040 has been certified to run at 200mhz!

RP2040 has now been certified to run at a system clock of 200Mhz when using a regulator voltage of at least 1.15 volts.

With this version of the SDK, you can now select a 200Mhz clock for RP2040 simply by setting SYS_CLK_MHZ=200 via preprocessor define. The regulator voltage will automatically be raised for you if necessary.

https://github.com/raspberrypi/pico-sdk/releases/tag/2.1.1

Easy 60% perf gain for nothing! This isn't an speculative overclock either, it's in spec now! This apparently came along with release of the new rp2350.

Seems to works perfectly on the yd-2040 boards, I also had a typo earlier, these boards come with 4mbytes of QSPI flash (32mbit) or 16mbytes of flash(128mbit). Original pico boards have 2mbytes(16mbit) of flash. Not that there's any real use for that much flash memory most of the time, certainly not in a MIDI controller.

Speaking of megabytes, Yamaha P-120 (released in 2002) had total wave rom size of just 32mbytes (for the whole instrument, includes other sounds, not just piano). Yamaha P-515 (released in 2018, 16 years later) had a total rom size of 256mbytes. Yamaha P-525 (released in 2023, 5 years later) has total rom size of..... unspecified amount (for obvious reasons)....

Thanks for the update.

DavisB Retiring sensor strip from my old narrow key

DavisB All wiring in this design can be completely eliminated by combining all 11pcbs * 88mm * 25mm into one 968mm* ~ 50mm PCB

Are you retiring the old ones to replace them with consolidated large ones? Or some other reasons? Are you still working with the slit-sensors? I never tried those myself, but I always thought that the calibration and/or tolerances would be very tough for a DIY project, so I discarded them to begin with. I'm interested to learn your experience with them, if you are willing to share.

DavisB I bought ten of these yd-2040 boards

DavisB each cost around ~ 1.1eur each (including shipping)!

Where did you buy them from?

DavisB At first I was slightly concerned that rp2040 is too weak for this task, but it is absolutely not.

Agreed, it is a very nice little chip. It does have its warts, though, for example this one. If you can stay away from such problems (and for some things I could not), it works great.

DavisB release of the new rp2350.

FWIW, for my "random" projects I switched to this new one (on the official Raspberry board)

I buy these boards from AE (usually when there are major sales (ie. anniversary, blackfriday, 11.11, etc)). There's many stores that sell boards based on yd2040 design such as (https://www.tztstore.com/goods/show-6203.html ).

There are many storefronts that are operated by TZT (or use the same warehouse and sources). Prices sometimes go pretty low.

For regular people I strongly recommend sticking with more reputable sources (LCSC for parts, and for devboards & swd probes WeActStudio, etc). While everything I've ordered pretty much always works for me. Huaqiangbei markets aren't exactly like ordering from Mouser...

Random local small EMS houses make those yd2040, so different batches will have different flash, different silkscreen quality... ie. they lack the consistency and quality you'd get from WeActStudio and similar.

These 0.96"/1.3" inch mono OLEDs are my favorites and along with those 2.8" 240x320 ST7789V SPI color LCDs (as little €2-3 a piece on sale) I stock them and treat them like generic jelly bean parts.

Re: I2C.

There's a comment in Pico SDK "i2c_write_blocking_internal" implementation that says the following:

A lot of things could have just happened due to the ingenious and creative design of I2C. Try to figure things out.

Emphasis mine. My understanding is that I2C is one of those deceptively "simple" things, that are best to be avoided whenever possible?

Hardware designers get it wrong. Module and I2C device designers get it wrong. SDK developers get it wrong.
The user (software developer) might get it wrong. Is it a 7 bit or 8 bit address, so does it have to be shifted or not, etc?
There are no built in timeout, the bus can hang, all sorts of stuff can happen.

If you put multiple such devices on a bus... it ends up being complicated. Even if you stick to the letter of the spec, there's no guarantee that everyone else will and well... (and then you put circuitry to just power cycle things... etc, not pretty)

There's also a version of i2c that fixes some of the issues called SMBus.

Sometimes you can't avoid I2C and there's plenty all sorts of sensor devices that offer I2C interface, etc.
And if there's just basic 1master-1slave write-only or read-only with 1device - like I2C OLED or some sensor - it's probably fine-ish, but otherwise...

Re: RP2350

There's RP2350-E9 Erratum which can only be addressed with a hardware revision. So I'll wait for quite a bit before switching over. (https://community.element14.com/products/raspberry-pi/f/forum/55046/rp2350-gpio-pull-down-latching-bug/223658)

Most issues with RP2040 are either known (the ADC issues as per errata RP2040-E11) and/or are addressed via hardware revisions (all rp2040 are on B2 I think) and well documented by this point.

Kind of like with the classic ubiquitous STM32F103.
The errata is massive, here's the portion just for the i2c:

Some early experiments & evaluation of using SBCs as romplers (in this case Radxa Rock2f, around 15eur to BOM + 5-6eur microsd) and SPI st7789v screen (2 eur bom)

(using https://github.com/torvalds/linux/blob/master/drivers/staging/fbtft/fb_st7789v.c kernel driver, which exposes 320x240 framebuffer as /dev/fb0, the kernel module had to be recompilled with a slight modification to invert the colors - other than that it works well!

OpenGLES using hardware acceleration KMS/DRM (without requiring desktop environment, etc), the rendered scene is red using glReadPixels and sent to /dev/fb0 - which is far from optimal, but even still this simple glxgears type scene (modified kmscube) gives around 440 fps. Ie. it should be plenty good for rendering UI.

Looks like noise, but its 10000 x (size:16x16) software-rendered sprites bouncing about at stable 60fps. (one A53 core out of four utilized). My phone makes the screen look way worse than it looks in person.

Notable part is how the SoC doesn't even heat up or require a heatsink even under moderate loads at 2ghz and hangs around at 45-50C.

The crucial part of course is - whether there's a good low-level kernel API for very low latency audio, and if it can be easily attuned to this very purpose, and if Soc is powerful enough for reliably mixing 64-128 sound polyphony + convolution reverb + some basic resonance modelling in time + streaming samples from microSD into 1-2 GB of ram... (initial impressions - it absolutely should be)

Dexibell series use Arm SoCs for their instruments (and I think there were one or two other DP models that do).
I think this is the way forward as far as retail DP rompler hardware go. The Arm Cortex-A53 quadcore (Rockchip 3528) SoC is <5eur to BOM in volume (plus you need some LPDDR4).

Apparently there's an upcoming new tariff in EU (starting from 1st of July) for small parcels which is likely going to significantly increase costs of prototyping (+3eur per item type/tax code, not package!)

So I presume this means every JLCPCB order will be +3eur tax, and if you order - say 100eur worth of components from LCSC you will pay 3eur per item type (package contains resistors +3eur, caps +3eur, connectors +3eur, MCUs +3eur, leds +3eur, ferrite beads +3eur, esd-diodes +3eur, usb connectors +3eur, etc, etc)

I really hope I'm just misunderstanding it, and this applies to neither LCSC nor JLCPCB, but I'm not sure...

Needless to say, it's a great time to build and play around with new sensorboard designs and hoard parts (LCSC has shipping discount till 30th April!), before the DIY hobbies doesn't double or triple in price. DIY hobbies, like custom DP builds and similar are super reliant on imports from China (including, but not limited to AliExpress). And they involve hundreds of different parts - many of which individually don't cost much.

Say, 500x 1% resistors in 0603 is 50cents. Or hundred USB connectors (micro USB 3eur, USB C 5eur or so), but if you tack 3eur tax on every item TYPE in a package, this would easily double and triple the total cost for things made in small volume.

Nothing particularly interesting about this design, other than it's super tiny (1mm thin PCB, 18mm in height, compared to 19mm height of low profile ddr3 stick), uses resistor arrays and FFC cables.

4 of these boards with 4 FFC cables into main board makes for a very neat and compact system. (need to cut 1/3 of PCB off with exacto knife for the 4th board so that it's 88sensors instead of 96).

FFC cable could be much smaller (this is 1mm pitch), and has a lots of ground wires in between signals.

It has mounting holes, but the best way to mount this is using double sided tape

New slit board!

This is probably my craziest design yet. This one has no muxing or "scanning" in traditional-sense whatsoever, the board (for 24keys per PCB) has 3 dedicated MCUs each dedicated to sensing any change to any of the 8keys/16sensors and using high resolution timers to detect keypress events above 1 million times a second - which it communicates to main processor.

And all that packed into a board 19mm in height!

But that's not all - you can either chain 4 of those boards with FFC cables into main board (for full 88 key piano), or use one of these boards standalone as a 24key MIDI keyboard (it has a fourth MCU for optional MIDI via USB!), it even has a OLED screen connector (mostly for debugging and testing that all the sensors register though)

The 3 pinheaders are SWD for programming the MCUs!

Other side (those QFN mcus are tiiiny! 5x5 mm for 3 keypress event MCUs and 4x4mm for MIDI USB main mcu!):

This is probably the most high-end sports car like sensing option out there, and the only upgrade I can think of is using Vishay surface mount slitsensors (ie. vishay TCUT1600X01) and some very minor changes...

I still have a soft spot for the utmost simplicity of my previous designs, but for the very best (probably, overkill sensing resolution?), this is the best I could come up with thus far.

DavisB I like the idea of slit sensors, it’s simple and reliable, close to how AvantGrand and Novus work. Is it for hammers, keys, or both? What parts do you mount to the hammers/keys for it to go through the slit? I imagine this to be the tricky part but once done, it’s probably good to go for years.

CyberGene
Just the hammers. And a machined "encoder pattern" is attached to hammers.
This thread was misleadingly named.
All the sensing systems are made for a DIY narrowkey DP/MIDI controller that uses - atleast mechanically - rather traditional DP style action.
So the hammer acts like hammers in DP actions - namely it's rather closely coupled to the key and has no real escapement. (with both all the good and bad it entails...)

The encoder patterns have to be attached at the same distance from the pivot on the hammer (or else the reported speed will be slightly different hammer-to-hammer).
Or if the cut-outs on key-element isn't made accurately it will measure the speed of the hammer at a slightly different level of keydip, etc

That's actually the main reason why I might upgrade to TCUT1600X01, both slit sensors for the key are housed into the same plastic mold, so the distance between slit1 and slit2 would be guaranteed to be even more accurate.

While these sensors do have a locating pin in the PCB, it's slightly oversized and if you're not careful you might solder them it in a way that they are not perfectly same distance from each other (at the end I started using special machined sensor holder element to ensure they get soldered in perfect alignment and positioning, etc)

In preperation of the new EU tariffs that come into effect on 1st July:

8 different PCB designs in 2 months, covers a good chunk of ideas (including some experimental designs) I had in the back of my mind. Not seen in the pic, boxes full of components from LCSC, and all sorts of parts for future DP builds...

One more PCB design box to arrive any day now (if successful this one will upgrade Piano Mainboard from USB1.1 to USB2.0 (mcu with integrated USB2.0 PHY, theoretical max 480mbps), potentially cutting down total MIDI latency from 1ms->125 microseconds.

Details of how exactly this tariff is gonna be applied and what extra handling fees etc will be applied are unclear, but they have potential to double - if not triple - costs for small time DIY builders and hobbyists.

Before this tariff came into effect, thanks to various Chinese ecommerce platforms, you could - in effect - operate as if you're in severely time delayed Shenzhen (typical 2-3 week delivery). That's to say, you could build and source - sometimes very niche - parts for literally ANYTHING you could think of, and do that very, very cost effectively - as long as you planned ahead around the time delay on all deliveries - you could build anything.

Now every little part you order - be it a single transistor or mosfet - from China is going to be slapped with extra +3eur (per item type) + handling fees and who knows what else.

DavisB I’ve missed this and it might be a political issue, and I’ll move it out of this discussion in such case, but what tariffs do you mean, what’s going on? Are there EU tariffs on electronics from China?

CyberGene

Are there EU tariffs on electronics from China?

Anything below 150eur from outside of EU.
So that most likely even includes orders from Mouser(US based) and DigiKey(US based)!

And any Piano Parts, PCBs (you name it) for DIY builds or similar from anywhere outside of EU.

https://www.vatcalc.com/eu/eu-e3-levy-low-value-e-commerce-import-package-july-2026

The EU will introduce an interim flat rate €3 customs duty per item type by customs code in parcels not exceeding €150 imported value from outside the EU from 1 July 2026-28, ending the duty-free treatment for parcels below €150.

This particularly effects electronics, DIY projects of all kinds, and similar things, because they are a sum total of hundreds of different parts - each with low individual cost. Where having a +3eur tariff per item type means potentially adding hundreds of euros on BOM overnight for basically... nothing. It significantly bloats up costs of doing prototypes and one-off experiments.

Although it's original stated intent, from my understanding, is primarily ment to discourage people from flooding customs with many packages with cheap flipflops and sunglasses from Temu and Shein, etc.

DavisB I see, thanks.

DavisB This particularly effects electronics, DIY projects of all kinds, and similar things, because they are a sum total of hundreds of different parts - each with low individual cost. Where having a +3eur tariff per item type means potentially adding hundreds of euros on BOM overnight for basically... nothing. It significantly bloats up costs of doing prototypes and one-off experiments.

That really sucks 🙁 Is it per item? Or you mean, since you might wanna order from different vendors, even if from the same e-commerce website and in one order, it would add-up? If that's the case then that sucks big time!

DavisB Although it's original stated intent, from my understanding, is primarily ment to discourage people from flooding customs with many packages with cheap flipflops and sunglasses from Temu and Shein, etc.

Frankly speaking, I don't get even this intent... Why shouldn't I be able to order cheap Chinese "junk"? Our family has been doing it for years. I believe the merchants that are selling similar stuff locally are just importers that put a heavy surplus.

CyberGene

Per item type in order (+3eur)
Based on HS codes (a resistor, opamp and MCU have different HS codes, so +3x3=9eur extra atleast on paper)
https://www.tariffnumber.com/

Then on November 2026 extra handling fees +2eur (now this is per package I think) and maybe something else on top.

There's just a lot of unknowns regarding how the whole thing will be implemented, collected and taxed exactly (and there might be some extra fees), which is why I premeptively ordered truckton of things I presume my builds will need in close future.

I believe the merchants that are selling similar stuff locally are just importers that put a heavy surplus.

That's more or less how it is. And these platforms allow to go Direct to Customer, sometimes directly from the OEM. Direct from Shenzhen... with a bit of a time delay.

This is just another case of gummint gummint gummint doing what it does worst.

Latest arrival...

Isn't that just a keyboard?
Yes, it uses off-the-shelf Mechanical Keyboard parts (Magnetic Silent Switches (so spring + moving magnet) and standard Keycaps. But it isn't a keyboard!

It's an Isomorphic Velocity Sensitive MIDI controller!

I'm always been curious about isomorphic instruments, they have always seemed like a gimmick, but I've always wanted to try one (including Jankos).

I doubt the velocity sensitivity will be good enough for playing piano music expressively, but maybe this would work as a fun synth with after touch?

I suppose this rides and dies on whether the velocity sensitivity will be "good", and there's just no way to tell without doing an experiment!

Hall Effect sensors are to be soldered on the other side of the PCB (it also has the footprints for USB/MCU, so each one of the pcbs can be a macropad/velocity sensitive MIDI USB device) and they are compatible with FFC cable pinout I use for Piano Mainboard (the analog sensor version) for traditional 88key piano.

Full size Isomorphic instruments like Lumatone use whopping 280 buttons, so almost 2.8x amount seen in the pic, but 100 buttons will do for an experiment!

Hi DavisB,

I hope you’re doing well!

I’ve been following your work on the forums and really admire your expertise in hardware design and high-speed MCU implementations. I'm looking to design an economic, high-performance PCB system to scan piano keys in modular groups of 12.

Based on my initial research, I’m planning to use MagnTek’s MT8901AT dual-latch Hall effect sensors paired with a WCH CH569 microcontroller to handle the high-speed processing.

I’d love to hear your thoughts on this approach.

Thanks so much for your time and all your contributions to the community.

CH569W is 6.2eur at 10qty from LCSC.

It has gigabit ethernet and USB3.0 PHY, which explains the price, but why would that be necessary for USB-MIDI over MCU with integrated USB2.0 PHY? Other than various hi-speed peripherals, this MCU itself isn't particularly powerful for the price. What's the rationale here?

Keep in mind that CH569 is not on (https://github.com/hathach/tinyusb) supported MCUs list, which means you'd be on your own implementing USB-MIDI. Unless you plan to do that, I'd stick with devices on that list.

Some notable cost-efficient MCUs with integrated USB2.0 PHY (480mbit theoretical max) and tinyusb support are:

1. CH32V305 (1-2eur in small quantities)
2. AT32F405 (1.5-2eur in small quantities, 100kb sram)
3. NXP MIMXRT1011 (500mhz cortex m7, 128kb sram, requires external QSPI flash for code(!!!), 2-3eur in small quantities)

Another thing to note is that, WCH MCUs require a special SWD probe called WCH-LinkE, so you can't leverage existing probes you'd use for stm32 and various other arm-cortex based MCU.

WCH-LinkE used to go for 4-5eur a while back, but now after the newly introduced EU tariffs it costs more like 10eur (post tariff, price of of every little thing has been bumped for at minimum 4eur)

Another thing to keep in mind regarding USB2.0 HS is that you need impedance control for the differential pair (Zdiff = 90ohm). So unlike USB FS (where you can be very sloppy), you'll have to carefully calculate trace width and trace spacing as well as spacing to copper pour (especially on 2layer pcb), etc.

The difference between USB FS and USB HS (2.0) MIDI latency is somewhere around 1ms. It's not large enought to be a dealbreaker for the initial version, in my opinion.

So you can draw the MainBoard PCB for some USB1.1FS MCU (some widely available rp2040/rp2350 devboard) and then eventually upgrade to mcu with usb 2.0 when the rest of the system is ready.

I can't comment on MagnTek’s MT8901AT, it looks like something that would be used as rotary encoder for motors, etc. Not sure how exactly you're planning to use it for velocity sensing - although I highly suspect (due to how it's worded) that I'm replying to an LLMed post. 🙂

DavisB I doubt the velocity sensitivity will be good enough for playing piano music expressively, but maybe this would work as a fun synth with after touch?

Not even close. More suitable to organ type of playing. Not sure what the travel Z distance of these keys (buttons) is but would assume is about 5 mm (max) which is insufficient for proper dynamics (velocity) for either organ\piano type of dynamics.

After‑touch? Yes. But it is an overkill with so many buttons. If you manage to assign and set them up for 'pitch bend up' that would be great.

It is a bit disappointing that such so called isomorphic keyboards are mostly used for microtonal layouts, which makes sense as they are not bound to full lever\parallel mechanics. The typical computer keyboard caps though are not ideal. But I advocate for dome shapes anyway.

What will be the controller chip\board used though?

DavisB Fair points, thanks for your time. USB 3.0 specs has 10 times lower latency than USB 2.0. If software compatible chip exists, that would nearly eliminate the system overall latency.

Is there any mcu can be used as magnetic sensors that has built-in velocity and direction functions for greater simplicity and reliablity over time than current optical solution?