Hardware test mode on Model 01

Programming
1

While trying to investigate potential issues with Qukeys (see related post) on my Model 01, I noticed that the hardware test mode (fn+prog+led) was reporting key chatter on ALL keys, even the ones that I hardly ever use so I decided to ignore it.

Until now I only had key chatter once on a few keys, and the alcohol bath cleaning technique worked well, so over 3 years of daily use it was definitely not a big deal.

Then, a few days ago a key really started to fail and send double keystrokes, so I tried to see if the hardware test mode could help me, but without any success because all the keys were reported as failing.

So, by looking at the hardware test mode implementation, I see that the heuristic to detect key chatter relies on the number of cycles between events.

If I understand this correctly, the hardware test mode ordering and the number of plugins can probably influence this heuristic and the loop() duration. I tried compiling a minimal firmware with only the hardware test mode, and :tada: the expected key chatter was properly detected where it was expected and I can now properly verify the cleaning process.

So it means I now have a few bunch of questions:

  • Does my understanding of this is correct ?
  • Is there another option to reliably detect key chatter ? for example using micros() or a similar time function ?
  • Would implementing a loop calibration help on this strategy ?
  • Moving the hardware test mode to be first in the list of plugins does not seem to make a difference here, why ?
  • If a minimal firmware can help here, I think it would be worth adding a ready-to-use example for that purpose, I’m volunteering for opening a PR just for that.
2

The actual keyscanning runs on the ATTinys, which aren’t affected by the number of plugins you’ve got running.

The test mode could absolutely be “more accurate”, but its primary intent is to be used at the factory as part of a pre-shipment check, where all keyboards are known to be running the same firmware.

On top of that, the test mode doesn’t use the standard Kaleidoscope runloop, so number of plugins shouldn’t be material. (Have a look at HardwareTestMode::testMatrix - Test Mode takes over keyscanning from the “real” runloop. That’s why you need to unplug and replug to reset after using it.)

Oh, and one of the things we do in test mode is to tell the ATTinys to scan the key matrix a lot faster than they do in normal usage. That makes them much, much more sensitive to “chatter” in an attempt to catch issues that are too subtle to be detected in regular usage.)

2 Likes
3

Thanks,

I completely missed the while(1){} loop in the plugin, that makes way more sense now :man_facepalming: .

I tried to re-flash the default firmware, and the hardware test mode behaved as expected, and provided quite reliable and consistent results.

So, the next time the hardware test mode reports way more chatter than expected, I’ll try re-flashing the default firmware first.