A DIY hybrid piano without ADCs (purely digital sensors)

candela Thanks for the input, Del Vento!

You are most welcome!

candela y reasons for choosing a slit/fork type detector over a reflective one are mainly to avoid the ADC step and not having to recalibrate when IREDs go dimmer over time, reflective surfaces get dirty etc.

Got it. For the ADC, if you are designing it yourself, I understand. Digital is certainly easier and more stable (that's why our computers, music, video, etc are basically all digital, despite years of analog head-start and occasional claim of its comeback). In fact, the project too is mostly digital, besides the initial position sensing.

For the calibration.... One of the main goals of these projects is to make that calibration automatic at startup, because it's all (mostly) multiplicative (light at key-at-rest get dimmer -> it's equally dimmer also during play). In addition a simple "play-all-keys" additional calibration can add the "closest it can get" step, probably necessary every several years only.

candela the freedom to design the action parts myself to suit the sensor type

DavisB I like this design the most frankly at the moment for it's utmost simplicity.
I'll probably be way less enthusiastic after trying to integrate them with the mechanics, but this is an approach i have to at least examine.

That's very cool. Just make sure you don't underestimate the complexity of mechanical calibration and don't overestimate its stability -- but perhaps you @candela have already done that.

candela The reason for me to do this is to build a narrow keys midi controller

Since I'm also interested in exploring narrow-keys keyboards, I'm looking forward to see your progress. Once you start building things, please post pictures and design files somewhere (a new thread here, github, whatever you want) and ping us all or at least me 🙂

@DavisB @Paulo164 @vagfilm @candela I moved this discussion here since it's not relevant with the original Cybrid thread anymore. That had the side effect of unsubscribing you, so click on the "Following" button on the top-right if you wish to resubscribe

New experiment time - optically isolated stepper driver adapter for piano callibration!

Bom:

• bigtreetech tmc2208 driver v3 = 2eur
• Screw terminals, 2p 4 cents x3 = 12 cents
• EL817 optocoupler, 3 cents x2 = 6 cents
• 4position dip switch, = 16 cents
• 78L05 linear voltage regulator = 2.5cents (used to convert 24v->5v, due to large difference it takes very little current to heat it up and smoke it)
• 1206 red led status indicator = 1cent
• 1206 resistors x8 = 2.2cent
• 3x 0805/1206 decoupling caps = 2cent
• 50v 100uF electrolytic cap, Rubycon = 53cent
• fr4 one sided copper = 20 cents

The purpose of this adapter is to avoid using a breadboard and to hopefully avoid frying teensy by having a bit of isolation between it. Thus the stepper is wholly powered by independent 24v supply. Or that's the idea.

The idea is to use this to measure that all keys trigger optical switches at the same distance and that the distance between trigger1/trigger2 is the same, or atleast similar enough.
If not, perhaps use the information to account for that in software. Ie. have a measurement diagnostics tool that couples sensor reading values with distance of how deeply a key is pressed.

This is how it looks in practice. Ideally it would also have a second axis and it would automatically press all the keys - octave by octave or key by key and confirm that the instrument is up to spec.

candela

The reason for me to do this is to build a narrow keys midi controller and when I looked around I somehow didn't find any through-hole sensors narrow enough to fit without fanning out the keys in the back, which I very much would like to avoid.

We are in the same boat then!

One question that has been on my mind is whether Schmitt triggers ought to be used to clean up the signal from fluttering between on and off when going from one state to the other? This is also suggested in the data sheet for the TCUT. I see that you don't do that so I'm wondering how that is working and if Schmitt triggers would be unnecessary?

AVR mcus, teensy 4.1 and others usually have schmitt triggers built in into GPIO inputs, or you can optionally enable them, as far as I know.

Perhaps you might want an external schmitt trigger if you want to have an explicit control of the analog threshold hi/lo values.

@candela The reason for me to do this is to build a narrow keys midi controller and when I looked around I somehow didn't find any through-hole sensors narrow enough to fit without fanning out the keys in the back, which I very much would like to avoid.

DavisB We are in the same boat then!

The QRE1113 is narrow enough and has a variant that is through hole (and another with the same footprint that is SMT, so it's an ideal part for experimenting easily at home and then get it assembled at scale professionally).

By the way, I'm now experimenting with WNG action parts (in my opinion much better than the Renner and Tokiwa one people are arguing/raving in the other threads). Possible to make 6" octaves, but really hard getting below that (and definitely impossible getting to 5.5" with "regular assembly") -- once I finish with the regularly sized project (hopefully just a weekend or two), I'll post some updates on this with some creative "non-regular" assembly I've been thinking of. Stay tuned!

Is there something I'm overlooking, but why isn't 74hc238 isn't used for multiplexing (in analog sensor case)?

1. Reduces power consumption to 1/8, because only every eigth LED is lit up.
2. Need only 2 resistors for 8 sensors (one for led and one for photo transistor which are shared by all 8), and decoupling caps for the IC.
3. Reduces light crosstalk (there's 7 unlit sensors on both sides)
4. Can be chained together to create 1-to-16 or 1-to-32 mux.

Even in 1-to-8 case this leaves only 11 analog signals to be multiplexed or processed. (11 boards of 8 sensors)

74hc238 is bit more expensive (12cents) than the ubiquitous inverting 74hc138 (these go as low as 5cents a piece)

Because you need high time resolution for analog sensors? Something like at least 10khz on each key I think. It is certainly possible to do it like that but you are asking for a problems because it's getting into RF territory where one wrong decision in PCB design can make it not work at all, and also you would need some great ADCs and very fast sensors.

DavisB multiplexing

I actually have not given much consideration into that, and just accepted what others have done, so let me bring @gzpiano and @JayKominek into the conversation, but here are my speculations

DavisB Reduces power consumption to 1/8

This is a nice-to-have. For constant current driver (which IMHO is what should be used for this project) where there is no current-limiting resistor, the power consumption is not that much, so I'll take the saving, but not a big deal.

DavisB Need only 2 resistors for 8 sensors

Again, you are thinking of the 16 resistors needed for a circuit with individual current limiting resistors, which IMHO you should not. See my quick take on this if you don't know what I am talking about

DavisB Reduces light crosstalk (there's 7 unlit sensors on both sides)

I think that's a great advantage, and the reason why you grabbed my attention even if I came to the computer with the intention of shutting it off, rather than posting another message 😃

Possible problems I see from the LED driver point of view: I am not sure how a constant current setup would react to this kind of multiplexing. The LED themselves are able to switch on and off at that rate no problem. I don't think their lifetime would be affected by the number of on/off cycles, if they are not subjected to current spikes. In fact their lifetime could be extended by such a driving mode since it's typically rated in pure time spent in the on status. The question is if one can make the parasitic impedance of the rest of circuit small enough to not subject them to current spikes (I think that is feasible) and to have the current stabilize quickly enough for the readout, since you don't want to use the sensor until you know the lighting from LED is constant. I think the most important questions are how much current can the mux carry, what is its parasitic impedance and how that would affect the the speed of switching the LEDs on and off?

As "gut feeling" (my EE is just amateurishy) is that this can be done with some work. Simply there is not such a large advantage for people to have (so far) thought about it. I think reducing crosstalk is very valuable benefit and worth investigating this more, especially for small-size keyboards, where the sensors are closer to each other.

See video number 29 for a take from @gzpiano about crosstalk.

See also my comment and @gzpiano somewhat dismissive one (which would apply less on reduced-size-keyboards) at things to consider number 6

Since I'm at it, let me comment on

RIP By the way, I'm now experimenting with WNG action parts

RIP I'll post some updates on this with some creative "non-regular" assembly I've been thinking of.

to just say that I've done very little about it, and I've found it's difficult for reasons I'll explain later because

RIP once I finish with the regularly sized project (hopefully just a weekend or two)

this is taking longer than I hoped (but it's making progress, as I reported in the other thread)

ambrozy Something like at least 10khz on each key I think.

LEDs can easily switch in the MHz regime, and probably much higher. There are multiplexes on the sensor side anyway, because otherwise one would need too many ADCs and those are too expensive and complicated (and would in turn need too much MCU computing power to deal with them)….

ambrozy and also you would need some great ADCs and very fast sensors.

You need all of that anyway

ambrozy it's getting into RF territory where one wrong decision in PCB design can make it not work at all,

These numbers are considered VLF and have wavelengths in the tens of km (miles) which mean any mistake on the cm (inch) size of the PCB is going to be irrelevant. I mean, one still has to correctly design the PCB to avoid it working as an antenna for the plenty of signals that exist at the wavelengths of its size, but having it work in the tens or even hundreds of kHz (and perhaps even low MHz) range is not going to be a big deal

this depends heavily on the physical realization of the circuit.

if what is depicted is entirely on one PCB with a ground plane, then eh, it's probably okay. you've moved the mux that was designed by Very Smart People out of the ADC and onto your PCB, and made a lot of the signal loops larger, and given yourself synchronization problems to worry about. you can probably overcome all of that.

if the P0..7 nets are pieces of copper wire leaving the board, coming from some more central circuit board to sensors on each key (which seems necessary, because most actions don't have all 88 keys spaced exactly the same distance from each other, but maybe you're lucky?), then those loops are going to act as illegal radio transmitters.

it isn't the 10kHz sampling rate, or the 80kHz mux switching rate that will matter, it'll be the speed of the edge(s) generated by the 74HC238 as it switches the signals on and off that generate the noise. the '238 switches fast enough to be used in circuits of many, many MHz, for which your wires will be passable antennas.

RIP I am not sure how a constant current setup would react to this kind of multiplexing.

probably best to make the driver aware of the switching of the mux, so that it can turn off, allow the mux to switch, and then turn back on. and you're going to want a very well tuned control loop in your CC driver so that it can settle fast enough.

RIP I don't think their lifetime would be affected by the number of on/off cycles, if they are not subjected to current spikes. In fact their lifetime could be extended by such a driving mode since it's typically rated in pure time spent in the on status.

yes the LEDs would be happier and last longer.

and as you alude to, while the LED might be happy to switch extremely fast, it isn't necessarily being driven in a fashion which will allow it to do so.

the LEDs transmitting data at megahertz aren't doing it with a voltage source on one side, a resistor on the other, and a meter of copper wire inbetween.

DavisB

That's interesting. I want to try to test a similar scheme. But I'm still forced to finish the renovation of the house. What if you use something like CD4022B instead of 74hc238?(maybe there are faster options..) Then you will need 1 channel instead of 3 channels to switch. I'll have to check it out..

RIP
Can this constant current source driver be made such that it's powered purely from USB? (see korg microkey: plug in USB and it works)
Can a constant current source of this type be built from commodity jellybean components?

Lighting up 88/8=11 LEDs is something than can be powered directly from USB I think, and this is highly desirable.

scherbakov.​al
I have not looked at this IC yet. It does look like an interesting option...

JayKominek this depends heavily on the physical realization of the circuit.

Thanks Jay

JayKominek it isn't the 10kHz sampling rate, or the 80kHz mux switching rate that will matter, it'll be the speed of the edge(s) generated by the 74HC238 as it switches the signals on and off that generate the noise. the '238 switches fast enough to be used in circuits of many, many MHz, for which your wires will be passable antennas.

Ah, that's right, I forgot the mux won't switch with a sine wave 🤣

JayKominek probably best to make the driver aware of the switching of the mux, so that it can turn off, allow the mux to switch, and then turn back on. and you're going to want a very well tuned control loop in your CC driver so that it can settle fast enough.

I'm not sure the constant current driver can reliably switch on and off at that rate without 1) damaging itself in the process and 2) settling at the intended current in time for the measurement to happen. The datasheet of the CL220 which I am currently using says that it has a shorter than 12us turn-on delay (total, see fig 3-3 and table 1-1), so time-wise it's fine (but one might need to make the capacitor smaller, otherwise that might take longer to charge/discharge at each cyle). What I don't like is that there is an inrush current spike (of unspecified value) and current overshoot of a whopping 25mA (again see fig 3-3 and table 1-1), which I am not sure it'd be good to expose the LEDs to (and one needs to make sure to not mistake those as hammer movements, but that is just timing the measurement right in the ADC and/or software). I guess other CC regulators may be more well-behaved in that regard?

Side node: I am currently using an off-the-shelf linear power supply namely the HB48-0.5-AG and, I've got two spares because I am a hoarder and I can't resist the volume discounts, let me know if you want one or two to play around with them.

JayKominek the LEDs transmitting data at megahertz aren't doing it with a voltage source on one side, a resistor on the other, and a meter of copper wire inbetween.

The mux could be placed closed to the driven LEDs, so that meter of cable could be made 5-10cm instead which will help some, not sure if enough.

DavisB Can a constant current source of this type be built from commodity jellybean components?

I would not build the CC driver, but buy it. See the link above to the CL220. It's just a commonly available part, not jellybean, but common simple to solder and inexpensive.

DavisB Can this constant current source driver be made such that it's powered purely from USB? (see korg microkey: plug in USB and it works)

DavisB Lighting up 88/8=11 LEDs is something than can be powered directly from USB I think, and this is highly desirable.

Power-wise, for sure. If you want to power them in series (which makes sense for longer chains, but may not be ideal in this situation), 11 LED with typical forward voltage of 1.5V each means you need 16.5V. Not impossible to generate, but I would not do it that way because you need to increase voltage and that would introduce ripple (among other things). However if you have (say) 6 chains of two LEDs each, that is just 3V each. Given how inexpensive the CL220 are you can have 6 parallel chains (see fig 3-5 in the datasheet) and that will work. However the minimum operating voltage of the CL220 is just 5V which might be too close to the USB nominal one, so I'd look for another similar component instead.

At this scale (just 11 LEDs driven at any given time), I would need to think more if I like the constant current approach more, or if the current limiting resistor is adequate and may sidestep the problem with the inrush and overshoot current. But still, you'd need to do something to make sure the current is stable enough. See the problem? In this design, we want the current to be very stable (like before), but then switch it on-and-off at all times, so some typical "smoothing" approaches to remove short-term stuff (e.g. large capacitors) cannot be used.

DavisB Can a constant current source of this type be built from commodity jellybean components?

My design includes a simple linear constant current supply.

https://github.com/jkominek/piano-conversion/blob/master/hardware/led-power/led-power%20schematic.pdf

An op-amp capable of handling whatever the supply voltage is, a MOSFET, a resistor, and a voltage reference (which can be shared between drivers) will do. If you turn the voltage reference off to a particular op amp (driving the non-inverting input to zero) then I believe that will turn off the supply.

RIP I'm not sure the constant current driver can reliably switch on and off at that rate without 1) damaging itself in the process and 2) settling at the intended current in time for the measurement to happen.

Switching constant current drivers might not appreciate being flipped on and off like that, but simple linear ones like I include in my design can be designed such that they shouldn't have any problem. If you look at my design, that would just be a matter of flipping an op amp and a MOSFET on & off at your 8 times sample rate. The MOSFET will do that gleefully. The op amp won't mind trying, but to your second point, it might be hard to get one that can do it fast enough while satisfying all the other various requirements.

RIP The mux could be placed closed to the driven LEDs, so that meter of cable could be made 5-10cm instead which will help some, not sure if enough.

That will certainly help with the speed of things. But that length of wire without an adjacent ground is still likely to radiate.

DavisB Can this constant current source driver be made such that it's powered purely from USB?

Running something like this purely off of USB is going to make your life harder. Unless you're going to implement USB-PD, then as a practical matter that limits you to 2.5W total. Some of which you're going to lose because you're going to have to regulate that tiny trickle of 5V down to something else so that you can ensure it is stable and clean where your digital logic needs it.

Thank you for the valuable feedback. It really got me thinking.

While the LED switching itself can be very fast, one reason this method might not work as well as I would have liked is that the phototransistors are quite slow.

ITR8307 (and CNY70 and similar) have bandwidth of around 20-40kHz depending on the load usually the 10k resistor as seen in the sample circuits) Rising/falling edge of around 20 microseconds.

If I understand correctly, when switching from one phototransistor to another (1 out of 8) up to 20microseconds are potentially necessary for the phototransistor output to settle on the correct output before even initiating any measurement or ADC conversion. This is getting too close to 10kHz-20kHz per sensor sample rate I'd like to achieve.

The difference between a photodiode and phototransistor is that phototransistor in itself functions as an amplifier of sorts, while a photodiode absolutely needs an amplifier as it outputs very little current (the transimpedence amplifier is often used in this case). Photodiodes can be very fast however (as used in fiber optics, etc)

hc238/hc138 ICs have falling rising edges of around 10ns at 5v (depends on VCC, significantly more at 3.3v).

As a rule of thumb, bandwidth of a squarewave signal is calculated using:
Bandwidth_in_GHZ = 0.35/Rise_time_in_nanoseconds.
In case of 10ns rising edge that would be ~ 35mHz.
The traces and the load will have a certain amount of capacitance and resistance - that will function as a low pass filter to reduce the 10ns rising edge to a degree.

I'm listening to lectures by Dan Gelbart, and from my understanding, as far as high accuracy sensing is concerned -
any measurement which can be converted to time measurement can be measured to a much higher degree of accuracy.
Most things - with great care - can be measured to about 1 part per million. 1micron to 1meter, 1volt to 1microvolt, 1mg to 1kg, except time, time can be measured to orders of magnitude higher accuracy (think atomic clocks). Comparitively 1s to 1microsecond(1Mhz) is very easy and cheap to measure. Any bargain bin MCU will do.

For signals that are AC and you're measuring frequency, that becomes a measurement of zero crossing time (ie. time measurement).

This is why FM has way better noise immunity than AM, it only cares about zero crossing time (not noise on amplitude and other distortions of the signal)!

If signal is AM modulated (data is in the amplitude not carrier frequency), you can get rid of lot of the noise by building a band pass filter around the carrier frequency F.

If you amplify DC signals you get DC drift, every amplifier has an offset voltage which drifts.
DC drift is a problem if you work with low level signals in mV. AC doesn't have this problem.

Optical sensors, the ones we use, typically have peak wavelength of 940 nm. They have a built in optical band pass filter
(colored glass/colored material which filters for that wavelength).
But there are other sources of 940nm ambient light other than the IR-LED itself (room lights, outdoor lights, etc)
Working with AC also provides a way to filter out other sources if IR-LED is shone modulated with certain frequency F (10kHz-100kHz).
Then we can bandpass filter modulated frequency, thus eliminating other sources of ambient light that operate at different frequencies.

If you have an analog sensor, you want to put amplifier right next to it (if you put it on the other end, you will amplify noise, etc).

Distance sensing can be used to measure many parameters, some of them:

1. Force (deflection of a cantilever spring, F=kX, if we can sense X we can sense F)
2. Acceleration (deflection of a cantilever, F=mA, mass is known, F can be measured from (1))
3. Mass (deflection of a cantilever, F=mg)
4. Pressure (deflection of flexible diaphragm)

Many accelometer IC have silicon micro etched springs that measure distance capacitively.

For highly accurate measurements ideally you want differential sensor that eliminate drift in other parameters of the sensor.

Vishay Semiconductors have "Application of Optical Reflex Sensors TCRT1000, TCRT5000, CNY70"
That has the following circuit that demonstrates use of such AM modulated signal:

The circuit in figure 20 is a simple example for operating the reflex sensors with chopped light. It uses a pulse generator constructed with a timer IC. This pulse generator operates with the pulse duty factor of approximately 1. The frequency is set to approximately 22 kHz. On the receiver side, a conventional LC resonance circuit (fo = 22 kHz) filters
the fundamental wave out of the received pulses and delievers it to an operational amplifier via the capacitor, Ck . The LC resonance circuit simultaneously represents the photo transistor’s load resistance. For direct current, the photo transistor’s load resistance is very low- in this case approximately 0.4, which means that the photo transistor is practically shorted for dc ambient light.

I did some measurements for Everlight elec ITR20001 phototransistor feeding into it a 160kHz 5v pwm signal from an arduino mega:

I'm getting around _800ns fall time of photo transistor output. Which is way less than specified 20microsecond rise/fall time, am I missing something?
This is using 8kOhm resistor as load on emitter side (hooked up as seen in the initial schematic, but without the hc238).

If all sensors are sampled at 20kHz, that gives 50microseconds to switch between the 8, giving 6.25us per sensor time window, 1us of which would be taken up by the transition.

Another way to look at is - if 50us are the time window to sample all 88 sensors, then 8x11 mux using 238 would eat up _8us of that budget in transitions. So this approach might as well work if that is taken into account.

I've upgraded slot-through slit-sensor PCB design with hc238 muxing too.
Now it effectively draw less than 200mA, which means it can easily be directly powered from USB alone.
And requires only 3 resistors instead of 32 previously, only one hc238 IC per 8keys (instead of two shift registers per 8keys), 1 decoupling cap. This reduces part count and simplifies assembly (matters alot if hand placed).

A single Raspberry Pi Pico is wholly sufficient as main USB-MIDI device too, with tinyusb library. RP2040 is 70cents @ 100qty, compatible QPSI flash around 25cents. Ready made original Raspberry Pico boards are 4.2-5€, WeActStudio rp2040 is 3-4€, YD-RP2040 modules go for as low as 1.5-2.5€ a piece.

Total effective electronics BOM of this slot through design ends up being roughly 50-60€, including PCBs, but excluding assembly. No external power supplies necessary either. This is as simple as it gets, but it does require a mechanical element to move through the slit, the only downside of this approach.

I suspect a wholly analog version can also be built in roughly same electronics BOM budget, but it is highly dependent on built in ADCs of stm32 mcus to be "good enough".

My first experiences with programming stm32 via SWD has been thoroughly positive, debugger and breakpoints work great, while also being able to see peripheral registers and their state as machine is running. This is great for troubleshooting. (not using cubeIDE)

stm32 has two vendor specific APIs, stm32 HAL (high level) and stm32 LL (low level). STM32 LL are just thin wrapper over peripheral registers that are memory mapped into flat address space. Interfacing with peripherals is essentially taking 32bit addresses (as pointers) and reading/writing to values to them. Reference manuals have descriptions in detail where each peripheral is in memory space. I find stm32 LL API particularly pleasant and easy to understand.

Other than vendor specific peripherals, both rp2040, stm32g431, stm32h7, teensy4.1, they all have arm cortex m0/m4/m7 cores . RP2040 is a cortex m0 (no floating point unit), teensy4.1 and stm32h7 are cortex m7 (have floating point units), just clocked at 600mhz(teensy) vs 480mhz (stm32h750). They are programmed and debugged in the same way via SWD/JTAG.

I have weact stm32g431 (2x 12bit 0.25us adcs) devboard on hand with weact stlink probe. DMA DAC works well (very useful as signal generator!), sending ADC readings via UART using DMA works well too. ADC conversions thus far seem to work great via DMA too (ADC conversions automatically get written in buffers).

I wrote a small app for streaming and displaying ADC values over UART, works easily up to 1mbit baud rate (haven't tested higher)

(ignore ENOB readings, those are rough estimates if the signal is not "moving")

This is capable of also generating MIDI signals to be routed to Piano VIs. Which means that I can develop and test velocity calculation algorithms fully on PC before porting it over to a MCU.

The "tricky part" is setting up the peripherals/timers/DMA and buffers such that almost nothing is blocking (or calling interrupts as interupts also take cycles to switch in and out of).

For h7 480mhz / 88keys * 20khz sampling = 272 cpu cycles per key. This is only slightly less than teensy at 340 cpu cyles per key.

DavisB ….. 480mhz (stm32h750)

There are stm32h723vgt6 boards with 550mhz processor and built-in full color display for only 10 dollars. I myself switched from stm32h750 to stm32h723. They work great and are inexpensive.