2. Theory.
This part requires some basic understanding of IR protocols, for
example as described in
this article.
2.1 General
Abstractly, an infrared signal consists of number of on-off
periods of modulated (typically 35-40kHz) infrared light. The
information in the signal sits in the timing of the on/off periods. An
infrared protocol is a mapping of a few parameters (a device number,
possibly a subdevice number, a command number, and sometimes others)
to an infrared signal, in the sense above. The device number (and
subdevice) is (are) (typically) the same for all signals intended for
the very device, while the command number enumerates the different
commands/keys. Typically (but not always), one bits of the parameters
are mapped onto one on/off-pair, one for the bit being 0, another for
the bit being 1 (often called pulse-width-modulation, PWM). The bits
making up the parameters have to be transmitted in a well defined
order: the only practically used schemes are MSB (most-significant-bit
first), and LSB (least-significant-bit first). Examples of common and
well known protocols are the
NEC protocol (using PWM), the
RC5
protocol, using bi-phase modulation. A complete infrared signal
typically consists of a lead-in pair, the parameters coded in a
suitable way, and possibly a lead-out pair -- typically there is a
period of "silence" between the "payloads", normally much longer than
the useful signal.
When a key on a remote repeats, the first signal is often different
from the others. It is then called an "intro sequence". In a few
rare cases, the last signal is also different. Not all
universal remotes can reproduce this behavior.
2.2 Learned signals vs. computed signals
A physical IR signal, captured with for example a learning remote,
roughly corresponds to a sort of tape-recording. Some physical device
measures the signal and determined its characteristic properties
from the measurements. Accordingly, different measurement errors are
to be expected. Learning signals is in this way akin to scanning printed
document, or sampling audio signals. It follows that using the
non-exact learned, "dirty", signal is likely to produce a remote control of lower
quality (reliability as well as range) than using a perfect signal.
A description of an IR signal in the sense above is essentially a
mathematical object. Using a pure signal can be expected to produce
higher quality remote controls.
Additionally, the learned signal often requires quite some memory
space to store, and the noisier it is, the more storage is often
required. (Learning remotes typically comes with only a few kiB of
storage for learned signals.) Instead, typically, a clean signal can be stored
as the name of the protocol, and the actual values of the parameter.
2.3 dBox Protocols and hardware.
The dBox2 from Nokia understands three quite different IR-protocols:
The "old" protocol, the "new" protocol, and the keyboard protocol. The
Sagem and Philips dBoxen understands the "new protocol" and the
keyboard protocol. A Nokia dBox can be forced to use only the new (old)
protocol by creating a file named
/var/etc/.newrc
(
/var/etc/.oldrc). Some owners of two dBoxes uses this property for
controlling two boxes independently with two different remotes.
The decoding of the received signals takes place in the dBox front
processor, driven by its own firmware, for which the exact workings
are not known. This determines for example which signals will cause
the system to wake up from (deep) standby. However, the Tuxbox
software contains drivers the front processor, where the interested
reader can do all sort of interesting manipulations.
Using the present drivers, as far as I am aware, it is not possible
for application programs to distinguish between "old" and "new" signals.
For debugging, it is useful to connect a serial console to the dBox, and to put
the line
debug=on in
/var/tuxbox/config/rc.conf. The reception of a
signal, or more precisely, the down-, up-, or repeat-event associated
with a particular signal, will then be reported to the serial console.
2.3.1 The "old protocol"
The "old protocol" is known as (Nokia)
NRC17. It
is similar to the RC5 protocol in that it uses bi-phase modulation and
similar modulation frequency. There is a 4 but device number, a 4 bit
subdevice number, a 8 bit command, all transmitted in the LSB
direction. Since the the bi-phase coding
requires a start bit, this makes up 17 bits (4 + 4 + 8 +1) which
accounts for the name. In the dBox, the device number 12 and the
subdevice number 5 is used (using the definition in the quoted source,
the JP1 project and DecodeIR use a different definition). The command number consists
of 8 bits, however only 32 different positions are used. (Probably, by
modifying the driver, it might be possible to use more positions.)
In the dBox setting, there is an intro sequence, always the same. It
consists of a command number of 254, and device- and subdevice numbers
both being 15.
According to the quoted source, there is also a "stop" signal emitted
when releasing a key. I have never really checked this, nor seen it
implemented it in code. In every case, things work as desired without
the stop signal.
2.3.2 The "new protocol"
The "new protocol" is known as "
Nokia", although the notation "Nokia24" might have
been more appropriate. There is a device number, a subdevice number,
and a command number, all having 8 bits, all transmitted in the MSB
direction. It is an uncommon protocol in that it codes two bits of
the parameters on each on-off-pair; a (binary) 00 is coded on 164
microseconds on, 276 off, a 01 coded as 164 microsecond on, 445
microseconds off, a 10 as 164 microseconds on, 614 microseconds off,
and finally a 11 as 164 microseconds on, 783 microseconds off. (This
property makes it comparatively hard for a learning remote to learn
the signal.) Of the 8 bits available for the command number, only the
lower 5 are effectively used. Bits 6 and 7 make up sort of a 4-state
toggle in the original remote; its use is not known to me. Bit 5 is
always 0. However, these three bits are all masked off in the driver
(
dbox2_fp_rc.c).
There is neither an intro- nor a stop-sequence.
2.3.3 The keyboard protocol.
The keyboard uses the
Nokia12-protocol, with a nonstandard
interpretation. This is basically the same as the Nokia(24)-protocol
above, except that it uses 4 bits for the device number, no subdevice,
and 8 bits for the command number, again in the MSB direction. Almost
all keys, even the ones with shift-function (Alt, Shift, capslock, Fn,
Ctrl, in some cases with left- and right-versions) send their own
(keycode-like) signal. These are a number in the range 0-127,
i.e. with bit 7 being 0. When the key is released, the same signal,
but with bit 7 being 1 (alternativelly, with 128 added to the command
number) is being sent, making it a protocol with no intro- but with a
stop sequence. Decoding of shifted keys is left to the driver in the
dBox: Pressing "Alt-F2" really does the following: When pressing Alt,
its sequence is being sent repetedly. When in addition pressing F2,
instead its sequence is being sent repetedly. When releasing F2, its
up-signals is being emitted. Assuming that the Alt key is still being
held down, it sequence is being transmitted (repeatedly) until the key
is released, when the corresponding up-signal is transmitted once,
Thus, the task of interpreting this as "Alt-F2" is being left to the
keyboard driver. (Fortunately, the driver is not really that choosy,
just one Alt-down and one F2 down is enough to trigger the "Alt-F2
received" event.) This applies to the keyboard driver and all
"shift-like" keys, except for the "Fn"-key (see below). To
complicate things further, a few keys on the keyboard does not
transmit their own "keycodes", but a sequence involving the Fn up and
down sequences. These are four keys: the "Home key, emitting Fn down +
left + Fn up; "Page down", emitting Fn down + right + Fn up; "Page
up", emitting Fn down + Up + Fn up; and finally the "End" key,
emitting Fn down + right + Fn up. However, for the dBox user, for
example configuring rc.conf, this is transparent; he only sees,
e.g. the End key as the key "rc_end".
The
rc driver in the Tuxbox software also has a peculiar property:
Just as the keyboard driver, it grabs the Fn key; Pressing it will
actually send its key-down sequence as long as it is held down;
however the rc driver will grab it, and not propagate it for further
processing (using
rc.conf for example). Instead, with Fn held down,
pressing for example the "k" key will have the rc driver output the
kp2 key to the rc (not just the keyboard) driver. I suspect this is
not a correct design. Note that this is a property of the Tuxbox
driver, not of the keyboard.
It can also be said that this protocol makes a fairly clever
debouncing algorithm in the driver possible. Just sending a sequence
of down-events, it is fairly easy to unintentionally produce double
presses (like "11" or even "111" instead of "1"). With the described
protocol, together with debouncing in the driver, the chance for
unintentional double presses is practically eliminated, and the
keyboard acts like quite a sensible remote replacement.
.