Revision as of 19:38, 14 May 2022

Importing Foreign IR Remotes in RemoteMaster

This guide will take the reader through a method for importing foreign (i.e. non-JP1) IR remotes into RemoteMaster. The procedure requires some knowledge by the user, who have to make some manual decisions. The guide is not aimed at beginning users. Some prior knowledge about RemoteMaster and IrScrutinizer is assumed. Also, importing raw or unknown codes are not covered.

Ultra-short version

• Perform an "RemoteMaster" export from IrScrutinizer 1.3 (or later) to a temporary file,
• Open the above created file in RemoteMaster. Select a usable executor manually. Perform other desired fixes.

Introduction

The Internet is a vast source of infrared code sets, see for example this list. For usage with RemoteMaster ("RM"), this information is in general not directly usable. Often, usable RM device update files ("rmdu") can be found in the JP1 device update repository (see also the master list and the lookup tool). But still some cases remain; in particular self captured ("learned") remotes.

This article only deals with decoded signals, i.e., the IR signals are considered as consisting of a parametrized protocol, together with its parameters. Of course, one way to solve the problem would be to manually type the signals (protocol, parameters, name, possible comment) in the function editor of RM, possibly the help of cut-n-paste. This is a very tedious and error prone approach. Importing these in a systematic way, with minimal interaction, is the topic of the current article.

It turns out that, with the current state of technology, the process is not fully automatic, but necessarily involves human interaction.

Background (Mythbuster's lingo: Danger: Science!)

The protocol and the corresponding parameter values constitute a mathematical description of how to render the signal as a sequence of on/off durations. This is good for us to examine, generate, exchange with others. Unfortunately, it is not quite the language the UEI remotes speak: Instead of "protocols", they contain a number of "executors", which are a small programs in machine code, responsible for computing the IR signal. Unfortunately, they are in general differently parameterized, and not in 1-1 correspondence with the protocols. Many executors implement several different protocols, so-called "combos". Also, for a particular protocol, there are often more than one executor to choose from. To make things extra interesting, "executors" are in the RM program and documentation in general referred to as "protocols".

For example, the NEC1 protocol is implemented by a number of different executors, NEC1, NEC 1or2 Combo, NEC 2DEV Combo, NEC 4DEV Combo, and others. Some of these also implement other protocols (like NEC2), some allow several different "D"s. All have slightly different properties.

Another problem is that the master parameter for the individual commands is the "F" parameter (called "OBC" in RM) in the protocol, but the hex parameter in RM. The details are outside of the scope of this article, but we just state some facts about the mapping OBC <-> hex:

• it depends on the executor (i.e., it is different for different executors),
• the hex parameter might depend on more input data than the OBC,
• it is "complicated", but deterministic and memory-less,
• RM can do this computation, provided that Allow Preserve Control

(accessable as Options -> Allow Preserve control) has been selected.

Importing a set of IR commands basically boils down to selecting an executor, computing its parameters, and, for all contained commands, compute the hex parameter.

For this reason, it has not been attempted to automatically selecting the executor from input data. Instead, this is delegated to the user. The following solution is proposed:

Outline of Solution

A deliberately "dumb" solution is proposed. A trivial "mock" executor, ImportOnly, having hex = OBC, has been added to protocols.ini. An export is performed using this executer. We then rely on the user to select a usable executor, and on RM to compute the corresponding parameters.

Preparation

Two things needs to be done once-and-for all to RM. These need not be repeated.

Extending protocols.ini

RemoteMaster's data base protocols.ini, located in the base directory of RM, already contains ImportOnly since version 2.04 build 9. If using an earlier version, add the following lines

# Add this to the end of protocols.ini of Remotemaster in order
# to import IrScrutinizer rmdu exports.
[ImportOnly]
PID=99 99
DevParms=Device:8=0,Sub Device:8=0
DeviceTranslator=Translator()
CmdParms=OBC:16=0
DefaultCmd=00
CmdTranslator=Translator()
Notes=This is a trival dummy executor (protocol), intended to import third-party incomplete device updates, allowing the user to manually fix it up. It will preserve Device, Sub Device, and OBC.\n\nThe user must select a usable protocol instead of this one. First please check Options -> "Allow preserve Control", and then select "Preserve: OBC and function parameters" on the "Setup" pane.

to protocols.ini.

Selecting Allow preserve control

The RM parameter Allow preserve control has to be selected; see figure

Solution

The Girr format for IR signals is an open and very versatile format for collections of IR signals. These can be parametrized, or in raw format. It is an XML based format.

First, acquire or generate a suitable Girr file. [IrScrutinizer_Guide IrScrutinizer] can generate such files, either by (using a suitable hardware receiver) "learning" an available physical remote, or by importing/converting from other format. (See the example below).

This file is then imported into RMDU, by "Open"-ing them. (See pictures in the next section). If the Girr file contains more than one remote, the useer is required to select one of them. In rare cases, the user is requested to select between several possible alternative executors. Although the import almost always succeeds, in rare cases it may fail. The import should be checked for plausibility. Assign the keys to functions, and make other desired fixes. The thus created device update can now be used as any other update.

Remark

Importing remotes is still a quite complicated process. Limitations (for example by "uncommon" protocols, or if signals from several substantially different protocols are present), and in rare cases even bugs, may show up. In this case, please report in the forum.

Example

We consider the Oppo BDP 103 BluRay player, which has a published set of IR commands. (The IrScrutinizer Tutorial describes how such files can be imported into IrScrutinizer.) We assume that this command set has been imported in IrScrutinizer, see figure. Note that every row denotes a command, has a name, a protocol, and one or more parameters. A comment may describe the command further.

Typically, the protocol and all but one parameter, in general called "F", are constant. Here, the protocol is "NEC1", D = 73, and S is "nonexistent". Having inspected this table, and made any desirable changes, the table is exported,

by selecting the "Export" pane, selecting "RemoteMaster" as the Export format, and pressing "Export param. remote". This creates a simple rmdu file.

We assume that RM has been prepared as per above. After starting, the just-created simple rmdu file is opened (File -> Open).

After opening the file, RM will present an error popup:

This simply means that, although RM understood the protocol (executor really) named ImportOnly (because _we_ put it into its protocols.ini!), it says that the currently selected remote does not support it, and the user must select another one. (Just as we would expect!) We know that the desired protocol is called "NEC1", so we next have to select an executor implementing that protocol. For the purpose of this example, we select the executor named NEC1, using the "Protocol" combo box. Make sure that as "Preserve" "OBC and function parameters" is selected.

Check that the protocol parameters (executor parameters really) make sense. Here, the "D" in the protocol has been successfully turned into the parameter "Device" (= 73), and the "Sub Device" is empty, as expected.

Now, select the "Functions" pane, and check the sanity of its content, in particular hex- and OBC values.

The import has been successful! It now remains to tune the device update (rmdu) to your needs: adjusting description, notes, device type as desired, select the target remote, assigning the functions to its buttons, saving the file to a suitable name, etc. This is outside of the scope of this article, and described in detail the RM documentation.

Support and help

Please post help requests in the forum.

Suggestions for improvements, both of the procedure here described, and of the present document, are solicited.