-
Notifications
You must be signed in to change notification settings - Fork 1
Direct to Excel
Contents:
Direct-to-Excel is a feature of most of the HID-based TEMPer variants, which is advertised as being a way to get the measurements without needing any drivers for the device, and as something that works on Windows, Mac and Linux.
This is partially true, but not completely.
To take the weakest falsehood first, technically it does require that a driver is installed and activated for the device, but, that driver is the standard USB keyboard driver, which in practically all cases is already installed anyway, since most systems use (or at least support) USB keyboards.
That one is perfectly forgivable, since most people would not consider that to be requiring a driver, since they don't need to install anything themselves - and explaining it properly would just confuse most people, which is obviously anathema to proper advertising.
More important is that it does not actually work on Linux, at least not on any version I've ever tried. It does work on Windows. I have not tried it on a Mac, so I don't know whether or not it works there.
First off, open Excel, OOo Calc, or some other spreadsheet program. (Actually, a simple text editor works too, but I don't think that's how it's intended to be used.)
Then you hold down Caps Lock or Num Lock for a few seconds, until you see characters starting to appear on the screen seemingly all by themselves.
The device will start by writing a header that's a couple lines long, which includes a short usage reminder, the firmware version, and the units of the data it will give (usually ℃ for a TEMPer, and ℃ and %RH for a TEMPerHUM).
Here's an example of what the header looks like (from a TEMPerHUM I have):
caps lock:on/off/++ fw:1.0
num lock:off/on/-- unit:c %
Then it starts writing rows of measurements. Each row generally consists of the date and time for that measurement, the measurements, and how long it is until the next measurement will be given, all separated by tabs, and ended with an enter.
Note that this makes use of a feature of Excel (that also exists in OO Calc), where pressing ctrl-colon will enter the current date, and ctrl-shift-colon will enter the current time - the device does not spell out the date and time, it just presses those key combinations to make Excel do it.
This means that if you use a plain text editor instead, the date and time will not be included, and it will appear as though the device just writes the measurements with a two-tab indent.
Here's an example of what the measurement rows look like, for the same device, if the active program is not a spreadsheet but e.g. a simple plain-text editor:
25.44 47.69 02
25.47 47.66 02
25.46 47.66 02
That last column indicates that there are 2 seconds between each measurement.
As the header indicated, you can press Caps Lock and Num Lock to increase and decrease the time between measurements. These are simple press-release cycles, like with normal typing, not press-and-hold like you do to start the feature.
Finally, you can press and hold Caps Lock or Num Lock for a few seconds again, to turn the feature back off (so it stops writing measurements), which it acknowledges by writing an empty row - that is, it writes an enter directly after the enter of the last row.
In many places in the world, the header will look a bit different, and the rows may not contain the date and time.
For some people, even in the US, I believe parts of the output will probably look completely garbled.
This will happen for those people and places that use keyboards layouts other than the common US QWERTY one, e.g. someone using a Dvorak keyboard, or those with national keyboards that has their own language's characters on it instead.
This is because the device does not, in fact, send characters to the system. It sends keypresses and releases, which is not the same thing - those just tell the system which key on the keyboard was pressed, not what character is printed on that key.
That's why most systems have configurable keyboard layouts. A keyboard layout is a way for the system to know that this key (or combination) corresponds to that character, for all the keys (and combinations) on the keyboard.
Since the device has no way of knowing which keyboard layout the system is currently using, it assumes a US QWERTY keyboard layout, which is quite common - certainly in the US, which I assume is the biggest target market for these devices - and is also a good choice because most other layouts are based on the US QWERTY one, and therefore have most of the letters and numbers in the same places. This means that, in most cases, at least the measurements themselves will survive intact, and most of the header, even if some of the characters (like the slash, plus, and colon) will be replaced by other characters.
That the colon is sometimes moved elsewhere (to make room for other things), is the reason the date and time may not appear.
As an example, on the keyboard I'm currently typing this on, the colon is placed on shift-period, right next to the semicolon which is on shift-comma, because the key they normally occupy is instead used for the national letter ø.
Maybe surprisingly, for KeyTemper it is actually a good thing that the device assumes a US QWERTY keyboard layout, instead of somehow finding out what the system is using.
It is a good thing because KeyTemper reads the keypresses directly, without going through the system's keyboard layout, and having the device always use the same keys allows us to ignore the layout as well. It means we can simply embed a translation table to map keypresses to characters, instead of needing some way to configure what layout to use with that device.
We now know what it is, and how it's used, so now we'll get into the technical details of how it actually works, in particular how the feature is triggered.
To know when to start sending keypresses, the device needs to know when the Caps Lock or Num Lock keys are held down.
To do this, it exploits a quirk in the handling of these keys, and how their state is marked for the user (the keyboard LEDs).
When one of these keys are pressed, the keyboard does not change the state of these LEDs on its own. Instead, it simply sends the keypress to the PC, just like for most of the other keys.
For simplicity, let's take the Caps Lock key as an example. The Num Lock key works the same way.
When you press the Caps Lock key, the keyboard sends that keypress to the PC.
The OS on the PC receives this keypress, notices that it's the Caps Lock key being pressed, and updates its internal Caps Lock state - turning it on or off, depending on its previous state.
Then, it sends an update to all of the keyboards connected to the system, telling them to turn on (or off) the LED that signifies the Caps Lock state.
Now, if you keep holding down the Caps Lock key instead of releasing it, then the automatic key repeat starts happening - like for other keys, the system sees that the key is held down, and starts sending the resulting signal over and over again until you release it.
In the case of the Caps Lock key, that signal is the signal that sets the LED on the keyboards, instead of the signal that sends a character to the active program, but otherwise the process is similar.
The TEMPer device exploits this by seeing that the same LED-setting signal is being repeated, and once it has been repeated for long enough, assumes that the user is trying to trigger this feature, and starts sending keypresses and releases to the system, just as if it was a keyboard someone was typing on.
Actually, instead of looking at how long this repeating happens, it appears that the device is simply counting the number of consecutive identical LED-setting signals, something KeyTemper exploits by sending them much faster than Windows would with the key held down, which triggers the feature sooner.
This doesn't work on Linux for one fairly simple reason: Linux doesn't send the LED-setting signal to the keyboards repeatedly when the Lock key is held down.
Linux knows that the LED state in the keyboard is persistent, so that there's really no need to send the signal more than once, so it simply doesn't.
Of course, that means that the TEMPer can't tell that the key is held down instead of being pressed once, which completely breaks the triggering of this feature, but that's hardly Linux's fault - the device is relying on a quirk of how Windows currently handles the Lock keys.
Nothing says that Windows has to keep doing this either, so the next version of Windows might not - and in that case, this feature would no longer work on Windows either.
KeyTemper activates the feature by doing basically the same thing Windows does, namely sending the same LED-setting signal to the device repeatedly, until it starts sending keypresses. However, it does this much faster than Windows does, which is the reason it usually manages to trigger the feature much sooner.