Mapping key-travel data to lighting effects in magnetic-switch keyboards essentially involves converting the « continuous analog displacement » output by a Hall-effect sensor into « lighting variables » that the keyboard’s microcontroller can process. The technical workflow is as follows: the Hall-effect sensor reads the position of the switch stem → an ADC (analog-to-digital converter) translates this into a digital travel value → the firmware normalizes the data and applies a mapping curve → the lighting controller or microcontroller uses PWM (pulse-width modulation) to adjust RGB brightness or color. This mapping transforms the keyboard’s lighting from a static « backlight » into a « dynamic interactive interface » that reflects the intensity of the user’s keystrokes in real time.
I. Data Source: Where Does Key-Travel Data Come From?
Beneath each switch on a magnetic-switch keyboard lies a Hall-effect sensor. When a key is pressed, the magnet at the base of the switch stem moves closer to the sensor; the resulting change in magnetic field strength is converted into a voltage signal, which is then processed by an ADC into a digital value. This value represents the current position of the switch stem (for example, 0 might indicate a fully unpressed state, while 1000 represents a bottomed-out state).
Unlike the binary « on/off » signals of traditional mechanical switches, this travel value changes continuously. As a finger presses a key with varying force or speed, the sensor outputs distinct position data with every passing millisecond. It is precisely this continuity that provides a rich, multi-dimensional dataset for lighting effect mapping.
II. The Mapping Workflow: From Travel Value to Lighting Parameters
The transition from raw sensor data to the final lighting effect involves the following mapping steps:
1. Normalization: Raw ADC values are not standardized—they can be influenced by individual sensor variations, ambient temperature, and magnet strength. The firmware first normalizes these raw values into a percentage ranging from 0.0 to 1.0. For instance, if a key has an actuation point of 1.5mm and bottoms out at 4.0mm, the firmware maps the ADC readings to this specific travel range.
2. Mapping Curve: Once normalized, the travel percentage is passed through a mapping curve to derive specific lighting parameters. This curve determines the relationship between how deep a key is pressed and the resulting brightness (or other lighting attributes). The simplest form of mapping is linear (e.g., 50% of the total key travel corresponds to 50% brightness). However, for a better visual experience, firmware typically employs a non-linear curve: the light changes gradually during the initial stage of a press (preventing intense lighting effects from being triggered by accidental, light touches), accelerates through the middle and later stages, and reaches its peak when the key is fully bottomed out.
3. Generation of Lighting Parameters: The mapped values can control various lighting dimensions, including:
– Brightness: The most direct mapping—the deeper the key is pressed, the brighter the LED becomes.
– Hue: Changes in key travel can drive shifts in hue—for example, transitioning from blue (light press) to red (heavy press)—creating a « pressure visualization » effect.
– Animation: Travel data can trigger or modulate dynamic lighting effects; for instance, the intensity of a press can dictate the speed at which a light wave propagates.
4. PWM Output: The final lighting parameters (brightness, color) are converted by the main controller or a dedicated lighting control chip into PWM (Pulse Width Modulation) signals, which drive the individual channels of the RGB LEDs.
III. Typical Applications: Examples of Travel-Driven Lighting Effects
In mass-produced products, this type of mapping has already been implemented in various practical ways.
The Dareu A98 Pro features a « Ripple » (or « Flick of a Finger ») lighting mode: when a key is pressed, light ripples outward like waves on water. The initial brightness and the spread radius of these ripples vary based on the depth of the key press. This effect is achieved by mapping the key-travel value to the trigger intensity and the propagation radius of the lighting effect.
The « lightsaber » side-strip on the Maicong (MCHOSE) GT75 changes in real-time based on the pressure applied: the deeper the press, the brighter the light strip. This utilizes a linear or quasi-linear mapping logic, where the brightness of the strip directly reflects the current percentage of the key’s total travel.
The Rapoo V500 PRO (Magnetic Switch Version) offers a « Travel-Based Lighting » option within its driver software, allowing users to customize specific color ranges for different depths of key travel. For example, 0–30% of the key travel is displayed in green, 30–70% in yellow, and 70–100% in red, creating an intuitive « pressure bar » visual effect.
IV. Engineering Challenges and Limitations
Driving lighting effects based on key-travel data presents several practical engineering constraints.
Refresh Rate and Latency: The refresh rate of the lighting effects must be synchronized with the keyboard’s scanning rate. If the scanning rate is 8 kHz, the refresh rate for the lighting-effect mapping must be sufficiently high; otherwise, the lighting may appear to « lag » behind the movement of the user’s fingers. The main controller must allocate processing power to lighting-effect mapping while simultaneously handling Rapid Trigger (RT) algorithms, key scanning, and USB reporting—placing significant demands on the controller’s load management.
Sensor Noise: Analog signals from Hall-effect sensors inherently contain noise, and even the slightest tremor in a user’s finger can cause fluctuations in the detected travel value. If these values are mapped directly to the lighting, it can result in flickering or jitter. Consequently, the firmware must incorporate filtering or smoothing algorithms to ensure that the lighting transitions remain fluid and natural.
« Decoupling » of Lighting Effects and Key Travel: Not all keyboards support driving lighting effects based on key-travel data. To conserve power or simplify firmware, some products disable travel-based mapping, opting instead for a basic « on/off » logic triggered only when a key is actuated. Driving lighting effects via key travel is generally considered an advanced feature, requiring manufacturers to implement specific adaptations within both the firmware and the lighting-control architecture.
