DIY piano sensors

RIP · 2021-12-14T22:14:39+00:00

This is mostly a question for @CyberGene but I think making it public could help others, in the same way that your pioneer project inspired many followers (including myself) I am arriving at the sensor stage of my project and I decided to test a few of them. @CyberGene Pretty much every DIY these days is using the CNY70 sensor which your groundbreaking project selected. I've found your posts on a variety of forums discussing the options you were considering at the time, but I did not find any of the class below. For example, the same manufacturer of the CNY70 sells many more sophisticated sensors, such as this one which goes "for peanuts". For less than 3 dollars you get one surface mount chip which includes: LED emitter (like the CNY70) Fototransistor receiver (CNY70) 16-bit ADC with offset compensation for temperature drift and ambient light influence I2C bus with high speed mode other stuff less important brews yourself a coffee and serves it in a golden cup From a cursory look, it might be possible to just put a bunch of these chips on the same I2C bus, and with a simple I2C controller get everything one needs for a DIY piano! Just the sensors you want (176+3 in my case for note on, off and pedals) and a single other board. No potentiometers. Free, industrial grade ADC and bus just there waiting to be used, without the need for one to design and implement them. Back of the envelope math indicate that the bus speed (3.4MHz) and capacity (1008 devices) is more than adequate for the amount of traffic expected, and any GHz grade controller should have enough horsepower to handle all the incoming digital data. But even if not, splitting the keyboard in a few sections with a few controllers would still be easier than all the other approaches I've seen. I'm really surprised nobody else mentioned these, so I must be missing something? Note that the one I picked is pretty much just a random one among many similar ones Vishay makes -- and I have not looked at other manufacturers yet (but I know that Evec makes the EAITRCA6 which is direct competitor of the CNY70, and the main one which I intended to test side-by-side when I accidentally found these with ADC and I2C integrated in the same die) So the question is: back in the day, did you evaluate this category of sensors and discarded them for some reasons which at a cursory glance I am missing?

vagfilm

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.

xooorx

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.

vagfilm

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.

RIP

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!

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.

RIP

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 😀

RIP

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

RIP

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

RIP

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

xooorx

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.

RIP

xooorx delvento @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.

Thanks for confirming. I'll reach out to that person then. Meanwhile, you (and others) might want to lurk or chime in the conversation at https://pianoclack.com/forum/d/289-scanning-speed-and-velocity-mapping-of-cybrid

« Previous Page