Importing Foreign IR Remotes in RemoteMaster

From JP1 Remotes
(Difference between revisions)
Jump to: navigation, search
m (protocols.ini already contains ImportOnly since RM 2.04build10. Fixed broken link to Oppo codes.)
(→‎Example)
 
(12 intermediate revisions by one user not shown)
Line 1: Line 1:
−
= Importing Foreign IR Remotes in RemoteMaster =
+
= Ultra-short version =
  
−
''This guide will take the reader through a method for importing foreign (i.e. non-JP1) IR remotes into RemoteMaster.''
+
* Perform an "Girr" export from IrScrutinizer to a file,
−
''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.''
+
* Open the above created file in RemoteMaster. Perform desired fixes.
  
−
= Ultra-short version =
+
= 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 [http://www.hifi-remote.com/wiki/index.php?title=Importing_Foreign_IR_Remotes_in_RemoteMaster&oldid=880 here].
  
−
* Perform an "RemoteMaster" export from IrScrutinizer 1.3 (or later) to a temporary file,
+
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.
−
* Open the above created file in RemoteMaster. Select a usable executor manually. Perform other desired fixes.
+
  
 
= Introduction =
 
= Introduction =
Line 19: Line 21:
 
But still some cases remain; in particular self captured ("learned") remotes.  
 
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,
+
Of course, one way to solve the problem would be to manually type the signals
−
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.
 
(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.
 
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.
 
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.
+
= Solution =
  
−
= Background (Mythbuster's lingo: Danger: Science!) =
+
The [http://www.harctoolbox.org/Girr.html 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. It is the native format of [http://www.hifi-remote.com/wiki/index.php/IrScrutinizer_Guide IrScrutinizer].
−
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''',
+
First, acquire or generate a suitable Girr file. 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).
−
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)
+
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, RM inquires the user 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, so 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.
−
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,
+
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.
−
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.
+
= Example =
−
Instead, this is delegated to the user. The following solution is proposed:
+
We consider the Oppo BDP 103 BluRay player, which has a [http://download.oppodigital.com/BDP103/BDP-103_BDP-105_Remote_Code_v1.1.xls published set of IR commands].
 +
(The [http://www.hifi-remote.com/wiki/index.php?title=IrScrutinizer_Guide#Importing_.22text.22_files IrScrutinizer Tutorial]
 +
describes how such files can be imported into IrScrutinizer.) We have downloaded the Excel file and saved it as a csv (comma separated values) file. Here we show the import from that csv file:
  
−
= Outline of Solution =
+
[[Image:Screenshot%20from%202022-05-14%2022-16-25.png]]
−
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.
+
  
 +
We now assume that this command set has been imported as parametrized in IrScrutinizer, see the screenshot below.
 +
Every row of the table denotes a command, has a (unique) name, a protocol, and one or more parameters. A comment may describe the command further.
  
−
= Preparation =
 
−
Two things needs to be done once-and-for all to RM. These need not be repeated.
 
  
−
== Extending '''protocols.ini''' ==
+
[[Image:Screenshot%20from%202022-05-14%2021-54-01.png]]
−
 
+
−
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
+
−
 
+
−
<pre># 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.
+
−
</pre>
+
−
 
+
−
to '''protocols.ini'''.
+
−
 
+
−
== Selecting '''Allow preserve control''' ==
+
−
The RM parameter '''Allow preserve control''' has to be selected; see figure
+
−
[[Image:rm_select_allow_preserve.png]]
+
−
 
+
−
 
+
−
= Procedure =
+
−
 
+
−
* First, a "dumb" rmdu file is generated, using the '''ImportOnly''' executor, using IrScrutinizer 1.3 (or another tool),
+
−
* This is imported in RM. The user there selects a usable executor. If RM computes the parameters correctly, this will produce a working rmdu device update.
+
−
 
+
−
== Caveat ==
+
−
 
+
−
As is probably clear to the user, some prior knowledge is required of the user. If RM do the computations correctly, this should
+
−
result in usable rmdu file. However, this functionality is not very widely used, and bugs may show up. (In that case, please report
+
−
in the forum.)
+
−
 
+
−
 
+
−
= Example =
+
−
We consider the Oppo BDP 103 BluRay player, which has a [http://download.oppodigital.com/BDP103/BDP-103_BDP-105_Remote_Code_v1.1.xls published set of IR commands].
+
−
(The [http://www.hifi-remote.com/wiki/index.php?title=IrScrutinizer_Guide#Importing_.22text.22_files 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.
+
−
 
+
−
[[Image:irscrutinizer_param_table.png]]
+
  
  
Line 116: Line 53:
 
Here, the protocol is "NEC1", D = 73, and S is "nonexistent".
 
Here, the protocol is "NEC1", D = 73, and S is "nonexistent".
 
Having inspected this table, and made
 
Having inspected this table, and made
−
any desirable changes, the table is exported,
+
any desirable changes, the table is exported, by selecting the "Export" pane, selecting "Girr" as the Export format, checking "Parameters" and pressing "Export param. remote".
−
 
+
This creates a girr file.
−
[[Image:irscrutinizer_param_export_rmdu.png]]
+
−
 
+
  
−
by selecting the "Export" pane, selecting "RemoteMaster" as the Export format, and pressing "Export param. remote".
+
[[Image:Screenshot%20from%202022-05-14%2021-15-25.png]]
−
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 starting RMDU, the just-created simple girr file is imported through File -> Open.
  
 
[[Image:rm_opening_file.png]]
 
[[Image:rm_opening_file.png]]
  
−
After opening the file, RM will present an error popup:
+
Next screenshot shows RMDU after the import:
  
−
[[Image:rm_popup.png]]
+
[[Image:Screenshot%20from%202022-05-14%2021-32-52.png]]
  
−
This simply means that, although RM understood the protocol (executor really) named '''ImportOnly'''
+
Now, select the "Functions" pane, and check the sanity of its content, in particular hex- and OBC values.
−
(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.
+
  
−
[[Image:rm_selected_executor.png]]
+
[[Image:Screenshot%20from%202022-05-14%2021-33-56.png]]
  
−
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.
 
−
 
−
[[Image:rm_imported_functions.png]]
 
  
 
The import has been successful! It now remains to tune the device update (rmdu) to your needs:
 
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
+
adjusting description, notes, device type as desired, select setup code and the target remote, assigning the functions to its buttons, saving the
 
file to a suitable name, etc.
 
file to a suitable name, etc.
 
This is outside of the scope of this article, and described in detail the RM documentation.
 
This is outside of the scope of this article, and described in detail the RM documentation.
 +
 +
= Remarks =
 +
 +
== Import ict files from IrScope ==
 +
 +
RMDU can also import ("open") ict files from the program [http://www.hifi-remote.com/wiki/index.php/IR_Scope_and_IR_Widget_User%27s_Guide IrScope].
  
 
= Support and help =
 
= Support and help =

Latest revision as of 10:05, 15 May 2022

Contents

[edit] Ultra-short version

  • Perform an "Girr" export from IrScrutinizer to a file,
  • Open the above created file in RemoteMaster. Perform desired fixes.

[edit] 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.

[edit] 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.

[edit] 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. It is the native format of IrScrutinizer.

First, acquire or generate a suitable Girr file. 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, RM inquires the user 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, so 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.

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.

[edit] 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 have downloaded the Excel file and saved it as a csv (comma separated values) file. Here we show the import from that csv file:

Screenshot from 2022-05-14 22-16-25.png

We now assume that this command set has been imported as parametrized in IrScrutinizer, see the screenshot below. Every row of the table denotes a command, has a (unique) name, a protocol, and one or more parameters. A comment may describe the command further.


Screenshot from 2022-05-14 21-54-01.png


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 "Girr" as the Export format, checking "Parameters" and pressing "Export param. remote". This creates a girr file.

Screenshot from 2022-05-14 21-15-25.png

After starting RMDU, the just-created simple girr file is imported through File -> Open.

Rm opening file.png

Next screenshot shows RMDU after the import:

Screenshot from 2022-05-14 21-32-52.png

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

Screenshot from 2022-05-14 21-33-56.png


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 setup code and 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.

[edit] Remarks

[edit] Import ict files from IrScope

RMDU can also import ("open") ict files from the program IrScope.

[edit] 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.

Retrieved from "http://www.hifi-remote.com/wiki/index.php?title=Importing_Foreign_IR_Remotes_in_RemoteMaster&oldid=1232"
Personal tools
Namespaces

Variants
Actions
Navigation
Tools