DOC: how to proceed in debugging sensor data

[davidedelvento]

With my sensors and my action (which you know are both very different than yours), I have a problem finding the appropriate calibration. I'm not asking for a fish, but to be taught to fish, which I can then make it into a PR for the documentation, so others can benefit too. I'm describing my problem just as an example: I speculate you went through something similar and so the actual question is "what steps would you suggest performing to debug similar issues". I know some people are mulling the option to use the system with different kind of sensors (maybe not even optical ones), so this would greatly help them too.

It feels like I am stuck at a note-on velocity of almost always 16. See for example this MIDI and corresponding ADC capture

note_on channel=1 note=24 velocity=16 time=0
note_off channel=1 note=24 velocity=23 time=0

note_on channel=1 note=24 velocity=16 time=0
note_off channel=1 note=24 velocity=50 time=0

note_on channel=1 note=24 velocity=16 time=0
note_off channel=1 note=24 velocity=84 time=0

note_on channel=1 note=24 velocity=16 time=0
note_off channel=1 note=24 velocity=79 time=0
note_off channel=1 note=24 velocity=4 time=0
note_off channel=1 note=24 velocity=0 time=0
note_off channel=1 note=24 velocity=2 time=0

note_on channel=1 note=24 velocity=16 time=0
note_on channel=1 note=24 velocity=34 time=0
note_off channel=1 note=24 velocity=10 time=0

In this example (which I unfortunately I forgot to separately timestamp on the MIDI capture part, given that real-time MIDI has no inherent timestamps) I had:

• only 5 hammer strikes of which 4 where with a keypress and one was with manual raise of the shank
• note that there are several note_off events after the 4th note_on. This is likely due to the fact that I grabbed the shank with my fingers and so I moved it in an "unexpected" way
• note that there are 6 note_on events, I manually grouped the last two together because that was my "manual" strike in which I did by moving the shank with my finger (no keypress involved), so that may be an actual double-strike. This way I was able to achieve a different-than-16 velocity
• damper_threshold = 0.22 (otherwise the MIDI channel would be flooded by a continuous stream of note_off events)
• hammer_strike_algorithm = 1

and the following problems:

• velocity is stuck at always 16, regardless of how I make a keypress from ppp to fff
• with manual shank movement (even a relatively slow one, definitely slower than what a keypress achieves) I can get faster velocities, and occasionally a zero (which is different than note_off as far as I understand the code in the firmware)
• there are many more peaks in the data captured from the ADC than there are note_on events. This is really puzzling. I mean, the ADC values may be too noisy for a gazillion of reasons, so in itself is somewhat okay. But then how can the code correctly identify the moments (if not the velocity) if the hammer strikes??!

I speculate that the hammers move too fast (my sensors are right under the felt, as compared to yours near the flange) and therefore something in the code is too slow to keep pace and measure them fast enough for sensing velocities faster than MIDI 16. Perhaps something else (e.g. some integer conversion) forces the velocity to not be slower than 16 either (given the range of ADC measurements), and so it's stuck there.... unless I move an hammer with my hand, which is slower enough to be measured and hence other velocity values are generated. Pure speculation here, which I could confirm if there is a quick debug setting somewhere to stop the multiplexing and go "full throttle" on one note only. Is there such an option?

Probably confirming the speculation above, but I tried changing various constants with _scaling and _threshold and the algorithm (0 or 1). None of those changes modified anything with regard to this behavior.

[gzweigle]

I always debugged with calibration off. One less variable.

Here is some data that could help. I moved a sensor to be over the hammer.

Attached is:

(1) A picture of the test setup.

(2) Measured values (received over Ethernet) for a very slow (manual move hammer), slow (keypress), and fast (keypress) hammer strike.

(3) A picture of plot of position and velocity.

Observations:

(A) The sensor does not pick up the hammer until it is close to the sensor. So the hammer position data is very nonlinear.

(B) There are less samples due to the faster motion (traveling 40mm at hammer vs 5 mm at flange). But back-of-the-envelope and looking at this attached data, the 300us sample rate may be ok.

(C) The velocity in attached plot is about 2X for the fast strike compared to the slow strike. This quick test didn't test if I actually played with 2X the velocity.

a0_fast_strike.txt a0_manual.txt a0_slow_strike.txt

[gzweigle]

The results I just shared is with calibration off.

[gzweigle]

Octave code to recreate my plots. The zeros in the filter are just to smooth things out. They aren't necessary.

clear;

x_slow = load("a0_slow_strike.txt"); x_fast = load("a0_fast_strike.txt");

v_slow = filter([1 0 0 0 0 0 0 0 -1],[1],x_slow); v_fast = filter([1 0 0 0 0 0 0 0 -1],[1],x_fast);

t = [0:length(x_slow)-1]*300e-6;

figure(1); subplot(2,2,1); plot(t, x_slow); grid; title('position, slow'); xlabel('seconds');

subplot(2,2,3); plot(t, x_fast); grid; title('position, fast'); xlabel('seconds');

subplot(2,2,2); plot(t, v_slow, 'k', t, v_slow, 'ok'); grid; title('velocity, slow'); xlabel('seconds');

subplot(2,2,4); plot(t, v_fast, 'k', t, v_fast, 'ok'); grid; title('velocity, fast'); xlabel('seconds');

[gzweigle]

With respect to my observation (B) and this comment in op - "...something in the code is too slow to keep pace and measure them fast enough..." After thinking about it. At both hammer and flange, the motion start time and end time are the same. All that differs is a numerical value. Therefore, the 300us sample rate is ok for both. In other words, the "code speed" is ok for measuring at hammer. The problem is somewhere else.