[HN Gopher] Typing with Pleasure (2015)
       ___________________________________________________________________
        
       Typing with Pleasure (2015)
        
       Author : tosh
       Score  : 17 points
       Date   : 2021-08-13 11:33 UTC (11 hours ago)
        
 (HTM) web link (pavelfatin.com)
 (TXT) w3m dump (pavelfatin.com)
        
       | riskable wrote:
       | > "Regardless of keyboard type, key switches are mechanically
       | imperfect and are subject to contact bounce..."
       | 
       | This is completely not true. For example, my Riskeyboard 70
       | (https://gfycat.com/alienatedflatcanvasback) analog hall effect
       | keyboard does not have contact bounce. This is because it's
       | entirely analog and contactless.
       | 
       | Instead what it uses is programmed hysteresis: You can set your
       | own completely arbitrary point of actuation as well as the
       | `release_threshold` (it's in the config). The way it works is
       | like this: Once you go past the point of actuation (a certain
       | amount of millivolts changed from the resting value) that is
       | considered a keypress but it won't consider it a keyrelease until
       | you go past the original point of actuation plus whatever the
       | release threshold is.
       | 
       | So if your resting mV (from the analog hall effect sensor) is
       | 2000, your actuation threshold is 250, and your release threshold
       | is 50 a keypress would work like this:                 * Physical
       | key is pressed and as it moves down the length of travel the mV
       | reading from the sensor changes (goes up or down depending on the
       | pole of the magnet).       * Once the difference from the resting
       | value is greater than the actuation threshold (250) that's
       | considered a keypress.  At this point the sensor would be reading
       | 1750 (the point of actuation).       * If the user kept the key
       | pressed exactly at the point of actuation there's a chance that
       | the keypress could "bounce" because the mV value goes up and down
       | ("voltage wobble") on its own depending on the noise on the PCB
       | and in the environment.       * The user releases the key and
       | once the mV reading goes above 1750+*<release_threshold>*
       | (1750+50) the key is considered released and a keyrelease event
       | is sent.
       | 
       | My keyboard uses an STM32F401CEU6 running at 84MHz. The ADC runs
       | at half that (42MHz) and is setup to read all 72 sensors (70 keys
       | + an analog rotary encoder built into the PCB) in 0.160ms. It
       | does this every millisecond to meet the USB spec's 1000Hz polling
       | rate.
       | 
       | I assume the other analog keyboards feature similar methods and
       | would have greatly reduce latency over traditional mechanical
       | keyboards.
       | 
       | For reference (only) I have uploaded the Riskeyboard 70 firmware
       | to github if you're curious to see how it all works (it's written
       | in Rust): https://github.com/riskable/riskeyboard70/
       | 
       | The keyboard uses 3D printed Void Switches (my magnetic
       | separation design). Chyrosran22 did a teardown video recently
       | going over the switches and their parametric nature here:
       | https://youtu.be/H_Ym9528awM
        
       | stinos wrote:
       | _Typical average latency of keyboard and monitor combined is
       | about 26 ms_
       | 
       | 'typical' might be a bit of a stretch here: I doubt that without
       | tuning settings on a standard OS like Ubuntu/Windows and with
       | your typical 60 or 75Hz monitor it's possible to achieve numbers
       | this low (I've measured software->monitor latencies, good luck
       | getting lower than 2 frames, and that's excluding input and
       | processing). Anyway since this is largely theoretical, what would
       | be really interesting here to actually measure this with external
       | hardware and see what the actual numbers are. Think 2-channel
       | oscilloscope, channel 1 probing keyboard key activation and
       | channel 2 measuring a photovoltaic sensor taped to the screen.
       | Anyone did that already?
        
         | NathanielK wrote:
         | Once you start using high speed sensors taped to the screens,
         | you starting noticing how slow LCDs are. It's a lot slower than
         | the marketing wank says. [0]
         | 
         | [0] https://www.youtube.com/watch?v=MbZUgKpzTA0
        
         | rowanG077 wrote:
         | Nvidia has something like that.
         | 
         | https://developer.nvidia.com/nvidia-latency-display-
         | analysis....
        
         | diggan wrote:
         | Similar idea, but instead of probing the keyboard keys, it has
         | a mechanical arm + takes a high-framerate video of the keyboard
         | + screen to measure the latency. Not automatic like yours
         | would, but probably wouldn't be hard to use different software
         | (they seem to be using a game, you could write an application
         | that instead flashes bright white/$color) and then process the
         | video to get the start/end time of the measures.
         | 
         | https://www.rtings.com/keyboard/tests/latency
         | 
         | Edit: This seems even closer to what you were suggesting:
         | https://thume.ca/2020/05/20/making-a-latency-tester/
        
       ___________________________________________________________________
       (page generated 2021-08-13 23:02 UTC)