This is really the "Expected Calibration Procedure" page, because none of this has been implemented, or tested yet.

What we've got to work with

Each key and hammer has a dedicated ADC channel, attached to an ADC converter which it shares with 6 or 7 other channels.

If the chip only has to sample a single channel (as might be reasonable during a very infrequent calibration procedure where the user presses each key in sequence), then we can reach a rate of 1Msps.

During normal operation, when the chip has to operate all 3 ADCs at once, and sample all 22 channels, we're limited to 700ksps across all the channels. Divided 22 ways, that's a bit more than 31kHz.

We might be able to have the ADC boards transmit to the main boards at nearly 3Mb/s, but the design target is 1Mb/s. Assuming some significant overhead, a single channel could be streamed with 16 bit resolution to the main board (and out to the attached PC) at a sustained 450kHz.

What we're working towards

We'll actually run the channels at 20kHz during operation, and the calibration procedure should produce something simple which the ADC boards can use in real time to turn their raw ADC measurements into simple velocity measurements to be sent to the main board. There is no intention of streaming ADC data to the main board, let alone the PC, outside of a calibration procedure.

The low-pass filtering and decimation referred to below will help to reduce the CPU load. Every time we get an DMA interrupt with a new sample, we can just apply the low pass filter code. Only every other (or every third, fourth, fifth, whatever) sample will we actually need to apply any fancier decision making procedures. Note we'll be running at 480MHz: 20kHz conversion, with 22 channels gives us a budget of 1090 clock cycles per raw sample. Some of that will be lost to interrupt handling overhead.

(Expected) Procedure

This will of course be overseen by a program dedicated to the task of calibrating an instrument, both telling the user what to do, and processing the received data (with appropriate user intervention, whatever that might end up being).

1. User activates calibration.
2. Main board instructs the user not to press any keys.
   1. The LEDs in the CNY70s are blinked on and off, to collect true "dark" measurements for the phototransistors, and also "dark" measurements that correspond to the keys/hammers being maximally distant from the sensors. That may be the same as a dark reading, depending on mechanics, particularly for the hammers.
3. For every single key:
   1. Host PC instructs the main board, and then the relevant channels of the two ADC boards (one for key and one for hammer), to go into data capture mode. At this point the devices will stream raw ADC readings back to the PC at 20kHz (or higher?).
   2. User is instructed to press the key softly, and then forcefully. Ideally they'd achieve ppp and fff. I think getting ppp will be more important than fff.
   3. The strikes should be detected in the data (along with quite a bit of pre and post-strike "quiet" time), and extracted.
4. At this point we'll have 352 position/time curves.
5. Apply low-pass filtering to them, and reduce them to 10kHz (8kHz? 6? 5? what will actually be necessary / sufficient?). Identify "start" and "stop" ADC values such that the time between them will correspond to the velocity of the note on / note off.
6. Program the main board with all of the computed values, and instruct it to pass them back to the ADC boards for use.
7. User tests piano.
8. ???
9. Complete!

Hopefully by collecting and being able to compare data from all keys simultaneously, the program can identify any outliers, and request those keys be pressed a second time. The calibration software should keep the raw data from all past calibrations, so that future ones can identify drift that may be occurring and/or have more data to average across. The actual calibrations computed and applied to the instrument should also be preserved, to facilitate easy comparison not only of past states, but past versions of the software.