IR control of the Tuxbox taken to the limit

Sammlung von Anleitungen und HowTos für dBox2
Barf
Developer
Beiträge: 1475
Registriert: Dienstag 4. Februar 2003, 22:02

IR control of the Tuxbox taken to the limit

Beitrag von Barf »

Since quite some time (see e.g. this),
I have planned to write some stuff on what can be achieved with IR
remote control of the dBox using the Tuxbox software.

I plan six parts.
  • 1. Motivation
  • 2. Theory
  • 3. Pronto (CCF)-Codes
  • 4. One For All (URC) Remotes, without special tools
  • 5. One For All Remotes, the JP1 way.
  • 6. Odds and ends
Just a polite request to other forum participants: This is the HOWTO forum, a
forum for documentation. Feel free to post discussion and on-topic
questions in the thread. However, I kindly ask that support questions ("it does
not work for me?", "how do I ...") be posted somewhere else, Create
new thread(s) as necessary. (And, of course, no personal PMs with
technical questions.)
Barf
Developer
Beiträge: 1475
Registriert: Dienstag 4. Februar 2003, 22:02

Part 1. Motivation

Beitrag von Barf »

1. Motivation

For the Neutrino user, there are two reasons to request more than the
26 (footnote 1) "normal" keys: First, through "Settings" ->
"Keybinding", there are different possibilities to bind different
events to different keys. Secondly, it is possible, using the
configuration file /var/tuxbox/conf/rc.conf (see
this documentation)
to bind a number of interesting and useful actions (like arbitrary
shell commands or the invocation of plugins) to arbitrary remote
control keys. Thereby it will soon be clear, that the 26 "normal" keys
already carry a number of different functions, and it is desirable
to have other keys available for customization. Thereby there are,
theoretically, two possibilities: The
"extra keys" (Footnote 2) on the remote are understood by the
software, but on (almost) no
normal remotes physically present. ("page_up" and "page_down" (called
"Doppelpfeiltasten", in
the form of a 90° rotated fast-forward-symbols) was present on a few
very early (dBox1?) remotes sold by Premiere.) Secondly, there are
the
dBox keyboards, which contains a large number of keys, normally not
used by the software. It is of course possible to use the keyboard as
a very bulky remote. More attractively, however, is to somehow "suck"
the keys (e.g. using a learnable remote, more to this later), and
sending them from a standard-size remote.

The Enigma user has, as far as I am aware of, even more possibilites
for indivual key bindings.

Footnote 1. The "normal" keys are: 0,...,9, Vol+, Vol-, up, down, left,
right, ok, home, dbox, red, green, yellow, blue, power, help,
mute.

Footnote 2. "Extra" keys are: page_up, page_down (in early hardware
sometimes called "doppelpfeiltasten" (double arrow keys)), topleft,
topright, bottomleft, bottomright.
Barf
Developer
Beiträge: 1475
Registriert: Dienstag 4. Februar 2003, 22:02

Part 2. Theory.

Beitrag von Barf »

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.
Barf
Developer
Beiträge: 1475
Registriert: Dienstag 4. Februar 2003, 22:02

Part 3. Codes in Pronto format

Beitrag von Barf »

3. Codes in Pronto format

For the purpose of this article, the "Pronto format", sometimes called
"ccf format", is a well established form for exchange of raw IR
signals. Here "raw" means that the signals are given as a number of
on/off pairs, not as protocol and parameter values. A raw signal can be
either clean or dirty, actually there is a priori no way to tell.

This XML file contains raw Pronto codes of all the three types discussed in the
previous section, packed in an XML file. They can be used, surprise, by the Philips Pronto
family of touchpanel remotes and their "clones" (Marantz, Yamaha,...), as well as a number of other
systems, like the Globalcache
and IRTrans families of IR
transmitters (some conversion needed).

Users of ProntoEdit (or a similar program, like the freeware Tonto) can download a
RU-890 ccf file containing all codes in a form that can be bind to own keys.

LIRC is probably fairly well known in
this forum. Clean Lircconfigs are available for the
old protocol, the new protocol, as well as the
keyboard protocol.

In the near future, I intend to submit IRTrans rem-files to the
IRTrans forum.
Barf
Developer
Beiträge: 1475
Registriert: Dienstag 4. Februar 2003, 22:02

Part 4. One For All remotes

Beitrag von Barf »

4. One For All remotes

4.1 General

There is a large number of "universal remote controls" on the market
today. Almost all are "preprogrammed" in the sense of having a number
of protocols coded in, and a data base for known device; for each
known device consisting of its parameters (protocol, device number
etc., as well as an assignment of commands to command numbers). The
remotes are configured by selecting a particular device code, typically
given in the documentation or on a WWW site. The assignment of the
keys is often found to be incomplete; not only does the (remote-)
manufacturers sometimes a less-than-perfect job, often the (device-)
manufacturer introduces new models, containing new commands. Also, in
many cases, devices contain undocumented IR commands, not present on
the original remotes (typically discrete power on/off commands
etc.). For this reason, many universal remotes comes with an
additional learning facility, allowing the remote to "learn" a
particular IR signal. As should be clear to the reader, this is not a
technologically very sound solution. Not only is the learned sequence
imperfectly learned, it takes up quite large space in the memory.

Selecting a particular device on a preprogrammed remote,
(in general) the different keys send commands that only differ in
the command number. On some remotes, it is possibly to send IR signals
corresponding to also other command numbers than originally bound. In
this way, a 32 key for the Tuxbox (using either the old or the new
protocol) can be implemented.

Many of the remotes from Universal Electronics Inc., manufactured
under the name One for all can do
this. It is even a documented feature called "Key magic". How this
works differs (somewhat) between modes, and is described in the
documentation. Typically (e.g. URC-7556) it goes like this: Press
desired device button. Press and hold the key marked "Magic" until the
"something" (in case of the URC-7756 the selected device button) key
blinks twice. Press "9", "9", and "4". "Something" now blinks
twice. Press "Magic" again. Then enter the desired "EFC-number" (in
general five digits), followed by the key that is to be assigned. The
"something" now blinks twice, and you are ready. It only remains to
find the "EFC" (extended Function Code) numbers. According to the
OfA-Manuals, this information is given per telephone from the
OfA-Hotline. But read on instead...

Remark. I am pretty certain that this property is, possibly
undocumented, present in remotes from other manufacturers.

4.2 The old protocol in OfA

In most OfAs, the old protocol can be accessed with the code number
0723 in the Satellite category. It turns out that, not only the
"extra" keys (page up/down, top/botton-right/left) are missing, but
also many of the fundamental ones. So, the above described key binding
("key magic") is used to assign the missing ones. The EFC codes are
found in this file as XML attributes. Note that there are three
"commandset"s in that file, the first one is describing the old
protocol. Also note that most OfAs expect a 5 digit
EFC, so the given EFC has to be padded with zeros. For example, the
"red" key has to be entered as EFC 00111.

4.3 The new protocol in OfA

This is similar to the old protocol. The code is 1114 (for "some I
tried"). Again, missing keys can be bound with the same procedure; the
EFCs are found in the same XML-file (but note that the EFC numbers are
different within the new and the old protocol).

Using this procedure, a 32-key-remote using either the old or the new
protocol can be implemented in 10-15 minutes.

4.4 Emulating the keyboard

To my knowledge, there is no preprogrammed remote that can send the
keyboard signals. For reasons described before, it is likely an
unusually hard task for a learning remote to learn this signals. But
see the next part of this article!
Barf
Developer
Beiträge: 1475
Registriert: Dienstag 4. Februar 2003, 22:02

Part 5. The JP1 way

Beitrag von Barf »

5. The JP1 way

Surely many readers who have read the previous chapter wish to
perform the customizations of the remote in a more comfortable
computer environment, and, also, to be able to save, restore, and
share the outcome. This is exactly what we will do in the present
chapter.

5.1 JP1 remotes

Many of the OfA remotes comes with a 6-pin connector, typically
located near the batteries. See photo. This connector is labeled
"JP1" on the PCB. This connector was likely intended for internal
tasks to the manufacturer, like debugging, upgrading etc. However,
the characteristics of this interface was soon discovered -- it is
essentially a TTL-level serial port.

JP1 remotes are manufactured by Universal Electronics Inc., sold under
their own brand name One for All, but also as Radio Shack, Sony,
Dreambox, and likely also others. Note that the OfA product line is
completely different depending upon what side of the Atlantic you
live.

In some cases, the JP1 connector is available and easily accessible,
in other case, it can be extra soldered in, or there is a suitable
contact area that can be accessed using pogo pins. In yet other cases,
it may be available and accessible but only while the battery power is
interrupted, unless some hardware modification has been done.

5.2 The JP1 project

This spawned what is now known as the
JP1-Project. It is to
UEI remotes roughly what the Tuxbox project is to the dBox. It is not
my goal to give a description, for this, see the JP1 forum. Anyhow, to
cut a long story short, and allowing several simplifications, the
needed tools (at least for the context of the present article) are:
  • A "JP1-cable" (JP1.x) for connecting the remote connection to a
    serial port,
    a USB port, or a parallel port on a
    computer. This is for reading and writing of the flash memory of the
    remote. See the forum for different types, building instructions,
    and/or purchase sources.
  • The IR program. The main program for interacting with the
    remote. In its most primitive usage, it allows reaout of the (user)
    flash memory, manipulaton thereof, saving and restoring to/from
    disc, etc, However, (assuming that a so-called rdf-file for the present remote
    is available) it also understands the meaning of the contents, and
    can thus manipulate all possible settings (device usage, key moves,
    macros, learned signals, etc.)
    Windows only, Freeware, but sources (at least presently) not
    available.
  • RemoteMaster. A Java program (sources available on Sourceforge) for
    the creation and manipulation of so-called device upgrades. These are
    new "devices" with own setup numbers. Commands and their command
    numbers can be assigned essentially arbitrarily to the available keys.
5.3 The new protocol

It is of course easiest to use the build-in setupcode 1114. Only a few
keys need to be added, which can easily be accomplished with the
keymove feature of IR.

Alternatively, it is possible to design a so-called device upgrade,
using for example RemoteMaster. The advantage is possibly more of a
systematic nature: within a device upgrade, you decide exactly what to
assign to what key, instead of modifying something someone else have
done, with a cryptic syntax (EFC-codes).

I have uploaded a Remotemaster device upgrade for the dBox using the
new protocol to the JP1-Forum here. It can be used as
is, or as a starting point for an individual customization.

5.4 The old protocol

It has already been mentioned in the previous part, that code 0723
corresponds to the old protocol, and that appropriate key moves can be
made. It is easily suggested, that it should be possible to build a
device upgrade using the protocol,NRC17 in Remotemaster, However, this
will not work. This is probably the problem described
here.

5.5 The keyboard protocol

On a request in the JP1 forum, Vicky ("vickyg2003") and
Rob ("The Robman") succeeded to implement the Nokia12 protocol as a custom
protocol. Using this protocol, it is possible to write a device update
for emulating the dBox keyboard
(Vicky's version (including Protocolbuilder code), my version (using names consistent with the rest of this
article). Many thanks to Rob and Vicky for their efforts!
Barf
Developer
Beiträge: 1475
Registriert: Dienstag 4. Februar 2003, 22:02

Part 6. Odds and ends.

Beitrag von Barf »

6. Odds and ends.

Here I collect some stuff that did not fit logically anywhere else.

6.1 Waking up the dBox from (deep) standby.

When in deep standby, the front processor governs the behavior, and
determines the events that is going to wake up the system. This is not
only IR signals, but also the front panel keys, and pin8 on the VCR
SCART connector (the latter not on the Sagem however). Some IR signals
from the remote wake up the system other not. For example, the
numerical keys, the "OK"-keys wake up, but not the volume keys or the
Help key. No keyboard keys wake up. In the
XML file with Pronto codes the codes waking up has been identified using the
attribute wakeup. However, while this is correct on my Nokia dBox
(BMon V1.0); it is quite likely that other firmware releases exist,
which behave differently.

6.1 Discrete on/off

The property of having separate commands, (just) turning the system
on, and another (just) turning it off (irrespectively on the present
state) is essential for all kind of serious automation. If you only
have a power-toggle command, it is not possible to write a macro to
unconditionally turn off the system, since power-toggle will turn it
on if already off. As with many modern pieces of customer equipment,
the Tuxbox (as well as the original Betanova software) does not come
with discrete on or off commands. However, with the tools now at our
disposal, this can be fixed:

6.1.1 Discrete on

Since the front processor, to which we have essentially no change
power, governs the wake-up behavior from deep standby, a candidate
discrete power on has to be one of the keys waking up, see the section
above. It probably should also make Neutrino leave soft standby. This
takes place for the power key, and also, with appropriate settings
(Main menu -> Settings -> Miscellaneous -> General -> Standby off with)
also the Home- and/or the OK-key. With this setting appropriate, the Home
key is very close to a discrete on key: it wakes up from both deep and
shallow standby, and has otherwise moderate side effects. It is also
possible to make a 100%-bona-fide discrete on key, by assuring
that it has no other functions, for example, in rc.conf:

Code: Alles auswählen

rc_standby=rc_null
rc_standby[r]=rc_null
rc_standby[u]=standby_off
6.1.2 Discrete off

Discrete off is actually easier; just take an unused key, and
associate the shutdown action to it, e.g.

Code: Alles auswählen

rc_bottom_right[r]=shutdown
6.2 Logitech harmony support

The Logitech Harmony family of remotes is in some forums considered as
the best thing after sliced bread. At least for people preferring
phoning hotlines over understanding technology...
My attempt to have it to control the Tuxbox in a sensible was rather disappointing. But I admit that it looks fancy...

Here is a (German) page on loading Pronto codes in the Harmony (have not tried it myself).

6.3 TODO

Write appropriate documentation for the rc,conf file and its
options. This page exists, but is not really up to my quality requirements as
documentation for rc.conf.

6.4 Assorted links

This page on my own site describes the dbox keyboard as well as the
rc.conf option.

A thread on getting the rc drivers right.

A thread on discrete power commands. Note how ignorant some participants treat the issue. Also see
this continuation.

This thead describes the development of (some of) the keyboard
support, both in the sense of computer keyboard and in the sense of
bulky remote control.

And, finally, my present pet, in case anyone is interested.