Interference Issues

April 11th, 2024
emandoharp, jammer, mandolin, music, tech
I've been working on building an electronic harp mandolin (previously, previously, previously). I got it all hooked up, but unfortunately I'm running into pretty bad interference, and need to redesign it.

Going back a bit, I had designed a circuit for testing and breadboarded it. It worked very well, and I wrote a bunch of code to interpret the pluck signals. [1] Here's a video of the breadboard version, showing both velocity sensitivity and direction detection:

I did a bit of soldering and got the full version hooked up:

Unfortunately I got very large amounts of interference. Here are all 18 pins, though only 13 have piezos attached:

It's even worse if move my hand close, and terrible if I touch one of the teeth:

Note the change in scale:

This looks like powerline interference, sinusoidal at ~60Hz. And then even if I don't touch it or do anything, I'll see spikes, which I think are probably other radio interference?

I made some attempts to fix this in software, though nothing super sophisticated. One option is to figure that mains interference affects all the pins equally and is close to synchronized, so we can just subtract the average across all pins from each pin. This works pretty well, except we still see those spikes:

I guess those hit different lines differently, depending on which path each takes through my ball of wires?

A different idea was to compute the correlations between each pair of pins, and use the two most similar pins to denoise each pin (you can't use just one pin, because then you can't tell which was plucked). This worked better for some pins than others, and didn't resolve the spikes:

Possibly I could do some sort of low-pass filtering to remove these spikes, but I'm guessing this is better to fix in hardware?

I think the key question is, why did I get good results with the breadboard prototype, but not the full version? I can think of a few things I've changed:

  • I now have 13 teeth hooked up, instead of one or two.

  • All 13 teeth are electrically connected on the black side, which includes the metal of the teeth for 11 of them (on 2 the brass of the piezo happened to end up insulated from the tooth by a full layer of epoxy).

  • All teeth share a black wire to the board, so I'd need to hook fewer things up, but maybe breaking the symmetry here was a bad idea.

  • The piezo wires are thin and short, and I soldered on extensions to make them easier to work with, but these longer cables should be better at picking up interference.

All of these sound not ideal, but I don't know enough electrical engineering to figure out what to prioritize, or what to test. After a bit of reading, here's what I think I should do:

  1. Instead of bare signal wires and a shared black wire, switch each piezeo to shielded cable.

  2. Put the board inside a metal box (or a cardboard box wrapped in tinfoil in testing).

  3. Redesign the board so the piezo ground is true ground, and use an op-amp to bias the output up.

  4. Possibly: remake the teeth so that the pizeo ground is electrically isolated from the metal of the tooth.

  5. Possibly redesign the board to use a star topology for grounding, where the pizeo grounds only come together at a single point, avoiding ground ground loops.

I think I'll probably start with the first two, since that doesn't require redoing the board. But I think that probably won't be enough, since I can't ground the cable shields: the current design has them at +1.65v.

Other suggestions?

[1] The main thing that made it tricky is that I wanted different notes plucking down vs up ("bisonoric"). Here are the shapes of some of these waveforms, taken from the breadboard version:

Some observations:

  • When I pluck gently there's a single sharp peak, negative for upstrokes and positive for downstrokes.

  • When I pluck more vigorously the sharp peak is proceeded by a broader peak in the opposite direction.

  • The sharp peak is generally greater in magnitude than the broad peak.

I initially coded a classifier that did the simplest thing that could possibly work: wait for the input to exceed a threshold, and then take the most extreme value you saw over the next N samples. If that's negative classify it as an upstroke, positive classify as a downstroke.

For how simple this is it works very well: it gets more than 95% of the plucks correct. But that's not good enough for a musical instrument. If I'm going to play wrong notes I want it to be because I made the wrong movement, not because I got unlucky.

This weekend I flew to CA to play a dance weekend and this seemed like a fun problem for the plane, now that I have an ergonomic stacked laptop monitor. I saved a bunch of examples of up and down plucks, and tried to write a classifier.

It seemed to me that there were two scenarios: either there was only the sharp peak, or there was a sharp peak proceeded by a broad peak. And if the broad peak was present, it was a completely reliable indicator of direction. So I could add "broad peak detection" to my algorithm from before, and if it said it found one I could use that to decide on the direction, falling back to simple magnitude if it couldn't.

The broad peak detector is quite simple: count how many samples the signal goes without falling below a gate, and that's the width of the peak. If the width is more than a threshold, you've seen a broad peak. This worked very well!

Referenced in: Electronic Harp Mandolin Prototype

Comment via: facebook, lesswrong, mastodon

Recent posts on blogs I like:

Animal Welfare and Capabilitarianism

All ethics is a special case of animal welfare science

via Thing of Things December 18, 2024

Developing the middle ground on polarized topics

Avoiding false dichotomies The post Developing the middle ground on polarized topics appeared first on Otherwise.

via Otherwise November 25, 2024

How to eat vegan on Icon of the Seas

Royal Caribbean has a new giant cruise ship, Icon of the Seas, which has a large selection of food options.

via Home November 21, 2024

more     (via openring)