First real signal & some mechanics

[jkominek]

I've had an action for some weeks now (feels like ages), and finally got enough frame built up around it to hold one of the CNY70s over a hammer shank.

The sensor is on the underside the horizontal 2020 rail, carefully positioned so you can't see it at all. 😄 The grey, green, brown and blue wires give away its position. It's over the B0 hammer shank. The LED is getting slightly more than 20mA, and the phototransistor is sitting on top of a 1800 ohm resistor, and the two of them have 5V applied.

There's some regularly occurring fuzz on the signal, at 120Hz, so I'm guessing the long wires/cable I'm using are picking up something from power lines. The BNC-to-dual-alligator clips cable I'm using on the scope was $5, so I expect they skippped the shielding. Not worried.

And finally, a short video of the oscilloscope as the key is struck repeatedly: https://www.youtube.com/watch?v=-9GIGnnsfAU

It turns out that placing the sensorboards I'd designed over the hammer shanks with an extrusion in the position depicted isn't actually great:

1. I had to make a custom hex wrench in order to tighten the M3 screws holding the sensor PCBs into the rail. And even with the wrench, it is still a complete pain. There's just no room to rotate even a tiny wrench.
2. I decided it was important to ensure the action could be slid out of the digital piano, for ongoing regulation, without having to dismantle part of the piano or sensors. That means I can't leave a rail that would block the hammers from sliding out.

So I've got new sensor boards, and custom cut aluminum extrusions on the way so that I can position the CNY70s at the back of the action. One row of them being directly struck by the hammers, and another row suspended over the key sticks, behind the backchecks.

[davidedelvento]

Way to go!! :-)

What do you mean "position the CNY70s at the back of the action"? What do you have in mind?
To slide the action out, I would have put the 8020 rail on a hinge on one side. To ease installation (and adjustment?) of the sensors, can't you use an L-shaped extrusion attached to the 8020?

[davidedelvento]

To clarify what I mean with option 1. I had in mind something like https://prometheuscinema.com/factory-3765-slotted-metal utilized as follows:

here the red is the PCB, green is the cable and the slotted metal extrusion is seen in section. Of course the ones from the website I linked it won't work (not enough "lip" for protection, too wide of a hole and not a proper way to attach the PCB), but perhaps somebody builds something like the 40x40 but with holes? Misumi does provide a service to customly drill extrusions, and with holes of various kinds, see https://us.misumi-ec.com/pdf/fa/2012/p2_0687.pdf https://us.misumi-ec.com/pdf/fa/2012/p2_0689.pdf and https://us.misumi-ec.com/pdf/fa/2012/p2_0691.pdf -- but I was hoping of something stock off-the-shelf.
Alternatively we could drill the holes ourselves? If everything is perfect about this arrangement, drilling that many holes does not sound too big of a problem with the right jig. But still it's a maintenance hassle: if one PCB or sensor goes bad in the middle of a section (or in the middle of the keyboard if we use a single section for everything), than half of the PCBs in that section needs to have their cables detached from the board, removed, go out of the slot, and then the reverse including adjust/align with the hammer. Do you anticipate PCB and sensor to be so reliable to never require that?

[ekumanov]

You should also take into account that the bass hammers hit another set of strings that are sitting higher than the rest (the bass strings diagonally cross the other strings and are about 10mm above them). It's not easy to regulate the action to strike at a single level because the bass hammer heads are drilled for the shank insertion to accommodate for the higher striking point. This means your hammer stop rail should be at two levels. This is the reason why I decided that my stop rail would be at shanks, just before the hammer heads, because the shanks are level.

[jkominek]

I measured the string height in the donor piano, and as near as I could tell, it was the same for all of the strings. Without taking careful measurements, it looked to me as though the bass strings angled up from the pin block, and the treble strings angled down, and at the line where the hammers impact, they were within a few millimeters of each other. Seemed odd, but who am I to argue with the measuring tape? Definitely something anyone doing this should keep it mind.

Regardless, I've split my hammer stop rail into three pieces. Here's the bass portion of what I hope will be my final design. Just got it on this afternoon.

[ekumanov]

Very clever piano design! So, it's OK then. What brand is it and how old?

You're so close to the finish line now. Can't wait to see your results 👏🏻

[davidedelvento]

The accurate way to measure hammer-string distance is described at http://www.pianosinsideout.com/PracticalTouch_HighRes.pdf (great book, by the way)

Since you (and I) can't do that anymore, we can still adjust the height of the virtual strings with this split design and make sure the action is withing its regulating parameter.

[jkominek]

Four hammer strikes on four sensors "simultaneously". Very nice to see there's no cross talk. (The picture is very small, you'll have to take my word for that.) I'm also amazed I can hit four pianos keys with +/-15ms precision. It certainly doesn't feel like it when I'm practicing. 😄

My initial "four sensor" spacer plate was too thin, and I got signals with a big V in the middle, probably where the hammer got close enough into the sensor to ensure that no light from the LED could reflect back onto the phototransistor. That's consistent with the earlier issue. So you definitely need to keep the hammer 1-2mm away from the sensor.

Tomorrow, I'll either get some sensors on the ends of the key sticks, or try actually attaching the ADC board to these four sensors. Or both!

[davidedelvento]

I don't see the 1mm issue on the oscilloscope am I supposed to (and I am missing it) or is it not visible in the picture?

What else to say? Fantastic progress, congratulations and thanks for sharing! Looking forward to finish fixing my action and trying to get my hands on your electronics to try it out!

[jkominek]

Sorry I keep not taking a picture of the problematic signals because I look at it and say "oh that's garbage i need to keep working on this" and then only take a picture when I get some place nice. 😄

But I should get pictures because they'll be diagnostically useful for anyone else setting this up. I'll try to replicate them today.

Until then, here's a picture stolen out of one of Greg Zweigle's videos:

We see the signal peak, and then dip back down, and then at the very right edge, start coming back up. I think that's the shank getting too close, and then falling back to more measurable distances.

[jkominek]

Here's two bad signals. The first one is my hand-holding the sensor as it is directly struck. So it's... smooshy. I obviously can't hold it as rigidly as an aluminum beam, so the signal sits up at the top for ages, as the hammer pushes on my hand. The time scale on this one is 10ms per division.

The second is four sensors, held rigidly by the beam, but the "sensor protector" is too thin, and allows the hammers to get too close to the emitting surface of the sensor, and so the signal drops back down again. This one is back to 2ms per division.

I wish I could get my oscilloscope to save images to a USB drive. Sigh.

[davidedelvento]

Perfect thanks! Exactly what I imagined, but good to see it in pictures.

Regarding your wish, last time I used oscilloscopes, they were two channels only, and huge, deep and heavy B/W CRT ones. We needed dedicated supporting shelves costing more than what you paid your device! So I am actually enjoying seeing how nifty is yours, with colors, 4 channels and almost pocketable (and yes, I've seen now they have pocketable ones too, and I am thinking of getting one)

[jkominek]

Here we go, an actual hammer strike, collected from data sent via one of the ADC boards:

If you're fluent in gnuplot you can note that I'm flipping the 16 bit value around, which is necessary and expected because the transimpedance amplifiers turn a 0 current signal in to the ADC's max input, and higher currents result in lower voltage inputs to the ADC.

With that done we're getting a signal range of ~2000 to ~20000. We're losing about 2 bits of range, and we've got a couple bits of noise (no attempt was made to figure out how many bits of noise there are 😄). Not bad! The code I'm running to collect this is hacked together junk, so there might be some dropped samples, the time base is hand wavy at best, etc.

I think I'll assemble one of the ADC boards from the most recent revision, and then I can start writing real code for it.

[davidedelvento]

Nice. Considering that from all of this curve you need only two numbers [*] it looks more than good enough to me. Obviously making it better won't hurt, but it looks like we do not need to sweat it :-)

[*]: for the casual reader: the two numbers are a time (the x-location of the peak of the curve) and an integer for the velocity, which in most cases could be just a 7 bits number, even though it would be nice to have more bits for the two versions of extended MIDI which support it velocities with higher resolution.

Three more questions:

1. Is the flattening on top the same thing we discussed of hammer getting too close to sensor?
2. Are you settled for hammering the PCBs and not use a transparent or perforated bar as a vibration protection? I was thinking of something like https://us.misumi-ec.com/vona2/detail/110300466750/ mounted independently from the PCB (obviously that will need to be perforated, and MISUMI can perforate it for me, but only 5 holes per section and not the several dozens I need -- perhaps I should ask if they can do it as a special order). That is 2mm thick though, so with it, some spacing and felt, one easily gets around 4mm distant from the sensors. Even with a transparent and/or thinner one, I doubt it can be done closer, so that bring the last question for now:
3. My understanding is that for optimal performance you want the hammer to arrive at 1-2mm from the sensor, correct?

[jkominek]

Obviously making it better won't hurt, but it looks like we do not need to sweat it :-)

Yup yup, we're in the ballpark, this isn't going to need radical hardware redesign or anything.

1. Is the flattening on top the same thing we discussed of hammer getting too close to sensor?

Good question! I'm not sure what's going on there. I assume that the hammer is getting just a tiny bit too close. I've only checked one of them, and I'm using a sensor on the edge of a 4 sensor board, so there's less material around the sensor to keep the hammer off the sensor.

FWIW the sensors and setup were jostled and adjusted between the last good oscilloscope photos and this attempt.

2. Are you settled for hammering the PCBs and not use a transparent or perforated bar as a vibration protection?

I'm not settled, but figuring out the best option for that does not seem to be blocking any other work. I hope that whatever calibration system is concocted in the end will be able to produce a useful calibration despite variation in distance between hammer and sensor at closest approach.

I'm not opposed to doing something that would protect the sensors, but I'm also not worried about failures in the PCB any time soon. The solder joints are the most likely candidates for failure, and a coat of epoxy over them on the back side, and some around the base of the sensor on the front would do wonders for them.

3. My understanding is that for optimal performance you want the hammer to arrive at 1-2mm from the sensor, correct?

My 3D printed widgets are 2mm taller than the sensor by design, and seem to be ok. I'd err towards more space rather than less; roundness/deformations of the hammers and their positioning relative to the sensor might have some effects.

[jkominek]

I dumped 15kHz data into a file and put it into a Gist: https://gist.github.com/jkominek/d0c3da99e5edb7396fec9a61f9a0eccd

First column is wall clock time, to the best of the ability of the processor's RC oscillator to measure (let's call it in +/-5%), and the second is the signal off the CNY70, measured at 16 bit resolution. There's quite a bit of noise down at the low end. I'd definitely be investigating that more, especially since it seems to have some 120Hz/240Hz structure to it. I might be picking up something from a switching power supply. The CNY70 LEDs are still running off of a simplistic LED, rather than the very nice one I designed. (:sunglasses:)

But if anyone cares to try and process such things, there you go.

(Notes: I used a larger gain resistor on this board, so the values are slightly higher than we saw in the previous gnuplot image. And in that previous image, I had a low pass filter in the firmware that I'd forgotten about. I've commented that out, so this is 100% raw ADC readings.)

[jkominek]

I FFT'd the noise, and get very different spectrums depending on how I power the LED driver I'm using. Disconnecting the power to the CNY70 LEDs drops the noise dramatically. So the ADC board ought to be fine.

I probably need to improve my sensor boards, though. I threw the current versions together rather quickly, and didn't think about the power and signal traces overlapping. Nor did I include any copper pours which could be tied to "ground" through the mounting screws.

[jkominek]

I switched over and I'm driving two 4 sensor boards with one channel of the LED driver board, so 8 CNY70s. It's intended for use with 20 to 25. It can drive fewer, but the MOSFET has to dissipate more heat. (It could probably even be short-circuited briefly, but I'm not going to test that...) So:

1. The MOSFET holds up and stays hot but not painfully so just doing 8. That's good, I didn't think it would fail, but I was concerned it might exceed 60C.
2. The super-stable, super-low noise LED driver board is actually low noise! Compared to the junky board, anyways. All of the structured, repetitive noise on the signal is gone. All I see now is small, high frequency stuff, which is cleaned up with just a bit of low pass filtering.

I should probably put up some more data now that it is cleaner, and include both key stick and hammer, from piano to forte. Oddly, there's a little ringing in the key stick signal. I'm... 99% sure the dumbest possible IIR low pass filter I'm using can't cause that. So I'm assuming it is mechanical. The wood of the key stick wiggles, perhaps, on millisecond timescales?

[davidedelvento]

Aha, so you are pushing the specs, eh? Good.

Re: wiggling, I don't know that there is any solid data on this issue, but it's a known thing that we want the keysticks as rigid as possible (hence they are relatively thick) but as light as possible (hence they are made of softwood). A similar need of contrasting needs happens for the hammer shanks, and that has been studied more extensively, however the only public information I know of is this video: https://youtu.be/_BRvtUGDHJ8?t=73

Perhaps if you have a high-resolution, high-speed camera (go pro?) you can try to record the keystick movement from the side and study if you see anything like that? Even if you don't have such a camera, most modern phones might be adequate enough in resolution and "slowmo" mode as they call it? Certainly worth a try.

[jkominek]

Sound!

https://youtu.be/oOU-k6UbhCA

I've got the ADC board converting some timings on the peak into velocity-like numbers, and sending them on. A little toy python script reads the messages (which would normally be interpreted by the main board) and turns them in to MIDI, sends them through loopmidi, and they're picked up by pianoteq.

Huzzah!

Tentatively the resolution doesn't look bad, with the haphazard calibration values I threw together for this single bass hammer, I've got every third (7 bit) MIDI velocity at the high end of the scale. And four or five times more values than necessary at the low end.

Next steps:

• Assemble enough sensor boards to get an entire ADC board worth of hammers going. Check behavior.
• Get some code on the ADC board so that whatever is upstream of it can adjust the per-key calibrations.
• Assemble some of the sensor boards for the key sticks, start seeing how they behave.

[jkominek]

Tiny little update: still alive, no problems, just not very productive, and what productivity I did have was directed elsewhere.

Before the hiatus, I did finish assembling enough sensor boards and cables that I've got 11 keys all wired up (hammers & key sticks), and attached to a single ADC board.

And I left the LED power board running continuously for the last two and a half months. On brief inspection, it appears to still be working fine, but one of the indicators LEDs failed. Zero light, but still electrically conductive. Very odd, didn't realize they could fail like that.

Tonight I put together some code for receiving/verifying messages sent to the ADC board over its serial link. (Somehow getting bidirectional UART code working on microcontrollers is always very satisfying.) Now for the calibration code on the boards and PC...

[davidedelvento]

Very weird that a LED constantly on would fail like that. I thought that the life of a LED was much, much longer if constantly on, or limited by the on-off power cycles (in my house the dimmable ones seem to fail much more quickly, if the dimmer setting is changed constantly).
Is it possible that the unit was defective and failed for that reason?

Looking forward to the progress!