Build your own DIY hybrid piano - step six putting it all together

RIP Tomorrow I should be done with the power supply too, which I made by using an off-the-shelf Bel Power Solutions HB48-0.5-AGbelfuse.comhttps://www.belfuse.com/resources/datasheets/powersolutions/ds-bps-linear-series.pdfNo preview could be generated for this link feeding six 20mA, Temperature-Compensated, Constant-Current, CL220ww1.microchip.comhttps://ww1.microchip.com/downloads/en/DeviceDoc/20005413A.pdfNo preview could be generated for this link. I need six since each LED could drop voltage by up to 1.6V and there are almost 180 of them, so using a single CL220 would require 180*1.6V which is too much to deal with, whereas making 6 circuits in parallel would work with the 48V out of the Bel Power.

That’s a clever solution. Sad that I missed it when designing the Cybrid, would have been very useful.

nice progress!

The code includes two hammer velocity algorithms.

See the hammer_settings.cpp file and the hammer_strike_algorithm variable.

The default is 0 which doesn't require precise thresholds but does make assumptions about tracking the hammer motion starting from its rest position.

The other option (1) uses a threshold at the letoff. Looking at your setup, you may want to use hammer_strike_algorithm = 1. Then, adjust the strike_threshold value, and possible the velocity_scale value.

I made a video showing the hammer position for all 88 keys when playing the piano.

https://www.youtube.com/watch?v=AWMlzoCq9G0

gzpiano I made a video showing the hammer position

I saw that, thanks!

gzpiano The default is 0 which doesn't require precise thresholds but does make assumptions about tracking the hammer motion starting from its rest position.

The other option (1) uses a threshold at the letoff. Looking at your setup, you may want to use hammer_strike_algorithm = 1. Then, adjust the strike_threshold value, and possible the velocity_scale value.

Thanks for explaining that. I thought it was the case and I intended to explore it today, which I will now do knowing it, rather than randomly!

Today's update: https://github.com/gzweigle/open-hybrid-piano/issues/109

Further updates (I should probably re-write the same thing here and perhaps I will after I try with batteries as described there)

Before the update about this weekend, summary of last weekend work:

Initially I had troubles to get any decent detection of hammer movement. After playing with various parameters, with the help of @gzpiano I settled on the following, which allowed to detect hammer movements (both as ADC values and as MIDI note on and off -- even if the latter only marginally)

  velocity_scale = 0.10;
  calibration_threshold = 0.8;
  damper_threshold = 0.22;
  damper_velocity_scaling = 0.025;
  hammer_strike_algorithm = 1;
  strike_threshold = 0.7;
  release_threshold = 0.90;

The most important ones were

velocity_scale = 0.10;
strike_threshold = 0.7;

At that point, I could detect the hammer movements, which in the ADC showed as following

zooming closely on the "flat" areas I noticed a peculiar noise

which has an evident periodicity, so moving into the frequency domain

it's clear that the noise is coming from the AC at 60Hz. Somewhat strangely, it includes very strong components from very high harmonics.

Preliminary work during that weekend did not point to a specific culprit or mitigation: light source was immediately ruled out (the piano is in an enclosure, certainly not sealed but not directly exposed to light, which I had turned off anyway and kept the door closed); any other power supply that had on hand still showed the same problems. But I did not really have good, certain alternatives (for example, I had a power bank, which most likely has a step-up from the 3.7V of the battery to the 5V of its output).

Finally, this week, I was able to fully power the system on battery (D-cells, 9V and others). All the external power supplies were off, and the only connection to the computer was the Ethernet cable.

Surprisingly, the results were almost identical!

So I concluded that one (or more) of the following must be true:

• the noise is injected from the computer via the Ethernet connection
• the noise is picked up by something -- the only possible external source is the computer, and the high harmonic count is consistent with this
• the noise is generated internally by either the IPS or the SCA or the Teensy

To debug the first option, I'd have to change the firmware to save the hammer data on the onboard memory and download it later.

The second option would be very strange: for this test I am using twisted pairs (ethernet cables) connected to the sensors via very short (1") jumper cables, also twisted. And Greg is using flat ribbons, so he would be much more sensitive… even though his environment may be cleaner

The third option would also be strange, since Greg's data does not appear to have this problem:

But this is low resolution image and not zoomed in. @gzpiano as a first sanity check before I embark in much more complicated debugging, can you please zoom in around the "zero" line on either plot on the left to see if it shows anything? TIA (and let me know if you prefer to have this conversation on github instead)

That's quite a mystery.

RIP can you please zoom in around the "zero" line on either plot on the left to see if it shows anything?

Just checked. It has a small signal at 120 Hz but nothing else. 1.5e-3 peak-to-peak on a normalized basis (1 = ADC full scale). I may have had lights on during the test. I've noticed that this system will pick up even faint light from an adjacent room.

With some work you could write firmware that saves a buffer of data without Ethernet connected. Then, connect Ethernet to retrieve.

Or, maybe a faraday cage 🙂

gzpiano Just checked. It has a small signal at 120 Hz but nothing else. 1.5e-3 peak-to-peak on a normalized basis

Thanks a lot for confirming so quickly!

gzpiano I've noticed that his system will pick up even faint light from an adjacent room.

Yes, I've noticed that too, but this is definitely not that.

gzpiano With some work you could write firmware that saves a buffer of data without Ethernet connected. Then, connect Ethernet to retrieve.

Yes, that is what I thought, maybe using one of the currently unused switches to trigger. Since you don't have that signal and I have another board, I need to decide if I want to embark myself in that debugging-development (could it be useful to other people?) or maybe try a different computer (that should be easy, once I find a suitable one, or a long enough ethernet cable) or even using (on the testbench, not on the piano) the other IPS I have with something more similar to HPS and no ACE, to make the system much closer to yours. I guess that's all options for the next weekend, I'll now sleep on it.

gzpiano Or, maybe a faraday cage

I see you are (half?) joking but I'll respond seriously for others who might be reading this. Yeah that would screen some electrical noise, but if it's coming from the cable it won't help at all, and even if it isn't coming from the cable, my geometry is such that it can't be 100% enclosed, so I need to understand root cause before attempting that 🌩️

Thanks again

My recollection is there is a DC-DC converter in the system? If so that is a difference to my setup.

Idea… the IPS has 3.3V LDO installed. Breadboard a sensor, connect sensor output as you have now, but connect its power to an IPS 3.3V power pin, put a piece of paper close to the sensor. If the noise stays the same or disappears is a clue.

gzpiano My recollection is there is a DC-DC converter in the system? If so that is a difference to my setup.

I have not added any DC-DC converter, so if I have one it's anything you have too.

What I added power-supply-wise is a linear regulator which spits out 48V with some ~5mVpp ripple (so extremely small, I'd be shocked if that contributes at all in this problem) and feeds a constant current feed (which leaves the voltage value alone and should not change anything noise-wise for the power supply). However both were off for this battery tests, so they cannot be the root cause.

gzpiano Idea… the IPS has 3.3V LDO installed. Breadboard a sensor, connect sensor output as you have now, but connect its power to an IPS 3.3V power pin, put a piece of paper close to the sensor. If the noise stays the same or disappears is a clue.

Thanks for the suggestion. If I understand this correctly, this is basically what I have done, just using the battery power rather than the IPS-provided one, which is indeed a clue.

And here comes this week update. After many tests, I've pinpointed the source of the noise.

The excellent news is that there's nothing wrong with the design of custom electronics boards, neither the control board, nor the sensor board.

The good news is that the LED constant-current power supply which I built (based on the linear voltage supply I purchased) is just fine as I thought/hoped.

The culprit is computer which I wanted to use to control everything. Even powering everything by batteries and connecting only the Ethernet cable to capture the ADC data injected the noise. Powering the LEDs with the linear constant-current supply, the piano with the batteries and connecting the prototype to a remote computer with a very long Ethernet cable (because I can't move the computer let alone the piano) shows no sign of that noise.

On the other hand, I now need to figure out how to power the main board from a different place than the USB, which probably mean from the same (or similar) power supply I already have (but if I use the same, that has a too high voltage, so I'd need to step down twice -- need to think about it more).

I also need to investigate if the same problem arises when connecting to the computer via MIDI rather than USB, since I had no time to run that test yet (I doubt it since @gzpiano tested the heck out of it, but it's not impossible since perhaps his chain is cleaner than mine). If necessary I need to nudge him to design some sort of filter to prevent this problem from happening. Also, I need to ping @vagfilm and @Akari -- guys you need to make sure you don't inadvertently run into it too, since you want to use the USB-MIDI rather than DIN-MIDI.

I guess this data is useful/interesting for @DavisB too, in the sense that powering from USB makes a lot of other challenges arise, as we were discussing in this other thread

And for completeness, I think also @xooorx @candela and @aleath -- guys, sorry if I just made noise in your inbox, but perhaps this is useful information for you too (just let me know if you prefer refraining me from pinging you like this in the future)

RIP My boards are still wrapped up. Like good Port wine, they need a long rest period before seeing again daylight…

Two small updates (Sunday is still young here, so I might be able to do more for today, but here it is).

• The computer-injected noise as expected varies a lot with various machines. With some logistical challenges I tried various computers that I have and found than an old iMac (10 years old or maybe even more, running lubuntu) has decent power supply and can make the board work without excessive noise. I mean, it's still visibly much more than on battery power, but it's not as horrible as with that Thinkpad, so I'll go with it, at least for now (at that might be a clue to why sometimes Apple computers sound "better" than non-Apple laptops). The noise in the measured ADC peak-to-peak signal is 0.5% in the Thinkpad, with a very clear spectrum of 60Hz harmonics (see the picture I posted above), whereas it goes down to 0.1% on the iMac with a pink-noise like spectrum to basically disappear at a 0.03% with batteries (again with something like pink-noise spectrum). Note that the batteries-powered data has been captured on the iMac itself, connected to the instrument just with Ethernet (a setup in which the Thinkpad also injected much more noise)
• I may be biasing my sensors a bit too much, in fact the peaks are not peaks, but flat-ish for anything between 8 and 30 time steps, with about 16 time steps being the most common (see picture below). Given the geometry of my sensor protectors, it might be that the hammers "hang around" that point for that long, since they may still be "approaching" as a whole, but the small section in front of the sensor window could be stopped by the protector, as designed, to prevent the sensors from being "hammered". But it's also possible that I'm instead just clipping. If I am doing the math right ( @gzpiano ?) 30 time steps at 300us is 9ms which seems too long of a time. Even the "fast" case of 8 time steps turn out to be 2.4ms which is also too long for a peak?

The data above is captured with the default software/releases/ips2_analytics/get_hammer_data.py and the firmware is also running default settings for multiplexing, timing and the likes (the only non-default settings are about the thresholds).

@gzpiano I know your geometry is different, so it may not be an apple-to-apple comparison, but do all similarly zoomed-in plots from your strikes look like the one it's in the repo? In that case the "really" flat part is just 2 time steps, however on the second strike you posted has a "flat-ish" area of about 13 time steps (see pictures below). Do you think I should update the interposer boards or your algorithm should be able to cope decently with this issue?

Greg's peaks

I can measure ~5ms of "flat" time. To determine how much is due to padding decompression I checked with a solid steel bar and even that has several milliseconds. Many things are deforming and moving and vibrating when the hammer hits. Not only the hammer but also the sensor itself.

For the threshold-based velocity algorithm it shouldn't matter.

gzpiano I can measure ~5ms of "flat" time.

Thanks for confirming.

gzpiano For the threshold-based velocity algorithm it shouldn't matter.

This is great to hear. So for now I'll proceed with the ACE interposers I have.

Keep you posted!

Are the sensorboard gerber files also in the repository?