Hifiremote Wiki - User contributions [en]

IrScrutinizer Guide

2025-10-11T12:25:25Z

Barf: Use https (instead of http) for RemoteCentral.

[[Image:irscrutinizer_splash.png]]

= Introduction =
IrScrutinizer is a powerful program for capturing, generating, analyzing, importing, and exporting of infrared (IR) signals. For capturing and sending IR signals several different hardware sensors and senders are supported. IR Signals can be imported not only by capturing from one of the supported hardware sensors (among others: IrWidget, Global Caché, and Arduino), but also from a number of different file formats (among others: LIRC, Wave, Pronto Classic and professional, RMDU (partially), and different text based formats; not only from files, but also from the clipboard, from URLs, and from file hierarchies), as well as the Internet IR Databases by Global Caché and by IRDB. Imported signals can be decoded, analyzed, edited, and plotted. A collection of IR signal can thus be assembled and edited, and finally exported in one of the many supported formats. In addition, the program contains the powerful IrpTransmogrifier IR-renderer and -decoder, which means that almost all IR protocols known to the Internet community (over 100) can be generated as well as decoded.

This document is not a manual for IrScrutinizer. (The full manual is found [https://www.harctoolbox.org/IrScrutinizer here], which should be read for questions not addressed here). Instead, it is a gentle guide to a program that can possibly look somewhat overwhelming at the first look. It focuses on what tasks can be achieved, and on the general "why", instead of a detailed description of all features.

As a tutorial, this document is not updated as often as the program, or even as the documentation. So the current program may have slightly different features and slightly different look than shown here.

== Prerequisites ==
For the sequel, a basic understanding of IR signals is required. My favorite introduction is [http://www.sbprojects.net/knowledge/ir/index.php the one by San Bergmans]. My [https://www.harctoolbox.org/Glossary.html glossary] (also included under the Help menu of the program) may come in handy. In particular, there is a concise description of the [https://www.harctoolbox.org/Glossary.html#ProntoSemantics semantics of the Prono hex format].

== History ==
In 2011, I wrote an IR signal "engine" implementing the [[IRP Notation]], called [https://www.harctoolbox.org/IrpMaster.html IrpMaster]. It was invoked as a command line program. Later that year, a program called [https://www.harctoolbox.org/IrMaster.html IrMaster] was released, which among other things constitutes a user friendly GUI front end to IrpMaster. The first versions of the present program, IrScrutinizer, was also based on IrpMaster, and adds functionality from IrMaster, in particular the possibility to collect IR signals, a vastly improved import and export facility, and edit collections of IR commands. (IrScrutizer almost completely replaces IrMaster, which is no longer maintained.) In 2019, IrpMaster, and the decoding engine DecodeIR, was replaced by IrpTransmogrifier, which is an even more developed rendering and decoding engine.

== Copyright ==
The program is copyright(c) by Bengt Martensson, and is Free Software published under the [https://www.gnu.org/licenses/gpl.html GPL3 license]. My copyright does not extend to the embedded "components", which are published under similar, but compatible licenses. Details are given in the [https://www.harctoolbox.org/IrScrutinizer.html#Copyright+and+License manual].

= Concepts =
For anyone familiar with the IR signals, the program is believed to be intuitive and easy to use. Almost all user interface elements have tool-help texts. Different panes have their own pop-up help. Many panes have a context menu, bound to the right mouse button.

Next picture shows the program immediately after startup.

[[Image:irscrutinizer_startup.png]]

In the upper row, there are six pull-down menus, named '''File, Edit, Actions, Options, Tools''', and '''Help'''. Their usage is believed to be mainly self explanatory.

Options to the program are in general found in the '''Options''' menu, or its subordinate menus. Some parameters for particular export formats are found in the sub-panes of the '''Export''' pane. Also the hardware configuring panes contain user parameters.

The main window is composed of seven sub panes denoted by '''Scrutinize signal''' (for processing single signal), '''Scrutinize remote''' (for collecting several signals to one "remote"), '''Generate''' (generates IR signal from protocol name and parameters), '''Import''', '''Export''', '''Capturing Hardware''', and '''Sending Hardware''' respectively.

= Installation =
IrScrutinizer takes great pride of being a portable program, and runs on Windows, Linux (including RaspberryPi), and MacOS. For Windows and MacOS, native installation packages are available; for Windows it is the setup file *.exe, for Mac the zipped app *.MacOS.zip. Users of (most) 64-bit Linux-es can use the AppImage (*x86_64.AppImage) version. In all these cases, they come with its own Java installation, although the Windows version allows for using a previously installed Java. Others, and those who do not like preinstalled binaries, can install the generic binary package, or install from the sources directly.
(Files ending with md5, sha1, and sha512 are checksum files, and are not required for installation.)

Details are given [https://www.harctoolbox.org/IrScrutinizer.html#Installation in the manual]. Downloads of the currently latest released version are found [https://github.com/bengtmartensson/harctoolboxbundle/releases/latest here].

= Scrutinizing a single IR signal =
The '''Scrutinize signal''' pane is used to analyze a single IR signal. Press F9 to see a sample IR signal directly. The program will now look like this:
[[File:Irscrutinizer_F9.png]]

The upper sub-window shows the signal either as [https://www.harctoolbox.org/Glossary.html#CCF Pronto Hex] (the default) or as a number of timings in microseconds (selected by Options -> Output text format). Then there follows an output area for the results of the decode and (if selected through Options -> Invoke Analyzer) a computed IRP form, possibly together with some other identified parameters. The plot windows shows the signal, with the [https://www.harctoolbox.org/Glossary.html#ModulationFrequency modulation] removed. The [https://www.harctoolbox.org/Glossary.html#IrSignal Intro sequence] is shown red (if present), the repeat signal blue (if present), while the ending signal (only present in rare cases) is shown green.

Basically, the user enters something in the upper subwindow, or capturing something with hardware. The program will then analyze the signal. Things that can be done on this pane:
* If suitable capturing hardware is connected and opened, pressing '''Capture''' will capture one IR signal form the hardware, and scrutinize it.
* Again assuming suitable hardware opened, pressing '''Capt. (cont)''' will start a capturing thread, capturing signals over and over again, without saving, until the button is pressed again.
* The user can enter something in the upper window, often by pasting from the clipboard, or hand modifying already present content. This requires pressing the '''Scrutinize''' button.
* If suitable sending hardware is connected and opened, pressing the '''Transmit''' button will transmit the signal with the selected hardware.
* If a suitable export format is selected, the '''Export''' button will export the signal in the export format selected.

Different formats are accepted in the input window: Pronto Hex, Timing list with or without signs, as well as the Global Cache irsend formats are currently understood.

The plotter can be zoomed (of course, only on the horizontal scale) by pressing the left mouse button at the desired start point, and dragging to the desired new ending point. To reset, use "Reset plot" from the context menu or the Actions menu. For comparison with other signals, the plot can be "torn off" by Action -> Clone plot menu entry.

There are a number of other possibilities offered by the top menus, and the context menus in the different sub-windows.

=== Excercise 1. ===
Find an "arbitrary" IR signal in the JP1 or RemoteCentral forums, for example [https://www.remotecentral.com/cgi-bin/mboard/rc-discrete/thread.cgi?7443 this one]. Copy the signal to the clipboard, and paste it, and scrutinize it (the button '''Paste & Scr.''' makes it in one click).

=== Excercise 2. ===
Make sure that Pronto Hex is selected as output text format. (Options -> Output text format). Press F9, which will show a NEC1 signal. Using the keyboard, remove the last four hexadecimal numbers ("015B 0057 0016 0E6C"). Press '''Scrutinize'''. This will produce an error message, since the signal length is now inconsistent with the header. So we fix that: Change the forth number from 0002 to 0000. Pressing '''Scrutinize''' again shows that the signal now decodes, but instead of "NEC1" as [https://www.harctoolbox.org/Glossary.html#IrProtocol protocol], we now have "NEC". There is strictly speaking no protocol named NEC; this is the decoder's way of saying that it has identified a NEC-type signal, but the repeat part is missing.

= Scrutinizing a remote (several IR signals) =
Often, we would like to consider a whole set of IR signals, for example, all that can be used for controlling a piece of consumer electronics. The word ''remote'' will be used in the sequel to denote such a set of IR signals, having something in common.

IrScrutinizer, as well as most other IR signal programs, can consider an IR signal either as a [https://www.harctoolbox.org/Glossary.html#IrProtocol Protocol] and parameteres (''parameteric'') or as (one, two, or three) sequences of durations, denoting on- and off-periods, a [https://www.harctoolbox.org/Glossary.html#RawIrSignal raw signal]. Whenever possible, the parametric form should be preferred.

The '''Scrutinize remote''' pane, has two sub-panes: '''Parametric Remote''' and '''Raw Remote'''. This tutorial will only consider the parametric remote sub-pane.

The pane consists of a table, like in a spreadsheet program. There are columns for protocol name, the more common protocol parameters, name, etc. It is used for capturing a number of signals using connected hardware, or to edit/inspect a previously captured, or imported, remote. See picture.

[[File:irscrutinizer_parametric_remote.png]]

Just like in a program like Excel, the columns can be resized, edited (using the text area on top of the table), and sorted from an arbitrary column (requires enabling the sorter in the context menu). The colums can also be reordered by dragging them with the mouse.

== Capturing in Parametric Remote ==
First of all, setup and test the hardware is to be used. Make sure that the capturing hardware has been opened. To capture parametric signals, the user just presses '''Capture''', which now stays active, until pressed again. IrScrutinizer will now use a separate thread for collecting the captures, entered into the table. The user can intermix captures and entering of names with the keyboard in any order he or she wishes.

The table can be edited the keyboard. New signals can be entered, having any recognized protocol name as protocol (case not being recognized). There are also a number of interesting things that can be done with the context menu.

When finished, the table is [[#Exporting_IR_Signals | exported]] in a suitable file format. Alternatively, the table can be copied to the clipboard, for being pasted into a spreadsheet program, or the [[Remote_Master_Manual#Functions_Tab|Remote Master functions tab]].

= Generating IR Signals =
IrScrutinizer can generate well over 100 different IR protocols. For this, select the desired protocol from the combo box. Different protocol require different parameters. The four most common are D ("device"), S ("subdevice"), F ("function"), and T ("toggle"). After having selected protocol, the fields corresponding to parameters not used by the current protocols are disabled. Also, some protocols need other parameters. In this case, these are entered in the '''Additional parameters''' text field, using the format like '''X=0 Y=42'''. Note that there are no spaces around the equals sign, however, space between the assignments.

The signal is generated by pressing '''Generate'''. See the picture.

[[Image:irscrutinizer_generate.png]]

The thus generated signal can be [[#Exporting_IR_Signals | exported]], or transmitted with suitable connected sending hardware. The three buttons in the lower row transfers the signal to the '''Scrutinize signal''' pane, or adds it to the '''Parametric Remote''' or '''Raw Remote''' panes.

Some versions of the program use the word "render" instead of "generate".

It is also possible to extend IrScrutinizer with new protocols. This is done by adding protocols to the protocol data base, the file IrpProtocols.xml, but is well outside of the scope of this introductory guide.

= Importing IR Signals =
The Internet is a vast resource for IR signals for different devices. Unfortunately, there is no universally accepted exchange format for a "remote", i.e. a collection of IR signals with names. For this reason, IrScrutinizer implements a number of different importers. These serves to fill the table '''Parametric Remote''' or '''Raw Remote''', where the imports can be further edited. That table does on clear on subsequent imports, so it can be used to merge signals from different sources. Data bases, local files (even zip-ped), directory hierarchies, and URLs, and even the clipboard can be imported.

In this introductory guide, we do not describe all the different importers. Usage of the not described importers is in general similar to the ones described.

== The IRDB Database ==
''This section is no longer correct -- replaced by RemoteLocator, and should be rewritten.''

[http://www.irdb.tk IRDB] is "one of the largest crowd-sourced, manufacturer-independent databases of infrared remote control codes on the web, and aspiring to become the most comprehensive and most accurate one."

To use, select the '''IRDB''' sub-pane within the '''Import''' pane. First, select "Select me to load" in the '''Manufacturer''' combo box, in order to load the list of known manufacturers. Select the desired one. This loads the list of '''Device Type''''s known for that manufacturer. The '''Protocol & Parameters''' combo box is now loaded by the known "devices". Select one, and press the '''Load''' button. This downloads the information from the data base and pushes it to the tree in the left middle part. Alternatively, the button '''Load all''' will load all of of the entries under '''Protocol & Parameters'''. The next picture shows IrScrutinizer after having '''Load all''' Sony video projectors.

[[File:irscrutinizer_irdb_sony.png]]

(During import, IrScrutinizer detected some inconsistencies in the imported data, as indicated by the messages in the console.)

The import tree is organized like this: The top level note is always "Remotes". Its immediate children are the remotes in the import, and can be opened or closed by clicking on the symbol to the left of the folder symbol. (The picture shows the first remote closed, and the second remote opened.) The children of the remotes are the named IR signals. By hovering the mouse over one such, its protocol and parameters (if available) are displayed as tooltips. (See the picture, where "DYNAMIC" is selected.)

The signal can now be imported by pressing '''Import all''', which transfers them to the '''Parametric Remote''' sub-pane in '''Scrutinizer remote''' pane. Alternatively, a subset can be selected with mouse clicks, (Shift-left and Ctrl-left works as espected for selecting multiple signals) and imported by '''Import selection'''. The button '''Import signal''' transfers the (single) selected signal to the '''Scrutinizer signal''' pane. If suitable sending hardware is opened, a selected signal can be transmitted directly by the '''Transmit selected''' button.

== Importing Lirc files ==
Both inside and outside of the Lirc community, there is often a need either to analyze or to extract the information in a Lirc configuration file. IrScrutinizer is very well fit for this task, as it contains a great deal of the Lirc code (translated to Java). The [https://sourceforge.net/p/lirc-remotes/code/ci/master/tree Lirc remotes data base] is also a considerable resource, to be considered when hunting the Internet for IR codes.

To import a single Lirc file posted in a web page or in a mail, it is easiest to just copy it to the clipboard, got to the '''Lirc''' import pane, and click '''Load from clipbard'''. To load a local file, use the '''...'''-Button to navigate to the file, and press '''Load File/URL''' to perform the actual import. This can also be used import directories containing Lirc configuration files. (In this way, the whole Lirc remote data base can be imported, at least if sufficient memory is available. On my computer, it takes less than one minute.)

Often, the imported Lirc files contain problems of different types. During import, there may be warnings in the console. IrScrutinizer handles these problems gracefully, in general by just ignoring the entries that it could not make sense of.

The entire Lirc data base can be browsed [https://lirc-remotes.sourceforge.net/remotes-table.html here]. (Note that the remotes without "Timing" are usable only with specialized hardware, for example a certain notebook computer, and unusable for the rest of us.)

Assuming [https://git-scm.com/ Git] is installed as a command line program, the entire Lirc remote data base can be checked out to a local disc by a command like

<code>git clone git://git.code.sf.net/p/lirc-remotes/code lirc-remotes</code>

As the name of the text area and button suggests, also URLs, like <code>
https://sourceforge.net/p/lirc-remotes/code/ci/master/tree/remotes/yamaha/RX-V995.lircd.conf?format=raw</code>, can be directly imported by entering it into the '''File/URL''' area.

== Importing Pronto Classic (ccf) files ==
In particular on [https://files.remotecentral.com/pronto/index.html RemoteCentral], there is a huge number of [https://www.harctoolbox.org/Glossary.html#ccfFileFormat CCF Files] for the Philips Pronto Classic. They are not really a data base for IR signals, rather a complete configuration for the probably best remote control there was, around 15 years ago. IrScrutinizer only considers them for importing the contained IR signals.

When downloading files from e.g. RemoteCentral, these are often zipped. There is no need to unzip these; IrScrutinizer will open the zip files directly.

When importing a CCF file, the contained devices (in the Pronto sense) will be mapped to different "remotes" in the import tree. Sub-pages of a device will all be merged together.

Unfortunately, there are often small problems within the imported files, in particular invalid IR signals. These problems are listed to the console. IrScrutinizer handles these problems gracefully, in general by just ignoring the entries that it could not make sense of.

[https://files.remotecentral.com/view/3491-7440-1/aaron_guenthers_pronto_ccf.html Here] is a file to exercise on, it contains several devices, there are sensible IR signals, as well as signals not recognized, likely bad learns.

== Importing RemoteMaster files ==
''This section is obsolete, and should be rewritten.''

The [http://www.hifi-remote.com/forums/index.php JP1 forum] is also a vast source of IR signals, see [http://www.hifi-remote.com/forums/dload.php?action=category&cat_id=4 the file section] and [http://www.hifi-remote.com/jp1/lookup/ the lookup tool]. Their files are in general "Device upgrades" configuration files for different remotes manufactured by UEI (Universal Electronics), meant to be maintained by the program [http://www.hifi-remote.com/wiki/index.php?title=Remote_Master_Manual RemoteMaster]. This means that the "protocol" used in a device upgrade can sometimes be hard to understand. The "protocol" in a device upgrade does not quite correspond to the meaning of "protocol" in IrScrutinizer, rather it is a an "executor", either built-in in the UEI remote, or a custom protocol, which is a small machine code chunk contained in the device upgrade, particular to the very microprocessor of the remote. In these cases, either an instance of that processor, or an emulator for it, would be required to faithfully render the signal. Fortunately, this is not always the case, and the contained protocols can be mapped onto the known IR protocols easily. Thus, the RemoteMaster import facility is by necessity limited and incomplete.

=== Excercise ===
[http://www.hifi-remote.com/forums/dload.php?action=file&file_id=6721 Here] is a file to try, that imports fine. (The "Download" button is only visible for logged-in users.)

== Importing Wave files ==
IrScrutinizer can import IR signal packed in wave files (*.wav). The details are outside of the scope of an introduction. (Leave "Half carrier frequency" selected, unless you know what you are doing.)

=== Excercise ===
Try importing [http://www.hifi-remote.com/forums/dload.php?action=file&file_id=12096 this file]. Note that some information on the content of the file is written to the console.

== Importing "text" files ==
In the absence of a universally accepted exchange format for remotes (in the sense of sets of named IR signals) -- a gap that the format [https://www.harctoolbox.org/Girr.html Girr] is trying to fill -- IR signals are often published in different text formats, or as spreadsheets. IrScrutinizer has quite some facilities for importing that sort of files. It can (at least not presently) not open Excel <code>.xsl</code>-files directly. Instead a spreadsheet program like Excel, OpenOffice/Libreoffice or Gnumeric can export (a subset of) its data as comma (or tab) separated values, a text file where the fields are divided by a certain character, in general the comma (,), the semicolon (;), the TAB character (ASCII 9), or general whitespace. We will cover the three sub-panes of the '''Text''' importer pane next.

=== Raw, line-based ===
"Raw, line-based" means that raw codes (e.g. in the Pronto Hex format) are found on lines by itself, preceded by a name, also on a line by itself. Many postings on RemoteCentral and JP1 follow this scheme. IrScrutinizer finds the "payload" (IR signal in any of the recognized formats, like Pronto Hex (also short format), UEI learned, timing lists, sendir) among other content, and imports it.

==== Exercise ====
Consider [https://www.remotecentral.com/cgi-bin/mboard/rc-discrete/thread.cgi?7222 this thread on RemoteCentral]. Copy the whole thread to the clipboard (Ctrl-A, Ctrl-C). Go to the '''Raw, line-based''' pane, and press '''Load from clipboard'''. There should now be 24 properly decoded signals in the tree view.

=== Raw ===
This is for importing raw formats in a spreadsheet like format (comma separate values etc). To use, select the character separating the fields as "Field separator". Select the column containing the name of the IR Signal/command, and the column containing the raw data.

==== Excercise ====
Download this [http://download.oppodigital.com/BDP103/BDP-103_BDP-105_Remote_Code_v1.1.xls Excel file] containing the IR commands for the Oppo 103/105 Bluray player. Using a spreadsheet program (e.g. Excel or LibreOffice), convert the first worksheet of it to a CSV file using any suitable field separator (e.g. TAB). Using the '''Raw''' pane, select the column containing the name, and the column containing the Pronto hex data, as well as the field separator. Import by pressing the '''Load File/URL''' button. There should now be 57 signals in the tree view, all NEC1 with D=73, varying F.

=== Parametric ===
This pane imports IR signals given as protocol and parameters. As the excercise shows, some manual work may be necessary. There are combo boxes to select the column number for the name, protocol, and the parameters D, S, and F. Also the number base for parsing the numbers can be selected.

==== Exercise ====
Use the same csv file as in the previous exercise. Select the name column, and ''either'' the column for the hexadecimal command number (=F) (in which case 16 has number number base should be selected), or the column for the decimal command number (in which case 10 has number number base should be selected). Note the warnings in the console, stating that some lines did not make sense as IR signals.

[[Image:irscrutinizer_oppo_parametric.png]]

Press '''Import all''' to transfer the result to the '''Parametric Remote'''. In that pane, note first that there are a few ''junk'' entries, not corresponding to IR signal, so remove them by marking the line, press the right mouse button, and select '''Delete selected''' from the context menu. Since the protocol and the D are the same for all signals, the file did not put in on every line, which means that the import missed it, and it has to be entered manually. For this, the individual lines can be edited, however, there is a shortcut: From the context menu, select '''Advanced''' -> '''Set protocol...''' and enter the protocol name (here NEC1) in the popup. Similarly, select '''Advanced''' -> '''Select D (deviceno) ...''', and enter D (73).

Note: Unfortunately, there is a bug in version 1.1.2, affecting import of csv files using colon (:), TAB, and WHITESPACE. To avoid, use comma (,) or semicolon (;) instead.

= Exporting IR Signals =
IrScrutinizer does not have a "save" feature, because that would be of very limited use. Instead, there is the possibility to "export" in a number of different formats.

Next picture shows the '''Export''' pane.

[[Image:irscrutinizer_export.png]]

The combo box to the left selects the export format. There is a large number of different export formats implemented, and the user can even add his own by adding them to a configuration file.

Different export formats have different properties. There are some options (see the picture) that do not make sense on some export formats. They will be disabled when selecting certain protocols.

Some formats (Girr and Text) can contain several "representation" of the same IR signal. These are the checkboxes to the right of the combo box.

There are four "things" that can be exported: The signal on the '''Scrutinize signal''' pane (the button '''Export signal'''), the '''Parametric remote''' pane within '''Scrutinize remote''' ('''Export param. remote'''), the '''Raw remote''' pane within '''Scrutinize remote''' ('''Export raw remote'''), and the signal(s) from the '''Generate''' pane ('''Export generated''').

The lower part of the pane allows to set a few format-specific parameters.

Next we give some comments on some of the export formats.

;[https://www.harctoolbox.org/Girr.html Girr]
: This is the native format of IrScrutinizer. It is an XML file that can contain different content, as selected by the checkboxes.
;Text
: Exports the IR signals in the form of normal ASCII files, not really suitable for anything but forums and such.
;LIRC
: Exports a set of IR signals as a Lirc configuration file.
;Wave
: Exports a single IR signal as a wave file.
;Pronto Classic
: Generates a Pronto Classic CCF file, complete with one button for every IR signal. (This can be considered to be a modern replacement of the IrPanels/CCF Panels program.)
;Spreadsheet
: Generates a [https://www.harctoolbox.org/Glossary.html#CSV CVS file], fields separated by TABs. This is suitable for importing in a spreadsheet program.
;RemoteMaster
:Generates a rudimentary RemoteMaster device upgrade that can be imported in RemoteMaster, see [http://www.hifi-remote.com/wiki/index.php?title=Importing_Foreign_IR_Remotes_in_RemoteMaster this guide].
;Arduino *
:Generates Arduino C++ code for generating and sending IR signals, using one of the popular Arduino libraries.
;AnyMote, irplus
:Generates files for the mentioned smartphone remote apps.

= Configuring Hardware for Capturing =
To capture real IR signals, some sort of hardware is needed. Version 1.4 of IrScrutinizer supports [https://www.globalcache.com Global Caché’] units with learner, Kevin Timmerman's [http://www.compendiumarcana.com/irwidget/ IrWidget], Dangerous Prototype's [http://dangerousprototypes.com/docs/USB_Infrared_Toy USB IrToy], Arduinos with a connected non-demodulating sensor (see for example [https://www.harctoolbox.org/arduino_nano.html this]), the [https://www.commandfusion.com/hardware/irlearner CommandFusion learner], (Linux only) Lirc mode 2 devices, and (Linux only) <code>/dev/lirc</code> devices. All but <code>/dev/lirc</code> and the Lirc mode2 devices are capable of determining the modulation frequency of the captured signal.

The splash image, also shown on top of this page, shows, from left to right, a Global Caché iTach Flex, an IrToy, and an Arduino Nano.

Many devices are capable both of sending and capturing. These in general have to be configured and opened on the "Sending hw" pane,
but for capturing still selected on the "Capturing hw" pane.

In order to keep the tutorial nature, not all devices are described.

== USB IrToy ==
This is configured at the [[#USB IrToy Sending|Sending hw]] pane.

== IrWidget ==
Connect the device to the computer and determine the device that the operating system assigns to it. For this, on Windows, use the device manager to find it. It should have a name like <code>COM8:</code> or such. (If not found, install the driver.) Using Linux, it is in general assigned a name like <code>/dev/ttyUSB0</code>. Now go to the IrWidget sub pane within the Capturing hw pane. Select the appropriate serial port, the one observed in the device manager or in the /dev directory. Press Open. See picture:

[[Image:irscrutinizer_irwidget.png]]

If Windows needs a driver, install the [https://www.ftdichip.com/Drivers/VCP.htm FTDI Virtual comm-port driver].

As the IrWidget firmware does not contain a version, the Version field is empty, as can be seen from the picture.

== Arduino ==

Configured at the [[#arduino sending|sending page]].

== Global Caché ==
Global Caché's with a build in learner, like the new [https://www.globalcache.com/files/docs/ds_Flex_print.pdf iTach Flex] work well with IrScrutinizer. Devices on the local network, having firmware from the last few years, are detected automatically by IrScrutinizer. Just select the desired one from the combo box.

Whatever hardware has been selected and opened, it can/should be tested directly on the pane. Press the '''Test button''' and fire an IR signal at the sensor within the next few seconds. It should now print the timing of the captured signal, the measured modulation frequency, and possible decodes. See the picture:

[[Image:irscrutinizer_irtoy_test.png]]

Please note that the Test facility is just what the name says, a testing facility -- productive captures should be make on the '''Scrutinize signal''' or '''Scrutinize remote''' panes.

= Configuring Hardware for Sending =
To keep the tutorial nature, we only describe a few of the devices. Configuration of the other devices are in general similar.

==USB IrToy==
Connect the device to the computer and determine the device that the operating system assigns to it. For this, on Windows, use the device manager to find it. It should have a name like <code>COM8:</code> or such. (If not found, install the [https://code.google.com/p/dangerous-prototypes-open-hardware/downloads/detail?name=USBIRToy.package.v22.zip driver].) Using Linux, it is in general assigned a name like <code>/dev/ttyACM0</code>. Now go to the '''IrToy''' sub pane within the '''Capturing hw''' pane. Select the appropriate serial port, the one observed in the device manager or in the <code>/dev</code> directory. Press '''Open'''. The version of the firmware in the IrToy should now be reported in the '''Ver:''' text field, here "V222". (This serves as a test that the communication is working.) See picture:

[[Image:irscrutinizer_irtoy.png]]

==Arduino==
A suitably equipped Arduino (for example [https://www.harctoolbox.org/arduino_nano.html this project]) makes an excellent IR capturer. Usage is analogous to the IrToy. If Windows needs a particular driver, visit the [https://www.arduino.cc Arduino home page].

This is configured as a [https://www.harctoolbox.org/Girs.html Girs] client. A Girs client can be configure using USB Serial or using Ethernet with TCP sockets. In this tutorial, we only cover the first possibility. For this, the device is identified as above, selected, and opened. See screenshot.

[[Image:irscrutinizer_girs_client.png]]

= Feedback =
IrScrutinizer is actively developed. ''Your'' feedback and suggestions for improvements is actively solicited. Suggestions and bug report can, e.g., be left in the forum here, or raised as [https://github.com/bengtmartensson/harctoolboxbundle/issues issues at Github] (requires a Github account). Apart from this forum, I participate on [https://www.remotecentral.com/cgi-bin/mboard/forums.cgi RemoteCentral forum] (in both cases with the user name [http://en.wikipedia.org/wiki/Spaceballs#Heroes Barf]) and on the [https://lists.sourceforge.net/lists/listinfo/lirc-list Lirc mailing list].

For feedback on this page, as well as improvements, either use the forum, or register on this Wiki.

== Sources ==
The sources to the program are maintained at [https://github.com/bengtmartensson/IrScrutinizer Github]. Contributions (Forks and push requests) are welcome.

IrScrutinizer Guide

2025-10-11T12:13:38Z

Barf: Don't call RemoteCentral links defunct any longer.

[[Image:irscrutinizer_splash.png]]

= Introduction =
IrScrutinizer is a powerful program for capturing, generating, analyzing, importing, and exporting of infrared (IR) signals. For capturing and sending IR signals several different hardware sensors and senders are supported. IR Signals can be imported not only by capturing from one of the supported hardware sensors (among others: IrWidget, Global Caché, and Arduino), but also from a number of different file formats (among others: LIRC, Wave, Pronto Classic and professional, RMDU (partially), and different text based formats; not only from files, but also from the clipboard, from URLs, and from file hierarchies), as well as the Internet IR Databases by Global Caché and by IRDB. Imported signals can be decoded, analyzed, edited, and plotted. A collection of IR signal can thus be assembled and edited, and finally exported in one of the many supported formats. In addition, the program contains the powerful IrpTransmogrifier IR-renderer and -decoder, which means that almost all IR protocols known to the Internet community (over 100) can be generated as well as decoded.

This document is not a manual for IrScrutinizer. (The full manual is found [https://www.harctoolbox.org/IrScrutinizer here], which should be read for questions not addressed here). Instead, it is a gentle guide to a program that can possibly look somewhat overwhelming at the first look. It focuses on what tasks can be achieved, and on the general "why", instead of a detailed description of all features.

As a tutorial, this document is not updated as often as the program, or even as the documentation. So the current program may have slightly different features and slightly different look than shown here.

== Prerequisites ==
For the sequel, a basic understanding of IR signals is required. My favorite introduction is [http://www.sbprojects.net/knowledge/ir/index.php the one by San Bergmans]. My [https://www.harctoolbox.org/Glossary.html glossary] (also included under the Help menu of the program) may come in handy. In particular, there is a concise description of the [https://www.harctoolbox.org/Glossary.html#ProntoSemantics semantics of the Prono hex format].

== History ==
In 2011, I wrote an IR signal "engine" implementing the [[IRP Notation]], called [https://www.harctoolbox.org/IrpMaster.html IrpMaster]. It was invoked as a command line program. Later that year, a program called [https://www.harctoolbox.org/IrMaster.html IrMaster] was released, which among other things constitutes a user friendly GUI front end to IrpMaster. The first versions of the present program, IrScrutinizer, was also based on IrpMaster, and adds functionality from IrMaster, in particular the possibility to collect IR signals, a vastly improved import and export facility, and edit collections of IR commands. (IrScrutizer almost completely replaces IrMaster, which is no longer maintained.) In 2019, IrpMaster, and the decoding engine DecodeIR, was replaced by IrpTransmogrifier, which is an even more developed rendering and decoding engine.

== Copyright ==
The program is copyright(c) by Bengt Martensson, and is Free Software published under the [https://www.gnu.org/licenses/gpl.html GPL3 license]. My copyright does not extend to the embedded "components", which are published under similar, but compatible licenses. Details are given in the [https://www.harctoolbox.org/IrScrutinizer.html#Copyright+and+License manual].

= Concepts =
For anyone familiar with the IR signals, the program is believed to be intuitive and easy to use. Almost all user interface elements have tool-help texts. Different panes have their own pop-up help. Many panes have a context menu, bound to the right mouse button.

Next picture shows the program immediately after startup.

[[Image:irscrutinizer_startup.png]]

In the upper row, there are six pull-down menus, named '''File, Edit, Actions, Options, Tools''', and '''Help'''. Their usage is believed to be mainly self explanatory.

Options to the program are in general found in the '''Options''' menu, or its subordinate menus. Some parameters for particular export formats are found in the sub-panes of the '''Export''' pane. Also the hardware configuring panes contain user parameters.

The main window is composed of seven sub panes denoted by '''Scrutinize signal''' (for processing single signal), '''Scrutinize remote''' (for collecting several signals to one "remote"), '''Generate''' (generates IR signal from protocol name and parameters), '''Import''', '''Export''', '''Capturing Hardware''', and '''Sending Hardware''' respectively.

= Installation =
IrScrutinizer takes great pride of being a portable program, and runs on Windows, Linux (including RaspberryPi), and MacOS. For Windows and MacOS, native installation packages are available; for Windows it is the setup file *.exe, for Mac the zipped app *.MacOS.zip. Users of (most) 64-bit Linux-es can use the AppImage (*x86_64.AppImage) version. In all these cases, they come with its own Java installation, although the Windows version allows for using a previously installed Java. Others, and those who do not like preinstalled binaries, can install the generic binary package, or install from the sources directly.
(Files ending with md5, sha1, and sha512 are checksum files, and are not required for installation.)

Details are given [https://www.harctoolbox.org/IrScrutinizer.html#Installation in the manual]. Downloads of the currently latest released version are found [https://github.com/bengtmartensson/harctoolboxbundle/releases/latest here].

= Scrutinizing a single IR signal =
The '''Scrutinize signal''' pane is used to analyze a single IR signal. Press F9 to see a sample IR signal directly. The program will now look like this:
[[File:Irscrutinizer_F9.png]]

The upper sub-window shows the signal either as [https://www.harctoolbox.org/Glossary.html#CCF Pronto Hex] (the default) or as a number of timings in microseconds (selected by Options -> Output text format). Then there follows an output area for the results of the decode and (if selected through Options -> Invoke Analyzer) a computed IRP form, possibly together with some other identified parameters. The plot windows shows the signal, with the [https://www.harctoolbox.org/Glossary.html#ModulationFrequency modulation] removed. The [https://www.harctoolbox.org/Glossary.html#IrSignal Intro sequence] is shown red (if present), the repeat signal blue (if present), while the ending signal (only present in rare cases) is shown green.

Basically, the user enters something in the upper subwindow, or capturing something with hardware. The program will then analyze the signal. Things that can be done on this pane:
* If suitable capturing hardware is connected and opened, pressing '''Capture''' will capture one IR signal form the hardware, and scrutinize it.
* Again assuming suitable hardware opened, pressing '''Capt. (cont)''' will start a capturing thread, capturing signals over and over again, without saving, until the button is pressed again.
* The user can enter something in the upper window, often by pasting from the clipboard, or hand modifying already present content. This requires pressing the '''Scrutinize''' button.
* If suitable sending hardware is connected and opened, pressing the '''Transmit''' button will transmit the signal with the selected hardware.
* If a suitable export format is selected, the '''Export''' button will export the signal in the export format selected.

Different formats are accepted in the input window: Pronto Hex, Timing list with or without signs, as well as the Global Cache irsend formats are currently understood.

The plotter can be zoomed (of course, only on the horizontal scale) by pressing the left mouse button at the desired start point, and dragging to the desired new ending point. To reset, use "Reset plot" from the context menu or the Actions menu. For comparison with other signals, the plot can be "torn off" by Action -> Clone plot menu entry.

There are a number of other possibilities offered by the top menus, and the context menus in the different sub-windows.

=== Excercise 1. ===
Find an "arbitrary" IR signal in the JP1 or RemoteCentral forums, for example [http://www.remotecentral.com/cgi-bin/mboard/rc-discrete/thread.cgi?7443 this one]. Copy the signal to the clipboard, and paste it, and scrutinize it (the button '''Paste & Scr.''' makes it in one click).

=== Excercise 2. ===
Make sure that Pronto Hex is selected as output text format. (Options -> Output text format). Press F9, which will show a NEC1 signal. Using the keyboard, remove the last four hexadecimal numbers ("015B 0057 0016 0E6C"). Press '''Scrutinize'''. This will produce an error message, since the signal length is now inconsistent with the header. So we fix that: Change the forth number from 0002 to 0000. Pressing '''Scrutinize''' again shows that the signal now decodes, but instead of "NEC1" as [https://www.harctoolbox.org/Glossary.html#IrProtocol protocol], we now have "NEC". There is strictly speaking no protocol named NEC; this is the decoder's way of saying that it has identified a NEC-type signal, but the repeat part is missing.

= Scrutinizing a remote (several IR signals) =
Often, we would like to consider a whole set of IR signals, for example, all that can be used for controlling a piece of consumer electronics. The word ''remote'' will be used in the sequel to denote such a set of IR signals, having something in common.

IrScrutinizer, as well as most other IR signal programs, can consider an IR signal either as a [https://www.harctoolbox.org/Glossary.html#IrProtocol Protocol] and parameteres (''parameteric'') or as (one, two, or three) sequences of durations, denoting on- and off-periods, a [https://www.harctoolbox.org/Glossary.html#RawIrSignal raw signal]. Whenever possible, the parametric form should be preferred.

The '''Scrutinize remote''' pane, has two sub-panes: '''Parametric Remote''' and '''Raw Remote'''. This tutorial will only consider the parametric remote sub-pane.

The pane consists of a table, like in a spreadsheet program. There are columns for protocol name, the more common protocol parameters, name, etc. It is used for capturing a number of signals using connected hardware, or to edit/inspect a previously captured, or imported, remote. See picture.

[[File:irscrutinizer_parametric_remote.png]]

Just like in a program like Excel, the columns can be resized, edited (using the text area on top of the table), and sorted from an arbitrary column (requires enabling the sorter in the context menu). The colums can also be reordered by dragging them with the mouse.

== Capturing in Parametric Remote ==
First of all, setup and test the hardware is to be used. Make sure that the capturing hardware has been opened. To capture parametric signals, the user just presses '''Capture''', which now stays active, until pressed again. IrScrutinizer will now use a separate thread for collecting the captures, entered into the table. The user can intermix captures and entering of names with the keyboard in any order he or she wishes.

The table can be edited the keyboard. New signals can be entered, having any recognized protocol name as protocol (case not being recognized). There are also a number of interesting things that can be done with the context menu.

When finished, the table is [[#Exporting_IR_Signals | exported]] in a suitable file format. Alternatively, the table can be copied to the clipboard, for being pasted into a spreadsheet program, or the [[Remote_Master_Manual#Functions_Tab|Remote Master functions tab]].

= Generating IR Signals =
IrScrutinizer can generate well over 100 different IR protocols. For this, select the desired protocol from the combo box. Different protocol require different parameters. The four most common are D ("device"), S ("subdevice"), F ("function"), and T ("toggle"). After having selected protocol, the fields corresponding to parameters not used by the current protocols are disabled. Also, some protocols need other parameters. In this case, these are entered in the '''Additional parameters''' text field, using the format like '''X=0 Y=42'''. Note that there are no spaces around the equals sign, however, space between the assignments.

The signal is generated by pressing '''Generate'''. See the picture.

[[Image:irscrutinizer_generate.png]]

The thus generated signal can be [[#Exporting_IR_Signals | exported]], or transmitted with suitable connected sending hardware. The three buttons in the lower row transfers the signal to the '''Scrutinize signal''' pane, or adds it to the '''Parametric Remote''' or '''Raw Remote''' panes.

Some versions of the program use the word "render" instead of "generate".

It is also possible to extend IrScrutinizer with new protocols. This is done by adding protocols to the protocol data base, the file IrpProtocols.xml, but is well outside of the scope of this introductory guide.

= Importing IR Signals =
The Internet is a vast resource for IR signals for different devices. Unfortunately, there is no universally accepted exchange format for a "remote", i.e. a collection of IR signals with names. For this reason, IrScrutinizer implements a number of different importers. These serves to fill the table '''Parametric Remote''' or '''Raw Remote''', where the imports can be further edited. That table does on clear on subsequent imports, so it can be used to merge signals from different sources. Data bases, local files (even zip-ped), directory hierarchies, and URLs, and even the clipboard can be imported.

In this introductory guide, we do not describe all the different importers. Usage of the not described importers is in general similar to the ones described.

== The IRDB Database ==
''This section is no longer correct -- replaced by RemoteLocator, and should be rewritten.''

[http://www.irdb.tk IRDB] is "one of the largest crowd-sourced, manufacturer-independent databases of infrared remote control codes on the web, and aspiring to become the most comprehensive and most accurate one."

To use, select the '''IRDB''' sub-pane within the '''Import''' pane. First, select "Select me to load" in the '''Manufacturer''' combo box, in order to load the list of known manufacturers. Select the desired one. This loads the list of '''Device Type''''s known for that manufacturer. The '''Protocol & Parameters''' combo box is now loaded by the known "devices". Select one, and press the '''Load''' button. This downloads the information from the data base and pushes it to the tree in the left middle part. Alternatively, the button '''Load all''' will load all of of the entries under '''Protocol & Parameters'''. The next picture shows IrScrutinizer after having '''Load all''' Sony video projectors.

[[File:irscrutinizer_irdb_sony.png]]

(During import, IrScrutinizer detected some inconsistencies in the imported data, as indicated by the messages in the console.)

The import tree is organized like this: The top level note is always "Remotes". Its immediate children are the remotes in the import, and can be opened or closed by clicking on the symbol to the left of the folder symbol. (The picture shows the first remote closed, and the second remote opened.) The children of the remotes are the named IR signals. By hovering the mouse over one such, its protocol and parameters (if available) are displayed as tooltips. (See the picture, where "DYNAMIC" is selected.)

The signal can now be imported by pressing '''Import all''', which transfers them to the '''Parametric Remote''' sub-pane in '''Scrutinizer remote''' pane. Alternatively, a subset can be selected with mouse clicks, (Shift-left and Ctrl-left works as espected for selecting multiple signals) and imported by '''Import selection'''. The button '''Import signal''' transfers the (single) selected signal to the '''Scrutinizer signal''' pane. If suitable sending hardware is opened, a selected signal can be transmitted directly by the '''Transmit selected''' button.

== Importing Lirc files ==
Both inside and outside of the Lirc community, there is often a need either to analyze or to extract the information in a Lirc configuration file. IrScrutinizer is very well fit for this task, as it contains a great deal of the Lirc code (translated to Java). The [https://sourceforge.net/p/lirc-remotes/code/ci/master/tree Lirc remotes data base] is also a considerable resource, to be considered when hunting the Internet for IR codes.

To import a single Lirc file posted in a web page or in a mail, it is easiest to just copy it to the clipboard, got to the '''Lirc''' import pane, and click '''Load from clipbard'''. To load a local file, use the '''...'''-Button to navigate to the file, and press '''Load File/URL''' to perform the actual import. This can also be used import directories containing Lirc configuration files. (In this way, the whole Lirc remote data base can be imported, at least if sufficient memory is available. On my computer, it takes less than one minute.)

Often, the imported Lirc files contain problems of different types. During import, there may be warnings in the console. IrScrutinizer handles these problems gracefully, in general by just ignoring the entries that it could not make sense of.

The entire Lirc data base can be browsed [https://lirc-remotes.sourceforge.net/remotes-table.html here]. (Note that the remotes without "Timing" are usable only with specialized hardware, for example a certain notebook computer, and unusable for the rest of us.)

Assuming [https://git-scm.com/ Git] is installed as a command line program, the entire Lirc remote data base can be checked out to a local disc by a command like

<code>git clone git://git.code.sf.net/p/lirc-remotes/code lirc-remotes</code>

As the name of the text area and button suggests, also URLs, like <code>
https://sourceforge.net/p/lirc-remotes/code/ci/master/tree/remotes/yamaha/RX-V995.lircd.conf?format=raw</code>, can be directly imported by entering it into the '''File/URL''' area.

== Importing Pronto Classic (ccf) files ==
In particular on [http://files.remotecentral.com/pronto/index.html RemoteCentral], there is a huge number of [https://www.harctoolbox.org/Glossary.html#ccfFileFormat CCF Files] for the Philips Pronto Classic. They are not really a data base for IR signals, rather a complete configuration for the probably best remote control there was, around 15 years ago. IrScrutinizer only considers them for importing the contained IR signals.

When downloading files from e.g. RemoteCentral, these are often zipped. There is no need to unzip these; IrScrutinizer will open the zip files directly.

When importing a CCF file, the contained devices (in the Pronto sense) will be mapped to different "remotes" in the import tree. Sub-pages of a device will all be merged together.

Unfortunately, there are often small problems within the imported files, in particular invalid IR signals. These problems are listed to the console. IrScrutinizer handles these problems gracefully, in general by just ignoring the entries that it could not make sense of.

[http://files.remotecentral.com/view/3491-7440-1/aaron_guenthers_pronto_ccf.html Here] is a file to exercise on, it contains several devices, there are sensible IR signals, as well as signals not recognized, likely bad learns.

== Importing RemoteMaster files ==
''This section is obsolete, and should be rewritten.''

The [http://www.hifi-remote.com/forums/index.php JP1 forum] is also a vast source of IR signals, see [http://www.hifi-remote.com/forums/dload.php?action=category&cat_id=4 the file section] and [http://www.hifi-remote.com/jp1/lookup/ the lookup tool]. Their files are in general "Device upgrades" configuration files for different remotes manufactured by UEI (Universal Electronics), meant to be maintained by the program [http://www.hifi-remote.com/wiki/index.php?title=Remote_Master_Manual RemoteMaster]. This means that the "protocol" used in a device upgrade can sometimes be hard to understand. The "protocol" in a device upgrade does not quite correspond to the meaning of "protocol" in IrScrutinizer, rather it is a an "executor", either built-in in the UEI remote, or a custom protocol, which is a small machine code chunk contained in the device upgrade, particular to the very microprocessor of the remote. In these cases, either an instance of that processor, or an emulator for it, would be required to faithfully render the signal. Fortunately, this is not always the case, and the contained protocols can be mapped onto the known IR protocols easily. Thus, the RemoteMaster import facility is by necessity limited and incomplete.

=== Excercise ===
[http://www.hifi-remote.com/forums/dload.php?action=file&file_id=6721 Here] is a file to try, that imports fine. (The "Download" button is only visible for logged-in users.)

== Importing Wave files ==
IrScrutinizer can import IR signal packed in wave files (*.wav). The details are outside of the scope of an introduction. (Leave "Half carrier frequency" selected, unless you know what you are doing.)

=== Excercise ===
Try importing [http://www.hifi-remote.com/forums/dload.php?action=file&file_id=12096 this file]. Note that some information on the content of the file is written to the console.

== Importing "text" files ==
In the absence of a universally accepted exchange format for remotes (in the sense of sets of named IR signals) -- a gap that the format [https://www.harctoolbox.org/Girr.html Girr] is trying to fill -- IR signals are often published in different text formats, or as spreadsheets. IrScrutinizer has quite some facilities for importing that sort of files. It can (at least not presently) not open Excel <code>.xsl</code>-files directly. Instead a spreadsheet program like Excel, OpenOffice/Libreoffice or Gnumeric can export (a subset of) its data as comma (or tab) separated values, a text file where the fields are divided by a certain character, in general the comma (,), the semicolon (;), the TAB character (ASCII 9), or general whitespace. We will cover the three sub-panes of the '''Text''' importer pane next.

=== Raw, line-based ===
"Raw, line-based" means that raw codes (e.g. in the Pronto Hex format) are found on lines by itself, preceded by a name, also on a line by itself. Many postings on RemoteCentral and JP1 follow this scheme. IrScrutinizer finds the "payload" (IR signal in any of the recognized formats, like Pronto Hex (also short format), UEI learned, timing lists, sendir) among other content, and imports it.

==== Exercise ====
Consider [http://www.remotecentral.com/cgi-bin/mboard/rc-discrete/thread.cgi?7222 this thread on RemoteCentral]. Copy the whole thread to the clipboard (Ctrl-A, Ctrl-C). Go to the '''Raw, line-based''' pane, and press '''Load from clipboard'''. There should now be 24 properly decoded signals in the tree view.

=== Raw ===
This is for importing raw formats in a spreadsheet like format (comma separate values etc). To use, select the character separating the fields as "Field separator". Select the column containing the name of the IR Signal/command, and the column containing the raw data.

==== Excercise ====
Download this [http://download.oppodigital.com/BDP103/BDP-103_BDP-105_Remote_Code_v1.1.xls Excel file] containing the IR commands for the Oppo 103/105 Bluray player. Using a spreadsheet program (e.g. Excel or LibreOffice), convert the first worksheet of it to a CSV file using any suitable field separator (e.g. TAB). Using the '''Raw''' pane, select the column containing the name, and the column containing the Pronto hex data, as well as the field separator. Import by pressing the '''Load File/URL''' button. There should now be 57 signals in the tree view, all NEC1 with D=73, varying F.

=== Parametric ===
This pane imports IR signals given as protocol and parameters. As the excercise shows, some manual work may be necessary. There are combo boxes to select the column number for the name, protocol, and the parameters D, S, and F. Also the number base for parsing the numbers can be selected.

==== Exercise ====
Use the same csv file as in the previous exercise. Select the name column, and ''either'' the column for the hexadecimal command number (=F) (in which case 16 has number number base should be selected), or the column for the decimal command number (in which case 10 has number number base should be selected). Note the warnings in the console, stating that some lines did not make sense as IR signals.

[[Image:irscrutinizer_oppo_parametric.png]]

Press '''Import all''' to transfer the result to the '''Parametric Remote'''. In that pane, note first that there are a few ''junk'' entries, not corresponding to IR signal, so remove them by marking the line, press the right mouse button, and select '''Delete selected''' from the context menu. Since the protocol and the D are the same for all signals, the file did not put in on every line, which means that the import missed it, and it has to be entered manually. For this, the individual lines can be edited, however, there is a shortcut: From the context menu, select '''Advanced''' -> '''Set protocol...''' and enter the protocol name (here NEC1) in the popup. Similarly, select '''Advanced''' -> '''Select D (deviceno) ...''', and enter D (73).

Note: Unfortunately, there is a bug in version 1.1.2, affecting import of csv files using colon (:), TAB, and WHITESPACE. To avoid, use comma (,) or semicolon (;) instead.

= Exporting IR Signals =
IrScrutinizer does not have a "save" feature, because that would be of very limited use. Instead, there is the possibility to "export" in a number of different formats.

Next picture shows the '''Export''' pane.

[[Image:irscrutinizer_export.png]]

The combo box to the left selects the export format. There is a large number of different export formats implemented, and the user can even add his own by adding them to a configuration file.

Different export formats have different properties. There are some options (see the picture) that do not make sense on some export formats. They will be disabled when selecting certain protocols.

Some formats (Girr and Text) can contain several "representation" of the same IR signal. These are the checkboxes to the right of the combo box.

There are four "things" that can be exported: The signal on the '''Scrutinize signal''' pane (the button '''Export signal'''), the '''Parametric remote''' pane within '''Scrutinize remote''' ('''Export param. remote'''), the '''Raw remote''' pane within '''Scrutinize remote''' ('''Export raw remote'''), and the signal(s) from the '''Generate''' pane ('''Export generated''').

The lower part of the pane allows to set a few format-specific parameters.

Next we give some comments on some of the export formats.

;[https://www.harctoolbox.org/Girr.html Girr]
: This is the native format of IrScrutinizer. It is an XML file that can contain different content, as selected by the checkboxes.
;Text
: Exports the IR signals in the form of normal ASCII files, not really suitable for anything but forums and such.
;LIRC
: Exports a set of IR signals as a Lirc configuration file.
;Wave
: Exports a single IR signal as a wave file.
;Pronto Classic
: Generates a Pronto Classic CCF file, complete with one button for every IR signal. (This can be considered to be a modern replacement of the IrPanels/CCF Panels program.)
;Spreadsheet
: Generates a [https://www.harctoolbox.org/Glossary.html#CSV CVS file], fields separated by TABs. This is suitable for importing in a spreadsheet program.
;RemoteMaster
:Generates a rudimentary RemoteMaster device upgrade that can be imported in RemoteMaster, see [http://www.hifi-remote.com/wiki/index.php?title=Importing_Foreign_IR_Remotes_in_RemoteMaster this guide].
;Arduino *
:Generates Arduino C++ code for generating and sending IR signals, using one of the popular Arduino libraries.
;AnyMote, irplus
:Generates files for the mentioned smartphone remote apps.

= Configuring Hardware for Capturing =
To capture real IR signals, some sort of hardware is needed. Version 1.4 of IrScrutinizer supports [https://www.globalcache.com Global Caché’] units with learner, Kevin Timmerman's [http://www.compendiumarcana.com/irwidget/ IrWidget], Dangerous Prototype's [http://dangerousprototypes.com/docs/USB_Infrared_Toy USB IrToy], Arduinos with a connected non-demodulating sensor (see for example [https://www.harctoolbox.org/arduino_nano.html this]), the [https://www.commandfusion.com/hardware/irlearner CommandFusion learner], (Linux only) Lirc mode 2 devices, and (Linux only) <code>/dev/lirc</code> devices. All but <code>/dev/lirc</code> and the Lirc mode2 devices are capable of determining the modulation frequency of the captured signal.

The splash image, also shown on top of this page, shows, from left to right, a Global Caché iTach Flex, an IrToy, and an Arduino Nano.

Many devices are capable both of sending and capturing. These in general have to be configured and opened on the "Sending hw" pane,
but for capturing still selected on the "Capturing hw" pane.

In order to keep the tutorial nature, not all devices are described.

== USB IrToy ==
This is configured at the [[#USB IrToy Sending|Sending hw]] pane.

== IrWidget ==
Connect the device to the computer and determine the device that the operating system assigns to it. For this, on Windows, use the device manager to find it. It should have a name like <code>COM8:</code> or such. (If not found, install the driver.) Using Linux, it is in general assigned a name like <code>/dev/ttyUSB0</code>. Now go to the IrWidget sub pane within the Capturing hw pane. Select the appropriate serial port, the one observed in the device manager or in the /dev directory. Press Open. See picture:

[[Image:irscrutinizer_irwidget.png]]

If Windows needs a driver, install the [https://www.ftdichip.com/Drivers/VCP.htm FTDI Virtual comm-port driver].

As the IrWidget firmware does not contain a version, the Version field is empty, as can be seen from the picture.

== Arduino ==

Configured at the [[#arduino sending|sending page]].

== Global Caché ==
Global Caché's with a build in learner, like the new [https://www.globalcache.com/files/docs/ds_Flex_print.pdf iTach Flex] work well with IrScrutinizer. Devices on the local network, having firmware from the last few years, are detected automatically by IrScrutinizer. Just select the desired one from the combo box.

Whatever hardware has been selected and opened, it can/should be tested directly on the pane. Press the '''Test button''' and fire an IR signal at the sensor within the next few seconds. It should now print the timing of the captured signal, the measured modulation frequency, and possible decodes. See the picture:

[[Image:irscrutinizer_irtoy_test.png]]

Please note that the Test facility is just what the name says, a testing facility -- productive captures should be make on the '''Scrutinize signal''' or '''Scrutinize remote''' panes.

= Configuring Hardware for Sending =
To keep the tutorial nature, we only describe a few of the devices. Configuration of the other devices are in general similar.

==USB IrToy==
Connect the device to the computer and determine the device that the operating system assigns to it. For this, on Windows, use the device manager to find it. It should have a name like <code>COM8:</code> or such. (If not found, install the [https://code.google.com/p/dangerous-prototypes-open-hardware/downloads/detail?name=USBIRToy.package.v22.zip driver].) Using Linux, it is in general assigned a name like <code>/dev/ttyACM0</code>. Now go to the '''IrToy''' sub pane within the '''Capturing hw''' pane. Select the appropriate serial port, the one observed in the device manager or in the <code>/dev</code> directory. Press '''Open'''. The version of the firmware in the IrToy should now be reported in the '''Ver:''' text field, here "V222". (This serves as a test that the communication is working.) See picture:

[[Image:irscrutinizer_irtoy.png]]

==Arduino==
A suitably equipped Arduino (for example [https://www.harctoolbox.org/arduino_nano.html this project]) makes an excellent IR capturer. Usage is analogous to the IrToy. If Windows needs a particular driver, visit the [https://www.arduino.cc Arduino home page].

This is configured as a [https://www.harctoolbox.org/Girs.html Girs] client. A Girs client can be configure using USB Serial or using Ethernet with TCP sockets. In this tutorial, we only cover the first possibility. For this, the device is identified as above, selected, and opened. See screenshot.

[[Image:irscrutinizer_girs_client.png]]

= Feedback =
IrScrutinizer is actively developed. ''Your'' feedback and suggestions for improvements is actively solicited. Suggestions and bug report can, e.g., be left in the forum here, or raised as [https://github.com/bengtmartensson/harctoolboxbundle/issues issues at Github] (requires a Github account). Apart from this forum, I participate on [http://www.remotecentral.com/cgi-bin/mboard/forums.cgi RemoteCentral forum] (in both cases with the user name [http://en.wikipedia.org/wiki/Spaceballs#Heroes Barf]) and on the [https://lists.sourceforge.net/lists/listinfo/lirc-list Lirc mailing list].

For feedback on this page, as well as improvements, either use the forum, or register on this Wiki.

== Sources ==
The sources to the program are maintained at [https://github.com/bengtmartensson/IrScrutinizer Github]. Contributions (Forks and push requests) are welcome.

Importing Foreign IR Remotes in RemoteMaster

2025-10-11T12:03:53Z

Barf: JP1 file locations changed to Github.

= Ultra-short version =

* Perform an "Girr" export from IrScrutinizer to a file,
* Open the above created file in RemoteMaster. Perform 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 [https://wiki.harctoolbox.org/index.php?title=Importing_Foreign_IR_Remotes_in_RemoteMaster&oldid=561 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 [http://harctoolbox.org/IR-resources.html 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
[https://github.com/hifiremote/deviceupgrades/ JP1 device update repository] (see also
[https://github.com/hifiremote/deviceupgrades/raw/refs/heads/main/jp1-master.xls the master list] and
[http://www.getzweb.net/jp1/ 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.

= Solution =

The [https://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 [[IrScrutinizer_Guide | 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.

= 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 [[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:

[[Image:Screenshot%20from%202022-05-14%2022-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.

[[Image:Screenshot%20from%202022-05-14%2021-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.

[[Image:Screenshot%20from%202022-05-14%2021-15-25.png]]

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

[[Image:rm_opening_file.png]]

Next screenshot shows RMDU after the import:

[[Image:Screenshot%20from%202022-05-14%2021-32-52.png]]

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

[[Image:Screenshot%20from%202022-05-14%2021-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.

= Remarks =

== Import ict files from IrScope ==

RMDU can also import ("open") ict files from the program [[IR_Scope_and_IR_Widget_User's_Guide|IrScope]].

= 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.

Main Page

2025-10-01T16:04:11Z

Barf: /* Forums */

Welcome to the JP1 community Wiki site. A collaborative website relative to the JP1 community to which anyone can contribute!

Anyone can create an account, and edit or add pages. The user administration is completely autonomous; you cannot log in with a user-id from another system.

==JP1 Guides==
*[[JP1_Introduction|Introduction to JP1]]
*[[The History of the JP1 Project]]
*[[JP1 - Just How Easy Is It?]]
*[[The WHAT and WHY of JP1]]
*[[Creating A Better Upgrade]]
*[[JP1 Cables]]
*[[Building the Arduino Interface for older remotes]]
*[[Hacking JP1 Remotes]]
*[[Extenders (an FAQ)]]
*[[Infrared Signals]]
*[[How to use RIDgen]]
*[[IrScrutinizer Guide]]
*[[ToadTog]]
*[[Getting started with Xsight and Nevo]]
*[[Xsight_Disassembly]]
*[[Importing Foreign IR Remotes in RemoteMaster]]
*[[Using URC6440 and OARUSB04G Remotes with Linux]]

==Manuals==
*[[Manuals|Remote Manuals]]
*[[Remote Master Manual]] (not complete)
*[[IR Help]]
*[[Protocol Builder]]
*[[IR Scope and IR Widget User's Guide]]
*[[DecodeIR]]
*[[AIRWidget and IRScope Operating Instructions]]
*[[The 3660 family|The 3660 family of remotes]]
*[[INT-422|Programming an INT-422-4 Remote]]
*[[WAV FILES]]

==General Remote Guides==
*[[Manual Programming - 9xx Commands]]
*[[Manual Programming - Sky Remotes]]
*[[Master Reset Instructions]]
*[[Modem Upgrade Procedure]]
*[[The Correct Learning Procedure]]
*[[RemoteChart]]

==Website Archives==
The following are official websites that are no longer active, that have been archived here at hifi-remote.com.
*[http://www.hifi-remote.com/radioshack/ Radio Shack remotes page]
*[http://www.hifi-remote.com/rcinfo/ Radio Shack's www.rcinfo.com site]
*[http://www.hifi-remote.com/ofaold/ One For All backup #1]
*[http://www.hifi-remote.com/ofausa/ One For All backup #2]
*[http://www.hifi-remote.com/ofa-int/ One For All International]
*[http://www.hifi-remote.com/urc/ UEI's cable remotes page]
*[http://www.hifi-remote.com/hag/ Hudson Access Group's OFA page]

The following are user-maintained sites that are no longer available.
*[http://www.hifi-remote.com/wasser/ John Wasser's old OFA site]
*[http://www.hifi-remote.com/ziggr/ Zig's Amazing IR Remote Control Page]
*[http://www.hifi-remote.com/huras/ Dave Huras's X10 and OFA Page]
*[http://www.hifi-remote.com/sony/ Rob Humphrey's Sony codes page]

==Slingbox==
*[[How to Install a Custom Remote onto the Slingbox]]
*[[Customising the Remote Image on your Slingplayer]]
*[[How to Create Custom Remote Controls and use them on your Slingbox]]
*[http://www.hifi-remote.com/forums/viewforum.php?f=19 Slingbox forum] (presently not operational)
*[https://github.com/hifiremote/Slingbox Slingbox files]

==Resources==
*[https://sourceforge.net/projects/controlremote/ Remote Master Repository]
*[https://www.oracle.com/java/technologies/downloads/ Java Runtime Download (for Remote Master)]
*[[IRP Notation]]
*[[DecodeIR]]
*[[Working With Pronto Hex]]
*[[JP1 versus Harmony]]
*[[Technical Documents]]
*[[Glossary]]
*[http://www.hifi-remote.com/forums JP1 Forums] (defunct)
*[http://www.hifi-remote.com/forums/dload.php JP1 Files] (defunct)
*[http://www.hifi-remote.com/jp1/lookup JP1 Lookup Tool]
*[https://www.youtube.com/watch?v=ubrq9Pr3Y1Y&list=PLXmyroJbN9CAxc6vADS4iiXQT3fp0c-Iq JP1 "How To" Videos]

==References==
''Presently all defunct.'' 
*[https://cdn.jsdelivr.net/gh/hifiremote/deviceupgrades@main/Home%20Automation/Lutron-Master-List.xls Lutron Master List]
*[http://www.hifi-remote.com/forums/dload.php?action=file&file_id=9545 Onkyo Master List]
*[http://www.hifi-remote.com/forums/dload.php?action=file&file_id=508 Pioneer Master List]
*[http://www.hifi-remote.com/forums/dload.php?action=file&file_id=383 Sanyo Projector Master List]
*[http://www.hifi-remote.com/sony/ Sony Master List]
*[http://www.hifi-remote.com/forums/dload.php?action=file&file_id=9582 Yamaha Master List]

==Forums==
*[http://www.hifi-remote.com/forums Old JP1 Forum](now defunct) [https://web.archive.org/web/20250608060913/http://www.hifi-remote.com/forums/ Snapshot from 2025-06-08]
*[https://www.remotecentral.com/forums RemoteCentral] (now defunct) [https://web.archive.org/web/20241104235537/https://www.remotecentral.com/cgi-bin/mboard/forums.cgi Snapshot from 2024-11-04]
*[https://forum.harctoolbox.org Experimental]
*[https://www.avsforum.com/forums/remote-control-area.93 Remote Control Area subforum within AVS forums]

==Links==
*[https://github.com/hifiremote/ Hifiremote organization at Github]
**[https://github.com/hifiremote/deviceupgrades JP1 device upgrades for RemoteMaster or KeymapMaster]
**[https://github.com/hifiremote/Extenders Collection of extenders, from hifi-remote.com's file section]
**[https://github.com/hifiremote/Tools JP1 Tools and programs] (except Remotemaster that is hosted on SourceForge)
**[https://github.com/hifiremote/Slingbox Slingbox files from JP1]
**[https://github.com/hifiremote/ReplayTV Files and programs used to add IR blaster codes to ReplayTV units]
**[https://github.com/hifiremote/Protocols A variety of information relating to protocols]
**[https://github.com/hifiremote/Miscellaneous-JP1 The "Miscellaneous" files from the JP1 File section]
**[https://github.com/hifiremote/HelpFiles Help and "how to" docs, especially useful for beginners.]
*[https://www.harctoolbox.org Harctoolbox.org Harctoolbox]
*[https://github.com/bengtmartensson/IrScrutinizer IrScrutinizer Repository]

Main Page

2025-10-01T15:31:46Z

Barf: /* Forums */

Welcome to the JP1 community Wiki site. A collaborative website relative to the JP1 community to which anyone can contribute!

Anyone can create an account, and edit or add pages. The user administration is completely autonomous; you cannot log in with a user-id from another system.

==JP1 Guides==
*[[JP1_Introduction|Introduction to JP1]]
*[[The History of the JP1 Project]]
*[[JP1 - Just How Easy Is It?]]
*[[The WHAT and WHY of JP1]]
*[[Creating A Better Upgrade]]
*[[JP1 Cables]]
*[[Building the Arduino Interface for older remotes]]
*[[Hacking JP1 Remotes]]
*[[Extenders (an FAQ)]]
*[[Infrared Signals]]
*[[How to use RIDgen]]
*[[IrScrutinizer Guide]]
*[[ToadTog]]
*[[Getting started with Xsight and Nevo]]
*[[Xsight_Disassembly]]
*[[Importing Foreign IR Remotes in RemoteMaster]]
*[[Using URC6440 and OARUSB04G Remotes with Linux]]

==Manuals==
*[[Manuals|Remote Manuals]]
*[[Remote Master Manual]] (not complete)
*[[IR Help]]
*[[Protocol Builder]]
*[[IR Scope and IR Widget User's Guide]]
*[[DecodeIR]]
*[[AIRWidget and IRScope Operating Instructions]]
*[[The 3660 family|The 3660 family of remotes]]
*[[INT-422|Programming an INT-422-4 Remote]]
*[[WAV FILES]]

==General Remote Guides==
*[[Manual Programming - 9xx Commands]]
*[[Manual Programming - Sky Remotes]]
*[[Master Reset Instructions]]
*[[Modem Upgrade Procedure]]
*[[The Correct Learning Procedure]]
*[[RemoteChart]]

==Website Archives==
The following are official websites that are no longer active, that have been archived here at hifi-remote.com.
*[http://www.hifi-remote.com/radioshack/ Radio Shack remotes page]
*[http://www.hifi-remote.com/rcinfo/ Radio Shack's www.rcinfo.com site]
*[http://www.hifi-remote.com/ofaold/ One For All backup #1]
*[http://www.hifi-remote.com/ofausa/ One For All backup #2]
*[http://www.hifi-remote.com/ofa-int/ One For All International]
*[http://www.hifi-remote.com/urc/ UEI's cable remotes page]
*[http://www.hifi-remote.com/hag/ Hudson Access Group's OFA page]

The following are user-maintained sites that are no longer available.
*[http://www.hifi-remote.com/wasser/ John Wasser's old OFA site]
*[http://www.hifi-remote.com/ziggr/ Zig's Amazing IR Remote Control Page]
*[http://www.hifi-remote.com/huras/ Dave Huras's X10 and OFA Page]
*[http://www.hifi-remote.com/sony/ Rob Humphrey's Sony codes page]

==Slingbox==
*[[How to Install a Custom Remote onto the Slingbox]]
*[[Customising the Remote Image on your Slingplayer]]
*[[How to Create Custom Remote Controls and use them on your Slingbox]]
*[http://www.hifi-remote.com/forums/viewforum.php?f=19 Slingbox forum] (presently not operational)
*[https://github.com/hifiremote/Slingbox Slingbox files]

==Resources==
*[https://sourceforge.net/projects/controlremote/ Remote Master Repository]
*[https://www.oracle.com/java/technologies/downloads/ Java Runtime Download (for Remote Master)]
*[[IRP Notation]]
*[[DecodeIR]]
*[[Working With Pronto Hex]]
*[[JP1 versus Harmony]]
*[[Technical Documents]]
*[[Glossary]]
*[http://www.hifi-remote.com/forums JP1 Forums] (defunct)
*[http://www.hifi-remote.com/forums/dload.php JP1 Files] (defunct)
*[http://www.hifi-remote.com/jp1/lookup JP1 Lookup Tool]
*[https://www.youtube.com/watch?v=ubrq9Pr3Y1Y&list=PLXmyroJbN9CAxc6vADS4iiXQT3fp0c-Iq JP1 "How To" Videos]

==References==
''Presently all defunct.'' 
*[https://cdn.jsdelivr.net/gh/hifiremote/deviceupgrades@main/Home%20Automation/Lutron-Master-List.xls Lutron Master List]
*[http://www.hifi-remote.com/forums/dload.php?action=file&file_id=9545 Onkyo Master List]
*[http://www.hifi-remote.com/forums/dload.php?action=file&file_id=508 Pioneer Master List]
*[http://www.hifi-remote.com/forums/dload.php?action=file&file_id=383 Sanyo Projector Master List]
*[http://www.hifi-remote.com/sony/ Sony Master List]
*[http://www.hifi-remote.com/forums/dload.php?action=file&file_id=9582 Yamaha Master List]

==Forums==
*[http://www.hifi-remote.com/forums Old JP1 Forum](now defunct)
*[https://www.remotecentral.com/forums RemoteCentral] (now defunct)
*[https://forum.harctoolbox.org Experimental]
*[https://www.avsforum.com/forums/remote-control-area.93 Remote Control Area subforum within AVS forums]

==Links==
*[https://github.com/hifiremote/ Hifiremote organization at Github]
**[https://github.com/hifiremote/deviceupgrades JP1 device upgrades for RemoteMaster or KeymapMaster]
**[https://github.com/hifiremote/Extenders Collection of extenders, from hifi-remote.com's file section]
**[https://github.com/hifiremote/Tools JP1 Tools and programs] (except Remotemaster that is hosted on SourceForge)
**[https://github.com/hifiremote/Slingbox Slingbox files from JP1]
**[https://github.com/hifiremote/ReplayTV Files and programs used to add IR blaster codes to ReplayTV units]
**[https://github.com/hifiremote/Protocols A variety of information relating to protocols]
**[https://github.com/hifiremote/Miscellaneous-JP1 The "Miscellaneous" files from the JP1 File section]
**[https://github.com/hifiremote/HelpFiles Help and "how to" docs, especially useful for beginners.]
*[https://www.harctoolbox.org Harctoolbox.org Harctoolbox]
*[https://github.com/bengtmartensson/IrScrutinizer IrScrutinizer Repository]

Main Page

2025-10-01T15:29:55Z

Barf: /* References */

Welcome to the JP1 community Wiki site. A collaborative website relative to the JP1 community to which anyone can contribute!

Anyone can create an account, and edit or add pages. The user administration is completely autonomous; you cannot log in with a user-id from another system.

==JP1 Guides==
*[[JP1_Introduction|Introduction to JP1]]
*[[The History of the JP1 Project]]
*[[JP1 - Just How Easy Is It?]]
*[[The WHAT and WHY of JP1]]
*[[Creating A Better Upgrade]]
*[[JP1 Cables]]
*[[Building the Arduino Interface for older remotes]]
*[[Hacking JP1 Remotes]]
*[[Extenders (an FAQ)]]
*[[Infrared Signals]]
*[[How to use RIDgen]]
*[[IrScrutinizer Guide]]
*[[ToadTog]]
*[[Getting started with Xsight and Nevo]]
*[[Xsight_Disassembly]]
*[[Importing Foreign IR Remotes in RemoteMaster]]
*[[Using URC6440 and OARUSB04G Remotes with Linux]]

==Manuals==
*[[Manuals|Remote Manuals]]
*[[Remote Master Manual]] (not complete)
*[[IR Help]]
*[[Protocol Builder]]
*[[IR Scope and IR Widget User's Guide]]
*[[DecodeIR]]
*[[AIRWidget and IRScope Operating Instructions]]
*[[The 3660 family|The 3660 family of remotes]]
*[[INT-422|Programming an INT-422-4 Remote]]
*[[WAV FILES]]

==General Remote Guides==
*[[Manual Programming - 9xx Commands]]
*[[Manual Programming - Sky Remotes]]
*[[Master Reset Instructions]]
*[[Modem Upgrade Procedure]]
*[[The Correct Learning Procedure]]
*[[RemoteChart]]

==Website Archives==
The following are official websites that are no longer active, that have been archived here at hifi-remote.com.
*[http://www.hifi-remote.com/radioshack/ Radio Shack remotes page]
*[http://www.hifi-remote.com/rcinfo/ Radio Shack's www.rcinfo.com site]
*[http://www.hifi-remote.com/ofaold/ One For All backup #1]
*[http://www.hifi-remote.com/ofausa/ One For All backup #2]
*[http://www.hifi-remote.com/ofa-int/ One For All International]
*[http://www.hifi-remote.com/urc/ UEI's cable remotes page]
*[http://www.hifi-remote.com/hag/ Hudson Access Group's OFA page]

The following are user-maintained sites that are no longer available.
*[http://www.hifi-remote.com/wasser/ John Wasser's old OFA site]
*[http://www.hifi-remote.com/ziggr/ Zig's Amazing IR Remote Control Page]
*[http://www.hifi-remote.com/huras/ Dave Huras's X10 and OFA Page]
*[http://www.hifi-remote.com/sony/ Rob Humphrey's Sony codes page]

==Slingbox==
*[[How to Install a Custom Remote onto the Slingbox]]
*[[Customising the Remote Image on your Slingplayer]]
*[[How to Create Custom Remote Controls and use them on your Slingbox]]
*[http://www.hifi-remote.com/forums/viewforum.php?f=19 Slingbox forum] (presently not operational)
*[https://github.com/hifiremote/Slingbox Slingbox files]

==Resources==
*[https://sourceforge.net/projects/controlremote/ Remote Master Repository]
*[https://www.oracle.com/java/technologies/downloads/ Java Runtime Download (for Remote Master)]
*[[IRP Notation]]
*[[DecodeIR]]
*[[Working With Pronto Hex]]
*[[JP1 versus Harmony]]
*[[Technical Documents]]
*[[Glossary]]
*[http://www.hifi-remote.com/forums JP1 Forums] (defunct)
*[http://www.hifi-remote.com/forums/dload.php JP1 Files] (defunct)
*[http://www.hifi-remote.com/jp1/lookup JP1 Lookup Tool]
*[https://www.youtube.com/watch?v=ubrq9Pr3Y1Y&list=PLXmyroJbN9CAxc6vADS4iiXQT3fp0c-Iq JP1 "How To" Videos]

==References==
''Presently all defunct.'' 
*[https://cdn.jsdelivr.net/gh/hifiremote/deviceupgrades@main/Home%20Automation/Lutron-Master-List.xls Lutron Master List]
*[http://www.hifi-remote.com/forums/dload.php?action=file&file_id=9545 Onkyo Master List]
*[http://www.hifi-remote.com/forums/dload.php?action=file&file_id=508 Pioneer Master List]
*[http://www.hifi-remote.com/forums/dload.php?action=file&file_id=383 Sanyo Projector Master List]
*[http://www.hifi-remote.com/sony/ Sony Master List]
*[http://www.hifi-remote.com/forums/dload.php?action=file&file_id=9582 Yamaha Master List]

==Forums==
*[http://www.hifi-remote.com/forums Old Forum (now defunct)]
*[https://www.remotecentral.com/forums RemoteCentral (now defunct)]
*[https://forum.harctoolbox.org Experimental]
*[https://www.avsforum.com/forums/remote-control-area.93 Remote Control Area subforum within AVS forums]

==Links==
*[https://github.com/hifiremote/ Hifiremote organization at Github]
**[https://github.com/hifiremote/deviceupgrades JP1 device upgrades for RemoteMaster or KeymapMaster]
**[https://github.com/hifiremote/Extenders Collection of extenders, from hifi-remote.com's file section]
**[https://github.com/hifiremote/Tools JP1 Tools and programs] (except Remotemaster that is hosted on SourceForge)
**[https://github.com/hifiremote/Slingbox Slingbox files from JP1]
**[https://github.com/hifiremote/ReplayTV Files and programs used to add IR blaster codes to ReplayTV units]
**[https://github.com/hifiremote/Protocols A variety of information relating to protocols]
**[https://github.com/hifiremote/Miscellaneous-JP1 The "Miscellaneous" files from the JP1 File section]
**[https://github.com/hifiremote/HelpFiles Help and "how to" docs, especially useful for beginners.]
*[https://www.harctoolbox.org Harctoolbox.org Harctoolbox]
*[https://github.com/bengtmartensson/IrScrutinizer IrScrutinizer Repository]

IRP Notation

2025-10-01T15:06:11Z

Barf:

'''''Specification of IRP Notation''' - ''by Graham Dixon'' ([https://cdn.jsdelivr.net/gh/hifiremote/HelpFiles@main/IRP%20Spec%20v0.02.pdf PDF Version])

The notation currently used for describing IR protocols, generally just referred to as “IRP notation”, was developed by John Fine in a series of postings on a restricted Yahoo forum on 13 March 2003 and a few following days. Partial descriptions have appeared since in various messages on the JP1 website, but I have been unable to find a comprehensive description. I feel it is time for one to appear.

This document attempts to be a full specification in sufficient detail that an automated process to parse and execute a protocol in IRP notation could be written without the fear that some possible construction has been overlooked. The sections on syntax give an informal description followed by a formal specification of the syntax and a description of the semantics of that syntax. A later section of the document gives an execution model written in the context of a conceptual remote control. This structure leads to some inevitable duplication in places, but I think the benefits outweigh the disadvantages.

==General principles of IRP notation==
===Introduction===
The function of an IR protocol is to transmit a set of named numerical values from one device to another, normally from a remote control to the piece of equipment that it controls, by flashing an infrared light on and off. The IR Protocol (IRP) notation is a means of describing how this is to be done. The names of the values are commonly “Device code”, “Subdevice code” and “Function code”, but some or even all of these may be absent and others may be present. There may also be values for other purposes, such as

*a calculated “Checksum” to provide a confirmation that the signal has been received correctly, or
*a “Toggle” that the sender changes from one signal to the next to enable the receiver to distinguish two otherwise identical signals from one longer signal.

The infrared signal consists of a series of flashes of light with gaps in between. In a flash the light is usually not on continuously, but is being pulsed on and off rapidly at a fixed frequency, known as the ''carrier frequency''. In the gaps, the light is fully off. As an example, a flash lasting 1200 microseconds could consist of 48 on/off cycles at a frequency of 40kHz and could be followed by a gap of 600 microseconds before the next flash. The information is carried in the durations of the flashes and gaps. The frequency itself carries no information. Frequencies vary between protocols, but are fixed for any individual protocol.

In the language of IR protocols a flash and its following gap is generally known as a “burst pair”. The IRP notation describes the encoding process by which the values to be transmitted are converted into a stream of burst pairs with varying durations.

===Basic objects===
The basic objects of the IRP notation are names and numbers. Names are sequences of capital letters and
digits but must not start with a digit. Numbers are sequences of digits but must not start with zero unless
they consist solely of the digit zero. The notation is composed of names and numbers together with other characters from the ASCII character set. White space, e.g. space characters, tabs, line feeds and form
feeds, are ignored but may be used anywhere for convenience and ease of readability.

Names and numbers both ultimately represent values. Names are used for two purposes. External names are given values by means outside the IRP notation. These values are the data that the protocol is to convey. Internal names correspond to checksums or any other derived values. Internal names are given values by means of definitions that show how they are to be calculated.

For conciseness it is common to use single capital letters for names, with the correspondence

D = Device code 
S = Subdevice code 
F = Function code (otherwise called OBC or Original Button Code) 
C = Checksum 
T = Toggle. 

Other single letters are also used as required, but so are abbreviations such as OEM1.

The values represented by names and numbers are integers. Values are usually positive integers or zero, but negative integer values can also occur, such as in the value of a name that represents displacement of a mouse. The value of a number is that number regarded as an integer expressed in decimal notation. Negative integers cannot be represented directly by numbers. A negative integer has to be enclosed in parentheses, e.g. (-12). This is a simple example of an expression. It is not a basic object as it is composed of the number 12 together with the non-alphanumeric symbols "(", "-" and ")".

===The execution process===
Execution is the process of generating the IR signal from the representation of a protocol in IRP notation. There is a specification of the execution process in section 14 in terms of the action of a conceptual remote control. The resulting signal is described in terms of the durations of the flashes and gaps that compose it, together with the frequency and duty cycle of the carrier wave that is sent during a flash.

The carrier frequency was described in 1.1. The duty cycle is the percentage of the cycle time that the IR light is on. A carrier frequency of 40kHz means that there are 40000 cycles per second, so each lasts 25μs. If each cycle consists of the IR light being on for 9μs and off for 16μs then the duty cycle is 9/25, or 36%. The frequency varies substantially between one protocol and another and is given in the IRP notation. The duty cycle is a matter for the implementation and is not given in the IRP notation. Duty cycles are typically around 33%. A larger value means that the batteries in a remote control will last less long but the range of the signal will be greater.

===Execution concepts===
There are two intermediate concepts used in the specification of the execution process, a binary form and a bit sequence. These do not have specific IRP notations as they do not occur as such in the IRP representation of protocols. A binary form is essentially the type of representation of an integer value that is used internally in computers, namely the value expressed in binary notation with a fixed bit length. The four-bit binary form for the value 5, for example, is 0101, and for -5 is 1011 (as these two add to 0000 when overflow is ignored).

A binary form has a numerical value. This is its value treated as the binary representation of an integer on the assumption that any leading bits not included in the binary form are 0's. It may seem pedantic to be this specific, but it is necessary since the value of a finite length binary form that represents a negative integer is not that integer, it is a positive integer which depends on that length. The value of the 4-bit binary form for -5 given above is 11, the value of the 6-bit binary form for -5 is 59.

Binary forms of infinite length can occur conceptually during execution. These are the only binary forms whose value can be negative. They occur implicitly in computers in the Arithmetic Shift Right operation on the binary representation of signed integers. In this operation the vacant space created on the left by the shift is filled not with zero but with a copy of the most significant bit of the unshifed value, as if that bit value continued indefinitely to the left and one bit of it has just been shifted into visibility.

The other intermediate concept in execution is a bit sequence. This is a sequence of bits given in the order in which they are to be processed for transmission. It is therefore a sequence in time, but when written the sequence order is from left to right. A bit is a binary digit, as in the binary notation for integers, so a written bit sequence looks very much like an integer in binary form. They are not the same, however, and the distinction is very important in IRP execution. The bits in a bit sequence have no interpretation in themselves. They are constructed from the values to be sent, and values are reconstructed from them when received, but it is the structure of the protocol and not the rules of binary notation that determines the relationship between values and bit sequences. In particular there is no demarcation between consecutive bit sequences constructed from distinct values.

During the execution process, values are translated into binary forms, binary forms into bit sequences and bit sequences into the sequences of flash and gap durations that describe the signal, so in outline the steps of the execution process are

values --> binary forms --> bit sequences --> duration sequences

===Translation objects===
The rule for each of these translation steps in the execution process is specified by a particular type of object in IRP notation. The translation of values to binary forms is described by a bitfield, that of binary forms to bit sequences by a sequencing rule and that of bit sequences to duration sequences by a bitspec.

These object differ in their scope. The scope of a bitfield is an individual value. The scope of a sequencing rule is the entire protocol. The scope of a bitspec is in between these two extremes. It covers everything up to the point at which another bitspec is given that changes the rule.

Not all durations in the signal come from values in this way. There are also flashes and gaps in the signal that are for control purposes, such as to distinguish one protocol from another. These do not depend on the data. They are described by specific notations for a flash duration and a gap duration.

There remains one other type of translation object. This is a gap of variable duration that is used to make the total extent in time of the signal, or some major part of the signal, up to a constant length that is independent of the data being sent. It is of variable duration since the lengths of the individual flashes and gaps do depend on the data. The notation for such a variable gap is an extent. The typical use of extents is as the lead-out gap at the end of the signal. Many buttons on a remote control repeat the signal throughout the time that the button is held down. Using an extent as a lead-out ensures that the frequency of repeats does not depend on the data being sent. In the translation phase the data is known, so that an extent can be translated into a specific gap duration

===Overall structure===
The complete description of a protocol in IRP notation is composed of three or four sections:
*A GeneralSpec that specifies the carrier frequency, the sequencing rule and a time unit that can be used in durations and extents;
*A Bitspec that provides the default rule for the translation of bit sequences to duration sequences.
*An IRStream that gives the sequence of data to be translated and transmitted.
*If required, Definitions that give the expressions required to calculate the values of internal names.

These are all described in detail in the following sections. The IRstream section can contain further bitspecs and IRstreams but there is only one GeneralSpec and at most one Definitions section. The Bitspec section provides only a default rule as bitspecs within the IRstream section may change the rule for certain parts of the data.

===Formal syntax===
Each descriptive part of the specification will be accompanied by a formal syntax given in EBNF (Extended Backus-Naur Form) notation and by a precise description of the semantics. An execution model that incorporates these semantics is given in section 14.

There are various extensions of BNF notation in use. This document uses the version standardized by ISO in ISO/IEC 14977:1996, which is freely available on the ISO website.

The characters used in the IRP notation are all characters of the International Reference Version of ISO/IEC 646:1991, commonly referred to as ASCII. Certain characters have more than one usage in the IRP notation, distinguished from one another by context. In particular, the LESS-THAN SIGN and GREATER-THAN SIGN also serve as left and right diamond brackets respectively and the HYPHENMINUS is used both as a minus sign and as a symbol with a meaning specific to IRP notation.

The formal syntax of the overall structure is:
'''protocol = generalspec, bitspec, irstream, [definitions];'''

In EBNF notation, square brackets denote an optional item. There are no semantics at this level.

==The GeneralSpec section==
===Description===
The GeneralSpec section specifies the carrier frequency and certain data that apply throughout the translation process. It is a list of up to three items, separated by commas and enclosed in curly brackets. Three types of item can occur in the list. Each type is optional and there can be at most one item of each type. They are:
*A frequency item, consisting of a number followed by the letter "k". It gives the carrier frequency in kilohertz. The default is a frequency of "0k", which signifies a baseband signal in which the light stays on continuously during a flash. Although optional, a frequency item is normally given since the default value is uncommon and so is best specified explicitly when it applies.
*A unit item, consisting of a number followed optionally by either of the letters "u" or "p". It determines a unit of time that can be used in durations and extents.
**No suffix, or a suffix "u" indicates that the unit is that number of microseconds.
**A suffix "p" indicates that the unit is the time taken for that number of pulses of the carrier frequency, so the unit in microseconds is the given value multiplied by (1000/f), where f is the number preceding the "k" in the frequency item.
**If there is no unit item, it defaults to "1u", i.e. one microsecond.
*An order item, which gives the sequencing rule that applies globally for the conversion of binary forms to bit sequences. If present it takes one of the values "lsb" or "msb". If it is "lsb" then the time ordering of the bits in the bit sequence is that the sequence starts with the least significant bit ("lsb"). If it is "msb" then the ordering is to start with the most significant bit. The default is "lsb". In contrast to the situation with the frequency item, the default is the most common rule and it is not usually specified explicitly.

The number in a frequency item can include a decimal point. This is the only situation in IRP notation in which numbers can be other than integers.

These items can be given in any order. Examples of possible GeneralSpecs are:

{ }, {38.4k, 564}, {msb, 889u}, {10p, msb, 40k}

In the first of these, all items take their default value, so the signal is baseband, the sequencing rule is to convert binary forms to bit sequences in lsb order and the time unit is one microsecond. In the last of these, the carrier frequency is 40 kilohertz, binary forms are converted in msb order and the time unit is 10*(1000/40) = 250 microseconds.

===Formal syntax===
The complication in giving a formal syntax for the GeneralSpec section comes from the order of the item types being arbitrary. This is dealt with by allowing each item to be of any type but then imposing a restriction that no two items can be of the same type, as follows:

<pre>generalspec = "{", generalspec list, "}";
generalspec list = | (generalspec item, 2*[",", generalspec item])
- generalspec list with repeats;
generalspec item = frequency item | unit item | order item;
frequency item = number with decimals, "k";
unit item = number, ["u" | "p"];
order item = "lsb" | "msb";

generalspec list with repeats =
{generalspec item, ","}, frequency item, ",", {generalspec item, ","},
frequency item, {",", generalspec item}
| {generalspec item, ","}, unit item, ",", {generalspec item, ","},
unit item, {",", generalspec item}
| {generalspec item, ","}, order item, ",", {generalspec item, ","},
order item, {",", generalspec item};</pre>

Vertical bars separate alternatives. The vertical bar at the start of generalspec list is preceded by an empty alternative, signifying that a generalspec list can be empty. The other alternative is one generalspec item followed by two more optional ones each preceded by a comma separator, provided that the list so constructed is not also a generalspec list with repeats. This consists of all lists of items that include two of the same type, specified separately for each possible repeated type. Curly brackets in EBNF notation denote an arbitrary number of repetitions, including zero.

The undefined identifier number is the basic object described in 1.2. Its formal definition is given in 13.2 The identifier number with decimals means the same except that a decimal point is allowed.

===Semantics===
The real number in a frequency item is the carrier frequency in kilohertz. A zero frequency means that the signal is baseband, i.e. during a flash the IR light is on continuously. This is the default when this item is absent.

A unit item specifies a length of time that can be used as a time unit in durations and extents. If it has no suffix or the suffix "u" then number is the length of time in microseconds. If it has suffix "p" then the length of time in microseconds is number multiplied by (1000/f) where f is the real number preceding the "k" in the frequency item. The result of the multiplication is rounded to the nearest integer. If the unit item is absent then it specifies a time unit of one microsecond.

The order item specifies the global sequencing rule. If it is absent or has the value "lsb" then binary forms are converted to bit sequences by starting with the least significant bit. If it has value "msb" then they are converted starting with the most significant bit.

==Durations==
===Description===
Durations specify a length of time in the sending of the IR signal. They describe the modulation of the signal carrier and have a meaning only as part of a sequence. There are two types of duration, a flash duration and a gap duration. A flash duration is a length of time for which the signal carrier is "on". A gap duration is a length of time for which it is "off". These are the only two states of the carrier during a signal; it is either fully on or fully off.

The notation for a flash duration is simply the length of time, given in terms of a time unit determined by
a suffix to the numerical value as follows:
*"m" indicates that the duration is in milliseconds;
*"u" indicates that the duration is in microseconds;
*"p" indicates that the duration is in pulses of the carrier frequency, as described in 2.1 above;
*no suffix indicates that the duration is in the time unit determined by the unit item of the GeneralSpec section.

The notation for a gap duration is the same but prefixed by "-". If there are two consecutive flash durations or gap durations in a sequence then the effect is the same as a single one for the total of the two times. There is nothing in the transmitted signal to indicate where one ends and the next starts.

Suppose that the GeneralSpec is {40k, 200}. Then if A = 150, the very artificial sequence 15p,-1m,3,Au,-20m means:
*a flash of 15*(1000/40) = 375 microseconds, followed by
*a gap of 1 millisecond = 1000 microseconds, followed by
*a flash of 3*200 + 150 = 750 microseconds, followed by
*a gap of 20 milliseconds = 20000 microseconds.

This illustrates that units can be mixed, that names can be used and can have suffixes and that flashes and gaps do not have to alternate.

===Formal syntax===
<pre>duration = flash duration | gap duration;
flash duration = name or number, ["m"|"u"|"p"];
gap duration = "-", name or number, ["m"|"u"|"p"];
name or number = name | number;</pre>

===Semantics===
A flash duration is a length of time in an IR signal for which the carrier is in the ON state. A gap duration is a length of time for which it is in the OFF state.

The suffix determines how the value of the name or number is converted into a length of time in microseconds, as follows:
*For suffix "u" the number is already the time in microseconds.
*For suffix "m", multiply by 1000.
*For suffix "p", multiply by (1000/f) where f is the real number preceding the "k" in the frequency item of the GeneralSpec.
*If there is no suffix, multiply by the length in microseconds of the time unit specified by the unit item of the GeneralSpec.

==Extents==
===Description===
An extent is a gap duration whose length in time cannot be given explicitly in the protocol. An extent has a scope which consists of a consecutive range of items that immediately precede the extent in the order of transmission in the signal. The role of an extent is to ensure that the time taken for this range of items to be transmitted, plus the following gap (corresponding to the extent), has a constant value even though the time taken by the individual items may vary according to the data being transmitted. It is this constant value that is given in the extent. The precise scope of an extent has to be defined in the context in which it is used.

The notation for an extent is as that for a gap duration, except that the prefix is "^" instead of "-". When all the items in its scope have been translated into durations, the extent can be translated into a gap duration by subtracting the total length in time of the durations in its scope from the time given in the extent. An artificial example is

1,-4,D,^25

as an extent with its preceding scope. This translates to 1,-4,10,-10 if D = 10 but to 1,-4,5,-15 if D = 5, the final gap making the duration as a whole up to 25 units regardless of the value of D.

===Formal syntax===
<pre>extent = "^", name or number, ["m"|"u"|"p"];</pre>

===Semantics===
The name or number together with the suffix, if any, determine a length of time as in the semantics of a duration described in 3.3.

An extent has a scope that has to be defined in any context in which an extent can be used. During execution, all the items in the scope are converted into durations. The extent then translates into a gap duration by subtracting the total length in time of these durations from the length of time determined by the extent.

==Bitfields==
===Structure and interpretation===
A bitfield is a translation object that converts a specific value to a binary form. Note, however, that the binary form may be constructed from only a portion of the bits in the binary expression of the value and that even if it corresponds to all these bits then the value of the binary form may not be the same as the value from which it was constructed.

A simple example of a bitfield is D:6. The binary form consists of the least significant six bits of D, with the binary representation of D considered as padded on the left with potentially an infinite number of zeroes. So if D = 244, its value in binary notation is ...00011110100 and the least significant six bits give the binary form 110100. If D = 5, its value in binary notation is ...00000101 and the least significant six bits give the binary form 000101.

A bitfield such as D:6:2 is similar, but leaves out the two least significant bits and selects the next six. For D = 244 and D = 5 this gives respectively the binary forms 111101 and 000001. The bitfield D:6 is equivalent to D:6:0.

The value concerned can be negative. In this case no padding is required. The complete binary representation of a negative integer (in the usual 1's complement form) extends on the left to infinity with all tbe bits beyond a certain point being 1. So -5 is ...11111011 where the dots denote an infinite sequence of ones (since when this is added to ...000000101 the digits of the sum are all zero). If D = -5, the binary form given by D:6 is 111011. To write this using an explicit value, we must use brackets, thus (-5):6 to show that the minus sign is part of the value and not a prefix of the IRP notation. This is an example of the use of an expression in a bitfield. Expressions are described in more detail in 9.1 below.

There are three further refinements to the bitfield notation. The first element of the bitfield can have a prefix "~". This complements each bit in the binary form, i.e. changes a 1 to a 0 and vice versa. The second element can be absent or, if present, can have a prefix "-". If it is absent then the bit length of the binary form is conceptually infinite, as described above. In this case the third element must be present to prevent the bitfield ending with a colon and so giving rise to ambiguous syntax. A third element can always be added without changing the interpretation, so although D: is not valid, D::0 is equivalent and is valid. Prefixing the second element with "-" reverses the order of the bits in the binary form, so the most significant bit becomes the least significant bit, etc. So with D = 244, ~D:6:2 gives the binary form 000010, D:-6:2 gives 101111 and ~D:-6:2 gives 010000.

It was explained in 1.4 that binary forms have values, although bit sequences do not. With D = 244 the values of these three binary forms are ~D:6:2 = 2, D:-6:2 = 47 and ~D:-6:2 = 16.

There are still more subtleties to be aware of. Each element can be any type of primary item, a primary item being a name, a number or an expression, provided that the second and third elements evaluate to non-negative integers. Expressions can be recognised as they are enclosed in parentheses but they can themselves contain bitfields. When a bitfield occurs in an expression, its value is the value of the binary form to which it translates, not the binary form itself. So F:D is a valid bitfield whose binary form consists of the D least significant bits of the value of F. It is not valid to take D = -4 and expect this to be the same as F:-4, since the prefix "-" in F:-4 is part of the IRP syntax, not of the value of the second element. But F:-D with D = 4 is valid, and does mean F:-4. If A = 7 then F:A:2 means F:7:2 but F:(A:2) means F:3, since A = 111 in binary notation so A:2 is the binary form 11 and the expression (A:2) evaluates to 3.

===Formal syntax===
<pre>bitfield = ["~"], primary item, ":", (["-"], primary item, [":", primary
item] | ":", primary item);
primary item = name | number | expression;
(* The different types of primary item can be distinguished by their first
character as follows: digit => unsigned integer, capital letter => name,
"(" => expression. *)</pre>

===Semantics===
Each type of primary item evaluates to an integer value. A bitfield evaluates to a binary form, an integer value expressed in binary notation with a fixed finite or infinite bit length in which negative integers are expressed in 1's complement notation. The value of the bitfield a:b:c, where the integer a and nonnegative integers b and c are the values of the primary items, is determined as follows:
*express a in its binary representation, conceptually padded on the left with an infinite number of 0's or 1's as appropriate, negative values being expressed in the usual 1's complement form;
*delete the c least significant bits;
*if b is present take the next b least significant bits and discard the rest, otherwise b is absent and nothing is discarded, the binary form is the conceptually infinite form that remains.

The value of a:b is the same as a:b:0. In the general case where either or both of the permitted prefixes are present then apply the following further steps:
*if the first item in the bitfield has the prefix "~" then complement each bit in the sequence, i.e. replace 1's by 0's and 0's by 1's;
*if the second item in the bitfield has the prefix "-" then reverse the order of the sequence.

Note that the "-" prefix is not permitted unless b is present. If either b or c is negative then the bitfield is invalid. In the execution process, a bitfield is a translation object that translates the value a to a binary form.

==IRstreams==
===Description===
As seen in 1.6, the detail of an IR protocol is carried in an IRstream but that is not the only role of
IRstreams, as will be seen in section 7. An IRstream consists of a list of items that represents an order for
transmission, together with an optional marker that describes whether and how those items are to be
repeated in the transmission. Each item ultimately translates to a duration or a sequence of durations.
IRstreams can be nested but the outer one, the IRstream section described in 1.6, translates to the
sequence of durations that describes the entire signal.

Each item in the list is one of the following:
*Duration
*Extent
*Assignment
*Variation
*Bitfield
*IRstream
*Bitspec followed by IRstream

The notation for an IRstream is that the items are separated by commas, the list is enclosed in parentheses and optionally followed by a repeat marker. Repeat markers are the subject of section 8 below.

Items that are durations need no translation. Extents are translated into durations in accordance with
section 4, the scope of an extent being all items from the start of the IRstream to the extent itself.
Assignments do not themselves translate to durations, instead they change the values bound to names in
the global environment. Variations are alternative sections of the IRstream in which the active alternative
may vary as the IRstream is repeated in accordance with its repeat marker. Durations and extents have
been described in previous sections, assignments and variations are described in sections 11 and 12 The
scope rule for an extent is handled automatically by the execution model of section 14.

Bitspecs also have a specific scope. Every bitspec is always followed by an IRstream, but not necessarily conversely. As the list of item types shows, an IRstream can contain other IRstreams that do not have preceding bitspecs. The scope of a bitspec is the whole of the IRstream that follows it but excluding the scopes of any bitspecs that this IRstream contains.

A bitfield is processed as follows. Its primary items (names, numbers and expressions) are evaluated in the context of the global environment. The bitfield is then evaluated as a binary form as described in 5.3. The sequencing rule determined by the GeneralSpec in accordance with 2.3 is then applied to translate the binary form into a bit sequence. Adjacent bit sequences are concatenated and then processed further in accordance with the currently active bitspec, i.e. the one in whose scope they lie. This is described in section 7 below.

During execution the processing of an IRstream is performed in left to right order, i.e. in the order of its
items for transmission. This is significant as assignments may change the values bound to names in the
global environment, so that subsequent items are processed in the context of the changed environment.
When this sequential processing reaches an item that is itself an IRstream, processing of the current
IRstream is suspended and that of the new one commenced. When the processing of this new IRstream is
completed, that of the previous one is resumed. In the execution model of section 14, this is handled
through a last in, first out (LIFO) IRstream stack. When the sequential processing reaches an item that is
a bitspec, this becomes the currently active bitspec. When processing of the IRstream that follows this
bitspec is completed, the bitspec that was formerly active is restored as the current one. In the execution
model of section 14, this is handled through a LIFO bitstream stack.

As a simple example of an IRstream, consider the following one that occurs in the Dish Network:
<pre>(F:-6,U:5,D:5,1,-15).</pre>

In this protocol the sequencing rule is lsb. Suppose F=13, U=3, D = 25. In binary notation these values are F = 1101, U = 11, D = 11001. Pad these to the lengths specified in the bitfields to give F = 001101, U = 00011, D = 11001. Take account of the "-" prefix in F:-6 to give the binary forms
<pre>F:-6 = 101100, U:5 = 00011, D:5 = 11001.</pre>

As the sequencing rule is lsb, these translate separately to the bit sequences

0 0 1 1 0 1, 1 1 0 0 0, 1 0 0 1 1

where the bits have been spaced out to distinguish them from binary forms. As these are adjacent in the IRstream they are concatenated into the single bit sequence

0 0 1 1 0 1 1 1 0 0 0 1 0 0 1 1

for further processing by the active bitspec.

There is now no demarcation in the bit sequence to show where the bits from the different external values
start and end. This comes into its own if the bitspec translates bits in groups rather than individually, a
possibility that will be seen in section 7. In the Dish Network protocol they actually are translated
individually, but suppose for the sake of this example that they are translated in groups of four, as actually happens in the XMP protocol. This grouping would be

0 0 1 1, 0 1 1 1, 0 0 0 1, 0 0 1 1

which is very different from that resulting from the binary forms. The bits comprising the second of these groups are actually the two least significant bits of F in msb order, followed by the two least significant bits of U in lsb order, but this group would be processed by the bitspec as a single entity. In a similar way both U and D contribute to the third group. As a result there would be no part of the IR signal that could be said to be the encoding of any of F, U or D. These separate values can be recovered from the signal only in the context of the protocol specification that was used to translate and encode them.

The concatenation of bit sequences and the subsequent re-grouping for processing by a bitspec is handled in the execution model by means of a first in, first out (FIFO) bit buffer. Each bitspec has its own such buffer for the bits it is to process.

===Formal syntax===
<pre>irstream = "(", bare irstream, ")", [repeat marker];
bare irstream = | irstream item, [",", bare irstream -];
(* This allows a bare irstream to be empty but the bare irstream in the
second alternative cannot be empty. This is the significance of the
minus sign, which is the EBNF exception symbol. What is excluded by
the exception is what follows it, which in this case is empty. *)
irstream item = duration | extent | assignment | variation | bitfield |
irstream | bitspec, irstream;</pre>

===Semantics===
The items of a bare irstream are processed sequentially from left to right, each in accordance with its own semantics. In the case of a bitfield there is a further processing stage. Processing of a bitfield yields a binary form. This is then translated to a bit sequence in accordance with the global sequencing rule.

The permitted item types include extent and bitspec, each of which requires its scope to be specified in any context in which it can be used. Within an irstream the scope of a bitspec is every item in the following irstream except for items of the form "bitspec, irstream", where the scope includes the bitspec but not the irstream. The scope of an extent is every item that precedes it in that irstream.

==Bitspecs==
===Description===
A bitspec specifies a rule for translating a bit sequence into a bare IRstream, i.e. an IRstream without its enclosing parentheses and any following repeat marker. In effect, this bare IRstream simply replaces the bit sequence to create a new IRstream. The details of this process are given below.

The action of a bitspec is not restricted to a specific bit sequence. Instead it is a general rule that has a well-defined scope specified in 6.1 and which applies to any bit sequence in its scope.

The rule usually translates each bit separately but it may translate bit pairs or bit quadruples, or indeed bits taken in groups of any size but only groups of 1, 2 or 4 bits have yet been seen in real protocols. The rule is defined simply by giving the bare IRstream corresponding to every possible combination of 0's and 1's in a group of the appropriate size.

For a bitspec that translates bits in groups of n, the number of possible combinations is 2 to the power n.
The corresponding sequences of bare IRstreams are listed in the order of the bit sequences given by the
bitfields

0:n, 1:n, 2:n, 3:n, ... (n-1):n.

These bitfields are translated to bit sequences as if they were themselves IRstream items, so this is a twostep
process. First they are translated to n-bit binary forms and then the global sequencing rule is applied
to further translate them to bit sequences. If the sequencing rule is "msb" and n = 3 then this order is

0 0 0, 0 0 1, 0 1 0, 0 1 1, 1 0 0, 1 0 1, 1 1 0, 1 1 1

but if the sequencing rule is "lsb" then the order is

0 0 0, 1 0 0, 0 1 0, 1 1 0, 0 0 1, 1 0 1, 0 1 1, 1 1 1.

The notation for a bitspec is a list of the bare IRstreams separated by vertical bars "|" with the whole enclosed in diamond brackets (i.e. less-than and greater-than signs). The number of bare IRstreams does not have to be a power of two, but if it is not then it is treated as if this number were the next greater nonzero power of two and with the bare IRstreams for the later bit sequences being empty. It is not a syntax error as a bare irstream is permitted to be empty. The qualification "non-zero" permits, say, <1,-2> to be a valid bitspec for which n = 1, the bit 0 is mapped to the bare IRstream 1,-2 and the bit 1 is mapped to the empty bare IRstream.

Some examples of bitspecs from real protocols are:

<1,-1,1,-8|1,-10>, <-1,1|1,-1>, <1,-3.3m|1,-4.7m>, <-4,2|-3,1,-1,1|-2,1,-2,1|-1,1,-3,1>.

These illustrate the form that is by far the most common, in that the bare IRstreams are simply sequences of durations. Bitfields also occur in bitspecs within IRstreams for some real protocols. The IRP notation, however, permits any of the types of item listed in 6.1 as permitted in IRstreams and the execution model of section 14 can handle any such construction.

The action of a bitspec in the execution process is as follows. Recall that adjacent bit sequences are concatenated, as described in 6.1, so this description applies to the resulting concatenated sequence. The bits of the bit sequence to be processed are taken in groups of the appropriate size starting from the beginning of the sequence. Each group is then translated into the corresponding bare IRstream. This will result in a series of consecutive bare IRstreams that are themselves concatenated into a single, larger, one. The overall effect is therefore to translate a bit sequence into a single bare IRstream. The execution process then processes this bare IRstream before returning to process the subsequent items of the original IRstream.

In the general form of a bitspec the bare IRstream that it constructs may itself contain bitfields (which occurs in a number of real protocols) or even IRstreams possibly proceded by other bitspecs (which have not yet been seen in real protocols). In either case the whole process for the translation of bitfields to bare irstreams may be called recursively. This raises the question of which bitspec is used for such recursive processing. This is answered by the scope rule for bitspecs. As described in 6.1, when a bitspec is encountered within an IRstream, the scope of the new bitspec is the IRstream that follows it. The bare IRstreams within that new bitspec fall within the scope of the "old" bitspec that applies to the containing IRstream, and therefore it is this "old" bitspec that applies in recursive processing. The execution model of section 14 handles this through the bitspec stack that was mentioned in 6.1.
===Execution example 1: Zenith protocol===
As an introduction to the execution model of section 14, this subsection examines a simple but non-trivial example, the Zenith protocol, to see how the semantics described so far can be modelled in terms of stacks and buffers. The protocol is

{40k,520}<1,-1,1,-8|1,-10>( S:1,<1:2|2:2>(F:D),-90m )+

where the plus sign is a repeat marker that will be explained in 8.1.

Suppose that D = 4, S = 1 and F = 43. The first item to be processed is the outer bitspec. This gets pushed on the bitspec stack and becomes the currently active one. The next one is the outer IRstream, which first gets pushed on the irstream stack and then its contents is processed.

This processing begins with the bitfield S:1, which now is 1:1 and which translates to the trivial bit sequence 1. The currently active bitspec translates this to the bare IRstream

1,-10

which in the execution model is then transmitted as the start of the signal.

The execution process then meets the inner bitspec, which is pushed on the bitspec stack and becomes the currently active one. The following IRstream is pushed on the IRstream stack and flagged as having a preceding bitspec.

The contents of this inner IRstream is now processed. It has one item, the bitfield F:D. The binary representation of F is 101011, so as a binary form F:D = 1011. The sequencing rule is lsb, so the bit sequence is 1 1 0 1. This is pushed into the buffer for the active (inner) bitspec, but as there are no more items in the IRstream then the next step is to process this buffer with the bitspec to which is belongs.

The first stage in processing the buffer is to make the previous bitspec (the outer one) be the active one by decrementing the stack pointer. The bits are pulled and processed (FIFO) one at a time, the order being 1 1 0 1. The first bit gets mapped to the bitfield 2:2, translated to the binary form 10 and then, since the sequencing rule is lsb, to the bit sequence 0 1. This is pushed into the buffer of the currently active bitspec, which is now the outer one. Note that two buffers are now in current use.

The remaining three bits of the buffer being processed are pulled, mapped and processed similarly; in general this continues until either the buffer is empty or processing of the bare IRstream resulting from the mapping meets something other than a bitfield. This is the way the concatenation of bit sequences is handled. When either of these happen then the buffer is processed. In the present case this continues until the buffer being processed is empty and the buffer of the current (outer) bitspec contains

0 1 0 1 1 0 0 1.

This buffer is now processed by its bitspec. The bitspec stack pointer is again decremented, which means that there is now no current bitspec. So if a bitfield was encountered it would be an error, but that does not happen here as each of these bits is mapped to a sequence of durations by the outer bitspec according to the mapping.

0 -> 1,-1,1,-8 1 -> 1,-10.

In the execution model these are transmitted as they are encountered. When this has been done and this buffer is empty, the previous active bitspec, the outer one, is again made current by incrementing the bitspec stack pointer. Its buffer is now empty so the bitspec stack pointer is incremented once again to make the inner bitspec be active.

Processing of the inner IRstream now resumes, with the item after F:D. But the end of this IRstream has been reached, so its processing has been completed, together with that of its preceding bitspec since its scope was just this IRstream. As the IRstream was flagged has having a preceding bitspec, that bitspec is pulled from the stack, once again making the outer bitspec be active. The completed (inner) IRstream is also pulled from its stack and processing resumes of the outer IRstream.

There is only one item left, the lead-out gap -90m. Execution waits for this time and then continues with the next execution of the (outer) IRstream in accordance with the repeat marker.

===Execution example 2: Proton protocol===
Extents do not occur in the Zenith protocol, but a real example in which they do occur is the Proton protocol. This protocol is

{38k,500}<1,-1|1,-3>(16,-8,D:8,1,-8,F:8,1,^63m)+

where again the plus sign is a repeat marker.
To handle extents in the execution model, when each IRstream is pushed on the stack its start time is recorded. If an extent is encountered while processing that IRstream, execution adds its time period to the start time and waits until that is the current time. In this way both the scope of the extent and its conversion to a gap duration get incorporated simply into the model.

Suppose the values of the device code D and function code (OBC) F are D = 34, F = 19. There are no nested IRstreams or bitspecs so processing is straightforward. The bitspec is pushed on the bitspec stack, the IRstream on the IRstream stack and the start time is recorded, say T. The initial durations 16, -8 are converted to a flash and gap and transmitted as the start of the signal. Since in binary notation D = 100010 and the sequencing rule is lsb, the bitfield D:8 translates to the bit sequence

0 1 0 0 0 1 0 0

This is pushed into the buffer of the bitspec but is immediately processed since the next item in the bare IRstream is a duration, not a bitfield. The bitspec shows that the bits are translated to duration sequences one at a time, with the correspondence

0 -> 1,-1 1 -> 1,-3.

The corresponding flashes and gaps are sent as the next part of the signal, followed by those for the two durations 1, -8 that are next in the bare IRstream. The bitfield F:8 translates to the bit sequence

1 1 0 0 1 0 0 0

which is mapped to durations just as for D:8 and sent next since it is followed by another duration, value 1, which follows these as a flash.

At this point the time taken by the flashes and gaps already transmitted totals 76 units. The unit is that specified by the GeneralSpec, namely 500μs, so 76 units is 38 milliseconds. The real-time clock that read T at the start of the processing of this IRstream therefore now reads T+38 milliseconds. The extent value is 63 milliseconds so the execution model waits until the current time is T+63 milliseconds before it performs the next action (which would be a repeat execution of the IRstream). This is a gap of 25 milliseconds, in agreement with the extent syntax of subtracting the total length (38 milliseconds) of the preceding durations in the IRstream from the time period (63 milliseconds) of the extent and treating the extent as a gap duration with the value of that time difference.

===Formal syntax===
<pre>bitspec = "<", bare irstream, {"|", bare irstream}, ">";</pre>

===Semantics===
A bitspec is always followed by an irstream. It acts on the contents of that irstream after any bitfield items within the scope of the bitspec have been translated into bit sequences in accordance with 6.3 and any consecutive bit sequences so produced have been concatenated. Its action is to translate such concatenated bit sequences into bare irstreams.

A bitfield itself defines a mapping of time-ordered bit sequences to bare irstreams. If the number of bare irstreams in the bitspec is 2 to the power n then these correspond, in their order of occurrence in the bitspec, to the bit sequences given by the bitfields 0:n, 1:n, 2:n, 3:n, ... (n-1):n. These bitfields are translated into time ordered bit sequences in the context of the global sequencing rule.

If the number of bare irstreams in the bitspec is not a power of 2 then n is taken as the power in the next greater non-zero power of two and the correspondence between bit sequences and bare irstreams is made in left to right order until the bare irstreams are exhausted. The remaining bit sequences are taken as mapped to empty bare irstreams.

The action of a bitfield on a fully concatenated bit sequence is given by taking its bits in groups of n in their time-sequence order starting from the earliest bit and concatenating the bare irstreams that result from mapping each such group. If the number of bits in the bit sequence is not a multiple of n then it is a semantic error.

==Repeat markers==
===Description===
A repeat marker is an optional element of an IRstream, as described in 6.1, that specifies whether and how execution of that IRstream is to be repeated. The possible repeat markers are:
*"*" which indicates zero or more times;
*"+" which indicates one or more times;
*a number, e.g "3", which indicates that number of times;
*a number followed by "+", which indicates at least that number of times.

So "*" is equivalent to "0+" and "+" to "1+". Assignments and variations in an IRstream may mean that the repeat executions may not all produce the same signal. For repeat markers that specify only a minimum number of repeats, repeats continue beyond the minimum number for as long as the button on the remote is held down, or for one more repeat beyond this if so determined by a variation in accordance with section 12 below. In the execution model of section 14 the remote is a conceptual one.

A simple example is the Dish Network protocol whose inner IRstream was considered in 6.1 In full the protocol is

{57.6k,400}<1,-7|1,-4>(1,-15,(F:-6,U:5,D:5,1,-15)+)

The initial durations 1, -15 are sent only once but the following inner IRstream is sent for as long as the button is held down, but at least once. All repeats are identical, since the inner IRstream contains no assignments or variations.

===Formal syntax===
<pre>repeat marker = "*" | "+" | number, ["+"];</pre>

===Semantics===
A repeat marker following an IRstream specifies whether and how execution of that IRstream is to be repeated. The number of repetitions is determined by the repeat marker as follows: "*" signifies that the IRstream is executed zero or more times, "+" signifies one or more times, a number signifies that many times and a number followed by "+" signifies at least that many times. For repeat markers that specify only a minimum number of times of execution, repeats continue beyond the minimum number for as long as the button on the remote is held down, or for one more repeat beyond this if so determined by the semantics of a variation, in accordance with 12.3 below.

==Expressions==
===Description===
An expression signifies a value that is derived from other values by calculation. It consists of names, numbers and bitfields connected by standard symbols for arithmetic and logical operations, the whole being enclosed in parentheses. Bitfields in expressions evaluate to the value of the binary form to which they translate, as described in 1.4, rather than the binary form itself.

Operators have their usual order of precedence and parentheses may be used inside an expression to change the order of precedence by grouping. The permitted operators and rules for evaluation are described in 9.3 below for completeness. Since numbers in IRP notation are purely sequences of digits, explicit negative values have to be represented by an expression in which the operator is the unary minus sign, e.g. (-12).

In the execution model, names that occur in an expression take the values that are bound to them in the global environment at the time that the expression is evaluated. The significance of this is that assignments within an IRstream can change the bindings during the course of execution. A simple example of the use of an expression is provided by the Panasonic protocol

{37k,432}<1,-1|1,-3>(8,-4, 2:8,32:8,D:8,S:8,F:8,(D^S^F):8,1,-173)+

in which (D^S^F) is an element of a bitfield and denotes the bitwise exclusive-or of the values of the device code D, subdevice code S and function code F.

When a colon appears in an expression, it is a separator in a bitfield. A minus sign that follows a colon is a prefix to the second primary item of a bitfield, as described in 5.1. A minus sign that is not preceded by a primary item must be a unary minus or a syntactic error. All other minus signs are binary operators, again unless they are a syntactic error. Note that a minus sign following a bitfield is preceded by a primary item, namely the final primary item of the bitfield.

Some examples of unusual but valid expressions are:
*(~A:-B:C), the value of the bitfield ~A:-B:C
*(-A:-B:C), unary minus followed by the bitfield A:-B:C
*(A - - 1), binary minus followed by unary minus, equivalent to (A + 1)
*(A:B-C:D), difference of the values of the bitfields A:B and C:D
*(A:(B-C):D), value of a single bitfield with the expression (B-C) as middle primary item
*(A:(B-C:D)), value of a bitfield whose second primary item is the difference of B and the value of the bitfield C:D.

===Formal syntax===
<pre>expression = "(", bare expression, ")";
bare expression = inclusive or expression;
inclusive or expression = [inclusive or expression, "|"], exclusive or
expression;
exclusive or expression = [exclusive or expression, "^"], and expression;
and expression = [and expression, "&"], additive expression;
additive expression = [additive expression, ("+" | "-")], multiplicative
expression;
multiplicative expression = [multiplicative expression, ("*" | "/" | "%")],
exponential expression;
exponential expression = [exponential expression, "**"], unary expression;
unary expression = ["-"], (primary item | bitfield);</pre>
(* "primary item" is defined in 5.2 above *)

===Semantics===
An expression is a type of primary item that determines an integer value through arithmetic and logical operations performed on the values of primary items or bitfields. Within an expression the value of a bitfield is given by translating it into a binary form in accordance with 5.3 and then taking the value of that binary form considered as an integer in binary notation. This value will be a non-negative integer unless the binary form is of infinite length with all leading bits beyond a cartain point being ones, in which case it is interpreted as a negative integer in 1's complement form.

The binary operations "+", "-", "*", "/" denote the arithmetic operations of addition, subtraction, multiplication and division of integers and "%" denotes the modulo (remainder) operation. The division and modulo operations a/b and a%b are only defined when b is nonzero and they are defined such that the inequalities and equation

0 <= a%b < abs(b), a = (a/b)*b + a%b

are always true, where abs denotes absolute value. This means that in all cases, a/b is the greatest integer that is not greater than the algebraic quotient.

The binary operation "**" denotes exponentiation, i.e. a**b denotes a raised to the power b. The unary operation "-" denotes change of sign, i.e. multiplication by -1.

The operations "&", "|", "^" denote the logical operations AND, OR and EXCLUSIVE OR performed bitwise on the binary representations of the values of the operands, where the binary representation of a negative integer is its usual 1's complement form (but with a potentially infinite number of bits, i.e. with enough bits such that using more bits does not give a different answer). As examples:

(-4)^1 = -5, (-4)^(-1) = 3.

:Note: John Fine's original postings say explicitly that he wants to keep the C and C++ shift operators ">>" and "<<" out of the expression syntax. He points out that X<<3 is equivalent to X*8 and X>>3 to the bitfield X::3. With integer division as defined above, X>>3 is also equivalent to X/8, a better parallel with X*8, regardless of whether X is positive or negative.

:John does not otherwise say what operators should be allowed in expressions but the above seems a reasonable list judging by his examples. I have included exponentiation as it permits an equivalent of a variable shift, since X<<Y and X>>Y are equivalent to X*2**Y and X/2**Y (as "**" has a higher precedence than "*" and "/"). The bitfield X::Y can be used instead of X>>Y but there is no other equivalent of X<<Y.

Evaluation of expressions should be performed in steps with each step being the action of the appropriate binary operator on two values (or the unary minus on one value) in accordance with the parsing syntax. This ensures correct operator precedence since the precedence of the operators, and left-to-right evaluation of expressions such as (x - y - z) that have multiple operators of equal precedence, is incorporated into the formal syntax. For reference, the order of precedence is the usual one. In
decreasing order it is:

<pre>unary -
**
*, /, %
+, -
&
^
|</pre>

There is only one environment in IRP notation, the global environment, but assignments may change the
value assigned to a name during the course of execution of the protocol. Expressions are evaluated in the
context of the environment as it is at the point of execution of the expression in the execution model.

==Definitions==
===10.1 Description===
Definitions occur only in the Definitions section of a protocol, which consists of a list of individual definitions separated by commas and enclosed in curly brackets. A definition uses an equals sign to bind a bare expression, i.e. an expression without the enclosing parentheses, to a name as a shorthand form that can be used elsewhere in the protocol, including in other definitions. A definition is never evaluated as such. In the execution process its expression is evaluated at the time that the name is evaluated, in the context of the global environment at that time.

Definitions are commonly used to express the calculation of a checksum. A simple example is the Somfy protocol:

{35.7k}<308,-881|669,-520>(2072,-484,F:2,D:3,C:4,-2300)+{C=F*4+D+3}

The plus sign before the definitions section is the repeat marker for the preceding IRstream. This is equivalent to

{35.7k}<308,-881|669,-520>(2072,-484,F:2,D:3,(F*4+D+3):4,-2300)+

A somewhat more complicated example is the DirecTV protocol:

{38k,600,msb}<1,-1|1,-2|2,-1|2,-2>(5,(5,-2,D:4,F:8,C:4,1,-50)+) {C=7*(F:2:6)+5*(F:2:4)
+3*(F:2:2)+(F:2)}

This also shows the use of bitfields in expressions. Enclosing the bitfields in parentheses, as here, is an aid to readability but it is not required by the syntax, which is valid and unambiguous if the parentheses are removed. The Somfy protocol remains easily understood when the expression is substituted for the defined name. The expression is sufficiently complicated in the DirecTV protocol that it would become unwieldy to express the protocol without the use of a definition for the checksum.

Whenever the name occurs as a primary item, as does the C in the IRstream of this example, the expression (with its enclosing parentheses) could be substituted for the defined name so the definition is merely a convenience. One case, however, where a definition provides the only way of using an expression is in a duration or extent. Durations and extents both allow the use of names or numbers but not expressions, so to use an expression it must be bound to a name and that name used in its place.

The definitions list in the Definitions section is read and executed from left to right. This is significant only if two different bare expressions are assigned to the same name. There is no valid reason to do so, but this rule eliminates the ambiguity of which one takes precedence. The right-most one takes precedence as the execution of a definition will supersede any existing binding of the defined name.

Definitions must not be self-referential, either directly or indirectly, as this leads to infinite recursion in the processing of definitions in the execution model. Two examples in which this happens are

{X=F+X} and {X=F+Y, Y=X+D}

The problem it causes is easily seen by repeatedly substituting the corresponding expression for each defined name, as discussed above. Neither the syntax nor the execution model prevents this error, but it would lead to an infinite loop during execution. This is an issue for the protocol writer, just as any programming language can give rise to infinite loops in a badly written program.

===Formal syntax===
<pre>definitions = "{", definitions list, "}";
definitions list = | definition, [",", definitions list - ];
(* This allows a definitions list to be empty but the definitions list in
the second alternative cannot be empty. This is the significance of the
minus sign, which is the EBNF exception symbol. What is excluded by
the exception is what follows it, which in this case is empty. *)
definition = name, "=", bare expression;</pre>

===Semantics===
The definitions in a definitions list are executed from left to right. Execution of a definition creates a binding in the global environment. It binds the name on the left of the equals sign to the bare expression on the right, superseding any existing binding of that name.

==Assignments==
===Description===
Assignments, like definitions, change the binding of names during the course of execution of a protocol and they have exactly the same form. The distinction is that a definition binds a name to an unevaluated expression, an assignment binds it to the value of an expression. They are distinguished from one another by context. Assignments occur only within IRstreams, definitions only within the Definitions section of a protocol.

When an assignment is executed, the bare expression is evaluated in the global environment as it is at that time. The resulting value is then bound to the name on the left of the assignment, so changing the environment. This makes an assignment such as

T = T + 1

valid. It increments the value bound to T. Because it is self-referential, this would not be valid as a definition.

Assignments are often used in conjunction with definitions, such as to be able to use the same checksum formula in different circumstances within the same protocol. An example is the OrtekMCE protocol, which can be written as

{38.6k,480}<1,-1|-1,1>((P=0,4,-1,D:5,P:2,F:6,C:4,-48m), (P=1,4,-1,D:5,P:2,F:6,C:4,-48m)+,
(P=2,4,-1,D:5,P:2,F:6,C:4,-48m){C=3+D:1+D:1:1+D:1:2+D:1:3+D:1:4+P:1+P:1:1+
F:1+F:1:1+F:1:2+F:1:3+F:1:4+F:1:5}

The checksum C is three more than the sum of the binary digits in D, P and F together, or put more simply, is three more than the number of "1" bits in their values. It is quite a complicated expression and is used in each of the three IRstreams of the protocol. It can be considered, alternatively, as one IRstream in which the value of P is 0 on the first transmission, 1 on all others except the last one and 2 on the last transmission, which is sent after the button has been released. But it is not only P that changes, so also does the value of the checksum C since this involves P. The use of an assignment means that the value of P in the global environment changes in the course of execution of the protocol, and as C is recalculated from its defined expression each time it is referenced, the correct value is transmitted each time.

Another use of assignments is to represent a toggle that keeps a fixed value throughout the signal from each button press but which toggles between one button press and the next. An example of this behaviour is the RC5 protocol:

{36k,msb,889}<1,-1|-1,1>(T=T+1,(1:1,~F:1:6,T:1,D:5,F:6,^114m)+).

Only two values are set by a button press, the device code D and function code F. The value of T is maintained by the remote control, incremented on each button press and used to generate the toggle bit T:1 in the IRstream. This is an example of persistence of the global environment, a concept that forms part of the execution model of section 14. The internal state of the remote changes when a button is pressed, and the new state persists until the next button press changes it again. This is modelled by having bindings in the global environment remain in existence until explicitly changed by the pressing of a button on the conceptual remote of the execution model. The value of T is unknown when the protocol is executed, but whatever it may be, it will be one greater on the next button press.

As a final example of the use of assignments, consider the AirAsync protocol:

(37.7k,840)<1|-1>(N=0,(1,B:8:N,-2,N=N+8)+)

The value of N is 0 on the first transmission of the repeating IRstream but increases by 8 on each successive transmission. The bitfield B:8:N is therefore the least significant 8 bits on the first transmission, the next 8 on the next transmission, and so on. The sequencing rule is lsb, so the result is that the value of B is sent in lsb order, eight bits at a time, on successive repeats, however large may be the value of B. This protocol represents standard asynchronous transmission with one start bit, eight data bits and two stop bits.

===Formal syntax===
<pre>assignment = name, "=", bare expression;</pre>

===Semantics===
When an assignment is executed, the bare expression is evaluated according to the current state of the global environment. The resulting value is then bound to the given name, so changing the environment.

==Variations==
===Description===
The OrtekMCE protocol considered in 11.1 had an IRstream that varied systematically between its first
transmission, its last one and all others in between. The first one is sent on button down, the middle ones
while the button remains held down and the last one on button up. A number of other protocols share this
pattern, yet more share a pattern of variation between button down and button held but without a
transmission on button up.

These patterns can be represented in IRP notation without the need for any new structure, as the example of the OrtekMCE protocol showed. When the protocol is written out in full in the form given in 11.1, it does however obscure the fact that the three different IRstreams are all small variations of one another. The use in IRstreams of a variation both simplifies the appearance of the protocol and clarifies this relationship between the various transmissions.

A variation consists of two or three alternative bare IRstreams given together, each enclosed in square brackets as delimiters. Typically the bare IRstreams will consist only of a single item, but this is not required. On first transmission (button down) the first alternative is used, on middle transmissions (button held) the second alternative is used, and if a third alternative is present then on button up the IRstream is sent once more with the third alternative being used. The OrtekMCE protocol can therefore be written in the simpler form

{38.6k,480}<1,-1|-1,1>([P=0][P=1][P=2],4,-1,D:5,P:2,F:6,C:4,-48m)+{C=3+D:1+D:1:1+
D:1:2+D:1:3+ D:1:4+P:1+P:1:1+F:1+F:1:1+F:1:2+F:1:3+F:1:4+F:1:5}

A simpler example is the CanalSat protocol:

{55.5k,250,msb}<-1,1|1,-1>([T=0][T=2],1:1,D:7,S:6,T:2,F:7,-89m)+

Here there is no dependent checksum, the protocol could be written without the use of T as

{55.5k,250,msb}<-1,1|1,-1>((1:1,D:7,S:6,0:2,F:7,-89m), (1:1,D:7,S:6,2:2,F:7,-89m)+)

but use of a variation emphasises that there is only a small systematic difference between the first and subsequent frames.

There are a few protocols in which one IRstream is transmitted on button down, a related one on button up, but nothing while the button is held. This typically corresponds to buttons of a mouse, where holding down a mouse button does nothing but there is an effect on button up. To meet this situation, an alternative with an empty IRstream signifies that the remainder of the IRstream should be skipped. An example is the variant of the Sejin protocol that corresponds to the buttons of a three-button mouse. This is:

{38.8k,310,msb}<-1|1>(<8:4|4:4|2:4|1:4>([F=B][ ][F=0],3,3:2,(-D):6,B:2,0:16,E:4,C:4,-3600u)+)
{C=((-D):4:2+4*(-D):2+F+E)&15}

In this, D is the device code but its negative is sent when the mouse part of the protocol is used. B numbers the buttons, 1,2 or 3. On button up the IRstream is sent with B=0, the same for all buttons as the button down part has shown which button is concerned. The checksum C is calculated with either the button number or 0 as appropriate. The middle alternative [ ] indicates that nothing is sent while the button is held.

===Formal syntax===
<pre>variation = 2*alternative, [alternative];
alternative = "[", bare irstream, "]";</pre>

===Semantics===
A variation is a permitted type of irstream item that operates in conjunction with a repeat marker for the irstream that contains it. If the repeat marker specifies an indefinite number of times of execution with a given minimum then the state, held or released, of the button of the remote control affects the effect of the variation but this is not so if the number of repeats is definite.

With a definite number in the repeat marker, on the first execution of the IRstream the bare IRstream of any first alternative is executed. If a variation is encountered with three alternatives then on the last execution of the IRstream, provided this is not also the first, that of the third alternative is executed. In all other cases that of the second alternative is executed.

The same holds with an indefinite number in the repeat marker but an additional rule is required to determine the actual number of times that the IRstream is executed. The IRstream is repeatedly executed for as long as the button is held down at the start of an execution. Repeats also continue beyond that, if necessary, until all of the following are true:
*the minimum number given in the repeat marker has been performed;
*at the end of the last execution the button is no longer held;
*the successive executions satisfy the rule for a fixed number of repeats with that fixed number being the actual number.

Note the implicit nature of these conditions. It is not possible to tell whether an execution is going to be the last one if the button was still held when it commenced, so if a variation with three alternatives is encountered, it may be necessary to perform one further execution after the button has been released in order to meet the third condition.

If the bare irstream of an alternative is empty then its execution consists of skipping the remainder of the IRstream and proceeding to its next execution.

==Names and numbers==
===Description===
For the sake of completeness, names and numbers are defined formally in this section. They were defined informally in 1.2. All that is needed to add here is that the presence of assignments or variations may mean that a name may not evaluate to the same value on each occasion that it is evaluated. A name bound to a value evaluates to the value that is bound to it in the global environment at the time that it is evaluated. A name bound to a bare expression is evaluated by evaluating that expression.

===Formal syntax===
<pre>number = "0" | nonzero digit, {digit};
number with decimals = number, [".", digit, {digit} ];
digit = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9";
nonzero digit = digit - "0";
name = letter, {letter | digit};
letter = "A"|"B"|"C"|"D"|"E"|"F"|"G"|"H"|"I"|"J"|"K"|"L"|"M"|"N"|"O"|"P"
|"Q"|"R"|"S"|"T"|"U"|"V"|"W"|"X"|"Y"|"Z";</pre>

===Semantics===
The value of a number is the non-negative integer represented by its sequence of digits in decimal notation.

The value of a number with decimals is the non-negative real number represented by its sequence of digits and optional decimal point in decimal notation.

The value of a name is the value bound to it at the time of evaluation, or is the result of evaluating the expression bound to it at that time, as the case may be.

==Execution model==
===Introduction===
The level of recursion permitted in the IRP notation is sufficiently great that a formal execution model is needed to ensure a consistent interpretation of some of its more complex possibilities. This section provides such a model in a natural language formulation.

The execution environment conceptually contains a timer and a carrier generator. All processes are considered as instantaneous other than TRANSMIT, which turns on the carrier generator for a specified time, and WAIT, which waits for a specified time. Processes are synchronous, so that any process that follows a TRANSMIT or WAIT is not performed until the TRANSMIT or WAIT is completed.

The execution model has two aspects, static and dynamic. The static aspect describes such things as how expressions are interpreted and how bitfields are converted to binary forms. Collectively the operations of the static aspect are described as evaluation. They are performed by the operator EVALUATE. The dynamic aspect describes such things as how IRstreams are processed to produce the flashes and gaps of the signal. The dynamic procedures are performed by the operator PROCESS. Both aspects are covered by the semantics specified in the previous sections but this execution model puts them together to form a coherent whole.

Processing is initiated by the pressing of a button on a conceptual remote control. The button press binds certain names to values in the global environment. These correspond to the Device Code and OBC or the like, the values that are set externally by means outside the scope of the IRP notation. Also set externally is the duty cycle of the carrier generator. This is typically 33% or thereabouts, but again it is outside the scope of the IRP notation. With these external processes performed, the button press initiates the procedure "PROCESS protocol".

The global environment is considered to have a continuing existence between button presses. The external process of binding names to values when a button is pressed changes the binding of those names but all other names are considered to have bound values as well, albeit possibly unknown values. This feature of the model permits names to be used that are neither bound to a value by a button press nor bound to an expression by a definition. This is the mechanism by which certain types of toggle can be represented. Some protocols have a toggle bit that alternates in value between successive button pressings, to enable successive presses of the same button to be distinguished from a single longer press. When a user picks up the remote and presses a button, the state of the toggle that will be used is unknown. What is known is that it will be different on the next press. The remote has "state", i.e. it maintains internal variables such that the same user action at different times may not result in precisely the same effect. Persistence of the global environment permits modelling of remotes with "state".

===Data Structures===
[[IRP Execution Model]]

Main Page

2025-10-01T14:49:42Z

Barf: /* Slingbox */

Welcome to the JP1 community Wiki site. A collaborative website relative to the JP1 community to which anyone can contribute!

Anyone can create an account, and edit or add pages. The user administration is completely autonomous; you cannot log in with a user-id from another system.

==JP1 Guides==
*[[JP1_Introduction|Introduction to JP1]]
*[[The History of the JP1 Project]]
*[[JP1 - Just How Easy Is It?]]
*[[The WHAT and WHY of JP1]]
*[[Creating A Better Upgrade]]
*[[JP1 Cables]]
*[[Building the Arduino Interface for older remotes]]
*[[Hacking JP1 Remotes]]
*[[Extenders (an FAQ)]]
*[[Infrared Signals]]
*[[How to use RIDgen]]
*[[IrScrutinizer Guide]]
*[[ToadTog]]
*[[Getting started with Xsight and Nevo]]
*[[Xsight_Disassembly]]
*[[Importing Foreign IR Remotes in RemoteMaster]]
*[[Using URC6440 and OARUSB04G Remotes with Linux]]

==Manuals==
*[[Manuals|Remote Manuals]]
*[[Remote Master Manual]] (not complete)
*[[IR Help]]
*[[Protocol Builder]]
*[[IR Scope and IR Widget User's Guide]]
*[[DecodeIR]]
*[[AIRWidget and IRScope Operating Instructions]]
*[[The 3660 family|The 3660 family of remotes]]
*[[INT-422|Programming an INT-422-4 Remote]]
*[[WAV FILES]]

==General Remote Guides==
*[[Manual Programming - 9xx Commands]]
*[[Manual Programming - Sky Remotes]]
*[[Master Reset Instructions]]
*[[Modem Upgrade Procedure]]
*[[The Correct Learning Procedure]]
*[[RemoteChart]]

==Website Archives==
The following are official websites that are no longer active, that have been archived here at hifi-remote.com.
*[http://www.hifi-remote.com/radioshack/ Radio Shack remotes page]
*[http://www.hifi-remote.com/rcinfo/ Radio Shack's www.rcinfo.com site]
*[http://www.hifi-remote.com/ofaold/ One For All backup #1]
*[http://www.hifi-remote.com/ofausa/ One For All backup #2]
*[http://www.hifi-remote.com/ofa-int/ One For All International]
*[http://www.hifi-remote.com/urc/ UEI's cable remotes page]
*[http://www.hifi-remote.com/hag/ Hudson Access Group's OFA page]

The following are user-maintained sites that are no longer available.
*[http://www.hifi-remote.com/wasser/ John Wasser's old OFA site]
*[http://www.hifi-remote.com/ziggr/ Zig's Amazing IR Remote Control Page]
*[http://www.hifi-remote.com/huras/ Dave Huras's X10 and OFA Page]
*[http://www.hifi-remote.com/sony/ Rob Humphrey's Sony codes page]

==Slingbox==
*[[How to Install a Custom Remote onto the Slingbox]]
*[[Customising the Remote Image on your Slingplayer]]
*[[How to Create Custom Remote Controls and use them on your Slingbox]]
*[http://www.hifi-remote.com/forums/viewforum.php?f=19 Slingbox forum] (presently not operational)
*[https://github.com/hifiremote/Slingbox Slingbox files]

==Resources==
*[https://sourceforge.net/projects/controlremote/ Remote Master Repository]
*[https://www.oracle.com/java/technologies/downloads/ Java Runtime Download (for Remote Master)]
*[[IRP Notation]]
*[[DecodeIR]]
*[[Working With Pronto Hex]]
*[[JP1 versus Harmony]]
*[[Technical Documents]]
*[[Glossary]]
*[http://www.hifi-remote.com/forums JP1 Forums] (defunct)
*[http://www.hifi-remote.com/forums/dload.php JP1 Files] (defunct)
*[http://www.hifi-remote.com/jp1/lookup JP1 Lookup Tool]
*[https://www.youtube.com/watch?v=ubrq9Pr3Y1Y&list=PLXmyroJbN9CAxc6vADS4iiXQT3fp0c-Iq JP1 "How To" Videos]

==References==
*[http://www.hifi-remote.com/forums/dload.php?action=file&file_id=2367 Lutron Master List]
*[http://www.hifi-remote.com/forums/dload.php?action=file&file_id=9545 Onkyo Master List]
*[http://www.hifi-remote.com/forums/dload.php?action=file&file_id=508 Pioneer Master List]
*[http://www.hifi-remote.com/forums/dload.php?action=file&file_id=383 Sanyo Projector Master List]
*[http://www.hifi-remote.com/sony/ Sony Master List]
*[http://www.hifi-remote.com/forums/dload.php?action=file&file_id=9582 Yamaha Master List]

==Forums==
*[http://www.hifi-remote.com/forums Old Forum (now defunct)]
*[https://www.remotecentral.com/forums RemoteCentral (now defunct)]
*[https://forum.harctoolbox.org Experimental]
*[https://www.avsforum.com/forums/remote-control-area.93 Remote Control Area subforum within AVS forums]

==Links==
*[https://github.com/hifiremote/ Hifiremote organization at Github]
**[https://github.com/hifiremote/deviceupgrades JP1 device upgrades for RemoteMaster or KeymapMaster]
**[https://github.com/hifiremote/Extenders Collection of extenders, from hifi-remote.com's file section]
**[https://github.com/hifiremote/Tools JP1 Tools and programs] (except Remotemaster that is hosted on SourceForge)
**[https://github.com/hifiremote/Slingbox Slingbox files from JP1]
**[https://github.com/hifiremote/ReplayTV Files and programs used to add IR blaster codes to ReplayTV units]
**[https://github.com/hifiremote/Protocols A variety of information relating to protocols]
**[https://github.com/hifiremote/Miscellaneous-JP1 The "Miscellaneous" files from the JP1 File section]
**[https://github.com/hifiremote/HelpFiles Help and "how to" docs, especially useful for beginners.]
*[https://www.harctoolbox.org Harctoolbox.org Harctoolbox]
*[https://github.com/bengtmartensson/IrScrutinizer IrScrutinizer Repository]

File:IRHelpChp6TL4.gif

2025-10-01T14:43:17Z

Barf: Barf uploaded File:IRHelpChp6TL4.gif

File:IRHelpChp6TL3.gif

2025-10-01T14:42:34Z

Barf: Barf uploaded File:IRHelpChp6TL3.gif

File:IRHelpChp6TL2.jpg

2025-10-01T14:41:47Z

Barf: Barf uploaded File:IRHelpChp6TL2.jpg

File:IRHelpChp6TL1.jpg

2025-10-01T14:40:45Z

Barf: Barf uploaded File:IRHelpChp6TL1.jpg

File:PBRMsetup.jpg

2025-10-01T14:35:17Z

Barf: Barf uploaded File:PBRMsetup.jpg

File:Codes4-txt2.jpg

2025-10-01T14:34:34Z

Barf: Barf uploaded File:Codes4-txt2.jpg

File:Codes4-txt.jpg

2025-10-01T14:33:47Z

Barf: Barf uploaded File:Codes4-txt.jpg

File:Pbass1.jpg

2025-10-01T14:31:35Z

Barf: Barf uploaded File:Pbass1.jpg

File:IR-learned-signals.jpg

2025-10-01T14:30:35Z

Barf: Barf uploaded File:IR-learned-signals.jpg

Protocol Builder

2025-10-01T14:29:04Z

Barf: /* Entering Signal Specifics Into PB */

'''Protocol Builder''' (aka "PB") is a spreadsheet based program that is used to create new executors for JP1 remotes. An 'executor' is a piece of code used by a JP1 remote to replicate an infared protocol. The documents below describe how you can capture a new signal using your JP1 learning remote and build a new upgrade.

Before you start, you should download this [http://www.hifi-remote.com/forums/dload.php?action=file&file_id=2304 zip file] which contains some sample files referred to in the following docs.

==Signal Specifics==
First, look at the signals in the "Learned Signals" tab of IR.exe, then cut & paste the timing data over to a text editor (such as Notepad, etc). It would be helpful if the text editor allows you to perform global edits. The version of Notepad that ships with Windows 2000 does allow global edits, but earlier versions do not, in which case it might be a better idea to use Wordpad. Copy the data in the order that the buttons appear in the Learned Signals tab so you don't lose track of which button each set of data belongs to.

[[Image:IR-learned-signals.jpg]] 
'''Image 1 – the “Learned Signals” tab in IR'''

When you have completed copying the data, you should have a file somewhat like the codes1.txt file included in this [http://www.hifi-remote.com/forums/dload.php?action=file&file_id=2304 zip file]. The next step is to try and clean up the signal times. IR tends to report the signal times very exactly, but in reality most devices have quite a large level of tolerance for signals not being exactly what they should be. So, what we need to do now is try and round all the numbers up or down so all similar numbers are actually the same. For example, if you see times like +988, +995, +1015, etc, they are all really the same time and can be rounded to +1000.

When you have finished rounding the numbers, you should end up with a file somewhat like codes2.txt in the [http://www.hifi-remote.com/forums/dload.php?action=file&file_id=2304 zip file]. The data in this file should be viewed as pairs, where a pair is a grouping of a ON time and an OFF time. The ON times are represented by positive numbers and the OFF times are represented by negative numbers. The next step is to attempt to identify the following pairs:

*Lead-in pair
*Logical "zero" pair
*Logical "one" pair
*Lead-out pair

Looking at the data in codes2.txt, you will notice that the first pair is "+5000 -3000" and then there is a mixture of the following two pairs "+1000 -1000" and "+1000 -3000", then eventually you will find a pair with a much bigger OFF time, and then the whole signal repeats. In all of these examples, the signal is repeated 2 times, and each repetition includes the lead-in and lead-out pairs.

Therefore, here's the data for the afore mentioned pairs:

*Lead-in pair = "+5000 -3000"
*Logical "zero" pair = "+1000 -1000"
*Logical "one" pair = "+1000 -3000"
*Lead-out pair = (to be determined)

Actually, there is no exact science to deciding which of the two variable pairs is the logical "one" and "zero" pairs. Generally speaking, the "zero" pair will have smaller times than the "one" pair, but even that's just a guess. Bottom line, it doesn't really matter. In fact, UEI gets it wrong more often than they get it right in their protocols.

So, now that we've guessed the "one" and "zero" pairs, let's edit the file so we can see the binary. My preferred way to do this is to edit the strings like this:

"+1000 -1000" --> 0^
"+1000 -3000" --> 1^

I put the ^ character after the number so that if I later decide I want to reverse the pairs and make the first pair the logical "one" I can edit all the 0^ and 1^ strings and reverse them. When you're done editing the "one" and "zero" pairs, you should end up with a file somewhat like codes3.txt You'll notice that I've inserted a space in the middle of the binary string, breaking it into two groups of 8. In the binary world, 8 is considered a round number, so you'll often find that the total length of the binary signal is a multiple of 8. In this case you should notice that the second string is constant for all the signals, so we can consider this to be our "device code". The first string is different for all the signals, so we can consider this to be our "command code".

While units of 8 are the most common, there are always exceptions to every rule. Your immediate goal is to determine which bits are constant for every signal and which bits vary. The more learned signals you have, the greater the chance that you will get this right.

At this point you should examine the data and see if you can spot any "compliments". A compliment code is where the data is the same as the previous data, only inverted. (Inverted, or complimented, means that if the original bit was 0, the new bit should be 1, and vice versa).

Normally, you would probably find that the lead-out pair is constant for all signals, but in this case it varies, which leads me to suspect that it's calculated as a result of the total signal length. Every "zero" pair lasts 2000 uSecs and every "one" pair lasts 4000 uSecs, so given that there are 16 bits in each of these signals, the data portion of the signal will last a minimum of 32000 uSecs (which would mean that the binary was all zeroes). Each "one" in the signal would add an additional 2000 uSecs to the total. If you calculate the total duration of the data portion of the signal and add in the lead-out times, you'll find that each signal lasts for a total of 98000 uSecs.

==Entering Signal Specifics Into PB==
Now, let's move on to the PB spreadsheet itself, when you first open it, it looks like this:

[[File:PB-sheet1.jpg]] 
'''Image 2 - Protocol Builder'''

And you thought KM was scary! Don't worry, just like KM this spreadsheet is actually easier to use than it looks. Now we have to start entering the data that we have just worked on.

#'''Description:''' Very short description of the signal, our signals were for a "Next Level" cable box, so let's enter "Next Level".
#'''Remote Type:''' Generally speaking, you should leave this as "S3C8 Generic Code" as this covers most of the remote in use in the JP1 world. If you believe that you need one of the other options, but are not sure which one to use, you should post a question about it in the forums.
#'''Protocol Id:''' Basically, this can be whatever you want, but it's generally a good idea to use an id that is not already established as an official protocol id. You enter the code in hex format where 0 is the smallest value allowed and 1FF is the largest. So, I would advise that you use 1FF for this new protocol.
#'''Frequency:''' Enter the value displayed in IR's "Learned Signals" tab.
#'''Duty Cycle:''' There's no easy way to determine this, so use 30% unless you have reason to do otherwise.
#'''Signal Structure:''' This is determined by how the binary data is laid out. In our example, the command code came before the device code and there weren't any compliments involved, so we should select "cmd-dev".
#'''[Device] Bytes:''' this is the number of bytes of fixed data. In our example we found one fixed byte, so we will enter 1.
#'''Bits/Dev:''' this is how many bits are in each fixed byte. The max value is 8, which is also the most common answer. In our example, there are 8 fixed bits.
#'''[Command] Bytes:''' this is the number of bytes of variable data. In our example we found one variable byte, so we will enter 1.
#'''Bits/Cmd:''' this is how many bits are in each variable byte. The max value is 8, which is also the most common answer. In our example, there are 8 fixed bits.
#'''[Repeat] Value:''' this is the minimum number of times the signal should repeat. It appears from the data in our examples, that the signal should repeat at least 2 times.
#'''Type:''' when set to 'Minimum', item 10 above controls the minimum number of repeats, supposedly 'Forced' makes the signal repeat that many times only, but I understand this this setting is not reliable.
#'''Hold:''' this determines if the signal repeats, and if so, under what circumstances. "Yes" means the whole signal will repeat for as long as the button is held down. "No" means the signal does not repeat at all. Selecting "Ch+/-, Vol+/-, FF, Rew" will cause the signal to only repeat when those buttons are used, otherwise it will not repeat. The final selection is "No data bits in repeat", which is outside of the scope of this document. All of the data in our limited sample would suggest that our signal does not need to repeat when the button is held down, so "no" would be the logical selection. However, the CH+ and CH- buttons did repeat, so "Ch+/-, Vol+/-, FF, Rew" is probably the right selection. If in doubt, try each of them and see which works.
#'''['1' Burst] ON (uSec):''' this is the ON time for the logical "one" pair (which is the positive number), so for our example we will enter 1000.
#'''OFF (uSec):''' this is the OFF time for the logical "one" pair (which is the negative number), so for our example we will enter 3000.
#'''['0' Burst] ON (uSec):''' this is the ON time for the logical "zero" pair (which is the positive number), so for our example we will enter 1000.
#'''OFF (uSec):''' this is the OFF time for the logical "zero" pair (which is the negative number), so for our example we will enter 1000.
#'''[Lead-In Style]:''' this determines whether there is a lead-in burst pair for this signal, and if so, whether it appears once only or in every repetition of the signal. In our example, the lead-in is present in every repetition, so "Same Every Frame" is the correct selection.
#'''[Lead-Out Style]:''' this determines whether the lead-out portion is a burst pair or just a single OFF time. "[-LO]" means it's just a single OFF time. "[LI,-LO]" means it's a pair which uses the Lead-in pairs ON time. "[OneOn, -LO]" means it's a pair that uses the logical "one" pairs ON time. "[LI], [OneOn, -LO]" means that the lead-in pair is repeated and it's followed by a "[OneOn, -LO]" pair. In our example, the lead-out ON time was 1000, which matches the ON time for the logical "one" pair, so we should select "[OneOn, -LO]".
#'''[Lead-Out] OFF (uSec):''' this is the lead-out OFF time. (see below)
#'''OFF as Total:''' when "no" is selected, the OFF time entered above will be used for every signal. When "yes" is selected, the total duration of the data portion of the signal is calculated and subtracted from the time entered above to determine the actual lead-out time. In our example, we found that the lead-out does indeed vary based on the total length of the signal and we also found that the total length of the signal is always 98000 uSecs, so we should select "yes" here and enter 98000 as the Lead-Out OFF time.

You will notice that I skipped over some of the selections available in PB, any skipped item should be left set to it's default value. Use of these skipped items is outside of the scope of this document, where I'm trying to keep things somewhat simple.

With all the above selections made, your PB screen should look like this…

[[Image:PB-sheet2.jpg]] 

Your new protocol code is in the upper right corner ready for you to use. Finally, you should save this code by using the SAVE button, just in case you want to re-load it in the future to make changes. You should also post the saved file in the Yahoo file section.

Next step is creating an upgrade to use this new protocol, for that we need to switch over to KM.

==Adding Assembler==
Sometimes complex protocols can't be created by just filling in the blanks on the worksheet. In those cases, we need to use assembly language code to manipulate the data or IR signal in special ways.

Each of the microprocessors, the S3C8, P8-740, HCS08 and 6805, that have been used in the various JP1 remotes have their own language. Mike England, (mr_d_p_gumby), has designed PB to work with all of these assembly languages. Text files with the syntax for each of the processors PB covers are included in the PB zip file. More comprehensive information on the assembly languages can be found in the data sheets for the various microprocessors. Check the [http://www.hifi-remote.com/wiki/index.php?title=Technical_Documents Technical Documents Area] for the microprocessor documentation.

The JP1 remotes are divided into 7 family types. The family type can be described by the microprocessor, the base address, and vector locations. PB can handle multiple sources on the Assembler sheet. There can be one set of source code for each of the seven types of JP1 remotes. Each section of source code *must* begin with the REMOTE directive specifying the remote type. The valid remote types are: HCS08, S3C8 , S3C8+, SST, 6805-RC16/18 , 6805-C9, P8/740, and NONE.

Note: The argument "(NONE)" may be used with the REMOTE directive to turn off assembly of the entire section.

===Getting started===

Using the generated protocol code is one of the easiest ways to get started with your assembly code. Fill in the timing data on the setup page. Make sure the “use assembled code” is unchecked.
#Copy the generated protocol code.
#Paste the protocol code into the decode area. As a best practice use “Paste Special Values” option from the menu, otherwise you may inadvertently paste protection into the cells.
#Press the Decode button and the Disassembly tab will appear.

[[Image:pbass1.jpg]]

You now have the starting assembly code for the selected processor.

Once you transfer the disassembly to the assembler tab you can add your own code. Its assumed that you have a working knowledge of the assembly language, and this document is just going to help you understand the PB interface.

Below is a screen capture of the assembler tab. As with KM the pale yellow area indicates read-only areas. The dark yellow areas designed for user input except column H which is overwritten with the error code. Column B: is the address, and Column C: is the Object Code. Column D: is the Label, Column E is the Operator, Column F: is the Operator Arguments, Column G is the Comments and Column H: contains the error codes for the given line.

You may also notice that the example below shows the source code for two different remote classes, the s3c8+ and the HCS08.

[[Image:PBAss2.jpg]]

In PB, the source code for the assembler is not case-sensitive, with one exception: literal quoted text strings used in a define-byte statement. White-space (spaces, etc.), unless part of a literal quoted text string, is ignored.

In general terms, the op code is entered in the Op column, and any arguments for the op code are entered in the OpArg column, with arguments separated by commas. Labels are entered in the Labels column. A colon may be entered after the label name, but is not required. Comments may be entered in the Comments column. No special syntax is required for comments, but a leading semicolon should be used if you expect to copy the code from Excel to a text file for use with another assembler. Column A is used for special purposes. The most common use for column A is to comment out an entire row by entering a semicolon.

Numeric values are interpreted as decimal by default. Hexadecimal values may be used, and can be indicated either with a leading '$' or trailing 'H'. Ex: $ABCD, ABCDH

For the S3C80 assembler, register references can be indicated with a leading 'R', and working registers indicated with a leading 'W'. Register references are always hexadecimal. Register-pair references using the 'RR' or 'WW' prefix are accepted, but not enforced.

For example (assuming RC0 is W0), these are all equivalent as far as the assembler is concerned: RC0, RRC0, W0, WW0.

Simple expressions may be used. The expression evaluator can only do addition, subtraction, multiplication and division, using the operators '+', '-', '*' and '/', respectively. Nesting with parenthesis is allowed. Results of an expression evaluation are truncated to an integer value.

Names of symbolic labels (and constants) must follow these rules:
#The first character must be a letter (A to Z)
#The remaining characters must be letters (A to Z), digits (0 to 9), or an underscore ('_').
#The name cannot evaluate to a hex value. For example, the name 'A001H' is invalid.
#For the S3C8 assembler, the name cannot look like a register reference. For example, 'R01' and 'W01' are invalid.
#Names are not case sensitive, so 'XYZ' is the same as 'xyz'

===Assembly Tab User Interface===

====[Clear Sheet]====
This button clears the Assembler sheet and sets the REMOTE directive on the first row to match the remote type selected on the Setup sheet. Any previously assembled binary code is erased.

====[Load Generated Code]====
This button clears the Assembler sheet and sets the REMOTE directive on the first row to match the remote type selected on the Setup sheet. The protocol code generated by the settings on the Setup sheet is then disassembled and placed on the Assembler sheet. Any previously assembled binary code is replaced by the generated code.

This makes it very convenient to use protocol-builder's Setup sheet to set the basic timing parameters as a starting point for creating a new protocol.

====[Load Disassembly] button====
This button is only enabled when the Disassembly sheet contains disassembled code that was obtained by using the [Decode] button on the Setup sheet. When used, this button clears the Assembler sheet and sets the REMOTE directive on the first row to match the remote type selected by the decoder. The disassembled protocol code is then placed on the Assembler sheet. Any previously assembled binary code is replaced by the decoded protocol code.

This makes it very convenient to use protocol-builder's decoder to disassemble an existing protocol for use as a starting point for modifying a protocol.

====[Assemble] button====
This button causes the assembler to execute and assemble the source code on the Assembler sheet. The assembler fills in the Addr and Code columns with the address and binary code respectively. If an error occurs on a row, the assembler will put an error message in the Errors column. On the row containing the REMOTE directive, the Errors column will be filled in either with the number of errors, or (if no errors) the number of bytes used by the protocol.

If the assembly completes with no errors, the resulting binary code is available for use on the Setup sheet. Checking the [Use Assembled Protocol Code] checkbox will cause the assembled code to be placed in the Protocol Code block instead of the normal PB-generated code.

Note that the assembled code is remote-type-specific, so only those remote types for which assembled code is available will be able to use the assembled code. If the assembled code has any errors, it will not be available. If required, PB can perform vector translation, vector offset or data offset processes on the assembled code before placing it in the Protocol Code block.

If source code for more than one type of remote is present on the Assembler sheet, the assembler processes all of them individually. An error in the source for one type of remote will not affect the assembly of source for other types. There can be only one set of source code for each of the five remote types.

====[Use pre-defined constants] checkbox====
If checked, then certain pre-defined constants are loaded prior to execution of the assembler. These constants are defined such that you can override them by redefining them in your source, if desired. Below is a list of the constants that will be defined and the values for each of the remote types.

6805-
Constant HCS08 S3C8 S3C8+ SST RC16/18 6805-C9 P8/740
-------- ----- ---- ----- --- ------- ------- ------
DCBUF $60 R03 R03 $5A $5A $5A $5D
PD00 $6A R12 R12 $67 $67 $67 $6A
PD01 $6B R13 R13 $68 $68 $68 $6B
PD02 $6C R14 R14 $69 $69 $69 $6C
PD03 $6D R15 R15 $6A $6A $6A $6D
PD04 $6E R16 R16 $6B $6B $6B $6E
PD05 $6F R17 R17 $6C $6C $6C $6F
PD06 $70 R18 R18 $6D $6D $6D $70
PD07 $71 R19 R19 $6E $6E $6E $71
PD08 $72 R1A R1A $6F $6F $6F $72
PD09 $73 R1B R1B $70 $70 $70 $73
PD0A $74 R1C R1C $71 $71 $71 $74
PD0B $75 R1D R1D $72 $72 $72 $75
PD0C $76 R1E R1E $73 $73 $73 $76
PD0D $77 R1F R1F $74 $74 $74 $77
PD0E $78 R20 R20 $75 $75 $75 $78
PD0F $79 R21 R21 $76 $76 $76 $79
PD10 $7A R22 R22 $77 $77 $77 $7A
PD11 $7B R23 R23 $78 $78 $78 $7B
PD12 $7C R24 R24 $79 $79 $79 $7C
PD13 $7D R25 R25 $7A $7A $7A $7D
PD14 $7E R26 R26 --- --- --- ---
PD15 $7F R27 R27 --- --- --- ---
PD16 $80 --- --- --- --- --- ---
PD17 $81 --- --- --- --- --- ---
PD18 $82 --- --- --- --- --- ---
PD19 $83 --- --- --- --- --- ---
PD1A $84 --- --- --- --- --- ---
PD1B $85 --- --- --- --- --- ---
PD1C $86 --- --- --- --- --- ---
PD1D $87 --- --- --- --- --- ---
PD1E $88 --- --- --- --- --- ---
PD1F $89 --- --- --- --- --- ---
PF0 $A2 R28 R28 $7B $7B $7B $7E
PF1 $A3 R29 R29 $7C $7C $7C $7F
PF2 $A4 R2A R2A $7D $7D $7D $80
PF3 $A5 R2B R2B $7E $7E --- $81
PF4 $A6 R2C R2C $7F $7F --- $82
DBYTES $A9 R10 R10 $66 $66 $66 $69
CBYTES $AA R11 R11 --- --- --- ---
FLAGS $B3 R00 R00 $57 $57 $57 $5A
XMITIR $FF5F $0133 $0146 $C02F $01AF $0183 $FF00

'---' above indicates the constant will not be defined.

The constant DCBUF refers to the first byte of the device-command buffer used during protocol execution, and is ten bytes long in all of the remote types. Other bytes within the buffer may be referenced with an offset notation, i.e., DCBUF+2 refers to the third byte in the buffer.

The constant DBYTES defines the address of the byte containing the number of device ("fixed") bytes within DCBUF. Similarly, CBYTES defines the address of the byte containing the number of command ("variable") bytes within DCBUF.

FLAGS defines the address of the byte that contains the bit-toggling bit(s).

The constant XMITIR is the address of the standard IR engine call for the remote.

====[Add comments to Protocol Data Bytes] checkbox====
If checked, then the next time the assembler is executed, it will replace any comments on rows defining protocol flag or data bytes with a description of what the values represent to the IR engine. This is only done if the assembly completes with no errors.

====[Reformat Sheet] button====
If, as a result of copying & pasting, etc. the format of the Assembler sheet gets corrupted, you can use this button to return the formatting to normal.

As distributed, the Assembler sheet is set to Protected mode. While most operations needed in creating source code can be performed with protection in effect, some functions are not available, such as search-and-replace. You are free to turn off the sheet protection (Tools menu, Protection, Unprotect Sheet) if you prefer, but be careful not to alter the contents of rows 1 through 9, and do not insert or delete any columns in the yellow area. (Rows 1 through 5 are hidden.) The Reformat Sheet button assumes that you have not inserted or deleted any of these rows.

====[Insert Row] and [Delete Row] buttons====
These buttons operate whether sheet Protection is in effect or not. The number of rows selected before clicking the button determines how many rows are inserted or deleted. Entire rows need not be selected; just selecting rows in one column will suffice. Only the yellow-colored columns will be affected, and selection of cells outside of the yellow areas will prevent the button from operating. No Undo is available after using these buttons.

===Assembler directives===
The assembler understands several special directives. These are listed below with a description of their use.

====Remote====
Each set of source code for a remote must begin with the REMOTE directive in the Op column, and a valid remote type in the OpArg column. The first row of the Assembler sheet will already have the REMOTE directive entered, and a drop list of valid remote types is available in the OpArg column. This information will have to be entered manually for any additional sets of source code.

Hint: Using the Alt-R key will enter the REMOTE directive on the current row (where cursor is), and create a droplist. Using Alt-R again will remove the droplist.

There can be only one set of source code for each of the seven remote types. If an invalid remote type is specified, the entire block of code (until the next REMOTE directive or the end of the source code is encountered) will not be assembled.

The valid remote types are:

*HCS08 - This selects the 68HCS08 assembler, and sets the starting assembly address to $0100. The resulting binary code is applicable to remotes using the HCS08 type on the Setup sheet.

*S3C8 - This selects the S3C80 assembler, and sets the starting assembly address to $8000. The resulting binary code is applicable to remotes using the S3C8 (Old) type on the Setup sheet. PB can also apply the vector translation process to make the assembled binary code available for use on S3C8 (New) remotes when S3C8+ code is not available.

*S3C8+ - This selects the S3C80 assembler, and sets the starting assembly address to $FF00. The resulting binary code is applicable to remotes using the S3C8 (New) type on the Setup sheet. PB can also apply the same type of vector translation used in KM & RM to make the assembled binary code available for use on S3C8 (Old) remotes.

*SST - This selects the 68HC05 assembler, and sets the starting assembly address to $0100. The resulting binary code is applicable to remotes using the SST type on the Setup sheet. PB can also apply a vector translation process to make the assembled binary code available for use on 6805-RC16/18 remotes when 6805-RC16/18 code is not available.

*6805-RC16/18 - This selects the 68HC05 assembler, and sets the starting assembly address to $0100. The resulting binary code is applicable to remotes using the 6805-RC16/18 type on the Setup sheet. PB can also apply the same type of data and vector offsets used in KM & RM to make this binary code available for use on remotes with non-standard data or vector locations. The data locations must be manually indicated in the source by putting an underscore character in column A. PB can also apply a vector translation process to make the assembled binary code available for use on SST remotes when SST code is not available.

*6805-C9 - This selects the 68HC05 assembler, and sets the starting assembly address to $0100. The resulting binary code is applicable to remotes using the 6805-C9 type on the Setup sheet.

*P8/740 - This selects the P8/740 assembler, and sets the starting assembly address to $0132. The resulting binary code is applicable to remotes using the P8/740 type on the Setup sheet.

*(NONE) - This disables assembly of the entire section. Since there can only be one active section for each remote type, this value may be used to deactivate different versions for the same remote type.

====EQU (or EQ)====
The EQU directive is used to define symbolic constants. The symbol name must be placed in the Label column, and must follow the naming rules for labels (see above). The OpArg column must contain an expression. The expression will be evaluated and the result assigned as the value of the symbol.

Seperate constants for hi-byte and lo-byte values must be defined in cases where the bytes of a 16-bit value need to be referenced in the source. (The expression evaluator is limited to basic add, subtract, multiply and divide operations, and cannot and, or, xor or shift.)

You can override the pre-defined constants added by the assembler when the checkbox option is active (see above) by redefining them in the source. Once defined in the source, you cannot redefine a constant a second time.

Symbolic constants and labels share the same namespace, so you may not use the same name for a label and a constant.

====DB or BYTE====
This directive generates binary output from one or more byte values supplied in the OpArg column. Each byte value must be separated with a comma. Examples:

DB $55,73H,27

Literal quoted text strings may also be defined with the DB or BYTE directive. The ASCII values of the text are output as byte values in the binary code.

DB "Text string"

====DW or WORD====
This directive generates binary output from one or more 16-bit word values supplied in the OpArg column. Each word value must be separated with a comma. Examples:

DW $5555,7373H,65530

Note that the HCS08, S3C80 and 68HC05 assemblers output word values in high-byte, low byte order, wheras the P8/740 assembler outputs word values in the opposite order. Use caution when using words to define protocol data values with the P8/740 assembler; it may be best to use byte definitions to prevent errors.

====XORG====
The XORG directive sets the target location counter. The OpArg column
must contain an expression.

Initially, the target location counter is the same as the current location counter. The XORG directive is useful when writing code that will be executed at a different address than the assembled code. While generally not used in writing protocols, it might be useful to authors of special protocols to be used with extenders.

The target location counter affects calculation of relative branches, and values of labels.

The target location counter may be restored to match the current location counter by setting it to '.'. (The dot special symbol returns the value of the current location counter.)

====WREG, WREGL and WREGH====
These directives are only valid for the S3C80 assembler. The OpArg column must contain an expression, or the special arguments ON or OFF.

The WREG directives used with an expression argument tell the assembler which registers are to be used as the working registers for purposes of assembling the code. WREG sets both the low and high working registers, while WREGL and WREGH set the low and high registers separately. The assembler will accept any values from 0 to $F0 ($F8 for WREGL & WREGH) where the lower three bits are zero. At the start of assembly, the initial setting of the working registers is equivalent to WREG $C0.

The assembler will use the working register setting to automatically convert register references to working register references. For some instructions, there are forms that will accept either normal register references or working register references, with the latter using fewer bytes in the instruction, and usually executing faster. In cases where you want to use the longer instruction form, you will need to use the WREG special argument OFF. The assembler will then not allow any working register conversion for those instructions. To return the assembler to normal, use the WREG special argument ON.

For example, with the default settings (WREG set to ON and WREG set to $C0), the following are all equivalent, and produce the same binary code:

=00C0 SYMB1 EQU C0H
09 01 LD R01,W0
09 01 LD R01,RC0
09 01 LD R01,C0H
09 01 LD R01,SYMB1

With WREG set to OFF, the same source produces the longer form of the
instruction:

=00C0 SYMB1 EQU C0H
WREG OFF
E4 C0 01 LD R01,W0
E4 C0 01 LD R01,RC0
E4 C0 01 LD R01,C0H
E4 C0 01 LD R01,SYMB1
WREG ON

Some or all of the address modes of the following instructions are affected by the WREG ON/OFF setting:
LD, INC, ADC, ADD, AND, CP, OR, SBC, SUB, TCM, TM, XOR

====OTHER/MISCELLANEOUS====

'''The '.' symbol'''
The dot ('.') symbol returns the value of the current location counter. The current location counter specifies the address at which the instruction/data bytes will reside. You may use the dot in any expression. For example, the following code jumps to the branch instruction in an endless loop:

JR . (S3C80)
BRA . (HCS08, 68HC05 & P8/740)

'''Column A'''
Column A of the Assembler sheet is used for special purposes. Below
are the currently available uses for this column.

#A semicolon (;) anywhere in the text in column A will cause the entire row to be treated as a comment. This is useful if you are trying several different approaches and want to retain the source code for other approaches for reference while developing a new approach.
#Under some circumstances, protocol binaries are subjected to a vector translation or vector offset process. Calls and Jumps to certain addresses are altered to refer to different addresses in this process. While it is unlikely, it is possible that data bytes or other code within the protocol might appear to be a call or jump instruction. If this occurs, you can flag a specific row so that it cannot be considered for this process by putting a dot in column A. This will cause a dot to be used as a delimiter between the bytes in the code column, which will prevent the vector translation/offset process from changing those bytes. The dot is only effective if more than one byte is generated on the row where it is used. Code exported to KM or RM (see below) will also contain the dot.
#Under some circumstances, protocol binaries need to be subjected to a data offset process. References to certain data addresses are then altered to refer to different addresses in this process. At this time, only the 6805-RC16/18 remote types require this. References to the protocol data (PDxx) and protocol flag (PFx) bytes must be flagged with an underscore in column A to allow this process to recognize the references. This will cause an underscore to be used as a delimiter between the bytes in the code column. Code exported to KM or RM (see below) will also contain the underscore.

==Adding to Keymap Master (KM)==
In KM, you should select "Manual Settings" as the protocol and you should cut & paste the protocol code generated by PB into the Notes panel. (You can still enter notes there too, if you like, KM will find the protocol). You should also select OBC for the button codes.

When you select "Manual Settings" a new set of options appears in the lower left hand side of the screen.

'''PID:''' this is the protocol id that you used in PB.
'''2nd Cmd Byte:''' this is only relevant for signals with more than 1 byte of variable data.
'''Signal Style:''' Sometimes this one is a crap-shoot. Take a look at the binary signals shown in the codes3.txt file. Ideally, you would notice that the numbers increase from the left (LSB) or the right (MSB) when you’re looking at the data for the numeric buttons, but that's not exactly the case here. However, you should notice that the last 2 bits on the right stay constant whereas the bits on the left change constantly, therefore I'm going to make the call that this protocol is LSB. Use of one of the -COMP styles implies that you got the ‘1’ and '0' pairs reversed, which is not typically the case for a protocol that you created yourself.
'''Bits/Dev:''' this should match what you selected in PB.
'''Bits/Cmd:''' this should match what you selected in PB.

So far, so good, but now you need to enter the functions and their OBCs in the Functions sheet, so you need to figure out what they are, and you still need to figure out what to enter as the device code for this upgrade.

codes4.txt (from the [http://www.hifi-remote.com/forums/dload.php?action=file&file_id=2304 zip file]) is a cleaned up version of codes3.txt with just one line per signal. You should open this file using Excel. Select "fixed width" and make sure all the columns are treated as text. You should end up with a sheet that looks like this...

[[Image:codes4-txt.jpg]] 

The first two columns show the lead in times and the last two show the lead out times, so you can delete those. As we determined that the signal style is LSB, in order to convert the binary signals to decimal, we will need to read them backwards. The easiest way to reverse the order of binary patterns in Excel is to use the MID function. The following formula would reverse the order of an 8 bit binary pattern in cell A1:

= mid(a1,8,1)& mid(a1,7,1)& mid(a1,6,1)& mid(a1,5,1)& mid(a1,4,1)& mid(a1,3,1)& mid(a1,2,1)& mid(a1,1,1)

Assuming that the two columns of binary are now in columns A and B, you could enter this foruma in column C and then copy it to column D, which would give you two columns of binary where the data from columns A and B are reversed.

You could then use the following formula in column E to convert the command codes to decimal:

=bin2dec(c1)

You could then copy this formula to column F in order for it to convert the device codes to decimal. You should end up with a sheet that looks like this (I added column headings to help illustrate the fields). (I have included this spreadsheet in the [http://www.hifi-remote.com/forums/dload.php?action=file&file_id=2304 zip file], it’s called codes4.xls)

[[Image:codes4-txt2.jpg]] 

Therefore, the device code for our upgrade is 58, and the OBCs for the numeric buttons are as shown.

The Setup sheet in KM should look like this...

[[Image:PB-KM-sheet.jpg]]

==Adding to Remote Master (RM)==

There are several ways to get a custom protocol into a RM.

You can create a custom protocols.ini entry, but if the official JP1 protocols.ini is not changed, the RDMU file will be unusable by the rest of the community. If you have Microsoft Excel you can create a KM upgrade and then open it in RM. You can also create a self-contained RDMU with a custom protocol. If you have Excel it is recommended that you create a KM sheet because it can be accessed by both KM and RM, but there are still advantages to doing development work in RM . RM lets you work directly with the hex, which can do the OBC and EFC calculations for you.

In this document we are going to show you how to create a self-contained RDMU file. It is an easy process but not intuitive.

In RM, you begin by accessing the New Manual Protocol option from the Advanced Menu. This was known as the “Manual Protocol” option in earlier versions of RM. In RMIR, after a remote image has been loaded (by opening a *.RMIR or *.IR file, downloading from a remote, or by File\New\RemoteImage), use the Protocols tab and click New.

[[Image:PBRMsetup.jpg]]

In RM 2.02 Alpha 10a, when the manual settings screen comes up, the “Import Protocol Upgrade” is not enabled until you touch the Protocol Code box.

[[Image:PBRMsettings.jpg]]

Pressing the Import Protocol Upgrade button will import a formatted protocol that was copied to the clipboard in PB. In this case the clipboard contained this protocol from PB.

Upgrade protocol 0 = 01 FF (HCS08) Dimmer (PB v4.01)
20 11 1F 4A 01 84 01 00 08 09 D8 03 63 00 D2 09
F3 41 D2 CC FF 5F
End

RM analyzes the protocol, finds the protocol ID to be 01FF and the processor type to be HCS08 and inserts it into the proper protocol code area. RM also analyzes the protocol to see how many device and function bytes are called for.

Note: If the protocol code next to any given processor is enabled (black instead of gray), you can manipulate the protocol bytes directly by double clicking on protocol code.

If you click on the HCS08, you can see the disassembly for the protocol upgrade in the right hand panel. A quick glance at the disassembly can be helpful in making sure that you had the correct data on the clipboard.

[[Image:PBRMsource.jpg]]

In the lower left corner of the manual settings page there will be an area where you can tell RM how to handle data. This area will look different depending on the protocol that you imported. You can tell RM if the data is LSB- Least significant bit first. You can tell RM whether the data needs to be Comp (complemented 0 is 1 and 1 is 0). Although the number of bits per devices and commands have already been specified in PB, the user can overide this if a complex protocol needs to perform some bit manipulation from within the executor. If the protocol requires multiple bytes per function, you can specify the command index, which tells RM whether the OBC portion is the first hex byte or the second hex byte.

[[Image:PBRMdevicedata.jpg]]

Once the protocol settings are complete, click OK. You must now change the PID on the Setup tab to match your protocol update. (If using RMIR, first change to the Devices tab, and click New.) It will be at the bottom of the protocol list. The code will only appear on the list if a protocol has been entered for the processor type of the chosen remote.

[[Image:PBRMpickPID.jpg]]

Note: The custom protocol MUST be selected on the Setup tab before you can make any changes to the custom protocol's manual settings.

To revisit the manual settings page, click Advanced\Edit Protocol. This will open the protocol currently selected on the Setup tab, so be sure your custom protocol is selected. (In RMIR, if an upgrade is using the custom protocol, click the protocol name or PID on the Devices tab.)

If you have already worked on the function page and then realize you need to make corrections to the Manual Settings Page, it is important that you check your “Primacy” settings before making the changes, so that you don’t corrupt all your data. Any changes to LSB, Comp, # of bits or Command Index will change the way calculations are performed. The Primacy setting lets you determine whether you want the OBC or EFC/Hex to be preserved when you change the calculation method. The Primacy setting is found in the Advanced Menu in RM, as shown below.

[[Image:PBRMprimacy.jpg]]

So far, so good, but now you need to enter the functions in the Functions sheet, so you need to figure out what they are. You can calculate the OBC's or you can enter the hex that you need and let RM compute the OBC's.

File:PB-sheet2.jpg

2025-10-01T14:27:22Z

Barf: Barf uploaded File:PB-sheet2.jpg

File:PB-sheet1.jpg

2025-10-01T14:27:04Z

Barf: Barf uploaded File:PB-sheet1.jpg

File:PBRMsource.jpg

2025-10-01T14:26:45Z

Barf: Barf uploaded File:PBRMsource.jpg

File:PBRMsettings.jpg

2025-10-01T14:26:25Z

Barf: Barf uploaded File:PBRMsettings.jpg

File:PBRMprimacy.jpg

2025-10-01T14:26:09Z

Barf: Barf uploaded File:PBRMprimacy.jpg

File:PBRMpickPID.jpg

2025-10-01T14:25:48Z

Barf: Barf uploaded File:PBRMpickPID.jpg

File:PBRMdevicedata.jpg

2025-10-01T14:25:23Z

Barf: Barf uploaded File:PBRMdevicedata.jpg

File:PB-KM-sheet.jpg

2025-10-01T14:25:03Z

Barf: Barf uploaded File:PB-KM-sheet.jpg

File:PBAss2.jpg

2025-10-01T14:24:38Z

Barf: Barf uploaded File:PBAss2.jpg

Importing Foreign IR Remotes in RemoteMaster

2025-10-01T14:21:39Z

Barf: /* Example */

= Ultra-short version =

* Perform an "Girr" export from IrScrutinizer to a file,
* Open the above created file in RemoteMaster. Perform 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 [https://wiki.harctoolbox.org/index.php?title=Importing_Foreign_IR_Remotes_in_RemoteMaster&oldid=561 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 [http://harctoolbox.org/IR-resources.html 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
[http://www.hifi-remote.com/forums/dload.php?action=category&cat_id=4 JP1 device update repository] (see also
[http://www.hifi-remote.com/forums/dload.php?action=file&file_id=8487 the master list] and
[http://www.getzweb.net/jp1/ 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.

= Solution =

The [https://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 [[IrScrutinizer_Guide | 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.

= 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 [[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:

[[Image:Screenshot%20from%202022-05-14%2022-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.

[[Image:Screenshot%20from%202022-05-14%2021-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.

[[Image:Screenshot%20from%202022-05-14%2021-15-25.png]]

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

[[Image:rm_opening_file.png]]

Next screenshot shows RMDU after the import:

[[Image:Screenshot%20from%202022-05-14%2021-32-52.png]]

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

[[Image:Screenshot%20from%202022-05-14%2021-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.

= Remarks =

== Import ict files from IrScope ==

RMDU can also import ("open") ict files from the program [[IR_Scope_and_IR_Widget_User's_Guide|IrScope]].

= 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.

Importing Foreign IR Remotes in RemoteMaster

2025-10-01T14:19:38Z

Barf: /* Solution */

= Ultra-short version =

* Perform an "Girr" export from IrScrutinizer to a file,
* Open the above created file in RemoteMaster. Perform 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 [https://wiki.harctoolbox.org/index.php?title=Importing_Foreign_IR_Remotes_in_RemoteMaster&oldid=561 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 [http://harctoolbox.org/IR-resources.html 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
[http://www.hifi-remote.com/forums/dload.php?action=category&cat_id=4 JP1 device update repository] (see also
[http://www.hifi-remote.com/forums/dload.php?action=file&file_id=8487 the master list] and
[http://www.getzweb.net/jp1/ 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.

= Solution =

The [https://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 [[IrScrutinizer_Guide | 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.

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

[[Image:Screenshot%20from%202022-05-14%2022-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.

[[Image:Screenshot%20from%202022-05-14%2021-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.

[[Image:Screenshot%20from%202022-05-14%2021-15-25.png]]

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

[[Image:rm_opening_file.png]]

Next screenshot shows RMDU after the import:

[[Image:Screenshot%20from%202022-05-14%2021-32-52.png]]

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

[[Image:Screenshot%20from%202022-05-14%2021-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.

= Remarks =

== Import ict files from IrScope ==

RMDU can also import ("open") ict files from the program [[IR_Scope_and_IR_Widget_User's_Guide|IrScope]].

= 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.

Importing Foreign IR Remotes in RemoteMaster

2025-10-01T14:17:50Z

Barf: /* Import ict files from IrScope */

= Ultra-short version =

* Perform an "Girr" export from IrScrutinizer to a file,
* Open the above created file in RemoteMaster. Perform 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 [https://wiki.harctoolbox.org/index.php?title=Importing_Foreign_IR_Remotes_in_RemoteMaster&oldid=561 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 [http://harctoolbox.org/IR-resources.html 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
[http://www.hifi-remote.com/forums/dload.php?action=category&cat_id=4 JP1 device update repository] (see also
[http://www.hifi-remote.com/forums/dload.php?action=file&file_id=8487 the master list] and
[http://www.getzweb.net/jp1/ 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.

= Solution =

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

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.

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

[[Image:Screenshot%20from%202022-05-14%2022-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.

[[Image:Screenshot%20from%202022-05-14%2021-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.

[[Image:Screenshot%20from%202022-05-14%2021-15-25.png]]

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

[[Image:rm_opening_file.png]]

Next screenshot shows RMDU after the import:

[[Image:Screenshot%20from%202022-05-14%2021-32-52.png]]

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

[[Image:Screenshot%20from%202022-05-14%2021-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.

= Remarks =

== Import ict files from IrScope ==

RMDU can also import ("open") ict files from the program [[IR_Scope_and_IR_Widget_User's_Guide|IrScope]].

= 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.

File:09 USBConnectorCover.jpg

2025-10-01T14:13:03Z

Barf: Barf uploaded File:09 USBConnectorCover.jpg

Location of USB connector and slot to receive rubber protective cover

File:04 OpenConnector.jpg

2025-10-01T14:11:57Z

Barf: Barf uploaded File:04 OpenConnector.jpg

Disconnecting touchscreen ribbon from PCB connector

File:08 KeyActuators&DisplayHolder.jpg

2025-10-01T14:10:50Z

Barf: Barf uploaded File:08 KeyActuators&DisplayHolder.jpg

Xsight key actuators in front shell with display assembly beside it

File:07 DisplayConnector.jpg

2025-10-01T14:10:28Z

Barf: Barf uploaded File:07 DisplayConnector.jpg

Xsight Touch dispaly connector on solder side of PCB

File:06 DisplayRibbonConnector.jpg

2025-10-01T14:09:58Z

Barf: Barf uploaded File:06 DisplayRibbonConnector.jpg

Side view of attached display ribbon in Xsight touch

File:05 RemoveScrews.jpg

2025-10-01T14:09:34Z

Barf: Barf uploaded File:05 RemoveScrews.jpg

Removing PCB screws from Xsight Touch

File:03 EmitterDiodes&RFantenna.jpg

2025-10-01T14:09:00Z

Barf: Barf uploaded File:03 EmitterDiodes&RFantenna.jpg

Top end of Xsight Touch PCB

File:02 OpenCase.jpg

2025-10-01T14:07:34Z

Barf: Barf uploaded File:02 OpenCase.jpg

Xsight Touch opened

File:01 DisassemblyRemoveScrews.jpg

2025-10-01T14:04:17Z

Barf: Barf uploaded File:01 DisassemblyRemoveScrews.jpg

Shows location of screws to be removed in first step of Xsight disassembly

File:10 ChargingContacts.jpg

2025-10-01T14:02:16Z

Barf: Barf uploaded File:10 ChargingContacts.jpg

XSight Touch charging contacts and corresponding openings in back shell.

File:IRTool.jpg

2025-10-01T13:59:38Z

Barf: Barf uploaded File:IRTool.jpg

ToadTog

2025-10-01T13:56:39Z

Barf:

ToadTog is a [[Special Protocols|Special Protocol]] that can be used to simulate [[Special Protocols#Discrete Codes|discrete on/off codes]] for devices that don't have them, and it can also be used to simulate a power toggle button for devices that only have discrete on/off codes.

==Basics==
ToadTog comes pre-installed into all the extenders, and it can be installed as a stand alone app in non-extended remotes. Once installed, you program it via the "Special Protocols" tab in [[JP1 - Just How Easy Is It? - RM-IR Version|RMIR]]. To get a ToadTog started, go to the "Special Protocols" tab and click on "New".

===Bound Key===
When you program a ToadTog, you are basically programming a keymove, and just like with a keymove, you need to pick the button and the device mode where you want the ToadTog to reside. The ToadTog itself is basically a macro where you perform different commands based on whether the toggle is on or off. Now let's take a look at the fields in RMIR.

===Parameters===
#'''Type''' - Select 'ToadTog'
#'''Toggle #''' - you have a choice of 8 bits (labeled 0 thru 7) to use where each bit can be used to keep track of the state of a different device.
#'''Condition''' - there are 4 options here:
##'''Force On''' - use this when you want to set the selected toggle bit on
##'''Force Off''' - use this when you want to set the selected toggle bit off
##'''Toggle''' - use this when you want to toggle the bit
##'''Test Only''' - use this when you want to test the toggle bit and perform different functions based on its setting, without actually changing the setting.

===Macro Definition===
The look of this part of the screen changes slightly based on which option is selected for Condition.

{| class="wikitable sortable" border="1" cellpadding="5"
| align="center" width=100 style="background:#f0f0f0;"|''' Condition'''
| align="center" width=100 style="background:#f0f0f0;"|''' Box1'''
| align="center" width=100 style="background:#f0f0f0;"|''' Box2'''
| align="center" width=100 style="background:#f0f0f0;"|''' Box3'''
|-
| Force On ||Available Keys||Already On||Off->On
|-
| Force Off ||Available Keys||On->Off||Already Off
|-
| Toggle ||Available Keys||On->Off||Off->On
|-
| Test Only ||Available Keys||On||Off
|}

#'''Available Keys''' - just like when creating a regular macro, these are the buttons that are available to be included in this ToadTog macro.
#'''On->Off''' - include the buttons that you want executed when the toggle switches from On to Off
#'''Off->On''' - include the buttons that you want executed when the toggle switches from Off to On
#'''Already On''' - include the buttons that you want executed when the toggle is already on (typically you will leave this blank)
#'''Already Off''' - include the buttons that you want executed when the toggle is already off (typically you will leave this blank)
#'''On''' - this is for the 'Test Only' option, list the buttons that you want executed when the toggle is on
#'''Off''' - this is for the 'Test Only' option, list the buttons that you want executed when the toggle is off

==Creating Discrete Codes==
The best way to understand what a ToadTog is and how you can use it is to see some examples, so here I am going to describe how to set up discrete on and off functions for a device that only has a power toggle, then I will describe how to create a toggle for a device that only has discrete on/off buttons.

This example assumes that you have a working setup code (or upgrade) where the POWER button works and you don't have anything programmed to SHIFT-POWER. We will be using "Shift Cloaking" here, which is the concept where the shifted version of each button performs the same task as the un-shifted version of the button. If you have the power function assigned to a different button, or you have a macro or something programmed to the SHIFT-POWER button, adjust these instructions accordingly.

===Discrete On===
For this first ToadTog, we are going to create a Discrete On function which you can then use in macros, etc. In the following screen shot you can see that I've assigned it to the DiscreteON phantom button, but you can use any button you like. I don't have anything selected when the device is already on, and when it's switching from Off to On, the only button in the macro is the SHIFT-POWER button, which will toggle the power.

[[Image:Toadtog1.jpg]]

===Discrete Off===
In the following screen shot you can see that I've assigned it to the DiscreteOFF phantom button, but you can use any button you like. I don't have anything selected when the device is already off, and when it's switching from On to Off, the only button in the macro is the SHIFT-POWER button, which will toggle the power.

[[Image:Toadtog2.jpg]]

===Power Toggle===
If you don't re-program the POWER button, the ToadTog won't be able to keep track of the state of the device, so here will will reprogram it so that when it switches from On to Off, or vice versa, the toggle bit gets flipped accordingly. If the toggle ever gets out of sync, you can re-sync it by manually pressing the SHIFT-POWER button yourself.

[[File:Toadtog3.jpg]]

==Creating a Power Toggle==
Sometimes a device only has ON and OFF buttons and doesn't have a POWER toggle button. ToadTog lets you create a toggle function that you can program onto the POWER button. For this example, I have already programmed the ON and OFF functions to the shifted DiscreteON and DiscreteOFF phantom buttons. I will be using these in the ToadTogs and I will be creating ToadTog functions on the un-shifted DiscreteON and DiscreteOFF buttons that can be used in macros.

[[Image:Toadtog5.jpg]]

===Discrete On===
This ToadTog function just has the DiscreteON button in the Off-On section. The reason we need this is so we can keep track of the state.

[[Image:Toadtog6.jpg]]

===Discrete Off===
This ToadTog function just has the DiscreteOFF button in the On->Off section. The reason we need this is so we can keep track of the state.

[[Image:Toadtog7.jpg]]

===Power Toggle===
Finally for the toggle function, we will use DiscreteON when the device is off, and DiscreteOFF when the device is on.

[[Image:Toadtog8.jpg]]

File:Toadtog8.jpg

2025-10-01T13:55:30Z

Barf: Barf uploaded File:Toadtog8.jpg

ToadTog screen shot

File:Toadtog7.jpg

2025-10-01T13:54:54Z

Barf: Barf uploaded File:Toadtog7.jpg

ToadTog screen shot

File:Toadtog6.jpg

2025-10-01T13:54:36Z

Barf: Barf uploaded File:Toadtog6.jpg

ToadTog screen shot

File:Toadtog5.jpg

2025-10-01T13:54:12Z

Barf: Barf uploaded File:Toadtog5.jpg

ToadTog screen shot

File:Toadtog3.jpg

2025-10-01T13:53:36Z

Barf: Barf uploaded File:Toadtog3.jpg

ToadTog screen shot

File:Toadtog2.jpg

2025-10-01T13:53:10Z

Barf: Barf uploaded File:Toadtog2.jpg

ToadTog screen shot

File:Toadtog1.jpg

2025-10-01T13:52:45Z

Barf: Barf uploaded File:Toadtog1.jpg

ToadTog screen shot

Working With Pronto Hex

2025-10-01T13:49:53Z

Barf: /* CCF file */

''Written by [http://www.hifi-remote.com/forums/profile.php?mode=viewprofile&u=1350 vickyg2003]''

The Philips Pronto is an expensive upscale universal remote that can be programmed via PC. Pronto hex is a convenient way of sharing infrared information. Many manufacturer's publish their infrared information in Pronto Hex on their websites.

Pronto sites are a very good place to search for signal information.
[http://www.remotecentral.com/ Remote Central], has a large collection of Philips Pronto files submitted by Pronto users.
You’ll find Pronto information in 4 forms, short form hex, long form hex, CCF files, and PCF files.

Glenn Clapp wrote a GUI program called IRTool.exe, which translates Pronto hex into code form. John Fine wrote DecodeIR.DLL, CCF2EFC and DecodeCCF to translate Pronto codes into JP1 terms. Mathdon has added the abilty to use long form pronto Hex in IR, RMIR and IRScope. All the tools will need DecodeIR.DLL to decode the pronto hex into a protocol-device-obc form that can be used to build a new upgrade. Depending on the form you are working with you’ll need to download the following tools.

==The Tools==
[[image:IRTool.jpg|right]]
{|cellpadding="3" style="border-collapse: collapse; border-width: 1px; border-style: solid; border-color: #000"
|-
!style="border-style: solid; width: 200px; border-width: 1px"| File
!style="border-style: solid; width: 400px; border-width: 1px"| Where to download
|-
|style="border-style: solid; border-width: 1px"| [http://www.hifi-remote.com/forums/dload.php?action=file&file_id=8625 DecodeIR.DLL]
|style="border-style: solid; border-width: 1px"| Forums->Downloads->Tools->Main
|-
|style="border-style: solid; border-width: 1px"| [http://www.hifi-remote.com/forums/dload.php?action=file&file_id=8457 IRTool.exe] (requires DecodeIR.DLL) Note: Now you can use IR.EXE, IRScope.EXE or RMIR instead of IRTool to work with Pronto Hex.
|style="border-style: solid; border-width: 1px"| Forums->Downloads->Tools->Programs
|-
|style="border-style: solid; border-width: 1px"| [http://www.hifi-remote.com/forums/dload.php?action=file&file_id=1887 DecodeCCF.exe] (requires DecodeIR.DLL)
|style="border-style: solid; border-width: 1px"| Forums->Downloads->Tools->Programs
|-
|style="border-style: solid; border-width: 1px"| [http://files.remotecentral.com/philipsng/97-1/index.html ProntoEdit NG.exe]
|style="border-style: solid; border-width: 1px"| http://www.remotecentral.com/
|}
'''IR Tool''' is a small program dedicated to translating Pronto hex. Several other JP1 tools, (IR, RMIR and IRScope), will also decode the long Pronto hex. In this example we'll use IR Tool to decode the pronto hex.

#Open IRTool
#Paste your Pronto hex code in the Hex Codes box.
#Press the [Decode Hex] button.
#And a popup with the DecodeIR DLL Results will appear.
#'''If you don’t get this "DecodeIR DLL Results" popup you did not install IRTool in the same directory as DecodeIR.''' This seems to be a common problem among new users.
 
 
 

==Long Form Hex - Raw Code==
'''Tools:'''
*DecodeIR.DLL
*IRTool.exe
 
The long form of pronto hex, is the equivalent of a JP1 learned signal. This is the most common form of pronto hex found in forum posts and manufacturer's web sites. Most types of signals don’t have a short form, so they will be in the raw code format. The long string of pronto hex contains the frequency and all the on/off timing data necessary to send a signal.

The first 4 digits of the Pronto code indicate the form it is stored in.
:0000 - raw oscillated code
:0100 - raw unmodulated code
 
'''Down Arrow:''' 
0000 0070 0000 0032 0080 0040 0010 0010 0010 0030 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0030 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0030 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0030 0010 0010 0010 0030 0010 0010 0010 0010 0010 0030 0010 0010 0010 0010 0010 0030 0010 0010 0010 0030 0010 0010 0010 0010 0010 0030 0010 0030 0010 0aa6
 

==Short Form - Pronto standard formats==
Tools: DecodeIR and (IR or IRScope)

If pronto hex begins with anything other than 0000 or 0100 it’s a short form.

For Pronto Codes that have short forms, each has different rules and descriptions..

Short form
:5000 - Philips RC5
:5001 - Philips RC5x
:6000 - Philips RC6 Mode 0
:7000 - predefined code of variable length
:8000 - index to UDB
:900x - various versions of the NEC protocol.

:Power Off: 900A 006D 0000 0001 874E 39C6

The 900A code in the example is a NEC1 signal

IR or IRScope can decode the 5000, 5001, 6000, 7000, and 900x short form pronto hex as well as the long-form learns. If you need to decode of a short-form that begins with 8000, post your code in the Protocol Decode forum, so an expert can assist you. While there are a few jp1 experts that know the standard Pronto format inside and out, knowledge of the off-beat formats is somewhat limited.

If you want to learn how to decode pronto hex, check out this document.
[http://www.hifi-remote.com/infrared/prontoirformats.pdf http://www.hifi-remote.com/infrared/prontoirformats.pdf]

==CCF file==
Tools: DecodeCCF.exe, DecodeIR.DLL

CCF files are a common Pronto file type. John Fine has a program called DecodeCCF that will put this file into readable form. DecodeCCF works with DecodeIR.DLL. If you drag a CCF onto the DecodeCCF Icon, it will produce a Tab delimited .txt file of the same name. If you open this txt file in a spreadsheet program or a text editor you’ll be able to read the information you need to enter in KeyMaster or RemoteMaster. When its part of a complete system, like this one is, you’ll need to scroll until you find what seems to be your device.
 
[[File:CCF-xls.jpg]]
 
If the Protocol column says something like "Gap-578-1682-32", instead of a Protocol name, you’ll want to run DecodeCCF with an option to display the raw timing data.

The command line syntax to force the timings is:
:DecodeCCF [number of word of raw hex to display] [display raw timings] ccf_file
:example:
:DecodeCCF 24 x foo.ccf

The first argument when there is more than one, is the number of words of raw Pronto hex to display when no decode is found.

The second argument when there are more than two, indicates (by just being there) that you want timing detail displayed on all signals.

The last argument is the ccf file name.

==PCF file==
Tools: ProntoEdit NG, DecodeIR.DLL, IRTool.exe

You might also find information in a PCF file. Currently there are no JP1 tools to do a batch extract of PCF files, so you'll need to retrieve them one at a time with ProntoEditNG. Note the version on the PCF file and then download the corresponding version of ProntoEditNG.

#Start ProtoEditNG
#Open the PCF Ffile. File - > Open Configuration. Navigate to your PCF file
#Highlight the Device you are looking for in the left hand panel of the screen
#In the right hand panel of the screen click on the button you want to investigate. This will open a Buttons Property Sheet
#On the Actions tab double click on the Learned IR code. This will open an Add IR Code window
#Copy all the data from the IR Code window
#Switch to IRTool
#Paste it into IRTool
#Click on the [Decode Hex] button and look at the pop up decode dialog.
#Write down the protocol name, the device number, and if there is one the subdevice number from a string that looks roughly like protocol:device.subdevice:obc For all further signals of the same device usually protocol, device and subdevice stay the same, but if they vary you must note that.
#In an excel sheet or in the functions sheet in the RemoteMaster program put the function name (from the name or icon of the button you navigated to) in one column and the obc in another.
#Repeat for all buttons of that device. If the Pronto hex strings don't give reasonable decodes, you should create a spreadsheet of that includes every function and its pronto hex, and post it to the diagnosis area. Extracting information from a PCF file is tedious, and you should not expect the expert to do this for you.
 
[[File:Prontoedit-NG.jpg]]