A DIY hybrid piano without ADCs (purely digital sensors)

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?

Star_catcher

That would only eliminate USB-MIDI latency, overall system latency would still be largely dominated by VST/Audio interface/Drivers.

If your total audio latency is 5ms (which is pretty darn good):

• USB1.1 would give total system latency of 6ms+.
• USB2.0 would give you 5.1ms+.
• And USB3.x might give you 5.01ms+.

So USB3.x over USB2.0 would likely give you somewhere around 2% improvement in total end-to-end latency. (ideally you'd accurately measure it if and when attempting to make such improvements)

USB2.0 is where you reach diminishing returns point, going above that drives up price and complexity significantly for minimal gain.

Hall effects / TMR sensors with analog output aren't all that different from reflective analog out optical phototransistors in terms of complexity. (other than usually being bipolar, they hang in the middle of Vdd and go up or down depending on the polarity of the magnet)

Although there are many kids of magnetic sensors, like thousands of different models with different sensitivity, min max ranges, some output PWM, clocked data out, etc. TMRs being the highend significantly pricier option.

One of the reasons I stayed away from magnetic sensors thus far is crosstalk - my piano sensors for 5.2" octave are mere 11mm away from each other, and unlike optical sensors - I don't know any simple or cheap way to provide shielding from magnetic crosstalk.

The magnetic keyboard switches are more like 19mm center-to-center distance, far enough from each other for no notable crosstalk to be observed.

Alleged reliability issues of optical sensors are mostly overblown by people who have no personal experience with them.

I'm still sticking with optical sensors for my Narrowkey Piano Actions, magnetic sensors is for experimental stuff for now.

Don't take my word for it, conduct experiment(s) and measure everything (including end-to-end latency). And report results 🙂

DavisB Totally agree with your measure of system latency. My audio interface with an old Mac on linux is approximately 2.5ms with an opensource cli sfz player, which means reducing 1ms is meaningful theoretically.

In my view, optical sensor crosstalk problem with the environment around the action would be incovenient for some. For example, other light sources. Magnetic sensor is tiny chip and only measure a very close distance with neodimyum pinpoint or plate.

Looking at some SMT sensors, I find that some have built-in digital velocity and direction measurement which built exactly for need of mechanical industries. So, optical solution requires a far more complexity software management. Would it possible to make another experiment?

I am not an expert in the field of building embeded system like you. I am glad to have the conversation. Very helpful.

Star_catcher

Looking at some SMT sensors, I find that some have built-in digital velocity and direction measurement which built exactly for need of mechanical industries.

Can you name the list of exact model numbers for the sensors that have built-in digital velocity and direction measurement - so that I can take a look at them?

Do you mean dual-latch sensors with the fixed 1.45mm distance between hall-effect sensing elements?
You're right, these perhaps could be used somewhat similarly to optical slit sensors - namely magnet doesn't move towards and back from them (as in distance measurement), but along them thus triggering the hall effects one-after another.

As long as you can make the 1.45mm trigger distance correlate to correct points on the keydip (this is kind of like 2-sensor action), this could work.

However, make no mistake - these sensors don't have any embedded smarts to measure velocity/speed, they are for magnetic rotary encoders, mainly measuring motor rpms/direction, that kind of thing.

(with optical slit sensors and a encoder pattern you can have multiple trigger points though and the trigger distance can be changed, etc)

That being said, these might be worth doing an experiment with...

I found some videos of building magnetic sensors for key detection. I am not sure how he implemented the solution, but it seems working.

Star_catcher

Just regular off-the-shelf hall-effect sensors with analog out and cd4051(8chan) or (cd4067 16chan) mux fed into ADC of Arduino Leonardo, velocity is derived from delta T of crossing two threshold values.

I urge people to conduct experiments.

People tend to make up all sorts of ideas in their head about all sorts of "problems", of what's simple or complicated, of what will work and what won't, of what's easy or hard to do, or not.

And these ideas don't come from the Praxis, from the Experiment, but from mere concoctions of the mind -
never challenged by the Experiment.

DavisB If the video indicates that magnet sensor works, does digital hall effect sensors that directly return velocity and directions can be used instead for minimal software mantainance and system complexity.

A few sensors I looked at: TLE5012B, TMAG527, AS5047P, ATS19520

Star_catcher

TMAG5273 is a low-power linear 3D Hall-effect sensor with I²C interface.
Have you ever talked to 88x I2C devices at once over a span of roughly 1meter at the bare-minimum necessary 10ksps per sensor sample rate? Incl. but not limited to converting the 3d position(s) to velocity?

If not, where does your ideas about "minimal software maintenance" and "minimal system complexity" come from? LLM? 🙂

P.S. This conversation is over. Make a seperate thread.