Firmware update request:
Since the Round 2 beam spring boards (and eventually all Model F and beam spring keyboards) will be using the Leyden Jar controller, it would be great to combine what is great about all of the various firmwares out there!
Hopefully someone in our community can update the Leyden Jar firmware with parts of Arkku's firmware to optimize the binning:
https://github.com/arkku/aakbdFor those not familiar, Arkku's firmware optimizes the number of calibration bins based on the variety of resting values in each keyboard, and turns off unused bins to improve the scan speed.
I think the more adaptable the firmware is to potential hardware issues in the future (including varying capacitance and dust/debris levels in the keyboards), the more these keyboards are likely to survive over the coming decades with folks who are less likely to maintain and repair their boards.
I am copying and pasting below some of the relevant discussion from the DT project thread:
Arkku: "By optimizing the code for my firmware I got it down to under 1 ms (for the whole keyboard, but in fairness one of the "key" optimizations was to only scan bins and columns that have mapped keys in them, and this means the effective number of bins scanned was either 1 or 2 because the calibration ended up not needing more – another optimization was to not artificially force extra bins to be used if the keys were close enough in their levels to not need more)."
My reply: "Thanks Arkku for this discussion! That is great information. I like your idea to set the number of bins based on the number of keys with different bins, and turn off / not use more bins than necessary. Would this be implementable in the new Leyden Jar Vial firmware (linked below)? For example, it could set each bin for all keys with a resting value of a certain value plus/minus 1, 2, or 3 values either higher or lower (not both higher and lower; easily user-adjustable by a variable. Should each bin's reference level be the highest level of keys in that bin, or the lowest?).
This would allow a lower offset to be used, which could be helpful to keep keyboards running even if they have some dust or debris that enter under the flipper at some point in time (these flippers would produce a weaker signal so the offset / value change when the key is pressed would be smaller). So for example it could put 378 and 379 resting values for one bin, 380 and 381 for another, one key with a 386 value on its own bin, and one key with 393 on another bin.
Sometimes with the F122 keyboards (they use the Leyden Jar controller), there are some keys that have a much higher resting value, and these values differ among these few keys. The current firmware hard-codes some of these keys to have their own custom bin, but sometimes the resting levels vary even between those keys so they shouldn't both be in one bin.
Do you (or does anyone else) have additional recommendations for the Leyden Jar project and firmware?
https://github.com/mymakercorner/vial-qmk/tree/leyden_jar "
Arkku: "I haven't looked at the details of how the Leyden Jar firmware is implemented, but assuming the hardware works similarly to the xwhatit's-based controller: sure, the same optimizations can be done, but the actual values for the thresholds would differ and would probably need to be determined by trial and error.
As for what value to use for each bin, IIRC the approach used in my firmware's auto-calibration is to take the average value of that bin and then offset it by a magic number to make it less sensitive. This magic number is what needs to be determined by trial and error based on the hardware – it's basically an offset that is sufficiently large that there are no phantom keypresses, but not so high that it would stop real keypresses from being detected. It also indirectly determines how many bins are needed: there must be enough bins that the keys in the same bin are close enough that they all work after the offset is applied (i.e., the average value is ok to use because no key in the same bin differs greatly from it).
The maximum number of bins is hardcoded at compile time and can't be changed, but as long as the difference between keys is small compared to the magic number, there is no reason to use all of those bins. All four of my model F keyboards work with either 1 or 2 bins – not sure whether the keys will start to deviate more with age.
Then it's just a matter of optimizing the code to be able to skip any unnecessary scans. And there are some additional micro-optimizations possible, like do every other scan in the opposite direction (this saves changing the DAC settings once per scan because the last setting of the previous scan is the first setting of the next – although it makes the latency of some keys variable since the scan order is not always the same). When talking about fractions of milliseconds, these do add up."
My reply: "Having manually analyzed many production F122 keyboards, including their unpressed and pressed values for each key, I believe that an offset of 6-7 (difference between pressed and unpressed values for a particular key) is acceptable for virtually all F122 keys if bins only allow 2 or 3 adjacent numbers for each bin, in terms of unpressed values. So I think your updated Leyden Jar firmware could start with those figures as an initial version.
To keep things simple I would like each bin's reference level to stay the same as what Rico has set. I like that your firmware plans for future deviance requiring more bins, without needing to recompile firmware in the future."
