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

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?

CrisOliveira Are the sensorboard gerber files also in the repository?

Depend on which repository you mean. Not here since as the name says that particular order did not include sensorboards.

However they are included in other repositories.

The ones I ordered myself are these ones and the page include a link to the exact order I placed.

The ones that @gzpiano purchased are these other ones (I believe, he might have purchased the v0.7 rather than the v0.8 I linked)

Note that mine use a smaller sensor (which is a big advantage, IMHO) and everyone else's use a larger one. Mine are made to be installed at the hammer (but could probably be installed at the shank too). @gzpiano are made to be installed at the shank. And then you have Jay's ones which are made to be installed at the hammer and use a larger sensor, see here

Hope this helps, and don't hesitate to ask if it doesn't or if you have follow ups!

Getting ready for a lot of cables….

And here it is in (almost) half of its gory details!

And if anybody did not believe me when I said the most important thing of the project was cabling…. keep in mind that these are just half of the cables!

Now, following the advice from @gzpiano I should disappear for 8 years as he says here

Attend Juilliard, Curtis Institute of Music, or Berklee College of Music for eight years and get a PhD in piano.

Before I do that, you may want to head to a sloppier playing happening now

vagfilm
Same for me haha, opened the package once to see if they were there in the first place 😂😅