Importing Foreign IR Remotes in RemoteMaster

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.

History

The previous version of this article described a faily "dumb" method of exporting a Girr file from IrScrutinizer to a stripped-down RemoteMaster rmdu file, using a effectively empty, dummy executor called "ImportOnly". This is imported in RemoteMaster, after which the user has to chose the executor manually. The previous version can be access through the Wiki history function, or directly here.

Since then, amazing work has been done in RemoteMaster on importing foreign IR signals, or more exactly, mapping the foreign protocols on the JP1's executors. Accordingly, Girr files can be imported directly, which makes the importing procedure almost automatic.

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.

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.

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.