A DIY hybrid piano without ADCs (purely digital sensors)

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.