DIY piano sensors

0.009ms cycle with a 20ms travel time means a 1/2200 accuracy. Far more than the 1/127 you would need with MIDI. You can even use the MIDI HiRes velocity extension.

But excepted Pianoteq, I know no virtual piano which would use them.

Frédéric L

It's a bit different due to the principle of how Cybrid measures duration. You can think of this as the regular triple-sensor digital piano action where you have three on/off switches and you measure the duration between second and the third. However I don't measure the time between the exact activation of each "switch" because that's not possible. Instead I go sequentially through all the switches and check if it has been activated and if it wasn't the last time I checked I mark this as "start". But it means that I may have lost 9 microseconds. For high velocity strikes it means gradual loss of accuracy. I've made calculations that for a MIDI velocity of 127 I have an accuracy of less than ±0.5 if I'm not mistaken which is very good. I can provide the higher resolution but the precision won't be there, so it won't make sense.

BTW, the VPC1 works in the exact same way as Cybrid, calculating duration by measuring duration between switches activation BUT only through sequential scanning, meaning there's also loss of accuracy for higher velocity strikes. I'm not sure how fast their scanning is but I'm pretty sure it would be less than the 600 MHz Teensy. But the hammers in the VPC1 are not moving as fast as a real grand piano action hammers (they don't have 1:5 leverage amplification ratio), so that makes up for the loss of accuracy.

If you count the number of cycles after the first second and before the last, it is like you are measuring a time bit with a (very) little inaccuracy.

I know no other practical way to measure a time

Not sure if I explained it properly. Intuitively you could think of second switch starting a timer and third switch stopping the timer. But that’s not how it works. It could work this way if all switches are simultaneously wired to the CPU and if there were hardware interrupts. Or if the switches had their own timer for each key. But since here we have a single CPU that scans sequentially through switches through multiplexing, you don’t know when exactly the switch was activated. You only know that on previous scan cycle it was off and now it’s on. That means it could have been activated any time between right now and 9 microseconds ago. For low velocities (long duration) 9 microseconds inaccuracy is not significant. For a high velocity strike, hence short duration, 9 microseconds can be already a high enough offset. Well, in my case they lead to 0.5 points of MIDI velocity inaccuracy.

CyberGene Not sure if I explained it properly. Intuitively you could think of second switch starting a timer and third switch stopping the timer. But that’s not how it works. It could work this way if all switches are simultaneously wired to the CPU and if there were hardware interrupts. Or if the switches had their own timer for each key. But since here we have a single CPU that scans sequentially through switches through multiplexing, you don’t know when exactly the switch was activated. You only know that on previous scan cycle it was off and now it’s on. That means it could have been activated any time between right now and 9 microseconds ago. For low velocities (long duration) 9 microseconds inaccuracy is not significant. For a high velocity strike, hence short duration, 9 microseconds can be already a high enough offset. Well, in my case they lead to 0.5 points of MIDI velocity inaccuracy.

Thanks again everybody and particularly @CyberGene for this last clarification. So let's forget for a moment that you have many sensors, and concentrate on one: if my understanding is correct, you are "sampling" the on/off condition of that sensor with a 9us period, which is roughly 3 orders of magnitude faster than what the chip/sensors I got fixated with can do. And that is more or less the "sweet spot" for enough MIDI v1 resolution, so "mine" are too slow -- 'nuff said.

I was partly confused by the fact that the the chip/sensors I was looking have different aspects of the "timing" of measurements and I should not look at things that can be confusing when it's past my bedtime (yes, I go to sleep early, if Flarum tells that). In fact, there is the laser pulse (which can be as short as 50us), then there is the sampling time (which can be at most 8ms, which -- including additional overhead -- gives a mere 67 measurements/sec) and the I2C reading time (which at the highest I2C bus frequencies can be 100us). In any case, this is too slow. Yet, I like this sensor very much: the laser is highly directional, so there is little to no risk of sensing the neighbor key; the laser is pulsed and the pulse is matched in the receiver, so there is a very high rejection of other light sources; and a lot of other functionalities which instead I would need to design and implement myself.

On the other hand, 12-bit ADCs with sampling rate of 500kHz (i.e. sampling time of 2us) are not uncommon, even though if I want to implement (in hw or in sw) some of the stuff that these sensors provide I may need a higher frequency.

So, in conclusion, I will be ordering a few samples of QRE1113, EAITRCA6 and CNY70 run many tests and see which ones I like best. FWIW, the size of the CNY70 is problematic for the way I want to assemble the key sensors. To make my life easier, at this stage I will use a few RPi pico, each of which has 3x 12-bit ADCs @ 500kHz.

Obviously, I will report back here what I find (and probably make a PR on either or both Cybrid and piano-conversion github repos with the code and data which I'll get).

Yes, not exactly, but any time measurement have the same issue. (Any measure has some limited accuracy too).

Even if you hardlink an input to a CPU IRQ, the CPU can memorize the Time Stamp Counter (TSC) when it receives the IRQ, but it won’t know how much time are spent between the last TSC increment and the IRQ. Then it won’t be an exact measure. (With GHz CPU clock you will however have some magnitude more accuracy).

RIP [@CyberGene...] if my understanding is correct, you are "sampling" the on/off condition of that sensor with a 9us period, which is roughly 3 orders of magnitude faster than what the chip/sensors I got fixated with can do. And that is more or less the "sweet spot" for enough MIDI v1 resolution, so "mine" are too slow -- 'nuff said.

The Cybrid, the VPC1, any of the 2/3 squidgy switch based systems, anything with a light gate waiting for a slot to pass through it... none of these systems are measuring velocity (distance/unit-time) directly. They are all measuring colevity (time/unit-distance) and then calculating a velocity by taking the reciprocal of the measured colevity.

(Yes, OK, "colevity" is a word I just made up, but it's still the thing that all these systems are measuring).

7 bits worth of directly measured velocity would give you 128 measurable velocities like this:

But 7 bits of directly measured colevity gives you 128 measurable colevities like this:

And when you calculate 128 velocities from these 128 colevities you get this:

As you can see this gives plenty of velocity resolution down there in the tiny highlighted area at bottom-left, but there's not so much resolution in the middle and there's barely any at the top, and this is why those systems need scan rates so very much faster than you might expect.

With a 9us scan time the Cybrid can "see" ridiculously high velocities: The last value, top-right of the third graph above, represents a hammer speed of many hundreds of miles per hour in the Cybrid. The hammer never goes anything like that fast of course, but it means that the speeds it does go are all clustered down in that bottom-left corner of the graph where the distinguishable velocities are packed close enough together to get the job done.

Your sensors are way too slow to take this approach. But to measure velocity directly instead? To measure the distance moved in a known unit of time, to obtain the first graph above instead of the third? The ones (of "yours") that I looked at were only a bit too slow for doing it that way.

xooorx They are all measuring colevity (time/unit-distance) and then calculating a velocity by taking the reciprocal of the measured colevity.

(Yes, OK, "colevity" is a word I just made up, but it's still the thing that all these systems are measuring).

Very nicely said, thanks. May I nudge you to make a PR with a markdown version of your text and the plots to incorporate in either or both https://github.com/ekumanov/cybrid/ and https://github.com/jkominek/piano-conversion/ ? I think it'll be extremely useful for others, and there is an easier to find place than here. I am sure @CyberGene will agree.

Besides, you could have said in the "traditional" approach the sensors are measuring time (since the distance unit is fixed for all of them) rather than colevity, but that sounds cool 😀

xooorx Your sensors are way too slow to take this approach.

Yes, I finally concluded that on my own, thanks for confirming.

xooorx But to measure velocity directly instead? To measure the distance moved in a known unit of time, to obtain the first graph above instead of the third? The ones (of "yours") that I looked at were only a bit too slow for doing it that way.

Assuming that the hammers could move that distance, which may not be the case: a properly regulated let off could be as close as just 2mm before the "string" strike, so at the highest speed there is simply not enough room for it to travel the fixed amount of time, no? One could (and I definitely will) measure the hammer before let off, but being still attached to the key its speed is "not authoritative" yet, and to infer the final velocity one should integrate the momentum transfer rather than just measuring speed. I'd need to do some math to confirm, but I suspect the error propagation will not make it worth it.

FWIW, I ordered several specimens of those 3 kind of sensors and the boards to control them. I'm now designing some test fixtures and I hope to gather some data during the holidays.

Or you could put accelerometers, and calculate position and velocity from instantaneous acceleration. Nothing other than Newton (I believe) but will drive you crazy 😊 no effect of coletivity (whatever that means).

RIP Assuming that the hammers could move that distance, which may not be the case: a properly regulated let off could be as close as just 2mm before the "string" strike, so at the highest speed there is simply not enough room for it to travel the fixed amount of time, no?

Hang on, yes, sorry... I was looking at "your" sensors in the context of key sensing and thought they were "a bit" too slow for that. Hammer sensing is complicated by higher speed, shorter distance, and trying to take measurements really close to the place where they bounce off something and start going in the opposite direction. Probably an order of magnitude, and then some, too slow for that. (With the other two orders of magnitude between them and the Cybrid then being the "colevity" thing).

xooorx Hammer sensing is complicated by higher speed

From the measurements I know of, key velocity is actually faster than hammer velocities. ff struck keys (not pressed with fingee contact throughout) are faster then hammers.

vagfilm I'm working from papers with diagrams like this and similar:

(Touch and temporal behaviour of grand piano actions)

which shows hammer velocities at generally around 5 x key velocities, as would be expected from the leverage in the action. (Which of course means the hammer travels further too... except we only want to look at the final 2mm of free flight hence me saying it's complicated by higher speed and shorter distance).

There are certainly moments in these plots where the key is travelling faster than the hammer, but the overall range of speeds to be measured is more for the hammer.

Oops... Embarrassing mistake: overlooked the different scale between hammer and key (force of habit... For easy comparison between conditions, in biomedicine we tend to prefer comparison over absolute values, and usually stick to using the same x and y scales in all panels if the same figure, whenever appropriate). You are absolutely right (and yes, this is the paper I usually refer to).

My error was also caused because to me the important thing in this figure is how fast the key moves from min to max in ff struck, because that determines the needed time resolution of the sensor.

I was good enough, so I got my Christmas gifts in the mail.

I assembled them as follow. Not super neat (I too like cables out of the way, and that's a painstaking activity to get right), but much better than air cabling. On the breadboard, I also like cables of the right color, which was a pain because the ones I had were colored by the length:

Here are some details of the connections on the Pico side:

Here are some details of the connections on the sensor side:

And of the sensors themselves. That is a Everligth EAITRCA6 on the left, a QRE1113 preassembled by sparkfun in the center (https://www.sparkfun.com/products/9453), and a well-known CNY70 by VISHAY on the right. All the LED have a 100Ohm resistor to limit the current, and all the phototransistors are wired in the same way with a 10kOhm resistor before Vcc

I adjusted their location on the breadboard such that they lay approximately at the same height:

And then I did some trivial programming on the Pico to turn them on and see if they show anything in the output. Not sure yet about the last part (too tired to try all three of them at the same time, but one at the time they worked).

When the LEDs are off, this is what it looks like:

When it's on, it's cute to see that the LED illuminates. Human eyes do not see it (pretty much I saw the same as previous image), but most cameras are sensitive to IR and they show it! As follows:

In the coming days I will run some tests and decide if there is a sensor that I like most from an electrical or optical point of view. I strongly prefer the smaller ones (both EAITRCA6 and QRE1113 are exactly the same package, but pins are different), and the surface mount (the EAITRCA6 can be gotten with short leads). Moreover, the EAITRCA6 is slightly cheaper than the QRE1113 and both are about 1/3 the price of the CNY70. Not a huge deal, but noticeable saving when multiplied by 88 (notes) x2 (hammer and key) + 3 (pedals). Most importantly, they fit my mechanical design much better.

So stay tuned!

One particular consideration I have for the CNY70 is the rim it has with the phototransistor and the LED being on the inside and lower than the rim. I haven’t made any measurements though but intuitively I believe it helps in preventing cross-talk from neighboring elements.

CyberGene One particular consideration I have for the CNY70 is the rim it has with the phototransistor and the LED being on the inside and lower than the rim. I haven’t made any measurements though but intuitively I believe it helps in preventing cross-talk from neighboring elements.

Yes, that's a good point. Also, that rim prevents the possibility that the object to be sensed gets too close to the sensor, reducing the signal, because the fototransistor is looking at an area which is outside of the illuminated region (this can be seen in all the datasheets, and one of them had the simple geometry explanation of why it is and can't be easily solved).

In fact I have some aces in my sleeves for exactly this thing, and how it applies to the smaller sensors. I'll play them in due time 😀

Preliminary result. The object for now is a hand-held aluminum bar. Next it'll be the piano keys (under the back action). I suspect the differences from one sensor to another are due to the different location of the sensors wrt the bar, which cannot be perfectly at the same distance and angle from all of them.

When nothing is present, this is what I get:

When the bar is held close to the sensors, this is what I get (too short of a time series to compute coherence in this case):

When I move the bar back and forth in front of the sensor (close/far) this is what I get:

From the last plot one might conclude that the QRE1113 is the worse performer, but that would be a rushed conclusion. Other attempts showed it performing better than the other sensors, e.g.

and

In these last two plots the CNY70 was loose from the breadboard because the length of its terminals is too short for such an arrangement, so please ignore that.

In all top graphs, y axis is the raw data out of the RPi pico, which is 12 bits, however only about 9 bits are usable (obviously does not matter for the plot). The x axis is time in second.
The bottom graphs are coherence between each pair, vs frequency of the signal in Hz. I'm moving the bar very slowly, hence plotting only up to a couple of Hz. For curiosity, I will check if I could see the 60Hz of the power line.

Raw data and software utilized for capture on github

I posted the followup to this in its own thread here (with link to more detailed data and plots on github)

xooorx The Cybrid, the VPC1, any of the 2/3 squidgy switch based systems, anything with a light gate waiting for a slot to pass through it... none of these systems are measuring velocity (distance/unit-time) directly. They are all measuring colevity (time/unit-distance) and then calculating a velocity by taking the reciprocal of the measured colevity.

(Yes, OK, "colevity" is a word I just made up, but it's still the thing that all these systems are measuring).

@xooorx you are not the same person as @Gruust on PTQ's site, are you? Reason is, somewhat I thought you were, but if you aren't I should ping that other person to come at least lurk (if not contribute) here. See e.g. https://forum.modartt.com/viewtopic.php?id=8956

RIP @xooorx you are not the same person as @Gruust on PTQ's site, are you?

No, I'm "xooorx" on here, on PTQ, and on PW.