JP1 Remotes Wiki - User contributions [en]

JP1 Cables

2026-04-09T12:16:07Z

The Robman: /* Older EEPROM based JP1 remotes */

'''JP1 Interfaces''' 

==Introduction==
In order to use the JP1 software to program your remote, you need an interface to connect the remote to your computer, for which several models now include a USB lead as original equipment. Otherwise you can build your own or purchase one from any one of several vendors. The first JP1 remotes had the same interface. But over the years, new types of JP1 remotes have been introduced which require different interfaces, the latest being USB. 

Lists of JP1 remotes and the type of interface each requires can be found at [[RemoteChart]] 
- and the technical details with a brief history of JP1 interface designs at https://www.hifi-remote.com/forums/dload.php?action=download&file_id=5204

==Interface Types==
UEI is the maker of all JP1 remotes. They change the way they build remotes every so often such that they require a different type of interface. There are currently two basic types of JP1 interfaces: JP1 (Flash) and JP1 (EEPROM). Their older remotes had a separate MCU chip and an EEPROM chip, with all the JP1 activity occurring on the EEPROM chip, so it didn't matter what brand and model of MCU they used because the access to the EEPROM was the same. These remotes are called JP1 or "JP1 (EEPROM)"

Then they switched to using flash based MCU chips, which meant it was no longer necessary to have a separate EEPROM chip. The protocol needed to access the flash chip is completely different to that needed to access the old EEPROM chips. Furthermore, the access method sometimes changes when they switch from one brand of flash chip to another. All these flash based JP1 remotes are called "JP1 (Flash)" (also JP1.x, JP1.1, JP1.2, JP1.1/2, JP1.2/3 or JP1.3). Below are the different types of JP1 remotes, where the type is indicated on the circuit board beside the JP1 connector. However in some cases the connector may be mislabeled.

JP1 indicates a remote with an EEPROM chip. (random signatures) 
JP1.1 indicates a remote with an SST brand flash chip. (CS30xxxx alpha-numeric signatures, only used in 4 Comcast remotes) 
JP1.2 indicates a remote with a Motorola HCS08 flash chip. (1xxx1xxx numeric signatures) 
JP1.3 indicates a remote with a Samsung S3F8 flash chip. (3xxx3xxx numeric signatures) 
JP1.4 indicates a remote with a Samsung S3F8 flash chip.* (3xxxxx numeric signatures) 
JP2 indicates a remote with a Maxim MAXQ622 flash chip.* (2xxxxx numeric signatures) 
JP2 also indicates a remote with a Texas Instruments TI2541 flash chip.* (6xxxxx numeric signatures) 
Mini-USB or Micro-USB indicates a remote which is supplied with a USB cable. 

* JP1.4 and JP2 remotes use a "segment" memory structure, which is completely different that all previous remotes.

Some JP1 (Flash) cables will work with both JP1.1 and JP1.2, but NOT JP1.3, these are usually called JP1.1/2 (Flash) cables.

Some JP1 (Flash) cables will work with both JP1.2 and JP1.3, but NOT JP1.1, these are usually called JP1.2/3 (Flash) cables.

If you have a JP1 (Flash) cable, you can use a special [https://www.diygadget.com/remote-control-accessories/jp1-2-1-3-to-jp1-adapter "JP1 EEPROM Programming Adapter"] to program a JP1 (EEPROM) remote. There are many advantages to this approach since JP1 (Flash) interfaces are compatible with the latest operating systems and I/O ports, and the old style JP1 cables are no longer available.

Some remotes have additional constraints related to the JP1 pins that require special consideration. The Radio Shack 15-133, 134 and 135 models have a smaller opening that the standard plug will not fit. In this case, you can remove the outer clip from the connector and reinforce with super glue, or purchase a cable with a smaller connector or an an adapter with a smaller connector. Some models are JP1 compatible but not "JP1 Ready", having no pins, but pads where the pins should be. In this case an adapter with pogo pins (spring loaded pins for making good contact with the pads) can be used. The connector is held against the pins when communicating with the remote. Some models have no pads at all, so a connector must be soldered to various points on the circuit board, like on the Radio Shack 15-100. Some models, like the URC-6131, require both an EEPROM chip and a connector to be soldered in.

==FTDI and Prolific cables on eBay==
There are many cables on eBay which will function as JP1.x cables. In order for the cable to work, it must have 6 connectors, there are many cables out there with only 4 connectors, these won't work because the RTS line is not exposed. These cables either come with 6 individual connectors, or one flat 1*6 connector. In order to make these ideal JP1.x cables, the supplied connectors should be replaced with a 2*3 DuPont connector. However, the cables with 6 individual connectors will work, it's just a lot more fiddly to connect them to your remote.

Two types of cable that are known to work are the FTDI FT232RL and the Prolific PL2303HXD.

'''PLEASE REMEMBER that the colors are not always the same, so please check what each connector is really for.'''

[[Image:FTDI cable.jpg]] [[Image:Prolific cable.jpg]] 

===Cable color codes===
The pin codes for these cables are ('''NOTE: colors can vary in different cables'''):

'''pin - color - type'''
:1 - (empty):VDD
:2 - RTS (usually Yellow)
:3 - GND (usually Black)
:4 - TXD (usually Green)
:5 - (empty)
:6 - RXD (usually White)
:''CTS (usually Blue, not connected)''
:''5V (usually Red, not connected)''

'''Special note:''' If your remote has a 24-pin S3F80P5X chip, like the URC-2020B0-B1, URC-2025, URC-2060BC0 and URC-625000-04R00, connect the RTS line to pin1 instead of pin2, and take the batteries out of the remote when programming it with RMIR. ''(More info: [http://www.hifi-remote.com/forums/viewtopic.php?p=149512#149512 here])''.

[[Image:Unusual FTDI cable.jpg|right]]
'''If your cable has pink and grey wires, this might be the pinout:'''
:Red 5v
:Black GND
:White RXD
:Teal/Green TXD
:Pink CTS (instead of blue)
:Grey RTS (instead of yellow)

For remotes with a 5-hole connector (like the URC-2025): 
'''[NOTE: remove the batteries while using RMIR]'''
:1 - RTS (usually Yellow)
:2 - (empty)
:3 - GND (usually Black)
:4 - TXD (usually Green)
:5 - RXD (usually White)

===Older EEPROM based JP1 remotes===
One option is make an interface using an Arduino board, see:
* [[Building the Arduino Interface for older remotes]]

To make an FTDI cable work with older EEPROM based JP1 remotes, you'll need a DIY Gadget JP1 EEPROM programming adapter $10 (+ $4 shipping): 
https://www.diygadget.com/remote-control-accessories/jp1-2-1-3-to-jp1-adapter.
 
These adapters usually do not have pin1 marked. To find pin1, feel the adapter over the heat shrink tubing and you'll notice that one side is flat whereas you can feel the components on the other side. Looking at the flat side, pin1 is marked with white dots in this photo:

[[Image:JP1 Adapter.jpg]] 

If you want a 6-pin DuPont plug for the end, click below (select 2x3P): 
* https://www.ebay.com/itm/335426536170 (qty=20 and up)
* https://www.ebay.com/itm/166241714052 (qty=50)

To remove the existing DuPont connector, use a blade and pop up the plastic tab over each connector and then pull the wire out. With the new connector, just slide each wire into the appropriate slot, with the connector tab facing up so that it pops out of the little window.

The following pic shows how the pins are numbered for the 6-pin connector in the remote itself:

[[Image:JP1 pins.jpg]] [[Image:JP1 6pin.jpg]] [[Image:JP1 pins3.jpg]] 

This video shows you how to connect the cable: 
https://www.youtube.com/watch?v=cLYzsh-usTo

See this for other cheap cable sources: 
https://www.hifi-remote.com/forums/viewtopic.php?t=16200

==Interface Designs==
There are many different interface designs. JP1 (EEPROM) interfaces include the "Simple" design which connects to your PC's parallel printer port and a USB design. JP1 (Flash) interfaces include two serial designs (one with discrete transistors and another with an IC), as well as a USB design. The serial interfaces are compatible with serial ports and with USB to Serial adapters. The parallel interfaces are compatible with parallel ports and parallel PCI or PCMCIA adapters. They are not compatible with USB to parallel printer adapters. Below are several interface design and troubleshooting documents.

EEPROM Interfaces: http://www.hifi-remote.com/forums/dload.php?action=category&cat_id=49 
Flash Interfaces: http://www.hifi-remote.com/forums/dload.php?action=category&cat_id=121 

==Interface Vendors==
JP1 is a hacker project. Most JP1 interfaces are hand made. You won't find a JP1 interface at any retailer. However, there are now some generic USB-Serial interfaces available on ebay that will work for JP1.1 and above. Since the hand made interfaces aren't mass produced, there are no economies of scale. So the interface can more than the remote. But this is still a great value since a JP1 remote with its interface cable and software becomes as functional as remotes costing 10 times as much. Below is a list of JP1 interface vendors.

[http://www.hifi-remote.com/forums/viewtopic.php?t=9405 Tommy Tyler] 
[http://www.diygadget.com/jp1-1-1-1-2-1-3-cables.html DIY Gadget] 
[http://www.txsat.net/ TX SAT Electronics] 
[http://www.hifi-remote.com/forums/viewtopic.php?t=16360 Generic FTDI USB-Serial (cheapest option)] 

==Interface Drivers==
The drivers for JP1 (Flash) interfaces are built in to the latest Windows OSs. They use a chip from FTDI. Drivers for JP1 (EEPROM) USB interfaces are supplied by Delcom, the maker of the chip in these interfaces. The Delcom drivers can be problematic and do not work with the latest 64-bit Windows OSs. There are several versions available with which users have varying degrees of success. There is also a generic WinUSB driver for JP1 (EEPROM) USB interfaces which is compatible with modern OSs. JP1 (EEPROM) parallel interfaces do not require a driver.

===JP1 (EEPROM) Drivers===
*http://www.hifi-remote.com/forums/dload.php?action=category&cat_id=81
*http://www.delcomproducts.com/productdetails.asp?PartNumber=890520

===JP1 (Flash) Drivers===
*http://www.ftdichip.com/Drivers/D2XX.htm 

===PDF Using Legacy Interfaces on Windows 10 ===
*http://www.hifi-remote.com/forums/dload.php?action=file&file_id=25588

===Prolific Drivers on Windows 10 ===
JP1 (Flash) interface cables using a non-genuine Prolific chip will be automatically disabled by default in Windows 10. To work around this issue, install the alternate driver below which bypasses the genuine hardware check, and prevent the genuine driver from reinstalling by following the steps below:
:1. Download the alternate Prolific Windows 10 driver:
::*http://www.hifi-remote.com/forums/dload.php?action=file&file_id=25608
:2. Download the "Show or Hide Updates" troubleshooter tool from Microsoft or mirror copy:
::*https://support.microsoft.com/en-us/topic/how-to-temporarily-prevent-a-driver-update-from-reinstalling-in-windows-10-17df0ef3-7480-36e9-0ed9-118351398897
::*http://www.hifi-remote.com/forums/dload.php?action=file&file_id=26315
:3. Plug in interface cable.
:4. In device manager, locate non-genuine Prolific device under Ports, Right-click and uninstall current driver.
:5. Leave cable plugged in and run the PL2303_64bit_Installer downloaded in step 1.
:6. Click "Continue" when prompted.
:7. Reboot when prompted, leaving cable plugged in.
:8. Run the troubleshooter downloaded in step 2 (wushowhide tool).
:9. Click "Hide" and choose the genuine Prolific driver, then click next (Windows reports problem is "fixed" and hides the driver).

Guide to identifying Atlas remotes

2025-12-07T15:30:21Z

The Robman:

==Atlas remotes==
UEIC manufactures remotes for a number of cable providers and other companies. One of the currently most widespread styles is the "Atlas 5-Device" remote. They go by various names (Atlas 5-Device, Atlas DVR, Atlas DVR/PVR, Atlas 5-Device DVR/PVR, Atlas 5-Device DVR/PVR (day), Atlas OCAP, etc...) and come from various providers (Comcast, Cox, Time Warner, TWC, Rogers, Scientific Atlanta, and others..).

There are [https://web.archive.org/web/20081217041606/http://www.urcsupport.com/ several variants of these remotes], and sometimes it is difficult to tell them apart. ''(Heck, even on the UEIC page linked above, if you look closely you will see that they show some of the same models TWICE iwth links to different manuals'' The variants seen to date are listed in [[Guide to identifying Atlas remotes#Known_variants|this chart]]. In UEIC nomenclature they are (from left to right):

Atlas DVR (1054);
Atlas DVR (day) (1055);
and
Atlas OCAP DVR (1056 and 1056BC) 
[[Image:Atlas5-DeviceSettings.jpg]]
[[Image:AtlasDVR_PVR2.jpg]]
[[Image:Atlas-OCAP-1056-1.jpg]]
[[Image:AtlasOCAPSilverDVR-PVR2.jpg]]

Here are two pictures of a URC-1056 Atlas OCAP Black Remote with backlighting: 
[[Image:Atlas-std.jpg]]
[[Image:Atlas-backlit.jpg]]

==Atlas DVR (1054)==
* has a "Menu" key centered directly above the "Up arrow" key;
* has a "Settings" key (single function) to the left of the "Left Arrow" key;
* is a '''JP1''' remote with '''signature SA_7SA_7'''.
* has a 1K factory EEPROM (can be replaced/upgraded by the user)

==Atlas DVR (day) (1055)==
* has the key above the "Up Arrow" key labelled "Settings" AND "Menu";
* replaces the key to left of the "Left Arrow" key with a rocker key labelled "Day" with a "+"and "-" direction;
* # button (to the right of 0) has a secondary label of HD/Zoom vs. ENTER
* is a '''JP 1.2 or JP 1.3''' remote;
* there are SEVERAL signatures identified (and RDFs created) to date, including:
:* '''10251025''' ('''JP 1.2 - labelled JP1''') has about 3.5K of equivalent "EEPROM" memory;
:* '''30003000''' ('''JP 1.3''') all of the JP1.3's have about 4.5K of equivalent "EEPROM" memory;
:* '''30323032''' ('''JP 1.3'''); and
:* '''30333033''' ('''JP 1.3''') - signature shared with the 1056 OCAP remote.

==Atlas OCAP (1056 and 1056BC)==
* (has a few more evident external differences):
* Separate "Menu" and "Settings" keys;
* "Exit" key moved up ABOVE the arrow key array;
:* this results in FIVE buttons between the "UP Arrow" and the Device keys rather than just the three on the other 2 remotes;
* there is an extra "D" key next to the three "A", "B", and "C" keys;
* Adds alphabetic characters to the numeric keys (like a phone keypad);
* has the middle "F" button enlarged, painted white, and labelled "ON DEMAND", whilst the other "F" keys are shrunken circular buttons;
* has a silver-colored variant (1056BC);
* shares signature '''30333033''' ('''JP1.3''') with one of the 1055s above - a modified rdf is available.
* has about 4.5K of equivalent "EEPROM" memory.

==Featires==
ALL of these remotes: 
* may or may not have learning capability. I expect the 1054 has no learning variant. At least the 1K EEPROM would suggest that is the case. Depending upon the cable provider's requirements with UEIC, the additional circuitry and alternate EEPROM size may be missing. There is no readily apparent way to tell this without opening up the remote '''''(or simply trying to learn, I suppose).'''''
* may or may not have UHF capability. There is an [https://www.hifi-remote.com/forums/app.php/file?file_id=4620 FCC document] indicating at least one version of the 30323032 URC-1055 (oddly enough it is internally labelled as a URC-2150(?!)) has a UHF transmitter compatible with certain Cable boxes. This would have no effect on JP1 programming;

* may or may not have backlighting. Of the Atlases I have seen personally or referred to in these fora, the 1056 (both colors) is the only one to have confirmed backlighting as an option;

* have three keys just below the "Mute"and "Last" keys that will have tailored labels for the cable provider. [size=75]''Note the difference in the 1056 OCAP remote in this regard.''[/size] In UEIC literature, on the 1054 and 1055s, these unlabelled keys are referred to as "TuneIn1", "TuneIn2", and "TuneIn3", and on the 1056, they are labelled "F1", "On Demand", and "F2" respectively. Although they may have different labels in a particular cable provider's application, these are the names used in the software tools;

* most of these remotes have a silkscreened marking next to the 6-pin connector identifying whether it is JP 1, JP 1.2 (see the comment about the 10251025) or JP 1.3, but some may not. As only the 1054 is JP1 and the others are JP 1.x, it's no problem simply connecting the appropriate cable and downloading from the remote to identify what signature it has, and IR should automatically select the correct rdf (unless it's another new one [[Image:icon_rolleyes.gif]] )

==Known variants==

{| class="wikitable"
! UEIC Support pg nomenclature !! Atlas 5 variant !! RDF !! Color !! Backlight !! Learning !! Silkscreen Label !! Battery Compartment Label
|-
| URC-1054 || "settings" || SA_7SA_7 || rowspan="11"| BLACK || NO || NO || || 1054-XXX-0001-001
|-
| rowspan="7"| URC-1055 || rowspan="7"| "day" || rowspan="2"| 10251025 || NO || NO || || 1055BC0
|-
| NO || YES || || 11055BC0
|-
| rowspan="2"| 30003000 || NO || NO || || 1055BC1; 1055BA1
|-
| NO || YES || || 11055BA1-XXX-0001-001
|-
| 30323032 || NO || NO || || 1055BC2
|-
| rowspan="2"| 30333033 || NO || NO || || 1055BC2
|-
| NO || YES || || 11055BA2
|-
| rowspan="3"| URC-1056 || rowspan="4"| "OCAP" ||rowspan="4"| 30333033 || NO || NO || 1056B01 || 1056BG1
|-
| YES || NO || 1056B01 || 1056BC1-BXX-001-0001-001-R
|-
| YES || YES || 1056B01-L || 1056BC1-BLX-XXX-0001-001-R
|-
| URC-1056BC || SILVER || YES || YES || 1056B01-L || 1056BC1-BLS-XXX-0001-001-R
|}

Talk:Guide to identifying Atlas remotes

2025-12-01T01:41:34Z

The Robman: Created page with "This article was copied from the following post by [https://www.hifi-remote.com/forums/memberlist.php?mode=viewprofile&u=304 Capn Trips]: https://www.hifi-remote.com/forums/viewtopic.php?t=8508 There is some discussion after the initial post."

This article was copied from the following post by [https://www.hifi-remote.com/forums/memberlist.php?mode=viewprofile&u=304 Capn Trips]: 
https://www.hifi-remote.com/forums/viewtopic.php?t=8508

There is some discussion after the initial post.

Main Page

2025-12-01T01:39:53Z

The Robman: /* JP1 Guides */

''(Back to [https://www.hifi-remote.com/forums JP1 Forums])'' 
Welcome to the JP1 community Wiki site. A collaborative website relative to the JP1 community to which anyone can contribute!

'''PLEASE NOTE:''' The Wiki section of this website has a different account system than the Forums, so please don't try to log onto the Wiki using your JP1 account id. If you wish to contribute, please see the [[Main Page#Note to new Wiki users|Note to new Wiki users]] below, and one of us will create a Wiki account for you.

==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]]
*[[Guide to identifying Atlas remotes]]

==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.
*[https://www.hifi-remote.com/radioshack/ Radio Shack remotes page]
*[https://www.hifi-remote.com/rcinfo/ Radio Shack's www.rcinfo.com site]
*[https://www.hifi-remote.com/ofaold/ One For All backup #1]
*[https://www.hifi-remote.com/ofausa/ One For All backup #2]
*[https://www.hifi-remote.com/ofa-int/ One For All International]
*[https://www.hifi-remote.com/urc/ UEI's cable remotes page]
*[https://www.hifi-remote.com/hag/ Hudson Access Group's OFA page]

The following are user-maintained sites that are no longer available.
*[https://www.hifi-remote.com/wasser/ John Wasser's old OFA site]
*[https://www.hifi-remote.com/ziggr/ Zig's Amazing IR Remote Control Page]
*[https://www.hifi-remote.com/huras/ Dave Huras's X10 and OFA Page]
*[https://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]]
*[https://www.hifi-remote.com/forums/viewforum.php?f=19 Slingbox forum]
*[https://www.hifi-remote.com/forums/dload.php?action=category&cat_id=97 Slingbox files] (inactive)

==Resources==
*[https://controlremote.sourceforge.io/ Remote Master Download]
*[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]]
*[https://www.hifi-remote.com/forums JP1 Forums]
*[https://www.hifi-remote.com/forums/dload.php JP1 Files] (inactive)
*[https://www.getzweb.net/jp1/ JP1 Lookup Tool]
*[https://www.youtube.com/watch?v=ubrq9Pr3Y1Y&list=PLXmyroJbN9CAxc6vADS4iiXQT3fp0c-Iq JP1 "How To" Videos]

==References==
*[https://www.hifi-remote.com/files/wiki/Lutron-Master-List.xls Lutron Master List]
*[https://www.hifi-remote.com/files/wiki/IR_AVR_121.xls Onkyo Master List]
*[https://www.hifi-remote.com/files/wiki/Pioneer_Master_List.rmdu Pioneer Master List]
*[https://www.hifi-remote.com/files/wiki/Sanyo_Projector_Master.rmdu Sanyo Projector Master List]
*[https://www.hifi-remote.com/sony/ Sony Master List]
*[https://www.hifi-remote.com/files/wiki/Yamaha-Master.zip Yamaha Master List]

==Note to new Wiki users==
Due to the incredibly high number of spam accounts being created on this wiki, we have been forced to disable the New Account feature. If you wish to contribute to the wiki, please contact any of the following via the main JP1 Forum:
[https://www.hifi-remote.com/forums/memberlist.php?mode=viewprofile&u=2 Rob],
[https://www.hifi-remote.com/forums/memberlist.php?mode=viewprofile&u=1350 Vicky],
[https://www.hifi-remote.com/forums/memberlist.php?mode=viewprofile&u=13357 3FG],
[https://www.hifi-remote.com/forums/memberlist.php?mode=viewprofile&u=823 xnappo],
[https://www.hifi-remote.com/forums/memberlist.php?mode=viewprofile&u=343 mdavej].

Guide to identifying Atlas remotes

2025-12-01T01:39:26Z

The Robman: Initial draft

==Atlas remotes==
UEIC manufactures remotes for a number of cable providers and other companies. One of the currently most widespread styles is the "Atlas 5-Device" remote. They go by various names (Atlas 5-Device, Atlas DVR, Atlas DVR/PVR, Atlas 5-Device DVR/PVR, Atlas 5-Device DVR/PVR (day), Atlas OCAP, etc...) and come from various providers (Comcast, Cox, Time Warner, TWC, Rogers, Scientific Atlanta, and others..).

There are [https://web.archive.org/web/20081217041606/http://www.urcsupport.com/ several variants of these remotes], and sometimes it is difficult to tell them apart. ''(Heck, even on the UEIC page linked above, if you look closely you will see that they show some of the same models TWICE iwth links to different manuals'' The variants seen to date are listed in [[Atlas Chart|this chart]]. In UEIC nomenclature they are (from left to right):

Atlas DVR (1054);
Atlas DVR (day) (1055);
and
Atlas OCAP DVR (1056 and 1056BC) 
[[Image:Atlas5-DeviceSettings.jpg]]
[[Image:AtlasDVR_PVR2.jpg]]
[[Image:Atlas-OCAP-1056-1.jpg]]
[[Image:AtlasOCAPSilverDVR-PVR2.jpg]]

Here are two pictures of a URC-1056 Atlas OCAP Black Remote with backlighting: 
[[Image:Atlas-std.jpg]]
[[Image:Atlas-backlit.jpg]]

==Atlas DVR (1054)==
* has a "Menu" key centered directly above the "Up arrow" key;
* has a "Settings" key (single function) to the left of the "Left Arrow" key;
* is a '''JP1''' remote with '''signature SA_7SA_7'''.
* has a 1K factory EEPROM (can be replaced/upgraded by the user)

==Atlas DVR (day) (1055)==
* has the key above the "Up Arrow" key labelled "Settings" AND "Menu";
* replaces the key to left of the "Left Arrow" key with a rocker key labelled "Day" with a "+"and "-" direction;
* # button (to the right of 0) has a secondary label of HD/Zoom vs. ENTER
* is a '''JP 1.2 or JP 1.3''' remote;
* there are SEVERAL signatures identified (and RDFs created) to date, including:
:* '''10251025''' ('''JP 1.2 - labelled JP1''') has about 3.5K of equivalent "EEPROM" memory;
:* '''30003000''' ('''JP 1.3''') all of the JP1.3's have about 4.5K of equivalent "EEPROM" memory;
:* '''30323032''' ('''JP 1.3'''); and
:* '''30333033''' ('''JP 1.3''') - signature shared with the 1056 OCAP remote.

==Atlas OCAP (1056 and 1056BC)==
* (has a few more evident external differences):
* Separate "Menu" and "Settings" keys;
* "Exit" key moved up ABOVE the arrow key array;
:* this results in FIVE buttons between the "UP Arrow" and the Device keys rather than just the three on the other 2 remotes;
* there is an extra "D" key next to the three "A", "B", and "C" keys;
* Adds alphabetic characters to the numeric keys (like a phone keypad);
* has the middle "F" button enlarged, painted white, and labelled "ON DEMAND", whilst the other "F" keys are shrunken circular buttons;
* has a silver-colored variant (1056BC);
* shares signature '''30333033''' ('''JP1.3''') with one of the 1055s above - a modified rdf is available.
* has about 4.5K of equivalent "EEPROM" memory.

==ALL of these remotes==
* may or may not have learning capability. I expect the 1054 has no learning variant. At least the 1K EEPROM would suggest that is the case. Depending upon the cable provider's requirements with UEIC, the additional circuitry and alternate EEPROM size may be missing. There is no readily apparent way to tell this without opening up the remote '''''(or simply trying to learn, I suppose).'''''
* may or may not have UHF capability. There is an [https://www.hifi-remote.com/forums/app.php/file?file_id=4620 FCC document] indicating at least one version of the 30323032 URC-1055 (oddly enough it is internally labelled as a URC-2150(?!)) has a UHF transmitter compatible with certain Cable boxes. This would have no effect on JP1 programming;

* may or may not have backlighting. Of the Atlases I have seen personally or referred to in these fora, the 1056 (both colors) is the only one to have confirmed backlighting as an option;

* have three keys just below the "Mute"and "Last" keys that will have tailored labels for the cable provider. [size=75]''Note the difference in the 1056 OCAP remote in this regard.''[/size] In UEIC literature, on the 1054 and 1055s, these unlabelled keys are referred to as "TuneIn1", "TuneIn2", and "TuneIn3", and on the 1056, they are labelled "F1", "On Demand", and "F2" respectively. Although they may have different labels in a particular cable provider's application, these are the names used in the software tools;

* most of these remotes have a silkscreened marking next to the 6-pin connector identifying whether it is JP 1, JP 1.2 (see the comment about the 10251025) or JP 1.3, but some may not. As only the 1054 is JP1 and the others are JP 1.x, it's no problem simply connecting the appropriate cable and downloading from the remote to identify what signature it has, and IR should automatically select the correct rdf (unless it's another new one [[Image:icon_rolleyes.gif]] )

File:Icon rolleyes.gif

2025-12-01T01:05:31Z

The Robman:

File:Atlas-backlit.jpg

2025-12-01T00:58:14Z

The Robman:

File:Atlas-std.jpg

2025-12-01T00:58:04Z

The Robman:

File:AtlasOCAPSilverDVR-PVR2.jpg

2025-12-01T00:57:52Z

The Robman:

File:Atlas-OCAP-1056-1.jpg

2025-12-01T00:57:36Z

The Robman:

File:AtlasDVR PVR2.jpg

2025-12-01T00:57:24Z

The Robman:

File:Atlas5-DeviceSettings.jpg

2025-12-01T00:56:10Z

The Robman:

Technical Documents

2025-11-23T16:24:51Z

The Robman:

==Schematics==

[https://www.hifi-remote.com/files/schematics/15-1925.pdf 15-1925.pdf] 
[https://www.hifi-remote.com/files/schematics/15-1935.pdf 15-1935.pdf] 
[https://www.hifi-remote.com/files/schematics/15-1995.pdf 15-1995.pdf] 
[https://www.hifi-remote.com/files/schematics/15-2117.pdf 15-2117.pdf] 
[https://www.hifi-remote.com/files/schematics/RCU810.pdf RCU810.pdf] 
[https://www.hifi-remote.com/files/schematics/URC-4300B01.pdf URC-4300B01.pdf] 
[https://www.hifi-remote.com/files/schematics/URC-7200-v1.gif URC-7200-v1.gif] 
[https://www.hifi-remote.com/files/schematics/URC-7200-v2.gif URC-7200-v2.gif] 
[https://www.hifi-remote.com/files/schematics/URC-9800.pdf URC-9800.pdf] 
[https://www.hifi-remote.com/files/schematics/URC-9800.pdf URC-9900.pdf] 

==MCU Chip Manuals==
===JP1.3 - Samsung S3F8===
[https://www.hifi-remote.com/files/chip-manuals/Samsung_S3F80JB_Rev11.pdf Samsung S3F80JB]

===JP1.2 - Motorola HCS08===
[https://www.hifi-remote.com/files/chip-manuals/MC9S08RG60.pdf MC9S08RG60.pdf] - Motorola HCS08 MCU chip used in the JP1.2 remotes 
[https://www.hifi-remote.com/files/chip-manuals/HCS08RMV1.pdf HCS08RMV1.pdf] - Motorola HCS08 MCU chip used in the JP1.2 "Catalyst 48" remotes 

===JP1.1 - SST===
[https://www.hifi-remote.com/files/chip-manuals/SST-65P542R.pdf SST 65P542R] - data sheet 
[https://www.hifi-remote.com/files/chip-manuals/SST-instruction-set.pdf SST 65P542R] - instruction set 

===JP1 - Samsung S3C8===
[https://www.hifi-remote.com/files/chip-manuals/S3C8-data-sheet.pdf S3C8-data-sheet.pdf] - S3C8 data sheet - S3C8639/C863A/P863A/C8647/F8647 
[https://www.hifi-remote.com/files/chip-manuals/S3C8-instruction-set.pdf S3C8-instruction-set.pdf] - Instruction set for S3C80E5/P80E5/C80E7/P80E7 

===JP1 - Mitsubishi 740===
[https://www.hifi-remote.com/files/chip-manuals/Mits-740-sum.pdf Mits-740-sum.pdf] - Summary Manual for the 740, a good programming reference.pdf Contains more detailed descriptions of the instructions and their results. 
[https://www.hifi-remote.com/files/chip-manuals/Mits-740.pdf Mits-740.pdf] - Mitsubishi 740 user manual (used in the Producer 8s) 

===JP1 - Motorola 6805===
[https://www.hifi-remote.com/files/chip-manuals/68HC05RC16.pdf 68HC05RC16.pdf] - Datasheet for the 68HC05RC16 chip. 
[https://www.hifi-remote.com/files/chip-manuals/68HC05RC18.pdf 68HC05RC18.pdf] - Datasheet for the 68HC05RC18 chip. 
[https://www.hifi-remote.com/files/chip-manuals/MC68HC05C9A.pdf MC68HC05C9A.pdf] - MC68HC05C9A (used in the URC-43000B01 Navigator) 

===JP1 - Mosaic===
[https://www.hifi-remote.com/files/chip-manuals/31LF041.pdf 31LF041.pdf] - SST 32-lead memory chip used by Mosaic 
[https://www.hifi-remote.com/files/chip-manuals/Sharp-ARM-block-diagram.pdf Sharp-ARM-block-diagram.pdf] - Sharp LH77790B: Block Diagram (used in the Mosaic) 
[https://www.hifi-remote.com/files/chip-manuals/Sharp-ARM.pdf Sharp-ARM.pdf] - Sharp LH77790B: General description of the main chip inside the Mosaic/Director remote 
[https://www.hifi-remote.com/files/chip-manuals/Sharp-LH77790B.pdf Sharp-LH77790B.pdf] - Sharp LH77790B: data sheet (used in the Mosaic) 

==EEPROM Chip Manuals==

[https://www.hifi-remote.com/files/chip-manuals/24AA16.pdf 24AA16.pdf] - "Microchip" 24AA16 and 24LC16B eeproms 
[https://www.hifi-remote.com/files/chip-manuals/AT24C32.pdf AT24C32.pdf] - Sheet for the ATMEL AT24C32 and AT24C64 EEPROM chips 
[https://www.hifi-remote.com/files/chip-manuals/NM24C16-17.pdf NM24C16-17.pdf] - Fairchild Semiconductors - EEPROM spec sheet 

==FCC Test Results==
===15-1935===
[https://www.hifi-remote.com/files/FCC/15-1935/15-1935.pdf 15-1935.pdf] 
[https://www.hifi-remote.com/files/FCC/15-1935/external-pics.pdf external-pics.pdf] 

===15-1995===
[https://www.hifi-remote.com/files/FCC/15-1995/15-1995a.pdf 15-1995a.pdf] 
[https://www.hifi-remote.com/files/FCC/15-1995/15-1995b.pdf 15-1995b.pdf] 
[https://www.hifi-remote.com/files/FCC/15-1995/RF-puck-bottom.jpg RF-puck-bottom.jpg] 
[https://www.hifi-remote.com/files/FCC/15-1995/RF-puck-top.jpg RF-puck-top.jpg] 
[https://www.hifi-remote.com/files/FCC/15-1995/description.pdf description.pdf] 
[https://www.hifi-remote.com/files/FCC/15-1995/graphic-design.pdf graphic-design.pdf] 
[https://www.hifi-remote.com/files/FCC/15-1995/internal-pictures.pdf internal-pictures.pdf] 
[https://www.hifi-remote.com/files/FCC/15-1995/letter1.pdf letter1.pdf] 
[https://www.hifi-remote.com/files/FCC/15-1995/letter2.pdf letter2.pdf] 
[https://www.hifi-remote.com/files/FCC/15-1995/pictures.pdf pictures.pdf] 
[https://www.hifi-remote.com/files/FCC/15-1995/schematics.jpg schematics.jpg] 
[https://www.hifi-remote.com/files/FCC/15-1995/schematics.pdf schematics.pdf] 
[https://www.hifi-remote.com/files/FCC/15-1995/test-results.pdf test-results.pdf] 
[https://www.hifi-remote.com/files/FCC/15-1995/testing-pictures.pdf testing-pictures.pdf] 
[https://www.hifi-remote.com/files/FCC/15-1995/user-manual.pdf user-manual.pdf] 

===15-2117===
[https://www.hifi-remote.com/files/FCC/15-2117a.pdf 15-2117a.pdf] 
[https://www.hifi-remote.com/files/FCC/15-2117b.pdf 15-2117b.pdf] 

===URC-9800===
[https://www.hifi-remote.com/files/FCC/URC-9800/URC-9800.pdf URC-9800.pdf] 
[https://www.hifi-remote.com/files/FCC/URC-9800/diagram.pdf diagram.pdf] 
[https://www.hifi-remote.com/files/FCC/URC-9800/external-pics.pdf external-pics.pdf] 
[https://www.hifi-remote.com/files/FCC/URC-9800/letter_1.pdf letter_1.pdf] 
[https://www.hifi-remote.com/files/FCC/URC-9800/letter_2.pdf letter_2.pdf] 
[https://www.hifi-remote.com/files/FCC/URC-9800/wave-description.pdf wave-description.pdf] 

===URC-9910===
[https://www.hifi-remote.com/files/FCC/URC-9910a.pdf URC-9910a.pdf] 
[https://www.hifi-remote.com/files/FCC/URC-9910b.pdf URC-9910b.pdf]

IRP Notation

2025-11-23T16:22:16Z

The Robman:

'''''Specification of IRP Notation''' - ''by [https://www.hifi-remote.com/forums/memberlist.php?mode=viewprofile&u=12337 Graham Dixon]'' ([https://www.hifi-remote.com/forums/dload.php?action=file&file_id=7926 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]]

IRP Notation

2025-11-23T16:21:01Z

The Robman:

'''''Specification of IRP Notation''' - ''by Graham Dixon'' ([https://www.hifi-remote.com/forums/dload.php?action=file&file_id=7926 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]]

How to Create Custom Remote Controls and use them on your Slingbox

2025-11-23T16:19:02Z

The Robman: /* Give your Binary file back to the Community */

''Written by: Al Richey'' 

One of the most common posts on the support site is about remote codes for unsupported devices. So if you find yourself in this situation I hope this will help. Before detailing the steps to go through there are some basic things you need to understand (this isn't essential reading but everything will make much more sense if you do know the details)

==Background information==
===Different UEI Chips===
: There were five different chips used in Slingboxes. These are designated as JU, PK, PL, RV & JB. If you want to check your type you can verify your IR blaster version in the Slingbox Properties dialog. Then match the IR version number with the chip type using the chart below.
#JU (VERY old US boxes)
#PL (current US boxes)
#PK (never used)
#RV (old European boxes)
#JB (All modern Slingboxes, but compatible with PL files)

So unless you have an old European Solo all you need is the PL file.

===Slingplayer Compatibility===
: In older versions of Slingplayer it was possible to change the look of the Custom Remote skin‟. Since Slingplayer V1.5 this functionality has been removed and as far as the look of the Remote is concerned you are stuck with the Generic design produced by Sling Media. All we can do is change the codes that are sent when a specific button is pressed. One drawback of the Generic Remote is that it has only the main buttons, so extra buttons on other remotes (such as Audio/Setup…) can not be mapped directly. What we have to do is put them into a Custom Menu which is accessed by tapping on the Menu button on the Generic Remote or right-clicking on the image. (Note: If a remote image has already been produced by Sling it is possible to use that image instead of the generic image, just contact me at alan@rmrsoft.com)
:

===Setup Code Nomenclature===
: When you run the Configure Inputs routines in the various Slingplayers and select a supported device, what actually happens is that a Binary Code is downloaded to the Slingbox. 
: This Binary Code details the IR codes that are sent when a specific button is pressed on the remote. Unfortunately the native Slingbox software doesn't use separate binary files that we can edit, their codes are apparently compressed and packaged into special files that we can't do anything with (that I know of). But what we can do instead of editing the built-in codes is to use a separate external upgrade code file. These files have the format such as "C1234_PL.BIN". 
: The first letter of the file describes the type of device, the main ones we are interested in are:

::V which is for VCRs, which encompasses PVRs, DVRs and other recorders
::S which is for Satellite and FTA set top boxes
::C which is for Cable boxes
::Y which is for DVD Players

:This is followed by a 4-digit code number. For Slingboxes the code numbers can be between 0000-2047 (actually higher in newer Slingboxes but to stay safe we are better staying below 2047). In general, codes below 2000 actually relate to specific boxes, for example V0618 is the code for a TIVO and D0032 is the code for a Pioneer CD Player. But we can feel fairly safe using 2000-2047 for our own codes. The final part of the filename defines the chip for which it will run. 
: So if you were looking for the binary file for a PVR with a code number allocated 1234, designed to run on a PL-equipped Slingbox, you would be searching for a file called V1234_PL.BIN. Note: You must NEVER change the name of the file, as the letter, code number and chip type are also defined inside the file itself.

===JP1===
:You will hear a lot about "JP1". Basically this is a process whereby people using "One For All‟ (OFA) remote controls can add new codes to their remotes from their PC. The remote control processor inside the Slingbox is made by the same company that makes OFA remotes, so the upgrades are similar. The JP1 tools have been upgraded so that we can now use them to create and modify upgrades for the Slingbox.

==The Basic Procedure.==
The official procedure to follow was to report the [https://web.archive.org/web/20100605080308/http://support.slingmedia.com/get/KB-005640.html Lack of a Supported Remote] to SlingMedia and they would add it to the database. In practice, they were not quick at doing this (I have been asking for a remote for over 4 years now), and the updated remote list seems to be only occasionally updated. So it was really not a practical quick solution. So what folks need to do is to create or acquire the correct Binary code file for your A/V device, and then install it into your Slingbox. This installation process is covered in detail in [[#Installing_the_Binary_file_to_the_Slingbox|Section 4]], so first let‟s see where you can look for these files. 

==Obtaining the Binary file for the Custom Remote==

#Before starting, make sure in the setup wizard you have tried all the devices by that same manufacturer, even if the model number does not match, and all the associated code numbers. It's also worth trying your TV Provider in case they have 'badged' someone else's box. You might be lucky and find one that works and that will save a lot of work. If that doesn't solve the problem here is the step by step approach to getting hold of your binary file: 
#Go to the JP1 forum. This has a specific Download area for [https://www.hifi-remote.com/forums/dload.php?action=category&cat_id=87 Slingbox Custom Remotes], so go through all those to see if your device has already been done. 
#If it isn't there the JP1 forum also has a more general [https://www.hifi-remote.com/forums/dload.php?action=category&cat_id=4 File Download Area]. From this page you select the download area for the specific type of device and check there. If you are lucky you will find a source file for using in the program RemoteMaster (RM or KM files), the use of which is discussed in [[#Creating_your_own_Binary_files_using_RemoteMaster|Section 6]]. 
#Have a look on the Hava forums. They are also using the same chips and the files might be there. Check out this [http://www.myhava.com/forum/viewforum.php?f=17&st=0&sk=t&sd=d&start=0 forum]. You‟re looking for a PK or PL file. They can be imported into Remote Master and then converted to the PK, PL, RV or JU files for the Slingbox. Again this is discussed in [[#Creating_your_own_Binary_files_using_RemoteMaster|Section 6]]. 
#Do it yourself by buying a Nevo C2, or an IR Widget, and learn the codes needed to control the device. How to do this is covered in [[#Learning_the_IR_codes_from_your_own_remote|Section 5]] & [[#Creating_your_own_Binary_files_using_RemoteMaster|Section 6]]. 
#Ask someone else to do the work for you. You can try this by posting a request for help in either:
##The [https://community.sling.com/content Slingbox Answers Forum].
##The [https://www.hifi-remote.com/forums/viewforum.php?f=19 JP1 forum]. 
I can normally install your device on my Harmony Universal Remote to mimic the original Remote and learn the codes for you (unless I am away on holiday). 

==Installing the Binary file to the Slingbox.==
 I have written a comprehensive Installation Guide at

[https://web.archive.org/web/20161021050303/https://placeshiftingenthusiasts.com/how-to-install-a-custom-remote-onto-the-slingbox/ http://placeshiftingenthusiasts.com/how-to-install-a-custom-remote-onto-the-slingbox/]

Once you have completed the setup and the BIN files have been downloaded to the Slingbox they are not used any more and can be deleted.

==Learning the IR codes from your own remote.==
===Requirements===
Assuming you have decided to create the Remote Binary File yourself, the first stage is to learn the codes from your original Remote. This is what you need:
====Hardware====
#A computer with a USB port. 
#A A Nevo C2 Learning Remote (Available on E-Bay for $20 or so) or alternatively

:An IR learning "widget". I got mine from Tommy Tyler through [https://web.archive.org/web/20160417092406/https://www.tindie.com/products/TommyTyler/ir-widget-infrared-remote-control-signal-recorderanalyzer/ https://www.tindie.com/products/TommyTyler/ir-widget-infrared-remote-control-signal-recorderanalyzer/] (My preferred solution). 

====Software====
If you are using the Nevo C2: 
[https://sourceforge.net/projects/controlremote/ RM/RMIR.EXE] 
[https://www.hifi-remote.com/forums/dload.php?action=file&file_id=7201 RDF Files] These are support files for the program. 

If you are using an IR Widget: 
[https://www.compendiumarcana.com/irwidget/irscope.zip IRSCOPE.EXE] 
[https://www.ftdichip.com/Drivers/VCP.htm The drivers] 
[https://www.hifi-remote.com/forums/dload.php?action=file&file_id=922 The IR decode DLL] 
Or download [https://web.archive.org/web/20160305015553/http://rmrsoft.com/remote.zip my full IRSCOPE/REMOTEMASTER package]. 
Much of the JP1 software needs the java runtime environment (JRE) as well. A lot of computers will already have it installed already, but if you need it, you can [https://www.java.com/en/download/manual.jsp download] 
Now we can learn the codes. First, we will cover the procedure using a Learning Remote, then cover it using an IR Widget. 

===USING A LEARNING REMOTE===
====Getting the Codes from your Remote====
Follow the instructions to learn your remote codes so the Nevo C2 operates your device. Then download the settings file onto your PC.

====Getting the Codes onto your PC.====
 
:#Install RMIR.EXE onto your PC. It comes as a ZIP file rather than an installation package, which you need to unzip to your PC. The files can actually go anywhere but as a bit of tidy person (geek?) I created a C:\Program Files\IR\ folder and put the files in there. Now go into the folder and click on Setup.vbs and that will produce shortcuts to run RMIR and RM (Full instructions are at https://www.hifi-remote.com/wiki/index.php?title=JP1_-_Just_How_Easy_Is_It%3F_-_RM-IR_Version)
:#You will need to create a sub folder called \RDF\ in whatever folder you have put the IR program and extract the RDF support files into that folder. Again, refer to the instructions. 

Now plug your Nevo into the PC and start RMIR. Use the '''Remote > Download Remote''' menu option to get the data from the Nevo to the PC.

Under the '''Devices Tab''' you should now see the device. Select it, then use the Edit Device button and then the Save As button to produce the required RMDU file.

You can now post that file to the forum where you requested the remote, or if you want to do it yourself then go to the next Section.

===USING AN IR WIDGET===
If you are using an IR Widget there is an excellent guide [http://freepdfhosting.com/6ea1213d67.pdf here] ([https://archive.is/FEVaK archive copy]) on the Tindle site. So I suggest you download that and read it thoroughly. There is no point in repeating it here, but just to emphasise a few points: 
:#You will want to regularly check for updates to the decodeir.dll. As new protocols are recognized, this dll will change. 
:#There is no way to save the learned values for importing into RemoteMaster (where you will make the remote) so you will need to write them down. 
:#Although I tend to put programs into C:\Program Files\.... this can be a bit dodgy in Windows as programs cannot save files to this area because of security limitations. So it might be safer to install it under \Documents\ 
:#The Guide has a very useful section comparing using a Learning Remotes and the IR Widget and highlighting the differences, (For example "Key" is equivalent to "OBC") so you could check out the previous sub-section covering using IR.EXE and the Learning Remote. And then you will understand this section. When complete you can move onto [[#Creating_your_own_Binary_files_using_RemoteMaster|Section 6]] to create the Binary file. 

==Creating your own Binary files using RemoteMaster==
:#To make life easier I have packaged a full set of the latest files required and uploaded them to my site. Just download them from [https://web.archive.org/web/20160305015553/http://rmrsoft.com/remote.zip here] and unzip them onto your computer. 
:#Start RemoteMaster.EXE. You may be promoted to highlight the folder the folder that contains the RDF files (Highlight the \RDF\ folder in the folder where you placed Remotemaster). You may also have to do the same for the Images folder. The display will now look something like this:[[Image:RM-setup.jpg]] 
:#If you have obtained an .rmdu file then use the File > Open menu option to load the file. If you have obtained a .bin file then use the Advanced > Import Binary Upgrade to load up the details. If you have not obtained a file then you will have to input the codes manually. 
:#Now to explain the main Setup Tab: '''Description ''': Use anything you like, I tend to use the device name. '''Remote''': Select the one appropriate for your chip. '''Device Type''': Should be set to the correct type of device (as covered in Paragraph 3 of Section 1). '''Setup Code''': This is where you put the 4-digit code. In theory it can be any number between 0000 and 2047, but as explained in Section 1 Paragraph 3, numbers below 2000 may actually be already allocated to specific devices, so to be safe I personally use 2010. Fell free to use your own value. '''Protocol''': From the dropdown list select the Protocol you discovered when you used IR.EXE/IRSCOPE.EXE. '''Device''': Type in the Device code you recorded from IR.EXE/IRSCOPE.EXE. '''Sub-Device''': If applicable type in the Sub-Device code you recorded from IR.EXE/ IRSCOPE.EXE. 
:#Now tap on the Functions Tab [[Image:RM-functions.jpg]] This picture shows the program with an .rmdu file or .bin file already imported; otherwise the code columns will be blank. The entries are fully configurable, so if there are pre-defined functions that you do not need (pip swap, pipmove..) then you highlight them and tap the "Delete" button. If you have a function that is not pre-defined (Audio, Setup…) then tap the "New" button and enter them. Now fill in the codes for each button that you recorded. You just put in the OBC value and press <Enter>, the other 2 values will be generated automatically based on the protocol you selected. Also, if you used a JP1 learning remote, there's a way to cut and paste all the codes which saves needing to enter them all. In IR, if you select File > Summary you get a page listing lots of stuff. If you scroll down, you'll see a list of learn decodes. You can cut and paste this list into Excel, then you can re-arrange the columns and just select the button names and OBC codes to cut and paste into RM. You can move the RM columns, so if the OBC column isn't the one next to the button names, you can move it there. 
:#Now tap on the Buttons Tab [[Image:RM-buttons.jpg]] This is where you map the defined functions onto the available buttons. Simply tap the Auto-Assign button which should allocate most of the buttons. For any buttons left in red drag the function name from the table on the left to the function column on the right. But note that not all these buttons are available on a Slingplayer Generic Remote. For example the 'Slow' and 'Eject' buttons do not exist on a Generic Remote. So only map the functions onto the buttons that actually exist (You will see that when you check out the Layout Tab, and from experience when you have done this a few times). The important ones to note are the Custom 10-29 buttons. These are the ones you use for the functions you need that aren't on the generic remote and they subsequently appear in the drop down menu of the remote as Custom options (except for Custom 22-26 which are pre-allocated to the colour buttons). 
:#Now tap on the Layout Tab. [[Image:RM-layout.jpg]] This shows the generic Slingplayer remote and shows the buttons you can actually use in the Buttons Tab. If a button shows yellow then that means it is in use. If it shows black (the PgUp/PgDn in the picture) then has not been allocated a function. Again you can drag and drop functions onto a button. 
:#Once you have finished experimenting go back to the Setup tab. Select the appropriate Slingbox remote, go to the 'Advanced' menu at the top and select 'Export Binary Upgrade'. This will produce the BIN file that we have discussed in previous Sections. If you aren‟t sure which Slingbox Chip you have then create a BIN file for the main 2 chips, so that would give you something like 
:::C2010_PL.BIN
:::C2010_RV.BIN

So now you can go back to [[#Installing_the_Binary_file_to_the_Slingbox.|Section 4]] and install the new Custom Remote onto your Slingbox. 

====Finding Missing Codes====
You can often find yourself in the position where the Custom Remote generally works OK but some of the functions are missing or some are sending the wrong code. This is relatively easy to fix by trial and error. The OBC codes must lie between 0-255, so the first thing to do is make a list of the OBC codes that are not being used in the Remote Control. Now use Remotemaster to allocate those codes to the 0-9 buttons and the 15 Custom buttons. Now build a new BIN files, replace the one in your \SBAV\ folder and rerun the "Setup Video Sources" routine. Now try those buttons and see if any of them action the missing function. If you find the missing codes then you can update the original remote file. You may have to repeat this operation 10 times to cover all the missing codes, although you can cut down the number of times by also using the Transport buttons (Play/Pause…) and Channel, Page +/- buttons as well. 

==Give your Binary file back to the Community==
Finally, remember that it is good to payback. If you find a remote file that works for you then upload it to the JP1 Forums. The way to do this is: 
#Put the 4 Binary files and the Remote Master RMDU file into a ZIP file. I also tend to add a Readme file in case users are unsure how to use the files. Although hopefully they will have read this article and will know what to do. 
#To be really helpful, you should upload your files in 3 different places:
##Upload your ZIP file to the [https://www.hifi-remote.com/forums/dload.php?action=category&cat_id=87 Slingbox Binary Files] area.
##Upload the Remote Master RMDU source file to the [https://www.hifi-remote.com/forums/dload.php?action=category&cat_id=98 Slingbox RM Files] area.
##Upload the RMDU file to the appropriate area in the [https://www.hifi-remote.com/forums/dload.php?action=category&cat_id=4 Device Upgrades] area.
 
I hope these instructions have been helpful. If you have any suggestions for changes or improvements please E-mail me at '''alan (at) rmrsoft (dot) com'''

How to Create Custom Remote Controls and use them on your Slingbox

2025-11-23T16:18:02Z

The Robman:

''Written by: Al Richey'' 

One of the most common posts on the support site is about remote codes for unsupported devices. So if you find yourself in this situation I hope this will help. Before detailing the steps to go through there are some basic things you need to understand (this isn't essential reading but everything will make much more sense if you do know the details)

==Background information==
===Different UEI Chips===
: There were five different chips used in Slingboxes. These are designated as JU, PK, PL, RV & JB. If you want to check your type you can verify your IR blaster version in the Slingbox Properties dialog. Then match the IR version number with the chip type using the chart below.
#JU (VERY old US boxes)
#PL (current US boxes)
#PK (never used)
#RV (old European boxes)
#JB (All modern Slingboxes, but compatible with PL files)

So unless you have an old European Solo all you need is the PL file.

===Slingplayer Compatibility===
: In older versions of Slingplayer it was possible to change the look of the Custom Remote skin‟. Since Slingplayer V1.5 this functionality has been removed and as far as the look of the Remote is concerned you are stuck with the Generic design produced by Sling Media. All we can do is change the codes that are sent when a specific button is pressed. One drawback of the Generic Remote is that it has only the main buttons, so extra buttons on other remotes (such as Audio/Setup…) can not be mapped directly. What we have to do is put them into a Custom Menu which is accessed by tapping on the Menu button on the Generic Remote or right-clicking on the image. (Note: If a remote image has already been produced by Sling it is possible to use that image instead of the generic image, just contact me at alan@rmrsoft.com)
:

===Setup Code Nomenclature===
: When you run the Configure Inputs routines in the various Slingplayers and select a supported device, what actually happens is that a Binary Code is downloaded to the Slingbox. 
: This Binary Code details the IR codes that are sent when a specific button is pressed on the remote. Unfortunately the native Slingbox software doesn't use separate binary files that we can edit, their codes are apparently compressed and packaged into special files that we can't do anything with (that I know of). But what we can do instead of editing the built-in codes is to use a separate external upgrade code file. These files have the format such as "C1234_PL.BIN". 
: The first letter of the file describes the type of device, the main ones we are interested in are:

::V which is for VCRs, which encompasses PVRs, DVRs and other recorders
::S which is for Satellite and FTA set top boxes
::C which is for Cable boxes
::Y which is for DVD Players

:This is followed by a 4-digit code number. For Slingboxes the code numbers can be between 0000-2047 (actually higher in newer Slingboxes but to stay safe we are better staying below 2047). In general, codes below 2000 actually relate to specific boxes, for example V0618 is the code for a TIVO and D0032 is the code for a Pioneer CD Player. But we can feel fairly safe using 2000-2047 for our own codes. The final part of the filename defines the chip for which it will run. 
: So if you were looking for the binary file for a PVR with a code number allocated 1234, designed to run on a PL-equipped Slingbox, you would be searching for a file called V1234_PL.BIN. Note: You must NEVER change the name of the file, as the letter, code number and chip type are also defined inside the file itself.

===JP1===
:You will hear a lot about "JP1". Basically this is a process whereby people using "One For All‟ (OFA) remote controls can add new codes to their remotes from their PC. The remote control processor inside the Slingbox is made by the same company that makes OFA remotes, so the upgrades are similar. The JP1 tools have been upgraded so that we can now use them to create and modify upgrades for the Slingbox.

==The Basic Procedure.==
The official procedure to follow was to report the [https://web.archive.org/web/20100605080308/http://support.slingmedia.com/get/KB-005640.html Lack of a Supported Remote] to SlingMedia and they would add it to the database. In practice, they were not quick at doing this (I have been asking for a remote for over 4 years now), and the updated remote list seems to be only occasionally updated. So it was really not a practical quick solution. So what folks need to do is to create or acquire the correct Binary code file for your A/V device, and then install it into your Slingbox. This installation process is covered in detail in [[#Installing_the_Binary_file_to_the_Slingbox|Section 4]], so first let‟s see where you can look for these files. 

==Obtaining the Binary file for the Custom Remote==

#Before starting, make sure in the setup wizard you have tried all the devices by that same manufacturer, even if the model number does not match, and all the associated code numbers. It's also worth trying your TV Provider in case they have 'badged' someone else's box. You might be lucky and find one that works and that will save a lot of work. If that doesn't solve the problem here is the step by step approach to getting hold of your binary file: 
#Go to the JP1 forum. This has a specific Download area for [https://www.hifi-remote.com/forums/dload.php?action=category&cat_id=87 Slingbox Custom Remotes], so go through all those to see if your device has already been done. 
#If it isn't there the JP1 forum also has a more general [https://www.hifi-remote.com/forums/dload.php?action=category&cat_id=4 File Download Area]. From this page you select the download area for the specific type of device and check there. If you are lucky you will find a source file for using in the program RemoteMaster (RM or KM files), the use of which is discussed in [[#Creating_your_own_Binary_files_using_RemoteMaster|Section 6]]. 
#Have a look on the Hava forums. They are also using the same chips and the files might be there. Check out this [http://www.myhava.com/forum/viewforum.php?f=17&st=0&sk=t&sd=d&start=0 forum]. You‟re looking for a PK or PL file. They can be imported into Remote Master and then converted to the PK, PL, RV or JU files for the Slingbox. Again this is discussed in [[#Creating_your_own_Binary_files_using_RemoteMaster|Section 6]]. 
#Do it yourself by buying a Nevo C2, or an IR Widget, and learn the codes needed to control the device. How to do this is covered in [[#Learning_the_IR_codes_from_your_own_remote|Section 5]] & [[#Creating_your_own_Binary_files_using_RemoteMaster|Section 6]]. 
#Ask someone else to do the work for you. You can try this by posting a request for help in either:
##The [https://community.sling.com/content Slingbox Answers Forum].
##The [https://www.hifi-remote.com/forums/viewforum.php?f=19 JP1 forum]. 
I can normally install your device on my Harmony Universal Remote to mimic the original Remote and learn the codes for you (unless I am away on holiday). 

==Installing the Binary file to the Slingbox.==
 I have written a comprehensive Installation Guide at

[https://web.archive.org/web/20161021050303/https://placeshiftingenthusiasts.com/how-to-install-a-custom-remote-onto-the-slingbox/ http://placeshiftingenthusiasts.com/how-to-install-a-custom-remote-onto-the-slingbox/]

Once you have completed the setup and the BIN files have been downloaded to the Slingbox they are not used any more and can be deleted.

==Learning the IR codes from your own remote.==
===Requirements===
Assuming you have decided to create the Remote Binary File yourself, the first stage is to learn the codes from your original Remote. This is what you need:
====Hardware====
#A computer with a USB port. 
#A A Nevo C2 Learning Remote (Available on E-Bay for $20 or so) or alternatively

:An IR learning "widget". I got mine from Tommy Tyler through [https://web.archive.org/web/20160417092406/https://www.tindie.com/products/TommyTyler/ir-widget-infrared-remote-control-signal-recorderanalyzer/ https://www.tindie.com/products/TommyTyler/ir-widget-infrared-remote-control-signal-recorderanalyzer/] (My preferred solution). 

====Software====
If you are using the Nevo C2: 
[https://sourceforge.net/projects/controlremote/ RM/RMIR.EXE] 
[https://www.hifi-remote.com/forums/dload.php?action=file&file_id=7201 RDF Files] These are support files for the program. 

If you are using an IR Widget: 
[https://www.compendiumarcana.com/irwidget/irscope.zip IRSCOPE.EXE] 
[https://www.ftdichip.com/Drivers/VCP.htm The drivers] 
[https://www.hifi-remote.com/forums/dload.php?action=file&file_id=922 The IR decode DLL] 
Or download [https://web.archive.org/web/20160305015553/http://rmrsoft.com/remote.zip my full IRSCOPE/REMOTEMASTER package]. 
Much of the JP1 software needs the java runtime environment (JRE) as well. A lot of computers will already have it installed already, but if you need it, you can [https://www.java.com/en/download/manual.jsp download] 
Now we can learn the codes. First, we will cover the procedure using a Learning Remote, then cover it using an IR Widget. 

===USING A LEARNING REMOTE===
====Getting the Codes from your Remote====
Follow the instructions to learn your remote codes so the Nevo C2 operates your device. Then download the settings file onto your PC.

====Getting the Codes onto your PC.====
 
:#Install RMIR.EXE onto your PC. It comes as a ZIP file rather than an installation package, which you need to unzip to your PC. The files can actually go anywhere but as a bit of tidy person (geek?) I created a C:\Program Files\IR\ folder and put the files in there. Now go into the folder and click on Setup.vbs and that will produce shortcuts to run RMIR and RM (Full instructions are at https://www.hifi-remote.com/wiki/index.php?title=JP1_-_Just_How_Easy_Is_It%3F_-_RM-IR_Version)
:#You will need to create a sub folder called \RDF\ in whatever folder you have put the IR program and extract the RDF support files into that folder. Again, refer to the instructions. 

Now plug your Nevo into the PC and start RMIR. Use the '''Remote > Download Remote''' menu option to get the data from the Nevo to the PC.

Under the '''Devices Tab''' you should now see the device. Select it, then use the Edit Device button and then the Save As button to produce the required RMDU file.

You can now post that file to the forum where you requested the remote, or if you want to do it yourself then go to the next Section.

===USING AN IR WIDGET===
If you are using an IR Widget there is an excellent guide [http://freepdfhosting.com/6ea1213d67.pdf here] ([https://archive.is/FEVaK archive copy]) on the Tindle site. So I suggest you download that and read it thoroughly. There is no point in repeating it here, but just to emphasise a few points: 
:#You will want to regularly check for updates to the decodeir.dll. As new protocols are recognized, this dll will change. 
:#There is no way to save the learned values for importing into RemoteMaster (where you will make the remote) so you will need to write them down. 
:#Although I tend to put programs into C:\Program Files\.... this can be a bit dodgy in Windows as programs cannot save files to this area because of security limitations. So it might be safer to install it under \Documents\ 
:#The Guide has a very useful section comparing using a Learning Remotes and the IR Widget and highlighting the differences, (For example "Key" is equivalent to "OBC") so you could check out the previous sub-section covering using IR.EXE and the Learning Remote. And then you will understand this section. When complete you can move onto [[#Creating_your_own_Binary_files_using_RemoteMaster|Section 6]] to create the Binary file. 

==Creating your own Binary files using RemoteMaster==
:#To make life easier I have packaged a full set of the latest files required and uploaded them to my site. Just download them from [https://web.archive.org/web/20160305015553/http://rmrsoft.com/remote.zip here] and unzip them onto your computer. 
:#Start RemoteMaster.EXE. You may be promoted to highlight the folder the folder that contains the RDF files (Highlight the \RDF\ folder in the folder where you placed Remotemaster). You may also have to do the same for the Images folder. The display will now look something like this:[[Image:RM-setup.jpg]] 
:#If you have obtained an .rmdu file then use the File > Open menu option to load the file. If you have obtained a .bin file then use the Advanced > Import Binary Upgrade to load up the details. If you have not obtained a file then you will have to input the codes manually. 
:#Now to explain the main Setup Tab: '''Description ''': Use anything you like, I tend to use the device name. '''Remote''': Select the one appropriate for your chip. '''Device Type''': Should be set to the correct type of device (as covered in Paragraph 3 of Section 1). '''Setup Code''': This is where you put the 4-digit code. In theory it can be any number between 0000 and 2047, but as explained in Section 1 Paragraph 3, numbers below 2000 may actually be already allocated to specific devices, so to be safe I personally use 2010. Fell free to use your own value. '''Protocol''': From the dropdown list select the Protocol you discovered when you used IR.EXE/IRSCOPE.EXE. '''Device''': Type in the Device code you recorded from IR.EXE/IRSCOPE.EXE. '''Sub-Device''': If applicable type in the Sub-Device code you recorded from IR.EXE/ IRSCOPE.EXE. 
:#Now tap on the Functions Tab [[Image:RM-functions.jpg]] This picture shows the program with an .rmdu file or .bin file already imported; otherwise the code columns will be blank. The entries are fully configurable, so if there are pre-defined functions that you do not need (pip swap, pipmove..) then you highlight them and tap the "Delete" button. If you have a function that is not pre-defined (Audio, Setup…) then tap the "New" button and enter them. Now fill in the codes for each button that you recorded. You just put in the OBC value and press <Enter>, the other 2 values will be generated automatically based on the protocol you selected. Also, if you used a JP1 learning remote, there's a way to cut and paste all the codes which saves needing to enter them all. In IR, if you select File > Summary you get a page listing lots of stuff. If you scroll down, you'll see a list of learn decodes. You can cut and paste this list into Excel, then you can re-arrange the columns and just select the button names and OBC codes to cut and paste into RM. You can move the RM columns, so if the OBC column isn't the one next to the button names, you can move it there. 
:#Now tap on the Buttons Tab [[Image:RM-buttons.jpg]] This is where you map the defined functions onto the available buttons. Simply tap the Auto-Assign button which should allocate most of the buttons. For any buttons left in red drag the function name from the table on the left to the function column on the right. But note that not all these buttons are available on a Slingplayer Generic Remote. For example the 'Slow' and 'Eject' buttons do not exist on a Generic Remote. So only map the functions onto the buttons that actually exist (You will see that when you check out the Layout Tab, and from experience when you have done this a few times). The important ones to note are the Custom 10-29 buttons. These are the ones you use for the functions you need that aren't on the generic remote and they subsequently appear in the drop down menu of the remote as Custom options (except for Custom 22-26 which are pre-allocated to the colour buttons). 
:#Now tap on the Layout Tab. [[Image:RM-layout.jpg]] This shows the generic Slingplayer remote and shows the buttons you can actually use in the Buttons Tab. If a button shows yellow then that means it is in use. If it shows black (the PgUp/PgDn in the picture) then has not been allocated a function. Again you can drag and drop functions onto a button. 
:#Once you have finished experimenting go back to the Setup tab. Select the appropriate Slingbox remote, go to the 'Advanced' menu at the top and select 'Export Binary Upgrade'. This will produce the BIN file that we have discussed in previous Sections. If you aren‟t sure which Slingbox Chip you have then create a BIN file for the main 2 chips, so that would give you something like 
:::C2010_PL.BIN
:::C2010_RV.BIN

So now you can go back to [[#Installing_the_Binary_file_to_the_Slingbox.|Section 4]] and install the new Custom Remote onto your Slingbox. 

====Finding Missing Codes====
You can often find yourself in the position where the Custom Remote generally works OK but some of the functions are missing or some are sending the wrong code. This is relatively easy to fix by trial and error. The OBC codes must lie between 0-255, so the first thing to do is make a list of the OBC codes that are not being used in the Remote Control. Now use Remotemaster to allocate those codes to the 0-9 buttons and the 15 Custom buttons. Now build a new BIN files, replace the one in your \SBAV\ folder and rerun the "Setup Video Sources" routine. Now try those buttons and see if any of them action the missing function. If you find the missing codes then you can update the original remote file. You may have to repeat this operation 10 times to cover all the missing codes, although you can cut down the number of times by also using the Transport buttons (Play/Pause…) and Channel, Page +/- buttons as well. 

==Give your Binary file back to the Community==
Finally, remember that it is good to payback. If you find a remote file that works for you then upload it to the JP1 Forums. The way to do this is: 
#Put the 4 Binary files and the Remote Master RMDU file into a ZIP file. I also tend to add a Readme file in case users are unsure how to use the files. Although hopefully they will have read this article and will know what to do. 
#To be really helpful, you should upload your files in 3 different places:
##Upload your ZIP file to the [http://www.hifi-remote.com/forums/dload.php?action=category&cat_id=87 Slingbox Binary Files] area.
##Upload the Remote Master RMDU source file to the [http://www.hifi-remote.com/forums/dload.php?action=category&cat_id=98 Slingbox RM Files] area.
##Upload the RMDU file to the appropriate area in the [http://www.hifi-remote.com/forums/dload.php?action=category&cat_id=4 Device Upgrades] area.
 
I hope these instructions have been helpful. If you have any suggestions for changes or improvements please E-mail me at '''alan (at) rmrsoft (dot) com'''

How to Create Custom Remote Controls and use them on your Slingbox

2025-11-23T16:16:59Z

The Robman: /* USING AN IR WIDGET */

''Written by: Al Richey'' 

One of the most common posts on the support site is about remote codes for unsupported devices. So if you find yourself in this situation I hope this will help. Before detailing the steps to go through there are some basic things you need to understand (this isn't essential reading but everything will make much more sense if you do know the details)

==Background information==
===Different UEI Chips===
: There were five different chips used in Slingboxes. These are designated as JU, PK, PL, RV & JB. If you want to check your type you can verify your IR blaster version in the Slingbox Properties dialog. Then match the IR version number with the chip type using the chart below.
#JU (VERY old US boxes)
#PL (current US boxes)
#PK (never used)
#RV (old European boxes)
#JB (All modern Slingboxes, but compatible with PL files)

So unless you have an old European Solo all you need is the PL file.

===Slingplayer Compatibility===
: In older versions of Slingplayer it was possible to change the look of the Custom Remote skin‟. Since Slingplayer V1.5 this functionality has been removed and as far as the look of the Remote is concerned you are stuck with the Generic design produced by Sling Media. All we can do is change the codes that are sent when a specific button is pressed. One drawback of the Generic Remote is that it has only the main buttons, so extra buttons on other remotes (such as Audio/Setup…) can not be mapped directly. What we have to do is put them into a Custom Menu which is accessed by tapping on the Menu button on the Generic Remote or right-clicking on the image. (Note: If a remote image has already been produced by Sling it is possible to use that image instead of the generic image, just contact me at alan@rmrsoft.com)
:

===Setup Code Nomenclature===
: When you run the Configure Inputs routines in the various Slingplayers and select a supported device, what actually happens is that a Binary Code is downloaded to the Slingbox. 
: This Binary Code details the IR codes that are sent when a specific button is pressed on the remote. Unfortunately the native Slingbox software doesn't use separate binary files that we can edit, their codes are apparently compressed and packaged into special files that we can't do anything with (that I know of). But what we can do instead of editing the built-in codes is to use a separate external upgrade code file. These files have the format such as "C1234_PL.BIN". 
: The first letter of the file describes the type of device, the main ones we are interested in are:

::V which is for VCRs, which encompasses PVRs, DVRs and other recorders
::S which is for Satellite and FTA set top boxes
::C which is for Cable boxes
::Y which is for DVD Players

:This is followed by a 4-digit code number. For Slingboxes the code numbers can be between 0000-2047 (actually higher in newer Slingboxes but to stay safe we are better staying below 2047). In general, codes below 2000 actually relate to specific boxes, for example V0618 is the code for a TIVO and D0032 is the code for a Pioneer CD Player. But we can feel fairly safe using 2000-2047 for our own codes. The final part of the filename defines the chip for which it will run. 
: So if you were looking for the binary file for a PVR with a code number allocated 1234, designed to run on a PL-equipped Slingbox, you would be searching for a file called V1234_PL.BIN. Note: You must NEVER change the name of the file, as the letter, code number and chip type are also defined inside the file itself.

===JP1===
:You will hear a lot about "JP1". Basically this is a process whereby people using "One For All‟ (OFA) remote controls can add new codes to their remotes from their PC. The remote control processor inside the Slingbox is made by the same company that makes OFA remotes, so the upgrades are similar. The JP1 tools have been upgraded so that we can now use them to create and modify upgrades for the Slingbox.

==The Basic Procedure.==
The official procedure to follow was to report the [https://web.archive.org/web/20100605080308/http://support.slingmedia.com/get/KB-005640.html Lack of a Supported Remote] to SlingMedia and they would add it to the database. In practice, they were not quick at doing this (I have been asking for a remote for over 4 years now), and the updated remote list seems to be only occasionally updated. So it was really not a practical quick solution. So what folks need to do is to create or acquire the correct Binary code file for your A/V device, and then install it into your Slingbox. This installation process is covered in detail in [[#Installing_the_Binary_file_to_the_Slingbox|Section 4]], so first let‟s see where you can look for these files. 

==Obtaining the Binary file for the Custom Remote==

#Before starting, make sure in the setup wizard you have tried all the devices by that same manufacturer, even if the model number does not match, and all the associated code numbers. It's also worth trying your TV Provider in case they have 'badged' someone else's box. You might be lucky and find one that works and that will save a lot of work. If that doesn't solve the problem here is the step by step approach to getting hold of your binary file: 
#Go to the JP1 forum. This has a specific Download area for [https://www.hifi-remote.com/forums/dload.php?action=category&cat_id=87 Slingbox Custom Remotes], so go through all those to see if your device has already been done. 
#If it isn't there the JP1 forum also has a more general [https://www.hifi-remote.com/forums/dload.php?action=category&cat_id=4 File Download Area]. From this page you select the download area for the specific type of device and check there. If you are lucky you will find a source file for using in the program RemoteMaster (RM or KM files), the use of which is discussed in [[#Creating_your_own_Binary_files_using_RemoteMaster|Section 6]]. 
#Have a look on the Hava forums. They are also using the same chips and the files might be there. Check out this [http://www.myhava.com/forum/viewforum.php?f=17&st=0&sk=t&sd=d&start=0 forum]. You‟re looking for a PK or PL file. They can be imported into Remote Master and then converted to the PK, PL, RV or JU files for the Slingbox. Again this is discussed in [[#Creating_your_own_Binary_files_using_RemoteMaster|Section 6]]. 
#Do it yourself by buying a Nevo C2, or an IR Widget, and learn the codes needed to control the device. How to do this is covered in [[#Learning_the_IR_codes_from_your_own_remote|Section 5]] & [[#Creating_your_own_Binary_files_using_RemoteMaster|Section 6]]. 
#Ask someone else to do the work for you. You can try this by posting a request for help in either:
##The [https://community.sling.com/content Slingbox Answers Forum].
##The [https://www.hifi-remote.com/forums/viewforum.php?f=19 JP1 forum]. 
I can normally install your device on my Harmony Universal Remote to mimic the original Remote and learn the codes for you (unless I am away on holiday). 

==Installing the Binary file to the Slingbox.==
 I have written a comprehensive Installation Guide at

[https://web.archive.org/web/20161021050303/https://placeshiftingenthusiasts.com/how-to-install-a-custom-remote-onto-the-slingbox/ http://placeshiftingenthusiasts.com/how-to-install-a-custom-remote-onto-the-slingbox/]

Once you have completed the setup and the BIN files have been downloaded to the Slingbox they are not used any more and can be deleted.

==Learning the IR codes from your own remote.==
===Requirements===
Assuming you have decided to create the Remote Binary File yourself, the first stage is to learn the codes from your original Remote. This is what you need:
====Hardware====
#A computer with a USB port. 
#A A Nevo C2 Learning Remote (Available on E-Bay for $20 or so) or alternatively

:An IR learning "widget". I got mine from Tommy Tyler through [https://web.archive.org/web/20160417092406/https://www.tindie.com/products/TommyTyler/ir-widget-infrared-remote-control-signal-recorderanalyzer/ https://www.tindie.com/products/TommyTyler/ir-widget-infrared-remote-control-signal-recorderanalyzer/] (My preferred solution). 

====Software====
If you are using the Nevo C2: 
[https://sourceforge.net/projects/controlremote/ RM/RMIR.EXE] 
[https://www.hifi-remote.com/forums/dload.php?action=file&file_id=7201 RDF Files] These are support files for the program. 

If you are using an IR Widget: 
[https://www.compendiumarcana.com/irwidget/irscope.zip IRSCOPE.EXE] 
[https://www.ftdichip.com/Drivers/VCP.htm The drivers] 
[https://www.hifi-remote.com/forums/dload.php?action=file&file_id=922 The IR decode DLL] 
Or download [https://web.archive.org/web/20160305015553/http://rmrsoft.com/remote.zip my full IRSCOPE/REMOTEMASTER package]. 
Much of the JP1 software needs the java runtime environment (JRE) as well. A lot of computers will already have it installed already, but if you need it, you can [https://www.java.com/en/download/manual.jsp download] 
Now we can learn the codes. First, we will cover the procedure using a Learning Remote, then cover it using an IR Widget. 

===USING A LEARNING REMOTE===
====Getting the Codes from your Remote====
Follow the instructions to learn your remote codes so the Nevo C2 operates your device. Then download the settings file onto your PC.

====Getting the Codes onto your PC.====
 
:#Install RMIR.EXE onto your PC. It comes as a ZIP file rather than an installation package, which you need to unzip to your PC. The files can actually go anywhere but as a bit of tidy person (geek?) I created a C:\Program Files\IR\ folder and put the files in there. Now go into the folder and click on Setup.vbs and that will produce shortcuts to run RMIR and RM (Full instructions are at https://www.hifi-remote.com/wiki/index.php?title=JP1_-_Just_How_Easy_Is_It%3F_-_RM-IR_Version)
:#You will need to create a sub folder called \RDF\ in whatever folder you have put the IR program and extract the RDF support files into that folder. Again, refer to the instructions. 

Now plug your Nevo into the PC and start RMIR. Use the '''Remote > Download Remote''' menu option to get the data from the Nevo to the PC.

Under the '''Devices Tab''' you should now see the device. Select it, then use the Edit Device button and then the Save As button to produce the required RMDU file.

You can now post that file to the forum where you requested the remote, or if you want to do it yourself then go to the next Section.

===USING AN IR WIDGET===
If you are using an IR Widget there is an excellent guide [http://freepdfhosting.com/6ea1213d67.pdf here] ([https://archive.is/FEVaK archive copy]) on the Tindle site. So I suggest you download that and read it thoroughly. There is no point in repeating it here, but just to emphasise a few points: 
:#You will want to regularly check for updates to the decodeir.dll. As new protocols are recognized, this dll will change. 
:#There is no way to save the learned values for importing into RemoteMaster (where you will make the remote) so you will need to write them down. 
:#Although I tend to put programs into C:\Program Files\.... this can be a bit dodgy in Windows as programs cannot save files to this area because of security limitations. So it might be safer to install it under \Documents\ 
:#The Guide has a very useful section comparing using a Learning Remotes and the IR Widget and highlighting the differences, (For example "Key" is equivalent to "OBC") so you could check out the previous sub-section covering using IR.EXE and the Learning Remote. And then you will understand this section. When complete you can move onto [[#Creating_your_own_Binary_files_using_RemoteMaster|Section 6]] to create the Binary file. 

==Creating your own Binary files using RemoteMaster==
:#To make life easier I have packaged a full set of the latest files required and uploaded them to my site. Just download them from [http://www.rmrsoft.com/remote.zip here] and unzip them onto your computer. 
:#Start RemoteMaster.EXE. You may be promoted to highlight the folder the folder that contains the RDF files (Highlight the \RDF\ folder in the folder where you placed Remotemaster). You may also have to do the same for the Images folder. The display will now look something like this:[[Image:RM-setup.jpg]] 
:#If you have obtained an .rmdu file then use the File > Open menu option to load the file. If you have obtained a .bin file then use the Advanced > Import Binary Upgrade to load up the details. If you have not obtained a file then you will have to input the codes manually. 
:#Now to explain the main Setup Tab: '''Description ''': Use anything you like, I tend to use the device name. '''Remote''': Select the one appropriate for your chip. '''Device Type''': Should be set to the correct type of device (as covered in Paragraph 3 of Section 1). '''Setup Code''': This is where you put the 4-digit code. In theory it can be any number between 0000 and 2047, but as explained in Section 1 Paragraph 3, numbers below 2000 may actually be already allocated to specific devices, so to be safe I personally use 2010. Fell free to use your own value. '''Protocol''': From the dropdown list select the Protocol you discovered when you used IR.EXE/IRSCOPE.EXE. '''Device''': Type in the Device code you recorded from IR.EXE/IRSCOPE.EXE. '''Sub-Device''': If applicable type in the Sub-Device code you recorded from IR.EXE/ IRSCOPE.EXE. 
:#Now tap on the Functions Tab [[Image:RM-functions.jpg]] This picture shows the program with an .rmdu file or .bin file already imported; otherwise the code columns will be blank. The entries are fully configurable, so if there are pre-defined functions that you do not need (pip swap, pipmove..) then you highlight them and tap the "Delete" button. If you have a function that is not pre-defined (Audio, Setup…) then tap the "New" button and enter them. Now fill in the codes for each button that you recorded. You just put in the OBC value and press <Enter>, the other 2 values will be generated automatically based on the protocol you selected. Also, if you used a JP1 learning remote, there's a way to cut and paste all the codes which saves needing to enter them all. In IR, if you select File > Summary you get a page listing lots of stuff. If you scroll down, you'll see a list of learn decodes. You can cut and paste this list into Excel, then you can re-arrange the columns and just select the button names and OBC codes to cut and paste into RM. You can move the RM columns, so if the OBC column isn't the one next to the button names, you can move it there. 
:#Now tap on the Buttons Tab [[Image:RM-buttons.jpg]] This is where you map the defined functions onto the available buttons. Simply tap the Auto-Assign button which should allocate most of the buttons. For any buttons left in red drag the function name from the table on the left to the function column on the right. But note that not all these buttons are available on a Slingplayer Generic Remote. For example the 'Slow' and 'Eject' buttons do not exist on a Generic Remote. So only map the functions onto the buttons that actually exist (You will see that when you check out the Layout Tab, and from experience when you have done this a few times). The important ones to note are the Custom 10-29 buttons. These are the ones you use for the functions you need that aren't on the generic remote and they subsequently appear in the drop down menu of the remote as Custom options (except for Custom 22-26 which are pre-allocated to the colour buttons). 
:#Now tap on the Layout Tab. [[Image:RM-layout.jpg]] This shows the generic Slingplayer remote and shows the buttons you can actually use in the Buttons Tab. If a button shows yellow then that means it is in use. If it shows black (the PgUp/PgDn in the picture) then has not been allocated a function. Again you can drag and drop functions onto a button. 
:#Once you have finished experimenting go back to the Setup tab. Select the appropriate Slingbox remote, go to the 'Advanced' menu at the top and select 'Export Binary Upgrade'. This will produce the BIN file that we have discussed in previous Sections. If you aren‟t sure which Slingbox Chip you have then create a BIN file for the main 2 chips, so that would give you something like 
:::C2010_PL.BIN
:::C2010_RV.BIN

So now you can go back to [[#Installing_the_Binary_file_to_the_Slingbox.|Section 4]] and install the new Custom Remote onto your Slingbox. 

====Finding Missing Codes====
You can often find yourself in the position where the Custom Remote generally works OK but some of the functions are missing or some are sending the wrong code. This is relatively easy to fix by trial and error. The OBC codes must lie between 0-255, so the first thing to do is make a list of the OBC codes that are not being used in the Remote Control. Now use Remotemaster to allocate those codes to the 0-9 buttons and the 15 Custom buttons. Now build a new BIN files, replace the one in your \SBAV\ folder and rerun the "Setup Video Sources" routine. Now try those buttons and see if any of them action the missing function. If you find the missing codes then you can update the original remote file. You may have to repeat this operation 10 times to cover all the missing codes, although you can cut down the number of times by also using the Transport buttons (Play/Pause…) and Channel, Page +/- buttons as well. 

==Give your Binary file back to the Community==
Finally, remember that it is good to payback. If you find a remote file that works for you then upload it to the JP1 Forums. The way to do this is: 
#Put the 4 Binary files and the Remote Master RMDU file into a ZIP file. I also tend to add a Readme file in case users are unsure how to use the files. Although hopefully they will have read this article and will know what to do. 
#To be really helpful, you should upload your files in 3 different places:
##Upload your ZIP file to the [http://www.hifi-remote.com/forums/dload.php?action=category&cat_id=87 Slingbox Binary Files] area.
##Upload the Remote Master RMDU source file to the [http://www.hifi-remote.com/forums/dload.php?action=category&cat_id=98 Slingbox RM Files] area.
##Upload the RMDU file to the appropriate area in the [http://www.hifi-remote.com/forums/dload.php?action=category&cat_id=4 Device Upgrades] area.
 
I hope these instructions have been helpful. If you have any suggestions for changes or improvements please E-mail me at '''alan (at) rmrsoft (dot) com'''

How to Create Custom Remote Controls and use them on your Slingbox

2025-11-23T16:16:42Z

The Robman: /* USING AN IR WIDGET */

''Written by: Al Richey'' 

One of the most common posts on the support site is about remote codes for unsupported devices. So if you find yourself in this situation I hope this will help. Before detailing the steps to go through there are some basic things you need to understand (this isn't essential reading but everything will make much more sense if you do know the details)

==Background information==
===Different UEI Chips===
: There were five different chips used in Slingboxes. These are designated as JU, PK, PL, RV & JB. If you want to check your type you can verify your IR blaster version in the Slingbox Properties dialog. Then match the IR version number with the chip type using the chart below.
#JU (VERY old US boxes)
#PL (current US boxes)
#PK (never used)
#RV (old European boxes)
#JB (All modern Slingboxes, but compatible with PL files)

So unless you have an old European Solo all you need is the PL file.

===Slingplayer Compatibility===
: In older versions of Slingplayer it was possible to change the look of the Custom Remote skin‟. Since Slingplayer V1.5 this functionality has been removed and as far as the look of the Remote is concerned you are stuck with the Generic design produced by Sling Media. All we can do is change the codes that are sent when a specific button is pressed. One drawback of the Generic Remote is that it has only the main buttons, so extra buttons on other remotes (such as Audio/Setup…) can not be mapped directly. What we have to do is put them into a Custom Menu which is accessed by tapping on the Menu button on the Generic Remote or right-clicking on the image. (Note: If a remote image has already been produced by Sling it is possible to use that image instead of the generic image, just contact me at alan@rmrsoft.com)
:

===Setup Code Nomenclature===
: When you run the Configure Inputs routines in the various Slingplayers and select a supported device, what actually happens is that a Binary Code is downloaded to the Slingbox. 
: This Binary Code details the IR codes that are sent when a specific button is pressed on the remote. Unfortunately the native Slingbox software doesn't use separate binary files that we can edit, their codes are apparently compressed and packaged into special files that we can't do anything with (that I know of). But what we can do instead of editing the built-in codes is to use a separate external upgrade code file. These files have the format such as "C1234_PL.BIN". 
: The first letter of the file describes the type of device, the main ones we are interested in are:

::V which is for VCRs, which encompasses PVRs, DVRs and other recorders
::S which is for Satellite and FTA set top boxes
::C which is for Cable boxes
::Y which is for DVD Players

:This is followed by a 4-digit code number. For Slingboxes the code numbers can be between 0000-2047 (actually higher in newer Slingboxes but to stay safe we are better staying below 2047). In general, codes below 2000 actually relate to specific boxes, for example V0618 is the code for a TIVO and D0032 is the code for a Pioneer CD Player. But we can feel fairly safe using 2000-2047 for our own codes. The final part of the filename defines the chip for which it will run. 
: So if you were looking for the binary file for a PVR with a code number allocated 1234, designed to run on a PL-equipped Slingbox, you would be searching for a file called V1234_PL.BIN. Note: You must NEVER change the name of the file, as the letter, code number and chip type are also defined inside the file itself.

===JP1===
:You will hear a lot about "JP1". Basically this is a process whereby people using "One For All‟ (OFA) remote controls can add new codes to their remotes from their PC. The remote control processor inside the Slingbox is made by the same company that makes OFA remotes, so the upgrades are similar. The JP1 tools have been upgraded so that we can now use them to create and modify upgrades for the Slingbox.

==The Basic Procedure.==
The official procedure to follow was to report the [https://web.archive.org/web/20100605080308/http://support.slingmedia.com/get/KB-005640.html Lack of a Supported Remote] to SlingMedia and they would add it to the database. In practice, they were not quick at doing this (I have been asking for a remote for over 4 years now), and the updated remote list seems to be only occasionally updated. So it was really not a practical quick solution. So what folks need to do is to create or acquire the correct Binary code file for your A/V device, and then install it into your Slingbox. This installation process is covered in detail in [[#Installing_the_Binary_file_to_the_Slingbox|Section 4]], so first let‟s see where you can look for these files. 

==Obtaining the Binary file for the Custom Remote==

#Before starting, make sure in the setup wizard you have tried all the devices by that same manufacturer, even if the model number does not match, and all the associated code numbers. It's also worth trying your TV Provider in case they have 'badged' someone else's box. You might be lucky and find one that works and that will save a lot of work. If that doesn't solve the problem here is the step by step approach to getting hold of your binary file: 
#Go to the JP1 forum. This has a specific Download area for [https://www.hifi-remote.com/forums/dload.php?action=category&cat_id=87 Slingbox Custom Remotes], so go through all those to see if your device has already been done. 
#If it isn't there the JP1 forum also has a more general [https://www.hifi-remote.com/forums/dload.php?action=category&cat_id=4 File Download Area]. From this page you select the download area for the specific type of device and check there. If you are lucky you will find a source file for using in the program RemoteMaster (RM or KM files), the use of which is discussed in [[#Creating_your_own_Binary_files_using_RemoteMaster|Section 6]]. 
#Have a look on the Hava forums. They are also using the same chips and the files might be there. Check out this [http://www.myhava.com/forum/viewforum.php?f=17&st=0&sk=t&sd=d&start=0 forum]. You‟re looking for a PK or PL file. They can be imported into Remote Master and then converted to the PK, PL, RV or JU files for the Slingbox. Again this is discussed in [[#Creating_your_own_Binary_files_using_RemoteMaster|Section 6]]. 
#Do it yourself by buying a Nevo C2, or an IR Widget, and learn the codes needed to control the device. How to do this is covered in [[#Learning_the_IR_codes_from_your_own_remote|Section 5]] & [[#Creating_your_own_Binary_files_using_RemoteMaster|Section 6]]. 
#Ask someone else to do the work for you. You can try this by posting a request for help in either:
##The [https://community.sling.com/content Slingbox Answers Forum].
##The [https://www.hifi-remote.com/forums/viewforum.php?f=19 JP1 forum]. 
I can normally install your device on my Harmony Universal Remote to mimic the original Remote and learn the codes for you (unless I am away on holiday). 

==Installing the Binary file to the Slingbox.==
 I have written a comprehensive Installation Guide at

[https://web.archive.org/web/20161021050303/https://placeshiftingenthusiasts.com/how-to-install-a-custom-remote-onto-the-slingbox/ http://placeshiftingenthusiasts.com/how-to-install-a-custom-remote-onto-the-slingbox/]

Once you have completed the setup and the BIN files have been downloaded to the Slingbox they are not used any more and can be deleted.

==Learning the IR codes from your own remote.==
===Requirements===
Assuming you have decided to create the Remote Binary File yourself, the first stage is to learn the codes from your original Remote. This is what you need:
====Hardware====
#A computer with a USB port. 
#A A Nevo C2 Learning Remote (Available on E-Bay for $20 or so) or alternatively

:An IR learning "widget". I got mine from Tommy Tyler through [https://web.archive.org/web/20160417092406/https://www.tindie.com/products/TommyTyler/ir-widget-infrared-remote-control-signal-recorderanalyzer/ https://www.tindie.com/products/TommyTyler/ir-widget-infrared-remote-control-signal-recorderanalyzer/] (My preferred solution). 

====Software====
If you are using the Nevo C2: 
[https://sourceforge.net/projects/controlremote/ RM/RMIR.EXE] 
[https://www.hifi-remote.com/forums/dload.php?action=file&file_id=7201 RDF Files] These are support files for the program. 

If you are using an IR Widget: 
[https://www.compendiumarcana.com/irwidget/irscope.zip IRSCOPE.EXE] 
[https://www.ftdichip.com/Drivers/VCP.htm The drivers] 
[https://www.hifi-remote.com/forums/dload.php?action=file&file_id=922 The IR decode DLL] 
Or download [https://web.archive.org/web/20160305015553/http://rmrsoft.com/remote.zip my full IRSCOPE/REMOTEMASTER package]. 
Much of the JP1 software needs the java runtime environment (JRE) as well. A lot of computers will already have it installed already, but if you need it, you can [https://www.java.com/en/download/manual.jsp download] 
Now we can learn the codes. First, we will cover the procedure using a Learning Remote, then cover it using an IR Widget. 

===USING A LEARNING REMOTE===
====Getting the Codes from your Remote====
Follow the instructions to learn your remote codes so the Nevo C2 operates your device. Then download the settings file onto your PC.

====Getting the Codes onto your PC.====
 
:#Install RMIR.EXE onto your PC. It comes as a ZIP file rather than an installation package, which you need to unzip to your PC. The files can actually go anywhere but as a bit of tidy person (geek?) I created a C:\Program Files\IR\ folder and put the files in there. Now go into the folder and click on Setup.vbs and that will produce shortcuts to run RMIR and RM (Full instructions are at https://www.hifi-remote.com/wiki/index.php?title=JP1_-_Just_How_Easy_Is_It%3F_-_RM-IR_Version)
:#You will need to create a sub folder called \RDF\ in whatever folder you have put the IR program and extract the RDF support files into that folder. Again, refer to the instructions. 

Now plug your Nevo into the PC and start RMIR. Use the '''Remote > Download Remote''' menu option to get the data from the Nevo to the PC.

Under the '''Devices Tab''' you should now see the device. Select it, then use the Edit Device button and then the Save As button to produce the required RMDU file.

You can now post that file to the forum where you requested the remote, or if you want to do it yourself then go to the next Section.

===USING AN IR WIDGET===
If you are using an IR Widget there is an excellent guide [http://freepdfhosting.com/6ea1213d67.pdf here] ([https://archive.is/FEVaK arhive copy]) on the Tindle site. So I suggest you download that and read it thoroughly. There is no point in repeating it here, but just to emphasise a few points: 
:#You will want to regularly check for updates to the decodeir.dll. As new protocols are recognized, this dll will change. 
:#There is no way to save the learned values for importing into RemoteMaster (where you will make the remote) so you will need to write them down. 
:#Although I tend to put programs into C:\Program Files\.... this can be a bit dodgy in Windows as programs cannot save files to this area because of security limitations. So it might be safer to install it under \Documents\ 
:#The Guide has a very useful section comparing using a Learning Remotes and the IR Widget and highlighting the differences, (For example "Key" is equivalent to "OBC") so you could check out the previous sub-section covering using IR.EXE and the Learning Remote. And then you will understand this section. When complete you can move onto [[#Creating_your_own_Binary_files_using_RemoteMaster|Section 6]] to create the Binary file. 

==Creating your own Binary files using RemoteMaster==
:#To make life easier I have packaged a full set of the latest files required and uploaded them to my site. Just download them from [http://www.rmrsoft.com/remote.zip here] and unzip them onto your computer. 
:#Start RemoteMaster.EXE. You may be promoted to highlight the folder the folder that contains the RDF files (Highlight the \RDF\ folder in the folder where you placed Remotemaster). You may also have to do the same for the Images folder. The display will now look something like this:[[Image:RM-setup.jpg]] 
:#If you have obtained an .rmdu file then use the File > Open menu option to load the file. If you have obtained a .bin file then use the Advanced > Import Binary Upgrade to load up the details. If you have not obtained a file then you will have to input the codes manually. 
:#Now to explain the main Setup Tab: '''Description ''': Use anything you like, I tend to use the device name. '''Remote''': Select the one appropriate for your chip. '''Device Type''': Should be set to the correct type of device (as covered in Paragraph 3 of Section 1). '''Setup Code''': This is where you put the 4-digit code. In theory it can be any number between 0000 and 2047, but as explained in Section 1 Paragraph 3, numbers below 2000 may actually be already allocated to specific devices, so to be safe I personally use 2010. Fell free to use your own value. '''Protocol''': From the dropdown list select the Protocol you discovered when you used IR.EXE/IRSCOPE.EXE. '''Device''': Type in the Device code you recorded from IR.EXE/IRSCOPE.EXE. '''Sub-Device''': If applicable type in the Sub-Device code you recorded from IR.EXE/ IRSCOPE.EXE. 
:#Now tap on the Functions Tab [[Image:RM-functions.jpg]] This picture shows the program with an .rmdu file or .bin file already imported; otherwise the code columns will be blank. The entries are fully configurable, so if there are pre-defined functions that you do not need (pip swap, pipmove..) then you highlight them and tap the "Delete" button. If you have a function that is not pre-defined (Audio, Setup…) then tap the "New" button and enter them. Now fill in the codes for each button that you recorded. You just put in the OBC value and press <Enter>, the other 2 values will be generated automatically based on the protocol you selected. Also, if you used a JP1 learning remote, there's a way to cut and paste all the codes which saves needing to enter them all. In IR, if you select File > Summary you get a page listing lots of stuff. If you scroll down, you'll see a list of learn decodes. You can cut and paste this list into Excel, then you can re-arrange the columns and just select the button names and OBC codes to cut and paste into RM. You can move the RM columns, so if the OBC column isn't the one next to the button names, you can move it there. 
:#Now tap on the Buttons Tab [[Image:RM-buttons.jpg]] This is where you map the defined functions onto the available buttons. Simply tap the Auto-Assign button which should allocate most of the buttons. For any buttons left in red drag the function name from the table on the left to the function column on the right. But note that not all these buttons are available on a Slingplayer Generic Remote. For example the 'Slow' and 'Eject' buttons do not exist on a Generic Remote. So only map the functions onto the buttons that actually exist (You will see that when you check out the Layout Tab, and from experience when you have done this a few times). The important ones to note are the Custom 10-29 buttons. These are the ones you use for the functions you need that aren't on the generic remote and they subsequently appear in the drop down menu of the remote as Custom options (except for Custom 22-26 which are pre-allocated to the colour buttons). 
:#Now tap on the Layout Tab. [[Image:RM-layout.jpg]] This shows the generic Slingplayer remote and shows the buttons you can actually use in the Buttons Tab. If a button shows yellow then that means it is in use. If it shows black (the PgUp/PgDn in the picture) then has not been allocated a function. Again you can drag and drop functions onto a button. 
:#Once you have finished experimenting go back to the Setup tab. Select the appropriate Slingbox remote, go to the 'Advanced' menu at the top and select 'Export Binary Upgrade'. This will produce the BIN file that we have discussed in previous Sections. If you aren‟t sure which Slingbox Chip you have then create a BIN file for the main 2 chips, so that would give you something like 
:::C2010_PL.BIN
:::C2010_RV.BIN

So now you can go back to [[#Installing_the_Binary_file_to_the_Slingbox.|Section 4]] and install the new Custom Remote onto your Slingbox. 

====Finding Missing Codes====
You can often find yourself in the position where the Custom Remote generally works OK but some of the functions are missing or some are sending the wrong code. This is relatively easy to fix by trial and error. The OBC codes must lie between 0-255, so the first thing to do is make a list of the OBC codes that are not being used in the Remote Control. Now use Remotemaster to allocate those codes to the 0-9 buttons and the 15 Custom buttons. Now build a new BIN files, replace the one in your \SBAV\ folder and rerun the "Setup Video Sources" routine. Now try those buttons and see if any of them action the missing function. If you find the missing codes then you can update the original remote file. You may have to repeat this operation 10 times to cover all the missing codes, although you can cut down the number of times by also using the Transport buttons (Play/Pause…) and Channel, Page +/- buttons as well. 

==Give your Binary file back to the Community==
Finally, remember that it is good to payback. If you find a remote file that works for you then upload it to the JP1 Forums. The way to do this is: 
#Put the 4 Binary files and the Remote Master RMDU file into a ZIP file. I also tend to add a Readme file in case users are unsure how to use the files. Although hopefully they will have read this article and will know what to do. 
#To be really helpful, you should upload your files in 3 different places:
##Upload your ZIP file to the [http://www.hifi-remote.com/forums/dload.php?action=category&cat_id=87 Slingbox Binary Files] area.
##Upload the Remote Master RMDU source file to the [http://www.hifi-remote.com/forums/dload.php?action=category&cat_id=98 Slingbox RM Files] area.
##Upload the RMDU file to the appropriate area in the [http://www.hifi-remote.com/forums/dload.php?action=category&cat_id=4 Device Upgrades] area.
 
I hope these instructions have been helpful. If you have any suggestions for changes or improvements please E-mail me at '''alan (at) rmrsoft (dot) com'''

How to Create Custom Remote Controls and use them on your Slingbox

2025-11-23T16:11:39Z

The Robman: /* Software */

''Written by: Al Richey'' 

One of the most common posts on the support site is about remote codes for unsupported devices. So if you find yourself in this situation I hope this will help. Before detailing the steps to go through there are some basic things you need to understand (this isn't essential reading but everything will make much more sense if you do know the details)

==Background information==
===Different UEI Chips===
: There were five different chips used in Slingboxes. These are designated as JU, PK, PL, RV & JB. If you want to check your type you can verify your IR blaster version in the Slingbox Properties dialog. Then match the IR version number with the chip type using the chart below.
#JU (VERY old US boxes)
#PL (current US boxes)
#PK (never used)
#RV (old European boxes)
#JB (All modern Slingboxes, but compatible with PL files)

So unless you have an old European Solo all you need is the PL file.

===Slingplayer Compatibility===
: In older versions of Slingplayer it was possible to change the look of the Custom Remote skin‟. Since Slingplayer V1.5 this functionality has been removed and as far as the look of the Remote is concerned you are stuck with the Generic design produced by Sling Media. All we can do is change the codes that are sent when a specific button is pressed. One drawback of the Generic Remote is that it has only the main buttons, so extra buttons on other remotes (such as Audio/Setup…) can not be mapped directly. What we have to do is put them into a Custom Menu which is accessed by tapping on the Menu button on the Generic Remote or right-clicking on the image. (Note: If a remote image has already been produced by Sling it is possible to use that image instead of the generic image, just contact me at alan@rmrsoft.com)
:

===Setup Code Nomenclature===
: When you run the Configure Inputs routines in the various Slingplayers and select a supported device, what actually happens is that a Binary Code is downloaded to the Slingbox. 
: This Binary Code details the IR codes that are sent when a specific button is pressed on the remote. Unfortunately the native Slingbox software doesn't use separate binary files that we can edit, their codes are apparently compressed and packaged into special files that we can't do anything with (that I know of). But what we can do instead of editing the built-in codes is to use a separate external upgrade code file. These files have the format such as "C1234_PL.BIN". 
: The first letter of the file describes the type of device, the main ones we are interested in are:

::V which is for VCRs, which encompasses PVRs, DVRs and other recorders
::S which is for Satellite and FTA set top boxes
::C which is for Cable boxes
::Y which is for DVD Players

:This is followed by a 4-digit code number. For Slingboxes the code numbers can be between 0000-2047 (actually higher in newer Slingboxes but to stay safe we are better staying below 2047). In general, codes below 2000 actually relate to specific boxes, for example V0618 is the code for a TIVO and D0032 is the code for a Pioneer CD Player. But we can feel fairly safe using 2000-2047 for our own codes. The final part of the filename defines the chip for which it will run. 
: So if you were looking for the binary file for a PVR with a code number allocated 1234, designed to run on a PL-equipped Slingbox, you would be searching for a file called V1234_PL.BIN. Note: You must NEVER change the name of the file, as the letter, code number and chip type are also defined inside the file itself.

===JP1===
:You will hear a lot about "JP1". Basically this is a process whereby people using "One For All‟ (OFA) remote controls can add new codes to their remotes from their PC. The remote control processor inside the Slingbox is made by the same company that makes OFA remotes, so the upgrades are similar. The JP1 tools have been upgraded so that we can now use them to create and modify upgrades for the Slingbox.

==The Basic Procedure.==
The official procedure to follow was to report the [https://web.archive.org/web/20100605080308/http://support.slingmedia.com/get/KB-005640.html Lack of a Supported Remote] to SlingMedia and they would add it to the database. In practice, they were not quick at doing this (I have been asking for a remote for over 4 years now), and the updated remote list seems to be only occasionally updated. So it was really not a practical quick solution. So what folks need to do is to create or acquire the correct Binary code file for your A/V device, and then install it into your Slingbox. This installation process is covered in detail in [[#Installing_the_Binary_file_to_the_Slingbox|Section 4]], so first let‟s see where you can look for these files. 

==Obtaining the Binary file for the Custom Remote==

#Before starting, make sure in the setup wizard you have tried all the devices by that same manufacturer, even if the model number does not match, and all the associated code numbers. It's also worth trying your TV Provider in case they have 'badged' someone else's box. You might be lucky and find one that works and that will save a lot of work. If that doesn't solve the problem here is the step by step approach to getting hold of your binary file: 
#Go to the JP1 forum. This has a specific Download area for [https://www.hifi-remote.com/forums/dload.php?action=category&cat_id=87 Slingbox Custom Remotes], so go through all those to see if your device has already been done. 
#If it isn't there the JP1 forum also has a more general [https://www.hifi-remote.com/forums/dload.php?action=category&cat_id=4 File Download Area]. From this page you select the download area for the specific type of device and check there. If you are lucky you will find a source file for using in the program RemoteMaster (RM or KM files), the use of which is discussed in [[#Creating_your_own_Binary_files_using_RemoteMaster|Section 6]]. 
#Have a look on the Hava forums. They are also using the same chips and the files might be there. Check out this [http://www.myhava.com/forum/viewforum.php?f=17&st=0&sk=t&sd=d&start=0 forum]. You‟re looking for a PK or PL file. They can be imported into Remote Master and then converted to the PK, PL, RV or JU files for the Slingbox. Again this is discussed in [[#Creating_your_own_Binary_files_using_RemoteMaster|Section 6]]. 
#Do it yourself by buying a Nevo C2, or an IR Widget, and learn the codes needed to control the device. How to do this is covered in [[#Learning_the_IR_codes_from_your_own_remote|Section 5]] & [[#Creating_your_own_Binary_files_using_RemoteMaster|Section 6]]. 
#Ask someone else to do the work for you. You can try this by posting a request for help in either:
##The [https://community.sling.com/content Slingbox Answers Forum].
##The [https://www.hifi-remote.com/forums/viewforum.php?f=19 JP1 forum]. 
I can normally install your device on my Harmony Universal Remote to mimic the original Remote and learn the codes for you (unless I am away on holiday). 

==Installing the Binary file to the Slingbox.==
 I have written a comprehensive Installation Guide at

[https://web.archive.org/web/20161021050303/https://placeshiftingenthusiasts.com/how-to-install-a-custom-remote-onto-the-slingbox/ http://placeshiftingenthusiasts.com/how-to-install-a-custom-remote-onto-the-slingbox/]

Once you have completed the setup and the BIN files have been downloaded to the Slingbox they are not used any more and can be deleted.

==Learning the IR codes from your own remote.==
===Requirements===
Assuming you have decided to create the Remote Binary File yourself, the first stage is to learn the codes from your original Remote. This is what you need:
====Hardware====
#A computer with a USB port. 
#A A Nevo C2 Learning Remote (Available on E-Bay for $20 or so) or alternatively

:An IR learning "widget". I got mine from Tommy Tyler through [https://web.archive.org/web/20160417092406/https://www.tindie.com/products/TommyTyler/ir-widget-infrared-remote-control-signal-recorderanalyzer/ https://www.tindie.com/products/TommyTyler/ir-widget-infrared-remote-control-signal-recorderanalyzer/] (My preferred solution). 

====Software====
If you are using the Nevo C2: 
[https://sourceforge.net/projects/controlremote/ RM/RMIR.EXE] 
[https://www.hifi-remote.com/forums/dload.php?action=file&file_id=7201 RDF Files] These are support files for the program. 

If you are using an IR Widget: 
[https://www.compendiumarcana.com/irwidget/irscope.zip IRSCOPE.EXE] 
[https://www.ftdichip.com/Drivers/VCP.htm The drivers] 
[https://www.hifi-remote.com/forums/dload.php?action=file&file_id=922 The IR decode DLL] 
Or download [https://web.archive.org/web/20160305015553/http://rmrsoft.com/remote.zip my full IRSCOPE/REMOTEMASTER package]. 
Much of the JP1 software needs the java runtime environment (JRE) as well. A lot of computers will already have it installed already, but if you need it, you can [https://www.java.com/en/download/manual.jsp download] 
Now we can learn the codes. First, we will cover the procedure using a Learning Remote, then cover it using an IR Widget. 

===USING A LEARNING REMOTE===
====Getting the Codes from your Remote====
Follow the instructions to learn your remote codes so the Nevo C2 operates your device. Then download the settings file onto your PC.

====Getting the Codes onto your PC.====
 
:#Install RMIR.EXE onto your PC. It comes as a ZIP file rather than an installation package, which you need to unzip to your PC. The files can actually go anywhere but as a bit of tidy person (geek?) I created a C:\Program Files\IR\ folder and put the files in there. Now go into the folder and click on Setup.vbs and that will produce shortcuts to run RMIR and RM (Full instructions are at https://www.hifi-remote.com/wiki/index.php?title=JP1_-_Just_How_Easy_Is_It%3F_-_RM-IR_Version)
:#You will need to create a sub folder called \RDF\ in whatever folder you have put the IR program and extract the RDF support files into that folder. Again, refer to the instructions. 

Now plug your Nevo into the PC and start RMIR. Use the '''Remote > Download Remote''' menu option to get the data from the Nevo to the PC.

Under the '''Devices Tab''' you should now see the device. Select it, then use the Edit Device button and then the Save As button to produce the required RMDU file.

You can now post that file to the forum where you requested the remote, or if you want to do it yourself then go to the next Section.

===USING AN IR WIDGET===
If you are using an IR Widget there is an excellent guide [http://freepdfhosting.com/6ea1213d67.pdf here] on the Tindle site. So I suggest you download that and read it thoroughly. There is no point in repeating it here, but just to emphasise a few points: 
:#You will want to regularly check for updates to the decodeir.dll. As new protocols are recognized, this dll will change. 
:#There is no way to save the learned values for importing into RemoteMaster (where you will make the remote) so you will need to write them down. 
:#Although I tend to put programs into C:\Program Files\.... this can be a bit dodgy in Windows as programs cannot save files to this area because of security limitations. So it might be safer to install it under \Documents\ 
:#The Guide has a very useful section comparing using a Learning Remotes and the IR Widget and highlighting the differences, (For example "Key" is equivalent to "OBC") so you could check out the previous sub-section covering using IR.EXE and the Learning Remote. And then you will understand this section. When complete you can move onto [[#Creating_your_own_Binary_files_using_RemoteMaster|Section 6]] to create the Binary file. 

==Creating your own Binary files using RemoteMaster==
:#To make life easier I have packaged a full set of the latest files required and uploaded them to my site. Just download them from [http://www.rmrsoft.com/remote.zip here] and unzip them onto your computer. 
:#Start RemoteMaster.EXE. You may be promoted to highlight the folder the folder that contains the RDF files (Highlight the \RDF\ folder in the folder where you placed Remotemaster). You may also have to do the same for the Images folder. The display will now look something like this:[[Image:RM-setup.jpg]] 
:#If you have obtained an .rmdu file then use the File > Open menu option to load the file. If you have obtained a .bin file then use the Advanced > Import Binary Upgrade to load up the details. If you have not obtained a file then you will have to input the codes manually. 
:#Now to explain the main Setup Tab: '''Description ''': Use anything you like, I tend to use the device name. '''Remote''': Select the one appropriate for your chip. '''Device Type''': Should be set to the correct type of device (as covered in Paragraph 3 of Section 1). '''Setup Code''': This is where you put the 4-digit code. In theory it can be any number between 0000 and 2047, but as explained in Section 1 Paragraph 3, numbers below 2000 may actually be already allocated to specific devices, so to be safe I personally use 2010. Fell free to use your own value. '''Protocol''': From the dropdown list select the Protocol you discovered when you used IR.EXE/IRSCOPE.EXE. '''Device''': Type in the Device code you recorded from IR.EXE/IRSCOPE.EXE. '''Sub-Device''': If applicable type in the Sub-Device code you recorded from IR.EXE/ IRSCOPE.EXE. 
:#Now tap on the Functions Tab [[Image:RM-functions.jpg]] This picture shows the program with an .rmdu file or .bin file already imported; otherwise the code columns will be blank. The entries are fully configurable, so if there are pre-defined functions that you do not need (pip swap, pipmove..) then you highlight them and tap the "Delete" button. If you have a function that is not pre-defined (Audio, Setup…) then tap the "New" button and enter them. Now fill in the codes for each button that you recorded. You just put in the OBC value and press <Enter>, the other 2 values will be generated automatically based on the protocol you selected. Also, if you used a JP1 learning remote, there's a way to cut and paste all the codes which saves needing to enter them all. In IR, if you select File > Summary you get a page listing lots of stuff. If you scroll down, you'll see a list of learn decodes. You can cut and paste this list into Excel, then you can re-arrange the columns and just select the button names and OBC codes to cut and paste into RM. You can move the RM columns, so if the OBC column isn't the one next to the button names, you can move it there. 
:#Now tap on the Buttons Tab [[Image:RM-buttons.jpg]] This is where you map the defined functions onto the available buttons. Simply tap the Auto-Assign button which should allocate most of the buttons. For any buttons left in red drag the function name from the table on the left to the function column on the right. But note that not all these buttons are available on a Slingplayer Generic Remote. For example the 'Slow' and 'Eject' buttons do not exist on a Generic Remote. So only map the functions onto the buttons that actually exist (You will see that when you check out the Layout Tab, and from experience when you have done this a few times). The important ones to note are the Custom 10-29 buttons. These are the ones you use for the functions you need that aren't on the generic remote and they subsequently appear in the drop down menu of the remote as Custom options (except for Custom 22-26 which are pre-allocated to the colour buttons). 
:#Now tap on the Layout Tab. [[Image:RM-layout.jpg]] This shows the generic Slingplayer remote and shows the buttons you can actually use in the Buttons Tab. If a button shows yellow then that means it is in use. If it shows black (the PgUp/PgDn in the picture) then has not been allocated a function. Again you can drag and drop functions onto a button. 
:#Once you have finished experimenting go back to the Setup tab. Select the appropriate Slingbox remote, go to the 'Advanced' menu at the top and select 'Export Binary Upgrade'. This will produce the BIN file that we have discussed in previous Sections. If you aren‟t sure which Slingbox Chip you have then create a BIN file for the main 2 chips, so that would give you something like 
:::C2010_PL.BIN
:::C2010_RV.BIN

So now you can go back to [[#Installing_the_Binary_file_to_the_Slingbox.|Section 4]] and install the new Custom Remote onto your Slingbox. 

====Finding Missing Codes====
You can often find yourself in the position where the Custom Remote generally works OK but some of the functions are missing or some are sending the wrong code. This is relatively easy to fix by trial and error. The OBC codes must lie between 0-255, so the first thing to do is make a list of the OBC codes that are not being used in the Remote Control. Now use Remotemaster to allocate those codes to the 0-9 buttons and the 15 Custom buttons. Now build a new BIN files, replace the one in your \SBAV\ folder and rerun the "Setup Video Sources" routine. Now try those buttons and see if any of them action the missing function. If you find the missing codes then you can update the original remote file. You may have to repeat this operation 10 times to cover all the missing codes, although you can cut down the number of times by also using the Transport buttons (Play/Pause…) and Channel, Page +/- buttons as well. 

==Give your Binary file back to the Community==
Finally, remember that it is good to payback. If you find a remote file that works for you then upload it to the JP1 Forums. The way to do this is: 
#Put the 4 Binary files and the Remote Master RMDU file into a ZIP file. I also tend to add a Readme file in case users are unsure how to use the files. Although hopefully they will have read this article and will know what to do. 
#To be really helpful, you should upload your files in 3 different places:
##Upload your ZIP file to the [http://www.hifi-remote.com/forums/dload.php?action=category&cat_id=87 Slingbox Binary Files] area.
##Upload the Remote Master RMDU source file to the [http://www.hifi-remote.com/forums/dload.php?action=category&cat_id=98 Slingbox RM Files] area.
##Upload the RMDU file to the appropriate area in the [http://www.hifi-remote.com/forums/dload.php?action=category&cat_id=4 Device Upgrades] area.
 
I hope these instructions have been helpful. If you have any suggestions for changes or improvements please E-mail me at '''alan (at) rmrsoft (dot) com'''

How to Create Custom Remote Controls and use them on your Slingbox

2025-11-23T15:54:29Z

The Robman: /* Learning the IR codes from your own remote. */

''Written by: Al Richey'' 

One of the most common posts on the support site is about remote codes for unsupported devices. So if you find yourself in this situation I hope this will help. Before detailing the steps to go through there are some basic things you need to understand (this isn't essential reading but everything will make much more sense if you do know the details)

==Background information==
===Different UEI Chips===
: There were five different chips used in Slingboxes. These are designated as JU, PK, PL, RV & JB. If you want to check your type you can verify your IR blaster version in the Slingbox Properties dialog. Then match the IR version number with the chip type using the chart below.
#JU (VERY old US boxes)
#PL (current US boxes)
#PK (never used)
#RV (old European boxes)
#JB (All modern Slingboxes, but compatible with PL files)

So unless you have an old European Solo all you need is the PL file.

===Slingplayer Compatibility===
: In older versions of Slingplayer it was possible to change the look of the Custom Remote skin‟. Since Slingplayer V1.5 this functionality has been removed and as far as the look of the Remote is concerned you are stuck with the Generic design produced by Sling Media. All we can do is change the codes that are sent when a specific button is pressed. One drawback of the Generic Remote is that it has only the main buttons, so extra buttons on other remotes (such as Audio/Setup…) can not be mapped directly. What we have to do is put them into a Custom Menu which is accessed by tapping on the Menu button on the Generic Remote or right-clicking on the image. (Note: If a remote image has already been produced by Sling it is possible to use that image instead of the generic image, just contact me at alan@rmrsoft.com)
:

===Setup Code Nomenclature===
: When you run the Configure Inputs routines in the various Slingplayers and select a supported device, what actually happens is that a Binary Code is downloaded to the Slingbox. 
: This Binary Code details the IR codes that are sent when a specific button is pressed on the remote. Unfortunately the native Slingbox software doesn't use separate binary files that we can edit, their codes are apparently compressed and packaged into special files that we can't do anything with (that I know of). But what we can do instead of editing the built-in codes is to use a separate external upgrade code file. These files have the format such as "C1234_PL.BIN". 
: The first letter of the file describes the type of device, the main ones we are interested in are:

::V which is for VCRs, which encompasses PVRs, DVRs and other recorders
::S which is for Satellite and FTA set top boxes
::C which is for Cable boxes
::Y which is for DVD Players

:This is followed by a 4-digit code number. For Slingboxes the code numbers can be between 0000-2047 (actually higher in newer Slingboxes but to stay safe we are better staying below 2047). In general, codes below 2000 actually relate to specific boxes, for example V0618 is the code for a TIVO and D0032 is the code for a Pioneer CD Player. But we can feel fairly safe using 2000-2047 for our own codes. The final part of the filename defines the chip for which it will run. 
: So if you were looking for the binary file for a PVR with a code number allocated 1234, designed to run on a PL-equipped Slingbox, you would be searching for a file called V1234_PL.BIN. Note: You must NEVER change the name of the file, as the letter, code number and chip type are also defined inside the file itself.

===JP1===
:You will hear a lot about "JP1". Basically this is a process whereby people using "One For All‟ (OFA) remote controls can add new codes to their remotes from their PC. The remote control processor inside the Slingbox is made by the same company that makes OFA remotes, so the upgrades are similar. The JP1 tools have been upgraded so that we can now use them to create and modify upgrades for the Slingbox.

==The Basic Procedure.==
The official procedure to follow was to report the [https://web.archive.org/web/20100605080308/http://support.slingmedia.com/get/KB-005640.html Lack of a Supported Remote] to SlingMedia and they would add it to the database. In practice, they were not quick at doing this (I have been asking for a remote for over 4 years now), and the updated remote list seems to be only occasionally updated. So it was really not a practical quick solution. So what folks need to do is to create or acquire the correct Binary code file for your A/V device, and then install it into your Slingbox. This installation process is covered in detail in [[#Installing_the_Binary_file_to_the_Slingbox|Section 4]], so first let‟s see where you can look for these files. 

==Obtaining the Binary file for the Custom Remote==

#Before starting, make sure in the setup wizard you have tried all the devices by that same manufacturer, even if the model number does not match, and all the associated code numbers. It's also worth trying your TV Provider in case they have 'badged' someone else's box. You might be lucky and find one that works and that will save a lot of work. If that doesn't solve the problem here is the step by step approach to getting hold of your binary file: 
#Go to the JP1 forum. This has a specific Download area for [https://www.hifi-remote.com/forums/dload.php?action=category&cat_id=87 Slingbox Custom Remotes], so go through all those to see if your device has already been done. 
#If it isn't there the JP1 forum also has a more general [https://www.hifi-remote.com/forums/dload.php?action=category&cat_id=4 File Download Area]. From this page you select the download area for the specific type of device and check there. If you are lucky you will find a source file for using in the program RemoteMaster (RM or KM files), the use of which is discussed in [[#Creating_your_own_Binary_files_using_RemoteMaster|Section 6]]. 
#Have a look on the Hava forums. They are also using the same chips and the files might be there. Check out this [http://www.myhava.com/forum/viewforum.php?f=17&st=0&sk=t&sd=d&start=0 forum]. You‟re looking for a PK or PL file. They can be imported into Remote Master and then converted to the PK, PL, RV or JU files for the Slingbox. Again this is discussed in [[#Creating_your_own_Binary_files_using_RemoteMaster|Section 6]]. 
#Do it yourself by buying a Nevo C2, or an IR Widget, and learn the codes needed to control the device. How to do this is covered in [[#Learning_the_IR_codes_from_your_own_remote|Section 5]] & [[#Creating_your_own_Binary_files_using_RemoteMaster|Section 6]]. 
#Ask someone else to do the work for you. You can try this by posting a request for help in either:
##The [https://community.sling.com/content Slingbox Answers Forum].
##The [https://www.hifi-remote.com/forums/viewforum.php?f=19 JP1 forum]. 
I can normally install your device on my Harmony Universal Remote to mimic the original Remote and learn the codes for you (unless I am away on holiday). 

==Installing the Binary file to the Slingbox.==
 I have written a comprehensive Installation Guide at

[https://web.archive.org/web/20161021050303/https://placeshiftingenthusiasts.com/how-to-install-a-custom-remote-onto-the-slingbox/ http://placeshiftingenthusiasts.com/how-to-install-a-custom-remote-onto-the-slingbox/]

Once you have completed the setup and the BIN files have been downloaded to the Slingbox they are not used any more and can be deleted.

==Learning the IR codes from your own remote.==
===Requirements===
Assuming you have decided to create the Remote Binary File yourself, the first stage is to learn the codes from your original Remote. This is what you need:
====Hardware====
#A computer with a USB port. 
#A A Nevo C2 Learning Remote (Available on E-Bay for $20 or so) or alternatively

:An IR learning "widget". I got mine from Tommy Tyler through [https://web.archive.org/web/20160417092406/https://www.tindie.com/products/TommyTyler/ir-widget-infrared-remote-control-signal-recorderanalyzer/ https://www.tindie.com/products/TommyTyler/ir-widget-infrared-remote-control-signal-recorderanalyzer/] (My preferred solution). 

====Software====
:If you are using the Nevo C2: [https://www.hifi-remote.com/forums/dload.php?action=category&cat_id=81 RM/RMIR.EXE] [https://www.hifi-remote.com/forums/dload.php?action=file&file_id=7201 RDF Files] These are support files for the program. If you are using an IR Widget: [http://www.compendiumarcana.com/irwidget/irscope.zip IRSCOPE.EXE] [http://www.ftdichip.com/Drivers/VCP.htm The drivers] [https://www.hifi-remote.com/forums/dload.php?action=file&file_id=922 The IR decode DLL] Or download [http://rmrsoft.com/remote.zip my full IRSCOPE/REMOTEMASTER package]. Much of the JP1 software needs the java runtime environment (JRE) as well. A lot of computers will already have it installed already, but if you need it you can [http://java.sun/j2se/1.4.2/download.html download] Now we can learn the codes. First we will cover the procedure using a Learning Remote, then cover it using an IR Widget. 

===USING A LEARNING REMOTE===
====Getting the Codes from your Remote====
Follow the instructions to learn your remote codes so the Nevo C2 operates your device. Then download the settings file onto your PC.

====Getting the Codes onto your PC.====
 
:#Install RMIR.EXE onto your PC. It comes as a ZIP file rather than an installation package, which you need to unzip to your PC. The files can actually go anywhere but as a bit of tidy person (geek?) I created a C:\Program Files\IR\ folder and put the files in there. Now go into the folder and click on Setup.vbs and that will produce shortcuts to run RMIR and RM (Full instructions are at https://www.hifi-remote.com/wiki/index.php?title=JP1_-_Just_How_Easy_Is_It%3F_-_RM-IR_Version)
:#You will need to create a sub folder called \RDF\ in whatever folder you have put the IR program and extract the RDF support files into that folder. Again, refer to the instructions. 

Now plug your Nevo into the PC and start RMIR. Use the '''Remote > Download Remote''' menu option to get the data from the Nevo to the PC.

Under the '''Devices Tab''' you should now see the device. Select it, then use the Edit Device button and then the Save As button to produce the required RMDU file.

You can now post that file to the forum where you requested the remote, or if you want to do it yourself then go to the next Section.

===USING AN IR WIDGET===
If you are using an IR Widget there is an excellent guide [http://freepdfhosting.com/6ea1213d67.pdf here] on the Tindle site. So I suggest you download that and read it thoroughly. There is no point in repeating it here, but just to emphasise a few points: 
:#You will want to regularly check for updates to the decodeir.dll. As new protocols are recognized, this dll will change. 
:#There is no way to save the learned values for importing into RemoteMaster (where you will make the remote) so you will need to write them down. 
:#Although I tend to put programs into C:\Program Files\.... this can be a bit dodgy in Windows as programs cannot save files to this area because of security limitations. So it might be safer to install it under \Documents\ 
:#The Guide has a very useful section comparing using a Learning Remotes and the IR Widget and highlighting the differences, (For example "Key" is equivalent to "OBC") so you could check out the previous sub-section covering using IR.EXE and the Learning Remote. And then you will understand this section. When complete you can move onto [[#Creating_your_own_Binary_files_using_RemoteMaster|Section 6]] to create the Binary file. 

==Creating your own Binary files using RemoteMaster==
:#To make life easier I have packaged a full set of the latest files required and uploaded them to my site. Just download them from [http://www.rmrsoft.com/remote.zip here] and unzip them onto your computer. 
:#Start RemoteMaster.EXE. You may be promoted to highlight the folder the folder that contains the RDF files (Highlight the \RDF\ folder in the folder where you placed Remotemaster). You may also have to do the same for the Images folder. The display will now look something like this:[[Image:RM-setup.jpg]] 
:#If you have obtained an .rmdu file then use the File > Open menu option to load the file. If you have obtained a .bin file then use the Advanced > Import Binary Upgrade to load up the details. If you have not obtained a file then you will have to input the codes manually. 
:#Now to explain the main Setup Tab: '''Description ''': Use anything you like, I tend to use the device name. '''Remote''': Select the one appropriate for your chip. '''Device Type''': Should be set to the correct type of device (as covered in Paragraph 3 of Section 1). '''Setup Code''': This is where you put the 4-digit code. In theory it can be any number between 0000 and 2047, but as explained in Section 1 Paragraph 3, numbers below 2000 may actually be already allocated to specific devices, so to be safe I personally use 2010. Fell free to use your own value. '''Protocol''': From the dropdown list select the Protocol you discovered when you used IR.EXE/IRSCOPE.EXE. '''Device''': Type in the Device code you recorded from IR.EXE/IRSCOPE.EXE. '''Sub-Device''': If applicable type in the Sub-Device code you recorded from IR.EXE/ IRSCOPE.EXE. 
:#Now tap on the Functions Tab [[Image:RM-functions.jpg]] This picture shows the program with an .rmdu file or .bin file already imported; otherwise the code columns will be blank. The entries are fully configurable, so if there are pre-defined functions that you do not need (pip swap, pipmove..) then you highlight them and tap the "Delete" button. If you have a function that is not pre-defined (Audio, Setup…) then tap the "New" button and enter them. Now fill in the codes for each button that you recorded. You just put in the OBC value and press <Enter>, the other 2 values will be generated automatically based on the protocol you selected. Also, if you used a JP1 learning remote, there's a way to cut and paste all the codes which saves needing to enter them all. In IR, if you select File > Summary you get a page listing lots of stuff. If you scroll down, you'll see a list of learn decodes. You can cut and paste this list into Excel, then you can re-arrange the columns and just select the button names and OBC codes to cut and paste into RM. You can move the RM columns, so if the OBC column isn't the one next to the button names, you can move it there. 
:#Now tap on the Buttons Tab [[Image:RM-buttons.jpg]] This is where you map the defined functions onto the available buttons. Simply tap the Auto-Assign button which should allocate most of the buttons. For any buttons left in red drag the function name from the table on the left to the function column on the right. But note that not all these buttons are available on a Slingplayer Generic Remote. For example the 'Slow' and 'Eject' buttons do not exist on a Generic Remote. So only map the functions onto the buttons that actually exist (You will see that when you check out the Layout Tab, and from experience when you have done this a few times). The important ones to note are the Custom 10-29 buttons. These are the ones you use for the functions you need that aren't on the generic remote and they subsequently appear in the drop down menu of the remote as Custom options (except for Custom 22-26 which are pre-allocated to the colour buttons). 
:#Now tap on the Layout Tab. [[Image:RM-layout.jpg]] This shows the generic Slingplayer remote and shows the buttons you can actually use in the Buttons Tab. If a button shows yellow then that means it is in use. If it shows black (the PgUp/PgDn in the picture) then has not been allocated a function. Again you can drag and drop functions onto a button. 
:#Once you have finished experimenting go back to the Setup tab. Select the appropriate Slingbox remote, go to the 'Advanced' menu at the top and select 'Export Binary Upgrade'. This will produce the BIN file that we have discussed in previous Sections. If you aren‟t sure which Slingbox Chip you have then create a BIN file for the main 2 chips, so that would give you something like 
:::C2010_PL.BIN
:::C2010_RV.BIN

So now you can go back to [[#Installing_the_Binary_file_to_the_Slingbox.|Section 4]] and install the new Custom Remote onto your Slingbox. 

====Finding Missing Codes====
You can often find yourself in the position where the Custom Remote generally works OK but some of the functions are missing or some are sending the wrong code. This is relatively easy to fix by trial and error. The OBC codes must lie between 0-255, so the first thing to do is make a list of the OBC codes that are not being used in the Remote Control. Now use Remotemaster to allocate those codes to the 0-9 buttons and the 15 Custom buttons. Now build a new BIN files, replace the one in your \SBAV\ folder and rerun the "Setup Video Sources" routine. Now try those buttons and see if any of them action the missing function. If you find the missing codes then you can update the original remote file. You may have to repeat this operation 10 times to cover all the missing codes, although you can cut down the number of times by also using the Transport buttons (Play/Pause…) and Channel, Page +/- buttons as well. 

==Give your Binary file back to the Community==
Finally, remember that it is good to payback. If you find a remote file that works for you then upload it to the JP1 Forums. The way to do this is: 
#Put the 4 Binary files and the Remote Master RMDU file into a ZIP file. I also tend to add a Readme file in case users are unsure how to use the files. Although hopefully they will have read this article and will know what to do. 
#To be really helpful, you should upload your files in 3 different places:
##Upload your ZIP file to the [http://www.hifi-remote.com/forums/dload.php?action=category&cat_id=87 Slingbox Binary Files] area.
##Upload the Remote Master RMDU source file to the [http://www.hifi-remote.com/forums/dload.php?action=category&cat_id=98 Slingbox RM Files] area.
##Upload the RMDU file to the appropriate area in the [http://www.hifi-remote.com/forums/dload.php?action=category&cat_id=4 Device Upgrades] area.
 
I hope these instructions have been helpful. If you have any suggestions for changes or improvements please E-mail me at '''alan (at) rmrsoft (dot) com'''

How to Create Custom Remote Controls and use them on your Slingbox

2025-11-23T15:51:43Z

The Robman: /* Installing the Binary file to the Slingbox. */

''Written by: Al Richey'' 

One of the most common posts on the support site is about remote codes for unsupported devices. So if you find yourself in this situation I hope this will help. Before detailing the steps to go through there are some basic things you need to understand (this isn't essential reading but everything will make much more sense if you do know the details)

==Background information==
===Different UEI Chips===
: There were five different chips used in Slingboxes. These are designated as JU, PK, PL, RV & JB. If you want to check your type you can verify your IR blaster version in the Slingbox Properties dialog. Then match the IR version number with the chip type using the chart below.
#JU (VERY old US boxes)
#PL (current US boxes)
#PK (never used)
#RV (old European boxes)
#JB (All modern Slingboxes, but compatible with PL files)

So unless you have an old European Solo all you need is the PL file.

===Slingplayer Compatibility===
: In older versions of Slingplayer it was possible to change the look of the Custom Remote skin‟. Since Slingplayer V1.5 this functionality has been removed and as far as the look of the Remote is concerned you are stuck with the Generic design produced by Sling Media. All we can do is change the codes that are sent when a specific button is pressed. One drawback of the Generic Remote is that it has only the main buttons, so extra buttons on other remotes (such as Audio/Setup…) can not be mapped directly. What we have to do is put them into a Custom Menu which is accessed by tapping on the Menu button on the Generic Remote or right-clicking on the image. (Note: If a remote image has already been produced by Sling it is possible to use that image instead of the generic image, just contact me at alan@rmrsoft.com)
:

===Setup Code Nomenclature===
: When you run the Configure Inputs routines in the various Slingplayers and select a supported device, what actually happens is that a Binary Code is downloaded to the Slingbox. 
: This Binary Code details the IR codes that are sent when a specific button is pressed on the remote. Unfortunately the native Slingbox software doesn't use separate binary files that we can edit, their codes are apparently compressed and packaged into special files that we can't do anything with (that I know of). But what we can do instead of editing the built-in codes is to use a separate external upgrade code file. These files have the format such as "C1234_PL.BIN". 
: The first letter of the file describes the type of device, the main ones we are interested in are:

::V which is for VCRs, which encompasses PVRs, DVRs and other recorders
::S which is for Satellite and FTA set top boxes
::C which is for Cable boxes
::Y which is for DVD Players

:This is followed by a 4-digit code number. For Slingboxes the code numbers can be between 0000-2047 (actually higher in newer Slingboxes but to stay safe we are better staying below 2047). In general, codes below 2000 actually relate to specific boxes, for example V0618 is the code for a TIVO and D0032 is the code for a Pioneer CD Player. But we can feel fairly safe using 2000-2047 for our own codes. The final part of the filename defines the chip for which it will run. 
: So if you were looking for the binary file for a PVR with a code number allocated 1234, designed to run on a PL-equipped Slingbox, you would be searching for a file called V1234_PL.BIN. Note: You must NEVER change the name of the file, as the letter, code number and chip type are also defined inside the file itself.

===JP1===
:You will hear a lot about "JP1". Basically this is a process whereby people using "One For All‟ (OFA) remote controls can add new codes to their remotes from their PC. The remote control processor inside the Slingbox is made by the same company that makes OFA remotes, so the upgrades are similar. The JP1 tools have been upgraded so that we can now use them to create and modify upgrades for the Slingbox.

==The Basic Procedure.==
The official procedure to follow was to report the [https://web.archive.org/web/20100605080308/http://support.slingmedia.com/get/KB-005640.html Lack of a Supported Remote] to SlingMedia and they would add it to the database. In practice, they were not quick at doing this (I have been asking for a remote for over 4 years now), and the updated remote list seems to be only occasionally updated. So it was really not a practical quick solution. So what folks need to do is to create or acquire the correct Binary code file for your A/V device, and then install it into your Slingbox. This installation process is covered in detail in [[#Installing_the_Binary_file_to_the_Slingbox|Section 4]], so first let‟s see where you can look for these files. 

==Obtaining the Binary file for the Custom Remote==

#Before starting, make sure in the setup wizard you have tried all the devices by that same manufacturer, even if the model number does not match, and all the associated code numbers. It's also worth trying your TV Provider in case they have 'badged' someone else's box. You might be lucky and find one that works and that will save a lot of work. If that doesn't solve the problem here is the step by step approach to getting hold of your binary file: 
#Go to the JP1 forum. This has a specific Download area for [https://www.hifi-remote.com/forums/dload.php?action=category&cat_id=87 Slingbox Custom Remotes], so go through all those to see if your device has already been done. 
#If it isn't there the JP1 forum also has a more general [https://www.hifi-remote.com/forums/dload.php?action=category&cat_id=4 File Download Area]. From this page you select the download area for the specific type of device and check there. If you are lucky you will find a source file for using in the program RemoteMaster (RM or KM files), the use of which is discussed in [[#Creating_your_own_Binary_files_using_RemoteMaster|Section 6]]. 
#Have a look on the Hava forums. They are also using the same chips and the files might be there. Check out this [http://www.myhava.com/forum/viewforum.php?f=17&st=0&sk=t&sd=d&start=0 forum]. You‟re looking for a PK or PL file. They can be imported into Remote Master and then converted to the PK, PL, RV or JU files for the Slingbox. Again this is discussed in [[#Creating_your_own_Binary_files_using_RemoteMaster|Section 6]]. 
#Do it yourself by buying a Nevo C2, or an IR Widget, and learn the codes needed to control the device. How to do this is covered in [[#Learning_the_IR_codes_from_your_own_remote|Section 5]] & [[#Creating_your_own_Binary_files_using_RemoteMaster|Section 6]]. 
#Ask someone else to do the work for you. You can try this by posting a request for help in either:
##The [https://community.sling.com/content Slingbox Answers Forum].
##The [https://www.hifi-remote.com/forums/viewforum.php?f=19 JP1 forum]. 
I can normally install your device on my Harmony Universal Remote to mimic the original Remote and learn the codes for you (unless I am away on holiday). 

==Installing the Binary file to the Slingbox.==
 I have written a comprehensive Installation Guide at

[https://web.archive.org/web/20161021050303/https://placeshiftingenthusiasts.com/how-to-install-a-custom-remote-onto-the-slingbox/ http://placeshiftingenthusiasts.com/how-to-install-a-custom-remote-onto-the-slingbox/]

Once you have completed the setup and the BIN files have been downloaded to the Slingbox they are not used any more and can be deleted.

==Learning the IR codes from your own remote.==
===Requirements===
Assuming you have decided to create the Remote Binary File yourself, the first stage is to learn the codes from your original Remote. This is what you need:
====Hardware====
#A computer with a USB port. 
#A A Nevo C2 Learning Remote (Available on E-Bay for $20 or so) or alternatively

:An IR learning "widget". I got mine from Tommy Tyler through https://www.tindie.com/products/TommyTyler/ir-widget-infrared-remote-control-signal-recorderanalyzer/ (My preferred solution). 

====Software====
:If you are using the Nevo C2: [http://www.hifi-remote.com/forums/dload.php?action=category&cat_id=81 RM/RMIR.EXE] [http://www.hifi-remote.com/forums/dload.php?action=file&file_id=7201 RDF Files] These are support files for the program. If you are using an IR Widget: [http://www.compendiumarcana.com/irwidget/irscope.zip IRSCOPE.EXE] [http://www.ftdichip.com/Drivers/VCP.htm The drivers] [http://www.hifi-remote.com/forums/dload.php?action=file&file_id=922 The IR decode DLL] Or download [http://rmrsoft.com/remote.zip my full IRSCOPE/REMOTEMASTER package]. Much of the JP1 software needs the java runtime environment (JRE) as well. A lot of computers will already have it installed already, but if you need it you can [http://java.sun/j2se/1.4.2/download.html download] Now we can learn the codes. First we will cover the procedure using a Learning Remote, then cover it using an IR Widget. 

===USING A LEARNING REMOTE===
====Getting the Codes from your Remote====
Follow the instructions to learn your remote codes so the Nevo C2 operates your device. Then download the settings file onto your PC.

====Getting the Codes onto your PC.====
 
:#Install RMIR.EXE onto your PC. It comes as a ZIP file rather than an installation package, which you need to unzip to your PC. The files can actually go anywhere but as a bit of tidy person (geek?) I created a C:\Program Files\IR\ folder and put the files in there. Now go into the folder and click on Setup.vbs and that will produce shortcuts to run RMIR and RM (Full instructions are at http://www.hifi-remote.com/wiki/index.php?title=JP1_-_Just_How_Easy_Is_It%3F_-_RM-IR_Version)
:#You will need to create a sub folder called \RDF\ in whatever folder you have put the IR program and extract the RDF support files into that folder. Again, refer to the instructions. 

Now plug your Nevo into the PC and start RMIR. Use the '''Remote > Download Remote''' menu option to get the data from the Nevo to the PC.

Under the '''Devices Tab''' you should now see the device. Select it, then use the Edit Device button and then the Save As button to produce the required RMDU file.

You can now post that file to the forum where you requested the remote, or if you want to do it yourself then go to the next Section.

===USING AN IR WIDGET===
If you are using an IR Widget there is an excellent guide [http://freepdfhosting.com/6ea1213d67.pdf here] on the Tindle site. So I suggest you download that and read it thoroughly. There is no point in repeating it here, but just to emphasise a few points: 
:#You will want to regularly check for updates to the decodeir.dll. As new protocols are recognized, this dll will change. 
:#There is no way to save the learned values for importing into RemoteMaster (where you will make the remote) so you will need to write them down. 
:#Although I tend to put programs into C:\Program Files\.... this can be a bit dodgy in Windows as programs cannot save files to this area because of security limitations. So it might be safer to install it under \Documents\ 
:#The Guide has a very useful section comparing using a Learning Remotes and the IR Widget and highlighting the differences, (For example "Key" is equivalent to "OBC") so you could check out the previous sub-section covering using IR.EXE and the Learning Remote. And then you will understand this section. When complete you can move onto [[#Creating_your_own_Binary_files_using_RemoteMaster|Section 6]] to create the Binary file. 

==Creating your own Binary files using RemoteMaster==
:#To make life easier I have packaged a full set of the latest files required and uploaded them to my site. Just download them from [http://www.rmrsoft.com/remote.zip here] and unzip them onto your computer. 
:#Start RemoteMaster.EXE. You may be promoted to highlight the folder the folder that contains the RDF files (Highlight the \RDF\ folder in the folder where you placed Remotemaster). You may also have to do the same for the Images folder. The display will now look something like this:[[Image:RM-setup.jpg]] 
:#If you have obtained an .rmdu file then use the File > Open menu option to load the file. If you have obtained a .bin file then use the Advanced > Import Binary Upgrade to load up the details. If you have not obtained a file then you will have to input the codes manually. 
:#Now to explain the main Setup Tab: '''Description ''': Use anything you like, I tend to use the device name. '''Remote''': Select the one appropriate for your chip. '''Device Type''': Should be set to the correct type of device (as covered in Paragraph 3 of Section 1). '''Setup Code''': This is where you put the 4-digit code. In theory it can be any number between 0000 and 2047, but as explained in Section 1 Paragraph 3, numbers below 2000 may actually be already allocated to specific devices, so to be safe I personally use 2010. Fell free to use your own value. '''Protocol''': From the dropdown list select the Protocol you discovered when you used IR.EXE/IRSCOPE.EXE. '''Device''': Type in the Device code you recorded from IR.EXE/IRSCOPE.EXE. '''Sub-Device''': If applicable type in the Sub-Device code you recorded from IR.EXE/ IRSCOPE.EXE. 
:#Now tap on the Functions Tab [[Image:RM-functions.jpg]] This picture shows the program with an .rmdu file or .bin file already imported; otherwise the code columns will be blank. The entries are fully configurable, so if there are pre-defined functions that you do not need (pip swap, pipmove..) then you highlight them and tap the "Delete" button. If you have a function that is not pre-defined (Audio, Setup…) then tap the "New" button and enter them. Now fill in the codes for each button that you recorded. You just put in the OBC value and press <Enter>, the other 2 values will be generated automatically based on the protocol you selected. Also, if you used a JP1 learning remote, there's a way to cut and paste all the codes which saves needing to enter them all. In IR, if you select File > Summary you get a page listing lots of stuff. If you scroll down, you'll see a list of learn decodes. You can cut and paste this list into Excel, then you can re-arrange the columns and just select the button names and OBC codes to cut and paste into RM. You can move the RM columns, so if the OBC column isn't the one next to the button names, you can move it there. 
:#Now tap on the Buttons Tab [[Image:RM-buttons.jpg]] This is where you map the defined functions onto the available buttons. Simply tap the Auto-Assign button which should allocate most of the buttons. For any buttons left in red drag the function name from the table on the left to the function column on the right. But note that not all these buttons are available on a Slingplayer Generic Remote. For example the 'Slow' and 'Eject' buttons do not exist on a Generic Remote. So only map the functions onto the buttons that actually exist (You will see that when you check out the Layout Tab, and from experience when you have done this a few times). The important ones to note are the Custom 10-29 buttons. These are the ones you use for the functions you need that aren't on the generic remote and they subsequently appear in the drop down menu of the remote as Custom options (except for Custom 22-26 which are pre-allocated to the colour buttons). 
:#Now tap on the Layout Tab. [[Image:RM-layout.jpg]] This shows the generic Slingplayer remote and shows the buttons you can actually use in the Buttons Tab. If a button shows yellow then that means it is in use. If it shows black (the PgUp/PgDn in the picture) then has not been allocated a function. Again you can drag and drop functions onto a button. 
:#Once you have finished experimenting go back to the Setup tab. Select the appropriate Slingbox remote, go to the 'Advanced' menu at the top and select 'Export Binary Upgrade'. This will produce the BIN file that we have discussed in previous Sections. If you aren‟t sure which Slingbox Chip you have then create a BIN file for the main 2 chips, so that would give you something like 
:::C2010_PL.BIN
:::C2010_RV.BIN

So now you can go back to [[#Installing_the_Binary_file_to_the_Slingbox.|Section 4]] and install the new Custom Remote onto your Slingbox. 

====Finding Missing Codes====
You can often find yourself in the position where the Custom Remote generally works OK but some of the functions are missing or some are sending the wrong code. This is relatively easy to fix by trial and error. The OBC codes must lie between 0-255, so the first thing to do is make a list of the OBC codes that are not being used in the Remote Control. Now use Remotemaster to allocate those codes to the 0-9 buttons and the 15 Custom buttons. Now build a new BIN files, replace the one in your \SBAV\ folder and rerun the "Setup Video Sources" routine. Now try those buttons and see if any of them action the missing function. If you find the missing codes then you can update the original remote file. You may have to repeat this operation 10 times to cover all the missing codes, although you can cut down the number of times by also using the Transport buttons (Play/Pause…) and Channel, Page +/- buttons as well. 

==Give your Binary file back to the Community==
Finally, remember that it is good to payback. If you find a remote file that works for you then upload it to the JP1 Forums. The way to do this is: 
#Put the 4 Binary files and the Remote Master RMDU file into a ZIP file. I also tend to add a Readme file in case users are unsure how to use the files. Although hopefully they will have read this article and will know what to do. 
#To be really helpful, you should upload your files in 3 different places:
##Upload your ZIP file to the [http://www.hifi-remote.com/forums/dload.php?action=category&cat_id=87 Slingbox Binary Files] area.
##Upload the Remote Master RMDU source file to the [http://www.hifi-remote.com/forums/dload.php?action=category&cat_id=98 Slingbox RM Files] area.
##Upload the RMDU file to the appropriate area in the [http://www.hifi-remote.com/forums/dload.php?action=category&cat_id=4 Device Upgrades] area.
 
I hope these instructions have been helpful. If you have any suggestions for changes or improvements please E-mail me at '''alan (at) rmrsoft (dot) com'''

How to Create Custom Remote Controls and use them on your Slingbox

2025-11-23T15:50:05Z

The Robman: /* Obtaining the Binary file for the Custom Remote */

''Written by: Al Richey'' 

One of the most common posts on the support site is about remote codes for unsupported devices. So if you find yourself in this situation I hope this will help. Before detailing the steps to go through there are some basic things you need to understand (this isn't essential reading but everything will make much more sense if you do know the details)

==Background information==
===Different UEI Chips===
: There were five different chips used in Slingboxes. These are designated as JU, PK, PL, RV & JB. If you want to check your type you can verify your IR blaster version in the Slingbox Properties dialog. Then match the IR version number with the chip type using the chart below.
#JU (VERY old US boxes)
#PL (current US boxes)
#PK (never used)
#RV (old European boxes)
#JB (All modern Slingboxes, but compatible with PL files)

So unless you have an old European Solo all you need is the PL file.

===Slingplayer Compatibility===
: In older versions of Slingplayer it was possible to change the look of the Custom Remote skin‟. Since Slingplayer V1.5 this functionality has been removed and as far as the look of the Remote is concerned you are stuck with the Generic design produced by Sling Media. All we can do is change the codes that are sent when a specific button is pressed. One drawback of the Generic Remote is that it has only the main buttons, so extra buttons on other remotes (such as Audio/Setup…) can not be mapped directly. What we have to do is put them into a Custom Menu which is accessed by tapping on the Menu button on the Generic Remote or right-clicking on the image. (Note: If a remote image has already been produced by Sling it is possible to use that image instead of the generic image, just contact me at alan@rmrsoft.com)
:

===Setup Code Nomenclature===
: When you run the Configure Inputs routines in the various Slingplayers and select a supported device, what actually happens is that a Binary Code is downloaded to the Slingbox. 
: This Binary Code details the IR codes that are sent when a specific button is pressed on the remote. Unfortunately the native Slingbox software doesn't use separate binary files that we can edit, their codes are apparently compressed and packaged into special files that we can't do anything with (that I know of). But what we can do instead of editing the built-in codes is to use a separate external upgrade code file. These files have the format such as "C1234_PL.BIN". 
: The first letter of the file describes the type of device, the main ones we are interested in are:

::V which is for VCRs, which encompasses PVRs, DVRs and other recorders
::S which is for Satellite and FTA set top boxes
::C which is for Cable boxes
::Y which is for DVD Players

:This is followed by a 4-digit code number. For Slingboxes the code numbers can be between 0000-2047 (actually higher in newer Slingboxes but to stay safe we are better staying below 2047). In general, codes below 2000 actually relate to specific boxes, for example V0618 is the code for a TIVO and D0032 is the code for a Pioneer CD Player. But we can feel fairly safe using 2000-2047 for our own codes. The final part of the filename defines the chip for which it will run. 
: So if you were looking for the binary file for a PVR with a code number allocated 1234, designed to run on a PL-equipped Slingbox, you would be searching for a file called V1234_PL.BIN. Note: You must NEVER change the name of the file, as the letter, code number and chip type are also defined inside the file itself.

===JP1===
:You will hear a lot about "JP1". Basically this is a process whereby people using "One For All‟ (OFA) remote controls can add new codes to their remotes from their PC. The remote control processor inside the Slingbox is made by the same company that makes OFA remotes, so the upgrades are similar. The JP1 tools have been upgraded so that we can now use them to create and modify upgrades for the Slingbox.

==The Basic Procedure.==
The official procedure to follow was to report the [https://web.archive.org/web/20100605080308/http://support.slingmedia.com/get/KB-005640.html Lack of a Supported Remote] to SlingMedia and they would add it to the database. In practice, they were not quick at doing this (I have been asking for a remote for over 4 years now), and the updated remote list seems to be only occasionally updated. So it was really not a practical quick solution. So what folks need to do is to create or acquire the correct Binary code file for your A/V device, and then install it into your Slingbox. This installation process is covered in detail in [[#Installing_the_Binary_file_to_the_Slingbox|Section 4]], so first let‟s see where you can look for these files. 

==Obtaining the Binary file for the Custom Remote==

#Before starting, make sure in the setup wizard you have tried all the devices by that same manufacturer, even if the model number does not match, and all the associated code numbers. It's also worth trying your TV Provider in case they have 'badged' someone else's box. You might be lucky and find one that works and that will save a lot of work. If that doesn't solve the problem here is the step by step approach to getting hold of your binary file: 
#Go to the JP1 forum. This has a specific Download area for [https://www.hifi-remote.com/forums/dload.php?action=category&cat_id=87 Slingbox Custom Remotes], so go through all those to see if your device has already been done. 
#If it isn't there the JP1 forum also has a more general [https://www.hifi-remote.com/forums/dload.php?action=category&cat_id=4 File Download Area]. From this page you select the download area for the specific type of device and check there. If you are lucky you will find a source file for using in the program RemoteMaster (RM or KM files), the use of which is discussed in [[#Creating_your_own_Binary_files_using_RemoteMaster|Section 6]]. 
#Have a look on the Hava forums. They are also using the same chips and the files might be there. Check out this [http://www.myhava.com/forum/viewforum.php?f=17&st=0&sk=t&sd=d&start=0 forum]. You‟re looking for a PK or PL file. They can be imported into Remote Master and then converted to the PK, PL, RV or JU files for the Slingbox. Again this is discussed in [[#Creating_your_own_Binary_files_using_RemoteMaster|Section 6]]. 
#Do it yourself by buying a Nevo C2, or an IR Widget, and learn the codes needed to control the device. How to do this is covered in [[#Learning_the_IR_codes_from_your_own_remote|Section 5]] & [[#Creating_your_own_Binary_files_using_RemoteMaster|Section 6]]. 
#Ask someone else to do the work for you. You can try this by posting a request for help in either:
##The [https://community.sling.com/content Slingbox Answers Forum].
##The [https://www.hifi-remote.com/forums/viewforum.php?f=19 JP1 forum]. 
I can normally install your device on my Harmony Universal Remote to mimic the original Remote and learn the codes for you (unless I am away on holiday). 

==Installing the Binary file to the Slingbox.==
 I have written a comprehensive Installation Guide at

http://placeshiftingenthusiasts.com/how-to-install-a-custom-remote-onto-the-slingbox/

Once you have completed the setup and the BIN files have been downloaded to the Slingbox they are not used any more and can be deleted.

==Learning the IR codes from your own remote.==
===Requirements===
Assuming you have decided to create the Remote Binary File yourself, the first stage is to learn the codes from your original Remote. This is what you need:
====Hardware====
#A computer with a USB port. 
#A A Nevo C2 Learning Remote (Available on E-Bay for $20 or so) or alternatively

:An IR learning "widget". I got mine from Tommy Tyler through https://www.tindie.com/products/TommyTyler/ir-widget-infrared-remote-control-signal-recorderanalyzer/ (My preferred solution). 

====Software====
:If you are using the Nevo C2: [http://www.hifi-remote.com/forums/dload.php?action=category&cat_id=81 RM/RMIR.EXE] [http://www.hifi-remote.com/forums/dload.php?action=file&file_id=7201 RDF Files] These are support files for the program. If you are using an IR Widget: [http://www.compendiumarcana.com/irwidget/irscope.zip IRSCOPE.EXE] [http://www.ftdichip.com/Drivers/VCP.htm The drivers] [http://www.hifi-remote.com/forums/dload.php?action=file&file_id=922 The IR decode DLL] Or download [http://rmrsoft.com/remote.zip my full IRSCOPE/REMOTEMASTER package]. Much of the JP1 software needs the java runtime environment (JRE) as well. A lot of computers will already have it installed already, but if you need it you can [http://java.sun/j2se/1.4.2/download.html download] Now we can learn the codes. First we will cover the procedure using a Learning Remote, then cover it using an IR Widget. 

===USING A LEARNING REMOTE===
====Getting the Codes from your Remote====
Follow the instructions to learn your remote codes so the Nevo C2 operates your device. Then download the settings file onto your PC.

====Getting the Codes onto your PC.====
 
:#Install RMIR.EXE onto your PC. It comes as a ZIP file rather than an installation package, which you need to unzip to your PC. The files can actually go anywhere but as a bit of tidy person (geek?) I created a C:\Program Files\IR\ folder and put the files in there. Now go into the folder and click on Setup.vbs and that will produce shortcuts to run RMIR and RM (Full instructions are at http://www.hifi-remote.com/wiki/index.php?title=JP1_-_Just_How_Easy_Is_It%3F_-_RM-IR_Version)
:#You will need to create a sub folder called \RDF\ in whatever folder you have put the IR program and extract the RDF support files into that folder. Again, refer to the instructions. 

Now plug your Nevo into the PC and start RMIR. Use the '''Remote > Download Remote''' menu option to get the data from the Nevo to the PC.

Under the '''Devices Tab''' you should now see the device. Select it, then use the Edit Device button and then the Save As button to produce the required RMDU file.

You can now post that file to the forum where you requested the remote, or if you want to do it yourself then go to the next Section.

===USING AN IR WIDGET===
If you are using an IR Widget there is an excellent guide [http://freepdfhosting.com/6ea1213d67.pdf here] on the Tindle site. So I suggest you download that and read it thoroughly. There is no point in repeating it here, but just to emphasise a few points: 
:#You will want to regularly check for updates to the decodeir.dll. As new protocols are recognized, this dll will change. 
:#There is no way to save the learned values for importing into RemoteMaster (where you will make the remote) so you will need to write them down. 
:#Although I tend to put programs into C:\Program Files\.... this can be a bit dodgy in Windows as programs cannot save files to this area because of security limitations. So it might be safer to install it under \Documents\ 
:#The Guide has a very useful section comparing using a Learning Remotes and the IR Widget and highlighting the differences, (For example "Key" is equivalent to "OBC") so you could check out the previous sub-section covering using IR.EXE and the Learning Remote. And then you will understand this section. When complete you can move onto [[#Creating_your_own_Binary_files_using_RemoteMaster|Section 6]] to create the Binary file. 

==Creating your own Binary files using RemoteMaster==
:#To make life easier I have packaged a full set of the latest files required and uploaded them to my site. Just download them from [http://www.rmrsoft.com/remote.zip here] and unzip them onto your computer. 
:#Start RemoteMaster.EXE. You may be promoted to highlight the folder the folder that contains the RDF files (Highlight the \RDF\ folder in the folder where you placed Remotemaster). You may also have to do the same for the Images folder. The display will now look something like this:[[Image:RM-setup.jpg]] 
:#If you have obtained an .rmdu file then use the File > Open menu option to load the file. If you have obtained a .bin file then use the Advanced > Import Binary Upgrade to load up the details. If you have not obtained a file then you will have to input the codes manually. 
:#Now to explain the main Setup Tab: '''Description ''': Use anything you like, I tend to use the device name. '''Remote''': Select the one appropriate for your chip. '''Device Type''': Should be set to the correct type of device (as covered in Paragraph 3 of Section 1). '''Setup Code''': This is where you put the 4-digit code. In theory it can be any number between 0000 and 2047, but as explained in Section 1 Paragraph 3, numbers below 2000 may actually be already allocated to specific devices, so to be safe I personally use 2010. Fell free to use your own value. '''Protocol''': From the dropdown list select the Protocol you discovered when you used IR.EXE/IRSCOPE.EXE. '''Device''': Type in the Device code you recorded from IR.EXE/IRSCOPE.EXE. '''Sub-Device''': If applicable type in the Sub-Device code you recorded from IR.EXE/ IRSCOPE.EXE. 
:#Now tap on the Functions Tab [[Image:RM-functions.jpg]] This picture shows the program with an .rmdu file or .bin file already imported; otherwise the code columns will be blank. The entries are fully configurable, so if there are pre-defined functions that you do not need (pip swap, pipmove..) then you highlight them and tap the "Delete" button. If you have a function that is not pre-defined (Audio, Setup…) then tap the "New" button and enter them. Now fill in the codes for each button that you recorded. You just put in the OBC value and press <Enter>, the other 2 values will be generated automatically based on the protocol you selected. Also, if you used a JP1 learning remote, there's a way to cut and paste all the codes which saves needing to enter them all. In IR, if you select File > Summary you get a page listing lots of stuff. If you scroll down, you'll see a list of learn decodes. You can cut and paste this list into Excel, then you can re-arrange the columns and just select the button names and OBC codes to cut and paste into RM. You can move the RM columns, so if the OBC column isn't the one next to the button names, you can move it there. 
:#Now tap on the Buttons Tab [[Image:RM-buttons.jpg]] This is where you map the defined functions onto the available buttons. Simply tap the Auto-Assign button which should allocate most of the buttons. For any buttons left in red drag the function name from the table on the left to the function column on the right. But note that not all these buttons are available on a Slingplayer Generic Remote. For example the 'Slow' and 'Eject' buttons do not exist on a Generic Remote. So only map the functions onto the buttons that actually exist (You will see that when you check out the Layout Tab, and from experience when you have done this a few times). The important ones to note are the Custom 10-29 buttons. These are the ones you use for the functions you need that aren't on the generic remote and they subsequently appear in the drop down menu of the remote as Custom options (except for Custom 22-26 which are pre-allocated to the colour buttons). 
:#Now tap on the Layout Tab. [[Image:RM-layout.jpg]] This shows the generic Slingplayer remote and shows the buttons you can actually use in the Buttons Tab. If a button shows yellow then that means it is in use. If it shows black (the PgUp/PgDn in the picture) then has not been allocated a function. Again you can drag and drop functions onto a button. 
:#Once you have finished experimenting go back to the Setup tab. Select the appropriate Slingbox remote, go to the 'Advanced' menu at the top and select 'Export Binary Upgrade'. This will produce the BIN file that we have discussed in previous Sections. If you aren‟t sure which Slingbox Chip you have then create a BIN file for the main 2 chips, so that would give you something like 
:::C2010_PL.BIN
:::C2010_RV.BIN

So now you can go back to [[#Installing_the_Binary_file_to_the_Slingbox.|Section 4]] and install the new Custom Remote onto your Slingbox. 

====Finding Missing Codes====
You can often find yourself in the position where the Custom Remote generally works OK but some of the functions are missing or some are sending the wrong code. This is relatively easy to fix by trial and error. The OBC codes must lie between 0-255, so the first thing to do is make a list of the OBC codes that are not being used in the Remote Control. Now use Remotemaster to allocate those codes to the 0-9 buttons and the 15 Custom buttons. Now build a new BIN files, replace the one in your \SBAV\ folder and rerun the "Setup Video Sources" routine. Now try those buttons and see if any of them action the missing function. If you find the missing codes then you can update the original remote file. You may have to repeat this operation 10 times to cover all the missing codes, although you can cut down the number of times by also using the Transport buttons (Play/Pause…) and Channel, Page +/- buttons as well. 

==Give your Binary file back to the Community==
Finally, remember that it is good to payback. If you find a remote file that works for you then upload it to the JP1 Forums. The way to do this is: 
#Put the 4 Binary files and the Remote Master RMDU file into a ZIP file. I also tend to add a Readme file in case users are unsure how to use the files. Although hopefully they will have read this article and will know what to do. 
#To be really helpful, you should upload your files in 3 different places:
##Upload your ZIP file to the [http://www.hifi-remote.com/forums/dload.php?action=category&cat_id=87 Slingbox Binary Files] area.
##Upload the Remote Master RMDU source file to the [http://www.hifi-remote.com/forums/dload.php?action=category&cat_id=98 Slingbox RM Files] area.
##Upload the RMDU file to the appropriate area in the [http://www.hifi-remote.com/forums/dload.php?action=category&cat_id=4 Device Upgrades] area.
 
I hope these instructions have been helpful. If you have any suggestions for changes or improvements please E-mail me at '''alan (at) rmrsoft (dot) com'''

How to Create Custom Remote Controls and use them on your Slingbox

2025-11-23T15:49:25Z

The Robman: /* The Basic Procedure. */

''Written by: Al Richey'' 

One of the most common posts on the support site is about remote codes for unsupported devices. So if you find yourself in this situation I hope this will help. Before detailing the steps to go through there are some basic things you need to understand (this isn't essential reading but everything will make much more sense if you do know the details)

==Background information==
===Different UEI Chips===
: There were five different chips used in Slingboxes. These are designated as JU, PK, PL, RV & JB. If you want to check your type you can verify your IR blaster version in the Slingbox Properties dialog. Then match the IR version number with the chip type using the chart below.
#JU (VERY old US boxes)
#PL (current US boxes)
#PK (never used)
#RV (old European boxes)
#JB (All modern Slingboxes, but compatible with PL files)

So unless you have an old European Solo all you need is the PL file.

===Slingplayer Compatibility===
: In older versions of Slingplayer it was possible to change the look of the Custom Remote skin‟. Since Slingplayer V1.5 this functionality has been removed and as far as the look of the Remote is concerned you are stuck with the Generic design produced by Sling Media. All we can do is change the codes that are sent when a specific button is pressed. One drawback of the Generic Remote is that it has only the main buttons, so extra buttons on other remotes (such as Audio/Setup…) can not be mapped directly. What we have to do is put them into a Custom Menu which is accessed by tapping on the Menu button on the Generic Remote or right-clicking on the image. (Note: If a remote image has already been produced by Sling it is possible to use that image instead of the generic image, just contact me at alan@rmrsoft.com)
:

===Setup Code Nomenclature===
: When you run the Configure Inputs routines in the various Slingplayers and select a supported device, what actually happens is that a Binary Code is downloaded to the Slingbox. 
: This Binary Code details the IR codes that are sent when a specific button is pressed on the remote. Unfortunately the native Slingbox software doesn't use separate binary files that we can edit, their codes are apparently compressed and packaged into special files that we can't do anything with (that I know of). But what we can do instead of editing the built-in codes is to use a separate external upgrade code file. These files have the format such as "C1234_PL.BIN". 
: The first letter of the file describes the type of device, the main ones we are interested in are:

::V which is for VCRs, which encompasses PVRs, DVRs and other recorders
::S which is for Satellite and FTA set top boxes
::C which is for Cable boxes
::Y which is for DVD Players

:This is followed by a 4-digit code number. For Slingboxes the code numbers can be between 0000-2047 (actually higher in newer Slingboxes but to stay safe we are better staying below 2047). In general, codes below 2000 actually relate to specific boxes, for example V0618 is the code for a TIVO and D0032 is the code for a Pioneer CD Player. But we can feel fairly safe using 2000-2047 for our own codes. The final part of the filename defines the chip for which it will run. 
: So if you were looking for the binary file for a PVR with a code number allocated 1234, designed to run on a PL-equipped Slingbox, you would be searching for a file called V1234_PL.BIN. Note: You must NEVER change the name of the file, as the letter, code number and chip type are also defined inside the file itself.

===JP1===
:You will hear a lot about "JP1". Basically this is a process whereby people using "One For All‟ (OFA) remote controls can add new codes to their remotes from their PC. The remote control processor inside the Slingbox is made by the same company that makes OFA remotes, so the upgrades are similar. The JP1 tools have been upgraded so that we can now use them to create and modify upgrades for the Slingbox.

==The Basic Procedure.==
The official procedure to follow was to report the [https://web.archive.org/web/20100605080308/http://support.slingmedia.com/get/KB-005640.html Lack of a Supported Remote] to SlingMedia and they would add it to the database. In practice, they were not quick at doing this (I have been asking for a remote for over 4 years now), and the updated remote list seems to be only occasionally updated. So it was really not a practical quick solution. So what folks need to do is to create or acquire the correct Binary code file for your A/V device, and then install it into your Slingbox. This installation process is covered in detail in [[#Installing_the_Binary_file_to_the_Slingbox|Section 4]], so first let‟s see where you can look for these files. 

==Obtaining the Binary file for the Custom Remote==

#Before starting, make sure in the setup wizard you have tried all the devices by that same manufacturer, even if the model number does not match, and all the associated code numbers. It's also worth trying your TV Provider in case they have 'badged' someone else's box. You might be lucky and find one that works and that will save a lot of work. If that doesn't solve the problem here is the step by step approach to getting hold of your binary file: 
#Go to the JP1 forum. This has a specific Download area for [http://www.hifi-remote.com/forums/dload.php?action=category&cat_id=87 Slingbox Custom Remotes], so go through all those to see if your device has already been done. 
#If it isn't there the JP1 forum also has a more general [http://www.hifi-remote.com/forums/dload.php?action=category&cat_id=4 File Download Area]. From this page you select the download area for the specific type of device and check there. If you are lucky you will find a source file for using in the program RemoteMaster (RM or KM files), the use of which is discussed in [[#Creating_your_own_Binary_files_using_RemoteMaster|Section 6]]. 
#Have a look on the Hava forums. They are also using the same chips and the files might be there. Check out this [http://www.myhava.com/forum/viewforum.php?f=17&st=0&sk=t&sd=d&start=0 forum]. You‟re looking for a PK or PL file. They can be imported into Remote Master and then converted to the PK, PL, RV or JU files for the Slingbox. Again this is discussed in [[#Creating_your_own_Binary_files_using_RemoteMaster|Section 6]]. 
#Do it yourself by buying a Nevo C2, or an IR Widget, and learn the codes needed to control the device. How to do this is covered in [[#Learning_the_IR_codes_from_your_own_remote|Section 5]] & [[#Creating_your_own_Binary_files_using_RemoteMaster|Section 6]]. 
#Ask someone else to do the work for you. You can try this by posting a request for help in either:
##The [https://community.sling.com/content Slingbox Answers Forum].
##The [http://www.hifi-remote.com/forums/viewforum.php?f=19 JP1 forum]. 
I can normally install your device on my Harmony Universal Remote to mimic the original Remote and learn the codes for you (unless I am away on holiday). 

==Installing the Binary file to the Slingbox.==
 I have written a comprehensive Installation Guide at

http://placeshiftingenthusiasts.com/how-to-install-a-custom-remote-onto-the-slingbox/

Once you have completed the setup and the BIN files have been downloaded to the Slingbox they are not used any more and can be deleted.

==Learning the IR codes from your own remote.==
===Requirements===
Assuming you have decided to create the Remote Binary File yourself, the first stage is to learn the codes from your original Remote. This is what you need:
====Hardware====
#A computer with a USB port. 
#A A Nevo C2 Learning Remote (Available on E-Bay for $20 or so) or alternatively

:An IR learning "widget". I got mine from Tommy Tyler through https://www.tindie.com/products/TommyTyler/ir-widget-infrared-remote-control-signal-recorderanalyzer/ (My preferred solution). 

====Software====
:If you are using the Nevo C2: [http://www.hifi-remote.com/forums/dload.php?action=category&cat_id=81 RM/RMIR.EXE] [http://www.hifi-remote.com/forums/dload.php?action=file&file_id=7201 RDF Files] These are support files for the program. If you are using an IR Widget: [http://www.compendiumarcana.com/irwidget/irscope.zip IRSCOPE.EXE] [http://www.ftdichip.com/Drivers/VCP.htm The drivers] [http://www.hifi-remote.com/forums/dload.php?action=file&file_id=922 The IR decode DLL] Or download [http://rmrsoft.com/remote.zip my full IRSCOPE/REMOTEMASTER package]. Much of the JP1 software needs the java runtime environment (JRE) as well. A lot of computers will already have it installed already, but if you need it you can [http://java.sun/j2se/1.4.2/download.html download] Now we can learn the codes. First we will cover the procedure using a Learning Remote, then cover it using an IR Widget. 

===USING A LEARNING REMOTE===
====Getting the Codes from your Remote====
Follow the instructions to learn your remote codes so the Nevo C2 operates your device. Then download the settings file onto your PC.

====Getting the Codes onto your PC.====
 
:#Install RMIR.EXE onto your PC. It comes as a ZIP file rather than an installation package, which you need to unzip to your PC. The files can actually go anywhere but as a bit of tidy person (geek?) I created a C:\Program Files\IR\ folder and put the files in there. Now go into the folder and click on Setup.vbs and that will produce shortcuts to run RMIR and RM (Full instructions are at http://www.hifi-remote.com/wiki/index.php?title=JP1_-_Just_How_Easy_Is_It%3F_-_RM-IR_Version)
:#You will need to create a sub folder called \RDF\ in whatever folder you have put the IR program and extract the RDF support files into that folder. Again, refer to the instructions. 

Now plug your Nevo into the PC and start RMIR. Use the '''Remote > Download Remote''' menu option to get the data from the Nevo to the PC.

Under the '''Devices Tab''' you should now see the device. Select it, then use the Edit Device button and then the Save As button to produce the required RMDU file.

You can now post that file to the forum where you requested the remote, or if you want to do it yourself then go to the next Section.

===USING AN IR WIDGET===
If you are using an IR Widget there is an excellent guide [http://freepdfhosting.com/6ea1213d67.pdf here] on the Tindle site. So I suggest you download that and read it thoroughly. There is no point in repeating it here, but just to emphasise a few points: 
:#You will want to regularly check for updates to the decodeir.dll. As new protocols are recognized, this dll will change. 
:#There is no way to save the learned values for importing into RemoteMaster (where you will make the remote) so you will need to write them down. 
:#Although I tend to put programs into C:\Program Files\.... this can be a bit dodgy in Windows as programs cannot save files to this area because of security limitations. So it might be safer to install it under \Documents\ 
:#The Guide has a very useful section comparing using a Learning Remotes and the IR Widget and highlighting the differences, (For example "Key" is equivalent to "OBC") so you could check out the previous sub-section covering using IR.EXE and the Learning Remote. And then you will understand this section. When complete you can move onto [[#Creating_your_own_Binary_files_using_RemoteMaster|Section 6]] to create the Binary file. 

==Creating your own Binary files using RemoteMaster==
:#To make life easier I have packaged a full set of the latest files required and uploaded them to my site. Just download them from [http://www.rmrsoft.com/remote.zip here] and unzip them onto your computer. 
:#Start RemoteMaster.EXE. You may be promoted to highlight the folder the folder that contains the RDF files (Highlight the \RDF\ folder in the folder where you placed Remotemaster). You may also have to do the same for the Images folder. The display will now look something like this:[[Image:RM-setup.jpg]] 
:#If you have obtained an .rmdu file then use the File > Open menu option to load the file. If you have obtained a .bin file then use the Advanced > Import Binary Upgrade to load up the details. If you have not obtained a file then you will have to input the codes manually. 
:#Now to explain the main Setup Tab: '''Description ''': Use anything you like, I tend to use the device name. '''Remote''': Select the one appropriate for your chip. '''Device Type''': Should be set to the correct type of device (as covered in Paragraph 3 of Section 1). '''Setup Code''': This is where you put the 4-digit code. In theory it can be any number between 0000 and 2047, but as explained in Section 1 Paragraph 3, numbers below 2000 may actually be already allocated to specific devices, so to be safe I personally use 2010. Fell free to use your own value. '''Protocol''': From the dropdown list select the Protocol you discovered when you used IR.EXE/IRSCOPE.EXE. '''Device''': Type in the Device code you recorded from IR.EXE/IRSCOPE.EXE. '''Sub-Device''': If applicable type in the Sub-Device code you recorded from IR.EXE/ IRSCOPE.EXE. 
:#Now tap on the Functions Tab [[Image:RM-functions.jpg]] This picture shows the program with an .rmdu file or .bin file already imported; otherwise the code columns will be blank. The entries are fully configurable, so if there are pre-defined functions that you do not need (pip swap, pipmove..) then you highlight them and tap the "Delete" button. If you have a function that is not pre-defined (Audio, Setup…) then tap the "New" button and enter them. Now fill in the codes for each button that you recorded. You just put in the OBC value and press <Enter>, the other 2 values will be generated automatically based on the protocol you selected. Also, if you used a JP1 learning remote, there's a way to cut and paste all the codes which saves needing to enter them all. In IR, if you select File > Summary you get a page listing lots of stuff. If you scroll down, you'll see a list of learn decodes. You can cut and paste this list into Excel, then you can re-arrange the columns and just select the button names and OBC codes to cut and paste into RM. You can move the RM columns, so if the OBC column isn't the one next to the button names, you can move it there. 
:#Now tap on the Buttons Tab [[Image:RM-buttons.jpg]] This is where you map the defined functions onto the available buttons. Simply tap the Auto-Assign button which should allocate most of the buttons. For any buttons left in red drag the function name from the table on the left to the function column on the right. But note that not all these buttons are available on a Slingplayer Generic Remote. For example the 'Slow' and 'Eject' buttons do not exist on a Generic Remote. So only map the functions onto the buttons that actually exist (You will see that when you check out the Layout Tab, and from experience when you have done this a few times). The important ones to note are the Custom 10-29 buttons. These are the ones you use for the functions you need that aren't on the generic remote and they subsequently appear in the drop down menu of the remote as Custom options (except for Custom 22-26 which are pre-allocated to the colour buttons). 
:#Now tap on the Layout Tab. [[Image:RM-layout.jpg]] This shows the generic Slingplayer remote and shows the buttons you can actually use in the Buttons Tab. If a button shows yellow then that means it is in use. If it shows black (the PgUp/PgDn in the picture) then has not been allocated a function. Again you can drag and drop functions onto a button. 
:#Once you have finished experimenting go back to the Setup tab. Select the appropriate Slingbox remote, go to the 'Advanced' menu at the top and select 'Export Binary Upgrade'. This will produce the BIN file that we have discussed in previous Sections. If you aren‟t sure which Slingbox Chip you have then create a BIN file for the main 2 chips, so that would give you something like 
:::C2010_PL.BIN
:::C2010_RV.BIN

So now you can go back to [[#Installing_the_Binary_file_to_the_Slingbox.|Section 4]] and install the new Custom Remote onto your Slingbox. 

====Finding Missing Codes====
You can often find yourself in the position where the Custom Remote generally works OK but some of the functions are missing or some are sending the wrong code. This is relatively easy to fix by trial and error. The OBC codes must lie between 0-255, so the first thing to do is make a list of the OBC codes that are not being used in the Remote Control. Now use Remotemaster to allocate those codes to the 0-9 buttons and the 15 Custom buttons. Now build a new BIN files, replace the one in your \SBAV\ folder and rerun the "Setup Video Sources" routine. Now try those buttons and see if any of them action the missing function. If you find the missing codes then you can update the original remote file. You may have to repeat this operation 10 times to cover all the missing codes, although you can cut down the number of times by also using the Transport buttons (Play/Pause…) and Channel, Page +/- buttons as well. 

==Give your Binary file back to the Community==
Finally, remember that it is good to payback. If you find a remote file that works for you then upload it to the JP1 Forums. The way to do this is: 
#Put the 4 Binary files and the Remote Master RMDU file into a ZIP file. I also tend to add a Readme file in case users are unsure how to use the files. Although hopefully they will have read this article and will know what to do. 
#To be really helpful, you should upload your files in 3 different places:
##Upload your ZIP file to the [http://www.hifi-remote.com/forums/dload.php?action=category&cat_id=87 Slingbox Binary Files] area.
##Upload the Remote Master RMDU source file to the [http://www.hifi-remote.com/forums/dload.php?action=category&cat_id=98 Slingbox RM Files] area.
##Upload the RMDU file to the appropriate area in the [http://www.hifi-remote.com/forums/dload.php?action=category&cat_id=4 Device Upgrades] area.
 
I hope these instructions have been helpful. If you have any suggestions for changes or improvements please E-mail me at '''alan (at) rmrsoft (dot) com'''

IR Help

2025-11-23T15:44:26Z

The Robman:

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

There is so much to learn about JP1. It’s a fascinating subject, but chances are if you are reading this, all you want to do is control your TV, VCR and DVD using 1 remote. This is my attempt to create a guide on how to use IR and the supporting tools. But keep in mind that the software is continually evolving and this document was last updated in the summer of 2010.

This is compiled from many posts and articles I read in the JP1 forum. I’ve borrowed freely from what I’ve read on the JP1 site at hifi-remotes.com, and from the old Yahoo site. My thanks to everyone on the JP1 experts who created the tools and shared their knowledge. - [https://www.hifi-remote.com/forums/memberlist.php?mode=viewprofile&u=1350 Vickyg2003]

'''Chapter 1 - Getting Started''' 
[[JP1 or JP1x]] 
[[Remote basics]] 
[[RDFs]] 
[[IR.EXE Safety]] 
[[How can I reset my remote?]] 
[[Files to run the JP1 Tools]] 
 
'''Chapter 2 - Next Steps''' 
[[Connecting IR to your remote]] 
[[IR's Display]] 
[[IR's Menus]] 
[[IR's General Tab]] 
[[IR's CodeSelector]] 
[[Sorts and Moves]] 
[[Macros]] 
[[Key Moves]] 
[[Learned Signals]] 
[[Fav Scan]] 
 
'''Chapter 3 - Intermediate Programming''' 
[[Remote Memory Usage]] 
[[Device Upgrades]] 
[[Using KM, Keymap-Master, to create a device upgrade]] 
[[Using RM, RemoteMaster, to create a device upgrade]] 
[[Protocol Upgrades]] 
[[Creating a Better Upgrade]] 
[[EFCs and OBCs]] 
 
'''Chapter 4 - Advanced Programming''' 
[[Extenders]] 
[[Special Protocols]] 
 
'''Chapter 5 - Finding Codes''' 
[[Finding Codes]] 
 
'''Chapter 6 - Modem Upgradeable Remotes''' 
[[WAV FILES]] 
 
'''Chapter 7 - The Glossary''' 
[[Glossary]]

User:Vickyg2003

2025-11-23T15:43:57Z

The Robman:

JP1 profile: https://www.hifi-remote.com/forums/memberlist.php?mode=viewprofile&u=1350

Main Page

2025-11-23T15:40:07Z

The Robman:

''(Back to [https://www.hifi-remote.com/forums JP1 Forums])'' 
Welcome to the JP1 community Wiki site. A collaborative website relative to the JP1 community to which anyone can contribute!

'''PLEASE NOTE:''' The Wiki section of this website has a different account system than the Forums, so please don't try to log onto the Wiki using your JP1 account id. If you wish to contribute, please see the [[Main Page#Note to new Wiki users|Note to new Wiki users]] below, and one of us will create a Wiki account for you.

==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.
*[https://www.hifi-remote.com/radioshack/ Radio Shack remotes page]
*[https://www.hifi-remote.com/rcinfo/ Radio Shack's www.rcinfo.com site]
*[https://www.hifi-remote.com/ofaold/ One For All backup #1]
*[https://www.hifi-remote.com/ofausa/ One For All backup #2]
*[https://www.hifi-remote.com/ofa-int/ One For All International]
*[https://www.hifi-remote.com/urc/ UEI's cable remotes page]
*[https://www.hifi-remote.com/hag/ Hudson Access Group's OFA page]

The following are user-maintained sites that are no longer available.
*[https://www.hifi-remote.com/wasser/ John Wasser's old OFA site]
*[https://www.hifi-remote.com/ziggr/ Zig's Amazing IR Remote Control Page]
*[https://www.hifi-remote.com/huras/ Dave Huras's X10 and OFA Page]
*[https://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]]
*[https://www.hifi-remote.com/forums/viewforum.php?f=19 Slingbox forum]
*[https://www.hifi-remote.com/forums/dload.php?action=category&cat_id=97 Slingbox files] (inactive)

==Resources==
*[https://controlremote.sourceforge.io/ Remote Master Download]
*[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]]
*[https://www.hifi-remote.com/forums JP1 Forums]
*[https://www.hifi-remote.com/forums/dload.php JP1 Files] (inactive)
*[https://www.getzweb.net/jp1/ JP1 Lookup Tool]
*[https://www.youtube.com/watch?v=ubrq9Pr3Y1Y&list=PLXmyroJbN9CAxc6vADS4iiXQT3fp0c-Iq JP1 "How To" Videos]

==References==
*[https://www.hifi-remote.com/files/wiki/Lutron-Master-List.xls Lutron Master List]
*[https://www.hifi-remote.com/files/wiki/IR_AVR_121.xls Onkyo Master List]
*[https://www.hifi-remote.com/files/wiki/Pioneer_Master_List.rmdu Pioneer Master List]
*[https://www.hifi-remote.com/files/wiki/Sanyo_Projector_Master.rmdu Sanyo Projector Master List]
*[https://www.hifi-remote.com/sony/ Sony Master List]
*[https://www.hifi-remote.com/files/wiki/Yamaha-Master.zip Yamaha Master List]

==Note to new Wiki users==
Due to the incredibly high number of spam accounts being created on this wiki, we have been forced to disable the New Account feature. If you wish to contribute to the wiki, please contact any of the following via the main JP1 Forum:
[https://www.hifi-remote.com/forums/memberlist.php?mode=viewprofile&u=2 Rob],
[https://www.hifi-remote.com/forums/memberlist.php?mode=viewprofile&u=1350 Vicky],
[https://www.hifi-remote.com/forums/memberlist.php?mode=viewprofile&u=13357 3FG],
[https://www.hifi-remote.com/forums/memberlist.php?mode=viewprofile&u=823 xnappo],
[https://www.hifi-remote.com/forums/memberlist.php?mode=viewprofile&u=343 mdavej].

The 3660 family

2025-11-23T15:24:04Z

The Robman: /* User Manuals */

The sections of this page follow the order of the User Manual that comes with the remote, and seeks to compare what you can do with the Remote Master software and a JP1 cable, compared to the Remote on its own.

=About this family of remotes=

These remotes include the '''[https://www.oneforall.com/universal-remotes/urc-3661-essential-6-antimicrobial-remote-control/ One For All URC-3661]''' (Europe), '''[https://www.oneforall.com/en-us/universal-remotes/urc-3680-essential-8-antimicrobial-remote-control One For All URC-3680]''' (USA), '''[https://www.walmart.com/ip/747238608 Onn URC-3660]'''(Walmart, USA) and '''[https://www.insigniaproducts.com/pdp/NS-RMT8D21/6495830 Insignia NS-RMT8D21]''' (Best Buy, USA). There is also the Insignia NS-RMT5D21 which has only four device buttons but also limited access to an Audio device. The URC-3660 and URC-3661 have six device buttons, but are capable of controlling eight devices but only if used with RMIR. The other two have eight device buttons. In the URC-3660 and URC-3661, RMIR refers to the missing buttons as "Dev4" and "Dev8". In addition, the NS-RMT5D21's two further missing device buttons are labelled "AUDIO" and "Dev7". There is also a missing Activity button on this one, referred to as "button5". You can access the devices without a button by putting Dev4/Dev8 (or AUDIO/Dev7) in a macro. More about Macros later. There are powerful features on these remotes which are enabled with RMIR, in conjunction with a JP1 cable which connects to your computer.

=Setting Up Your Remote=

In the manual that comes with the remote, you are shown how to use built-in device codes to set up your devices. This may be adequate for your needs, but on occasions, not all buttons on the original remote will become available on your remote. In some cases, buttons may not be in the right place, or to your requirements. With RMIR there is another way.

Your remote is able to "learn" signals from your original remote, and RMIR is able to decode those signals, in such a way that you can build up your own device code. You can then use the accompanying RMDU program to create your own Device Upgrade. The disadvantage is that it takes time and patience. One advantage is that you can get every button exactly where you want it. Another is that you can often get information to add one or two extra controls that were not originally on your remote, for things such as Discrete On and Discrete Off, as opposed to a Power Toggle button. Such controls are very useful in macros to turn everything on or off, without things getting out of sync, and you can often find them out by asking on the JP1 forum.

You can find out how to add devices from other JP1 users, or to create your own from scratch, on [http://www.hifi-remote.com/wiki/index.php/JP1_-_Just_How_Easy_Is_It%3F this page]. You should read the entire page, and also [http://www.hifi-remote.com/wiki/index.php/JP1_Cables this one], which shows how to make a JP1 cable.

=Volume Punch Through ("Volume Lock")=

The manual for your remote shows you how to lock your volume and mute buttons so that they always operate the same device. However, on the "General" Tab of RMIR, you can assign "Volume Punch Through" individually. So, for example, you can set volume controls on your BluRay device to operate the Volume on the TV, but the volume on a different device (say a CD player) to operate the volume on your amplifier. You only get this flexibility with RMIR.

=Multi Macros ("Channel Shortcut Macros")=

This is where we get to the real power of this remote, in conjunction with RMIR.

RMIR, on most remotes, enables use of a short press of the "Setup" key, in order to add a Shifted state to each key (two short presses for number keys). But with this family of remotes, there is also the Multi-Macro.

In the Remote’s manual, you are shown how to put a sequence of numeric macros on the four colour keys, representing your favourite channels. Using the Red button as Sport, if, instead of briefly pressing the Red button, which sends the normal signal associated with that button, you press and hold it for a couple of seconds, you will get the channel you programmed in, and if you do another long press, it will go to the next one in the list. These macros can be global or device-specific.

However, if you use RMIR, the macros can include keys other than numeric keys, and each macro can be put on almost any key. Not the three App keys (between the colour keys and the numbers), the Rewind/FastFwd keys, nor the device keys. And they will clash with the short-press function on a key where the short-press function involves a key move (including Volume Punch Through) or a macro. But on most keys they will work properly.

Of course, a Macro can have just one step, and there doesn't have to be more than one Multi-Macro on any given key. As an example, if on your BluRay device, you put a single Device Specific Multi Macro on the Stop key, with just one stage which sends the code for "eject", then if you press the Stop key briefly, the BluRay will stop playing, but if you press and hold it, the disc will be ejected. If you do want to have more than one multi-macro on a key, they are executed in the same order as they appear on the Special Functions tab.

Another example is the Power key. You can use a short press to send the normal Power function to a device. A long press can be used to run a macro which will switch off the device and also other devices needed to use that device. For example, the BluRay player would have a macro on the long press to switch off the player, the TV and also the amplifier.

You have 10 phantom keys (i.e., keys that are not physically on the remote, but which you can allocate in RMDU and include in macros) and 10 shifted-phantom keys per device. This gives you plenty of options for Shifted keys and Multimacros.

=Real-Time Macros ("App Shortcut Keys")=

The Manual describes three App Shortcut Keys which can learn a macro that you enter in real time, giving the opportunity to wait for certain functions to have taken place before you press the next key. Once learned, you can just press the key and the remote sends the signals, remembering the times for which keys are held down, and the delays between them.

With RMIR, you can place these macros on any key, global or device specific. You can actually write them from scratch, or edit the time for which each signal is sent, and the delay between signals.

=Activities=

The Manual describes "Activities" which allows you to have groups of keys from different devices working at the same time. There are more choices than given in the manual (for the URC-3660/1 at least) which involve Dev8 as the audio device. But you need RMIR to access Dev8 on the "6 Device" remotes.

The Manual shows "AV Shift" and "Power Macro" as separate headings, but these are tied in with Activities. With "AV Shift", pressing the AV/Input key brings up a TV menu to change the input, and for 10 seconds, the Arrow Keys and OK operate the TV. However, on some TVs, pressing the Input (AV) button cycles through the possible inputs, so you don’t need it to temporarily allocate the arrow keys and "OK" to the TV. Where it does, you may wish to use Activities, but RMIR provides an alternative. If not using activities, it’s still possible to write Key Moves to the Input/AV button so that it always sends the signal to cycle through inputs to the TV. "Power Macro" sends the Power signal to every device involved in the current Activity, but using standard Power keys on the remote which will be toggles. Sometimes the toggles get out of sync, and it’s possible to write your own (device specific) macros for the Power key, to make use of Discrete Power Off signals where known.

If you don't want to use the inbuilt activity settings, but write your own macros instead, RMIR offers a function for this remote on the Advanced drop-down menu, to Disable activities. ''NOTE: This feature is available from version 3.0.0, released on 13 June 2023''. Once you have done this, you can allocate the Activity keys as normal keys, or write macros on them. Unless you do this, anything you put on those keys won’t work. So, as an example, you may allocate a macro to the "Watch Movie" button, which switches on your TV, BluRay player, Amplifier, selects appropriate inputs and leaves the remote buttons controlling the BluRay player, except for Volume Punch Through controlling the amplifier. Depending on your devices, this may or may not be a better plan than using the built-in Activity feature. But without RMIR, you don’t have the choice.

=More Features=

==Macros==

The manual doesn't even mention ordinary macros! With RMIR and your JP1 cable, you can put an ordinary macro on any button except the device buttons. It can be global or device specific. For example, the power button, under the BluRay device, can have a macro that switches off the BluRay player, the amplifier and the TV. Remember earlier that they were all switched on by pressing the "Watch Movie" button.

==Backlight==

The Remote has a backlight, which can be switched on and off by a button at the bottom of the keys. When on, and a key is pressed, the backlight lights up for 10 seconds. RMIR allows you to change the time it lights for, there’s an entry on the General tab for this purpose. RMIR also allows you to allocate a function to that key! This would mean that every time you operated this function, you’d also be switching backlighting on and off. If you don’t want backlighting, you can set the time on the General tab to zero. This won’t stop the backlighting altogether, but it will be very short, a fraction of a second.

In normal use, if backlighting is on, you have to press a key to light up the remote. If you want to operate it in a darkened room, the backlight button can be felt at the bottom of the remote. Press it once to turn backlighting off, press it again and the entire remote will light up.

==Fast Forward, Rewind and Skip==

There is a feature, undocumented in the official manual, where the signal sent by the Fast Forward and Rewind transport controls, depends on how long you hold the button down for. A short press sends a different signal to a long press. In the RMDU program, these alternatives are labelled Rewind, Rewind(Held), FastFwd and FastFwd(Held). Some people use the short press function as "Skip", forwards or backwards as appropriate. Some people prefer to use the longer press for this purpose. As for the built-in devices, there isn’t a great deal of consistency between the two. If you design your own device, as per "Setting Up Your Remote" above, you can, of course, allocate these keys to your own preference.

=User Manuals=
Here are the original user manuals for this family of remotes:
* [https://www.hifi-remote.com/files/manuals/URC-3660-onn.pdf Onn URC-3660]
* [https://www.hifi-remote.com/files/manuals/URC-3660.pdf One For All URC-3660]
* [https://www.hifi-remote.com/files/manuals/URC-3661.pdf One For All URC-3661]
* [https://www.hifi-remote.com/files/manuals/URC-3680.pdf One For All URC-3680]
* [https://www.hifi-remote.com/files/manuals/Insignia_NS-RMT3D21-English.pdf Insignia NS-RMT3D21]
* [https://www.hifi-remote.com/files/manuals/Insignia_NS-RMT5D21-English.pdf Insignia NS-RMT5D21]
* [https://www.hifi-remote.com/files/manuals/Insignia_NS-RMT8D21-English.pdf Insignia NS-RMT8D21]

AIRWidget and IRScope Operating Instructions

2025-11-23T00:15:44Z

The Robman:

[[File:AWFig0.png]]

=INTRODUCTION=
These instructions apply to the Arduino IR Widget ('''AIRWidget''') when used with its companion Windows software, '''IRScope v3.05'''. Performance is functionally identical to that of the old IR Widget when used with '''IRScope 2.01a''', and remains unsurpassed as a tool for capturing, recording, and analyzing signals transmitted by infrared remote controls. Its fast optical sensor detects individual pulses of a remote's infrared LED to measure carrier frequency and ON/OFF times of carrier bursts with much greater accuracy and detail than possible with any other type of measurement instrument. '''IRScope''' uses its smart algorithms and broad data base to identify the signal protocol and provide a complete analysis. A graphic display similar to that of a digital storage oscilloscope provides a visual representation of the signal and shows precise timing details. Each recording can be from 1/2 to 15 seconds long, and can be zoomed in or out to an exact scale from 1 to 1000 microseconds per pixel on your PC screen. The '''AIRWidget''' can display an unlimited number of records simultaneously, and data can be saved or imported and exported in many different formats. Section 13 on page 15 of these instructions shows how to build the simple, inexpensive '''AIRWidget''' shown above and tells how to obtain the free software sketch the Arduino Nano needs to run it.

=APPLICATION SOFTWARE=
A software bundle for '''IRScope''' ('''IRScope v3.05''') can be downloaded at
[https://www.hifi-remote.com/forums/dload.php?action=file&file_id=26615 IRScope] , from which you can extract these files:

# DecodeIR.dll ............................. Application extension
# DecodeIR.html .......................... Chrome HTML Document
# ExchangeIR.dll ......................... Application extension
# IRScope.exe ............................ Application
# MakeHex.dll ............................. Application extension
# ReadMe.txt .............................. Text Document

Installing the software consists simply of placing items (1) through (4) in the same folder (any folder of your choice). Items (5) and (6) are not essential to operation of the '''AIRWidget''' and can be discarded if you don't want to keep them. Item (5) is a good summary of the major features of '''IRScope''', and also provides some useful information on drivers for the '''AIRWidget''' and how to install them. Item (6) is an excellent reference on how protocols are decoded, and provides specifications for more than 100 of the most common infrared remote control protocols.

=USB DRIVER=
'''AIRWidget''' requires the latest virtual COM port (VCP) driver available from FTDI Chip Ltd. Windows 7 may search and find the driver automatically, but if that doesn't work you can download it at: [http://www.ftdichip.com/resources/utilities.htm FTDI Drivers]. If by chance you have an old version FTDI driver installed in your PC (older than '''2.04.06''') you must first uninstall it by using a utility called '''CDM Uninstaller 1.4''', which you can download at: [http://www.ftdichip.com/Support/Utilities.htm CDM Uninstaller] as either a command line version or GUI version. The uninstaller download includes a brief '''readme.html''' file that explains how to use it.

The first time you plug in your '''AIRWidget''', Windows' '''New Hardware Wizard''' will prompt you through the driver installation process in two phases. First, a driver ls installed for the '''USB Serial Converter''' function of AIRWidget. Following that, a driver is installed for the '''USB Serial Port''' function of the '''AIRWidget'''. Windows may do it all automatically. In case of problems you can verify whether your driver installation is working by opening '''Device Manager''' and expanding both the '''Ports (COM & LPT)''' list and the '''Universal Serial Bus controllers''' list. Watch the lists as you plug in the '''AIRWidget'''. A new entry called '''USB Serial Port (COMX)''' (where "X" is the virtual COM port number assigned by Windows) should pop up at the end of the '''Ports (COM & LPT)''' list. Simultaneously, a new entry called USB Serial Converter should pop up at the end of the '''Universal Serial Bus controllers''' list, as shown below in Figure 1.
[[File:AWFig1.jpg|frame|50px|center|Figure 1. Device Manager Showing Typical '''AIRWidget''' Device Recognition]]
=THE MAIN WINDOW=
After plugging in your '''AIRWidget''' and opening '''IRScope''' the operating window will
look something like Figure 2 below. It contains all of the '''AIRWidget''' controls, and will remain on your screen as long as your recording session is active. The large blank area in the center is the decode area. It will list all the signals you capture, and also those you retrieve from previously saved records.
[[File:AWFig2.jpg|frame|50px|center|Figure 2. Default Main Window]]

The appearance may vary slightly depending on which Windows operating system you are using, as well as some of the configuration changes you may have made during your previous session. The registry has keys that preserve many configuration changes from one session to the next so you can save your preferences. To reset everything to default, run '''Regedit''' and delete the '''IRScope''' folder at '''HKEY_CURRENT_USER / Software / UEIC'''.

:'''Port''' .... This must be set to the virtual COM port your '''AIRWidget''' is connected to. There are two ways to set it, manual and automatic. If you drop down the Advanced tab menu and check the '''AutoLocate Widget''' option, then each time you open '''IRScope''' the computer will search through all the ports to find the '''AIRWidget''', and automatically select that port. It indicates this by greying out the Port box, as shown in Figure 2, and you can't change it. If you un-check the '''AutoLocate Widget''' option, then each time you open '''IRScope''' the Port box will be highlighted, letting you know that the port number shown may or may not be correct. If you get a port error message when you try to make a capture, drop down the list of COM ports and manually select the one that '''Device Manager''' says you are connected to.

:'''Capture Duration''' .... Shows the total length of a recording in milliseconds, starting when the '''AIRWidget''' detects the beginning of a signal from your remote. The entry in this box must be a number between '''500''' and '''15000''' ('''1/2''' second to '''15''' seconds). The default value of '''700''' milliseconds is fine for capturing typical individual buttons, but should be increased to capture a macro containing several commands.

:'''Hardware and Mode''' .... '''When using the AIRWidget this must be set on Arduino Widget'''.

:'''View button''' .... Used to select a previously saved file for viewing.

:'''Import button''' .... Used to import '''Pronto''' and '''UEI Learned''' formats and also '''Timing Lists''' of the form displayed by the '''Times Summary''' of the '''Learned Signals''' tab of '''IR.exe''' or by the new '''Summary''' facility of this program. The '''Pronto''' import can handle both raw and pre-defined '''Pronto''' formats other than format 8000. Imported signals are displayed exactly as if they had been captured with the '''AIRWidget'''.

:'''Capture button''' .... Prepares the system to collect data. When you are all set-up and ready to record a signal, place your remote so that its LED emitter is within a few inches of the sensor end of the '''AIRWidget'''. Click on '''Capture''', then press a remote button to transmit a signal. If you wait longer than five seconds before pressing a remote button, the capture will time-out with an error message. Otherwise, captured data will appear at the end of the '''Capture Duration'''. The default configuration is for the program to output an audible beep when you click on '''Capture''', and again if it times out in five seconds. If you don't like the beeps, click on '''Advanced''' and check the '''Suppress Beeps''' option. A flashing white indicator on the '''AIRWidget''' tells you when it detects infrared signals. If the indicator is on constantly, you may be in an area of too high ambient illumination. Avoid bright lights or direct sunlight where you use the '''AIRWidget'''.

:'''Decode area''' .... This area shows a list of all the signals you have captured. Most of the column headings are self-explanatory, and the column widths are completely adjustable. If there is a '''sub-device''', its number appears following a decimal point in the '''Device''' column. Comments in the '''Misc''' column describe repetition characteristics of a signal. No Repeat means the signal consisted of only one full frame. '''+N''' copies means the signal consisted of the initial frame followed by '''N''' identical copies. '''+N''' dittos means the signal consisted of the initial frame followed by '''N''' ditto frames. These terms are defined as follows:

::A "signal" is a message or command that causes a device to do something. A macro is a collection of two or more signals to the same or different devices.

::Signals are made up of one or more "frames". Sometimes frames are repeated as long as a button is held down. Many remotes are programmed to repeat frames two or three times for redundancy, even if a button is barely tapped.

::Full frames often have an initial starting burst (usually distinctively long) and a final OFF time long enough to clearly indicate separation between frames. Within the frame are a series of bursts and spaces that encode address bits, data bits, etc.

::Ditto frames consist of only a starting and ending burst. They are used primarily to indicate that a button is being held down, such as might be done when increasing or decreasing audio volume.

:For saving, exporting, or deleting a recording, moving it up or down in the list, adding notes, etc., select (highlight) the target decode entry by single-clicking anywhere on it. Deselect that one by selecting another one. Or deselect all of them by clicking in a blank area.

:'''Start, End, and Error''' .... This data is used mainly by Forum experts when debugging decoding problems, and so is not of much use to the typical user. You might prefer to make better use of screen space and keep the display simple by sliding those three columns beyond the right edge of the main window, out of sight. Some of the illustrations in these instructions may appear that way.

:'''Add/Edit Note''' .... Used to open a '''Decode Note Editor''' box for adding or modifying a comment in the '''Note''' column for a signal you have selected (highlighted) in the decode panel. Very handy for keeping track of signal source identity, such as brand and model of device controlled, remote used, button pressed, etc.

:'''Save As''' .... Used to save a recording you have selected (highlighted) in the decode area. If you select more than one recording they will be saved as a single file but with each signal clearly separated.

:'''Save All As''' .... A faster and easier way to save the entire list of recordings in the decode area as a single file without having to first select them all individually.

:'''Export''' .... Used to export decoded signals. The format depends on the selection in '''Export Mode''' under the '''Export''' drop-down menu, and can be either '''Pronto''', '''UEI Learned''', or '''Lintronic''' (a format used by the Beoworld community). The '''Pronto''' export is in the raw '''Pronto''' format, but can be generated from either the signal data or from its decode, as required. Exports are appended to a file called '''ExportedUEI.txt''', '''ExportedPronto.txt''' or '''ExportedLintronic.txt''', as appropriate, and the file is created if it does not exist. By default these files are created in the folder containing '''IRScope.exe''' but this can be changed with the '''Set Export Output Folder''' selection in the '''File''' drop-down menu.

:'''Up, Down, and Delete''' .... Used to change the order of items in the decode area, or delete them entirely. Deleting a decode entry automatically deletes its waveform display.

:'''Signal structure''' .... Shows additional information about a signal that is selected in the decode area.

:'''IRP Form''' .... Presents a signal in '''IRP''' form when it is selected in the '''Decode Panel'''. The '''IRP''' representation is made independently of the decode operation, so an '''IRP''' form can sometimes be determined for signals that cannot be decoded by '''DecodeIR''', and vice versa.

:'''Summary''' .... Opens a '''Summary''' display box like the one shown in Figure 3.
[[File:AWFig3.jpg|frame|50px|center|Figure 3. Summary Display]]

:In addition to decoded parameters, the '''Summary''' display includes two forms of timing for a signal, the raw timings as used in the waveform display, and analyzed timings in which repeats have been identified and timings averaged over supposedly identical bursts. To see all timing data, either scroll horizontally with the slider at the bottom, or check the '''Wrap to window''' box and scroll vertically with the slider at the right edge. The '''Summary''' display can be saved in either Rich Text Format '''(.rtf)''' or as a plain text file '''(.txt)'''.

:'''Clear''' .... Clears all entries in the decode area and their corresponding waveform displays. Does not delete any previously saved files.

:'''Clear before capture''' .... Check this box to automatically clear the previous decode data and waveform each time you click on the '''Capture''' button to make a new recording.

:'''Show waveform''' .... Checked by default, provides a '''Waveform Display''' of each new captured signal.

:'''Menu Bar''' .... Right below the title bar of the main window is a menu bar with five drop-down menus, '''File, Edit, Export, Advanced''', and '''Help'''. There are so many sophisticated features within these menus that rather than try to explain them all here I suggest you experiment with them to explore your needs and preferences.

=THE WAVEFORM DISPLAY=
Displaying a detailed picture of a recorded signal is a key feature of '''IRScope'''. When you click on the '''Capture''' button, the PC sends a signal to the '''AIRWidget''' to start looking for an IR signal. When the '''AIRWidget''' detects a remote signal it starts transmitting data to the PC at precise intervals, telling it how many infrared carrier pulses it has seen and when the carrier is turned on and off. At the end of the selected Capture Duration time, the PC sends another signal to the '''AIRWidget''' to stop looking.

'''IRScope''' then processes the data and displays the results two ways. First, its analysis and identification of the recording appears in the decode area of the main window. Second, a '''waveform display''' pops up in the upper left corner of your screen. Those two items define what was captured, and remain linked together (even if you close the '''waveform display'''), until you delete the decode entry. For an example we will use a recording captured from a '''Sony''' remote by pointing it at the '''AIRWidget''', clicking on '''Capture''', the tapping the '''POWER''' button on the remote.
Figure 4 shows the resulting '''waveform display''', and Figure 5 shows the corresponding decode entry that appears in the main window. Even if '''IRScope''' is unable to identify a signal it has captured, it still displays the waveform it received from the '''AIRWidget''' and labels it "unknown" in the protocol column of the decode area.
[[File:AWFig4.jpg|frame|50px|center|Figure 4. Waveform Display for Sony POWER Button]]

[[File:AWFig5.jpg|frame|50px|center|Figure 5. Decode Analysis for Sony POWER Button]]
In Figure 4, the first line of the waveform display shows the carrier frequency, followed by a one-line thumbnail sketch of the captured signal that provides an overview of your recording. Our example was shot with the default selection of '''Thumbnail Scale''', which is '''Entire Waveform'''. That means the thumbnail shows everything that was recorded, from the beginning of the first signal to the end of the Capture Duration period.

To select a different format for the thumbnail display, drop down the '''Advanced''' tab of the main window. There are three choices available.
[[File:AWFig6.jpg|frame|50px|center]]
<div style="text-align: center;">
'''Fixed Resolution''' shows captured data at a resolution of '''400µs''' per pixel:
[[File:AWWv1.jpg|frame|50px|center]]

'''Limited Duration''' shows as much of the captured data as will fit on the line, up to a maximum of 300ms:
[[File:AWWv2.jpg|frame|50px|center]]

'''Entire Waveform''' shows everything captured during the entire Capture Duration time:
[[File:AWWv3.jpg|frame|50px|center]]
</div>
The thumbnail scale is universal, and all waveform displays are immediately updated as soon as a new thumbnail scale format is selected. It's not necessary to capture new samples after changing it, and you can change it as often as you like to find the one that you prefer in various situations.

Sony12 protocol specifies that a remote should transmit a frame repeatedly about twenty times per second as long as a button is held down, but in no case less than three times even for a brief press of the button. In our example the button was just tapped lightly. But If it had been held down steadily, the Misc column of the decode entry would have said +14 copies, and the thumbnail would have looked like this:
[[File:AWWv4.jpg|frame|50px|center]]

The waveform display in Figure 4 depicts the demodulated carrier, drawn to a precise scale of '''20µs''' per pixel. Waveform timing starts on the second line at time 0 (the moment the remote began transmitting), and increases from left to right across successive rows as you move down the screen. Numbers down the left side (11860, 23720, 35580, 47440, etc.) show the time in µs at that point in the waveform. Raised portions of the waveform are periods when the carrier is turned ON, and lower (baseline) portions are periods when it is turned OFF. Numbers beneath the baseline (2400, 600, 1200, 600, etc.) are carrier ON and OFF times in µs, and numbers above the baseline within the raised portions (96, 48, 24, 48, etc.) are the number of carrier cycles (infrared pulses) that were counted by the '''AIRWidget''' during those ON bursts.

Each time you capture a record a new waveform is displayed, always in the upper left area of the screen at default size, stacked on top of those previously recorded, and a new decode line is added in numerical order in the decode area of the window. If the recording is of a macro it will be shown as a single waveform display with the actual time of separation between commands. But each command of a macro will be listed separately in the main window with its own individual carrier frequency, protocol identity, and decoding, as if they were recorded separately.

You can drag waveforms anywhere on your screen to compare several of them at the same time, or you can use the convenient Waveform Selection Tool (described in Section 6) to look at them one at a time. The size, location, and scale of each waveform display can be individually adjusted with the mouse, but the changes will remain in effect only during the current session and cannot be permanently saved with the waveforms.

=THE WAVEFORM SELECTION TOOL=
This is without doubt one of the handiest features of '''IRScope'''. It enables you to list a large number of recordings in the decode area and have instant access to the waveform of any one of them with a click of the mouse. The "Note" below the main window is completely explanatory: "Double-click a decode entry to open and/or highlight its waveform."

Suppose you have collected six records, all listed in the decode area in the order you captured them, with waveforms stacked on top of each other on your screen so that all you can see is record #6 on top of the stack. If you wanted to examine, for example, record #3 you simply double-click on that decode entry in the main window and Instantly that waveform display is brought to the top of the stack and highlighted in red.

You don't even have to leave the waveforms stacked on your screen to use the selection tool. You can get them all out of the way by CLOSING them, as long as you DO NOT delete anything in the decode list of the main window. When you double-click an entry, the waveform will be re-opened automatically and highlighted for you.

The selection tool works similarly with macro waveforms. Instead of having to tediously scroll through a macro waveform display containing a bunch of commands to get to the one you want to examine, just double-click on its decode entry in the main window. If the macro waveform is already opened it will Instantly scroll to that command, without changing size or position, and highlight only that portion of the macro so there's no mistake where it starts and ends. If the macro waveform is closed, it will re-open automatically and scroll to the highlighted command.

=SAVING AND RETRIEVING CAPTURED DATA=
It is strongly suggested that you form the habit of naming and saving important files promptly. When collecting a lot of data it's easy to get carried away and lose track of which records are which. Every capture event, whether it be for an individual signal or a macro, produces a temporary file containing all of the numerical data sent from the '''AIRWidget''' and used to generate the signal analysis in the decode area as well as the graphic Waveform Display. This data can be saved under a filename of your own choosing, or under a default filename automatically generated by '''IRScope''', and consisting of the letters IR followed by a 14-character date/time code in the format: [YYYY] [MM] [DD] [HH] [MM] [SS]. Example: IR20150411083927.
NOTE: This is the date/time you are saving the file, not the date/time the recording was collected.
If you save a file using the same name as on that is already saved, the new file will replace the old file without any warning.

Saved files have an extension of .ict, but they are in text format and you can look at them with any text editor.

[[File:AWFig6.jpg|frame|50px|center|Figure 6. Portion of a Typical .ict File]]

Figure 6 shows the initial portion of a typical .ict file that has been opened with Notepad. A number preceded by a "+" symbol is a carrier burst ON time in microseconds, followed by a comma and another number which is the number of carrier cycles in that burst. A number preceded by a "─" symbol is an OFF time in microseconds between carrier bursts. As you can see, there's enough information in the .ict file to completely reproduce the recording.

Once you have saved a file, its filename appears in the title bar of the Waveform Display. You can tell that the file in Figure 5 has not yet been saved because the title bar is blank. Note that what you are saving consists mainly of raw numeric measurement data, not the decode analysis. When a saved file is reopened, DecodeIR makes a fresh analysis, and its decode data immediately appears in the decode area. If you open two or more copies of the same file, duplicate copies of the decode data will appear. Notes which have been added to a decode entry in the Note column can also be saved so they are reproduced whenever the file is recalled. The note, if saved, is placed at the beginning of the first line of burst data in the .ict file. But configuration changes made to a waveform display (e.g., zooming or resizing the waveform window) cannot be saved.

=CHANGING THE APPEARANCE OF A WAVEFORM DISPLAY=
'''IRScope''' allows you to manipulate the appearance of waveform displays in many ways, for taking measurements, making comparisons, etc. Probably the change that is most useful is to vary the waveform resolution to see more or less detail. It's fast and easy. To illustrate, I'll start with Figure 4 as an example. Here's the start of what that waveform looks like as captured.
[[File:AWWv5.jpg|frame|50px|center]]

First I'll drag the width of the waveform window so that it fills the full width of my screen.
[[File:AWWv6.jpg|frame|50px|center]]

You'll notice that the amount of time shown in each horizontal line increased from '''11860µ'''s to '''23180µs''', enough to show a complete frame on one line. But resolution remains unchanged from the default value of '''20µs''' per pixel.

Clicking anywhere on a waveform display pops up the '''IRScope''' Config box showing the present resolution.
[[File:AWFig6b.jpg|frame|50px|center]]

If we type any value from 1 to 1000 into the highlighted “microseconds per pixel” box and either hit Enter or click OK, the display instantly zooms to the new resolution. Here's what the waveform looks like after we enter a resolution value of 100 microseconds per pixel to show all three frames on one line. The window size and thumbnail resolution are not affected.
[[File:AWWv7.jpg|frame|50px|center]]

The numbers showing ON and OFF times and carrier pulse counts are still there, but they are too close together to be readable. Unchecking those boxes in '''IRScope''' Config turns off the numbers for a clearer view of the waveform.
[[File:AWWv8.jpg|frame|50px|center]]

Here's a portion of a capture from a Pioneer DVD remote at standard resolution. It shows how hard it is to distinguish all the time values when the protocol has many short on/off times in sequence.
[[File:AWWv9.jpg|frame|50px|center]]

Zooming in to a resolution of '''15µs''' or more makes it much easier to read the on and off times.
[[File:AWWv10.jpg|frame|50px|center]]

All examples shown so far are of PWM (pulse width modulation) protocols, where data bits (1's and 0's) are encoded either as the width of carrier-ON bursts separated by fixed duration OFF times, or the width of OFF times separated by fixed duration carrier-ON bursts. Most IR protocols are PWM, but a few are PPM (pulse position modulation) protocol. Here's an example of a Jerrold Cable PPM signal captured at standard resolution.
[[File:AWWv11.jpg|frame|50px|center]]

Since there is no carrier, no frequency value is shown at the beginning of the thumbnail, and a "0" is placed in the Frequency column of the decode entry. Let's zoom out to '''120µs''' per pixel so things are not so spread out.
[[File:AWWv12.jpg|frame|50px|center]]

Now you can see clearly that one frame of the signal has six single pulses, separated by two different spaces, '''11.3ms''' and '''7.7m'''s. Let's zoom in as far as we can go ('''1µs''' per pixel) to look at a pulse in greater detail.
[[File:AWWv13.jpg|frame|50px|center]]

The waveform now shows each pulse has a width of exactly '''100µs''', but that's misleading. Since the Widget only reports the number of pulses it sees every '''100µs''' and doesn't measure them, we can't tell what the actual pulse width is. We know only that it is a single pulse whose width is '''100µs''' or less. (Examining these pulses with an oscilloscope would show them to be actually about '''75µs''' wide.)
=WORKING WITH MACROS=
Capturing a macro is not much different from capturing an individual command. The main thing to remember is to set the Capture Duration to a value greater than the macro duration. Here's an example of a typical macro for which I made an initial test capture with a duration setting of '''10,000 ms'''.

[[File:AWFig7.jpg|frame|50px|center|Figure 7. 10-Second Capture of Macro Containing Four Commands]]

The decode panel shows that this macro sends four commands:
# Turn on a JVC receiver
# Turn on a Sony TV
# Send a TV/VCR command to the TV to set the input to VIDEO1
# Turn on a Dish Network satellite receiver

Note that each command of the macro is listed separately in the decode panel so that there is a place to show carrier frequency and decoding details. In the waveform display of the macro, the thumbnail shows all four commands and the precise timing between them, however irregular it may be. But since several different carrier frequencies are involved, the usual carrier frequency value is replaced with the comment "freq varies".

The first thing I'll do is to stretch the waveform display until that thumbnail line is an even ruler dimension on the PC screen, to give me a thumbnail scale factor of 10 seconds (the capture duration) divided by 10 inches (the length to which I adjusted the line), or 1 second/inch. Then I'll measure from start to the end of the fourth command. It is a little less than 3-1/4 inches. That means I can record the entire macro with a capture duration setting of just a little over 3-1/4 seconds. The data will be just as accurate, but I will avoid a lot of waiting for the capture to complete each time I have to re-record that same macro as I work with it.

[[File:AWFig8.jpg|frame|50px|center|Figure 8. 3.5-Second Capture of Macro Containing Four Commands]]

Here's the same macro with capture duration reduced to 3500ms. Compare this thumbnail with that in Figure 7, and remember that our thumbnail scale is set to show the entire capture duration. When the captured signal is part of a macro, the calculation of carrier frequency shown in the decode entry is close, but not quite as accurate as when the signal is captured alone. So if you want the most accurate measurement of carrier frequency possible you'll have to capture a sample of that signal protocol alone, not as part of a macro. Macro speed (delay between commands) is usually determined by the design of the particular remote control used. Sometimes it is possible to speed-up macro execution, and the '''AIRWidget''' can be of great help in testing changes to make sure you are not trying to go so fast that the equipment doesn't have time to respond to successive commands.

Remember to use the Waveform Selection Tool to zip instantly to different commands of a macro recording for examination. Don't waste time scrolling. You can save one or several commands of a macro as one file by selecting them in the Decode Panel and using the Save As button. But to save the entire macro as one file you don't have to select them one at a time. Just use the Save All As button instead.

=TAKING TIMING MEASUREMENTS FROM A WAVEFORM=
Since waveforms are drawn to exact scale and labeled with elapsed time at the start of each line as well as the duration of all carrier ON and OFF times, you can often just read the time you're interested in, or find it by adding a few values. As an example, suppose I wanted to find the time between the first and second frames of the third command of the macro of Figure 8. First I double-click on item 3 in the decode area so that the Waveform Selection Tool immediately displays command #3 highlighted in red, as shown in Figure 9. The time we are looking for is from '''B''' (the end of frame #1) to '''C''' (the beginning of frame #2).

[[File:AWFig9.png|frame|50px|center|Figure 9. Waveform Display of Macro Command #3]]

That's the same as the OFF time of '''26382µs''' shown right below the line at '''B'''. Too simple. Let's make the example more complicated. Suppose I wanted to find the total length of the third command, from '''A''' to '''D''' in Figure 9. I'll show you three ways to do that, and you can decide which you prefer.
::'''a. Summation Method''' This method is a no-brainer. Just add all the ON and OFF time values below the line from the first point of interest, '''A''', to the second point of interest, '''D'''. The only drawback is there can be a LOT of numbers to add (77 in this case), and avoiding a mistake is tedious work.

::'''b. Ruler Method''' Using an ordinary 12-inch plastic ruler, measure the length of an empty line, such as the one beginning at '''2573620'''. (On my screen it's 7.3 inches long) Then determine the time represented by that line length by subtracting the starting time of one line from the starting time of the next one. For example, '''2632920µs''' - '''2621060µs''' = '''11860µs'''. Now divide '''11860µs''' by '''7.3 inches''' to get '''1625µs''' per inch, which is the scale factor.

::Note that the entire command is contained on nine full lines plus two partial lines. Measure the distance from A to the end of the first partial line (on my screen it's '''0.9''' inch x '''1625µs''' /inch = '''1463µs''') and from the beginning of the last partial line to D (on my screen it's '''1.3''' inches x '''1625µs''' /inch = '''2113µs'''). So the total length of the command is ['''9''' x '''11860'''] + '''1463''' + '''2113''' = '''110316µs''', or simply '''110ms'''.

::'''c. Start-of-Line Method''' This method relies entirely on the times shown at the start of each line in the waveform display. First, stretch or shrink the width of the display to try and place the first point of interest precisely at the beginning of a line, where the time is known. Scroll vertically to keep the point in sight as you keep changing display width to move it as close as possible to the start of any line. Don't worry if you can't place it exactly, just get as close as you can.

[[File:AWFig10.png|frame|50px|center|Figure 10. First Point of Interest Aligned Near Start of Line 2548240]]

::If you look at Figure 10 you can judge from nearby ON and OFF times that we've been able to place the first point of interest within about '''100µs''' of the start of a line. So we'll say the command starts at about '''2548240µs'''.

::Now find the second point of interest and likewise adjust the display to place it at the start of a line.

[[File:AWFig11.png|frame|50px|center|Figure 11. Second Point of Interest Aligned Near Start of Line 2658320]]

::In Figure 11 we were able to place the second point of interest fairly close to the start of a line, so we'll say the command ends at about '''2658320µs'''. (NOTE: The point is actually a little beyond the start of the line, about half the width of one of those '''610µs''' OFF times in the line above. If that bothers you, just add '''300µs''' to the ending time, making it '''2658620µs'''. instead of '''2658320µs'''.)

::Subtracting '''2548240µs''' from '''2658320µs''' (or '''2658620µs''') gives 110ms as the length of the command. This method may give an error of as much as 1ms because of the difficulty of placing events precisely at the start of a line, but that amount of error is negligible when working with infrared signals.

=ADDING NOTES TO YOUR DATA=
The decode entry identifies a recorded button accurately, but a description such as "NEC1 Device 4 OBC 2 Hex BF" might not be of much help if you're searching for a particular recording you may have made a day or week ago. You can avoid this problem by adding descriptive information to a saved waveform easily.

Right-click on a selected (highlighted) entry in the decode area to drop down a menu, then Click on Add Note, to open the Decode Note Editor box.
[[File:AWFig11a.png|frame|50px|center]]

Type your note in the box. The note can be as long as you want, but for practical reasons it is recommended you limit it to what you will be able to see in the limited width of the Note column in the decode area.
[[File:AWFig11b.png|frame|50px|center]]

If all of your note is not visible you can make the Note column wider by sliding the '''Misc''' column to the right until its right edge is just off-screen.
[[File:AWFig11c.png|frame|50px|center]]

Be sure to save the recording AFTER adding or modifying a note, if you want the note to be part of the saved data.

=KEEPING UP-TO-DATE WITH IRSCOPE=
The JP1 Forum is where '''IRScope''' software is maintained, including periodically releasing new protocols, tracking down bugs, etc. Registration is free, and entitles you to post questions regarding not only '''AIRWidget''' applications, but infrared control technology in general. You can also freely download any of the vast collection of data files, instructions, etc. from the site. There are many experts available to respond to your questions and offer advice. You can join by going HERE.

=BUILDING AN AIRWIDGET=
To appreciate the simplicity of the '''AIRWidget''', take a look at its schematic (Figure 12). The main component is the Arduino Nano Microcomputer board. If you are familiar with the Nano you may notice that we use only three of its 30 pins, and you may think the board is over-qualified for the job. However, it was chosen because it is one of the least expensive and smallest microcomputer boards made. When you shop around for this component remember that an '''AIRWidget''' works just as well with Chinese clones of the Nano, most of which use a CH340 UART instead of the much more expensive FTDI brand.

'''AIRWidget''' parts are available from electronics distributors such as Mouser and DigiKey as well as on-line from Amazon, eBay, and other sources. The simplest form of '''AIRWidget''' can be made using a solderless breadboard, which is fast and easy because it does not require the use of a soldering iron
[[File:AWFig12.jpg|frame|50px|center|Figure 12. Complete Schematic of AIRWidget]]

A key component of the '''AIRWidget''' is the QSE159 optical sensor. This 3-pin IC, about the size of a TO92 transistor, combines a very fast photo diode, a high-gain amplifier, a band-pass filter, and an output driver in an infrared-transparent, daylight-opaque package. Its function is to count each carrier cycle of a remote's infrared emitter as it outputs the bursts of IR carrier whose timing encodes the data bits of the transmitted message. The '''AIRWidget''' sends a running total of the count to your PC over its USB connection at precise 100 uS intervals.

There are at least three different sizes of Solderless breadboards: The full size, which is 6-1/2 inches long and has over 800 points; The half-size, which has 400 or more points; And the mini, which has 130 or more points. If you already own a half-size solderless breadboard, Figure 13 shows how you can use it. The four jumper wires should be solid 20 or 22 gage, insulated or non-insulated. This breadboard is fine for a quick-and-dirty trial, but is more than you need if you want to minimize the size of your '''AIRWidget''' or package it in a small box.

[[File:AWFig13.jpg|frame|50px|center|Figure 13. '''AIRWidget''' Built on Half-Size Solderless Breadboard]]

A smaller '''AIRWidget''' can be built using a Mini Solderless Breadboard (Figure 14). These are sold as single units or in packs of five to eight units by Sparkfun, Adafruit, Pololu, Amazon, eBay, and other internet sources.

[[File:AWFig14.jpg|thumb|upright=7|center| Figure 14. AIRWidget Built on Mini Solderless Breadboard]]

Note that two of the wire jumpers are located beneath the Nano. If you want to put the '''AIRWidget''' in a box you will find several sources of small plastic boxes on the internet, usually sold in small bunches. You will have to use one that has inside dimensions of at least 1.5 " x 1.9" x .75" height. Most mini's have hooks on two sides for linking multiple units together. You can reduce the overall length and width another 0.1" if you have trouble fitting it within a box by cutting these off or filing them down.

=INSTALLING THE FIRMWARE IN YOUR PC=
There are three software files that must be installed in your PC before you can use an '''AIRWidget'''.

(1) '''Arduino IDE 1.8.13 or 1.8.19'''. This is a sort of “do it all” software tool that can be used to create, edit, debug, compile, and upload sketches to an Arduino product, such as the '''Nano'''. We use it only to upload the sketch. It is possible you already have it installed in your PC. If so, skip to paragraph (2). If not, search for it online and follow the instructions given for downloading and installing it.

(2) '''AIRWidget v1.00'''. This is the sketch you must upload into the Nano using the IDE. With the IDE installed, go [https://www.hifi-remote.com/forums/dload.php?action=file&file_id=26621 HERE] to get started. Download the '''AIRWidget''' sketch and use '''IDE''' to upload it to the '''Nano'''. Click on Tools to drop down a menu box, and make sure the following selections are listed.

[[File:AWFig14b.PNG|frame|50px|center]]

(3) '''IRScope v3.05'''. This is the program you must install in your PC.
::Go [https://www.hifi-remote.com/forums/dload.php?action=file&file_id=26615 HERE]
::Click on the '''Download''' button.
::Click on the '''Extract''' all button.
::Enter your Arduino folder as destination for the extracted files.
::Make a shortcut that opens '''IRScope.exe''' in the Arduino folder.

[[File:AWFig15.jpg|frame|50px|center|Figure 15. Opening Lines of AIRWidget Sketch]]

Figure 15 shows the first 29 lines of the 182-line sketch. It has long been my wish that we could simplify this wonderful system that '''Kevin Timmerman''' gave us so many years ago for collecting data with an '''IR Widget'''. I owe an enormous debt of gratitude to two people who made that possible:
# a member of the Arduino Forum known only as '''6v6gt''', who programmed the sketch for the '''AIRWidget'''; and
# a member of the JP1 Forum known as '''mathdon''' (Graham Dixon), who updated '''IRScope''' software as needed to maintain compatibility with old hardware as well as the new '''AIRWidget'''.

IR Scope and IR Widget User's Guide

2025-11-23T00:13:56Z

The Robman: /* TOMMY’S MACRO EXAMPLE */

A PDF form of this topic can be found here[https://www.hifi-remote.com/forums/dload.php?action=file&file_id=9696],

''Documentation written by Vicky, Tommy Tyler and Graham Dixon''

==Introduction==
[[Image:irscope0.jpg]] 
The IR Widget is a tool for recording signals transmitted from infrared remote controls. Its small optical detector probe is placed a few inches in front of a remote to capture the output signal. The Widget works by counting individual pulses of the remote's infrared LED. It measures carrier frequency and ON/OFF times of carrier bursts with very good accuracy. A Widget has the capacity to capture and display an almost unlimited number of records 1/2 second to 15 seconds in length.

IRScope is the software that collects and displays the data from the Widget. IRScope provides a graphic display, similar to that of a digital storage oscilloscope, showing precise timing details of the signal. IRScope’s built-in decoder provides a complete descriptive analysis if the signal pattern is recognized. Graphic displays are drawn to exact scale, and can be zoomed, stretched, dragged, scrolled, and saved.
IRScope and an IR Widget are great tools for studying infrared signals. The IR Widget and IRScope were designed by Kevin Timmerman. Tommy Tyler enhanced the design and sells them. You can find Tommy Tyler's Store in the market place in the JP1 site. Graham Dixon (mathdon) took over development of IRScope and made some exciting enhancements that make the software a fantastic tool for anyone studying signals, even if they have not purchased a Widget.

There are many ways to capture a signal for analysis. For instance, a JP1 user with a learning remote and interface cable, can capture signals with the remote and read them in via IR or RMIR. Many people find that procedure cumbersome. With a Widget, you can avoid the frustration of collecting learns in batches, the hassle of botched learns, and the confusion of figuring out what you put where.
A Widget can learn virtually all signals. Some signals are too complicated to be analyzed and stored by a JP1 remote, but a Widget doesn’t have these shortcomings.

The Widget is an economical solution. It is a bargain when compared to other oscilloscope solutions. The Widget can be less expensive than purchasing a learning remote with a cable for data collection too.
The Widget is an IR collection tool; it doesn’t function as a remote. That is the one place where the JP1 remote with interface cable does have a huge advantage. You can use the learning remote to record the signals, and have a pretty cool remote that you can program with your PC using the JP1 tools. For a serious enthusiast, I’d recommend having both the Widget and a learning remote with cable interface!

IRScope’s oscilloscope type representation of the infrared signal’s timing data can be very helpful when learning about infrared protocols. IRScope can acquire timing data from several different sources. This makes the software helpful even without a Widget. The signal can be captured by the Widget or the signals can be imported from UEI (JP1) remote type learns, Pronto type learns or raw timing data. IRScope provides a large variety of output. Signal information can be saved in IRScope’s .ict (Infrared Capture Text) files; the information can be exported as UEI learns, Pronto learns, Lintronic forms; and detailed Summary reports.
2
IRScope’s creates and reads .ict (Infrared Capture Text). Originally these files only recorded a single capture. Two of the new features that Graham has added, (allowing notes and saving multiple signals from several capture sessions in a single ict file), make ICT files a convenient way of documenting and organizing signal information. An ICT file holds all the timing data and any notes entered while collecting signals. The decode data is not saved in the ICT file; the signal is decoded each time the ICT file is opened. This method allows ICT decodes to be improved when new versions of decodeIR.dll become available. DecodeIR.dll is the decoder used with all the JP1 tools such as IR, RMIR, DecodeCCF and IRTool.

IRScope is a powerful diagnostic tool. It is always nice to be able to see what is coming out of the remote. The waveform allows you to visually compare signals to see if the OEM and upgrade signals match. It is very useful in diagnosing macro problems, such as duration problems or programming errors. IRScope can also be useful in diagnosing a wide variety of upgrade issues.

==Software Installation==
The IRScope software bundle contains everything except the Widget’s USB driver. IRScope can be downloaded from the '''File Section>Tools>Main''' in the JP1 forum.

The bundle includes:
#IRScope.exe
#DecodeIR.dll
#Features of IRScope version. xxx .pdf. a document that describes the new features
#DecodeIR.html a document that gives specifications for various protocols.
#MakeHex.dll
#ExchangeIR.dll

Unzip the download and place all six files in the same folder.

IRScope requires version DecodeIR.dll v2.39 (or later) that is supplied in the download package.
Many of the JP1 tools use DecodeIR.dll, so you may have older versions on your PC. If you store your decodeIR.dll in a centralized Windows System folder so that the applications share the same dll, make sure that your system is using decodeIR.dll version 2.39 or later.

==IR Widget Driver Installation==
The Widget’s driver is not bundled with IRScope, the driver is downloaded separately.

The Widget requires version 2.04.06 (or later) of the FTDI USB driver. You can download version 2.06.00 from: http://www.ftdichip.com/Drivers/VCP.htm. If you have an older version in your PC (perhaps from using a USB JP1.2/3 (Flash) Interface) you must first uninstall it. You'll need a utility called CDMUninstallerGUI, which you can download from: http://www.ftdichip.com/Resources/Utilities.htm. The download includes a brief readme.html that explains how to use the uninstaller.

The first time you plug in a Widget after uninstalling old drivers, Windows' New Hardware Wizard will prompt you through new driver installation in two phases. First it installs a driver for the USB Serial Converter function of the Widget. Following that, it installs a driver for the USB Serial Port function of the Widget.
To verify that your driver installation is successful, open Device Manager and expand both the Ports (COM & LPT) list and the Universal Serial Bus controllers list. When you plug in the Widget, a new entry called USB Serial Port (COMx) will appear at the end of the Ports list, and simultaneously a new entry called USB Serial Converter will appear at the end of the Universal Serial Bus controllers list, as shown in Figure 1 on the following page.

[[Image:irscope1.jpg]] 
'''Figure 1. Device Manager Showing Typical Widget Device Recognition'''

IRScope should be able to Autodetect this port, but on some systems Autodetect does not work, and you may need to manually enter that COM port number in the Port field in IRScope’s main window.

==Exploring the Main Screen==
[[Image:irscope2.jpg]] 
'''Figure 2. Default Main Window'''

Capturing a Signal
To capture a signal with your Widget, you will need to make sure the Port, Capture Duration and Hardware and Mode settings are set and then press the Capture button.
Port
A grayed-out Port box indicates that you cannot drop down the list of COM ports because IRScope has already found the correct USB port. However, if the Port number were enabled, as in Figure 2, it could mean that the AutoLocate feature is not working. In the Advanced menu make sure there is a check mark in front of AutoLocate Widget. Try closing and relaunching the program. If it still doesn’t automatically locate, manually find the COM port number in the device manger as you did when you verified your Widget driver installation. Type that COM number in the port field in IRScope’s main window.
Capture Duration
Shows the total length of a recording in milliseconds, starting when the Widget detects the beginning of a signal from the remote. The entry in this box must be an integer value between 500 and 15000 (1/2 second to 15 seconds). The default value of 700 mS is fine for capturing individual buttons, but must be increased to capture a macro. You will have 5 seconds to start sending a signal, and as soon as the signal is detected, IRScope will record infrared activity for the specified capture duration.
Hardware and Mode
When working with a Widget, ALWAYS leave this set on IR Widget Count!
Capture Button
The Capture button prepares the system to collect data. When you are all setup and ready to record a signal, click on Capture, point your remote at the Widget’s probe and press a remote button. If you wait longer than 5 seconds before starting transmission, the capture will abort with an error message. The default configuration is for the program to output an audible beep when you press Capture and start the five second clock. If you don't like beeps, check the Suppress Beeps option in the Advanced menu.

SHOW WAVE FORM 
[[Image:irscope3a.jpg]] 
If the show waveform box was checked, a waveform window will appear when the capture is finished.

[[Image:irscope3.jpg]] 
'''Figure 3. Waveform Window'''

The waveform window is very useful in diagnosing problems, and creating custom protocols. The waveform in Figure 3 has been labeled to show what the various parts of a waveform represent. A brief description follows here. The Waveforms Explained section provides a more detailed description.
The top line of the waveform windows shows thumbnails. There are three options to control how the thumbnail line will be displayed. Under the Advanced menu, Thumbnail Scale you have the option of Fixed Resolution, Limited Duration and Entire Waveform. You should choose a Thumbnail Scale that best suits your activity.
The Frequency is in the upper corner. The frequency in Figure 3 is 39944hz. If a mixture of signals was captured, the frequency is not computed and instead < freq varies> is shown. Frequency is a measure of how many times the light flashed during the ON pulse time.
The waveform is completely scalable. If the timings are so close that the numbers are unreadable, you can click on the form and change the number of microseconds per pixel. You can also remove the pulse counts, those pulse times or the elapsed times.
The pulse times are the numbers below the line. You may be used to seeing pulse times with + and minus like +2400, -600, + 1200 –600 +600 when no waveform is available. The – was used to indicate the quite times, not to indicate a negative time.
If you don’t want to see the waveform on each capture uncheck the show waveform option. 6

[[Image:irscope4.jpg]] 
'''Figure 4. Decode Grid and Action on Items Selected box'''
Decode Grid
The decode grid shows a list of decodes for the recorded signals. The grid has 11 sizeable columns, #, Frequency, Protocol, Device, OBC, Hex, Note, Miss, Start, End and Error. Depending on how the columns have been sized, some columns may be hidden. The grid allows single or multiple signal selections. Double click on a selection to open and or highlight its waveform.
In Figure 4, the grid entries for the highlighted signal show:
# 2. This shows the position this signal holds in the grid and ict files.
Frequency 37423. This shows the relation ship of the pulse count to the pulse time.
Protocol This shows which set of formatting rules the signal follows, in this case Panasonic.
Device 128.0 indicates a device of 128, sub-device 0 (note a zero and a blank are not the same)
OBC this is the function part of the signal. That is the part that changes with each key press.
Note this information is input by the user.
Hex codes for the specific button. NEVER USE THIS hex to create an upgrade. The hex you need to enter in RemoteMaster’s (RM) hex column may not match this hex!
Misc describes the repetition characteristics of the signal and other miscellaneous information.
No Repeat means the signal consisted of only one full frame. +N copies means the signal consisted of N+1 full frames. +N dittos means the signal consisted of one full frame followed by N ditto frames. Ditto frames consist of only a starting and ending burst but no data portion. Dittos frames are used to indicate that a button is being held down.
Start and End the numbers in the columns refer to carrier ON bursts in a signal, and are used only by experts when debugging decoding errors.
Error column is not used.
Action on Items Selected Box
All the buttons in this box work on the lines selected in the Decode Grid.
Add/Edit Note allows a label to be entered on the selected grid line. Add/Edit Note is how the “pause” and “play” descriptions got into the Note column.
UP and DOWN moves the selected signals in the decode grid.
DELETE deletes the selected signals from the decode grid.
EXPORT writes timing information in UEI Learns, Pronto Learns or Lintronic timing formats to a text file. See the Export menu and in the IRScope’s Output formats sections for more detailed information.
SAVE AS saves the timing data for the selected signals in an ICT (Infrared Control Timing) file.

[[Image:irscope5.jpg]] 
'''FIGURE 5. Signal structures and IRP Form'''

Signal Structure
This gives general information about the selected signal.
IRP Form:
IRP notation is a way of describing the signal. The IRP Form displayed in IRScope is a generic IRP form. The portion shown as {A=} is a representation of the analyzed data portion of the signal. You can adjust the way A is displayed from the Advanced menu. If you want to understand the protocol rules, take a look at the official IRP for the protocol. To see the official IRP, select HELP and then select Interpreting Decoded IR Signals.
Generic IRP Form.
{37.4k,427,msb}<1,-1|1,-3>(8,-4,A:48,1,-73.5m)+{A=$400401008889}; Alt leadout form: ^127m
The official IRP for the Panasonic code looks like this.
{37k,432}<1,-1|1,-3>(8,-4,2:8,32:8,D:8,S:8,F:8,(D^S^F):8,1,-173)+
D is the device, S is the subdevice, and F is the OBC and the signal is lsb.

[[Image:irscope6.jpg]] 
'''FIGURE 6. Clear and Clear before capture'''

CLEAR
The clear button will immediately delete everything from the decode grid, to delete selected lines use the Delete in the Action on Items Selected area.
Clear before Capture
If this option is checked, the contents of the decode grid will be erased every time you capture a new signal.

[[Image:irscope7a.jpg]] 
SAVE ALL AS
Save All As, will save an ICT (Infrared Capture Text) file, that will includes all the signals in the decode grid. The Save As only saves the highlighted signals. ICT files that have a complete signal set are very a very convenient way to pass information.
VIEW
The view button allows you to open an ICT file and adds all the information into the decode grid.

[[Image:irscope7.jpg]] 
'''FIGURE 7. SUMMARY REPORT'''

SUMMARY
The summary button produces the report in figure 7. The DECODES portion of the report reproduces the decode grid from the main screen. This can be helpful if you need a hard copy to do your data entry in RM or KM. I like to copy and paste this data into a spreadsheet and manipulate it so that I don’t have to risk making data entry errors.
The RAW TIMINGS DATA and ANALYSED TIMING DATA portions can be useful if the signals couldn’t be decoded because they didn’t follow the rules for any known protocol.

[[Image:irscope8.jpg]] 
'''Figure 8, IRScope’s Import window'''

IMPORT
IRScope is also capable of importing signal in the form of Pronto Hex, Raw timing data and UEI learns. Select the import type; indicate the number of repeats to be displayed and paste the timing information into the area provided. 
Pronto Hex is a form of timing data that is used in high end Philips remotes. This is a convenient way to exchange information about IR signals. Many manufacturers post data in Pronto Hex format. Pronto users exchange information via pronto hex and in CCF files and PCF files containing their configurations. 
Pronto Hex looks like this. 
0000 006C 0032 0000 0080 003C 0010 000F 0010 000F 0010 002F 0010 000F 0010 002F 0010 000F 0010 000F 0010 000F 0010 002F 0010 002F 0010 000F 0010 000F 0010 000F 0010 002F 0010 002F 0010 000F 0010 000F 0010 000F 0010 000F 0010 000F 0010 000F 0010 000F 0010 000F 0010 000F 0010 000F 0010 000F 0010 002F 0010 000F 0010 000F 0010 000F 0010 000F 0010 002F 0010 000F 0010 000F 0010 002F 0010 002F 0010 000F 0010 000F 0010 000F 0010 002F 0010 000F 0010 002F 0010 000F 0010 000F 0010 002F 0010 000F 0010 000F 0010 000F 0010 34AC 
Raw Timing Data is another form of timing data often found. When using data you’ll need a frequency as well as the pulse times. If no frequency is available try 38000. 
+3414 -1686 +433 -421 +433 -1294 +406 -440 +433 -421 +433 -413 +433 -421 +433 -440 +406 -440 +433 -421 +433
-413 +433 -421 +433 -413 +433 -421 +433 -1294 +433 -413 +433 -421 +433 -413 +433 -421 +433 -440 +406 –440 +433 -421 +433 -413 +433 -421 +433 -1294 +406 -440 +433 -421 +433 -413 +433 -421 +433 -413 +433 -421 +433
-440 +406 -440 +433 -421 +433 -413 +433 -421 +433 -440 +406 -1294 +433 -421 +433 -413 +433 -421 +433 -413 +433 -421 +433 -440 +406 -440 +433 -1267 +433 -421 +433 -440 +406 -1294 +433 -73694
10 
UEI Learns 
The learns from a JP1 remote can be imported too. From IR or RMIR, edit the learned key and then copy the data portion of the learned command, and then paste it into the Import window in IRScope.

[[Image:irscope9.jpg]] 
'''Figure 9, Learned signal from IR'''

JP1 people are pretty familiar with this screen. IR is the main JP1 program for downloading information from our remotes. Similar functionality is available in RMIR, the java based version of IR. IRScope can format and export UEI learns or Pronto learns. That exported data can be used to add learns to a JP1 remote.

==Exploring the Menus==
File Menu
<table width="592" border="1">
<tr>
<td bgcolor="#CCCCCC" width="183" >Capture </td>
<td width="393">Capture is the same as the Capture button on screen

 </td>
</tr>
<tr>
<td bgcolor="#CCCCCC" width="183" >Open </td>
<td width="393">Open is same as the View button on screen</td>
</tr>
<tr>

<td bgcolor="#CCCCCC" width="183" >Import</td>
<td width="393">Import is same as Import button on screen.</td>
</tr>
<tr>

<td bgcolor="#CCCCCC" width="183" >Summary</td>
<td width="393">Creates as timing summary report, same as the summary button on screen</td>
</tr>
<tr>

<td bgcolor="#CCCCCC" width="183" >Save Last Signal</td>
<td width="393">Saves the last signal captured with auto number naming.</td>
</tr>
<tr>

<td bgcolor="#CCCCCC" width="183" > Save Last Signal As</td>
<td width="393">Saves the last signal captured but asks for a filename.</td>
</tr>
<tr>

<td bgcolor="#CCCCCC" width="183" >Save Selected As</td>
<td width="393">Saves the information for the signals selected in the decode grid.</td>
</tr>
<tr>

<td bgcolor="#CCCCCC" width="183" >Save All as</td>
<td width="393">Saves all the signals in the decode grid</td>
</tr>
<tr>

<td bgcolor="#CCCCCC" width="183" >Set Folder > 
Set Save Folder</td>
<td width="393">Use this option to set the folder where the ict files are to be saved.</td>
</tr>
<tr>

<td bgcolor="#CCCCCC" width="183" > Set Export Output Folder</td>
<td width="393">This is the folder where exported files will be saved. If this option is grayed out, the Advanced menu’s Use Common Folder has been set and exported files will be written to the Save folder specified above.</td>
</tr>
<tr>

<td bgcolor="#CCCCCC" width="183" > Set IRP Folder</td>

<td width="393">IRP files are only needed to export Pronto hex in the Export Proto like decode mode. You don’t need these files to export Pronto hex from timings. These IRP definitions can be downloaded from the JP1 file section. Use this option to locate the folder where the IRP definition files are stored.</td>
</tr>
<tr>

<td bgcolor="#CCCCCC" width="183" >Clear Recent
1 filename 
2 filename 
3 filename</td>

<td width="393">Clears the list of the last files accessed. 
IRScope saves the last 6 files accessed.</td>

</tr>
<tr>

<td bgcolor="#CCCCCC" width="183" >Exit</td>
<td width="393">Quits the program and closes all waveform windows.</td>
</tr>
</table>

.
Edit menu
<table width="592" border="1">
<tr>
<td bgcolor="#CCCCCC" width="183" >Select All Ctrl+A</td>

<td width="393">Selects all the signals from the decode grid.</td>
</tr>
<tr>

<td bgcolor="#CCCCCC" width="183" >Deselect All Ctrl+D</td>

<td width="393">Deselect all the signals from the decode grid.</td>
</tr>
<tr>

<td bgcolor="#CCCCCC" width="183" >Clear All</td>

<td width="393">Deletes all the signals from the decode grid.</td>
</tr>
<tr>

<td bgcolor="#CCCCCC" width="183" >Add Note to Selected Ctrl+N</td>

<td width="393">This allows you to label each signal in the decode grid. This is an important feature when you are collecting a set of signals. These notes are used in the summary reports and in the export reports.</td>
</tr>
<tr>

<td bgcolor="#CCCCCC" width="183" >Move Selected Up Ctrl+Up</td>

<td width="393">Moves the selected items in the decode grid up.</td>

</tr>
<tr>
<td bgcolor="#CCCCCC" width="183" >Move Selected Down Ctrl+Dn</td>

<td width="393">Moves the selected items in the decode grid down.</td>
</tr>
<tr>

<td bgcolor="#CCCCCC" width="183" >Delete Selected Del</td>
<td width="393">Deletes the selected items from the decode grid.</td>
</tr>
</table>

Export Menu
<table width="592" border="1">
<tr>
<td bgcolor="#CCCCCC" width="183" >Export Last Signal</td>
<td width="393">Creates or appends to a file with the name ExportedUEI, ExportedPronto or ExportedLintronic.txt depending on the current Export Mode. The file will be created in the file Export Output Folder or the Common Save Folder. Exports the last signal captured in the mode selected.</td>
</tr>
<tr>

<td bgcolor="#CCCCCC" width="183" >Export Selected Ctrl+E</td>
<td width="393">Same as above, only this will export the signals selected in the decode grid.</td>
</tr>
<tr>

<td bgcolor="#CCCCCC" width="183" >Export Mode</td>
<td width="393"> </td>
</tr>
<tr>

<td bgcolor="#CCCCCC" width="183" > UEI Learned</td>
<td width="393">Use this option to create or append to a file named ExportedUEI.txt. The individual learns can be pasted into an ir file and uploaded into a learning remote.</td>
</tr>
<tr>

<td bgcolor="#CCCCCC" width="183" >Pronto from signal</td>
<td width="393">Use this to create or append to a file named ExportedPronto.txt file based on the actual timings.</td>
</tr>
<tr>

<td bgcolor="#CCCCCC" width="183" >Pronto from decode</td>
<td width="393">This file will create or append to a file named ExportedPronto.txt file based on the protocols rules. To use this option you need to download the IRP files required for MakeHex and set the IRP folder. Use this option to create proto hex suitable for presentations.</td>

</tr>
<tr>

<td bgcolor="#CCCCCC" width="183" >Lintronic</td>
<td width="393">This file will appends to or creates an ExportedLincronic.txt file based on the actual timings.</td>
</tr>
</table>

Advanced Menu

<table width="592" border="1">
<tr>
<td bgcolor="#CCCCCC" width="183" >AutosSave Types > </td>
<td width="393">AutoSave saves every Widget capture automatically. New features in the software allow better options for saving signals. Saving a set is a better practice than using autosave.</td>

</tr>
<tr>

<td bgcolor="#CCCCCC" width="183" >IR Capture Text (.ict)</td>
<td width="393">Infrared Capture txt is one of the options for autosave. These are the IRScope files that can be reopened.</td>

</tr>
<tr>

<td bgcolor="#CCCCCC" width="183" >Audio(.wav)</td>
<td width="393">This legacy format is only available in AutoSave mode from initial captures.</td>

</tr>
<tr>

<td bgcolor="#CCCCCC" width="183" >TV-B-Gone (tvbg.c)</td>
<td width="393">This legacy format is only available in AutoSave mode from initial captures.</td>

</tr>
<tr>

<td bgcolor="#CCCCCC" width="183" >AutoSave Mode</td>
<td width="393"> </td>
</tr>
<tr>

<td bgcolor="#CCCCCC" width="183" >Auto Filename</td>
<td width="393">This option automatically generates a filename for the ict files. The default filename is consists of the letters IR followed by a 14-character date/time code in the format: [year] [month] [day] [hour] [minute] [second]. For example, IR20091212162102.ict</td>
</tr>
<tr>

<td bgcolor="#CCCCCC" width="183" >Prompt for Filename</td>
<td width="393">This option automatically saves every capture, but pauses to allow entry of a meaningful name for each ict file.</td>
</tr>
<tr>

<td bgcolor="#CCCCCC" width="183" >AutoLocate Widget</td>
<td width="393">This feature automatically finds which Com Port is assigned to the Widget.</td>
</tr>
<tr>

<td bgcolor="#CCCCCC" width="183" >Suppress Beeps</td>
<td width="393">IRScope beeps when it is ready to start the capture unless the option is checked.</td>
</tr>
<tr>

<td bgcolor="#CCCCCC" width="183" >Hide Save-Panel </td>

<td width="393">[[Image:irscope10a.jpg]]
This option hides the Save panel. This panel duplicates the AutoSave Types and AutoSave Mode menu selections described above.</td>
</tr>
<tr>

<td bgcolor="#CCCCCC" width="183" > Thumbnail Scale</td>
<td width="393">The options below control the way the thumbnails appear in the waveform window.</td>
</tr>
<tr>

<td bgcolor="#CCCCCC" width="183" > Fixed Resolution</td>
<td width="393">Fixed resolution always depicts the thumbnail on a 500ms scale.</td>
</tr>
<tr>

<td bgcolor="#CCCCCC" width="183" > Limited Duration</td>
<td width="393">Limited duration uses a variable scale that depicts the capture or the selected signal.</td>
</tr>
<tr>

<td bgcolor="#CCCCCC" width="183" > Entire Waveform</td>
<td width="393">Represents the entire capture time</td>
</tr>
<tr>

<td bgcolor="#CCCCCC" width="183" > Select on Capture</td>
<td width="393">This option causes the capture to be automatically selected in the decode grid after it is captured. This allows for speedier data entry on the notes field. Turn this option off to manually control which decode grid item is selected.</td>
</tr>
<tr>

<td bgcolor="#CCCCCC" width="183" > Common Output Folder</td>
<td width="393">This features automatically saves Export files in the same folder as the Save Output folder. This option helps users working on multiple projects to keep their work organized.</td>
</tr>
<tr>

<td bgcolor="#CCCCCC" width="183" > IRP Data Format</td>
<td width="393">This option specifies for how the portion of the IRP form that represents the data {A=} will be displayed. In my example A is 32 bits of data. 
Sample IRP form: 
{39.0k,243,msb}<2,-5|2,-12>(35,-4262u,A:32,2,-33.5m)
+{A=$00D4C936}
Binary (base2 prefix 0b) 
{A=0b00000000110101001100100100110110} 
Quaternary (base 4, prefix0q) 
{A=0q0000311030210312} 
Hex (base 16 prefix 0x) 
{A=0x00D4C936} 
Hex (base 16, prefix $) 
{A=$00D4C936} </td>
</tr>
<tr>

<td bgcolor="#CCCCCC" width="183" > Disable Decoder</td>
<td width="393">This disables the decoder and makes the decode grid disappear from the main screen. If you decode grid goes missing check this setting.</td>
</tr>
</table>
Help
<table width="592" border="1">
<tr>
<td bgcolor="#CCCCCC" width="183" >Interpreting IR Decodes</td>
<td width="393">This option opens DecodeIR.HTM in your internet browser. DecodeIR, gives the information about the protocol rules used to decode the signals.</td>
</tr>
<tr>

<td bgcolor="#CCCCCC" width="183" >About</td>
<td width="393">Displays the licensing and copyright information for IRScope. Note that on the software version numbers are not buried in the About box, they are already clearly displayed in the title bar of the main IRScope window.</td>
</tr>
</table>

==Exploring the Waveform==
[[Image:irscope3.jpg]] 
'''Figure 10. Waveform Explained'''

The waveform window is very useful in diagnosing problems and creating custom protocols. The waveform in Figure 10 has been labeled to show what the various parts of a waveform represent.
The waveform can be seen on capture; when you Open or View an ict file; or when you double click on a signal from the decode grid. When double clicking the decode grid, the portion of the waveform that represents the selected decodes will be highlighted in red.
The Frequency is in the upper corner. In Fig.10, the frequency is 39944hz. If a mixture of signals was captured, the frequency is not computed and instead < freq varies> is shown. Frequency is a measure of how many times the light flickered during an ON pulse time period.
The pulse times are the numbers below the line. You may be used to seeing pulse times with + and minus like +2400, -600, + 1200 –600 +600 when no waveform is available. The – was used to indicate the quite times, not to indicate a negative time.
Thumbnails The top line of the waveform windows shows thumbnails. There are three options to control how the thumbnail line will be displayed. Under the Advanced menu, Thumbnail Scale you have the option of Fixed Resolution, Limited Duration and Entire Waveform. Choose a thumbnail scale that suits your activity.
Fixed Resolution When the thumbnail scale is set to fixed resolution, the thumbnail will always represent 500mS. Fixed resolution is your best choice when comparing signals in different waveform windows.
Limited Duration When the thumbnail scale is set to limited duration, the thumbnail will be scaled to show the entire capture dropping any quiet time at the end of the signal. The thumbnail will shrink or expand depending on how long the infrared activity lasted.

Entire Waveform When the thumbnail scale is set to entire waveform, the thumbnail will represent the capture duration including any quite time at the end.
Figure 11 shows the same capture showing in all three thumbnail scales. The capture duration was 1500ms, the infrared activity lasted only far less than the 500ms in the fixed.

[[Image:irscope11.jpg]] 
'''Figure 11. Thumbnail Scales'''

Scalability. Another one of IRScope’s powerful features is the ability to change the resolution of the waveform. Not all signals will display well at the default 20 microseconds per pixel resolution. You can easily change this resolution to make the display more readable. You can also remove the pulse counts, pulse times and the elapsed time numbers from the display.

[[Image:irscope12.jpg]] 
'''Figure 12. IRScope Config Dialog Box'''

Figure 12 shows the scale of the timing chart as presently displayed. The default resolution is 20 microseconds per pixel. The microseconds per pixel can be set anywhere from 1 to 2000. Click OK, and the display instantly shrinks or expands to the new scale.

[[Image:irscope13.jpg]] 
'''Figure 13. Example of Waveforms Zoomed Out 5X'''

Figure 13 shows a simple example where the zooming feature has been used. The waveform displays of signals for buttons "1", "2", and "3" of an RCA remote have each been zoomed out to a resolution of 100 μS per pixel, then the windows were overlayed and lined up for comparison. Can you spot the subtle differences in timing between the three display patterns? Since all the carrier ON times are of uniform duration, and there are two sizes of OFF times, it's obvious this protocol encodes "1" and "0" bits by the amount of OFF time between carrier bursts.
The "1 button" example in Figure 13 typifies the appearance you get when you just zoom out on a signal. The numbers showing ON and OFF times etc. are still there, but they overlap too much to be readable except for some of the larger ON and OFF times. The three check boxes in the IRScope Config dialog box enable you to turn off one or more of these measurements when you want to see a cleaner picture. To illustrate the effect, I unchecked all three boxes when zooming out on the "2 button" and "3 button" waveforms. Zooming in and out is fast, but if you prefer you can also open more than one copy of the same waveform and zoom them out to different scales for simultaneous viewing while studying a signal.
When zooming, neither the size of the window nor the scale of the thumbnail display is changed. Only the scale of the waveform is expanded or contracted to show more or less detail. You can also stretch the overall width of a waveform display window to the full width of your screen, but that won't change the amount of detail shown. For an experiment, try stretching a display until the lines start at 0, 20000, 40000, 60000, etc. By doing this you have adjusted the display so that its width is exactly 20,000 μS, or 20 mS, a nice round number for estimating or measuring the position of various features.

==IRScope's Output==
IRScope has a lot of output formats. The formats are ICT files, Summary Reports, ExportedUEI.txt, ExportedPronto.txt, and ExportedLintronix.txt files. There are also two old legacy formats, audio.(wav) and TV-B-Gone (tvbg.c).
ICT Infrared Capture Text
IRScope's primary file format is the ICT file. ICT files are the only type of files used for both input and output in IRScope. ICT files can be created with the Save As, Save All As buttons and with the Save Last, Save Last As, Save Selected and Save Selected As items on the File Menu. The files will be stored in the folder specified in with the Set Output Save Folder option in the File Menu. Any option that included “As” will prompt for a filename. The other save methods will use automatic file naming form, (IRyyyymmddhhmmss.ict).
ICT files can be opened with the View button from the screen, or with the Open command on the File menu.
Saved files are in text format, and have an extension of .ict. Figure 14 shows the initial portion of a typical .ict file.

[[Image:irscope14.jpg]] 
'''Figure 14. Portions of a Sample.ict File'''

In Figure 14, the numbers correspond to the timing numbers that appeared in the waveform.
A number preceded by a "+" symbol is the ON time in microseconds for a carrier burst, and the number following a comma is the number of carrier cycles that make up that burst. A number proceeded by a "-" symbol is the OFF time in microseconds between carrier bursts. As you can see, there is enough data in the .ict file to completely reproduce a graphic display. Decode data is not part of a saved file. When a saved file is recalled, the decoder reprocesses the data to decode it.
Any notes that were manually entered in the decode grid are also stored in the ict file. When the ict file is opened or viewed the note and decode will be added to the decode grid.

Summary file
The summary file is an rtf (rich text format). This is an output only file. This report is created by pressing the Summary button on the screen, or selecting Summary from the File menu.

[[Image:irscope7.jpg]] 
'''Figure 15. Summary Report'''

Exported files
IRScope can also export timing data in UEI format, Pronto Format, and Lintronic Format. These files are for output only. Each format type has its own predefined filename ExportedUEI.txt, ExportedPronto.txt, and ExportedLintronics.txt. These files will be automatically located in the folder specified for Set Export Output Folder, or if the Common Output Folder option is set on the Advanced menu, these will be located in the Set Save Output Folder. If the filename already exists, the signals will be appended to the existing file. To export, select signals in the decode grid and press the Export button on the screen. The format to be exported is controlled by the Export Mode option on the Export menu.

Figures 16, 17 and 18 are examples of what the exported output looks like when viewed in notepad

[[Image:irscope16.jpg]] 
'''Figure 16. ExportedUEI.txt'''

[[Image:irscope17.jpg]] 
'''Figure 17. Sample ExportedPronto.txt'''

The hex in the ExportedPronto files could have been created either from the raw timing data, or from the decode. The difference is that in Pronto from decode mode, the timings will be adjusted to match the IRP definition. The Pronto from Decode option makes hex that is free from itty-bitty capture variations, but you should verify that the signal truly complies with the decode, since this method could either correct or distort the signal.
Hint: To make presentation worthy waveforms, export the pronto hex using the Pronto from Decode export mode. Then open the ExportedPronto.txt file in notepad. Copy the pronto hex for the signal from notepad and paste the data into IRScope’s Import window. This will make beautiful waveforms that use IRP timing data and don’t show any of the timing variations introduced during play and capture.

[[Image:irscope18.jpg]] 
'''Figure 18. Partial ExportedLintronic.txt'''

Legacy Formats

IRScope can produce two other output only formats, Audio (.wav) files and TV-B-Gone (tvbg.c) files. These formats were available in the original IRScope, but support for these formats has not evolved as the enhancements were made to IRScope. These legacy formats are only available in AutoSave mode on capture

==Tommy's Macro Example==
Solving problems with macros is much easier if you know exactly what is being transmitted and when. For an example I created a macro containing four commands on my URC6012 remote. I test fired it at the Widget to make sure I was getting multiple LED flashes, and based on that, I set the Capture Duration for 4000 mS. I also dropped down the Advanced menu and set the Thumbnail Scale to Entire Waveform.

[[Image:irscope19.jpg]] 
'''Figure 19. Example of Macro Waveform Display'''

Figure 19 shows the captured waveform display, and Figure 20 shows how IRScope has decoded the macro as four separate signals, as if you had pressed those four buttons individually. Each signal has a different carrier frequency, so the waveform display shows it as <freq varies>. The thumbnail shows the entire 4 seconds Capture Duration and, although you can't make out much detail, you can clearly see that it contains four signals. The main waveform display is only large enough to show the three frames of the first signal, which is only about 3% of the entire macro.

[[Image:irscope20.jpg]] 
'''Figure 20. Example of Decoded Macro'''

There are several ways to get a better look at the overall picture: You can zoom out, you can scroll through it, you can use the waveform selection tool, or you can use a combination of these. Zooming out is a good way to see the time delays between macro commands. Figure 21 shows the macro zoomed out to 590 μS per pixel.

[[Image:irscope21.jpg]] 
'''Figure 21. Example of Figure 19 After Zooming Out to 590 μS Per Pixel'''

Why did I select 590 μS per pixel? Note that in Figure 21 the last full line we can see starts at 135740 μS. So if we want to compress (zoom out on) the entire 4000 mS recording so it appears in that same space, we need to multiply the default resolution by 4000000 μS /135740 μS, or 29.5. So I double-clicked on the waveform display and changed the resolution from 20 microseconds per pixel to (29.5 x 20) = 590 microseconds per pixel.
At this scale you can easily see the time delay between the four commands, shown as 1,057,830, 1,061,373, and 1,057,737 μS. (To be scientifically correct, you should express these and all other IRScope measurements to only three significant figures, such as 1.06 seconds, in consideration of the limit of their accuracy.) Other types of remotes might repeat the signals a different number of times, or separate the commands by more or less time, because macro specifications are not chiseled in stone. One reason people like to use Extenders is that they often reduce the delay between commands to speed up macro execution.
If you are working with a large screen monitor and you really want to see this macro as one gigantic picture, here's the way to do it. After stretching the width and height of the window until it completely filled my screen, I noted that the bottom line started at 462000 μS. Dividing the overall macro Capture Duration, 4000000, by 462000 and multiplying by 20 μS per pixel gives 173 μS per pixel as my new resolution.

[[Image:irscope22.jpg]] 
'''Figure 22. Macro of Figure 21 Expanded and Zoomed to Fill the Screen'''

Figure 22 shows the entire waveform display at this resolution, although the page is not really large enough to show it as well as it looks on a screen twice this size.
Another easy way to examine a macro is with the waveform selection tool. Even though there is only one waveform display, selecting a signal for viewing is done the same way as with individual recordings. Just click on one of the four lines in the decode area and the macro waveform display will instantly scroll to that signal and highlight it in red.
You will find that the measurement of carrier frequency and timing may not be quite as accurate when working with a macro. However, these errors are still well within the acceptable range of operation for the infrared receivers used in consumer devices. If you want more accurate measurements for one of the signals, capture a sample of that signal alone.

==Vicky's Protocol Example==
IRScope is a great companion for Protocol Builder (PB). PB is a Microsoft Excel spreadsheet that can create executors to handle oddball signals for our JP1 remotes. Getting the remote to produce the desired signal can be a challenge. IRScope’s waveform takes the guesswork out of the process since visual comparisons can ensure that the executor’s signal matches the OEM signal.
IRScope is a great tool for debugging user upgrade problems too. Sometimes the user does everything right and the dang thing still won’t operate the equipment. Sometimes you actually need to see the signals to diagnose a problem.
DecodeIR, IRScope’s decoding module, does some magical mathematical gymnastics to identify the various signals. Usually an unknown signal is identified as a Gap protocol or Unknown protocol. Occasionally the signal follows enough of the protocols rules to be misidentified.
In my example, the OEM learns work, but the NEC2 upgrade, made from the decodes, did not work. All of the user’s files looked okay. I transferred the user’s learn to my remote, and captured the signal. I then loaded the upgrade into my remote, and captured the signal. On the surface everything looks good, but the user had reported that the signals don’t work.

[[Image:irscope23.jpg]] 
'''Figure 23: OEM Signal works, NEC2 Upgrade does not'''

Looking at the Decode Grid you see that the device, subdevice and OBC all match. You might notice the small difference in frequency, but that is insignificant. Most devices tolerate frequency differences of +1000 or -1000 or more without any issue, so the tiny frequency difference shown in fig.23, is not the cause of our problems.
My first order of business is to make sure that I have my thumbnail scale to Fixed Resolution. This will set the thumbnail scale to be equal on all signals, regardless of the sample size. Both Limited Duration and Entire Waveform Thumbnails use arbitrary time lines and so thumbnails of different durations cause the thumbnails to be distorted so they can’t be easily compared.

[[Image:irscope24.jpg]] 
'''Figure 24. Limited Duration and Fixed Duration thumbnails.'''

In Figure 24, the Limited Duration makes the signals look more alike than they really are. The Fixed Resolution shows the signals on the same time scale.
IRScope’s thumbnail comparisons can quickly point out problems. Certain signal problems have different characteristics. For instance, if the lead out time (the time between first frame and the second frame) is too long or too short, it can cause the repeat frames to be treated as new key presses, so a press of “1” might show up as “11”. In this user’s situation, the signals don’t didn’t work at all. When upgrade signals work, the thumbnails look like the thumbnails from the OEM signal. Remember, an IR signal is a timed light pattern, the timing is important. If you look at the Fixed Resolution thumbnails in fig. 24, you can easily see that the timings of the two samples are very different.
Most equipment is pretty forgiving when it comes to small variations in pulse times, but no equipment is going to recognize signals that are this far off. We’re going to need a custom protocol here.

If the thumbnails had not made the problem so evident, I would have looked for more subtle timing problems by comparing the detail portion of the waveform. The OEM signal waveform, Figure 25, shows a typical variance in the pulse timings. We need to do some rounding here to get numbers we can work with. Generally timings with values within 50uS are considered to be equal.
When building a protocol executor in Protocol Builder (PB), I would use the rounded timings from the waveform to create an executor. I would use the following values to create the OEM signal shown in fig.25. 
Lead-In Pair= + 8500, -4250 
Zero = +500, -1250 
One = +500, -3000 

[[Image:irscope25.jpg]] 
'''Figure 25. OEM Signal'''

The official NEC2 IRP shows times in multiples of 564.
Nec2 IRP notation: {38.4k,564}<1,-1|1,-3>(16,-8,D:8,S:8,F:8,~F:8,1,-78)+
Our IRP for the OEM signal, will be show times in a multiples of 500.
If you are comfortable with IRP, you could do the computation and see how different these signals timings are.
<table>
<tr>
<td>
Official Nec2 
Lead in Pair =+8824, -4412 
Zero =+564, -564 
One= +564, -1692 
IRP{38.4k,564}<1,-1|1,-3>(16,-8,D:8,S:8,F:8,~F:8,1,-78)+ 
</td>
<td>
The OEM signal (fig.25) 
Lead-In Pair=+ 8500, -4250 
Zero= +500, -1250 
One =+ 500, -3000 
IRP: {38.4k,500}<1,-2.5|1,-6>(17,-8.5,D:8,S:8,F:8,~F:8,1,-67)+ 
</td>
</tr>
</table>
[[Image:irscope26.jpg]] 
'''Figure 26, shows the pulse times when an upgrade is using the NEC2 executor.'''

For figure 26, I would round the timings to: 
Lead in Pair =+8800, -4400 
Zero =+550, -550 
One= +550, -1650 
Compared side by side, you can see that the NEC2 signal from the upgrade complies with the official

 NEC2 IRP. 

<table>
<tr>
<td>
Official Nec2 times 
Lead in Pair =+8824, -4412 
Zero =+564, -564 
One= +564, -1692 
IRP{38.4k,564}<1,-1|1,-3>(16,-8,D:8,S:8,F:8,~F:8,1,-78)+ 
</td>
<td>
The Nec Upgrade signal fig(26) 
Lead in Pair =+8800, -4400 
Zero =+550, -550 
One= +550, -1650 
IRP{38.4k,550}<1,-1|1,-3>(16,-8,D:8,S:8,F:8,~F:8,1,-78)+ 
</td>
</tr>
</table>
[[Image:irscope26.jpg]] 
'''Figure 26. NEC2 Upgrade Signal'''

If you are not familiar with IRP, you could just compare the rounded timing values from both the OEM signal’s waveform in Figure 25, and the NEC2 upgrade signal in Figure 26.
Compared side by side, you can see how much different the timings are.
<table>
<tr>
<td>
The Nec2 Upgrade signals (fig.26) 
Lead in Pair =+8800, -4400 
Zero =+550, -550 
One= +550, -1650 
</td>
<td>
The OEM signal (fig.25) 
Lead-In Pair=+ 8500, -4250 
Zero= +500, -1250 
One =+ 500, -3000 
</td>
</tr>
</table>

Apparently the OEM signal followed enough of the Nec2 protocol rules to fool decodeIR, but it is not nearly close enough to operate the equipment. The upgrade can’t use the NEC2 protocol. Instead a custom protocol executor would be written. An executor to send a signal like this, with such simple formatting rules, can be easily created by filling in the fields in a Protocol Builder spreadsheet. No additional assembly language programming would be necessary.
After building the executor, I test the executor by shooting the signals at the Widget. Then I adjust settings as necessary to get the details as close to the OEM signals as possible. This assures that the equipment will respond reliably to upgrades created with the new executor.
To learn more about IRP I recommend reading the Infrared Protocol Primer.

==Troubleshooting==
'''Why doesn’t my IRScope Window have a decode grid?''' 
You may have disabled decodeIR. In the Advanced menu, uncheck Disable DecodeIR. 

'''Why am I getting a file creation error when saving or exporting?''' 
Make sure that the Set Save Folder and the Set Export Folder in the File menu have been set to valid directories and that you are not trying to store them directly in the root directory. 

'''When trying to launch IRScope I get a message “Could not open File”.''' 
IRScope only allows one session to run at a time. This message usually indicates IRScope is already running in another window. If that does not seem to be the case, confirm that by checking the
Applications Tab of the Windows Task Manger. 

'''Why can’t I export Pronto Hex when in “Pronto from decode” mode?''' 
The Pronto from decode mode only uses known protocols. If an unknown protocol is selected nothing will be exported, try the Pronto from timings mode instead.

'''I started IRScope, but I can’t find it.''' 
Many settings are preserved between sessions using registry settings. Screen location is one of those settings. Use Windows Task Manager to switch to IRScope and then check the perimeters of the screen to see if you have moved IRScope to the edge and drag it back where you want it. 

IRScope stores its registry settings in HKEY_CURRENT_USER/Software/UEIC/IRScope/Settings 

'''COMMENTS AND SUGGESTIONS:''' Suggestions for additions or corrections to these instructions are
welcomed and should be posted to the forum.

IR Scope and IR Widget User's Guide

2025-11-23T00:13:28Z

The Robman:

A PDF form of this topic can be found here[https://www.hifi-remote.com/forums/dload.php?action=file&file_id=9696],

''Documentation written by Vicky, Tommy Tyler and Graham Dixon''

==Introduction==
[[Image:irscope0.jpg]] 
The IR Widget is a tool for recording signals transmitted from infrared remote controls. Its small optical detector probe is placed a few inches in front of a remote to capture the output signal. The Widget works by counting individual pulses of the remote's infrared LED. It measures carrier frequency and ON/OFF times of carrier bursts with very good accuracy. A Widget has the capacity to capture and display an almost unlimited number of records 1/2 second to 15 seconds in length.

IRScope is the software that collects and displays the data from the Widget. IRScope provides a graphic display, similar to that of a digital storage oscilloscope, showing precise timing details of the signal. IRScope’s built-in decoder provides a complete descriptive analysis if the signal pattern is recognized. Graphic displays are drawn to exact scale, and can be zoomed, stretched, dragged, scrolled, and saved.
IRScope and an IR Widget are great tools for studying infrared signals. The IR Widget and IRScope were designed by Kevin Timmerman. Tommy Tyler enhanced the design and sells them. You can find Tommy Tyler's Store in the market place in the JP1 site. Graham Dixon (mathdon) took over development of IRScope and made some exciting enhancements that make the software a fantastic tool for anyone studying signals, even if they have not purchased a Widget.

There are many ways to capture a signal for analysis. For instance, a JP1 user with a learning remote and interface cable, can capture signals with the remote and read them in via IR or RMIR. Many people find that procedure cumbersome. With a Widget, you can avoid the frustration of collecting learns in batches, the hassle of botched learns, and the confusion of figuring out what you put where.
A Widget can learn virtually all signals. Some signals are too complicated to be analyzed and stored by a JP1 remote, but a Widget doesn’t have these shortcomings.

The Widget is an economical solution. It is a bargain when compared to other oscilloscope solutions. The Widget can be less expensive than purchasing a learning remote with a cable for data collection too.
The Widget is an IR collection tool; it doesn’t function as a remote. That is the one place where the JP1 remote with interface cable does have a huge advantage. You can use the learning remote to record the signals, and have a pretty cool remote that you can program with your PC using the JP1 tools. For a serious enthusiast, I’d recommend having both the Widget and a learning remote with cable interface!

IRScope’s oscilloscope type representation of the infrared signal’s timing data can be very helpful when learning about infrared protocols. IRScope can acquire timing data from several different sources. This makes the software helpful even without a Widget. The signal can be captured by the Widget or the signals can be imported from UEI (JP1) remote type learns, Pronto type learns or raw timing data. IRScope provides a large variety of output. Signal information can be saved in IRScope’s .ict (Infrared Capture Text) files; the information can be exported as UEI learns, Pronto learns, Lintronic forms; and detailed Summary reports.
2
IRScope’s creates and reads .ict (Infrared Capture Text). Originally these files only recorded a single capture. Two of the new features that Graham has added, (allowing notes and saving multiple signals from several capture sessions in a single ict file), make ICT files a convenient way of documenting and organizing signal information. An ICT file holds all the timing data and any notes entered while collecting signals. The decode data is not saved in the ICT file; the signal is decoded each time the ICT file is opened. This method allows ICT decodes to be improved when new versions of decodeIR.dll become available. DecodeIR.dll is the decoder used with all the JP1 tools such as IR, RMIR, DecodeCCF and IRTool.

IRScope is a powerful diagnostic tool. It is always nice to be able to see what is coming out of the remote. The waveform allows you to visually compare signals to see if the OEM and upgrade signals match. It is very useful in diagnosing macro problems, such as duration problems or programming errors. IRScope can also be useful in diagnosing a wide variety of upgrade issues.

==Software Installation==
The IRScope software bundle contains everything except the Widget’s USB driver. IRScope can be downloaded from the '''File Section>Tools>Main''' in the JP1 forum.

The bundle includes:
#IRScope.exe
#DecodeIR.dll
#Features of IRScope version. xxx .pdf. a document that describes the new features
#DecodeIR.html a document that gives specifications for various protocols.
#MakeHex.dll
#ExchangeIR.dll

Unzip the download and place all six files in the same folder.

IRScope requires version DecodeIR.dll v2.39 (or later) that is supplied in the download package.
Many of the JP1 tools use DecodeIR.dll, so you may have older versions on your PC. If you store your decodeIR.dll in a centralized Windows System folder so that the applications share the same dll, make sure that your system is using decodeIR.dll version 2.39 or later.

==IR Widget Driver Installation==
The Widget’s driver is not bundled with IRScope, the driver is downloaded separately.

The Widget requires version 2.04.06 (or later) of the FTDI USB driver. You can download version 2.06.00 from: http://www.ftdichip.com/Drivers/VCP.htm. If you have an older version in your PC (perhaps from using a USB JP1.2/3 (Flash) Interface) you must first uninstall it. You'll need a utility called CDMUninstallerGUI, which you can download from: http://www.ftdichip.com/Resources/Utilities.htm. The download includes a brief readme.html that explains how to use the uninstaller.

The first time you plug in a Widget after uninstalling old drivers, Windows' New Hardware Wizard will prompt you through new driver installation in two phases. First it installs a driver for the USB Serial Converter function of the Widget. Following that, it installs a driver for the USB Serial Port function of the Widget.
To verify that your driver installation is successful, open Device Manager and expand both the Ports (COM & LPT) list and the Universal Serial Bus controllers list. When you plug in the Widget, a new entry called USB Serial Port (COMx) will appear at the end of the Ports list, and simultaneously a new entry called USB Serial Converter will appear at the end of the Universal Serial Bus controllers list, as shown in Figure 1 on the following page.

[[Image:irscope1.jpg]] 
'''Figure 1. Device Manager Showing Typical Widget Device Recognition'''

IRScope should be able to Autodetect this port, but on some systems Autodetect does not work, and you may need to manually enter that COM port number in the Port field in IRScope’s main window.

==Exploring the Main Screen==
[[Image:irscope2.jpg]] 
'''Figure 2. Default Main Window'''

Capturing a Signal
To capture a signal with your Widget, you will need to make sure the Port, Capture Duration and Hardware and Mode settings are set and then press the Capture button.
Port
A grayed-out Port box indicates that you cannot drop down the list of COM ports because IRScope has already found the correct USB port. However, if the Port number were enabled, as in Figure 2, it could mean that the AutoLocate feature is not working. In the Advanced menu make sure there is a check mark in front of AutoLocate Widget. Try closing and relaunching the program. If it still doesn’t automatically locate, manually find the COM port number in the device manger as you did when you verified your Widget driver installation. Type that COM number in the port field in IRScope’s main window.
Capture Duration
Shows the total length of a recording in milliseconds, starting when the Widget detects the beginning of a signal from the remote. The entry in this box must be an integer value between 500 and 15000 (1/2 second to 15 seconds). The default value of 700 mS is fine for capturing individual buttons, but must be increased to capture a macro. You will have 5 seconds to start sending a signal, and as soon as the signal is detected, IRScope will record infrared activity for the specified capture duration.
Hardware and Mode
When working with a Widget, ALWAYS leave this set on IR Widget Count!
Capture Button
The Capture button prepares the system to collect data. When you are all setup and ready to record a signal, click on Capture, point your remote at the Widget’s probe and press a remote button. If you wait longer than 5 seconds before starting transmission, the capture will abort with an error message. The default configuration is for the program to output an audible beep when you press Capture and start the five second clock. If you don't like beeps, check the Suppress Beeps option in the Advanced menu.

SHOW WAVE FORM 
[[Image:irscope3a.jpg]] 
If the show waveform box was checked, a waveform window will appear when the capture is finished.

[[Image:irscope3.jpg]] 
'''Figure 3. Waveform Window'''

The waveform window is very useful in diagnosing problems, and creating custom protocols. The waveform in Figure 3 has been labeled to show what the various parts of a waveform represent. A brief description follows here. The Waveforms Explained section provides a more detailed description.
The top line of the waveform windows shows thumbnails. There are three options to control how the thumbnail line will be displayed. Under the Advanced menu, Thumbnail Scale you have the option of Fixed Resolution, Limited Duration and Entire Waveform. You should choose a Thumbnail Scale that best suits your activity.
The Frequency is in the upper corner. The frequency in Figure 3 is 39944hz. If a mixture of signals was captured, the frequency is not computed and instead < freq varies> is shown. Frequency is a measure of how many times the light flashed during the ON pulse time.
The waveform is completely scalable. If the timings are so close that the numbers are unreadable, you can click on the form and change the number of microseconds per pixel. You can also remove the pulse counts, those pulse times or the elapsed times.
The pulse times are the numbers below the line. You may be used to seeing pulse times with + and minus like +2400, -600, + 1200 –600 +600 when no waveform is available. The – was used to indicate the quite times, not to indicate a negative time.
If you don’t want to see the waveform on each capture uncheck the show waveform option. 6

[[Image:irscope4.jpg]] 
'''Figure 4. Decode Grid and Action on Items Selected box'''
Decode Grid
The decode grid shows a list of decodes for the recorded signals. The grid has 11 sizeable columns, #, Frequency, Protocol, Device, OBC, Hex, Note, Miss, Start, End and Error. Depending on how the columns have been sized, some columns may be hidden. The grid allows single or multiple signal selections. Double click on a selection to open and or highlight its waveform.
In Figure 4, the grid entries for the highlighted signal show:
# 2. This shows the position this signal holds in the grid and ict files.
Frequency 37423. This shows the relation ship of the pulse count to the pulse time.
Protocol This shows which set of formatting rules the signal follows, in this case Panasonic.
Device 128.0 indicates a device of 128, sub-device 0 (note a zero and a blank are not the same)
OBC this is the function part of the signal. That is the part that changes with each key press.
Note this information is input by the user.
Hex codes for the specific button. NEVER USE THIS hex to create an upgrade. The hex you need to enter in RemoteMaster’s (RM) hex column may not match this hex!
Misc describes the repetition characteristics of the signal and other miscellaneous information.
No Repeat means the signal consisted of only one full frame. +N copies means the signal consisted of N+1 full frames. +N dittos means the signal consisted of one full frame followed by N ditto frames. Ditto frames consist of only a starting and ending burst but no data portion. Dittos frames are used to indicate that a button is being held down.
Start and End the numbers in the columns refer to carrier ON bursts in a signal, and are used only by experts when debugging decoding errors.
Error column is not used.
Action on Items Selected Box
All the buttons in this box work on the lines selected in the Decode Grid.
Add/Edit Note allows a label to be entered on the selected grid line. Add/Edit Note is how the “pause” and “play” descriptions got into the Note column.
UP and DOWN moves the selected signals in the decode grid.
DELETE deletes the selected signals from the decode grid.
EXPORT writes timing information in UEI Learns, Pronto Learns or Lintronic timing formats to a text file. See the Export menu and in the IRScope’s Output formats sections for more detailed information.
SAVE AS saves the timing data for the selected signals in an ICT (Infrared Control Timing) file.

[[Image:irscope5.jpg]] 
'''FIGURE 5. Signal structures and IRP Form'''

Signal Structure
This gives general information about the selected signal.
IRP Form:
IRP notation is a way of describing the signal. The IRP Form displayed in IRScope is a generic IRP form. The portion shown as {A=} is a representation of the analyzed data portion of the signal. You can adjust the way A is displayed from the Advanced menu. If you want to understand the protocol rules, take a look at the official IRP for the protocol. To see the official IRP, select HELP and then select Interpreting Decoded IR Signals.
Generic IRP Form.
{37.4k,427,msb}<1,-1|1,-3>(8,-4,A:48,1,-73.5m)+{A=$400401008889}; Alt leadout form: ^127m
The official IRP for the Panasonic code looks like this.
{37k,432}<1,-1|1,-3>(8,-4,2:8,32:8,D:8,S:8,F:8,(D^S^F):8,1,-173)+
D is the device, S is the subdevice, and F is the OBC and the signal is lsb.

[[Image:irscope6.jpg]] 
'''FIGURE 6. Clear and Clear before capture'''

CLEAR
The clear button will immediately delete everything from the decode grid, to delete selected lines use the Delete in the Action on Items Selected area.
Clear before Capture
If this option is checked, the contents of the decode grid will be erased every time you capture a new signal.

[[Image:irscope7a.jpg]] 
SAVE ALL AS
Save All As, will save an ICT (Infrared Capture Text) file, that will includes all the signals in the decode grid. The Save As only saves the highlighted signals. ICT files that have a complete signal set are very a very convenient way to pass information.
VIEW
The view button allows you to open an ICT file and adds all the information into the decode grid.

[[Image:irscope7.jpg]] 
'''FIGURE 7. SUMMARY REPORT'''

SUMMARY
The summary button produces the report in figure 7. The DECODES portion of the report reproduces the decode grid from the main screen. This can be helpful if you need a hard copy to do your data entry in RM or KM. I like to copy and paste this data into a spreadsheet and manipulate it so that I don’t have to risk making data entry errors.
The RAW TIMINGS DATA and ANALYSED TIMING DATA portions can be useful if the signals couldn’t be decoded because they didn’t follow the rules for any known protocol.

[[Image:irscope8.jpg]] 
'''Figure 8, IRScope’s Import window'''

IMPORT
IRScope is also capable of importing signal in the form of Pronto Hex, Raw timing data and UEI learns. Select the import type; indicate the number of repeats to be displayed and paste the timing information into the area provided. 
Pronto Hex is a form of timing data that is used in high end Philips remotes. This is a convenient way to exchange information about IR signals. Many manufacturers post data in Pronto Hex format. Pronto users exchange information via pronto hex and in CCF files and PCF files containing their configurations. 
Pronto Hex looks like this. 
0000 006C 0032 0000 0080 003C 0010 000F 0010 000F 0010 002F 0010 000F 0010 002F 0010 000F 0010 000F 0010 000F 0010 002F 0010 002F 0010 000F 0010 000F 0010 000F 0010 002F 0010 002F 0010 000F 0010 000F 0010 000F 0010 000F 0010 000F 0010 000F 0010 000F 0010 000F 0010 000F 0010 000F 0010 000F 0010 002F 0010 000F 0010 000F 0010 000F 0010 000F 0010 002F 0010 000F 0010 000F 0010 002F 0010 002F 0010 000F 0010 000F 0010 000F 0010 002F 0010 000F 0010 002F 0010 000F 0010 000F 0010 002F 0010 000F 0010 000F 0010 000F 0010 34AC 
Raw Timing Data is another form of timing data often found. When using data you’ll need a frequency as well as the pulse times. If no frequency is available try 38000. 
+3414 -1686 +433 -421 +433 -1294 +406 -440 +433 -421 +433 -413 +433 -421 +433 -440 +406 -440 +433 -421 +433
-413 +433 -421 +433 -413 +433 -421 +433 -1294 +433 -413 +433 -421 +433 -413 +433 -421 +433 -440 +406 –440 +433 -421 +433 -413 +433 -421 +433 -1294 +406 -440 +433 -421 +433 -413 +433 -421 +433 -413 +433 -421 +433
-440 +406 -440 +433 -421 +433 -413 +433 -421 +433 -440 +406 -1294 +433 -421 +433 -413 +433 -421 +433 -413 +433 -421 +433 -440 +406 -440 +433 -1267 +433 -421 +433 -440 +406 -1294 +433 -73694
10 
UEI Learns 
The learns from a JP1 remote can be imported too. From IR or RMIR, edit the learned key and then copy the data portion of the learned command, and then paste it into the Import window in IRScope.

[[Image:irscope9.jpg]] 
'''Figure 9, Learned signal from IR'''

JP1 people are pretty familiar with this screen. IR is the main JP1 program for downloading information from our remotes. Similar functionality is available in RMIR, the java based version of IR. IRScope can format and export UEI learns or Pronto learns. That exported data can be used to add learns to a JP1 remote.

==Exploring the Menus==
File Menu
<table width="592" border="1">
<tr>
<td bgcolor="#CCCCCC" width="183" >Capture </td>
<td width="393">Capture is the same as the Capture button on screen

 </td>
</tr>
<tr>
<td bgcolor="#CCCCCC" width="183" >Open </td>
<td width="393">Open is same as the View button on screen</td>
</tr>
<tr>

<td bgcolor="#CCCCCC" width="183" >Import</td>
<td width="393">Import is same as Import button on screen.</td>
</tr>
<tr>

<td bgcolor="#CCCCCC" width="183" >Summary</td>
<td width="393">Creates as timing summary report, same as the summary button on screen</td>
</tr>
<tr>

<td bgcolor="#CCCCCC" width="183" >Save Last Signal</td>
<td width="393">Saves the last signal captured with auto number naming.</td>
</tr>
<tr>

<td bgcolor="#CCCCCC" width="183" > Save Last Signal As</td>
<td width="393">Saves the last signal captured but asks for a filename.</td>
</tr>
<tr>

<td bgcolor="#CCCCCC" width="183" >Save Selected As</td>
<td width="393">Saves the information for the signals selected in the decode grid.</td>
</tr>
<tr>

<td bgcolor="#CCCCCC" width="183" >Save All as</td>
<td width="393">Saves all the signals in the decode grid</td>
</tr>
<tr>

<td bgcolor="#CCCCCC" width="183" >Set Folder > 
Set Save Folder</td>
<td width="393">Use this option to set the folder where the ict files are to be saved.</td>
</tr>
<tr>

<td bgcolor="#CCCCCC" width="183" > Set Export Output Folder</td>
<td width="393">This is the folder where exported files will be saved. If this option is grayed out, the Advanced menu’s Use Common Folder has been set and exported files will be written to the Save folder specified above.</td>
</tr>
<tr>

<td bgcolor="#CCCCCC" width="183" > Set IRP Folder</td>

<td width="393">IRP files are only needed to export Pronto hex in the Export Proto like decode mode. You don’t need these files to export Pronto hex from timings. These IRP definitions can be downloaded from the JP1 file section. Use this option to locate the folder where the IRP definition files are stored.</td>
</tr>
<tr>

<td bgcolor="#CCCCCC" width="183" >Clear Recent
1 filename 
2 filename 
3 filename</td>

<td width="393">Clears the list of the last files accessed. 
IRScope saves the last 6 files accessed.</td>

</tr>
<tr>

<td bgcolor="#CCCCCC" width="183" >Exit</td>
<td width="393">Quits the program and closes all waveform windows.</td>
</tr>
</table>

.
Edit menu
<table width="592" border="1">
<tr>
<td bgcolor="#CCCCCC" width="183" >Select All Ctrl+A</td>

<td width="393">Selects all the signals from the decode grid.</td>
</tr>
<tr>

<td bgcolor="#CCCCCC" width="183" >Deselect All Ctrl+D</td>

<td width="393">Deselect all the signals from the decode grid.</td>
</tr>
<tr>

<td bgcolor="#CCCCCC" width="183" >Clear All</td>

<td width="393">Deletes all the signals from the decode grid.</td>
</tr>
<tr>

<td bgcolor="#CCCCCC" width="183" >Add Note to Selected Ctrl+N</td>

<td width="393">This allows you to label each signal in the decode grid. This is an important feature when you are collecting a set of signals. These notes are used in the summary reports and in the export reports.</td>
</tr>
<tr>

<td bgcolor="#CCCCCC" width="183" >Move Selected Up Ctrl+Up</td>

<td width="393">Moves the selected items in the decode grid up.</td>

</tr>
<tr>
<td bgcolor="#CCCCCC" width="183" >Move Selected Down Ctrl+Dn</td>

<td width="393">Moves the selected items in the decode grid down.</td>
</tr>
<tr>

<td bgcolor="#CCCCCC" width="183" >Delete Selected Del</td>
<td width="393">Deletes the selected items from the decode grid.</td>
</tr>
</table>

Export Menu
<table width="592" border="1">
<tr>
<td bgcolor="#CCCCCC" width="183" >Export Last Signal</td>
<td width="393">Creates or appends to a file with the name ExportedUEI, ExportedPronto or ExportedLintronic.txt depending on the current Export Mode. The file will be created in the file Export Output Folder or the Common Save Folder. Exports the last signal captured in the mode selected.</td>
</tr>
<tr>

<td bgcolor="#CCCCCC" width="183" >Export Selected Ctrl+E</td>
<td width="393">Same as above, only this will export the signals selected in the decode grid.</td>
</tr>
<tr>

<td bgcolor="#CCCCCC" width="183" >Export Mode</td>
<td width="393"> </td>
</tr>
<tr>

<td bgcolor="#CCCCCC" width="183" > UEI Learned</td>
<td width="393">Use this option to create or append to a file named ExportedUEI.txt. The individual learns can be pasted into an ir file and uploaded into a learning remote.</td>
</tr>
<tr>

<td bgcolor="#CCCCCC" width="183" >Pronto from signal</td>
<td width="393">Use this to create or append to a file named ExportedPronto.txt file based on the actual timings.</td>
</tr>
<tr>

<td bgcolor="#CCCCCC" width="183" >Pronto from decode</td>
<td width="393">This file will create or append to a file named ExportedPronto.txt file based on the protocols rules. To use this option you need to download the IRP files required for MakeHex and set the IRP folder. Use this option to create proto hex suitable for presentations.</td>

</tr>
<tr>

<td bgcolor="#CCCCCC" width="183" >Lintronic</td>
<td width="393">This file will appends to or creates an ExportedLincronic.txt file based on the actual timings.</td>
</tr>
</table>

Advanced Menu

<table width="592" border="1">
<tr>
<td bgcolor="#CCCCCC" width="183" >AutosSave Types > </td>
<td width="393">AutoSave saves every Widget capture automatically. New features in the software allow better options for saving signals. Saving a set is a better practice than using autosave.</td>

</tr>
<tr>

<td bgcolor="#CCCCCC" width="183" >IR Capture Text (.ict)</td>
<td width="393">Infrared Capture txt is one of the options for autosave. These are the IRScope files that can be reopened.</td>

</tr>
<tr>

<td bgcolor="#CCCCCC" width="183" >Audio(.wav)</td>
<td width="393">This legacy format is only available in AutoSave mode from initial captures.</td>

</tr>
<tr>

<td bgcolor="#CCCCCC" width="183" >TV-B-Gone (tvbg.c)</td>
<td width="393">This legacy format is only available in AutoSave mode from initial captures.</td>

</tr>
<tr>

<td bgcolor="#CCCCCC" width="183" >AutoSave Mode</td>
<td width="393"> </td>
</tr>
<tr>

<td bgcolor="#CCCCCC" width="183" >Auto Filename</td>
<td width="393">This option automatically generates a filename for the ict files. The default filename is consists of the letters IR followed by a 14-character date/time code in the format: [year] [month] [day] [hour] [minute] [second]. For example, IR20091212162102.ict</td>
</tr>
<tr>

<td bgcolor="#CCCCCC" width="183" >Prompt for Filename</td>
<td width="393">This option automatically saves every capture, but pauses to allow entry of a meaningful name for each ict file.</td>
</tr>
<tr>

<td bgcolor="#CCCCCC" width="183" >AutoLocate Widget</td>
<td width="393">This feature automatically finds which Com Port is assigned to the Widget.</td>
</tr>
<tr>

<td bgcolor="#CCCCCC" width="183" >Suppress Beeps</td>
<td width="393">IRScope beeps when it is ready to start the capture unless the option is checked.</td>
</tr>
<tr>

<td bgcolor="#CCCCCC" width="183" >Hide Save-Panel </td>

<td width="393">[[Image:irscope10a.jpg]]
This option hides the Save panel. This panel duplicates the AutoSave Types and AutoSave Mode menu selections described above.</td>
</tr>
<tr>

<td bgcolor="#CCCCCC" width="183" > Thumbnail Scale</td>
<td width="393">The options below control the way the thumbnails appear in the waveform window.</td>
</tr>
<tr>

<td bgcolor="#CCCCCC" width="183" > Fixed Resolution</td>
<td width="393">Fixed resolution always depicts the thumbnail on a 500ms scale.</td>
</tr>
<tr>

<td bgcolor="#CCCCCC" width="183" > Limited Duration</td>
<td width="393">Limited duration uses a variable scale that depicts the capture or the selected signal.</td>
</tr>
<tr>

<td bgcolor="#CCCCCC" width="183" > Entire Waveform</td>
<td width="393">Represents the entire capture time</td>
</tr>
<tr>

<td bgcolor="#CCCCCC" width="183" > Select on Capture</td>
<td width="393">This option causes the capture to be automatically selected in the decode grid after it is captured. This allows for speedier data entry on the notes field. Turn this option off to manually control which decode grid item is selected.</td>
</tr>
<tr>

<td bgcolor="#CCCCCC" width="183" > Common Output Folder</td>
<td width="393">This features automatically saves Export files in the same folder as the Save Output folder. This option helps users working on multiple projects to keep their work organized.</td>
</tr>
<tr>

<td bgcolor="#CCCCCC" width="183" > IRP Data Format</td>
<td width="393">This option specifies for how the portion of the IRP form that represents the data {A=} will be displayed. In my example A is 32 bits of data. 
Sample IRP form: 
{39.0k,243,msb}<2,-5|2,-12>(35,-4262u,A:32,2,-33.5m)
+{A=$00D4C936}
Binary (base2 prefix 0b) 
{A=0b00000000110101001100100100110110} 
Quaternary (base 4, prefix0q) 
{A=0q0000311030210312} 
Hex (base 16 prefix 0x) 
{A=0x00D4C936} 
Hex (base 16, prefix $) 
{A=$00D4C936} </td>
</tr>
<tr>

<td bgcolor="#CCCCCC" width="183" > Disable Decoder</td>
<td width="393">This disables the decoder and makes the decode grid disappear from the main screen. If you decode grid goes missing check this setting.</td>
</tr>
</table>
Help
<table width="592" border="1">
<tr>
<td bgcolor="#CCCCCC" width="183" >Interpreting IR Decodes</td>
<td width="393">This option opens DecodeIR.HTM in your internet browser. DecodeIR, gives the information about the protocol rules used to decode the signals.</td>
</tr>
<tr>

<td bgcolor="#CCCCCC" width="183" >About</td>
<td width="393">Displays the licensing and copyright information for IRScope. Note that on the software version numbers are not buried in the About box, they are already clearly displayed in the title bar of the main IRScope window.</td>
</tr>
</table>

==Exploring the Waveform==
[[Image:irscope3.jpg]] 
'''Figure 10. Waveform Explained'''

The waveform window is very useful in diagnosing problems and creating custom protocols. The waveform in Figure 10 has been labeled to show what the various parts of a waveform represent.
The waveform can be seen on capture; when you Open or View an ict file; or when you double click on a signal from the decode grid. When double clicking the decode grid, the portion of the waveform that represents the selected decodes will be highlighted in red.
The Frequency is in the upper corner. In Fig.10, the frequency is 39944hz. If a mixture of signals was captured, the frequency is not computed and instead < freq varies> is shown. Frequency is a measure of how many times the light flickered during an ON pulse time period.
The pulse times are the numbers below the line. You may be used to seeing pulse times with + and minus like +2400, -600, + 1200 –600 +600 when no waveform is available. The – was used to indicate the quite times, not to indicate a negative time.
Thumbnails The top line of the waveform windows shows thumbnails. There are three options to control how the thumbnail line will be displayed. Under the Advanced menu, Thumbnail Scale you have the option of Fixed Resolution, Limited Duration and Entire Waveform. Choose a thumbnail scale that suits your activity.
Fixed Resolution When the thumbnail scale is set to fixed resolution, the thumbnail will always represent 500mS. Fixed resolution is your best choice when comparing signals in different waveform windows.
Limited Duration When the thumbnail scale is set to limited duration, the thumbnail will be scaled to show the entire capture dropping any quiet time at the end of the signal. The thumbnail will shrink or expand depending on how long the infrared activity lasted.

Entire Waveform When the thumbnail scale is set to entire waveform, the thumbnail will represent the capture duration including any quite time at the end.
Figure 11 shows the same capture showing in all three thumbnail scales. The capture duration was 1500ms, the infrared activity lasted only far less than the 500ms in the fixed.

[[Image:irscope11.jpg]] 
'''Figure 11. Thumbnail Scales'''

Scalability. Another one of IRScope’s powerful features is the ability to change the resolution of the waveform. Not all signals will display well at the default 20 microseconds per pixel resolution. You can easily change this resolution to make the display more readable. You can also remove the pulse counts, pulse times and the elapsed time numbers from the display.

[[Image:irscope12.jpg]] 
'''Figure 12. IRScope Config Dialog Box'''

Figure 12 shows the scale of the timing chart as presently displayed. The default resolution is 20 microseconds per pixel. The microseconds per pixel can be set anywhere from 1 to 2000. Click OK, and the display instantly shrinks or expands to the new scale.

[[Image:irscope13.jpg]] 
'''Figure 13. Example of Waveforms Zoomed Out 5X'''

Figure 13 shows a simple example where the zooming feature has been used. The waveform displays of signals for buttons "1", "2", and "3" of an RCA remote have each been zoomed out to a resolution of 100 μS per pixel, then the windows were overlayed and lined up for comparison. Can you spot the subtle differences in timing between the three display patterns? Since all the carrier ON times are of uniform duration, and there are two sizes of OFF times, it's obvious this protocol encodes "1" and "0" bits by the amount of OFF time between carrier bursts.
The "1 button" example in Figure 13 typifies the appearance you get when you just zoom out on a signal. The numbers showing ON and OFF times etc. are still there, but they overlap too much to be readable except for some of the larger ON and OFF times. The three check boxes in the IRScope Config dialog box enable you to turn off one or more of these measurements when you want to see a cleaner picture. To illustrate the effect, I unchecked all three boxes when zooming out on the "2 button" and "3 button" waveforms. Zooming in and out is fast, but if you prefer you can also open more than one copy of the same waveform and zoom them out to different scales for simultaneous viewing while studying a signal.
When zooming, neither the size of the window nor the scale of the thumbnail display is changed. Only the scale of the waveform is expanded or contracted to show more or less detail. You can also stretch the overall width of a waveform display window to the full width of your screen, but that won't change the amount of detail shown. For an experiment, try stretching a display until the lines start at 0, 20000, 40000, 60000, etc. By doing this you have adjusted the display so that its width is exactly 20,000 μS, or 20 mS, a nice round number for estimating or measuring the position of various features.

==IRScope's Output==
IRScope has a lot of output formats. The formats are ICT files, Summary Reports, ExportedUEI.txt, ExportedPronto.txt, and ExportedLintronix.txt files. There are also two old legacy formats, audio.(wav) and TV-B-Gone (tvbg.c).
ICT Infrared Capture Text
IRScope's primary file format is the ICT file. ICT files are the only type of files used for both input and output in IRScope. ICT files can be created with the Save As, Save All As buttons and with the Save Last, Save Last As, Save Selected and Save Selected As items on the File Menu. The files will be stored in the folder specified in with the Set Output Save Folder option in the File Menu. Any option that included “As” will prompt for a filename. The other save methods will use automatic file naming form, (IRyyyymmddhhmmss.ict).
ICT files can be opened with the View button from the screen, or with the Open command on the File menu.
Saved files are in text format, and have an extension of .ict. Figure 14 shows the initial portion of a typical .ict file.

[[Image:irscope14.jpg]] 
'''Figure 14. Portions of a Sample.ict File'''

In Figure 14, the numbers correspond to the timing numbers that appeared in the waveform.
A number preceded by a "+" symbol is the ON time in microseconds for a carrier burst, and the number following a comma is the number of carrier cycles that make up that burst. A number proceeded by a "-" symbol is the OFF time in microseconds between carrier bursts. As you can see, there is enough data in the .ict file to completely reproduce a graphic display. Decode data is not part of a saved file. When a saved file is recalled, the decoder reprocesses the data to decode it.
Any notes that were manually entered in the decode grid are also stored in the ict file. When the ict file is opened or viewed the note and decode will be added to the decode grid.

Summary file
The summary file is an rtf (rich text format). This is an output only file. This report is created by pressing the Summary button on the screen, or selecting Summary from the File menu.

[[Image:irscope7.jpg]] 
'''Figure 15. Summary Report'''

Exported files
IRScope can also export timing data in UEI format, Pronto Format, and Lintronic Format. These files are for output only. Each format type has its own predefined filename ExportedUEI.txt, ExportedPronto.txt, and ExportedLintronics.txt. These files will be automatically located in the folder specified for Set Export Output Folder, or if the Common Output Folder option is set on the Advanced menu, these will be located in the Set Save Output Folder. If the filename already exists, the signals will be appended to the existing file. To export, select signals in the decode grid and press the Export button on the screen. The format to be exported is controlled by the Export Mode option on the Export menu.

Figures 16, 17 and 18 are examples of what the exported output looks like when viewed in notepad

[[Image:irscope16.jpg]] 
'''Figure 16. ExportedUEI.txt'''

[[Image:irscope17.jpg]] 
'''Figure 17. Sample ExportedPronto.txt'''

The hex in the ExportedPronto files could have been created either from the raw timing data, or from the decode. The difference is that in Pronto from decode mode, the timings will be adjusted to match the IRP definition. The Pronto from Decode option makes hex that is free from itty-bitty capture variations, but you should verify that the signal truly complies with the decode, since this method could either correct or distort the signal.
Hint: To make presentation worthy waveforms, export the pronto hex using the Pronto from Decode export mode. Then open the ExportedPronto.txt file in notepad. Copy the pronto hex for the signal from notepad and paste the data into IRScope’s Import window. This will make beautiful waveforms that use IRP timing data and don’t show any of the timing variations introduced during play and capture.

[[Image:irscope18.jpg]] 
'''Figure 18. Partial ExportedLintronic.txt'''

Legacy Formats

IRScope can produce two other output only formats, Audio (.wav) files and TV-B-Gone (tvbg.c) files. These formats were available in the original IRScope, but support for these formats has not evolved as the enhancements were made to IRScope. These legacy formats are only available in AutoSave mode on capture

==TOMMY’S MACRO EXAMPLE==
Solving problems with macros is much easier if you know exactly what is being transmitted and when. For an example I created a macro containing four commands on my URC6012 remote. I test fired it at the Widget to make sure I was getting multiple LED flashes, and based on that, I set the Capture Duration for 4000 mS. I also dropped down the Advanced menu and set the Thumbnail Scale to Entire Waveform.

[[Image:irscope19.jpg]] 
'''Figure 19. Example of Macro Waveform Display'''

Figure 19 shows the captured waveform display, and Figure 20 shows how IRScope has decoded the macro as four separate signals, as if you had pressed those four buttons individually. Each signal has a different carrier frequency, so the waveform display shows it as <freq varies>. The thumbnail shows the entire 4 seconds Capture Duration and, although you can't make out much detail, you can clearly see that it contains four signals. The main waveform display is only large enough to show the three frames of the first signal, which is only about 3% of the entire macro.

[[Image:irscope20.jpg]] 
'''Figure 20. Example of Decoded Macro'''

There are several ways to get a better look at the overall picture: You can zoom out, you can scroll through it, you can use the waveform selection tool, or you can use a combination of these. Zooming out is a good way to see the time delays between macro commands. Figure 21 shows the macro zoomed out to 590 μS per pixel.

[[Image:irscope21.jpg]] 
'''Figure 21. Example of Figure 19 After Zooming Out to 590 μS Per Pixel'''

Why did I select 590 μS per pixel? Note that in Figure 21 the last full line we can see starts at 135740 μS. So if we want to compress (zoom out on) the entire 4000 mS recording so it appears in that same space, we need to multiply the default resolution by 4000000 μS /135740 μS, or 29.5. So I double-clicked on the waveform display and changed the resolution from 20 microseconds per pixel to (29.5 x 20) = 590 microseconds per pixel.
At this scale you can easily see the time delay between the four commands, shown as 1,057,830, 1,061,373, and 1,057,737 μS. (To be scientifically correct, you should express these and all other IRScope measurements to only three significant figures, such as 1.06 seconds, in consideration of the limit of their accuracy.) Other types of remotes might repeat the signals a different number of times, or separate the commands by more or less time, because macro specifications are not chiseled in stone. One reason people like to use Extenders is that they often reduce the delay between commands to speed up macro execution.
If you are working with a large screen monitor and you really want to see this macro as one gigantic picture, here's the way to do it. After stretching the width and height of the window until it completely filled my screen, I noted that the bottom line started at 462000 μS. Dividing the overall macro Capture Duration, 4000000, by 462000 and multiplying by 20 μS per pixel gives 173 μS per pixel as my new resolution.

[[Image:irscope22.jpg]] 
'''Figure 22. Macro of Figure 21 Expanded and Zoomed to Fill the Screen'''

Figure 22 shows the entire waveform display at this resolution, although the page is not really large enough to show it as well as it looks on a screen twice this size.
Another easy way to examine a macro is with the waveform selection tool. Even though there is only one waveform display, selecting a signal for viewing is done the same way as with individual recordings. Just click on one of the four lines in the decode area and the macro waveform display will instantly scroll to that signal and highlight it in red.
You will find that the measurement of carrier frequency and timing may not be quite as accurate when working with a macro. However, these errors are still well within the acceptable range of operation for the infrared receivers used in consumer devices. If you want more accurate measurements for one of the signals, capture a sample of that signal alone.

==Vicky's Protocol Example==
IRScope is a great companion for Protocol Builder (PB). PB is a Microsoft Excel spreadsheet that can create executors to handle oddball signals for our JP1 remotes. Getting the remote to produce the desired signal can be a challenge. IRScope’s waveform takes the guesswork out of the process since visual comparisons can ensure that the executor’s signal matches the OEM signal.
IRScope is a great tool for debugging user upgrade problems too. Sometimes the user does everything right and the dang thing still won’t operate the equipment. Sometimes you actually need to see the signals to diagnose a problem.
DecodeIR, IRScope’s decoding module, does some magical mathematical gymnastics to identify the various signals. Usually an unknown signal is identified as a Gap protocol or Unknown protocol. Occasionally the signal follows enough of the protocols rules to be misidentified.
In my example, the OEM learns work, but the NEC2 upgrade, made from the decodes, did not work. All of the user’s files looked okay. I transferred the user’s learn to my remote, and captured the signal. I then loaded the upgrade into my remote, and captured the signal. On the surface everything looks good, but the user had reported that the signals don’t work.

[[Image:irscope23.jpg]] 
'''Figure 23: OEM Signal works, NEC2 Upgrade does not'''

Looking at the Decode Grid you see that the device, subdevice and OBC all match. You might notice the small difference in frequency, but that is insignificant. Most devices tolerate frequency differences of +1000 or -1000 or more without any issue, so the tiny frequency difference shown in fig.23, is not the cause of our problems.
My first order of business is to make sure that I have my thumbnail scale to Fixed Resolution. This will set the thumbnail scale to be equal on all signals, regardless of the sample size. Both Limited Duration and Entire Waveform Thumbnails use arbitrary time lines and so thumbnails of different durations cause the thumbnails to be distorted so they can’t be easily compared.

[[Image:irscope24.jpg]] 
'''Figure 24. Limited Duration and Fixed Duration thumbnails.'''

In Figure 24, the Limited Duration makes the signals look more alike than they really are. The Fixed Resolution shows the signals on the same time scale.
IRScope’s thumbnail comparisons can quickly point out problems. Certain signal problems have different characteristics. For instance, if the lead out time (the time between first frame and the second frame) is too long or too short, it can cause the repeat frames to be treated as new key presses, so a press of “1” might show up as “11”. In this user’s situation, the signals don’t didn’t work at all. When upgrade signals work, the thumbnails look like the thumbnails from the OEM signal. Remember, an IR signal is a timed light pattern, the timing is important. If you look at the Fixed Resolution thumbnails in fig. 24, you can easily see that the timings of the two samples are very different.
Most equipment is pretty forgiving when it comes to small variations in pulse times, but no equipment is going to recognize signals that are this far off. We’re going to need a custom protocol here.

If the thumbnails had not made the problem so evident, I would have looked for more subtle timing problems by comparing the detail portion of the waveform. The OEM signal waveform, Figure 25, shows a typical variance in the pulse timings. We need to do some rounding here to get numbers we can work with. Generally timings with values within 50uS are considered to be equal.
When building a protocol executor in Protocol Builder (PB), I would use the rounded timings from the waveform to create an executor. I would use the following values to create the OEM signal shown in fig.25. 
Lead-In Pair= + 8500, -4250 
Zero = +500, -1250 
One = +500, -3000 

[[Image:irscope25.jpg]] 
'''Figure 25. OEM Signal'''

The official NEC2 IRP shows times in multiples of 564.
Nec2 IRP notation: {38.4k,564}<1,-1|1,-3>(16,-8,D:8,S:8,F:8,~F:8,1,-78)+
Our IRP for the OEM signal, will be show times in a multiples of 500.
If you are comfortable with IRP, you could do the computation and see how different these signals timings are.
<table>
<tr>
<td>
Official Nec2 
Lead in Pair =+8824, -4412 
Zero =+564, -564 
One= +564, -1692 
IRP{38.4k,564}<1,-1|1,-3>(16,-8,D:8,S:8,F:8,~F:8,1,-78)+ 
</td>
<td>
The OEM signal (fig.25) 
Lead-In Pair=+ 8500, -4250 
Zero= +500, -1250 
One =+ 500, -3000 
IRP: {38.4k,500}<1,-2.5|1,-6>(17,-8.5,D:8,S:8,F:8,~F:8,1,-67)+ 
</td>
</tr>
</table>
[[Image:irscope26.jpg]] 
'''Figure 26, shows the pulse times when an upgrade is using the NEC2 executor.'''

For figure 26, I would round the timings to: 
Lead in Pair =+8800, -4400 
Zero =+550, -550 
One= +550, -1650 
Compared side by side, you can see that the NEC2 signal from the upgrade complies with the official

 NEC2 IRP. 

<table>
<tr>
<td>
Official Nec2 times 
Lead in Pair =+8824, -4412 
Zero =+564, -564 
One= +564, -1692 
IRP{38.4k,564}<1,-1|1,-3>(16,-8,D:8,S:8,F:8,~F:8,1,-78)+ 
</td>
<td>
The Nec Upgrade signal fig(26) 
Lead in Pair =+8800, -4400 
Zero =+550, -550 
One= +550, -1650 
IRP{38.4k,550}<1,-1|1,-3>(16,-8,D:8,S:8,F:8,~F:8,1,-78)+ 
</td>
</tr>
</table>
[[Image:irscope26.jpg]] 
'''Figure 26. NEC2 Upgrade Signal'''

If you are not familiar with IRP, you could just compare the rounded timing values from both the OEM signal’s waveform in Figure 25, and the NEC2 upgrade signal in Figure 26.
Compared side by side, you can see how much different the timings are.
<table>
<tr>
<td>
The Nec2 Upgrade signals (fig.26) 
Lead in Pair =+8800, -4400 
Zero =+550, -550 
One= +550, -1650 
</td>
<td>
The OEM signal (fig.25) 
Lead-In Pair=+ 8500, -4250 
Zero= +500, -1250 
One =+ 500, -3000 
</td>
</tr>
</table>

Apparently the OEM signal followed enough of the Nec2 protocol rules to fool decodeIR, but it is not nearly close enough to operate the equipment. The upgrade can’t use the NEC2 protocol. Instead a custom protocol executor would be written. An executor to send a signal like this, with such simple formatting rules, can be easily created by filling in the fields in a Protocol Builder spreadsheet. No additional assembly language programming would be necessary.
After building the executor, I test the executor by shooting the signals at the Widget. Then I adjust settings as necessary to get the details as close to the OEM signals as possible. This assures that the equipment will respond reliably to upgrades created with the new executor.
To learn more about IRP I recommend reading the Infrared Protocol Primer.

==Troubleshooting==
'''Why doesn’t my IRScope Window have a decode grid?''' 
You may have disabled decodeIR. In the Advanced menu, uncheck Disable DecodeIR. 

'''Why am I getting a file creation error when saving or exporting?''' 
Make sure that the Set Save Folder and the Set Export Folder in the File menu have been set to valid directories and that you are not trying to store them directly in the root directory. 

'''When trying to launch IRScope I get a message “Could not open File”.''' 
IRScope only allows one session to run at a time. This message usually indicates IRScope is already running in another window. If that does not seem to be the case, confirm that by checking the
Applications Tab of the Windows Task Manger. 

'''Why can’t I export Pronto Hex when in “Pronto from decode” mode?''' 
The Pronto from decode mode only uses known protocols. If an unknown protocol is selected nothing will be exported, try the Pronto from timings mode instead.

'''I started IRScope, but I can’t find it.''' 
Many settings are preserved between sessions using registry settings. Screen location is one of those settings. Use Windows Task Manager to switch to IRScope and then check the perimeters of the screen to see if you have moved IRScope to the edge and drag it back where you want it. 

IRScope stores its registry settings in HKEY_CURRENT_USER/Software/UEIC/IRScope/Settings 

'''COMMENTS AND SUGGESTIONS:''' Suggestions for additions or corrections to these instructions are
welcomed and should be posted to the forum.

Protocol Builder

2025-11-23T00:09:40Z

The Robman:

'''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 [https://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:

[[Image: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.

IR Help

2025-11-23T00:08:38Z

The Robman:

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

There is so much to learn about JP1. It’s a fascinating subject, but chances are if you are reading this, all you want to do is control your TV, VCR and DVD using 1 remote. This is my attempt to create a guide on how to use IR and the supporting tools. But keep in mind that the software is continually evolving and this document was last updated in the summer of 2010.

This is compiled from many posts and articles I read in the JP1 forum. I’ve borrowed freely from what I’ve read on the JP1 site at hifi-remotes.com, and from the old Yahoo site. My thanks to everyone on the JP1 experts who created the tools and shared their knowledge. - [[User:Vickyg2003|Vickyg2003]]

'''Chapter 1 - Getting Started''' 
[[JP1 or JP1x]] 
[[Remote basics]] 
[[RDFs]] 
[[IR.EXE Safety]] 
[[How can I reset my remote?]] 
[[Files to run the JP1 Tools]] 
 
'''Chapter 2 - Next Steps''' 
[[Connecting IR to your remote]] 
[[IR's Display]] 
[[IR's Menus]] 
[[IR's General Tab]] 
[[IR's CodeSelector]] 
[[Sorts and Moves]] 
[[Macros]] 
[[Key Moves]] 
[[Learned Signals]] 
[[Fav Scan]] 
 
'''Chapter 3 - Intermediate Programming''' 
[[Remote Memory Usage]] 
[[Device Upgrades]] 
[[Using KM, Keymap-Master, to create a device upgrade]] 
[[Using RM, RemoteMaster, to create a device upgrade]] 
[[Protocol Upgrades]] 
[[Creating a Better Upgrade]] 
[[EFCs and OBCs]] 
 
'''Chapter 4 - Advanced Programming''' 
[[Extenders]] 
[[Special Protocols]] 
 
'''Chapter 5 - Finding Codes''' 
[[Finding Codes]] 
 
'''Chapter 6 - Modem Upgradeable Remotes''' 
[[WAV FILES]] 
 
'''Chapter 7 - The Glossary''' 
[[Glossary]]

Remote Master Manual

2025-11-23T00:07:42Z

The Robman:

=== Opening Screen ===
[[image:RM-Intro.jpg]]

==='''Preface'''===
Open Source UEI Remote Control Upgrade Manager. This software was intended to author remote updates for your JP1 compatible remote. It was designed to replace and extend the JP1 software. The ultimate goal is to combine the function of IR and the KeymapMaster Excel spreadsheet into a single application.
----

==='''Requirements'''===
===='''Hardware'''====
===='''Software'''====
----
==='''Get Started'''===
If you haven't already, download and install Java version 6.0 or later. You can download it from the [http://java.sun.com/javase/downloads/index.jsp J2SE Download] page. Either the Java Developer Kit (JDK) or the Java Runtime Environment (JRE) will do.
Download the latest version of Remote Master from [https://sourceforge.net/project/showfiles.php?group_id=30560&package_id=22596 SourceForge], and unzip it to the directory of your choice, preserving directory names.
Download the latest version of the [https://www.hifi-remote.com/forums/dload.php?action=file&file_id=6160 Maps and Images required for RM] from the [https://www.hifi-remote.com/forums/dload.php?action=category&cat_id=81 Main] [https://www.hifi-remote.com/forums/dload.php?action=category&cat_id=7 Tools] section of the [https://www.hifi-remote.com/forums/dload.php File Section] of the [https://www.hifi-remote.com/forums/ JP1 Remotes Forums].
Unzip it to the folder of your choice, creating a maps sub-folder containing all the maps and images. 

If you haven't already, download the lastest version of the [https://www.hifi-remote.com/forums/dload.php?action=file&file_id=5338 RDF files needed for IR and RM] from the [https://www.hifi-remote.com/forums/dload.php?action=category&cat_id=81 Main] [https://www.hifi-remote.com/forums/dload.php?action=category&cat_id=7 Tools] section of the [https://www.hifi-remote.com/forums/dload.php File Section] of the [https://www.hifi-remote.com/forums/ JP1 Remotes Forums].

Unzip it to the folder of your choice. It is recommended that you do NOT place it in the same directory as you placed Remote Master.

Note: You must have RDFs for all supported remotes in order for RM to work correctly when importing or loading device upgrades that were created for remotes other than the one(s) you will be using.

If you are using a version of Windows (95/98/NT/XP/Vista/Windows 7), double-click on Setup.vbs.
This will create shortcuts in Start > Programs > Remote Master for your use. Feel free to send them to you Desktop or copy them to your Quick Launch toolbar. File associations are also created for .rmdu and .rmir file, so you can just double-click on them directly.

That's it, Remote Master is now ready for your use! There are a few different ways to start Remote Master:

Click on the Remote Master or RMIR shortcut in Start > All Programs > Remote Master
Non-windows users should use the rmaster.sh and rmir.sh scripts.

Double-click on a .rmdu or .rmir file.
In your browser, click on a link to a *.rmdu or *.rmir file.
There is a short tutorial available for RM. See [[JP1 - Just How Easy Is It? - RM-IR Version]]

----

==='''User Interface'''===
----
===='''Command Bar'''====
The Remote Master menu bar provides access to general functions and options.

[[image:Rm_cb_prev.jpg]]
====='''File'''=====
The File menu provides ways to load and save Device Upgrade files. Below are the menu items available, and what they do: 
[[image:Rm_cb_file.jpg]]

:'''New''' - :Set all upgrade information to default values, as though starting from scratch.
:'''Open...''' - Bring up a file dialog allowing you to load an existing RemoteMaster Device Upgrade file (*.rmdu). To load a KeymapMaster Device Upgrade file (*.txt), change the Files of type: field to KeyMapMaster device upgrade files.
:'''Save''' - This menu will save the device upgrade to a file. This item will be diabled unless a RemoteMaster Device Upgrade file was loaded, or the "Save as..." item has been used.
:'''Save as...''' - Save the device upgrade to a different file name. The default file name will be the name of the file loaded, or the name used for "Save as...", or the contents of the Description field.
:'''Import from Clipboard''' - Imports a device upgrade from the clipboard. This is useful if you click on a link to a device upgrade (either KM or RM), and your browser simply displays the text of the upgrade. Simply use the context-menu (right-click) to Select All and then Copy the entire upgrade to the clipboard.
:'''Recent''' - Lists up to the 10 most recently opened, or saved, RM device upgrade files.
:'''Exit''' - Exit Remote Master

====='''Options'''=====
The Options menu provides ways to customize Remote Master 
[[image:Rm cb opt prev.jpg]]

:'''Look and Feel''' - Allows you to select the over all look and feel used by RemoteMaster. Most Windows users will want to use the Windows Look and Feel, but I recommend the Metal Look and Feel. The reason for this is simple: the Windows Look and Feel does not highlight the current cell in the Functions panel.
:[[Image:Rm cb opt lf.jpg]]

:'''Font Size''' - Allows you to increase or decrease the size of the fonts used by RemoteMaster.
:[[Image:Rm cb opt fs.jpg]]

:'''Prompt to Save''' - Allows you to specify when Remote Master will prompt you to save your Device Upgrade. The valid values are:
:[[Image:Rm cb opt pts.jpg]]

:'''Remotes''' - Allows you to choose the set of remotes that RemoteMaster will display. Your choices are All, meaning all remotes for which RemoteMaster can find Remote Definition Files (RDFs), or Preferred, meaning only those remotes that are in your preferred list.
:[[Image:Rm cb opt rem.jpg]]

:'''Function names''' - Allows you to choose the function names used when creating a new upgrade. Your choices are Default, meaning the same as KM, or Custom, meaning your own custom list.

:You can edit the list of custom names using Edit custom names.... When editing the custom names, there is a button to import the names of the buttons on the current remote.
:[[Image:Rm cb opt fn.jpg]]

:'''Show remote signature''' - This option display's the remote's signature in () after the remote name. This if very helpful when dealing with remotes with confusing names like the Atlases or the Comcast remotes.

:'''Folders''' - If you have decided to reorganize your file system after the initial RM installation, use this option to locate the RDF's or Map's and Images for RM and RMIR.
:[[Image:Rm cb opt fold.jpg]]

====='''Advance'''=====
[[Image:Rm cb advanced.jpg]]

:'''Primacy''' - This option allows users to choose whether to preserve the OBCs or the Hex when making protocols changes. Typically this should be should be set to OBC, to make sure the signal is correct. Hex is executor specific, so preserving the Hex can change the output.

:'''Edit Protocol''' - This option allows the manual settings for the current protocol to be changed.

:'''New Manual Settings''' - Sometimes a protocol requires a custom executor. A custom executor may be needed for an unrecognized signal, or it might just be a simple tweak to control the number of repeats being sent. Currently we use Protocol Builder (PB) a Microsoft Excel Worksheet to compile a new executor, and then use this option to import the protocol. See [https://www.hifi-remote.com/wiki/index.php?title=PB:_Adding_to_Remote_Master_%28RM%29 Adding a PB Protocol to Remote Master] to see the step by step process.

:'''Import Raw Upgrade''' - If you found an upgrade posted in the forum, but the RDMU or KM TXT file is not available, by pasting the guts of the upgrade, and identifying the remote it was created for, RM can reverse engineer the upgrade.

:'''Import Binary Upgrade''' -This creates an RDMU from a Slingbox BIN file.

:'''Export Binary Upgrade''' - This creates a BIN file for use with a Slingbox or similar device.

====='''Help'''=====
[[Image:Rm cb help.jpg]]

:Readme
:Tutorial
:Home Page
:Forums
:Check for updates
:About...
----

===='''Definition Header'''====
[[Image:RM_Description.jpg]]
:'''Description''' – Fill this field in with the brand and model of the device being controlled
:'''Remote''' – This field must be filled in with the target remote. If this field is incorrect the upgrade will not function correctly. Failing to select the correct remote is the most common newbie error.
:'''Device Type''' – The device type determines which keys will be available without needing to use keymoves. The device type may effect things like volume punch through, but does not determine what type of equipment can be controlled.

----

===='''Tabs'''====
[[Image:RM_Tabs.jpg]]
====='''Setup Tab'''=====
[[Image:RM_Setup_Tab.jpg]]
:'''Setup Code''' – The setup code needs to be a number between 0000 and 2047 for most remotes, however some of the newer remotes allow a range of 0000-4095.
:'''Protocol''' – The protocol is selected from the drop down. Each protocol has a Protocol ID or PID.
:'''Protocol Parameters''' – The protocol parameters will change depending on the protocol selected. Fill in the device numbers, sub devices that were found in the signal decode. Note a zero is not the same as a blank. Do not fill in a sub device if none was reported in the decode. Examine the decode carefully. For this example the decode would be Nec1 1.252 or Nec1 Device 1 sub device 252.

====='''Functions Tab'''=====
[[Image:RM_Functions_Tab.jpg]]

The Function Tab is used to create a list of all the buttons on the OEM remote.
:'''#''' - is the line identifier.
:'''Name''' – Name represents the labeling on the OEM remote. When you are creating the function list, make sure to note double functioning. Often your OEM remote buttons are used to do different functions. They may have small print on or above the buttons, that indicates those functions. That is important information. If you don’t have the OEM remote in front of you its difficult to imagine for example, that the “pause button” for playback, might also be the “up button” when you are in working in the menus. The best way to handle this is to use a compound function name (eg, "pause/up_arrow").
:'''EFC5''' – This column only appears for remotes that can handle 5 digit EFCs. Remotes manufactured prior to 2005 only do 3 digit EFCs.
:'''EFC''' – When signals are decoded an EFC may be reported, but if you are using a non-standard protocol executor, the EFC is unreliable, and you should use the OBC instead.
:'''OBC''' – The Original Button Code, is the function to be represented in the infrared signal. Use this column for data entry when possible.
:'''HEX''' – RM allows entry in the Hex column. This is useful to protocol developers, but leads to confusion to new users because this hex does not correspond to the hex reported in a LIRC file or a manufacturer’s infrared spec.
:'''Action Bar'''
::'''New'''- Inserts a new line
:: '''Delete''' - Deletes the current line, (might not be active if the function has been assigned to a button on the buttons tab.
:: '''Clean Up''' - Deletes all lines with now function codes.
::'''Up''' - Moves the highlighted line up in the list.
::'''Down''' - Moves the highlighted line down in the list.
::'''Copy'''
::'''Paste'''
::'''Paste (IE)''' - Internet Explorer handles the clipboard differently than most programs. This allows for pasting from Internet explorer.

====='''External Functions tab'''=====
[[Image:RM_External_Functions_Tab.jpg]]
Sometimes you need functions from another setup code/upgrade in order to get a complete function list. These functions would be setup as keymoves. The External Functions tab allows these to be included when you assign functions to buttons. The grid will contain all the information that is necessary to setup a keymove. Device/Setup code

:'''Grid'''
::'''#''' - Line number
::'''Name''' – Function name
::'''Device Type''' – Device type of external setup code.
::'''Setup Code''' – External setup code.
::'''Type '''– Specifies the type of data is being entered EFC/Hex
::'''EFC/Hex''' – information for the keymove function.
::'''Notes''' – Notes about the function
:'''Action Bar'''
::'''New''' – Adds a new line.
::'''Delete''' – Deletes the current line
::'''Clean up''' – Deletes any functions that do not have a function code
::'''Up ''' - Moves the selected line up
::'''Down ''' - Moves the selected line down
::'''Copy '''
::'''Paste'''
::'''Paste (IE)''' - A paste that handles an IE (Internet Explorer) clipboard.
::'''Import''' – Opens an upgrade file to add the "available functions"
: The Import screen looks like this.

[[Image:RM_External_Function_Import.jpg|right]]
::Import Controls
::: Select all
::: Select None
::: Toggle - Reverses all the selection marks
::: Ok - adds the selected functions to the external function grid
::: Cancel - aborts selections.
 

====='''Buttons tab'''=====
[[Image:RM_Buttons_Tab.jpg]]
RM has two tabs for assigning functions to buttons. The Buttons tab is a textual interface, the Layout tab is a graphical interface. On this tab, you use have three methods of associating functions with a button.
:1) Press the Auto Assign button attempts to match the functions to the buttons by name.
:2) You can drag and drop a function from the Available Functions area to the Function cell, or the Shift cell, or xShift cell if that feature is available. .
:3) You can double click on a function, shift or xshift cell and then pick the desired function from a list.
:'''The Grid'''
::'''Button''' - These cells contain a list of buttons on the remote,
::'''Function''' – These cells contain the function name assigned to the button.
::'''Shift''' refers to an alternate function that is accessed by pressing a special key such as SET prior to pressing the button
::'''Available Functions''' – is a list of the functions that were entered on the functions tab.
:'''Action Bar'''
::'''Auto Assign''' – attempts to assign functions by matching up the name of the function to the button.
::'''Remove''' – Deletes the function from the current cell

====='''Layout tab'''=====
[[Image:RM_Layout_Tab.jpg]]
RM has two tabs for assigning functions to buttons. The Layout tab is a graphical interface, the Buttons tab is a textual interface.
On this tab, buttons with assigned functions are colored in yellow, and buttons that are present in the key map for the selected device type are outlined in orange. When a button is selected it will be outlined in white, and the button name and associated function name will appear in the field. On this tab functions can be assigned to buttons in 4 different ways:
:1. Press the Auto assign button to get some functions automatically assigned. The ones that get assigned automatically are the ones where you used the default function names and there's an equivalent button on your JP1 remote for that function. You are under no obligation to accept these default assignments.
:2. Drag-n-drop a function onto the desired button
:3. Right-click on a button and select the desired function
:4. Click on a button (it will turn white), then double-click the desired function.
:'''Mode'''
::'''Normal''' – Normal function.
::'''Shift ''' - refers to an alternate function that is accessed by pressing a special key such as SET prior to pressing the button
::'''xShift''' - refers to an alternate function often available when an extender is installed. This alternate function is accessed by pressing a special button prior to pressing the named button.
:'''Available Functions''' – is a list of the functions that were entered on the functions tab.
:'''Action Bar'''
::'''Auto Assign '''– attempts to assign functions by matching up the name of the function to the button.
::'''Remove''' – Deletes the function from the current cell

====='''Key Map tab'''=====
[[Image:RM_Keymap_Tab.jpg]]
The purpose of this tab is to provide print capability for documentation purposes. The grid is described under the Buttons tab.

====='''Output tab'''=====
[[Image:RM_Output_Tab.jpg]]
The output tab is used to transfer an upgrade from RM to IR.EXE. If you are using RMIR, this process is automated.

[[Image:RM_Copy_Icon.jpg|left]]This button is a copy button. There is a copy button above the Device Upgrade and the Protocol Upgrade box.
 
To transfer the device from RM to IR follow these steps.
:1. Switch to IR.
:2. Navigate to the Device Tab
:3. Select Add
:4. Switch to RM
:5. Press the Copy button above the Device Upgrade
:6. Switch back to IR
:7. Paste the upgrade
:8. Press Ok.

Note that the Protocol Upgrade box is empty and there is a message that "Upgrade Protocol NOT REQUIRED" in the example above. If there had been a protocol in the box, the protocol would have to be transferred to IR.exe.
:1. Switch to IR.
:2. Navigate to the Protocol Tab
:3. Select Add
:4. Switch to RM
:5. Press the Copy button above the Protocol Upgrade
:6. Switch back to IR
:7. Paste the upgrade
:8. Press Ok.

Importing Foreign IR Remotes in RemoteMaster

2025-11-23T00:06:20Z

The Robman:

= 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://www.hifi-remote.com/wiki/index.php?title=Importing_Foreign_IR_Remotes_in_RemoteMaster&oldid=880 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://www.hifi-remote.com/forums/dload.php?action=category&cat_id=4 JP1 device update repository] (see also
[https://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 [https://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 [https://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 [https://www.hifi-remote.com/wiki/index.php/IR_Scope_and_IR_Widget_User%27s_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.

Getting started with Xsight and Nevo

2025-11-23T00:04:46Z

The Robman:

[[Image:Xsight_touch.jpg|right]]
== Introduction ==
The Xsight and Nevo model remotes are very advanced IR and RF remotes made by Universal Electronics Inc. (UEI), the maker of One-for-all (OFA) brand and supplier to many OEMs, cable and satellite systems. With original list prices of $150-$250 US, and current prices of around $20 on [https://www.ebay.com/sch/i.html?_from=R40%28xsight%2Cnevo%29+remote+-smart+-battery+-batteries+-rca.TRS0&_nkw=%28xsight%2Cnevo%29+remote+-smart+-battery+-batteries+-rca ebay], they are arguably the best value of any universal remote available today, very similar in form and function to certain Harmony remotes at a fraction of the price. It can control any consumer IR device in existence. Universal Electronics Device Codes Database is the largest and most comprehensive in the world.

:Nevo C2 / Xsight Color - IR only
:Nevo C3 / Xsight Touch - IR and RF

Advanced features include:
*LCD display with up to 5 pages of 6 functions per page
*Fully backlit
*15-18 devices (18 devices for Touch, C2 and C3)
*Rechargeable battery (Touch and C3 only)
*RF with 6 IR blasters (Touch and C3 only)
*Direct RF control of several home automation devices and HR20 series DirecTV receivers (Touch and C3 only)
*72 favorites with icons and custom categories (Mom, Dad, Kids, Sports, News, etc.)
*Activity macros
*Device specific macros
*Variable hold durations
*Pronto hex import
*Custom devices and protocols
*Custom icon for any command
*Offline config with unlimited local file backups and versions
*IR signal analysis tools via Remote Master
*Convert learns to new device
*Programming via Remote Master on Mac/Linux/Windows XP/7/8/10
*Access to huge UEI database, Remote Central codes and JP1 database

== Setup and Programming ==
Xsight and Nevo can be programmed entirely in Remote Master. Device configuration can be done entirely on the remote itself. Activities, Macros and Favorites must be programmed from a PC. If your remote came with a CD, DO NOT install it. The EZ-RC website and software used to program these remotes no longer exists. If you are running Windows 8.1 or greater, also apply the [http://www.oneforall.com/downloads/dl/file/id/344/urc8602_windows_8_1_10_connection_patch.zip Xsight Color patch] ([https://www.hifi-remote.com/files/wiki/urc8602_windows_8_1_10_connection_patch.zip mirror copy]), or the [http://www.oneforall.com/downloads/dl/file/id/347/urc8603_windows_8_1_10_connection_patch.zip Xsight Touch patch] ([https://www.hifi-remote.com/files/wiki/urc8603_windows_8_1_10_connection_patch.zip mirror copy]).

Remote Master is an alternative to the now defunct EZ-RC website. To use it, download and install [https://sourceforge.net/projects/controlremote/files/RMIRDevelopment/ Remote Master]. Then connect your remote and download from it.

If you are new to Remote Master, please read the [[JP1 - Just How Easy Is It? - RM-IR Version|Tutorials]] and learn how to use it before you attempt to program your Xsight or Nevo with it. All JP1 remotes share much of the same functionality. But features unique to Xsight/Nevo are found [[JP1 - Just How Easy Is It? - RM-IR Version#Xsight.2FNevo|here]].

Here is the general work flow:

* The first time you run RMIR, connect your remote and Download from it (and save the .rmir file, in case you want to restore it later)
* Go to the [https://www.hifi-remote.com/forums/dload.php JP1 file section] and download the device upgrades you'd like to add. (Device model numbers usually don't need to match exactly since most models of a similar vintage within the same brand share most of the same codes).
* In RMIR, go to the Devices tab, click New, Open, then browse to the device upgrade file you downloaded from the file section and arrange the functions as desired on the Layout and/or Buttons tabs (click Page+/- to access each page of the LCD screen). Assign icons as desired.
* Click OK when done
* Assign device icons, button names and volume lock (volume punch through) on the General tab
* Create and edit Activities on the Activities tab. Assign icons as desired.
* Create and edit Macros on the Macros tab
* Create and edit Favorites on the Favorites tab. Assign icons as desired.
* Optionally manage and convert learned signals to device upgrades on the Learned Signals tab
* Upload to the remote
* Save often (you can save/load as many versions as you wish)

A Macro is simply a series of commands performed with a single button press. An Activity is a special kind of macro that also assigns groups of buttons to different devices, i.e., volume keys to a receiver, playback keys to a disc player, number keys to a cable box, etc. Activities are good for turning several devices on or off and selecting the appropriate inputs as well as assigning each group of keys to the appropriate devices. Macros are good for sending a series of commands to save button presses, i.e., if it takes several steps to toggle captions on your device, put all those steps in a macro and assign to a single button.

The Volume Lock settings on the General tab set the volume control device when a given device is selected. The volume device on the Activities tab takes precedence over this when a given activity is run.

Please post questions, bug reports and feature requests [https://www.hifi-remote.com/forums/viewtopic.php?t=14804&start=0 here]. Development discussion should continue in the existing developer thread. If you are a beginner with RM and have general questions, please post those in a new thread or other existing threads if applicable.

== Favorites and Icons ==

The Nevo and Xsight Touch and Color models have a favorites list feature. It consists of one master list, and several other custom lists which are a subset of the master list. Each favorite can have an icon (max 72x34, automatically scaled down if larger) which can be assigned in RMIR by double clicking the Icon checkbox. The best source for channel logo icons is [http://www.iconharmony.com/icons/watchtv?category=NevoXsight iconharmony] and there are more icons [https://www.hifi-remote.com/forums/dload.php?action=category&cat_id=164 here].

Every individual function for every device can also have an icon. Devices and Activities can also have icons, but those are limited to a set of built-in icons.

The total number of icons across all favorites, profiles and functions is limited to 80 minus the 8 built in profile icons. If you find that you cannot add an icon, you have reached this limit. In that case, delete any unused or unnecessary icons.

[https://www.hifi-remote.com/forums/viewtopic.php?p=120666#120666 Here] is a dedicated icons thread with more info and links to other icon sources.

== Win 8.1/10 Requirements ==

Certain registry settings are required in order for Xsight to maintain a connection in Win 8.1 and 10 which are detailed [[Enhanced Power Management|here]]. ''(Requires RMIR v2.10 build 5, or later)''

Links to the official registry patches from OneForAll are posted below in the [[Getting started with Xsight and Nevo#References|References]] section. Or you can simply follow the instructions in RMIR linked above.

== Troubleshooting ==

*If the remote won't learn, make sure you are aiming at the bottom of the Xsight/Nevo. The learning eye is not at the top of the remote like most other JP1 remotes.
*If you can't remove the Assist buttons in your activities, then you need to update the firmware on your remote. If your firmware is not the latest version, Remote Master will prompt you to upgrade it.
*If your remote won't download, upload or stay connected in Windows 8/8.1/10, you need to perform the registry patch in the previous section.
*If your remote is unresponsive, try the reset instructions [https://www.hifi-remote.com/forums/viewtopic.php?p=27215#27215 here].
*If none of the above work, you can rebuild the memory in the remote and so remove any corruption by performing the following steps:
# Connect remote with the USB cable.
# Open RMIR and load the .rmir file of the setup before you had any problems. Do NOT try to upload it to the remote. Just load it into RMIR.
# Open the "Advanced" menu and select "XSight operations". This opens a sub-menu. On that, select "Format and rebuild XSight file system...".
# You should now have a message with some information that asks if you are sure you want to continue. Click the "Yes" button.
# The progress bar at the bottom of the screen will now say "REBUILDING FILE SYSTEM". This will take a few minutes. I have just done this and it took 2 minutes on my PC. After one minute it only reached 15%, but it speeds up after that. When it finishes, it should give a message saying "Reformatting and rebuild complete" and showing an OK button. Press that button.
# Now press the Upload button on the toolbar (or select "Remote > Upload to remote" from the menu bar if you prefer). You will get the usual message saying that an upload overwrites what is in the remote and asking if you want to continue. Yes, you do. Your setup should now upload to the remote without any problems. When the upload finishes, you can disconnect the remote from the PC

== FAQ ==
'''What's the difference between the Xsight Color, Xsight Touch, Nevo C2 and Nevo C3?'''
*The 18 device Xsight Touch (URC-8603 or AARX18G) is identical to the Nevo C3, and the 15 device Color (URC-8602 or ARRX15G) is identical to the C2 except that the C2 has 18 devices. The Touch and Color are the same except that all Touch models are 18 device, add RF capability, rechargeable battery, charging base, slimmer/lighter design and touchscreen. The on-screen functions on the Color are accessed via buttons along the sides rather than direct touch. The URC models are OneForAll brand in Europe and the AARX are Acoustic Research brand in the US. C2 and C3 are Nevo brand worldwide. The first Xsight model was introduced around 2009 and discontinued around 2011.

*The RF capable Xsight Touch and Nevo C3 require a base (with 6 included blasters) in order to be used in RF mode (ARRE433B or REX-433). Without the base, the remote can still be used in IR mode or in RF mode for HR2x and H2x series DirecTV devices and certain RF home automation devices.

*There are two other similar, but more limited Xsight models, the 12 device Plus (URC-8620 or AARX12G) and 6 device Lite (URC-8610). These are physically smaller and have only a 3 line LCD where each function is accessed by using an up/down rocker switch to select.

*Finally, there is the entirely unique Monster Revolution 200. It is not to be confused with any other Monster remote and is the only one that used EZ-RC. It is essentially two different controllers in one. It is described as providing Home Theater (AV) and Lighting Control and these are entirely separate functions. The AV support is broadly similar to that of the XSight Lite, supporting 6 devices together with Activities and Favorites. The big difference from the XSight Lite is that it can ONLY be programmed with EZ-RC (and now, of course, RMIR). There is no built-in IR database and no means of programming it from the remote. RMIR (as of v2.05 build 2) provides a complete replacement for EZ-RC support, including firmware upgrade. The Lighting control, on the other hand, can ONLY be programmed from the remote. EZ-RC has nothing to do with this functionality. A detailed manual is provided on disk about this programming. This is Z-Wave control; for those like me who have no idea what this means, the glossary in the manual says "Z-Wave uses reliable, low power radio waves to control all aspects of your home wirelessly: lighting, climate control, safety and security, home entertainment, energy conservation, and remote monitoring".

'''What are some of the special features of Remote Master?'''
*It gives you direct access to every aspect of the remote configuration.
*Save/load/edit/create any number of devices or remote configurations off-line and edit them whether your remote is connected or not.
*Load any of the thousands of devices in the JP1 file section.
*Download new devices from UEI on the Simple Set website and convert to Xsight/Nevo format.
*Convert learns to new devices which results in perfect signals and uses less memory.
*You can use tools like IRScrutinizer to analyze pronto hex codes and build your own devices from them in RM.
*Runs on many platforms (PC/Mac/Linux) and does not require a browser.

'''How is Xsight different from other JP1 remotes?'''
*Xsight has an LCD (controlled via touch or buttons depending on the model) for up to 30 additional functions per device or 72 favorites with custom icons. This is a major advantage as additional functions can be logically organized and clearly labeled. On a traditional JP1 remote, additional functions would have to be memorized or documented on a "cheat sheet" for reference.

*Xsight includes a USB interface cable, so it is not necessary to buy or build a JP1 cable.

*Xsight has no "keymoves" like other JP1 remotes since you can assign any function from any device to any button in the Device editor. This takes the place of keymoves.

*Xsight does not and never will have an extender. This means no extender capabilities like toadtog or calling macros from within macros.

*Xsight has many extender features already built-in: unlimited length macros, device specific macros, pauses, key group mapping and enough devices so that multiplexing isn't needed. It also has enough LCD buttons that long, short, double, shifted and double shifted buttons aren't needed either.

*Xsight is activity based. This means the Xsight has a special class of macros that includes key group mapping for mixing the functions of different devices and handling channel lock and volume punch thru. However, Xsight activities differ from Harmony activities in that after the activity macro runs, the remote ends up in a specific device mode with certain key groups mapped to other devices as desired. In this sense, an Xsight activity is simply a macro plus key group mapping, not a mode of operation per se, like a Harmony activity would be.

*Xsight Touch can natively control HR2x, H2x series DirecTV DVRs and receivers as well as many home automation devices directly via RF without needing an RF base or IR blasters, making it a truly universal RF remote

*Xsight has guided, interactive device code setup on the remote. This means if you want to use Xsight without activities, to set up the remote, you simply look up the brands of your devices on the remote itself without having to look up any codes or connect to a computer.

*Xsight favorites feature is greatly enhanced over other JP1 remotes. Rather than just a few favorites executed sequentially by a single button, Xsight has up to 72 directly accessible favorites on the LCD with custom full color icons and optionally grouped into several custom categories.

*Xsight Touch has a rechargeable battery and charging base.

*Xsight has a huge amount of memory. Rather than a few kilobytes, it has a few megabytes for devices, macros, learning and icons.

*These remotes have been discontinued since 2011 and as such, the material used to create the rubberized feel on these remotes is aging. It may be desirable to remove it using a solvent or similar product.

'''How does Xsight compare to similar Harmony remotes?'''
*The Xsight Touch RF remote is very similar to the Harmony 900 and Xsight Color IR remote is very similar to the Harmony One, 650, 665 and 700 in terms of button layout, ergonomics and features. Both are PC programmable, activity based, backlit, learning, have a step-wise help facility, and have favorites and icons. Like the 900, the Touch is RF and has a rechargeable battery and charging base. Like the 650/665, the Color is IR only and uses standard AA batteries. But you can use rechargeable AAs (Eneloop type batteries are highly recommend).

*The biggest difference is that Xsight does NOT have power and input state tracking like Harmony. This means for TOADs (devices that have only power toggle and input cycling commands), Xsight cannot remember those states. In activity macros, devices could toggle off when it was intended for them to toggle on or go to the wrong input. But, if you are able to use discrete power and input commands, this doesn't matter. With discretes, the power and input states will always work correctly. This can also be an advantage in systems using HDMI-CEC control which normally interferes with Harmony state tracking.

*'''Key advantages Xsight has over Harmony are:'''
**6 functions per page
**Hard Red/Green/Blue/Yellow buttons (Harmony One lacks these)
**15 devices (18 devices for Touch, C2 and C3)
**Native RF universal remote control for home automation and some DirecTV receivers
**72 favorites with custom categories (Mom, Dad, Kids, Sports, News, etc.)
**Editable activity macros
**Unlimited macro length
**Variable hold durations (great for turning TV vol to zero with one command)
**Pronto hex import
**Custom devices and protocols
**Custom icon for any command
**Offline config with unlimited local file backups and versions
**IR signal analysis tools
**Advanced programming via Remote Master on Mac/Linux/Windows XP/7/8/10
**Access to huge UEI device database, Remote Central codes and JP1 database

*'''Key advantages Harmony has over Xsight are:'''
**Power and input state tracking
**Access to Harmony device database

'''What is the latest firmware and how do I get it?'''
*The latest firmware version is 1.3.32 for Xsight and 1.3.33 for Nevo (Home -> Settings -> -> About) and is available in Remote Master. If you are not running the latest, Remote Master will prompt you, and you can perform the upgrade from there.

'''How can I factory reset my remote?'''
# Go to 'Home'
# Hit settings'
# Scroll to the last page
# Hit 'Reset' ONCE
# Type '981'
# Screen should change from 'Reset' to 'Factory Reset'
# Press Factory Reset

== Buying the Nevo ==
* '''Nevo C2 / C3, Xsight Color / Touch:''' You can buy the Nevo C2 / Xsight Color on ebay (shipped worldwide from China) for under $25, other models for more: ([https://www.ebay.com/sch/i.html?_from=R40&_nkw=%28xsight%2Cnevo%29+remote+-smart+-battery+-batteries+-rca+-sl+-q50&_sacat=0&_odkw=%28xsight%2Cnevo%29+remote+-smart+-battery+-batteries+-rca+-sl&_osacat=0 eBay Search])

[[Image:Xsight_Lite.jpg|right]]
== Other Xsight Models ==
There are also a few other Xsight models, the 6-device Xsight Lite / Plus / Uno, aka, URC-8610 / URC-8620 / ARRX06G. Like the other models, they have an LCD screen, but it's limited to 3 commands at a time, accessed by scrolling and selecting one at a time. They also have a USB port and works with Remote Master and may have a black or silver bezel around the screen.

== References ==
*[[Xsight_Disassembly]]
*[https://www.hifi-remote.com/files/wiki/urc8602_manua_en.pdf Xsight Manual (mirror copy)]
*[http://www.avsforum.com/forum/93-remote-control-area/1157746-acoustic-research-xsight-remote.html Xsight thread at AVSForum]
*[http://www.remotecentral.com/reviews/acoustic_research_xsight_touch/index.html Xsight review at RemoteCentral]
*[http://www.iconharmony.com/icons/home Icons and Logos]
*[https://sourceforge.net/projects/controlremote/files/RMIRDevelopment/ Remote Master]
*Win 8/10 Connection Patch from OneForAll (mirror): [https://www.hifi-remote.com/files/wiki/urc8602_windows_8_1_10_connection_patch.zip Xsight Color], [https://www.hifi-remote.com/files/wiki/urc8603_windows_8_1_10_connection_patch.zip Xsight Touch]
*[https://blogs.msdn.microsoft.com/usbcoreblog/2013/11/08/help-after-installing-windows-8-1-my-usb-device-doesnt-charge-or-it-disconnects-and-reconnects-frequently/ Microsoft Windows 8.1 connection patch]
Note: All Xsight Color/Touch info also applies to Nevo C2/C3.

RIDgen

2025-11-22T23:58:19Z

The Robman:

<noinclude>{{ReplayTV Header}}</noinclude>
===[[RIDgen]]===
[https://www.hifi-remote.com/forums/dload.php?action=file&file_id=2253 RIDgen] is a software tool created by Flipflop to convert UEI's EFC or OBC codes into a format useable by [[ReplayTV]] DVRs. <noinclude>There is a tutorial called "[[How to use RIDgen]]", which explains how to extrapolate information from an RMDU file and incorporate it into RIDgen to create a RID file.</noinclude>
<noinclude> [[Image:RIDgen.jpg]]</noinclude>
[[Category:ReplayTV]]
<noinclude>{{ReplayTV Footer}}</noinclude>

How to use RIDgen

2025-11-22T23:57:29Z

The Robman:

<noinclude>{{ReplayTV Header}}</noinclude>
==[[How to use RIDgen]]==
<noinclude>{{:RIDgen}}</noinclude>
===Prequisites:===
:*[https://www.hifi-remote.com/forums/dload.php?action=file&file_id=2253 RIDgen] software package
:*[https://controlremote.sourceforge.net/ RemoteMaster] with associated [https://www.hifi-remote.com/forums/dload.php?action=file&file_id=5338 RDF] files.

===Instructions:===

:# Find a JP1 upgrade file the [https://www.hifi-remote.com/forums/dload.php?action=category&cat_id=4 Device Upgrade] category of the File Section.<noinclude> (In the examples below, we're going to use this file, "[https://www.hifi-remote.com/forums/dload.php?action=file&file_id=4687 DirecTV D1x, H2x, HR2x, R1x and R2x series (addr 1-8)]" in the demonstration) </noinclude>
:# Load that file into Remote Master (RM).<noinclude> [[Image:RIDgen.RM-Setup.jpg]] </noinclude>
:# Run RIDGen and copy the "Protocol", "Device Number", and "Sub-Device" or other sub-parameter from RM into the respective fields. <noinclude>[[Image:RIDgen.Setup.jpg]] </noinclude>
:# Select the "Functions" tab in RM. <noinclude> [[image:RIDgen.RM-Functions.jpg]] </noinclude>
:# Copy the EFC or OBC codes for all digits 0 through 9, as well as Enter and Power functions (if available) from RM to RIDGen. <noinclude>[[Image:RIDgen.Functions.jpg]] </noinclude>
:# Click the "MakeHex" button to verify the Initial bits and Repeated bits get generated and propagate into their respective columns. 
:#* You might get an error stating, "Unknown Protocol". <noinclude> [[Image:RIDgen.Unknown.jpg]] </noinclude> This is an indication that MakeHex does not have a InfraRed Protocol (IRP) file for the respective protocol included with the RIDgen distribution. You may need to generate one or find an appropriate IRP file which address the selected protocol. <noinclude>In this case, we can the [[DecodeIR#DirecTV|DecodeIR]] documentation against the [[DirecTV]] protocol. It states that DirecTV was once called, "Russound". Since there is a Russound.irp file in the RIDgen directory, we can either rename the file or reword the protocol field appropriately. [[Image:RIDgen.MakeHex.jpg]] </noinclude> 
:# At this point you can click "Save" in RIDGen, the filename will default to "C1000fi.rid". The nomenclature of the filename is "(first letter of Type)(Code#)fi.rid". Altering the values for Code and Type in RIDgen will change the output filename respectively when opting to save. 
:* You can see an overview of the fields in the [[RM to RIDgen Overview]] document.
<noinclude>{{ReplayTV Footer}}</noinclude>
[[Category:ReplayTV]]

Pronto IR Formats

2025-11-22T23:56:27Z

The Robman:

= Pronto IR Formats =

== Preamble ==
This article describes in detail the formats of IR code filing for Pronto and ProntoPro models (RU-890, RU-940, RU-970, TS-1000, TSU-2000, TSU-6000, RC-5000, RC-5000i, RC-5200, RC9200, RAV-2000, USR-5). It is supposed to be interesting for those, who want to clean up his IR codes – in order to find out what all the numbers in field “IR code:” mean and for troubleshooting; - those, who want to develop an IR code converter into other driver/configuration formats – Crestron (.IR), AMX (.IRL), Xantech (.PAL), Niles (.LIN), ADI Ocelot (.LIR), RedRat2 (.TXT), Denon RC8000 (.RCX), ProntoNeo (.NCF), ProntoNG (.PCF) etc, as a manual of most popular and complicated IMHO IR code format.

It is advisable for you to have a notion of modulated IR signals transmission [1], but I will also coin that terms for completeness. References to some concepts can be earlier than the description of theirs, so as not to touch on same concept doubly. I am not going to mention the details of realization which is not essential for the description of the format.

== Acknowledgments ==
I would like to thank Daniel Tonks, Stewart Allen, Barry Gordon, Marcel Majoor, Steven Keyser, Bertrand Gillis, Loran Richardson, Bernard Barrier, Barry Shaw, Rob Crowe, Andrea Whitlock, those, who reply at forums - for help and support, my wife – for indulgence and star50fiveoh - for sober intolerance to this article’s subject :)

== Warning ==
Standard warning about “… your own risk” is in effect.

== Buttons, signals, commands and codes ==
In order to avoid involving in terms, I specify them precisely:

[[Image:Pronto-formats-buttons.jpg]] 
''Figure placeholder: Picture 1 — Interaction of buttons, IR signals, commands and IR codes''

The button, IR signal, command and IR code are not corresponding mutually:
* the same button can produce different IR signals (see Toggle Codes);
* different IR signals can be recognized by decoder as same command (see Clean and Dirty Codes);
* the same IR signal can be encoded as a number of IR codes in different formats.

== Modulated IR signal ==
For some reasons, mainly for simplicity and interference immunity, almost all IR signals, currently used to IR translation, have the same structure. IR transmitter includes a square-wave generator (oscillator), coder and IR LED. All the time of transfer oscillator generates square impulses with fixed (for this remote) carrier frequency; depending on pressed button (and, may be, remote mode), coder forms a code of command — sequence of conventional logical 0s and 1s; IR LED flashes this command modulated by generated impulses.

[[Image:Pronto-formats-2-IR.jpg]] 
''Figure placeholder: Picture 2 — IR LED replays modulated IR signal''

Any modulated IR signal can be fully characterized via carrier frequency and the sequence of period amounts when emitting is on and off. For picture 2 this sequence is 6–2–4–2–4–…

Sometimes remote emits the signal all the time until the button such as VOLUME+ will released. Another way it flashes once per press, or first, once emitted signal is not the same that repeating one, followed it. So, it is convenient to suppose that in the general way IR signal consists of once part, the start emitting sequence and repeat part. For example, endless IR signal 6-2-4-2-4-6-6-3-3-12-6-3-3-12- has the once sequence 6-2-4-2-4-6 and repeat sequence 6-3-3-12: 6-2-4-2-4-6 | 6-3-3-12. All currently used IR signals can be represented either as a union of once and repeat sequences or as the only once or only repeating sequence.

[[Image:Pronto-formats-3-IR.jpg]] 
''Figure placeholder: Picture 3 — Cutting IR signal into once sequence and repeat sequence''

Usually, IR codes, describing IR signal this way, are not so long. If learned IR code is not an air conditioner code, it can be completely go in “IR code:” field at ProntoEdit.

In the most of cases carrier frequencies are nearby 35KHz, but you will certainly be lucky enough to try a remote with 175KHz, 345KHz, 455KHz or 1.1MHz.

== “Clean” and “dirty” codes ==
[1: “Unclean” and “clean” IR commands (Working With Prontoedit: Learning & Infrared)]

It is not necessary to replay IR signal precisely, IR receiver will “identify” received IR signal as correct command, if it looks like real command adequately, say, carrier frequency and burst pairs’s lengths differ from original IR signal less than for 10%. I.e. there is precise, original IR signal for every command, may be not replay-able for Pronto, and also many IR signals that Pronto can replay and IR receiver can recognize as that command. The codes of those signals may have different lengths, and the shortest one is “clean” code, and the all other codes are “dirty” and very “dirty”.

Reasons to prefer “clean” codes:
* IR signal of “clean” IR code is more recognizable by IR receiver
* some “dirty” IR codes can lead IR receiver astray or halt it
* “clean” code is shorter, and replay of it takes less time in macros
* you can visually check “clean” IR code’s accuracy — the lengths of every “clean” IR codes per remote are the same, except, may be, buttons like VOLUME+
* “clean” code is more convenient to analyzing, in order to guess a discrete command, absent at this remote
* using of “clean” IR codes stirs ambitions of punctual Prontoyers

The ordinal way to obtain “clean” IR code is cutting from existing one [1]. Sometimes it is useful to develop special software — generator of all concrete type IR codes — in order to “discover” all possible commands, supported by that device, including those absent at remotes.

Note: There is no difference in IR learning to Pronto standalone or to computer via Pronto, but sometimes this process is faulted due a communication error.

== Toggle IR codes ==
[1: Why won’t my buttons work twice in a row? (Working With Prontoedit: Learning & Infrared)]

It is necessary not to mix up toggle IR codes and toggle IR commands. Toggle Command is a command with toggle function such as standby/on, see TOAD at [1]. In contrast to that, Toggle IR Code contains as minimal 1 toggle bit, see RC5 at [2].

There are many possible troubles and noises at IR transfer — sun, fluorescent lamps, interference with another IR transfer, dust, pets, household and tremor of hesitating hand, holding remote. First two troubles can be cured by signal modulation. Other problems, concerning temporary obstacle, are solved logically. Commonly they use two different IR signals per button — one for odd presses and another for even. As a rule, these codes differ in one or two logical bits (“toggle” bit or “parity”), and both of them encode the same command. When IR decoder receives IR signal such type, it ignores the same signals (or signals with the same “parity” bit) received twice, in order to avoid taking noise as double click.

Pronto IR learning procedure uses the only button pressing, and because of it Pronto can detect as toggle codes only codes of some predefined types, that look like known codes, for example, RC5. When Pronto replays these codes, it emits in turn odd and even IR signals for every type of predefined code format (and if existing, subformat). So repeating the same alias for “long button press” in macro is not effective for toggle codes; it is necessary to convert this code to format 0000 to do it.

If Pronto learns real toggle codes as ordinary, learn all codes in the same parity, and only the “blank” command (that does nothing, if it exists at remote) — in opposite parity, and give any Pronto button two actions — odd real command and even “blank” [1].

== Pronto IR code filling formats ==
[1: Type of code (Working With Prontoedit: Learning & Infrared)]

IR codes are kept in Pronto and in CCFs in bytes (as all data), but Pronto software uses two-byte hexadecimal words delimited by spaces at IR code view (editBox):
<code>0000 0070 0003 0002 0006 0002 0004 0002 0004 0006 0006 0003 0003 000C</code>

I will write all sizes and offsets in 16-bit words and all numbers in hex, if not specified otherwise. First word — '''wFmtID''' — identifies IR format.

Supported formats:
* 0000 — raw oscillated code
* 0100 — raw unmodulated code
* 5000 — RC5
* 5001 — RC5x
* 6000 — RC6 Mode 0
* 7000 — predefined code of variable length
* 8000 — index to UDB
* 9000, 900A, 900B, 900C, 900D, 900E — NEC
* 9001 — basic mode YAMAHA NEC code

[[Image:Pronto-formats-4-hierarchy.jpg]] 
''Figure placeholder: Picture 4 — hierarchy of Pronto IR formats''

= Raw formats (wFmtID = 0000 or 0100) =
They are simple, basic, most commonly used formats. Almost all IR signals can be represented (exactly or cognitive) either in 0000 or 0100 format. There is no way to encode toggle IR codes at these formats, but separately, odd and even IR code can be converted from toggle form to 0000 format.

== Raw oscillated code (wFmtID = 0000) ==
This is the format that is often implied, when they say “Pronto IR format”. It contains lengths while LED flashes and while
LED is off in carrier periods (“burst pairs”) in two optional parts - once and repeat sequences.

For example, code from pic.2 and 3 will encoded in this format as 0000 0070 0003 0002 0006 0002 0004 0002 0004
0006 0006 0003 0003 000С, where:

{| class="wikitable"
! offset !! size !! name !! type !! description !! sample
|-
| 0 || 1 || wFmtID || word, ID || Format ID. Must be 0000 || 0000
|-
| 1 || 1 || wFrqDiv || word, positive || Carrier frequency divider || 0070
|-
| 2 || 1 || nOnceSeq || word, length || Number of burst pairs at once sequence || 0003
|-
| 3 || 1 || nRepeatSeq || word, length || Number of burst pairs at repeat sequence || 0002
|-
| 4 || 2*nOnceSeq || aOnceSeq || array of rBurstPair || Once sequence || 0006 0002 0004 0002 0004 0006
|-
| 4+2*nOnceSeq || 2*nRepeatSeq || aRepeatSeq || array of rBurstPair || Repeat sequence || 0006 0003 0003 000C
|}

and rBurstPair consists of:

{| class="wikitable"
! offset !! size !! name !! type !! description !! sample
|-
| 0 || 1 || wLEDflash || word, positive || Periods when LED flashes with carrier || 0006
|-
| 1 || 1 || wLEDoff || word, positive || Periods when LED is off || 0002
|}

Details:
* wFmtID: word = 0000, Format ID
* wFrqDiv: word in range 0001..FFFF, wFrqDiv = 4,145146 MHz / <signal carrier>. So wFrqDiv = 0001 corresponds to signal carrier » 4,1 MHz, and wFrqDiv =FFFF ~ 63Hz. I have measured this constant indirectly and have obtained 4,1455±0,0006 MHz, which is close enough with magical number 4,145146 [2], and far enough from 4,194304 [5], but I can’t locate quartz oscillator with this nominal at catalogues.
* nOnceSeq: word in range 0000..0100, is equal to amount of burst pairs at once sequence
* nRepeatSeq: word in range 0000..0100, is equal to amount of burst pairs at repeat sequence
* wLEDflash: word in range 0001..FFFF, is amount of carrier frequency periods when LED flashes every first half-period and turned off for the last half-period
* wLEDoff: word in range 0001..FFFF, is amount of carrier frequency periods when the LED is off

Next picture will dispel all residuary questions:

[[Image:Pronto-formats-5-correspondence.jpg]] 
''Figure placeholder: Picture 5 — correspondence between IR-signal and IR-code at format 0000''

== Raw unmodulated code (wFmtID = 0100) ==
Same structure as 0000, but LED is continuously on for the first word of the burst pair (no carrier):

[[Image:Pronto-formats-6-difference.jpg]] 
''Figure placeholder: Picture 6 — difference between IR signals for 0000 vs 0100''

Differences:
{| class="wikitable"
! offset !! size !! name !! type !! description !! sample
|-
| 0 || 1 || wFmtID || word, ID || Format ID. Must be 0100 || 0100
|}

aBurstPair consists of:

{| class="wikitable"
! offset !! size !! name !! type !! description !! sample
|-
| 0 || 1 || wLEDon || word, positive || Periods when LED is on || 0006
|-
| 1 || 1 || wLEDoff || word, positive || Periods when LED is off || 0002
|}

This format completes format 0000 to universal description of all raw IR signals, but codes at format 0100 are rare – it is
exposed to sun light and other IR noises. I have learned only 2 devices with these codes – noname drape drive and Dish Satellite
Positioner. Nevertheless, sometimes it is useful to use IR signal without carrier, for example, for Sony Contol-S: you can replace an
IR probe at RX-77 to ordinal jack, change 0000 to 0100 at IR codes, and your Sony device will be controlled by Control-S. Some
other systems also support IR signals without carrier, like Crestron’s CstmFreq value = 43.

= Predefined formats (wFmtID = 5000, 5001, 6000, 7000, 8000, 9000, 9001, 900A, 900B, 900C, 900D, 900E) =
There are a number of additional, predefined IR formats, supported by some reasons. They can’t describe all IR signals, every type/subtype of this format represents only IR codes with specific structure, for custom “brand”. Also, we need additional data tables to replay these signals. These predefined formats are more compact than corresponding raw IR codes and, as a rule, simple and “clean”. I.e., if you learn IR as 5000 or 7000 and it is not a bug, then that and all other IR signals from this remote must be codes of this type.

Predefined formats have different structure, but for the reason of compatibility with format 0000, fields wFrqDiv, nOnceSeq, nRepeatSeq leave as dummy, so that code “looks” the same. aOnceSeq and aRepeatSeq are replaced with sCode, that consist real code info. Also, nOnceSeq and nRepeatSeq must meet the condition (nOnceSeq + nRepeatSeq) * 2 = sizeOf(sCode):

Template header:
{| class="wikitable"
! offset !! size !! name !! type !! description !! sample
|-
| 0 || 1 || wFmtID || word, ID || Format ID || 5000
|-
| 1 || 1 || wFrqDiv || word, dummy || Unused word for compatibility || 0000
|-
| 2 || 1 || nOnceSeq || word, dummy || Dummy code length || 0000
|-
| 3 || 1 || nRepeatSeq || word, dummy || Dummy code length || 0001
|-
| 4 || (nOnceSeq+nRepeatSeq)*2 || sCode || structure || Predefined code || 0000 0000
|}

Not all of the predefined formats are supported by any Pronto model – here a table of compatibility is:

{| class="wikitable"
! wFmtID !! RU-890/940/TS-1000/RC-5000/5000i !! TSU-2000 !! RC-5200/9200 !! TSU-6000/RU-970/USR-5 !! RAV-2000
|-
| 0000, 0100, 5000, 5001, 6000, 7000 || ✔ || ✔ || ✔ || ✔ || ✔
|-
| 8000 || || ✔ || || ✔ || ✔
|-
| 9000 || || || ✔ || ✔ || ✔
|-
| 9001 || || || || || ✔
|-
| 900A–900E || || || ✔ || ✔ ||
|}

Also, RC-3200 does not support all of this formats directly (except 0000), but RC-3200 Setup converts codes 0100, 5000, 5001 and 6000 codes into format 0000 automatically, and this feature can be used from elsewhere!

Note: 0000 format used by RC-3200 is extended by including support of unmodulated IR signals with special value of wFrqDiv = 0001.

When I describe these formats, I will translate them to format 0000, in anticipation of this converter is already exist.

= Template based formats (wFmtID = 5000, 5001, 6000, 7000, 9000, 9001, 900A, 900B, 900C, 900D, 900E) =
Template based formats are used for memory saving, for representing toggle IR codes, and for encoding IR signals with high
carrier frequency.

Segment SYS at Pronto Firmware contains 2 tables for encoding/decoding IR codes these types:

== SYS segment tables ==
{| class="wikitable"
! dID !! zSystem !! zTemplate !! zMask !! dFrqDiv !! bU1 !! dU2 !! dU3 !! dU4
|-
| 00 || rc5 || 1[01]{01}[01]%11R || 5000h + {4-8}{12,9-14} || 73 || 0 || 2 || 0 || 0A
|-
| 01 || rc6m0 || H1000ftT}[01]%16R || 6000h + {7-14}{15-22} || 73 || 0 || 0 || 0 || 0A
|-
| 02 || rc5e || 1 01]{01} [01]%5S[01]%12R || 5001h + {4-8}{12,10-15}{15-20} || 73 || 0 || 3 || 0 || 0A
|-
| 03 || b&o || 115[1234]*R?|<3[12345]* || 7000h || -09 || 0 || 5 || 0 || 14
|-
| 04 || kenwood || s$[01]%32e|rp || 7000h || -09 || 0 || 2 || 1 || 14
|-
| 05 || pioneer || o$[01]%32[RSTUo] r[01rRSTUo]* || 7000h || -04 || 0 || 4 || 1 || 14
|-
| 06 || ehrep || s[abcderst]%4[abcderst]* |s[abcderst]%4[abcderst]* || 7000h || -0C || 0 || 4 || 0 || 14
|-
| 07 || ehonce || s[abcderst]%4[abcderst]* || 7000h || -0C || 0 || 4 || 0 || 14
|-
| 08 || grundig 16ac || P{ac} [abcd]%7r || 7000h || 88 || 0 || 0 || 0 || 06
|-
| 09 || grundig 16bd || P{bd}[abcd]%7r || 7000h || 88 || 0 || 0 || 0 || 06
|-
| 0A || thomson1 || 2{12}[12]%9R || 7000h || 7C || 0 || 1 || 0 || 0E
|-
| 0B || thomson2 || {12}{12}[12]%9[RS] || 7000h || 7C || 0 || -1 || 0 || 0F
|-
| 0C || thomson3 || [12]%4{12}[12]%7[RST] || 7000h || 7C || 0 || -1 || 0 || 10
|-
| 0D || ferguson || s%2(01}[01]%9[RS] || 7000h || -0C || 1 || 4 || 0 || 0D
|-
| 0E || telefunken || (01} {01}[01]%9[RS || 7000h || -18 || 1 || -1 || 0 || 0E
|-
| 0F || echostar || T01]%5R || 7000h || 42 || 0 || -1 || 0 || 07
|-
| 10 || saba || (01}{01}[01]%9[RS || 7000h || -08 || 1 || -1 || 0 || 0E
|-
| 11 || crown || 2{12}[12]%9[RS] || 7000h || 6D || 0 || 2 || 0 || 0E
|-
| 12 || seleco || 2(12}[12]%9[RS || 7000h || 63 || 0 || 2 || 0 || 0E
|-
| 13 || nec1a || I[01]%32F|R || 900Ah + {8-1,16-9)}{24-17,32-25} || 6D || 0 || 0 || 0 || 0E
|-
| 14 || nec1b || I[01]%32F || 900Bh + {9-2,17-10}{25-18,33-26} || 6D || 0 || 0 || 0 || 0E
|-
| 15 || nec1c || I[01]%32FI[01]%32F|R || 900Ch + {8-1,16-9}{24-17,32-25} {42-35,50-43}{58-51,66-59} || 6D || 0 || 0 || 0 || 0E
|-
| 16 || nec1d || I[01]%32F|I[01]%32F || 900Dh + {8-1,16-9}{24-17,32-25} {43-36,51-44}{59-52,67-60} || 6D || 0 || 0 || 0 || 0E
|-
| 17 || nec1e || I[01]%32FI[01]%32F || 900Eh + {9-2,17-10}{25-18,33-26} {43-36,51-44}{59-52,67-60} || 6D || 0 || 0 || 0 || 0E
|-
| 18 || nec2a || I[01]%32FJR || 900Ah + {8-1,16-9}{24-17,32-25} || 68 || 0 || 0 || 0 || 0E
|-
| 19 || nec2b || I[01]%32F || 900Bh + {9-2,17-10}{25-18,33-26} || 68 || 0 || 0 || 0 || 0E
|-
| 1A || nec2c || I[01]%32FI[01]%32F|R || 900Ch + {8-1,16-9}{24-17,32-25} {42-35,50-43}{58-51,66-59} || 68 || 0 || 0 || 0 || 0E
|-
| 1B || nec2d || I[01]%32F|I[01]%32F || 900Dh + {8-1,16-9}{24-17,32-25} {43-36,51-44}{59-52,67-60} || 68 || 0 || 0 || 0 || 0E
|-
| 1C || nec2e || |I[01]%32FI[01]%32F || 900Eh + {9-2,17-10}{25-18,33-26} {43-36,51-44}{59-52,67-60} || 68 || 0 || 0 || 0 || 0E
|-
| 1D || nec || I[01]%32%F|R || 9000h + {8-1}{16-9}{24-17}{32-25} || 6D || 0 || 0 || 0 || 0E
|-
| * || rc6m6a-24 || H1110{tT}0[01]%23R || 6001h + {8-14)}{15-22}{23-30} || 73 || 0 || ? || 0 || ?
|-
| ** || rc6m6a-32 || H1110{tT} 1[01]%31R || 6001h + {8-22}{23-30}{31-38} || 73 || 0 || ? || 0 || ?
|-
| *** || yamahanec || ?I[01]%32F|R || ?9001h + {8-1}{24-17}, + {!16-19}{132 -! 25} || ?6D || 0 || 0 || 0 || ?
|}

{| class="wikitable"
! dID !! bCh !! [i] !! aBurstSeq !! dID !! bCh !! [i] !! aBurstSeq !! dID !! bCh !! [i] !! aBurstSeq
|-
| 00 || R || 0 || -0CA0 || 02 || R || 0 || -0AA0 || 03 || 1 || 5 || 005B -0546
|-
| 00 || 0 || 1 || 0020 -0020 || 02 || S || 1 || -0080 || 04 || p || 0 || 0103 -AD01
|-
| 00 || 1 || 2 || -0020 0020 || 02 || 0 || 2 || 0020 -0020 || 04 || e || 1 || 0103 -47D5
|-
| 01 || H || 0 || 0060 -0020 || 02 || 1 || 3 || -0020 0020 || 04 || s || 2 || 0103 -1745
|-
| 01 || T || 1 || 0020 -0020 || 03 || R || 0 || 005B -C422 || 04 || r || 3 || 1010 -040C
|-
| 01 || t || 2 || -0020 0020 || 03 || 5 || 1 || 005B -1BC0 || 04 || 0 || 4 || 0103 -0309
|-
| 01 || 0 || 3 || -0010 0010 || 03 || 4 || 2 || 005B -1622 || 04 || 1 || 5 || 0103 -0103
|-
| 01 || 1 || 4 || 0010 -0010 || 03 || 3 || 3 || 005B -1083 || 04 || s$ || 6 || 1010 -081E
|-
| 01 || R || 5 || -0BC0 || 03 || 2 || 4 || 005B -0AE4 || 05 || r || 0 || 227B -1160
|-
| 05 || R || 1 || 022C -8FFA || 0A || R || 0 || 0006 -0857 || 10 || S || 1 || 0009 -58D2
|-
| 05 || S || 2 || 022C -6108 || 0A || 2 || 1 || 0006 -011A || 10 || 0 || 2 || 0009 -0F3E
|-
| 05 || T || 3 || 022C -4165 || 0A || 1 || 2 || 0006 -00BB || 10 || 1 || 3 || 0009 -0A2A
|-
| 05 || o || 4 || 022C -31AF || 0B || R || 0 || 0010 -0857 || 11,12 || R || 0 || 0006 -0841
|-
| 05 || U || 5 || 022C -2C13 || 0B || S || 1 || 0010 -0642 || 11,12 || S || 1 || 0006 -065B
|-
| 05 || 0 || 6 || 022C -0684 || 0B || 2 || 2 || 0010 -0112 || 11,12 || 2 || 2 || 0006 -011A
|-
| 05 || 1 || 7 || 022C -022C || 0B || 1 || 3 || 0010 -00B1 || 11,12 || 1 || 3 || 0006 -00BB
|-
| 05 || o$ || 8 || 227B -1160 || 0C || R || 0 || 0010 -059D || 13–1D, *** || I || 0 || 0157 -00AB
|-
| 06,07 || r || 0 || 00FC -347B || 0C || S || 1 || 0010 -0417 || 13–1D, *** || F || 1 || 0016 -05E7
|-
| 06,07 || a || 1 || 00FC -00FC || 0C || T || 2 || 0010 -02FB || 13–1D, *** || 1 || 2 || 0016 -0040
|-
| 06,07 || e || 2 || 00FC -007E || 0C || 2 || 3 || 0010 -0099 || 13–1D || 0 || 3 || 0016 -0015
|-
| 06,07 || t || 3 || 007E -347B || 0C || 1 || 4 || 0010 -0044 || 13,15,18,1A || R || 4 || 0157 -0055 0016 -0E3B
|-
| 06,07 || s || 4 || 007E -0274 || 0D || R || 0 || 0008 -4B7B || * ** || H || 0 || 0070 -0020
|-
| 06,07 || b || 5 || 007E -017A || 0D || S || 1 || 0008 -3A74 || * ** || T? || 1 || 0020 -0020
|-
| 06,07 || c || 6 || 007E -00FC || 0D || 0 || 2 || 0008 -0A2B || * ** || t || 2 || -0020 0020
|-
| 06,07 || d || 7 || 007E -007E || 0D || 1 || 3 || 0008 -06C3 || * ** || 0 || 3 || -0010 0010
|-
| 08,09 || P || 0 || 0019 -005A 0028 || 0D || s || 4 || 0008 -0515 || * ** || 1 || 4 || 0010 -0010
|-
| 08,09 || a || 1 || -0044 0024 || 0E || R || 0 || 0008 -2BAE || * || R || 5 || -0AB0
|-
| 08,09 || b || 2 || -0036 0012 -000E 0012 || 0E || S || 1 || 0008 -2104 || ** || R || 5 || -09B0
|-
| 08,09 || c || 3 || -0022 0012 -0022 0012 || 0E || 0 || 2 || 0008 -05CA || 10 || R || 0 || 0009 -74F3
|-
| 08,09 || d || 4 || -000E 0012 -0036 0012 || 0E || 1 || 3 || 0008 -03D9 || || || ||
|-
| 08,09 || r || 5 || -07FC || 0F || R || 0 || 0019 -024C || || || ||
|-
| 0F || 0 || 1 || 0019 -010A || 0F || 1 || 2 || 0019 -00AF || || || ||
|}

At the first table: 
dID – subformat, used at format 7000 and for connection with second table
zSystem – unused string, “brand”-like description of dID
zTemplate – template of logical structure of IR signal of this type (dID)
:<letters> and <numbers> - are references as bCh to second table, where they (with dID) point out to a concrete aBurstSeq
:| – delimits once sequence and repeat sequence parts
:[<chars>] – means any of suggested characters
:{<char1><char2>} – corresponds to toggle bit: at odd replaying of IR code of this type must be <char1>, at even – <char2>
:%<number> - means <number> of duplicates of previous character/term
:<nowiki>*</nowiki> - any number of any previously defined characters at [<chars>]
:<char>$ - strange 2-byte name for char, nothing else :)
:?, < - garbage that must be ignored :)
zMask – mask, correspondence between zTemplate and IR code at Fixed Size Template Based Formats. Be described at these formats. zMask is used while learning only.
:Hexadecimal word is wFmtID
:{<expression>} – means description of corresponded word from sCode
:<number> - means index at forming String Code for corresponded bit at sCode word
:<number1>-<number2> - means a range (inversed range) of these bounds – <number1>, <number1+(-)1>, …,
::<number2>
:!<number> – means index at String Code for logical negation of corresponded bit at sCode
dFrqDiv – carrier frequency divider. “-“ means high (>58KHz?) frequency, that is need to be analyzed (when learning) with another filter, I think, so “-“ must be ignored.
bU1, dU2, dU3, dU4 – additional class/format characteristics. I suppose, they are used by recognition routine, or as additional info, like index of developer, who encodes special code for this format/subformat :), and must be ignored at replaying/converting.

At the second table: 
dID – same as at the first table
bCh – means index (char) from zTemplate or String Code
[i] – means index to aBurstSeq from aCode (same as wCIdx) at Predefined Codes of Variable Length (7000)
aBurstSeq – analogue of burst pair with variable length – from 1 to 4 words. Positive words mean time when LED flashes, negative – when LED is off.

= Template Based Formats of Fixed Size (wFmtID = 5000, 5001, 6000, 9000, 9001, 900A, 900B, 900C, 900D, 900E) =

Template based formats of fixed size represent strongly defined IR signals of common brands. As a rule, IR signal, leaned at this format, is the only and “clean” (but I have trouble with RC9200 + Onkyo DVD – it learns its IR codes as 900A mistakenly). IR codes at this format are short, sCode can be 2, 3 or 4 words length, and every of this word means anything like “System”, “Command” or “Data” but that meanings are not essential for converting.

Now, the ranges of that codes:

5000 0000 0000 0001 0000 0000 – 5000 0000 0000 0001 001f 007f

5001 0000 0000 0002 0000 0000 0000 0000 – 5001 0000 0000 0002 001f 007f 003f 0000 
Note: it looks like erratum at firmware table, really zMask for dID = 02 must be 5001h + {4-8}{!2,10-15}{16-21}. This bug causes
a real brain pain: any RC5x code can not be learned by any Pronto! But replaying of these codes works OK, because zMask is not
used for replay.

6000 0000 0000 0001 0000 0000 – 6000 0000 0000 0001 00ff 00ff 
Note: [2] contains description of RC6 Mode 6A as format 6001 with toggle bit, as all other RC-formats. Currently software
represents that codes at format 0000 without toggle bit. I have inserted corresponded (obsolete?) entries * and ** to the end of
firmware tables from [2] for considerations of universality: 
(<nowiki>*</nowiki>subformat of 6001, where first argument (Customer Code) is in range of 0000..007f)

6001 0000 0000 0002 0000 0000 0000 0000 – 6001 0000 0000 0002 007f 00ff 00ff 0000 
(<nowiki>**</nowiki>subformat of 6001, where first argument is in range of 8000..ffff)

6001 0000 0000 0002 8000 0000 0000 0000 – 6001 0000 0000 0002 ffff 00ff 00ff 0000

9000 0000 0000 0002 0000 0000 0000 0000 – 9000 0000 0000 0002 00ff 00ff 00ff 00ff

900a 0000 0000 0001 0000 0000 – 900a 0000 0000 0001 ffff ffff 
Note: These codes represent most common (may be, after RC) IR signal type (32bits NEC). Usually it consist of 8bit device code, 8bit device code binary compliment, 8bit function code and 8bit function code binary compliment [3,4]. All Pronto models, except RC5200, RC-9200, TSU-6000, RU-970, USR-5 must learn this type of IR signals as 0000 006* 0022 0002 0157 …, and it works fine. New Pronto models can replay formats 900A to 900E, but recognition routine is inclined to learn all NEC IR signals as format 900A, that often results in fsults.

900b 0000 0000 0001 0000 0000 – 900b 0000 0000 0001 ffff ffff

900c 0000 0000 0002 0000 0000 0000 0000 – 900c 0000 0000 0002 ffff ffff ffff ffff

900d 0000 0000 0002 0000 0000 0000 0000 – 900d 0000 0000 0002 ffff ffff ffff ffff

900e 0000 0000 0002 0000 0000 0000 0000 – 900e 0000 0000 0002 ffff ffff ffff ffff

9001 0000 0000 0001 0000 0000 – 9001 0000 0000 0001 00ff 00ff

Note: format 9001 is supported only by RAV-2000, but absent in all tables. I can’t check it, and I hope that codes, described at [3,4] are the same, so I have inserted it to firmware tables as ***. 

For converting that codes to format 0000 I offer this procedure: 
* Obtaining String Code from zTemplate, zMask and source code
* Obtaining raw IR data by indexing from String Code
* Forming IR code at format 0000 from raw IR data

[[Image:Pronto-formats-7-converting.jpg]] 
''Picture 7: Converting IR code of template based format of fixed size into format 0000 '' 
Note: 0CE0 = -0020 (last “0” at String Code ) + -0CA0 (“R”) + -0020 (first “1”)

= Predefined code of variable length (wFmtID = 7000) =
This format is for representing IR signals that can not (yet) be easily encoded as predefined format of fixed size. The structure of this
code is described on sample - Grundig 7000 0088 0000 0007 0008 000b 0010 0000 0017 0001 0001 0001
0001 0001 0001 0001 0005 0044:

{| class="wikitable"
! offset !! size !! name !! type !! description !! sample
|-
| 0 || 1 || wFmtID || word, ID || Format ID = 7000 || 7000
|-
| 1 || 1 || wFrqDiv || word, dummy || Unused word || 0088
|-
| 2 || 1 || nOnceSeq || word, dummy || Dummy length || 0000
|-
| 3 || 1 || nRepeatSeq || word, dummy || Dummy length || 0007
|-
| 4 || 1 || wSubFmtID || word, ID || SubFormat ID (dID) || 0008
|-
| 5 || 1 || nCodeSeq || word, length || Length of aCode || 000B
|-
| 6 || nCodeSeq || aCode || array of wCIdx || Code. Every word point a word in String Code || 0010 0000 0017 0001 0001 0001 0001 0001 0001 0001 0005
|-
| 6+nCodeSeq || 0 or 1 || wRest || word, dummy || Unused word for compatibility, it is present if nCodeSeq is odd || 0044
|}

Also, nOnceSeq and nRepeatSeq must meet the condition (nOnceSeq + nRepeatSeq) * 2 = 2 + nCodeSeq + sizeOf( wRest
)
Converting procedure is the same as previous one except String Code obtaining, that I describe now: 
Character choosing to String Code depends on value of corresponded wCIdx from aCode: 
- if wCIdx < 0010, then corresponded bCh indexes from second firmware table dID bCh [i] , where dID = wSubFmtID and [i] = wCIdx 
- if wCIdx = 0010, then bCh = “|” 
- if wCIdx > 0010, then this char is toggle. On odd code (of this subformat) replaying bCh is equal (wCIdx – 14h)-th char of
corresponded zTemplate: bCh = zTemplate[ wCIdx – 14 ], where first index in zTemplate is 0. On even code replaying – next
char: bCh = zTemplate[ wCIdx – 13 ]:

[[Image:Pronto-formats-8-forming.jpg]] 
''Figure placeholder: Picture 8 — Forming String Code from 7000''

= Index to UDB (wFmtID = 8000) =
Some Pronto models (RAV-2000, USR-5, TSU-2000, TSU-6000, TSU-500, TSU-3000, RU-970, RU930) supports internal IR
database, others have no internal DB, but only software, and RC-3200 has no any databases:

'''Database availability'''
{| class="wikitable"
! model !! DB type !! file !! size
|-
| TS-1000, RU-890, RU-940 || IR database at ProntoEdit || rcir.mdb (Jet) || 360,448
|-
| TSU-2000, TSU-6000 || UDB || UDP_int.hex || 362,711
|-
| RU-970 || UDB || UDP_int.hex || 662,090
|-
| TSU-500 || UDB as part of || TSU500.dat (Jet) || 5,851,136
|-
| RU-930 || UDB as part of || RU930.dat (Jet) || 7,299,072
|-
| TSU-3000 || UDB || UDB_TSU3000.bin || 422,622
|-
| RC-5000/5000i/5200/9200 || IR database at TSS || rcir.mdb (Jet) || 978,944
|-
| RC-3200 || — || — || —
|-
| RAV-2000 || UDB || ww_udp.idb || 662,090
|-
| USR-5 || UDB || ww_udp.idb || 661,011
|}

This format is used for recall IR codes from real UDB. UDB has clear structure – all commands in it are indexed first by Device Type
(see tables); next – by Brand/Code Set and finally – by Function (depending on device type); it is really easy to custom. Accordingly,
structure of this format is systematic – code contains no IR data, only function – device type, brand and device function!
For example – code of “Power On” for Amp Yamaha, code set 1 - 8000 0000 0002 0000 000a 23f0 0002 0000:

Structure:
{| class="wikitable"
! offset !! size !! name !! type !! description !! sample
|-
| 0 || 1 || wFmtID || word, ID || Must be 8000 || 8000
|-
| 1 || 1 || wFrqDiv || word, dummy || Unused || 0000
|-
| 2 || 1 || nOnceSeq || word, dummy || Dummy length || 0002
|-
| 3 || 1 || nRepeatSeq || word, dummy || Dummy length || 0000
|-
| 4 || 1 || wDevType || word, index || Device type (000A = Amp) || 000A
|-
| 5 || 1 || wBrandCodeSet || word, index || Brand/Code Set (23F0 = Yamaha-1) || 23F0
|-
| 6 || 1 || wFunction || word, index || Function (0002 = Power On) || 0002
|-
| 7 || 1 || wRest || word, dummy || Padding to even words || 0000
|}

Fields wDevType, wBrandCodeSet and wFunction indexes corresponded list values from UDB:

Not all of the UDB codes (format 8000) are supported by all Pronto models, also, not all of the code combinations of this format are supported by any Pronto at all – UDBs differ from model to model!

It is not so hard to extract real IR codes from corresponded DB files, but it is easily to get them directly via TSS.

{| class="wikitable"
! wDevType !! description
|-
| 1 || A. proc
|-
| 2 || Cable
|-
| 3 || CD
|-
| ... || ...
|}

{| class="wikitable"
! wFunction !! description
|-
| 1 || Power off
|-
| 2 || Power on
|-
| 3 || Channel down
|-
| ... || ...
|}

= References =
There are a number of articles about IR formats applied to Pronto on the internet:
# Daniel Tonks “Unofficial Philips Pronto & Marantz RC5000 FAQ”, http://www.remotecentral.com
# Marcel Majoor “Communicating with the Pronto”, http://home.hccnet.nl/m.majoor
# Barry Gordon “ProntoEdit’s IR Display Format”, http://the-gordons.net:8080/, http://www.remotecentral.com/features/irdisp1.htm
# Barry Shaw, Rob Crowe, Andrea Whitlock “Yamaha extended IR codes”, http://darius.mobius-soft.com/~andrea/
# Stewart Allen, “The CCF file format”, http://giantlaser.com/tonto/

----
''Author note:'' Please excuse my poor English. For questions about Pronto IR you can reach me at eoulianov@hotbox.ru, and I will try to answer more clearly :)

Infrared Signals

2025-11-22T23:52:35Z

The Robman:

The IR signal emitted by the standard household remote is a series of ON and OFF bleeps of the infrared light, the frequency of light used does not vary much, many remotes use a signal of approximately 40KHz. The message is carried in the time the light is on or off. These on and off combinations can be translated into a binary code which in turn can be translated into decimal numbers. These numbers are the device and command codes. First off, the device code in the signal must match the pre-programmed device code in your equipment, and if it does the equipment will follow the instructions that have been pre-programmed for the command number included in the signal.

There are two primary formats of IR signal. The most common format is known as '''Pulse Width Method''', this is a format where either the ON or OFF time is constant, and the message is carried in the variations of the non-constant time. The second format is known as '''Bi-Phase''' or RC-5 and is primarily used by Philips. In this format both the on and off times vary, the light is sampled at a fixed rate and it's the state of the light that decides if a binary ONE or ZERO is present. Usually if the light is ON, it means it's a ONE and if it's off it means it's a ZERO.

This was just a very brief overview. There are two excellent documents about each format, please read them to understand more. Both of these documents refer to the Pronto HEX format, this is the way IR signals are displayed by the Philips Pronto. The Pronto is a universal remote that can be hooked up to a PC and used to load IR signals up to the PC for examination.

{|class="wikitable"
| '''[[Infrared 101]]'''
| - by Rob Crowe
|-
| '''[[Pulse Width Method]]'''
| - by Barry Gordon
|-
| '''[[Bi-Phase Method]]'''
| - by Guy Kuo
|-
| '''[[Infrared Protocol Primer]]'''
| - by Vicky Getz
|-
| '''[[Pronto IR Formats]]'''
| - by Evgueni Oulianov
|-
| '''[[Working With Pronto Hex]]'''
| - by Vicky Getz
|}

Talk:Pronto IR Formats

2025-11-22T23:51:25Z

The Robman: Created page with "This wiki article was transcribed from the original article below: https://www.hifi-remote.com/forums/dload.php?action=file&file_id=6309"

This wiki article was transcribed from the original article below: 
https://www.hifi-remote.com/forums/dload.php?action=file&file_id=6309

Pronto IR Formats

2025-11-22T22:58:03Z

The Robman: /* Index to UDB (wFmtID = 8000) */

= Pronto IR Formats =

== Preamble ==
This article describes in detail the formats of IR code filing for Pronto and ProntoPro models (RU-890, RU-940, RU-970, TS-1000, TSU-2000, TSU-6000, RC-5000, RC-5000i, RC-5200, RC-9200, RAV-2000, USR-5). It is supposed to be interesting for:
* those, who want to clean up his IR codes — in order to find out what all the numbers in field “IR code:” mean and for troubleshooting;
* those, who want to develop an IR code converter into other driver/configuration formats — Crestron (.IR), AMX (.IRL), Xantech (.PAL), Niles (.LIN), ADI Ocelot (.LIR), RedRat2 (.TXT), Denon RC-8000 (.RCX), ProntoNeo (.NCF), ProntoNG (.PCF) etc, as a manual of most popular and complicated IMHO IR code format.

It is advisable for you to have a notion of modulated IR signals transmission [1], but I will also coin that terms for completeness. References to some concepts can be earlier than the description of theirs, so as not to touch on same concept doubly. I am not going to mention the details of realization which is not essential for the description of the format.

== Acknowledgments ==
I would like to thank Daniel Tonks, Stewart Allen, Barry Gordon, Marcel Majoor, Steven Keyser, Bertrand Gillis, Loran Richardson, Bernard Barrier, Barry Shaw, Rob Crowe, Andrea Whitlock, those, who reply at forums — for help and support, my wife — for indulgence and star50fiveoh — for sober intolerance to this article's subject :)

== Warning ==
Standard warning about “… your own risk” is in effect.

== Buttons, signals, commands and codes ==
In order to avoid involving in terms, I specify them precisely:

[[Image:Pronto-formats-buttons.jpg]] 
''Figure placeholder: Picture 1 — Interaction of buttons, IR signals, commands and IR codes''

The button, IR signal, command and IR code are not corresponding mutually:
* the same button can produce different IR signals (see Toggle Codes);
* different IR signals can be recognized by decoder as same command (see Clean and Dirty Codes);
* the same IR signal can be encoded as a number of IR codes in different formats.

== Modulated IR signal ==
For some reasons, mainly for simplicity and interference immunity, almost all IR signals, currently used to IR translation, have the same structure. IR transmitter includes a square-wave generator (oscillator), coder and IR LED. All the time of transfer oscillator generates square impulses with fixed (for this remote) carrier frequency; depending on pressed button (and, may be, remote mode), coder forms a code of command — sequence of conventional logical 0s and 1s; IR LED flashes this command modulated by generated impulses.

[[Image:Pronto-formats-2-IR.jpg]] 
''Figure placeholder: Picture 2 — IR LED replays modulated IR signal''

Any modulated IR signal can be fully characterized via carrier frequency and the sequence of period amounts when emitting is on and off. For picture 2 this sequence is 6–2–4–2–4–…

Sometimes remote emits the signal all the time until the button such as VOLUME+ will released. Another way it flashes once per press, or first, once emitted signal is not the same that repeating one, followed it. So, it is convenient to suppose that in the general way IR signal consists of once part, the start emitting sequence and repeat part. For example, endless IR signal 6-2-4-2-4-6-6-3-3-12-6-3-3-12- has the once sequence 6-2-4-2-4-6 and repeat sequence 6-3-3-12: 6-2-4-2-4-6 | 6-3-3-12. All currently used IR signals can be represented either as a union of once and repeat sequences or as the only once or only repeating sequence.

[[Image:Pronto-formats-3-IR.jpg]] 
''Figure placeholder: Picture 3 — Cutting IR signal into once sequence and repeat sequence''

Usually, IR codes, describing IR signal this way, are not so long. If learned IR code is not an air conditioner code, it can be completely go in “IR code:” field at ProntoEdit.

In the most of cases carrier frequencies are nearby 35KHz, but you will certainly be lucky enough to try a remote with 175KHz, 345KHz, 455KHz or 1.1MHz.

== “Clean” and “dirty” codes ==
[1: “Unclean” and “clean” IR commands (Working With Prontoedit: Learning & Infrared)]

It is not necessary to replay IR signal precisely, IR receiver will “identify” received IR signal as correct command, if it looks like real command adequately, say, carrier frequency and burst pairs’s lengths differ from original IR signal less than for 10%. I.e. there is precise, original IR signal for every command, may be not replay-able for Pronto, and also many IR signals that Pronto can replay and IR receiver can recognize as that command. The codes of those signals may have different lengths, and the shortest one is “clean” code, and the all other codes are “dirty” and very “dirty”.

Reasons to prefer “clean” codes:
* IR signal of “clean” IR code is more recognizable by IR receiver
* some “dirty” IR codes can lead IR receiver astray or halt it
* “clean” code is shorter, and replay of it takes less time in macros
* you can visually check “clean” IR code’s accuracy — the lengths of every “clean” IR codes per remote are the same, except, may be, buttons like VOLUME+
* “clean” code is more convenient to analyzing, in order to guess a discrete command, absent at this remote
* using of “clean” IR codes stirs ambitions of punctual Prontoyers

The ordinal way to obtain “clean” IR code is cutting from existing one [1]. Sometimes it is useful to develop special software — generator of all concrete type IR codes — in order to “discover” all possible commands, supported by that device, including those absent at remotes.

Note: There is no difference in IR learning to Pronto standalone or to computer via Pronto, but sometimes this process is faulted due a communication error.

== Toggle IR codes ==
[1: Why won’t my buttons work twice in a row? (Working With Prontoedit: Learning & Infrared)]

It is necessary not to mix up toggle IR codes and toggle IR commands. Toggle Command is a command with toggle function such as standby/on, see TOAD at [1]. In contrast to that, Toggle IR Code contains as minimal 1 toggle bit, see RC5 at [2].

There are many possible troubles and noises at IR transfer — sun, fluorescent lamps, interference with another IR transfer, dust, pets, household and tremor of hesitating hand, holding remote. First two troubles can be cured by signal modulation. Other problems, concerning temporary obstacle, are solved logically. Commonly they use two different IR signals per button — one for odd presses and another for even. As a rule, these codes differ in one or two logical bits (“toggle” bit or “parity”), and both of them encode the same command. When IR decoder receives IR signal such type, it ignores the same signals (or signals with the same “parity” bit) received twice, in order to avoid taking noise as double click.

Pronto IR learning procedure uses the only button pressing, and because of it Pronto can detect as toggle codes only codes of some predefined types, that look like known codes, for example, RC5. When Pronto replays these codes, it emits in turn odd and even IR signals for every type of predefined code format (and if existing, subformat). So repeating the same alias for “long button press” in macro is not effective for toggle codes; it is necessary to convert this code to format 0000 to do it.

If Pronto learns real toggle codes as ordinary, learn all codes in the same parity, and only the “blank” command (that does nothing, if it exists at remote) — in opposite parity, and give any Pronto button two actions — odd real command and even “blank” [1].

== Pronto IR code filling formats ==
[1: Type of code (Working With Prontoedit: Learning & Infrared)]

IR codes are kept in Pronto and in CCFs in bytes (as all data), but Pronto software uses two-byte hexadecimal words delimited by spaces at IR code view (editBox):
<code>0000 0070 0003 0002 0006 0002 0004 0002 0004 0006 0006 0003 0003 000C</code>

I will write all sizes and offsets in 16-bit words and all numbers in hex, if not specified otherwise. First word — '''wFmtID''' — identifies IR format.

Supported formats:
* 0000 — raw oscillated code
* 0100 — raw unmodulated code
* 5000 — RC5
* 5001 — RC5x
* 6000 — RC6 Mode 0
* 7000 — predefined code of variable length
* 8000 — index to UDB
* 9000, 900A, 900B, 900C, 900D, 900E — NEC
* 9001 — basic mode YAMAHA NEC code

[[Image:Pronto-formats-4-hierarchy.jpg]] 
''Figure placeholder: Picture 4 — hierarchy of Pronto IR formats''

= Raw formats (wFmtID = 0000 or 0100) =
They are simple, basic, most commonly used formats. Almost all IR signals can be represented (exactly or cognitive) either in 0000 or 0100 format. There is no way to encode toggle IR codes at these formats, but separately, odd and even IR code can be converted from toggle form to 0000 format.

== Raw oscillated code (wFmtID = 0000) ==
This is the format that is often implied, when they say “Pronto IR format”. It contains lengths while LED flashes and while
LED is off in carrier periods (“burst pairs”) in two optional parts - once and repeat sequences.

For example, code from pic.2 and 3 will encoded in this format as 0000 0070 0003 0002 0006 0002 0004 0002 0004
0006 0006 0003 0003 000С, where:

{| class="wikitable"
! offset !! size !! name !! type !! description !! sample
|-
| 0 || 1 || wFmtID || word, ID || Format ID. Must be 0000 || 0000
|-
| 1 || 1 || wFrqDiv || word, positive || Carrier frequency divider || 0070
|-
| 2 || 1 || nOnceSeq || word, length || Number of burst pairs at once sequence || 0003
|-
| 3 || 1 || nRepeatSeq || word, length || Number of burst pairs at repeat sequence || 0002
|-
| 4 || 2*nOnceSeq || aOnceSeq || array of rBurstPair || Once sequence || 0006 0002 0004 0002 0004 0006
|-
| 4+2*nOnceSeq || 2*nRepeatSeq || aRepeatSeq || array of rBurstPair || Repeat sequence || 0006 0003 0003 000C
|}

and rBurstPair consists of:

{| class="wikitable"
! offset !! size !! name !! type !! description !! sample
|-
| 0 || 1 || wLEDflash || word, positive || Periods when LED flashes with carrier || 0006
|-
| 1 || 1 || wLEDoff || word, positive || Periods when LED is off || 0002
|}

Details:
* wFmtID: word = 0000, Format ID
* wFrqDiv: word in range 0001..FFFF, wFrqDiv = 4,145146 MHz / <signal carrier>. So wFrqDiv = 0001 corresponds to signal carrier » 4,1 MHz, and wFrqDiv =FFFF ~ 63Hz. I have measured this constant indirectly and have obtained 4,1455±0,0006 MHz, which is close enough with magical number 4,145146 [2], and far enough from 4,194304 [5], but I can’t locate quartz oscillator with this nominal at catalogues.
* nOnceSeq: word in range 0000..0100, is equal to amount of burst pairs at once sequence
* nRepeatSeq: word in range 0000..0100, is equal to amount of burst pairs at repeat sequence
* wLEDflash: word in range 0001..FFFF, is amount of carrier frequency periods when LED flashes every first half-period and turned off for the last half-period
* wLEDoff: word in range 0001..FFFF, is amount of carrier frequency periods when the LED is off

Next picture will dispel all residuary questions:

[[Image:Pronto-formats-5-correspondence.jpg]] 
''Figure placeholder: Picture 5 — correspondence between IR-signal and IR-code at format 0000''

== Raw unmodulated code (wFmtID = 0100) ==
Same structure as 0000, but LED is continuously on for the first word of the burst pair (no carrier):

[[Image:Pronto-formats-6-difference.jpg]] 
''Figure placeholder: Picture 6 — difference between IR signals for 0000 vs 0100''

Differences:
{| class="wikitable"
! offset !! size !! name !! type !! description !! sample
|-
| 0 || 1 || wFmtID || word, ID || Format ID. Must be 0100 || 0100
|}

aBurstPair consists of:

{| class="wikitable"
! offset !! size !! name !! type !! description !! sample
|-
| 0 || 1 || wLEDon || word, positive || Periods when LED is on || 0006
|-
| 1 || 1 || wLEDoff || word, positive || Periods when LED is off || 0002
|}

This format completes format 0000 to universal description of all raw IR signals, but codes at format 0100 are rare – it is
exposed to sun light and other IR noises. I have learned only 2 devices with these codes – noname drape drive and Dish Satellite
Positioner. Nevertheless, sometimes it is useful to use IR signal without carrier, for example, for Sony Contol-S: you can replace an
IR probe at RX-77 to ordinal jack, change 0000 to 0100 at IR codes, and your Sony device will be controlled by Control-S. Some
other systems also support IR signals without carrier, like Crestron’s CstmFreq value = 43.

= Predefined formats (wFmtID = 5000, 5001, 6000, 7000, 8000, 9000, 9001, 900A, 900B, 900C, 900D, 900E) =
There are a number of additional, predefined IR formats, supported by some reasons. They can’t describe all IR signals, every type/subtype of this format represents only IR codes with specific structure, for custom “brand”. Also, we need additional data tables to replay these signals. These predefined formats are more compact than corresponding raw IR codes and, as a rule, simple and “clean”. I.e., if you learn IR as 5000 or 7000 and it is not a bug, then that and all other IR signals from this remote must be codes of this type.

Predefined formats have different structure, but for the reason of compatibility with format 0000, fields wFrqDiv, nOnceSeq, nRepeatSeq leave as dummy, so that code “looks” the same. aOnceSeq and aRepeatSeq are replaced with sCode, that consist real code info. Also, nOnceSeq and nRepeatSeq must meet the condition (nOnceSeq + nRepeatSeq) * 2 = sizeOf(sCode):

Template header:
{| class="wikitable"
! offset !! size !! name !! type !! description !! sample
|-
| 0 || 1 || wFmtID || word, ID || Format ID || 5000
|-
| 1 || 1 || wFrqDiv || word, dummy || Unused word for compatibility || 0000
|-
| 2 || 1 || nOnceSeq || word, dummy || Dummy code length || 0000
|-
| 3 || 1 || nRepeatSeq || word, dummy || Dummy code length || 0001
|-
| 4 || (nOnceSeq+nRepeatSeq)*2 || sCode || structure || Predefined code || 0000 0000
|}

Not all of the predefined formats are supported by any Pronto model – here a table of compatibility is:

{| class="wikitable"
! wFmtID !! RU-890/940/TS-1000/RC-5000/5000i !! TSU-2000 !! RC-5200/9200 !! TSU-6000/RU-970/USR-5 !! RAV-2000
|-
| 0000, 0100, 5000, 5001, 6000, 7000 || ✔ || ✔ || ✔ || ✔ || ✔
|-
| 8000 || || ✔ || || ✔ || ✔
|-
| 9000 || || || ✔ || ✔ || ✔
|-
| 9001 || || || || || ✔
|-
| 900A–900E || || || ✔ || ✔ ||
|}

Also, RC-3200 does not support all of this formats directly (except 0000), but RC-3200 Setup converts codes 0100, 5000, 5001 and 6000 codes into format 0000 automatically, and this feature can be used from elsewhere!

Note: 0000 format used by RC-3200 is extended by including support of unmodulated IR signals with special value of wFrqDiv = 0001.

When I describe these formats, I will translate them to format 0000, in anticipation of this converter is already exist.

= Template based formats (wFmtID = 5000, 5001, 6000, 7000, 9000, 9001, 900A, 900B, 900C, 900D, 900E) =
Template based formats are used for memory saving, for representing toggle IR codes, and for encoding IR signals with high
carrier frequency.

Segment SYS at Pronto Firmware contains 2 tables for encoding/decoding IR codes these types:

== SYS segment tables ==
{| class="wikitable"
! dID !! zSystem !! zTemplate !! zMask !! dFrqDiv !! bU1 !! dU2 !! dU3 !! dU4
|-
| 00 || rc5 || 1[01]{01}[01]%11R || 5000h + {4-8}{12,9-14} || 73 || 0 || 2 || 0 || 0A
|-
| 01 || rc6m0 || H1000ftT}[01]%16R || 6000h + {7-14}{15-22} || 73 || 0 || 0 || 0 || 0A
|-
| 02 || rc5e || 1 01]{01} [01]%5S[01]%12R || 5001h + {4-8}{12,10-15}{15-20} || 73 || 0 || 3 || 0 || 0A
|-
| 03 || b&o || 115[1234]*R?|<3[12345]* || 7000h || -09 || 0 || 5 || 0 || 14
|-
| 04 || kenwood || s$[01]%32e|rp || 7000h || -09 || 0 || 2 || 1 || 14
|-
| 05 || pioneer || o$[01]%32[RSTUo] r[01rRSTUo]* || 7000h || -04 || 0 || 4 || 1 || 14
|-
| 06 || ehrep || s[abcderst]%4[abcderst]* |s[abcderst]%4[abcderst]* || 7000h || -0C || 0 || 4 || 0 || 14
|-
| 07 || ehonce || s[abcderst]%4[abcderst]* || 7000h || -0C || 0 || 4 || 0 || 14
|-
| 08 || grundig 16ac || P{ac} [abcd]%7r || 7000h || 88 || 0 || 0 || 0 || 06
|-
| 09 || grundig 16bd || P{bd}[abcd]%7r || 7000h || 88 || 0 || 0 || 0 || 06
|-
| 0A || thomson1 || 2{12}[12]%9R || 7000h || 7C || 0 || 1 || 0 || 0E
|-
| 0B || thomson2 || {12}{12}[12]%9[RS] || 7000h || 7C || 0 || -1 || 0 || 0F
|-
| 0C || thomson3 || [12]%4{12}[12]%7[RST] || 7000h || 7C || 0 || -1 || 0 || 10
|-
| 0D || ferguson || s%2(01}[01]%9[RS] || 7000h || -0C || 1 || 4 || 0 || 0D
|-
| 0E || telefunken || (01} {01}[01]%9[RS || 7000h || -18 || 1 || -1 || 0 || 0E
|-
| 0F || echostar || T01]%5R || 7000h || 42 || 0 || -1 || 0 || 07
|-
| 10 || saba || (01}{01}[01]%9[RS || 7000h || -08 || 1 || -1 || 0 || 0E
|-
| 11 || crown || 2{12}[12]%9[RS] || 7000h || 6D || 0 || 2 || 0 || 0E
|-
| 12 || seleco || 2(12}[12]%9[RS || 7000h || 63 || 0 || 2 || 0 || 0E
|-
| 13 || nec1a || I[01]%32F|R || 900Ah + {8-1,16-9)}{24-17,32-25} || 6D || 0 || 0 || 0 || 0E
|-
| 14 || nec1b || I[01]%32F || 900Bh + {9-2,17-10}{25-18,33-26} || 6D || 0 || 0 || 0 || 0E
|-
| 15 || nec1c || I[01]%32FI[01]%32F|R || 900Ch + {8-1,16-9}{24-17,32-25} {42-35,50-43}{58-51,66-59} || 6D || 0 || 0 || 0 || 0E
|-
| 16 || nec1d || I[01]%32F|I[01]%32F || 900Dh + {8-1,16-9}{24-17,32-25} {43-36,51-44}{59-52,67-60} || 6D || 0 || 0 || 0 || 0E
|-
| 17 || nec1e || I[01]%32FI[01]%32F || 900Eh + {9-2,17-10}{25-18,33-26} {43-36,51-44}{59-52,67-60} || 6D || 0 || 0 || 0 || 0E
|-
| 18 || nec2a || I[01]%32FJR || 900Ah + {8-1,16-9}{24-17,32-25} || 68 || 0 || 0 || 0 || 0E
|-
| 19 || nec2b || I[01]%32F || 900Bh + {9-2,17-10}{25-18,33-26} || 68 || 0 || 0 || 0 || 0E
|-
| 1A || nec2c || I[01]%32FI[01]%32F|R || 900Ch + {8-1,16-9}{24-17,32-25} {42-35,50-43}{58-51,66-59} || 68 || 0 || 0 || 0 || 0E
|-
| 1B || nec2d || I[01]%32F|I[01]%32F || 900Dh + {8-1,16-9}{24-17,32-25} {43-36,51-44}{59-52,67-60} || 68 || 0 || 0 || 0 || 0E
|-
| 1C || nec2e || |I[01]%32FI[01]%32F || 900Eh + {9-2,17-10}{25-18,33-26} {43-36,51-44}{59-52,67-60} || 68 || 0 || 0 || 0 || 0E
|-
| 1D || nec || I[01]%32%F|R || 9000h + {8-1}{16-9}{24-17}{32-25} || 6D || 0 || 0 || 0 || 0E
|-
| * || rc6m6a-24 || H1110{tT}0[01]%23R || 6001h + {8-14)}{15-22}{23-30} || 73 || 0 || ? || 0 || ?
|-
| ** || rc6m6a-32 || H1110{tT} 1[01]%31R || 6001h + {8-22}{23-30}{31-38} || 73 || 0 || ? || 0 || ?
|-
| *** || yamahanec || ?I[01]%32F|R || ?9001h + {8-1}{24-17}, + {!16-19}{132 -! 25} || ?6D || 0 || 0 || 0 || ?
|}

{| class="wikitable"
! dID !! bCh !! [i] !! aBurstSeq !! dID !! bCh !! [i] !! aBurstSeq !! dID !! bCh !! [i] !! aBurstSeq
|-
| 00 || R || 0 || -0CA0 || 02 || R || 0 || -0AA0 || 03 || 1 || 5 || 005B -0546
|-
| 00 || 0 || 1 || 0020 -0020 || 02 || S || 1 || -0080 || 04 || p || 0 || 0103 -AD01
|-
| 00 || 1 || 2 || -0020 0020 || 02 || 0 || 2 || 0020 -0020 || 04 || e || 1 || 0103 -47D5
|-
| 01 || H || 0 || 0060 -0020 || 02 || 1 || 3 || -0020 0020 || 04 || s || 2 || 0103 -1745
|-
| 01 || T || 1 || 0020 -0020 || 03 || R || 0 || 005B -C422 || 04 || r || 3 || 1010 -040C
|-
| 01 || t || 2 || -0020 0020 || 03 || 5 || 1 || 005B -1BC0 || 04 || 0 || 4 || 0103 -0309
|-
| 01 || 0 || 3 || -0010 0010 || 03 || 4 || 2 || 005B -1622 || 04 || 1 || 5 || 0103 -0103
|-
| 01 || 1 || 4 || 0010 -0010 || 03 || 3 || 3 || 005B -1083 || 04 || s$ || 6 || 1010 -081E
|-
| 01 || R || 5 || -0BC0 || 03 || 2 || 4 || 005B -0AE4 || 05 || r || 0 || 227B -1160
|-
| 05 || R || 1 || 022C -8FFA || 0A || R || 0 || 0006 -0857 || 10 || S || 1 || 0009 -58D2
|-
| 05 || S || 2 || 022C -6108 || 0A || 2 || 1 || 0006 -011A || 10 || 0 || 2 || 0009 -0F3E
|-
| 05 || T || 3 || 022C -4165 || 0A || 1 || 2 || 0006 -00BB || 10 || 1 || 3 || 0009 -0A2A
|-
| 05 || o || 4 || 022C -31AF || 0B || R || 0 || 0010 -0857 || 11,12 || R || 0 || 0006 -0841
|-
| 05 || U || 5 || 022C -2C13 || 0B || S || 1 || 0010 -0642 || 11,12 || S || 1 || 0006 -065B
|-
| 05 || 0 || 6 || 022C -0684 || 0B || 2 || 2 || 0010 -0112 || 11,12 || 2 || 2 || 0006 -011A
|-
| 05 || 1 || 7 || 022C -022C || 0B || 1 || 3 || 0010 -00B1 || 11,12 || 1 || 3 || 0006 -00BB
|-
| 05 || o$ || 8 || 227B -1160 || 0C || R || 0 || 0010 -059D || 13–1D, *** || I || 0 || 0157 -00AB
|-
| 06,07 || r || 0 || 00FC -347B || 0C || S || 1 || 0010 -0417 || 13–1D, *** || F || 1 || 0016 -05E7
|-
| 06,07 || a || 1 || 00FC -00FC || 0C || T || 2 || 0010 -02FB || 13–1D, *** || 1 || 2 || 0016 -0040
|-
| 06,07 || e || 2 || 00FC -007E || 0C || 2 || 3 || 0010 -0099 || 13–1D || 0 || 3 || 0016 -0015
|-
| 06,07 || t || 3 || 007E -347B || 0C || 1 || 4 || 0010 -0044 || 13,15,18,1A || R || 4 || 0157 -0055 0016 -0E3B
|-
| 06,07 || s || 4 || 007E -0274 || 0D || R || 0 || 0008 -4B7B || * ** || H || 0 || 0070 -0020
|-
| 06,07 || b || 5 || 007E -017A || 0D || S || 1 || 0008 -3A74 || * ** || T? || 1 || 0020 -0020
|-
| 06,07 || c || 6 || 007E -00FC || 0D || 0 || 2 || 0008 -0A2B || * ** || t || 2 || -0020 0020
|-
| 06,07 || d || 7 || 007E -007E || 0D || 1 || 3 || 0008 -06C3 || * ** || 0 || 3 || -0010 0010
|-
| 08,09 || P || 0 || 0019 -005A 0028 || 0D || s || 4 || 0008 -0515 || * ** || 1 || 4 || 0010 -0010
|-
| 08,09 || a || 1 || -0044 0024 || 0E || R || 0 || 0008 -2BAE || * || R || 5 || -0AB0
|-
| 08,09 || b || 2 || -0036 0012 -000E 0012 || 0E || S || 1 || 0008 -2104 || ** || R || 5 || -09B0
|-
| 08,09 || c || 3 || -0022 0012 -0022 0012 || 0E || 0 || 2 || 0008 -05CA || 10 || R || 0 || 0009 -74F3
|-
| 08,09 || d || 4 || -000E 0012 -0036 0012 || 0E || 1 || 3 || 0008 -03D9 || || || ||
|-
| 08,09 || r || 5 || -07FC || 0F || R || 0 || 0019 -024C || || || ||
|-
| 0F || 0 || 1 || 0019 -010A || 0F || 1 || 2 || 0019 -00AF || || || ||
|}

At the first table: 
dID – subformat, used at format 7000 and for connection with second table
zSystem – unused string, “brand”-like description of dID
zTemplate – template of logical structure of IR signal of this type (dID)
:<letters> and <numbers> - are references as bCh to second table, where they (with dID) point out to a concrete aBurstSeq
:| – delimits once sequence and repeat sequence parts
:[<chars>] – means any of suggested characters
:{<char1><char2>} – corresponds to toggle bit: at odd replaying of IR code of this type must be <char1>, at even – <char2>
:%<number> - means <number> of duplicates of previous character/term
:<nowiki>*</nowiki> - any number of any previously defined characters at [<chars>]
:<char>$ - strange 2-byte name for char, nothing else :)
:?, < - garbage that must be ignored :)
zMask – mask, correspondence between zTemplate and IR code at Fixed Size Template Based Formats. Be described at these formats. zMask is used while learning only.
:Hexadecimal word is wFmtID
:{<expression>} – means description of corresponded word from sCode
:<number> - means index at forming String Code for corresponded bit at sCode word
:<number1>-<number2> - means a range (inversed range) of these bounds – <number1>, <number1+(-)1>, …,
::<number2>
:!<number> – means index at String Code for logical negation of corresponded bit at sCode
dFrqDiv – carrier frequency divider. “-“ means high (>58KHz?) frequency, that is need to be analyzed (when learning) with another filter, I think, so “-“ must be ignored.
bU1, dU2, dU3, dU4 – additional class/format characteristics. I suppose, they are used by recognition routine, or as additional info, like index of developer, who encodes special code for this format/subformat :), and must be ignored at replaying/converting.

At the second table: 
dID – same as at the first table
bCh – means index (char) from zTemplate or String Code
[i] – means index to aBurstSeq from aCode (same as wCIdx) at Predefined Codes of Variable Length (7000)
aBurstSeq – analogue of burst pair with variable length – from 1 to 4 words. Positive words mean time when LED flashes, negative – when LED is off.

= Template Based Formats of Fixed Size (wFmtID = 5000, 5001, 6000, 9000, 9001, 900A, 900B, 900C, 900D, 900E) =

Template based formats of fixed size represent strongly defined IR signals of common brands. As a rule, IR signal, leaned at this format, is the only and “clean” (but I have trouble with RC9200 + Onkyo DVD – it learns its IR codes as 900A mistakenly). IR codes at this format are short, sCode can be 2, 3 or 4 words length, and every of this word means anything like “System”, “Command” or “Data” but that meanings are not essential for converting.

Now, the ranges of that codes:

5000 0000 0000 0001 0000 0000 – 5000 0000 0000 0001 001f 007f

5001 0000 0000 0002 0000 0000 0000 0000 – 5001 0000 0000 0002 001f 007f 003f 0000 
Note: it looks like erratum at firmware table, really zMask for dID = 02 must be 5001h + {4-8}{!2,10-15}{16-21}. This bug causes
a real brain pain: any RC5x code can not be learned by any Pronto! But replaying of these codes works OK, because zMask is not
used for replay.

6000 0000 0000 0001 0000 0000 – 6000 0000 0000 0001 00ff 00ff 
Note: [2] contains description of RC6 Mode 6A as format 6001 with toggle bit, as all other RC-formats. Currently software
represents that codes at format 0000 without toggle bit. I have inserted corresponded (obsolete?) entries * and ** to the end of
firmware tables from [2] for considerations of universality: 
(<nowiki>*</nowiki>subformat of 6001, where first argument (Customer Code) is in range of 0000..007f)

6001 0000 0000 0002 0000 0000 0000 0000 – 6001 0000 0000 0002 007f 00ff 00ff 0000 
(<nowiki>**</nowiki>subformat of 6001, where first argument is in range of 8000..ffff)

6001 0000 0000 0002 8000 0000 0000 0000 – 6001 0000 0000 0002 ffff 00ff 00ff 0000

9000 0000 0000 0002 0000 0000 0000 0000 – 9000 0000 0000 0002 00ff 00ff 00ff 00ff

900a 0000 0000 0001 0000 0000 – 900a 0000 0000 0001 ffff ffff 
Note: These codes represent most common (may be, after RC) IR signal type (32bits NEC). Usually it consist of 8bit device code, 8bit device code binary compliment, 8bit function code and 8bit function code binary compliment [3,4]. All Pronto models, except RC5200, RC-9200, TSU-6000, RU-970, USR-5 must learn this type of IR signals as 0000 006* 0022 0002 0157 …, and it works fine. New Pronto models can replay formats 900A to 900E, but recognition routine is inclined to learn all NEC IR signals as format 900A, that often results in fsults.

900b 0000 0000 0001 0000 0000 – 900b 0000 0000 0001 ffff ffff

900c 0000 0000 0002 0000 0000 0000 0000 – 900c 0000 0000 0002 ffff ffff ffff ffff

900d 0000 0000 0002 0000 0000 0000 0000 – 900d 0000 0000 0002 ffff ffff ffff ffff

900e 0000 0000 0002 0000 0000 0000 0000 – 900e 0000 0000 0002 ffff ffff ffff ffff

9001 0000 0000 0001 0000 0000 – 9001 0000 0000 0001 00ff 00ff

Note: format 9001 is supported only by RAV-2000, but absent in all tables. I can’t check it, and I hope that codes, described at [3,4] are the same, so I have inserted it to firmware tables as ***. 

For converting that codes to format 0000 I offer this procedure: 
* Obtaining String Code from zTemplate, zMask and source code
* Obtaining raw IR data by indexing from String Code
* Forming IR code at format 0000 from raw IR data

[[Image:Pronto-formats-7-converting.jpg]] 
''Picture 7: Converting IR code of template based format of fixed size into format 0000 '' 
Note: 0CE0 = -0020 (last “0” at String Code ) + -0CA0 (“R”) + -0020 (first “1”)

= Predefined code of variable length (wFmtID = 7000) =
This format is for representing IR signals that can not (yet) be easily encoded as predefined format of fixed size. The structure of this
code is described on sample - Grundig 7000 0088 0000 0007 0008 000b 0010 0000 0017 0001 0001 0001
0001 0001 0001 0001 0005 0044:

{| class="wikitable"
! offset !! size !! name !! type !! description !! sample
|-
| 0 || 1 || wFmtID || word, ID || Format ID = 7000 || 7000
|-
| 1 || 1 || wFrqDiv || word, dummy || Unused word || 0088
|-
| 2 || 1 || nOnceSeq || word, dummy || Dummy length || 0000
|-
| 3 || 1 || nRepeatSeq || word, dummy || Dummy length || 0007
|-
| 4 || 1 || wSubFmtID || word, ID || SubFormat ID (dID) || 0008
|-
| 5 || 1 || nCodeSeq || word, length || Length of aCode || 000B
|-
| 6 || nCodeSeq || aCode || array of wCIdx || Code. Every word point a word in String Code || 0010 0000 0017 0001 0001 0001 0001 0001 0001 0001 0005
|-
| 6+nCodeSeq || 0 or 1 || wRest || word, dummy || Unused word for compatibility, it is present if nCodeSeq is odd || 0044
|}

Also, nOnceSeq and nRepeatSeq must meet the condition (nOnceSeq + nRepeatSeq) * 2 = 2 + nCodeSeq + sizeOf( wRest
)
Converting procedure is the same as previous one except String Code obtaining, that I describe now: 
Character choosing to String Code depends on value of corresponded wCIdx from aCode: 
- if wCIdx < 0010, then corresponded bCh indexes from second firmware table dID bCh [i] , where dID = wSubFmtID and [i] = wCIdx 
- if wCIdx = 0010, then bCh = “|” 
- if wCIdx > 0010, then this char is toggle. On odd code (of this subformat) replaying bCh is equal (wCIdx – 14h)-th char of
corresponded zTemplate: bCh = zTemplate[ wCIdx – 14 ], where first index in zTemplate is 0. On even code replaying – next
char: bCh = zTemplate[ wCIdx – 13 ]:

[[Image:Pronto-formats-8-forming.jpg]] 
''Figure placeholder: Picture 8 — Forming String Code from 7000''

= Index to UDB (wFmtID = 8000) =
Some Pronto models (RAV-2000, USR-5, TSU-2000, TSU-6000, TSU-500, TSU-3000, RU-970, RU930) supports internal IR
database, others have no internal DB, but only software, and RC-3200 has no any databases:

'''Database availability'''
{| class="wikitable"
! model !! DB type !! file !! size
|-
| TS-1000, RU-890, RU-940 || IR database at ProntoEdit || rcir.mdb (Jet) || 360,448
|-
| TSU-2000, TSU-6000 || UDB || UDP_int.hex || 362,711
|-
| RU-970 || UDB || UDP_int.hex || 662,090
|-
| TSU-500 || UDB as part of || TSU500.dat (Jet) || 5,851,136
|-
| RU-930 || UDB as part of || RU930.dat (Jet) || 7,299,072
|-
| TSU-3000 || UDB || UDB_TSU3000.bin || 422,622
|-
| RC-5000/5000i/5200/9200 || IR database at TSS || rcir.mdb (Jet) || 978,944
|-
| RC-3200 || — || — || —
|-
| RAV-2000 || UDB || ww_udp.idb || 662,090
|-
| USR-5 || UDB || ww_udp.idb || 661,011
|}

This format is used for recall IR codes from real UDB. UDB has clear structure – all commands in it are indexed first by Device Type
(see tables); next – by Brand/Code Set and finally – by Function (depending on device type); it is really easy to custom. Accordingly,
structure of this format is systematic – code contains no IR data, only function – device type, brand and device function!
For example – code of “Power On” for Amp Yamaha, code set 1 - 8000 0000 0002 0000 000a 23f0 0002 0000:

Structure:
{| class="wikitable"
! offset !! size !! name !! type !! description !! sample
|-
| 0 || 1 || wFmtID || word, ID || Must be 8000 || 8000
|-
| 1 || 1 || wFrqDiv || word, dummy || Unused || 0000
|-
| 2 || 1 || nOnceSeq || word, dummy || Dummy length || 0002
|-
| 3 || 1 || nRepeatSeq || word, dummy || Dummy length || 0000
|-
| 4 || 1 || wDevType || word, index || Device type (000A = Amp) || 000A
|-
| 5 || 1 || wBrandCodeSet || word, index || Brand/Code Set (23F0 = Yamaha-1) || 23F0
|-
| 6 || 1 || wFunction || word, index || Function (0002 = Power On) || 0002
|-
| 7 || 1 || wRest || word, dummy || Padding to even words || 0000
|}

Fields wDevType, wBrandCodeSet and wFunction indexes corresponded list values from UDB:

Not all of the UDB codes (format 8000) are supported by all Pronto models, also, not all of the code combinations of this format are supported by any Pronto at all – UDBs differ from model to model!

It is not so hard to extract real IR codes from corresponded DB files, but it is easily to get them directly via TSS.

{| class="wikitable"
! wDevType !! description
|-
| 1 || A. proc
|-
| 2 || Cable
|-
| 3 || CD
|-
| ... || ...
|}

{| class="wikitable"
! wFunction !! description
|-
| 1 || Power off
|-
| 2 || Power on
|-
| 3 || Channel down
|-
| ... || ...
|}

= References =
There are a number of articles about IR formats applied to Pronto on the internet:
# Daniel Tonks “Unofficial Philips Pronto & Marantz RC5000 FAQ”, http://www.remotecentral.com
# Marcel Majoor “Communicating with the Pronto”, http://home.hccnet.nl/m.majoor
# Barry Gordon “ProntoEdit’s IR Display Format”, http://the-gordons.net:8080/, http://www.remotecentral.com/features/irdisp1.htm
# Barry Shaw, Rob Crowe, Andrea Whitlock “Yamaha extended IR codes”, http://darius.mobius-soft.com/~andrea/
# Stewart Allen, “The CCF file format”, http://giantlaser.com/tonto/

----
''Author note:'' Please excuse my poor English. For questions about Pronto IR you can reach me at eoulianov@hotbox.ru, and I will try to answer more clearly :)

Pronto IR Formats

2025-11-22T22:57:22Z

The Robman: /* Index to UDB (wFmtID = 8000) */

= Pronto IR Formats =

== Preamble ==
This article describes in detail the formats of IR code filing for Pronto and ProntoPro models (RU-890, RU-940, RU-970, TS-1000, TSU-2000, TSU-6000, RC-5000, RC-5000i, RC-5200, RC-9200, RAV-2000, USR-5). It is supposed to be interesting for:
* those, who want to clean up his IR codes — in order to find out what all the numbers in field “IR code:” mean and for troubleshooting;
* those, who want to develop an IR code converter into other driver/configuration formats — Crestron (.IR), AMX (.IRL), Xantech (.PAL), Niles (.LIN), ADI Ocelot (.LIR), RedRat2 (.TXT), Denon RC-8000 (.RCX), ProntoNeo (.NCF), ProntoNG (.PCF) etc, as a manual of most popular and complicated IMHO IR code format.

It is advisable for you to have a notion of modulated IR signals transmission [1], but I will also coin that terms for completeness. References to some concepts can be earlier than the description of theirs, so as not to touch on same concept doubly. I am not going to mention the details of realization which is not essential for the description of the format.

== Acknowledgments ==
I would like to thank Daniel Tonks, Stewart Allen, Barry Gordon, Marcel Majoor, Steven Keyser, Bertrand Gillis, Loran Richardson, Bernard Barrier, Barry Shaw, Rob Crowe, Andrea Whitlock, those, who reply at forums — for help and support, my wife — for indulgence and star50fiveoh — for sober intolerance to this article's subject :)

== Warning ==
Standard warning about “… your own risk” is in effect.

== Buttons, signals, commands and codes ==
In order to avoid involving in terms, I specify them precisely:

[[Image:Pronto-formats-buttons.jpg]] 
''Figure placeholder: Picture 1 — Interaction of buttons, IR signals, commands and IR codes''

The button, IR signal, command and IR code are not corresponding mutually:
* the same button can produce different IR signals (see Toggle Codes);
* different IR signals can be recognized by decoder as same command (see Clean and Dirty Codes);
* the same IR signal can be encoded as a number of IR codes in different formats.

== Modulated IR signal ==
For some reasons, mainly for simplicity and interference immunity, almost all IR signals, currently used to IR translation, have the same structure. IR transmitter includes a square-wave generator (oscillator), coder and IR LED. All the time of transfer oscillator generates square impulses with fixed (for this remote) carrier frequency; depending on pressed button (and, may be, remote mode), coder forms a code of command — sequence of conventional logical 0s and 1s; IR LED flashes this command modulated by generated impulses.

[[Image:Pronto-formats-2-IR.jpg]] 
''Figure placeholder: Picture 2 — IR LED replays modulated IR signal''

Any modulated IR signal can be fully characterized via carrier frequency and the sequence of period amounts when emitting is on and off. For picture 2 this sequence is 6–2–4–2–4–…

Sometimes remote emits the signal all the time until the button such as VOLUME+ will released. Another way it flashes once per press, or first, once emitted signal is not the same that repeating one, followed it. So, it is convenient to suppose that in the general way IR signal consists of once part, the start emitting sequence and repeat part. For example, endless IR signal 6-2-4-2-4-6-6-3-3-12-6-3-3-12- has the once sequence 6-2-4-2-4-6 and repeat sequence 6-3-3-12: 6-2-4-2-4-6 | 6-3-3-12. All currently used IR signals can be represented either as a union of once and repeat sequences or as the only once or only repeating sequence.

[[Image:Pronto-formats-3-IR.jpg]] 
''Figure placeholder: Picture 3 — Cutting IR signal into once sequence and repeat sequence''

Usually, IR codes, describing IR signal this way, are not so long. If learned IR code is not an air conditioner code, it can be completely go in “IR code:” field at ProntoEdit.

In the most of cases carrier frequencies are nearby 35KHz, but you will certainly be lucky enough to try a remote with 175KHz, 345KHz, 455KHz or 1.1MHz.

== “Clean” and “dirty” codes ==
[1: “Unclean” and “clean” IR commands (Working With Prontoedit: Learning & Infrared)]

It is not necessary to replay IR signal precisely, IR receiver will “identify” received IR signal as correct command, if it looks like real command adequately, say, carrier frequency and burst pairs’s lengths differ from original IR signal less than for 10%. I.e. there is precise, original IR signal for every command, may be not replay-able for Pronto, and also many IR signals that Pronto can replay and IR receiver can recognize as that command. The codes of those signals may have different lengths, and the shortest one is “clean” code, and the all other codes are “dirty” and very “dirty”.

Reasons to prefer “clean” codes:
* IR signal of “clean” IR code is more recognizable by IR receiver
* some “dirty” IR codes can lead IR receiver astray or halt it
* “clean” code is shorter, and replay of it takes less time in macros
* you can visually check “clean” IR code’s accuracy — the lengths of every “clean” IR codes per remote are the same, except, may be, buttons like VOLUME+
* “clean” code is more convenient to analyzing, in order to guess a discrete command, absent at this remote
* using of “clean” IR codes stirs ambitions of punctual Prontoyers

The ordinal way to obtain “clean” IR code is cutting from existing one [1]. Sometimes it is useful to develop special software — generator of all concrete type IR codes — in order to “discover” all possible commands, supported by that device, including those absent at remotes.

Note: There is no difference in IR learning to Pronto standalone or to computer via Pronto, but sometimes this process is faulted due a communication error.

== Toggle IR codes ==
[1: Why won’t my buttons work twice in a row? (Working With Prontoedit: Learning & Infrared)]

It is necessary not to mix up toggle IR codes and toggle IR commands. Toggle Command is a command with toggle function such as standby/on, see TOAD at [1]. In contrast to that, Toggle IR Code contains as minimal 1 toggle bit, see RC5 at [2].

There are many possible troubles and noises at IR transfer — sun, fluorescent lamps, interference with another IR transfer, dust, pets, household and tremor of hesitating hand, holding remote. First two troubles can be cured by signal modulation. Other problems, concerning temporary obstacle, are solved logically. Commonly they use two different IR signals per button — one for odd presses and another for even. As a rule, these codes differ in one or two logical bits (“toggle” bit or “parity”), and both of them encode the same command. When IR decoder receives IR signal such type, it ignores the same signals (or signals with the same “parity” bit) received twice, in order to avoid taking noise as double click.

Pronto IR learning procedure uses the only button pressing, and because of it Pronto can detect as toggle codes only codes of some predefined types, that look like known codes, for example, RC5. When Pronto replays these codes, it emits in turn odd and even IR signals for every type of predefined code format (and if existing, subformat). So repeating the same alias for “long button press” in macro is not effective for toggle codes; it is necessary to convert this code to format 0000 to do it.

If Pronto learns real toggle codes as ordinary, learn all codes in the same parity, and only the “blank” command (that does nothing, if it exists at remote) — in opposite parity, and give any Pronto button two actions — odd real command and even “blank” [1].

== Pronto IR code filling formats ==
[1: Type of code (Working With Prontoedit: Learning & Infrared)]

IR codes are kept in Pronto and in CCFs in bytes (as all data), but Pronto software uses two-byte hexadecimal words delimited by spaces at IR code view (editBox):
<code>0000 0070 0003 0002 0006 0002 0004 0002 0004 0006 0006 0003 0003 000C</code>

I will write all sizes and offsets in 16-bit words and all numbers in hex, if not specified otherwise. First word — '''wFmtID''' — identifies IR format.

Supported formats:
* 0000 — raw oscillated code
* 0100 — raw unmodulated code
* 5000 — RC5
* 5001 — RC5x
* 6000 — RC6 Mode 0
* 7000 — predefined code of variable length
* 8000 — index to UDB
* 9000, 900A, 900B, 900C, 900D, 900E — NEC
* 9001 — basic mode YAMAHA NEC code

[[Image:Pronto-formats-4-hierarchy.jpg]] 
''Figure placeholder: Picture 4 — hierarchy of Pronto IR formats''

= Raw formats (wFmtID = 0000 or 0100) =
They are simple, basic, most commonly used formats. Almost all IR signals can be represented (exactly or cognitive) either in 0000 or 0100 format. There is no way to encode toggle IR codes at these formats, but separately, odd and even IR code can be converted from toggle form to 0000 format.

== Raw oscillated code (wFmtID = 0000) ==
This is the format that is often implied, when they say “Pronto IR format”. It contains lengths while LED flashes and while
LED is off in carrier periods (“burst pairs”) in two optional parts - once and repeat sequences.

For example, code from pic.2 and 3 will encoded in this format as 0000 0070 0003 0002 0006 0002 0004 0002 0004
0006 0006 0003 0003 000С, where:

{| class="wikitable"
! offset !! size !! name !! type !! description !! sample
|-
| 0 || 1 || wFmtID || word, ID || Format ID. Must be 0000 || 0000
|-
| 1 || 1 || wFrqDiv || word, positive || Carrier frequency divider || 0070
|-
| 2 || 1 || nOnceSeq || word, length || Number of burst pairs at once sequence || 0003
|-
| 3 || 1 || nRepeatSeq || word, length || Number of burst pairs at repeat sequence || 0002
|-
| 4 || 2*nOnceSeq || aOnceSeq || array of rBurstPair || Once sequence || 0006 0002 0004 0002 0004 0006
|-
| 4+2*nOnceSeq || 2*nRepeatSeq || aRepeatSeq || array of rBurstPair || Repeat sequence || 0006 0003 0003 000C
|}

and rBurstPair consists of:

{| class="wikitable"
! offset !! size !! name !! type !! description !! sample
|-
| 0 || 1 || wLEDflash || word, positive || Periods when LED flashes with carrier || 0006
|-
| 1 || 1 || wLEDoff || word, positive || Periods when LED is off || 0002
|}

Details:
* wFmtID: word = 0000, Format ID
* wFrqDiv: word in range 0001..FFFF, wFrqDiv = 4,145146 MHz / <signal carrier>. So wFrqDiv = 0001 corresponds to signal carrier » 4,1 MHz, and wFrqDiv =FFFF ~ 63Hz. I have measured this constant indirectly and have obtained 4,1455±0,0006 MHz, which is close enough with magical number 4,145146 [2], and far enough from 4,194304 [5], but I can’t locate quartz oscillator with this nominal at catalogues.
* nOnceSeq: word in range 0000..0100, is equal to amount of burst pairs at once sequence
* nRepeatSeq: word in range 0000..0100, is equal to amount of burst pairs at repeat sequence
* wLEDflash: word in range 0001..FFFF, is amount of carrier frequency periods when LED flashes every first half-period and turned off for the last half-period
* wLEDoff: word in range 0001..FFFF, is amount of carrier frequency periods when the LED is off

Next picture will dispel all residuary questions:

[[Image:Pronto-formats-5-correspondence.jpg]] 
''Figure placeholder: Picture 5 — correspondence between IR-signal and IR-code at format 0000''

== Raw unmodulated code (wFmtID = 0100) ==
Same structure as 0000, but LED is continuously on for the first word of the burst pair (no carrier):

[[Image:Pronto-formats-6-difference.jpg]] 
''Figure placeholder: Picture 6 — difference between IR signals for 0000 vs 0100''

Differences:
{| class="wikitable"
! offset !! size !! name !! type !! description !! sample
|-
| 0 || 1 || wFmtID || word, ID || Format ID. Must be 0100 || 0100
|}

aBurstPair consists of:

{| class="wikitable"
! offset !! size !! name !! type !! description !! sample
|-
| 0 || 1 || wLEDon || word, positive || Periods when LED is on || 0006
|-
| 1 || 1 || wLEDoff || word, positive || Periods when LED is off || 0002
|}

This format completes format 0000 to universal description of all raw IR signals, but codes at format 0100 are rare – it is
exposed to sun light and other IR noises. I have learned only 2 devices with these codes – noname drape drive and Dish Satellite
Positioner. Nevertheless, sometimes it is useful to use IR signal without carrier, for example, for Sony Contol-S: you can replace an
IR probe at RX-77 to ordinal jack, change 0000 to 0100 at IR codes, and your Sony device will be controlled by Control-S. Some
other systems also support IR signals without carrier, like Crestron’s CstmFreq value = 43.

= Predefined formats (wFmtID = 5000, 5001, 6000, 7000, 8000, 9000, 9001, 900A, 900B, 900C, 900D, 900E) =
There are a number of additional, predefined IR formats, supported by some reasons. They can’t describe all IR signals, every type/subtype of this format represents only IR codes with specific structure, for custom “brand”. Also, we need additional data tables to replay these signals. These predefined formats are more compact than corresponding raw IR codes and, as a rule, simple and “clean”. I.e., if you learn IR as 5000 or 7000 and it is not a bug, then that and all other IR signals from this remote must be codes of this type.

Predefined formats have different structure, but for the reason of compatibility with format 0000, fields wFrqDiv, nOnceSeq, nRepeatSeq leave as dummy, so that code “looks” the same. aOnceSeq and aRepeatSeq are replaced with sCode, that consist real code info. Also, nOnceSeq and nRepeatSeq must meet the condition (nOnceSeq + nRepeatSeq) * 2 = sizeOf(sCode):

Template header:
{| class="wikitable"
! offset !! size !! name !! type !! description !! sample
|-
| 0 || 1 || wFmtID || word, ID || Format ID || 5000
|-
| 1 || 1 || wFrqDiv || word, dummy || Unused word for compatibility || 0000
|-
| 2 || 1 || nOnceSeq || word, dummy || Dummy code length || 0000
|-
| 3 || 1 || nRepeatSeq || word, dummy || Dummy code length || 0001
|-
| 4 || (nOnceSeq+nRepeatSeq)*2 || sCode || structure || Predefined code || 0000 0000
|}

Not all of the predefined formats are supported by any Pronto model – here a table of compatibility is:

{| class="wikitable"
! wFmtID !! RU-890/940/TS-1000/RC-5000/5000i !! TSU-2000 !! RC-5200/9200 !! TSU-6000/RU-970/USR-5 !! RAV-2000
|-
| 0000, 0100, 5000, 5001, 6000, 7000 || ✔ || ✔ || ✔ || ✔ || ✔
|-
| 8000 || || ✔ || || ✔ || ✔
|-
| 9000 || || || ✔ || ✔ || ✔
|-
| 9001 || || || || || ✔
|-
| 900A–900E || || || ✔ || ✔ ||
|}

Also, RC-3200 does not support all of this formats directly (except 0000), but RC-3200 Setup converts codes 0100, 5000, 5001 and 6000 codes into format 0000 automatically, and this feature can be used from elsewhere!

Note: 0000 format used by RC-3200 is extended by including support of unmodulated IR signals with special value of wFrqDiv = 0001.

When I describe these formats, I will translate them to format 0000, in anticipation of this converter is already exist.

= Template based formats (wFmtID = 5000, 5001, 6000, 7000, 9000, 9001, 900A, 900B, 900C, 900D, 900E) =
Template based formats are used for memory saving, for representing toggle IR codes, and for encoding IR signals with high
carrier frequency.

Segment SYS at Pronto Firmware contains 2 tables for encoding/decoding IR codes these types:

== SYS segment tables ==
{| class="wikitable"
! dID !! zSystem !! zTemplate !! zMask !! dFrqDiv !! bU1 !! dU2 !! dU3 !! dU4
|-
| 00 || rc5 || 1[01]{01}[01]%11R || 5000h + {4-8}{12,9-14} || 73 || 0 || 2 || 0 || 0A
|-
| 01 || rc6m0 || H1000ftT}[01]%16R || 6000h + {7-14}{15-22} || 73 || 0 || 0 || 0 || 0A
|-
| 02 || rc5e || 1 01]{01} [01]%5S[01]%12R || 5001h + {4-8}{12,10-15}{15-20} || 73 || 0 || 3 || 0 || 0A
|-
| 03 || b&o || 115[1234]*R?|<3[12345]* || 7000h || -09 || 0 || 5 || 0 || 14
|-
| 04 || kenwood || s$[01]%32e|rp || 7000h || -09 || 0 || 2 || 1 || 14
|-
| 05 || pioneer || o$[01]%32[RSTUo] r[01rRSTUo]* || 7000h || -04 || 0 || 4 || 1 || 14
|-
| 06 || ehrep || s[abcderst]%4[abcderst]* |s[abcderst]%4[abcderst]* || 7000h || -0C || 0 || 4 || 0 || 14
|-
| 07 || ehonce || s[abcderst]%4[abcderst]* || 7000h || -0C || 0 || 4 || 0 || 14
|-
| 08 || grundig 16ac || P{ac} [abcd]%7r || 7000h || 88 || 0 || 0 || 0 || 06
|-
| 09 || grundig 16bd || P{bd}[abcd]%7r || 7000h || 88 || 0 || 0 || 0 || 06
|-
| 0A || thomson1 || 2{12}[12]%9R || 7000h || 7C || 0 || 1 || 0 || 0E
|-
| 0B || thomson2 || {12}{12}[12]%9[RS] || 7000h || 7C || 0 || -1 || 0 || 0F
|-
| 0C || thomson3 || [12]%4{12}[12]%7[RST] || 7000h || 7C || 0 || -1 || 0 || 10
|-
| 0D || ferguson || s%2(01}[01]%9[RS] || 7000h || -0C || 1 || 4 || 0 || 0D
|-
| 0E || telefunken || (01} {01}[01]%9[RS || 7000h || -18 || 1 || -1 || 0 || 0E
|-
| 0F || echostar || T01]%5R || 7000h || 42 || 0 || -1 || 0 || 07
|-
| 10 || saba || (01}{01}[01]%9[RS || 7000h || -08 || 1 || -1 || 0 || 0E
|-
| 11 || crown || 2{12}[12]%9[RS] || 7000h || 6D || 0 || 2 || 0 || 0E
|-
| 12 || seleco || 2(12}[12]%9[RS || 7000h || 63 || 0 || 2 || 0 || 0E
|-
| 13 || nec1a || I[01]%32F|R || 900Ah + {8-1,16-9)}{24-17,32-25} || 6D || 0 || 0 || 0 || 0E
|-
| 14 || nec1b || I[01]%32F || 900Bh + {9-2,17-10}{25-18,33-26} || 6D || 0 || 0 || 0 || 0E
|-
| 15 || nec1c || I[01]%32FI[01]%32F|R || 900Ch + {8-1,16-9}{24-17,32-25} {42-35,50-43}{58-51,66-59} || 6D || 0 || 0 || 0 || 0E
|-
| 16 || nec1d || I[01]%32F|I[01]%32F || 900Dh + {8-1,16-9}{24-17,32-25} {43-36,51-44}{59-52,67-60} || 6D || 0 || 0 || 0 || 0E
|-
| 17 || nec1e || I[01]%32FI[01]%32F || 900Eh + {9-2,17-10}{25-18,33-26} {43-36,51-44}{59-52,67-60} || 6D || 0 || 0 || 0 || 0E
|-
| 18 || nec2a || I[01]%32FJR || 900Ah + {8-1,16-9}{24-17,32-25} || 68 || 0 || 0 || 0 || 0E
|-
| 19 || nec2b || I[01]%32F || 900Bh + {9-2,17-10}{25-18,33-26} || 68 || 0 || 0 || 0 || 0E
|-
| 1A || nec2c || I[01]%32FI[01]%32F|R || 900Ch + {8-1,16-9}{24-17,32-25} {42-35,50-43}{58-51,66-59} || 68 || 0 || 0 || 0 || 0E
|-
| 1B || nec2d || I[01]%32F|I[01]%32F || 900Dh + {8-1,16-9}{24-17,32-25} {43-36,51-44}{59-52,67-60} || 68 || 0 || 0 || 0 || 0E
|-
| 1C || nec2e || |I[01]%32FI[01]%32F || 900Eh + {9-2,17-10}{25-18,33-26} {43-36,51-44}{59-52,67-60} || 68 || 0 || 0 || 0 || 0E
|-
| 1D || nec || I[01]%32%F|R || 9000h + {8-1}{16-9}{24-17}{32-25} || 6D || 0 || 0 || 0 || 0E
|-
| * || rc6m6a-24 || H1110{tT}0[01]%23R || 6001h + {8-14)}{15-22}{23-30} || 73 || 0 || ? || 0 || ?
|-
| ** || rc6m6a-32 || H1110{tT} 1[01]%31R || 6001h + {8-22}{23-30}{31-38} || 73 || 0 || ? || 0 || ?
|-
| *** || yamahanec || ?I[01]%32F|R || ?9001h + {8-1}{24-17}, + {!16-19}{132 -! 25} || ?6D || 0 || 0 || 0 || ?
|}

{| class="wikitable"
! dID !! bCh !! [i] !! aBurstSeq !! dID !! bCh !! [i] !! aBurstSeq !! dID !! bCh !! [i] !! aBurstSeq
|-
| 00 || R || 0 || -0CA0 || 02 || R || 0 || -0AA0 || 03 || 1 || 5 || 005B -0546
|-
| 00 || 0 || 1 || 0020 -0020 || 02 || S || 1 || -0080 || 04 || p || 0 || 0103 -AD01
|-
| 00 || 1 || 2 || -0020 0020 || 02 || 0 || 2 || 0020 -0020 || 04 || e || 1 || 0103 -47D5
|-
| 01 || H || 0 || 0060 -0020 || 02 || 1 || 3 || -0020 0020 || 04 || s || 2 || 0103 -1745
|-
| 01 || T || 1 || 0020 -0020 || 03 || R || 0 || 005B -C422 || 04 || r || 3 || 1010 -040C
|-
| 01 || t || 2 || -0020 0020 || 03 || 5 || 1 || 005B -1BC0 || 04 || 0 || 4 || 0103 -0309
|-
| 01 || 0 || 3 || -0010 0010 || 03 || 4 || 2 || 005B -1622 || 04 || 1 || 5 || 0103 -0103
|-
| 01 || 1 || 4 || 0010 -0010 || 03 || 3 || 3 || 005B -1083 || 04 || s$ || 6 || 1010 -081E
|-
| 01 || R || 5 || -0BC0 || 03 || 2 || 4 || 005B -0AE4 || 05 || r || 0 || 227B -1160
|-
| 05 || R || 1 || 022C -8FFA || 0A || R || 0 || 0006 -0857 || 10 || S || 1 || 0009 -58D2
|-
| 05 || S || 2 || 022C -6108 || 0A || 2 || 1 || 0006 -011A || 10 || 0 || 2 || 0009 -0F3E
|-
| 05 || T || 3 || 022C -4165 || 0A || 1 || 2 || 0006 -00BB || 10 || 1 || 3 || 0009 -0A2A
|-
| 05 || o || 4 || 022C -31AF || 0B || R || 0 || 0010 -0857 || 11,12 || R || 0 || 0006 -0841
|-
| 05 || U || 5 || 022C -2C13 || 0B || S || 1 || 0010 -0642 || 11,12 || S || 1 || 0006 -065B
|-
| 05 || 0 || 6 || 022C -0684 || 0B || 2 || 2 || 0010 -0112 || 11,12 || 2 || 2 || 0006 -011A
|-
| 05 || 1 || 7 || 022C -022C || 0B || 1 || 3 || 0010 -00B1 || 11,12 || 1 || 3 || 0006 -00BB
|-
| 05 || o$ || 8 || 227B -1160 || 0C || R || 0 || 0010 -059D || 13–1D, *** || I || 0 || 0157 -00AB
|-
| 06,07 || r || 0 || 00FC -347B || 0C || S || 1 || 0010 -0417 || 13–1D, *** || F || 1 || 0016 -05E7
|-
| 06,07 || a || 1 || 00FC -00FC || 0C || T || 2 || 0010 -02FB || 13–1D, *** || 1 || 2 || 0016 -0040
|-
| 06,07 || e || 2 || 00FC -007E || 0C || 2 || 3 || 0010 -0099 || 13–1D || 0 || 3 || 0016 -0015
|-
| 06,07 || t || 3 || 007E -347B || 0C || 1 || 4 || 0010 -0044 || 13,15,18,1A || R || 4 || 0157 -0055 0016 -0E3B
|-
| 06,07 || s || 4 || 007E -0274 || 0D || R || 0 || 0008 -4B7B || * ** || H || 0 || 0070 -0020
|-
| 06,07 || b || 5 || 007E -017A || 0D || S || 1 || 0008 -3A74 || * ** || T? || 1 || 0020 -0020
|-
| 06,07 || c || 6 || 007E -00FC || 0D || 0 || 2 || 0008 -0A2B || * ** || t || 2 || -0020 0020
|-
| 06,07 || d || 7 || 007E -007E || 0D || 1 || 3 || 0008 -06C3 || * ** || 0 || 3 || -0010 0010
|-
| 08,09 || P || 0 || 0019 -005A 0028 || 0D || s || 4 || 0008 -0515 || * ** || 1 || 4 || 0010 -0010
|-
| 08,09 || a || 1 || -0044 0024 || 0E || R || 0 || 0008 -2BAE || * || R || 5 || -0AB0
|-
| 08,09 || b || 2 || -0036 0012 -000E 0012 || 0E || S || 1 || 0008 -2104 || ** || R || 5 || -09B0
|-
| 08,09 || c || 3 || -0022 0012 -0022 0012 || 0E || 0 || 2 || 0008 -05CA || 10 || R || 0 || 0009 -74F3
|-
| 08,09 || d || 4 || -000E 0012 -0036 0012 || 0E || 1 || 3 || 0008 -03D9 || || || ||
|-
| 08,09 || r || 5 || -07FC || 0F || R || 0 || 0019 -024C || || || ||
|-
| 0F || 0 || 1 || 0019 -010A || 0F || 1 || 2 || 0019 -00AF || || || ||
|}

At the first table: 
dID – subformat, used at format 7000 and for connection with second table
zSystem – unused string, “brand”-like description of dID
zTemplate – template of logical structure of IR signal of this type (dID)
:<letters> and <numbers> - are references as bCh to second table, where they (with dID) point out to a concrete aBurstSeq
:| – delimits once sequence and repeat sequence parts
:[<chars>] – means any of suggested characters
:{<char1><char2>} – corresponds to toggle bit: at odd replaying of IR code of this type must be <char1>, at even – <char2>
:%<number> - means <number> of duplicates of previous character/term
:<nowiki>*</nowiki> - any number of any previously defined characters at [<chars>]
:<char>$ - strange 2-byte name for char, nothing else :)
:?, < - garbage that must be ignored :)
zMask – mask, correspondence between zTemplate and IR code at Fixed Size Template Based Formats. Be described at these formats. zMask is used while learning only.
:Hexadecimal word is wFmtID
:{<expression>} – means description of corresponded word from sCode
:<number> - means index at forming String Code for corresponded bit at sCode word
:<number1>-<number2> - means a range (inversed range) of these bounds – <number1>, <number1+(-)1>, …,
::<number2>
:!<number> – means index at String Code for logical negation of corresponded bit at sCode
dFrqDiv – carrier frequency divider. “-“ means high (>58KHz?) frequency, that is need to be analyzed (when learning) with another filter, I think, so “-“ must be ignored.
bU1, dU2, dU3, dU4 – additional class/format characteristics. I suppose, they are used by recognition routine, or as additional info, like index of developer, who encodes special code for this format/subformat :), and must be ignored at replaying/converting.

At the second table: 
dID – same as at the first table
bCh – means index (char) from zTemplate or String Code
[i] – means index to aBurstSeq from aCode (same as wCIdx) at Predefined Codes of Variable Length (7000)
aBurstSeq – analogue of burst pair with variable length – from 1 to 4 words. Positive words mean time when LED flashes, negative – when LED is off.

= Template Based Formats of Fixed Size (wFmtID = 5000, 5001, 6000, 9000, 9001, 900A, 900B, 900C, 900D, 900E) =

Template based formats of fixed size represent strongly defined IR signals of common brands. As a rule, IR signal, leaned at this format, is the only and “clean” (but I have trouble with RC9200 + Onkyo DVD – it learns its IR codes as 900A mistakenly). IR codes at this format are short, sCode can be 2, 3 or 4 words length, and every of this word means anything like “System”, “Command” or “Data” but that meanings are not essential for converting.

Now, the ranges of that codes:

5000 0000 0000 0001 0000 0000 – 5000 0000 0000 0001 001f 007f

5001 0000 0000 0002 0000 0000 0000 0000 – 5001 0000 0000 0002 001f 007f 003f 0000 
Note: it looks like erratum at firmware table, really zMask for dID = 02 must be 5001h + {4-8}{!2,10-15}{16-21}. This bug causes
a real brain pain: any RC5x code can not be learned by any Pronto! But replaying of these codes works OK, because zMask is not
used for replay.

6000 0000 0000 0001 0000 0000 – 6000 0000 0000 0001 00ff 00ff 
Note: [2] contains description of RC6 Mode 6A as format 6001 with toggle bit, as all other RC-formats. Currently software
represents that codes at format 0000 without toggle bit. I have inserted corresponded (obsolete?) entries * and ** to the end of
firmware tables from [2] for considerations of universality: 
(<nowiki>*</nowiki>subformat of 6001, where first argument (Customer Code) is in range of 0000..007f)

6001 0000 0000 0002 0000 0000 0000 0000 – 6001 0000 0000 0002 007f 00ff 00ff 0000 
(<nowiki>**</nowiki>subformat of 6001, where first argument is in range of 8000..ffff)

6001 0000 0000 0002 8000 0000 0000 0000 – 6001 0000 0000 0002 ffff 00ff 00ff 0000

9000 0000 0000 0002 0000 0000 0000 0000 – 9000 0000 0000 0002 00ff 00ff 00ff 00ff

900a 0000 0000 0001 0000 0000 – 900a 0000 0000 0001 ffff ffff 
Note: These codes represent most common (may be, after RC) IR signal type (32bits NEC). Usually it consist of 8bit device code, 8bit device code binary compliment, 8bit function code and 8bit function code binary compliment [3,4]. All Pronto models, except RC5200, RC-9200, TSU-6000, RU-970, USR-5 must learn this type of IR signals as 0000 006* 0022 0002 0157 …, and it works fine. New Pronto models can replay formats 900A to 900E, but recognition routine is inclined to learn all NEC IR signals as format 900A, that often results in fsults.

900b 0000 0000 0001 0000 0000 – 900b 0000 0000 0001 ffff ffff

900c 0000 0000 0002 0000 0000 0000 0000 – 900c 0000 0000 0002 ffff ffff ffff ffff

900d 0000 0000 0002 0000 0000 0000 0000 – 900d 0000 0000 0002 ffff ffff ffff ffff

900e 0000 0000 0002 0000 0000 0000 0000 – 900e 0000 0000 0002 ffff ffff ffff ffff

9001 0000 0000 0001 0000 0000 – 9001 0000 0000 0001 00ff 00ff

Note: format 9001 is supported only by RAV-2000, but absent in all tables. I can’t check it, and I hope that codes, described at [3,4] are the same, so I have inserted it to firmware tables as ***. 

For converting that codes to format 0000 I offer this procedure: 
* Obtaining String Code from zTemplate, zMask and source code
* Obtaining raw IR data by indexing from String Code
* Forming IR code at format 0000 from raw IR data

[[Image:Pronto-formats-7-converting.jpg]] 
''Picture 7: Converting IR code of template based format of fixed size into format 0000 '' 
Note: 0CE0 = -0020 (last “0” at String Code ) + -0CA0 (“R”) + -0020 (first “1”)

= Predefined code of variable length (wFmtID = 7000) =
This format is for representing IR signals that can not (yet) be easily encoded as predefined format of fixed size. The structure of this
code is described on sample - Grundig 7000 0088 0000 0007 0008 000b 0010 0000 0017 0001 0001 0001
0001 0001 0001 0001 0005 0044:

{| class="wikitable"
! offset !! size !! name !! type !! description !! sample
|-
| 0 || 1 || wFmtID || word, ID || Format ID = 7000 || 7000
|-
| 1 || 1 || wFrqDiv || word, dummy || Unused word || 0088
|-
| 2 || 1 || nOnceSeq || word, dummy || Dummy length || 0000
|-
| 3 || 1 || nRepeatSeq || word, dummy || Dummy length || 0007
|-
| 4 || 1 || wSubFmtID || word, ID || SubFormat ID (dID) || 0008
|-
| 5 || 1 || nCodeSeq || word, length || Length of aCode || 000B
|-
| 6 || nCodeSeq || aCode || array of wCIdx || Code. Every word point a word in String Code || 0010 0000 0017 0001 0001 0001 0001 0001 0001 0001 0005
|-
| 6+nCodeSeq || 0 or 1 || wRest || word, dummy || Unused word for compatibility, it is present if nCodeSeq is odd || 0044
|}

Also, nOnceSeq and nRepeatSeq must meet the condition (nOnceSeq + nRepeatSeq) * 2 = 2 + nCodeSeq + sizeOf( wRest
)
Converting procedure is the same as previous one except String Code obtaining, that I describe now: 
Character choosing to String Code depends on value of corresponded wCIdx from aCode: 
- if wCIdx < 0010, then corresponded bCh indexes from second firmware table dID bCh [i] , where dID = wSubFmtID and [i] = wCIdx 
- if wCIdx = 0010, then bCh = “|” 
- if wCIdx > 0010, then this char is toggle. On odd code (of this subformat) replaying bCh is equal (wCIdx – 14h)-th char of
corresponded zTemplate: bCh = zTemplate[ wCIdx – 14 ], where first index in zTemplate is 0. On even code replaying – next
char: bCh = zTemplate[ wCIdx – 13 ]:

[[Image:Pronto-formats-8-forming.jpg]] 
''Figure placeholder: Picture 8 — Forming String Code from 7000''

= Index to UDB (wFmtID = 8000) =
Some Pronto models (RAV-2000, USR-5, TSU-2000, TSU-6000, TSU-500, TSU-3000, RU-970, RU930) supports internal IR
database, others have no internal DB, but only software, and RC-3200 has no any databases:

'''Database availability'''
{| class="wikitable"
! model !! DB type !! file !! size
|-
| TS-1000, RU-890, RU-940 || IR database at ProntoEdit || rcir.mdb (Jet) || 360,448
|-
| TSU-2000, TSU-6000 || UDB || UDP_int.hex || 362,711
|-
| RU-970 || UDB || UDP_int.hex || 662,090
|-
| TSU-500 || UDB as part of || TSU500.dat (Jet) || 5,851,136
|-
| RU-930 || UDB as part of || RU930.dat (Jet) || 7,299,072
|-
| TSU-3000 || UDB || UDB_TSU3000.bin || 422,622
|-
| RC-5000/5000i/5200/9200 || IR database at TSS || rcir.mdb (Jet) || 978,944
|-
| RC-3200 || — || — || —
|-
| RAV-2000 || UDB || ww_udp.idb || 662,090
|-
| USR-5 || UDB || ww_udp.idb || 661,011
|}

This format is used for recall IR codes from real UDB. UDB has clear structure – all commands in it are indexed first by Device Type
(see tables); next – by Brand/Code Set and finally – by Function (depending on device type); it is really easy to custom. Accordingly,
structure of this format is systematic – code contains no IR data, only function – device type, brand and device function!
For example – code of “Power On” for Amp Yamaha, code set 1 - 8000 0000 0002 0000 000a 23f0 0002 0000:

Structure:
{| class="wikitable"
! offset !! size !! name !! type !! description !! sample
|-
| 0 || 1 || wFmtID || word, ID || Must be 8000 || 8000
|-
| 1 || 1 || wFrqDiv || word, dummy || Unused || 0000
|-
| 2 || 1 || nOnceSeq || word, dummy || Dummy length || 0002
|-
| 3 || 1 || nRepeatSeq || word, dummy || Dummy length || 0000
|-
| 4 || 1 || wDevType || word, index || Device type (000A = Amp) || 000A
|-
| 5 || 1 || wBrandCodeSet || word, index || Brand/Code Set (23F0 = Yamaha-1) || 23F0
|-
| 6 || 1 || wFunction || word, index || Function (0002 = Power On) || 0002
|-
| 7 || 1 || wRest || word, dummy || Padding to even words || 0000
|}

Fields wDevType, wBrandCodeSet and wFunction indexes corresponded list values from UDB:

Not all of the UDB codes (format 8000) are supported by all Pronto models, also, not all of the code combinations of this format are supported by any Pronto at all – UDBs differ from model to model!

It is not so hard to extract real IR codes from corresponded DB files, but it is easily to get them directly via TSS.

{| class="wikitable"
! wDevType !! description
|-
| 1 || A. proc
|-
| 2 || Cable
|-
| 3 || CD
|-
| ... || ...
|}

{| class="wikitable"
! wFunction !! description
|-
| 1 || Power off
|-
| 2 || Power on
|-
| 3 || Channel down
|-
| ... || ...
|}

Please excuse my poor English. On any questions about Pronto IR – please request me to eoulianov@hotbox.ru , and I will try to answer more clearly :)

= References =
There are a number of articles about IR formats applied to Pronto on the internet:
# Daniel Tonks “Unofficial Philips Pronto & Marantz RC5000 FAQ”, http://www.remotecentral.com
# Marcel Majoor “Communicating with the Pronto”, http://home.hccnet.nl/m.majoor
# Barry Gordon “ProntoEdit’s IR Display Format”, http://the-gordons.net:8080/, http://www.remotecentral.com/features/irdisp1.htm
# Barry Shaw, Rob Crowe, Andrea Whitlock “Yamaha extended IR codes”, http://darius.mobius-soft.com/~andrea/
# Stewart Allen, “The CCF file format”, http://giantlaser.com/tonto/

----
''Author note:'' Please excuse my poor English. For questions about Pronto IR you can reach me at eoulianov@hotbox.ru, and I will try to answer more clearly :)

Pronto IR Formats

2025-11-22T22:49:38Z

The Robman: /* Predefined code of variable length (wFmtID = 7000) */

= Pronto IR Formats =

== Preamble ==
This article describes in detail the formats of IR code filing for Pronto and ProntoPro models (RU-890, RU-940, RU-970, TS-1000, TSU-2000, TSU-6000, RC-5000, RC-5000i, RC-5200, RC-9200, RAV-2000, USR-5). It is supposed to be interesting for:
* those, who want to clean up his IR codes — in order to find out what all the numbers in field “IR code:” mean and for troubleshooting;
* those, who want to develop an IR code converter into other driver/configuration formats — Crestron (.IR), AMX (.IRL), Xantech (.PAL), Niles (.LIN), ADI Ocelot (.LIR), RedRat2 (.TXT), Denon RC-8000 (.RCX), ProntoNeo (.NCF), ProntoNG (.PCF) etc, as a manual of most popular and complicated IMHO IR code format.

It is advisable for you to have a notion of modulated IR signals transmission [1], but I will also coin that terms for completeness. References to some concepts can be earlier than the description of theirs, so as not to touch on same concept doubly. I am not going to mention the details of realization which is not essential for the description of the format.

== Acknowledgments ==
I would like to thank Daniel Tonks, Stewart Allen, Barry Gordon, Marcel Majoor, Steven Keyser, Bertrand Gillis, Loran Richardson, Bernard Barrier, Barry Shaw, Rob Crowe, Andrea Whitlock, those, who reply at forums — for help and support, my wife — for indulgence and star50fiveoh — for sober intolerance to this article's subject :)

== Warning ==
Standard warning about “… your own risk” is in effect.

== Buttons, signals, commands and codes ==
In order to avoid involving in terms, I specify them precisely:

[[Image:Pronto-formats-buttons.jpg]] 
''Figure placeholder: Picture 1 — Interaction of buttons, IR signals, commands and IR codes''

The button, IR signal, command and IR code are not corresponding mutually:
* the same button can produce different IR signals (see Toggle Codes);
* different IR signals can be recognized by decoder as same command (see Clean and Dirty Codes);
* the same IR signal can be encoded as a number of IR codes in different formats.

== Modulated IR signal ==
For some reasons, mainly for simplicity and interference immunity, almost all IR signals, currently used to IR translation, have the same structure. IR transmitter includes a square-wave generator (oscillator), coder and IR LED. All the time of transfer oscillator generates square impulses with fixed (for this remote) carrier frequency; depending on pressed button (and, may be, remote mode), coder forms a code of command — sequence of conventional logical 0s and 1s; IR LED flashes this command modulated by generated impulses.

[[Image:Pronto-formats-2-IR.jpg]] 
''Figure placeholder: Picture 2 — IR LED replays modulated IR signal''

Any modulated IR signal can be fully characterized via carrier frequency and the sequence of period amounts when emitting is on and off. For picture 2 this sequence is 6–2–4–2–4–…

Sometimes remote emits the signal all the time until the button such as VOLUME+ will released. Another way it flashes once per press, or first, once emitted signal is not the same that repeating one, followed it. So, it is convenient to suppose that in the general way IR signal consists of once part, the start emitting sequence and repeat part. For example, endless IR signal 6-2-4-2-4-6-6-3-3-12-6-3-3-12- has the once sequence 6-2-4-2-4-6 and repeat sequence 6-3-3-12: 6-2-4-2-4-6 | 6-3-3-12. All currently used IR signals can be represented either as a union of once and repeat sequences or as the only once or only repeating sequence.

[[Image:Pronto-formats-3-IR.jpg]] 
''Figure placeholder: Picture 3 — Cutting IR signal into once sequence and repeat sequence''

Usually, IR codes, describing IR signal this way, are not so long. If learned IR code is not an air conditioner code, it can be completely go in “IR code:” field at ProntoEdit.

In the most of cases carrier frequencies are nearby 35KHz, but you will certainly be lucky enough to try a remote with 175KHz, 345KHz, 455KHz or 1.1MHz.

== “Clean” and “dirty” codes ==
[1: “Unclean” and “clean” IR commands (Working With Prontoedit: Learning & Infrared)]

It is not necessary to replay IR signal precisely, IR receiver will “identify” received IR signal as correct command, if it looks like real command adequately, say, carrier frequency and burst pairs’s lengths differ from original IR signal less than for 10%. I.e. there is precise, original IR signal for every command, may be not replay-able for Pronto, and also many IR signals that Pronto can replay and IR receiver can recognize as that command. The codes of those signals may have different lengths, and the shortest one is “clean” code, and the all other codes are “dirty” and very “dirty”.

Reasons to prefer “clean” codes:
* IR signal of “clean” IR code is more recognizable by IR receiver
* some “dirty” IR codes can lead IR receiver astray or halt it
* “clean” code is shorter, and replay of it takes less time in macros
* you can visually check “clean” IR code’s accuracy — the lengths of every “clean” IR codes per remote are the same, except, may be, buttons like VOLUME+
* “clean” code is more convenient to analyzing, in order to guess a discrete command, absent at this remote
* using of “clean” IR codes stirs ambitions of punctual Prontoyers

The ordinal way to obtain “clean” IR code is cutting from existing one [1]. Sometimes it is useful to develop special software — generator of all concrete type IR codes — in order to “discover” all possible commands, supported by that device, including those absent at remotes.

Note: There is no difference in IR learning to Pronto standalone or to computer via Pronto, but sometimes this process is faulted due a communication error.

== Toggle IR codes ==
[1: Why won’t my buttons work twice in a row? (Working With Prontoedit: Learning & Infrared)]

It is necessary not to mix up toggle IR codes and toggle IR commands. Toggle Command is a command with toggle function such as standby/on, see TOAD at [1]. In contrast to that, Toggle IR Code contains as minimal 1 toggle bit, see RC5 at [2].

There are many possible troubles and noises at IR transfer — sun, fluorescent lamps, interference with another IR transfer, dust, pets, household and tremor of hesitating hand, holding remote. First two troubles can be cured by signal modulation. Other problems, concerning temporary obstacle, are solved logically. Commonly they use two different IR signals per button — one for odd presses and another for even. As a rule, these codes differ in one or two logical bits (“toggle” bit or “parity”), and both of them encode the same command. When IR decoder receives IR signal such type, it ignores the same signals (or signals with the same “parity” bit) received twice, in order to avoid taking noise as double click.

Pronto IR learning procedure uses the only button pressing, and because of it Pronto can detect as toggle codes only codes of some predefined types, that look like known codes, for example, RC5. When Pronto replays these codes, it emits in turn odd and even IR signals for every type of predefined code format (and if existing, subformat). So repeating the same alias for “long button press” in macro is not effective for toggle codes; it is necessary to convert this code to format 0000 to do it.

If Pronto learns real toggle codes as ordinary, learn all codes in the same parity, and only the “blank” command (that does nothing, if it exists at remote) — in opposite parity, and give any Pronto button two actions — odd real command and even “blank” [1].

== Pronto IR code filling formats ==
[1: Type of code (Working With Prontoedit: Learning & Infrared)]

IR codes are kept in Pronto and in CCFs in bytes (as all data), but Pronto software uses two-byte hexadecimal words delimited by spaces at IR code view (editBox):
<code>0000 0070 0003 0002 0006 0002 0004 0002 0004 0006 0006 0003 0003 000C</code>

I will write all sizes and offsets in 16-bit words and all numbers in hex, if not specified otherwise. First word — '''wFmtID''' — identifies IR format.

Supported formats:
* 0000 — raw oscillated code
* 0100 — raw unmodulated code
* 5000 — RC5
* 5001 — RC5x
* 6000 — RC6 Mode 0
* 7000 — predefined code of variable length
* 8000 — index to UDB
* 9000, 900A, 900B, 900C, 900D, 900E — NEC
* 9001 — basic mode YAMAHA NEC code

[[Image:Pronto-formats-4-hierarchy.jpg]] 
''Figure placeholder: Picture 4 — hierarchy of Pronto IR formats''

= Raw formats (wFmtID = 0000 or 0100) =
They are simple, basic, most commonly used formats. Almost all IR signals can be represented (exactly or cognitive) either in 0000 or 0100 format. There is no way to encode toggle IR codes at these formats, but separately, odd and even IR code can be converted from toggle form to 0000 format.

== Raw oscillated code (wFmtID = 0000) ==
This is the format that is often implied, when they say “Pronto IR format”. It contains lengths while LED flashes and while
LED is off in carrier periods (“burst pairs”) in two optional parts - once and repeat sequences.

For example, code from pic.2 and 3 will encoded in this format as 0000 0070 0003 0002 0006 0002 0004 0002 0004
0006 0006 0003 0003 000С, where:

{| class="wikitable"
! offset !! size !! name !! type !! description !! sample
|-
| 0 || 1 || wFmtID || word, ID || Format ID. Must be 0000 || 0000
|-
| 1 || 1 || wFrqDiv || word, positive || Carrier frequency divider || 0070
|-
| 2 || 1 || nOnceSeq || word, length || Number of burst pairs at once sequence || 0003
|-
| 3 || 1 || nRepeatSeq || word, length || Number of burst pairs at repeat sequence || 0002
|-
| 4 || 2*nOnceSeq || aOnceSeq || array of rBurstPair || Once sequence || 0006 0002 0004 0002 0004 0006
|-
| 4+2*nOnceSeq || 2*nRepeatSeq || aRepeatSeq || array of rBurstPair || Repeat sequence || 0006 0003 0003 000C
|}

and rBurstPair consists of:

{| class="wikitable"
! offset !! size !! name !! type !! description !! sample
|-
| 0 || 1 || wLEDflash || word, positive || Periods when LED flashes with carrier || 0006
|-
| 1 || 1 || wLEDoff || word, positive || Periods when LED is off || 0002
|}

Details:
* wFmtID: word = 0000, Format ID
* wFrqDiv: word in range 0001..FFFF, wFrqDiv = 4,145146 MHz / <signal carrier>. So wFrqDiv = 0001 corresponds to signal carrier » 4,1 MHz, and wFrqDiv =FFFF ~ 63Hz. I have measured this constant indirectly and have obtained 4,1455±0,0006 MHz, which is close enough with magical number 4,145146 [2], and far enough from 4,194304 [5], but I can’t locate quartz oscillator with this nominal at catalogues.
* nOnceSeq: word in range 0000..0100, is equal to amount of burst pairs at once sequence
* nRepeatSeq: word in range 0000..0100, is equal to amount of burst pairs at repeat sequence
* wLEDflash: word in range 0001..FFFF, is amount of carrier frequency periods when LED flashes every first half-period and turned off for the last half-period
* wLEDoff: word in range 0001..FFFF, is amount of carrier frequency periods when the LED is off

Next picture will dispel all residuary questions:

[[Image:Pronto-formats-5-correspondence.jpg]] 
''Figure placeholder: Picture 5 — correspondence between IR-signal and IR-code at format 0000''

== Raw unmodulated code (wFmtID = 0100) ==
Same structure as 0000, but LED is continuously on for the first word of the burst pair (no carrier):

[[Image:Pronto-formats-6-difference.jpg]] 
''Figure placeholder: Picture 6 — difference between IR signals for 0000 vs 0100''

Differences:
{| class="wikitable"
! offset !! size !! name !! type !! description !! sample
|-
| 0 || 1 || wFmtID || word, ID || Format ID. Must be 0100 || 0100
|}

aBurstPair consists of:

{| class="wikitable"
! offset !! size !! name !! type !! description !! sample
|-
| 0 || 1 || wLEDon || word, positive || Periods when LED is on || 0006
|-
| 1 || 1 || wLEDoff || word, positive || Periods when LED is off || 0002
|}

This format completes format 0000 to universal description of all raw IR signals, but codes at format 0100 are rare – it is
exposed to sun light and other IR noises. I have learned only 2 devices with these codes – noname drape drive and Dish Satellite
Positioner. Nevertheless, sometimes it is useful to use IR signal without carrier, for example, for Sony Contol-S: you can replace an
IR probe at RX-77 to ordinal jack, change 0000 to 0100 at IR codes, and your Sony device will be controlled by Control-S. Some
other systems also support IR signals without carrier, like Crestron’s CstmFreq value = 43.

= Predefined formats (wFmtID = 5000, 5001, 6000, 7000, 8000, 9000, 9001, 900A, 900B, 900C, 900D, 900E) =
There are a number of additional, predefined IR formats, supported by some reasons. They can’t describe all IR signals, every type/subtype of this format represents only IR codes with specific structure, for custom “brand”. Also, we need additional data tables to replay these signals. These predefined formats are more compact than corresponding raw IR codes and, as a rule, simple and “clean”. I.e., if you learn IR as 5000 or 7000 and it is not a bug, then that and all other IR signals from this remote must be codes of this type.

Predefined formats have different structure, but for the reason of compatibility with format 0000, fields wFrqDiv, nOnceSeq, nRepeatSeq leave as dummy, so that code “looks” the same. aOnceSeq and aRepeatSeq are replaced with sCode, that consist real code info. Also, nOnceSeq and nRepeatSeq must meet the condition (nOnceSeq + nRepeatSeq) * 2 = sizeOf(sCode):

Template header:
{| class="wikitable"
! offset !! size !! name !! type !! description !! sample
|-
| 0 || 1 || wFmtID || word, ID || Format ID || 5000
|-
| 1 || 1 || wFrqDiv || word, dummy || Unused word for compatibility || 0000
|-
| 2 || 1 || nOnceSeq || word, dummy || Dummy code length || 0000
|-
| 3 || 1 || nRepeatSeq || word, dummy || Dummy code length || 0001
|-
| 4 || (nOnceSeq+nRepeatSeq)*2 || sCode || structure || Predefined code || 0000 0000
|}

Not all of the predefined formats are supported by any Pronto model – here a table of compatibility is:

{| class="wikitable"
! wFmtID !! RU-890/940/TS-1000/RC-5000/5000i !! TSU-2000 !! RC-5200/9200 !! TSU-6000/RU-970/USR-5 !! RAV-2000
|-
| 0000, 0100, 5000, 5001, 6000, 7000 || ✔ || ✔ || ✔ || ✔ || ✔
|-
| 8000 || || ✔ || || ✔ || ✔
|-
| 9000 || || || ✔ || ✔ || ✔
|-
| 9001 || || || || || ✔
|-
| 900A–900E || || || ✔ || ✔ ||
|}

Also, RC-3200 does not support all of this formats directly (except 0000), but RC-3200 Setup converts codes 0100, 5000, 5001 and 6000 codes into format 0000 automatically, and this feature can be used from elsewhere!

Note: 0000 format used by RC-3200 is extended by including support of unmodulated IR signals with special value of wFrqDiv = 0001.

When I describe these formats, I will translate them to format 0000, in anticipation of this converter is already exist.

= Template based formats (wFmtID = 5000, 5001, 6000, 7000, 9000, 9001, 900A, 900B, 900C, 900D, 900E) =
Template based formats are used for memory saving, for representing toggle IR codes, and for encoding IR signals with high
carrier frequency.

Segment SYS at Pronto Firmware contains 2 tables for encoding/decoding IR codes these types:

== SYS segment tables ==
{| class="wikitable"
! dID !! zSystem !! zTemplate !! zMask !! dFrqDiv !! bU1 !! dU2 !! dU3 !! dU4
|-
| 00 || rc5 || 1[01]{01}[01]%11R || 5000h + {4-8}{12,9-14} || 73 || 0 || 2 || 0 || 0A
|-
| 01 || rc6m0 || H1000ftT}[01]%16R || 6000h + {7-14}{15-22} || 73 || 0 || 0 || 0 || 0A
|-
| 02 || rc5e || 1 01]{01} [01]%5S[01]%12R || 5001h + {4-8}{12,10-15}{15-20} || 73 || 0 || 3 || 0 || 0A
|-
| 03 || b&o || 115[1234]*R?|<3[12345]* || 7000h || -09 || 0 || 5 || 0 || 14
|-
| 04 || kenwood || s$[01]%32e|rp || 7000h || -09 || 0 || 2 || 1 || 14
|-
| 05 || pioneer || o$[01]%32[RSTUo] r[01rRSTUo]* || 7000h || -04 || 0 || 4 || 1 || 14
|-
| 06 || ehrep || s[abcderst]%4[abcderst]* |s[abcderst]%4[abcderst]* || 7000h || -0C || 0 || 4 || 0 || 14
|-
| 07 || ehonce || s[abcderst]%4[abcderst]* || 7000h || -0C || 0 || 4 || 0 || 14
|-
| 08 || grundig 16ac || P{ac} [abcd]%7r || 7000h || 88 || 0 || 0 || 0 || 06
|-
| 09 || grundig 16bd || P{bd}[abcd]%7r || 7000h || 88 || 0 || 0 || 0 || 06
|-
| 0A || thomson1 || 2{12}[12]%9R || 7000h || 7C || 0 || 1 || 0 || 0E
|-
| 0B || thomson2 || {12}{12}[12]%9[RS] || 7000h || 7C || 0 || -1 || 0 || 0F
|-
| 0C || thomson3 || [12]%4{12}[12]%7[RST] || 7000h || 7C || 0 || -1 || 0 || 10
|-
| 0D || ferguson || s%2(01}[01]%9[RS] || 7000h || -0C || 1 || 4 || 0 || 0D
|-
| 0E || telefunken || (01} {01}[01]%9[RS || 7000h || -18 || 1 || -1 || 0 || 0E
|-
| 0F || echostar || T01]%5R || 7000h || 42 || 0 || -1 || 0 || 07
|-
| 10 || saba || (01}{01}[01]%9[RS || 7000h || -08 || 1 || -1 || 0 || 0E
|-
| 11 || crown || 2{12}[12]%9[RS] || 7000h || 6D || 0 || 2 || 0 || 0E
|-
| 12 || seleco || 2(12}[12]%9[RS || 7000h || 63 || 0 || 2 || 0 || 0E
|-
| 13 || nec1a || I[01]%32F|R || 900Ah + {8-1,16-9)}{24-17,32-25} || 6D || 0 || 0 || 0 || 0E
|-
| 14 || nec1b || I[01]%32F || 900Bh + {9-2,17-10}{25-18,33-26} || 6D || 0 || 0 || 0 || 0E
|-
| 15 || nec1c || I[01]%32FI[01]%32F|R || 900Ch + {8-1,16-9}{24-17,32-25} {42-35,50-43}{58-51,66-59} || 6D || 0 || 0 || 0 || 0E
|-
| 16 || nec1d || I[01]%32F|I[01]%32F || 900Dh + {8-1,16-9}{24-17,32-25} {43-36,51-44}{59-52,67-60} || 6D || 0 || 0 || 0 || 0E
|-
| 17 || nec1e || I[01]%32FI[01]%32F || 900Eh + {9-2,17-10}{25-18,33-26} {43-36,51-44}{59-52,67-60} || 6D || 0 || 0 || 0 || 0E
|-
| 18 || nec2a || I[01]%32FJR || 900Ah + {8-1,16-9}{24-17,32-25} || 68 || 0 || 0 || 0 || 0E
|-
| 19 || nec2b || I[01]%32F || 900Bh + {9-2,17-10}{25-18,33-26} || 68 || 0 || 0 || 0 || 0E
|-
| 1A || nec2c || I[01]%32FI[01]%32F|R || 900Ch + {8-1,16-9}{24-17,32-25} {42-35,50-43}{58-51,66-59} || 68 || 0 || 0 || 0 || 0E
|-
| 1B || nec2d || I[01]%32F|I[01]%32F || 900Dh + {8-1,16-9}{24-17,32-25} {43-36,51-44}{59-52,67-60} || 68 || 0 || 0 || 0 || 0E
|-
| 1C || nec2e || |I[01]%32FI[01]%32F || 900Eh + {9-2,17-10}{25-18,33-26} {43-36,51-44}{59-52,67-60} || 68 || 0 || 0 || 0 || 0E
|-
| 1D || nec || I[01]%32%F|R || 9000h + {8-1}{16-9}{24-17}{32-25} || 6D || 0 || 0 || 0 || 0E
|-
| * || rc6m6a-24 || H1110{tT}0[01]%23R || 6001h + {8-14)}{15-22}{23-30} || 73 || 0 || ? || 0 || ?
|-
| ** || rc6m6a-32 || H1110{tT} 1[01]%31R || 6001h + {8-22}{23-30}{31-38} || 73 || 0 || ? || 0 || ?
|-
| *** || yamahanec || ?I[01]%32F|R || ?9001h + {8-1}{24-17}, + {!16-19}{132 -! 25} || ?6D || 0 || 0 || 0 || ?
|}

{| class="wikitable"
! dID !! bCh !! [i] !! aBurstSeq !! dID !! bCh !! [i] !! aBurstSeq !! dID !! bCh !! [i] !! aBurstSeq
|-
| 00 || R || 0 || -0CA0 || 02 || R || 0 || -0AA0 || 03 || 1 || 5 || 005B -0546
|-
| 00 || 0 || 1 || 0020 -0020 || 02 || S || 1 || -0080 || 04 || p || 0 || 0103 -AD01
|-
| 00 || 1 || 2 || -0020 0020 || 02 || 0 || 2 || 0020 -0020 || 04 || e || 1 || 0103 -47D5
|-
| 01 || H || 0 || 0060 -0020 || 02 || 1 || 3 || -0020 0020 || 04 || s || 2 || 0103 -1745
|-
| 01 || T || 1 || 0020 -0020 || 03 || R || 0 || 005B -C422 || 04 || r || 3 || 1010 -040C
|-
| 01 || t || 2 || -0020 0020 || 03 || 5 || 1 || 005B -1BC0 || 04 || 0 || 4 || 0103 -0309
|-
| 01 || 0 || 3 || -0010 0010 || 03 || 4 || 2 || 005B -1622 || 04 || 1 || 5 || 0103 -0103
|-
| 01 || 1 || 4 || 0010 -0010 || 03 || 3 || 3 || 005B -1083 || 04 || s$ || 6 || 1010 -081E
|-
| 01 || R || 5 || -0BC0 || 03 || 2 || 4 || 005B -0AE4 || 05 || r || 0 || 227B -1160
|-
| 05 || R || 1 || 022C -8FFA || 0A || R || 0 || 0006 -0857 || 10 || S || 1 || 0009 -58D2
|-
| 05 || S || 2 || 022C -6108 || 0A || 2 || 1 || 0006 -011A || 10 || 0 || 2 || 0009 -0F3E
|-
| 05 || T || 3 || 022C -4165 || 0A || 1 || 2 || 0006 -00BB || 10 || 1 || 3 || 0009 -0A2A
|-
| 05 || o || 4 || 022C -31AF || 0B || R || 0 || 0010 -0857 || 11,12 || R || 0 || 0006 -0841
|-
| 05 || U || 5 || 022C -2C13 || 0B || S || 1 || 0010 -0642 || 11,12 || S || 1 || 0006 -065B
|-
| 05 || 0 || 6 || 022C -0684 || 0B || 2 || 2 || 0010 -0112 || 11,12 || 2 || 2 || 0006 -011A
|-
| 05 || 1 || 7 || 022C -022C || 0B || 1 || 3 || 0010 -00B1 || 11,12 || 1 || 3 || 0006 -00BB
|-
| 05 || o$ || 8 || 227B -1160 || 0C || R || 0 || 0010 -059D || 13–1D, *** || I || 0 || 0157 -00AB
|-
| 06,07 || r || 0 || 00FC -347B || 0C || S || 1 || 0010 -0417 || 13–1D, *** || F || 1 || 0016 -05E7
|-
| 06,07 || a || 1 || 00FC -00FC || 0C || T || 2 || 0010 -02FB || 13–1D, *** || 1 || 2 || 0016 -0040
|-
| 06,07 || e || 2 || 00FC -007E || 0C || 2 || 3 || 0010 -0099 || 13–1D || 0 || 3 || 0016 -0015
|-
| 06,07 || t || 3 || 007E -347B || 0C || 1 || 4 || 0010 -0044 || 13,15,18,1A || R || 4 || 0157 -0055 0016 -0E3B
|-
| 06,07 || s || 4 || 007E -0274 || 0D || R || 0 || 0008 -4B7B || * ** || H || 0 || 0070 -0020
|-
| 06,07 || b || 5 || 007E -017A || 0D || S || 1 || 0008 -3A74 || * ** || T? || 1 || 0020 -0020
|-
| 06,07 || c || 6 || 007E -00FC || 0D || 0 || 2 || 0008 -0A2B || * ** || t || 2 || -0020 0020
|-
| 06,07 || d || 7 || 007E -007E || 0D || 1 || 3 || 0008 -06C3 || * ** || 0 || 3 || -0010 0010
|-
| 08,09 || P || 0 || 0019 -005A 0028 || 0D || s || 4 || 0008 -0515 || * ** || 1 || 4 || 0010 -0010
|-
| 08,09 || a || 1 || -0044 0024 || 0E || R || 0 || 0008 -2BAE || * || R || 5 || -0AB0
|-
| 08,09 || b || 2 || -0036 0012 -000E 0012 || 0E || S || 1 || 0008 -2104 || ** || R || 5 || -09B0
|-
| 08,09 || c || 3 || -0022 0012 -0022 0012 || 0E || 0 || 2 || 0008 -05CA || 10 || R || 0 || 0009 -74F3
|-
| 08,09 || d || 4 || -000E 0012 -0036 0012 || 0E || 1 || 3 || 0008 -03D9 || || || ||
|-
| 08,09 || r || 5 || -07FC || 0F || R || 0 || 0019 -024C || || || ||
|-
| 0F || 0 || 1 || 0019 -010A || 0F || 1 || 2 || 0019 -00AF || || || ||
|}

At the first table: 
dID – subformat, used at format 7000 and for connection with second table
zSystem – unused string, “brand”-like description of dID
zTemplate – template of logical structure of IR signal of this type (dID)
:<letters> and <numbers> - are references as bCh to second table, where they (with dID) point out to a concrete aBurstSeq
:| – delimits once sequence and repeat sequence parts
:[<chars>] – means any of suggested characters
:{<char1><char2>} – corresponds to toggle bit: at odd replaying of IR code of this type must be <char1>, at even – <char2>
:%<number> - means <number> of duplicates of previous character/term
:<nowiki>*</nowiki> - any number of any previously defined characters at [<chars>]
:<char>$ - strange 2-byte name for char, nothing else :)
:?, < - garbage that must be ignored :)
zMask – mask, correspondence between zTemplate and IR code at Fixed Size Template Based Formats. Be described at these formats. zMask is used while learning only.
:Hexadecimal word is wFmtID
:{<expression>} – means description of corresponded word from sCode
:<number> - means index at forming String Code for corresponded bit at sCode word
:<number1>-<number2> - means a range (inversed range) of these bounds – <number1>, <number1+(-)1>, …,
::<number2>
:!<number> – means index at String Code for logical negation of corresponded bit at sCode
dFrqDiv – carrier frequency divider. “-“ means high (>58KHz?) frequency, that is need to be analyzed (when learning) with another filter, I think, so “-“ must be ignored.
bU1, dU2, dU3, dU4 – additional class/format characteristics. I suppose, they are used by recognition routine, or as additional info, like index of developer, who encodes special code for this format/subformat :), and must be ignored at replaying/converting.

At the second table: 
dID – same as at the first table
bCh – means index (char) from zTemplate or String Code
[i] – means index to aBurstSeq from aCode (same as wCIdx) at Predefined Codes of Variable Length (7000)
aBurstSeq – analogue of burst pair with variable length – from 1 to 4 words. Positive words mean time when LED flashes, negative – when LED is off.

= Template Based Formats of Fixed Size (wFmtID = 5000, 5001, 6000, 9000, 9001, 900A, 900B, 900C, 900D, 900E) =

Template based formats of fixed size represent strongly defined IR signals of common brands. As a rule, IR signal, leaned at this format, is the only and “clean” (but I have trouble with RC9200 + Onkyo DVD – it learns its IR codes as 900A mistakenly). IR codes at this format are short, sCode can be 2, 3 or 4 words length, and every of this word means anything like “System”, “Command” or “Data” but that meanings are not essential for converting.

Now, the ranges of that codes:

5000 0000 0000 0001 0000 0000 – 5000 0000 0000 0001 001f 007f

5001 0000 0000 0002 0000 0000 0000 0000 – 5001 0000 0000 0002 001f 007f 003f 0000 
Note: it looks like erratum at firmware table, really zMask for dID = 02 must be 5001h + {4-8}{!2,10-15}{16-21}. This bug causes
a real brain pain: any RC5x code can not be learned by any Pronto! But replaying of these codes works OK, because zMask is not
used for replay.

6000 0000 0000 0001 0000 0000 – 6000 0000 0000 0001 00ff 00ff 
Note: [2] contains description of RC6 Mode 6A as format 6001 with toggle bit, as all other RC-formats. Currently software
represents that codes at format 0000 without toggle bit. I have inserted corresponded (obsolete?) entries * and ** to the end of
firmware tables from [2] for considerations of universality: 
(<nowiki>*</nowiki>subformat of 6001, where first argument (Customer Code) is in range of 0000..007f)

6001 0000 0000 0002 0000 0000 0000 0000 – 6001 0000 0000 0002 007f 00ff 00ff 0000 
(<nowiki>**</nowiki>subformat of 6001, where first argument is in range of 8000..ffff)

6001 0000 0000 0002 8000 0000 0000 0000 – 6001 0000 0000 0002 ffff 00ff 00ff 0000

9000 0000 0000 0002 0000 0000 0000 0000 – 9000 0000 0000 0002 00ff 00ff 00ff 00ff

900a 0000 0000 0001 0000 0000 – 900a 0000 0000 0001 ffff ffff 
Note: These codes represent most common (may be, after RC) IR signal type (32bits NEC). Usually it consist of 8bit device code, 8bit device code binary compliment, 8bit function code and 8bit function code binary compliment [3,4]. All Pronto models, except RC5200, RC-9200, TSU-6000, RU-970, USR-5 must learn this type of IR signals as 0000 006* 0022 0002 0157 …, and it works fine. New Pronto models can replay formats 900A to 900E, but recognition routine is inclined to learn all NEC IR signals as format 900A, that often results in fsults.

900b 0000 0000 0001 0000 0000 – 900b 0000 0000 0001 ffff ffff

900c 0000 0000 0002 0000 0000 0000 0000 – 900c 0000 0000 0002 ffff ffff ffff ffff

900d 0000 0000 0002 0000 0000 0000 0000 – 900d 0000 0000 0002 ffff ffff ffff ffff

900e 0000 0000 0002 0000 0000 0000 0000 – 900e 0000 0000 0002 ffff ffff ffff ffff

9001 0000 0000 0001 0000 0000 – 9001 0000 0000 0001 00ff 00ff

Note: format 9001 is supported only by RAV-2000, but absent in all tables. I can’t check it, and I hope that codes, described at [3,4] are the same, so I have inserted it to firmware tables as ***. 

For converting that codes to format 0000 I offer this procedure: 
* Obtaining String Code from zTemplate, zMask and source code
* Obtaining raw IR data by indexing from String Code
* Forming IR code at format 0000 from raw IR data

[[Image:Pronto-formats-7-converting.jpg]] 
''Picture 7: Converting IR code of template based format of fixed size into format 0000 '' 
Note: 0CE0 = -0020 (last “0” at String Code ) + -0CA0 (“R”) + -0020 (first “1”)

= Predefined code of variable length (wFmtID = 7000) =
This format is for representing IR signals that can not (yet) be easily encoded as predefined format of fixed size. The structure of this
code is described on sample - Grundig 7000 0088 0000 0007 0008 000b 0010 0000 0017 0001 0001 0001
0001 0001 0001 0001 0005 0044:

{| class="wikitable"
! offset !! size !! name !! type !! description !! sample
|-
| 0 || 1 || wFmtID || word, ID || Format ID = 7000 || 7000
|-
| 1 || 1 || wFrqDiv || word, dummy || Unused word || 0088
|-
| 2 || 1 || nOnceSeq || word, dummy || Dummy length || 0000
|-
| 3 || 1 || nRepeatSeq || word, dummy || Dummy length || 0007
|-
| 4 || 1 || wSubFmtID || word, ID || SubFormat ID (dID) || 0008
|-
| 5 || 1 || nCodeSeq || word, length || Length of aCode || 000B
|-
| 6 || nCodeSeq || aCode || array of wCIdx || Code. Every word point a word in String Code || 0010 0000 0017 0001 0001 0001 0001 0001 0001 0001 0005
|-
| 6+nCodeSeq || 0 or 1 || wRest || word, dummy || Unused word for compatibility, it is present if nCodeSeq is odd || 0044
|}

Also, nOnceSeq and nRepeatSeq must meet the condition (nOnceSeq + nRepeatSeq) * 2 = 2 + nCodeSeq + sizeOf( wRest
)
Converting procedure is the same as previous one except String Code obtaining, that I describe now: 
Character choosing to String Code depends on value of corresponded wCIdx from aCode: 
- if wCIdx < 0010, then corresponded bCh indexes from second firmware table dID bCh [i] , where dID = wSubFmtID and [i] = wCIdx 
- if wCIdx = 0010, then bCh = “|” 
- if wCIdx > 0010, then this char is toggle. On odd code (of this subformat) replaying bCh is equal (wCIdx – 14h)-th char of
corresponded zTemplate: bCh = zTemplate[ wCIdx – 14 ], where first index in zTemplate is 0. On even code replaying – next
char: bCh = zTemplate[ wCIdx – 13 ]:

[[Image:Pronto-formats-8-forming.jpg]] 
''Figure placeholder: Picture 8 — Forming String Code from 7000''

= Index to UDB (wFmtID = 8000) =
Some models support an internal IR database (UDB). Others rely on software DBs.

'''Database availability'''
{| class="wikitable"
! model !! DB type !! file !! size
|-
| TS-1000, RU-890, RU-940 || IR database at ProntoEdit || rcir.mdb (Jet) || 360,448
|-
| TSU-2000, TSU-6000 || UDB || UDP_int.hex || 362,711
|-
| RU-970 || UDB || UDP_int.hex || 662,090
|-
| TSU-500 || UDB as part of || TSU500.dat (Jet) || 5,851,136
|-
| RU-930 || UDB as part of || RU930.dat (Jet) || 7,299,072
|-
| TSU-3000 || UDB || UDB_TSU3000.bin || 422,622
|-
| RC-5000/5000i/5200/9200 || IR database at TSS || rcir.mdb (Jet) || 978,944
|-
| RC-3200 || — || — || —
|-
| RAV-2000 || UDB || ww_udp.idb || 662,090
|-
| USR-5 || UDB || ww_udp.idb || 661,011
|}

'''Code example (Power On for Amp Yamaha, code set 1):'''
<code>8000 0000 0002 0000 000a 23f0 0002 0000</code>

Structure:
{| class="wikitable"
! offset !! size !! name !! type !! description !! sample
|-
| 0 || 1 || wFmtID || word, ID || Must be 8000 || 8000
|-
| 1 || 1 || wFrqDiv || word, dummy || Unused || 0000
|-
| 2 || 1 || nOnceSeq || word, dummy || Dummy length || 0002
|-
| 3 || 1 || nRepeatSeq || word, dummy || Dummy length || 0000
|-
| 4 || 1 || wDevType || word, index || Device type (000A = Amp) || 000A
|-
| 5 || 1 || wBrandCodeSet || word, index || Brand/Code Set (23F0 = Yamaha-1) || 23F0
|-
| 6 || 1 || wFunction || word, index || Function (0002 = Power On) || 0002
|-
| 7 || 1 || wRest || word, dummy || Padding to even words || 0000
|}

Functions and device-type enumerations follow the UDB. Not all combinations are supported across all models.

= References =
There are a number of articles about IR formats applied to Pronto on the internet:
# Daniel Tonks “Unofficial Philips Pronto & Marantz RC5000 FAQ”, http://www.remotecentral.com
# Marcel Majoor “Communicating with the Pronto”, http://home.hccnet.nl/m.majoor
# Barry Gordon “ProntoEdit’s IR Display Format”, http://the-gordons.net:8080/, http://www.remotecentral.com/features/irdisp1.htm
# Barry Shaw, Rob Crowe, Andrea Whitlock “Yamaha extended IR codes”, http://darius.mobius-soft.com/~andrea/
# Stewart Allen, “The CCF file format”, http://giantlaser.com/tonto/

----
''Author note:'' Please excuse my poor English. For questions about Pronto IR you can reach me at eoulianov@hotbox.ru, and I will try to answer more clearly :)

File:Pronto-formats-8-forming.jpg

2025-11-22T22:49:12Z

The Robman:

Pronto IR Formats

2025-11-22T22:41:47Z

The Robman: /* Template Based Formats of Fixed Size (wFmtID = 5000, 5001, 6000, 9000, 9001, 900A, 900B, 900C, 900D, 900E) */

= Pronto IR Formats =

== Preamble ==
This article describes in detail the formats of IR code filing for Pronto and ProntoPro models (RU-890, RU-940, RU-970, TS-1000, TSU-2000, TSU-6000, RC-5000, RC-5000i, RC-5200, RC-9200, RAV-2000, USR-5). It is supposed to be interesting for:
* those, who want to clean up his IR codes — in order to find out what all the numbers in field “IR code:” mean and for troubleshooting;
* those, who want to develop an IR code converter into other driver/configuration formats — Crestron (.IR), AMX (.IRL), Xantech (.PAL), Niles (.LIN), ADI Ocelot (.LIR), RedRat2 (.TXT), Denon RC-8000 (.RCX), ProntoNeo (.NCF), ProntoNG (.PCF) etc, as a manual of most popular and complicated IMHO IR code format.

It is advisable for you to have a notion of modulated IR signals transmission [1], but I will also coin that terms for completeness. References to some concepts can be earlier than the description of theirs, so as not to touch on same concept doubly. I am not going to mention the details of realization which is not essential for the description of the format.

== Acknowledgments ==
I would like to thank Daniel Tonks, Stewart Allen, Barry Gordon, Marcel Majoor, Steven Keyser, Bertrand Gillis, Loran Richardson, Bernard Barrier, Barry Shaw, Rob Crowe, Andrea Whitlock, those, who reply at forums — for help and support, my wife — for indulgence and star50fiveoh — for sober intolerance to this article's subject :)

== Warning ==
Standard warning about “… your own risk” is in effect.

== Buttons, signals, commands and codes ==
In order to avoid involving in terms, I specify them precisely:

[[Image:Pronto-formats-buttons.jpg]] 
''Figure placeholder: Picture 1 — Interaction of buttons, IR signals, commands and IR codes''

The button, IR signal, command and IR code are not corresponding mutually:
* the same button can produce different IR signals (see Toggle Codes);
* different IR signals can be recognized by decoder as same command (see Clean and Dirty Codes);
* the same IR signal can be encoded as a number of IR codes in different formats.

== Modulated IR signal ==
For some reasons, mainly for simplicity and interference immunity, almost all IR signals, currently used to IR translation, have the same structure. IR transmitter includes a square-wave generator (oscillator), coder and IR LED. All the time of transfer oscillator generates square impulses with fixed (for this remote) carrier frequency; depending on pressed button (and, may be, remote mode), coder forms a code of command — sequence of conventional logical 0s and 1s; IR LED flashes this command modulated by generated impulses.

[[Image:Pronto-formats-2-IR.jpg]] 
''Figure placeholder: Picture 2 — IR LED replays modulated IR signal''

Any modulated IR signal can be fully characterized via carrier frequency and the sequence of period amounts when emitting is on and off. For picture 2 this sequence is 6–2–4–2–4–…

Sometimes remote emits the signal all the time until the button such as VOLUME+ will released. Another way it flashes once per press, or first, once emitted signal is not the same that repeating one, followed it. So, it is convenient to suppose that in the general way IR signal consists of once part, the start emitting sequence and repeat part. For example, endless IR signal 6-2-4-2-4-6-6-3-3-12-6-3-3-12- has the once sequence 6-2-4-2-4-6 and repeat sequence 6-3-3-12: 6-2-4-2-4-6 | 6-3-3-12. All currently used IR signals can be represented either as a union of once and repeat sequences or as the only once or only repeating sequence.

[[Image:Pronto-formats-3-IR.jpg]] 
''Figure placeholder: Picture 3 — Cutting IR signal into once sequence and repeat sequence''

Usually, IR codes, describing IR signal this way, are not so long. If learned IR code is not an air conditioner code, it can be completely go in “IR code:” field at ProntoEdit.

In the most of cases carrier frequencies are nearby 35KHz, but you will certainly be lucky enough to try a remote with 175KHz, 345KHz, 455KHz or 1.1MHz.

== “Clean” and “dirty” codes ==
[1: “Unclean” and “clean” IR commands (Working With Prontoedit: Learning & Infrared)]

It is not necessary to replay IR signal precisely, IR receiver will “identify” received IR signal as correct command, if it looks like real command adequately, say, carrier frequency and burst pairs’s lengths differ from original IR signal less than for 10%. I.e. there is precise, original IR signal for every command, may be not replay-able for Pronto, and also many IR signals that Pronto can replay and IR receiver can recognize as that command. The codes of those signals may have different lengths, and the shortest one is “clean” code, and the all other codes are “dirty” and very “dirty”.

Reasons to prefer “clean” codes:
* IR signal of “clean” IR code is more recognizable by IR receiver
* some “dirty” IR codes can lead IR receiver astray or halt it
* “clean” code is shorter, and replay of it takes less time in macros
* you can visually check “clean” IR code’s accuracy — the lengths of every “clean” IR codes per remote are the same, except, may be, buttons like VOLUME+
* “clean” code is more convenient to analyzing, in order to guess a discrete command, absent at this remote
* using of “clean” IR codes stirs ambitions of punctual Prontoyers

The ordinal way to obtain “clean” IR code is cutting from existing one [1]. Sometimes it is useful to develop special software — generator of all concrete type IR codes — in order to “discover” all possible commands, supported by that device, including those absent at remotes.

Note: There is no difference in IR learning to Pronto standalone or to computer via Pronto, but sometimes this process is faulted due a communication error.

== Toggle IR codes ==
[1: Why won’t my buttons work twice in a row? (Working With Prontoedit: Learning & Infrared)]

It is necessary not to mix up toggle IR codes and toggle IR commands. Toggle Command is a command with toggle function such as standby/on, see TOAD at [1]. In contrast to that, Toggle IR Code contains as minimal 1 toggle bit, see RC5 at [2].

There are many possible troubles and noises at IR transfer — sun, fluorescent lamps, interference with another IR transfer, dust, pets, household and tremor of hesitating hand, holding remote. First two troubles can be cured by signal modulation. Other problems, concerning temporary obstacle, are solved logically. Commonly they use two different IR signals per button — one for odd presses and another for even. As a rule, these codes differ in one or two logical bits (“toggle” bit or “parity”), and both of them encode the same command. When IR decoder receives IR signal such type, it ignores the same signals (or signals with the same “parity” bit) received twice, in order to avoid taking noise as double click.

Pronto IR learning procedure uses the only button pressing, and because of it Pronto can detect as toggle codes only codes of some predefined types, that look like known codes, for example, RC5. When Pronto replays these codes, it emits in turn odd and even IR signals for every type of predefined code format (and if existing, subformat). So repeating the same alias for “long button press” in macro is not effective for toggle codes; it is necessary to convert this code to format 0000 to do it.

If Pronto learns real toggle codes as ordinary, learn all codes in the same parity, and only the “blank” command (that does nothing, if it exists at remote) — in opposite parity, and give any Pronto button two actions — odd real command and even “blank” [1].

== Pronto IR code filling formats ==
[1: Type of code (Working With Prontoedit: Learning & Infrared)]

IR codes are kept in Pronto and in CCFs in bytes (as all data), but Pronto software uses two-byte hexadecimal words delimited by spaces at IR code view (editBox):
<code>0000 0070 0003 0002 0006 0002 0004 0002 0004 0006 0006 0003 0003 000C</code>

I will write all sizes and offsets in 16-bit words and all numbers in hex, if not specified otherwise. First word — '''wFmtID''' — identifies IR format.

Supported formats:
* 0000 — raw oscillated code
* 0100 — raw unmodulated code
* 5000 — RC5
* 5001 — RC5x
* 6000 — RC6 Mode 0
* 7000 — predefined code of variable length
* 8000 — index to UDB
* 9000, 900A, 900B, 900C, 900D, 900E — NEC
* 9001 — basic mode YAMAHA NEC code

[[Image:Pronto-formats-4-hierarchy.jpg]] 
''Figure placeholder: Picture 4 — hierarchy of Pronto IR formats''

= Raw formats (wFmtID = 0000 or 0100) =
They are simple, basic, most commonly used formats. Almost all IR signals can be represented (exactly or cognitive) either in 0000 or 0100 format. There is no way to encode toggle IR codes at these formats, but separately, odd and even IR code can be converted from toggle form to 0000 format.

== Raw oscillated code (wFmtID = 0000) ==
This is the format that is often implied, when they say “Pronto IR format”. It contains lengths while LED flashes and while
LED is off in carrier periods (“burst pairs”) in two optional parts - once and repeat sequences.

For example, code from pic.2 and 3 will encoded in this format as 0000 0070 0003 0002 0006 0002 0004 0002 0004
0006 0006 0003 0003 000С, where:

{| class="wikitable"
! offset !! size !! name !! type !! description !! sample
|-
| 0 || 1 || wFmtID || word, ID || Format ID. Must be 0000 || 0000
|-
| 1 || 1 || wFrqDiv || word, positive || Carrier frequency divider || 0070
|-
| 2 || 1 || nOnceSeq || word, length || Number of burst pairs at once sequence || 0003
|-
| 3 || 1 || nRepeatSeq || word, length || Number of burst pairs at repeat sequence || 0002
|-
| 4 || 2*nOnceSeq || aOnceSeq || array of rBurstPair || Once sequence || 0006 0002 0004 0002 0004 0006
|-
| 4+2*nOnceSeq || 2*nRepeatSeq || aRepeatSeq || array of rBurstPair || Repeat sequence || 0006 0003 0003 000C
|}

and rBurstPair consists of:

{| class="wikitable"
! offset !! size !! name !! type !! description !! sample
|-
| 0 || 1 || wLEDflash || word, positive || Periods when LED flashes with carrier || 0006
|-
| 1 || 1 || wLEDoff || word, positive || Periods when LED is off || 0002
|}

Details:
* wFmtID: word = 0000, Format ID
* wFrqDiv: word in range 0001..FFFF, wFrqDiv = 4,145146 MHz / <signal carrier>. So wFrqDiv = 0001 corresponds to signal carrier » 4,1 MHz, and wFrqDiv =FFFF ~ 63Hz. I have measured this constant indirectly and have obtained 4,1455±0,0006 MHz, which is close enough with magical number 4,145146 [2], and far enough from 4,194304 [5], but I can’t locate quartz oscillator with this nominal at catalogues.
* nOnceSeq: word in range 0000..0100, is equal to amount of burst pairs at once sequence
* nRepeatSeq: word in range 0000..0100, is equal to amount of burst pairs at repeat sequence
* wLEDflash: word in range 0001..FFFF, is amount of carrier frequency periods when LED flashes every first half-period and turned off for the last half-period
* wLEDoff: word in range 0001..FFFF, is amount of carrier frequency periods when the LED is off

Next picture will dispel all residuary questions:

[[Image:Pronto-formats-5-correspondence.jpg]] 
''Figure placeholder: Picture 5 — correspondence between IR-signal and IR-code at format 0000''

== Raw unmodulated code (wFmtID = 0100) ==
Same structure as 0000, but LED is continuously on for the first word of the burst pair (no carrier):

[[Image:Pronto-formats-6-difference.jpg]] 
''Figure placeholder: Picture 6 — difference between IR signals for 0000 vs 0100''

Differences:
{| class="wikitable"
! offset !! size !! name !! type !! description !! sample
|-
| 0 || 1 || wFmtID || word, ID || Format ID. Must be 0100 || 0100
|}

aBurstPair consists of:

{| class="wikitable"
! offset !! size !! name !! type !! description !! sample
|-
| 0 || 1 || wLEDon || word, positive || Periods when LED is on || 0006
|-
| 1 || 1 || wLEDoff || word, positive || Periods when LED is off || 0002
|}

This format completes format 0000 to universal description of all raw IR signals, but codes at format 0100 are rare – it is
exposed to sun light and other IR noises. I have learned only 2 devices with these codes – noname drape drive and Dish Satellite
Positioner. Nevertheless, sometimes it is useful to use IR signal without carrier, for example, for Sony Contol-S: you can replace an
IR probe at RX-77 to ordinal jack, change 0000 to 0100 at IR codes, and your Sony device will be controlled by Control-S. Some
other systems also support IR signals without carrier, like Crestron’s CstmFreq value = 43.

= Predefined formats (wFmtID = 5000, 5001, 6000, 7000, 8000, 9000, 9001, 900A, 900B, 900C, 900D, 900E) =
There are a number of additional, predefined IR formats, supported by some reasons. They can’t describe all IR signals, every type/subtype of this format represents only IR codes with specific structure, for custom “brand”. Also, we need additional data tables to replay these signals. These predefined formats are more compact than corresponding raw IR codes and, as a rule, simple and “clean”. I.e., if you learn IR as 5000 or 7000 and it is not a bug, then that and all other IR signals from this remote must be codes of this type.

Predefined formats have different structure, but for the reason of compatibility with format 0000, fields wFrqDiv, nOnceSeq, nRepeatSeq leave as dummy, so that code “looks” the same. aOnceSeq and aRepeatSeq are replaced with sCode, that consist real code info. Also, nOnceSeq and nRepeatSeq must meet the condition (nOnceSeq + nRepeatSeq) * 2 = sizeOf(sCode):

Template header:
{| class="wikitable"
! offset !! size !! name !! type !! description !! sample
|-
| 0 || 1 || wFmtID || word, ID || Format ID || 5000
|-
| 1 || 1 || wFrqDiv || word, dummy || Unused word for compatibility || 0000
|-
| 2 || 1 || nOnceSeq || word, dummy || Dummy code length || 0000
|-
| 3 || 1 || nRepeatSeq || word, dummy || Dummy code length || 0001
|-
| 4 || (nOnceSeq+nRepeatSeq)*2 || sCode || structure || Predefined code || 0000 0000
|}

Not all of the predefined formats are supported by any Pronto model – here a table of compatibility is:

{| class="wikitable"
! wFmtID !! RU-890/940/TS-1000/RC-5000/5000i !! TSU-2000 !! RC-5200/9200 !! TSU-6000/RU-970/USR-5 !! RAV-2000
|-
| 0000, 0100, 5000, 5001, 6000, 7000 || ✔ || ✔ || ✔ || ✔ || ✔
|-
| 8000 || || ✔ || || ✔ || ✔
|-
| 9000 || || || ✔ || ✔ || ✔
|-
| 9001 || || || || || ✔
|-
| 900A–900E || || || ✔ || ✔ ||
|}

Also, RC-3200 does not support all of this formats directly (except 0000), but RC-3200 Setup converts codes 0100, 5000, 5001 and 6000 codes into format 0000 automatically, and this feature can be used from elsewhere!

Note: 0000 format used by RC-3200 is extended by including support of unmodulated IR signals with special value of wFrqDiv = 0001.

When I describe these formats, I will translate them to format 0000, in anticipation of this converter is already exist.

= Template based formats (wFmtID = 5000, 5001, 6000, 7000, 9000, 9001, 900A, 900B, 900C, 900D, 900E) =
Template based formats are used for memory saving, for representing toggle IR codes, and for encoding IR signals with high
carrier frequency.

Segment SYS at Pronto Firmware contains 2 tables for encoding/decoding IR codes these types:

== SYS segment tables ==
{| class="wikitable"
! dID !! zSystem !! zTemplate !! zMask !! dFrqDiv !! bU1 !! dU2 !! dU3 !! dU4
|-
| 00 || rc5 || 1[01]{01}[01]%11R || 5000h + {4-8}{12,9-14} || 73 || 0 || 2 || 0 || 0A
|-
| 01 || rc6m0 || H1000ftT}[01]%16R || 6000h + {7-14}{15-22} || 73 || 0 || 0 || 0 || 0A
|-
| 02 || rc5e || 1 01]{01} [01]%5S[01]%12R || 5001h + {4-8}{12,10-15}{15-20} || 73 || 0 || 3 || 0 || 0A
|-
| 03 || b&o || 115[1234]*R?|<3[12345]* || 7000h || -09 || 0 || 5 || 0 || 14
|-
| 04 || kenwood || s$[01]%32e|rp || 7000h || -09 || 0 || 2 || 1 || 14
|-
| 05 || pioneer || o$[01]%32[RSTUo] r[01rRSTUo]* || 7000h || -04 || 0 || 4 || 1 || 14
|-
| 06 || ehrep || s[abcderst]%4[abcderst]* |s[abcderst]%4[abcderst]* || 7000h || -0C || 0 || 4 || 0 || 14
|-
| 07 || ehonce || s[abcderst]%4[abcderst]* || 7000h || -0C || 0 || 4 || 0 || 14
|-
| 08 || grundig 16ac || P{ac} [abcd]%7r || 7000h || 88 || 0 || 0 || 0 || 06
|-
| 09 || grundig 16bd || P{bd}[abcd]%7r || 7000h || 88 || 0 || 0 || 0 || 06
|-
| 0A || thomson1 || 2{12}[12]%9R || 7000h || 7C || 0 || 1 || 0 || 0E
|-
| 0B || thomson2 || {12}{12}[12]%9[RS] || 7000h || 7C || 0 || -1 || 0 || 0F
|-
| 0C || thomson3 || [12]%4{12}[12]%7[RST] || 7000h || 7C || 0 || -1 || 0 || 10
|-
| 0D || ferguson || s%2(01}[01]%9[RS] || 7000h || -0C || 1 || 4 || 0 || 0D
|-
| 0E || telefunken || (01} {01}[01]%9[RS || 7000h || -18 || 1 || -1 || 0 || 0E
|-
| 0F || echostar || T01]%5R || 7000h || 42 || 0 || -1 || 0 || 07
|-
| 10 || saba || (01}{01}[01]%9[RS || 7000h || -08 || 1 || -1 || 0 || 0E
|-
| 11 || crown || 2{12}[12]%9[RS] || 7000h || 6D || 0 || 2 || 0 || 0E
|-
| 12 || seleco || 2(12}[12]%9[RS || 7000h || 63 || 0 || 2 || 0 || 0E
|-
| 13 || nec1a || I[01]%32F|R || 900Ah + {8-1,16-9)}{24-17,32-25} || 6D || 0 || 0 || 0 || 0E
|-
| 14 || nec1b || I[01]%32F || 900Bh + {9-2,17-10}{25-18,33-26} || 6D || 0 || 0 || 0 || 0E
|-
| 15 || nec1c || I[01]%32FI[01]%32F|R || 900Ch + {8-1,16-9}{24-17,32-25} {42-35,50-43}{58-51,66-59} || 6D || 0 || 0 || 0 || 0E
|-
| 16 || nec1d || I[01]%32F|I[01]%32F || 900Dh + {8-1,16-9}{24-17,32-25} {43-36,51-44}{59-52,67-60} || 6D || 0 || 0 || 0 || 0E
|-
| 17 || nec1e || I[01]%32FI[01]%32F || 900Eh + {9-2,17-10}{25-18,33-26} {43-36,51-44}{59-52,67-60} || 6D || 0 || 0 || 0 || 0E
|-
| 18 || nec2a || I[01]%32FJR || 900Ah + {8-1,16-9}{24-17,32-25} || 68 || 0 || 0 || 0 || 0E
|-
| 19 || nec2b || I[01]%32F || 900Bh + {9-2,17-10}{25-18,33-26} || 68 || 0 || 0 || 0 || 0E
|-
| 1A || nec2c || I[01]%32FI[01]%32F|R || 900Ch + {8-1,16-9}{24-17,32-25} {42-35,50-43}{58-51,66-59} || 68 || 0 || 0 || 0 || 0E
|-
| 1B || nec2d || I[01]%32F|I[01]%32F || 900Dh + {8-1,16-9}{24-17,32-25} {43-36,51-44}{59-52,67-60} || 68 || 0 || 0 || 0 || 0E
|-
| 1C || nec2e || |I[01]%32FI[01]%32F || 900Eh + {9-2,17-10}{25-18,33-26} {43-36,51-44}{59-52,67-60} || 68 || 0 || 0 || 0 || 0E
|-
| 1D || nec || I[01]%32%F|R || 9000h + {8-1}{16-9}{24-17}{32-25} || 6D || 0 || 0 || 0 || 0E
|-
| * || rc6m6a-24 || H1110{tT}0[01]%23R || 6001h + {8-14)}{15-22}{23-30} || 73 || 0 || ? || 0 || ?
|-
| ** || rc6m6a-32 || H1110{tT} 1[01]%31R || 6001h + {8-22}{23-30}{31-38} || 73 || 0 || ? || 0 || ?
|-
| *** || yamahanec || ?I[01]%32F|R || ?9001h + {8-1}{24-17}, + {!16-19}{132 -! 25} || ?6D || 0 || 0 || 0 || ?
|}

{| class="wikitable"
! dID !! bCh !! [i] !! aBurstSeq !! dID !! bCh !! [i] !! aBurstSeq !! dID !! bCh !! [i] !! aBurstSeq
|-
| 00 || R || 0 || -0CA0 || 02 || R || 0 || -0AA0 || 03 || 1 || 5 || 005B -0546
|-
| 00 || 0 || 1 || 0020 -0020 || 02 || S || 1 || -0080 || 04 || p || 0 || 0103 -AD01
|-
| 00 || 1 || 2 || -0020 0020 || 02 || 0 || 2 || 0020 -0020 || 04 || e || 1 || 0103 -47D5
|-
| 01 || H || 0 || 0060 -0020 || 02 || 1 || 3 || -0020 0020 || 04 || s || 2 || 0103 -1745
|-
| 01 || T || 1 || 0020 -0020 || 03 || R || 0 || 005B -C422 || 04 || r || 3 || 1010 -040C
|-
| 01 || t || 2 || -0020 0020 || 03 || 5 || 1 || 005B -1BC0 || 04 || 0 || 4 || 0103 -0309
|-
| 01 || 0 || 3 || -0010 0010 || 03 || 4 || 2 || 005B -1622 || 04 || 1 || 5 || 0103 -0103
|-
| 01 || 1 || 4 || 0010 -0010 || 03 || 3 || 3 || 005B -1083 || 04 || s$ || 6 || 1010 -081E
|-
| 01 || R || 5 || -0BC0 || 03 || 2 || 4 || 005B -0AE4 || 05 || r || 0 || 227B -1160
|-
| 05 || R || 1 || 022C -8FFA || 0A || R || 0 || 0006 -0857 || 10 || S || 1 || 0009 -58D2
|-
| 05 || S || 2 || 022C -6108 || 0A || 2 || 1 || 0006 -011A || 10 || 0 || 2 || 0009 -0F3E
|-
| 05 || T || 3 || 022C -4165 || 0A || 1 || 2 || 0006 -00BB || 10 || 1 || 3 || 0009 -0A2A
|-
| 05 || o || 4 || 022C -31AF || 0B || R || 0 || 0010 -0857 || 11,12 || R || 0 || 0006 -0841
|-
| 05 || U || 5 || 022C -2C13 || 0B || S || 1 || 0010 -0642 || 11,12 || S || 1 || 0006 -065B
|-
| 05 || 0 || 6 || 022C -0684 || 0B || 2 || 2 || 0010 -0112 || 11,12 || 2 || 2 || 0006 -011A
|-
| 05 || 1 || 7 || 022C -022C || 0B || 1 || 3 || 0010 -00B1 || 11,12 || 1 || 3 || 0006 -00BB
|-
| 05 || o$ || 8 || 227B -1160 || 0C || R || 0 || 0010 -059D || 13–1D, *** || I || 0 || 0157 -00AB
|-
| 06,07 || r || 0 || 00FC -347B || 0C || S || 1 || 0010 -0417 || 13–1D, *** || F || 1 || 0016 -05E7
|-
| 06,07 || a || 1 || 00FC -00FC || 0C || T || 2 || 0010 -02FB || 13–1D, *** || 1 || 2 || 0016 -0040
|-
| 06,07 || e || 2 || 00FC -007E || 0C || 2 || 3 || 0010 -0099 || 13–1D || 0 || 3 || 0016 -0015
|-
| 06,07 || t || 3 || 007E -347B || 0C || 1 || 4 || 0010 -0044 || 13,15,18,1A || R || 4 || 0157 -0055 0016 -0E3B
|-
| 06,07 || s || 4 || 007E -0274 || 0D || R || 0 || 0008 -4B7B || * ** || H || 0 || 0070 -0020
|-
| 06,07 || b || 5 || 007E -017A || 0D || S || 1 || 0008 -3A74 || * ** || T? || 1 || 0020 -0020
|-
| 06,07 || c || 6 || 007E -00FC || 0D || 0 || 2 || 0008 -0A2B || * ** || t || 2 || -0020 0020
|-
| 06,07 || d || 7 || 007E -007E || 0D || 1 || 3 || 0008 -06C3 || * ** || 0 || 3 || -0010 0010
|-
| 08,09 || P || 0 || 0019 -005A 0028 || 0D || s || 4 || 0008 -0515 || * ** || 1 || 4 || 0010 -0010
|-
| 08,09 || a || 1 || -0044 0024 || 0E || R || 0 || 0008 -2BAE || * || R || 5 || -0AB0
|-
| 08,09 || b || 2 || -0036 0012 -000E 0012 || 0E || S || 1 || 0008 -2104 || ** || R || 5 || -09B0
|-
| 08,09 || c || 3 || -0022 0012 -0022 0012 || 0E || 0 || 2 || 0008 -05CA || 10 || R || 0 || 0009 -74F3
|-
| 08,09 || d || 4 || -000E 0012 -0036 0012 || 0E || 1 || 3 || 0008 -03D9 || || || ||
|-
| 08,09 || r || 5 || -07FC || 0F || R || 0 || 0019 -024C || || || ||
|-
| 0F || 0 || 1 || 0019 -010A || 0F || 1 || 2 || 0019 -00AF || || || ||
|}

At the first table: 
dID – subformat, used at format 7000 and for connection with second table
zSystem – unused string, “brand”-like description of dID
zTemplate – template of logical structure of IR signal of this type (dID)
:<letters> and <numbers> - are references as bCh to second table, where they (with dID) point out to a concrete aBurstSeq
:| – delimits once sequence and repeat sequence parts
:[<chars>] – means any of suggested characters
:{<char1><char2>} – corresponds to toggle bit: at odd replaying of IR code of this type must be <char1>, at even – <char2>
:%<number> - means <number> of duplicates of previous character/term
:<nowiki>*</nowiki> - any number of any previously defined characters at [<chars>]
:<char>$ - strange 2-byte name for char, nothing else :)
:?, < - garbage that must be ignored :)
zMask – mask, correspondence between zTemplate and IR code at Fixed Size Template Based Formats. Be described at these formats. zMask is used while learning only.
:Hexadecimal word is wFmtID
:{<expression>} – means description of corresponded word from sCode
:<number> - means index at forming String Code for corresponded bit at sCode word
:<number1>-<number2> - means a range (inversed range) of these bounds – <number1>, <number1+(-)1>, …,
::<number2>
:!<number> – means index at String Code for logical negation of corresponded bit at sCode
dFrqDiv – carrier frequency divider. “-“ means high (>58KHz?) frequency, that is need to be analyzed (when learning) with another filter, I think, so “-“ must be ignored.
bU1, dU2, dU3, dU4 – additional class/format characteristics. I suppose, they are used by recognition routine, or as additional info, like index of developer, who encodes special code for this format/subformat :), and must be ignored at replaying/converting.

At the second table: 
dID – same as at the first table
bCh – means index (char) from zTemplate or String Code
[i] – means index to aBurstSeq from aCode (same as wCIdx) at Predefined Codes of Variable Length (7000)
aBurstSeq – analogue of burst pair with variable length – from 1 to 4 words. Positive words mean time when LED flashes, negative – when LED is off.

= Template Based Formats of Fixed Size (wFmtID = 5000, 5001, 6000, 9000, 9001, 900A, 900B, 900C, 900D, 900E) =

Template based formats of fixed size represent strongly defined IR signals of common brands. As a rule, IR signal, leaned at this format, is the only and “clean” (but I have trouble with RC9200 + Onkyo DVD – it learns its IR codes as 900A mistakenly). IR codes at this format are short, sCode can be 2, 3 or 4 words length, and every of this word means anything like “System”, “Command” or “Data” but that meanings are not essential for converting.

Now, the ranges of that codes:

5000 0000 0000 0001 0000 0000 – 5000 0000 0000 0001 001f 007f

5001 0000 0000 0002 0000 0000 0000 0000 – 5001 0000 0000 0002 001f 007f 003f 0000 
Note: it looks like erratum at firmware table, really zMask for dID = 02 must be 5001h + {4-8}{!2,10-15}{16-21}. This bug causes
a real brain pain: any RC5x code can not be learned by any Pronto! But replaying of these codes works OK, because zMask is not
used for replay.

6000 0000 0000 0001 0000 0000 – 6000 0000 0000 0001 00ff 00ff 
Note: [2] contains description of RC6 Mode 6A as format 6001 with toggle bit, as all other RC-formats. Currently software
represents that codes at format 0000 without toggle bit. I have inserted corresponded (obsolete?) entries * and ** to the end of
firmware tables from [2] for considerations of universality: 
(<nowiki>*</nowiki>subformat of 6001, where first argument (Customer Code) is in range of 0000..007f)

6001 0000 0000 0002 0000 0000 0000 0000 – 6001 0000 0000 0002 007f 00ff 00ff 0000 
(<nowiki>**</nowiki>subformat of 6001, where first argument is in range of 8000..ffff)

6001 0000 0000 0002 8000 0000 0000 0000 – 6001 0000 0000 0002 ffff 00ff 00ff 0000

9000 0000 0000 0002 0000 0000 0000 0000 – 9000 0000 0000 0002 00ff 00ff 00ff 00ff

900a 0000 0000 0001 0000 0000 – 900a 0000 0000 0001 ffff ffff 
Note: These codes represent most common (may be, after RC) IR signal type (32bits NEC). Usually it consist of 8bit device code, 8bit device code binary compliment, 8bit function code and 8bit function code binary compliment [3,4]. All Pronto models, except RC5200, RC-9200, TSU-6000, RU-970, USR-5 must learn this type of IR signals as 0000 006* 0022 0002 0157 …, and it works fine. New Pronto models can replay formats 900A to 900E, but recognition routine is inclined to learn all NEC IR signals as format 900A, that often results in fsults.

900b 0000 0000 0001 0000 0000 – 900b 0000 0000 0001 ffff ffff

900c 0000 0000 0002 0000 0000 0000 0000 – 900c 0000 0000 0002 ffff ffff ffff ffff

900d 0000 0000 0002 0000 0000 0000 0000 – 900d 0000 0000 0002 ffff ffff ffff ffff

900e 0000 0000 0002 0000 0000 0000 0000 – 900e 0000 0000 0002 ffff ffff ffff ffff

9001 0000 0000 0001 0000 0000 – 9001 0000 0000 0001 00ff 00ff

Note: format 9001 is supported only by RAV-2000, but absent in all tables. I can’t check it, and I hope that codes, described at [3,4] are the same, so I have inserted it to firmware tables as ***. 

For converting that codes to format 0000 I offer this procedure: 
* Obtaining String Code from zTemplate, zMask and source code
* Obtaining raw IR data by indexing from String Code
* Forming IR code at format 0000 from raw IR data

[[Image:Pronto-formats-7-converting.jpg]] 
''Picture 7: Converting IR code of template based format of fixed size into format 0000 '' 
Note: 0CE0 = -0020 (last “0” at String Code ) + -0CA0 (“R”) + -0020 (first “1”)

= Predefined code of variable length (wFmtID = 7000) =
Structure (example: Grundig):
{| class="wikitable"
! offset !! size !! name !! type !! description !! sample
|-
| 0 || 1 || wFmtID || word, ID || Format ID = 7000 || 7000
|-
| 1 || 1 || wFrqDiv || word, dummy || Unused word || 0088
|-
| 2 || 1 || nOnceSeq || word, dummy || Dummy length || 0000
|-
| 3 || 1 || nRepeatSeq || word, dummy || Dummy length || 0007
|-
| 4 || 1 || wSubFmtID || word, ID || SubFormat ID (dID) || 0008
|-
| 5 || 1 || nCodeSeq || word, length || Length of aCode || 000B
|-
| 6 || nCodeSeq || aCode || array of wCIdx || Code indexes to String Code || 0010 0000 0017 0001 0001 0001 0001 0001 0001 0001 0005
|-
| 6+nCodeSeq || 0 or 1 || wRest || word, dummy || Present if nCodeSeq is odd || 0044
|}

Condition: (nOnceSeq + nRepeatSeq) * 2 = 2 + nCodeSeq + sizeOf(wRest)

String Code selection:
* if wCIdx < 0010: use firmware table (dID, bCh, [i]) where dID = wSubFmtID and [i] = wCIdx
* if wCIdx = 0010: bCh = “1”
* if wCIdx > 0010: toggle char; odd replay uses zTemplate[wCIdx - 14], even uses zTemplate[wCIdx - 13]

''Figure placeholder: Picture 8 — Forming String Code from 7000''

= Index to UDB (wFmtID = 8000) =
Some models support an internal IR database (UDB). Others rely on software DBs.

'''Database availability'''
{| class="wikitable"
! model !! DB type !! file !! size
|-
| TS-1000, RU-890, RU-940 || IR database at ProntoEdit || rcir.mdb (Jet) || 360,448
|-
| TSU-2000, TSU-6000 || UDB || UDP_int.hex || 362,711
|-
| RU-970 || UDB || UDP_int.hex || 662,090
|-
| TSU-500 || UDB as part of || TSU500.dat (Jet) || 5,851,136
|-
| RU-930 || UDB as part of || RU930.dat (Jet) || 7,299,072
|-
| TSU-3000 || UDB || UDB_TSU3000.bin || 422,622
|-
| RC-5000/5000i/5200/9200 || IR database at TSS || rcir.mdb (Jet) || 978,944
|-
| RC-3200 || — || — || —
|-
| RAV-2000 || UDB || ww_udp.idb || 662,090
|-
| USR-5 || UDB || ww_udp.idb || 661,011
|}

'''Code example (Power On for Amp Yamaha, code set 1):'''
<code>8000 0000 0002 0000 000a 23f0 0002 0000</code>

Structure:
{| class="wikitable"
! offset !! size !! name !! type !! description !! sample
|-
| 0 || 1 || wFmtID || word, ID || Must be 8000 || 8000
|-
| 1 || 1 || wFrqDiv || word, dummy || Unused || 0000
|-
| 2 || 1 || nOnceSeq || word, dummy || Dummy length || 0002
|-
| 3 || 1 || nRepeatSeq || word, dummy || Dummy length || 0000
|-
| 4 || 1 || wDevType || word, index || Device type (000A = Amp) || 000A
|-
| 5 || 1 || wBrandCodeSet || word, index || Brand/Code Set (23F0 = Yamaha-1) || 23F0
|-
| 6 || 1 || wFunction || word, index || Function (0002 = Power On) || 0002
|-
| 7 || 1 || wRest || word, dummy || Padding to even words || 0000
|}

Functions and device-type enumerations follow the UDB. Not all combinations are supported across all models.

= References =
There are a number of articles about IR formats applied to Pronto on the internet:
# Daniel Tonks “Unofficial Philips Pronto & Marantz RC5000 FAQ”, http://www.remotecentral.com
# Marcel Majoor “Communicating with the Pronto”, http://home.hccnet.nl/m.majoor
# Barry Gordon “ProntoEdit’s IR Display Format”, http://the-gordons.net:8080/, http://www.remotecentral.com/features/irdisp1.htm
# Barry Shaw, Rob Crowe, Andrea Whitlock “Yamaha extended IR codes”, http://darius.mobius-soft.com/~andrea/
# Stewart Allen, “The CCF file format”, http://giantlaser.com/tonto/

----
''Author note:'' Please excuse my poor English. For questions about Pronto IR you can reach me at eoulianov@hotbox.ru, and I will try to answer more clearly :)

File:Pronto-formats-7-converting.jpg

2025-11-22T22:40:13Z

The Robman:

Pronto IR Formats

2025-11-22T22:37:41Z

The Robman: /* Template Based Formats of Fixed Size (wFmtID = 5000, 5001, 6000, 9000, 9001, 900A, 900B, 900C, 900D, 900E) */

= Pronto IR Formats =

== Preamble ==
This article describes in detail the formats of IR code filing for Pronto and ProntoPro models (RU-890, RU-940, RU-970, TS-1000, TSU-2000, TSU-6000, RC-5000, RC-5000i, RC-5200, RC-9200, RAV-2000, USR-5). It is supposed to be interesting for:
* those, who want to clean up his IR codes — in order to find out what all the numbers in field “IR code:” mean and for troubleshooting;
* those, who want to develop an IR code converter into other driver/configuration formats — Crestron (.IR), AMX (.IRL), Xantech (.PAL), Niles (.LIN), ADI Ocelot (.LIR), RedRat2 (.TXT), Denon RC-8000 (.RCX), ProntoNeo (.NCF), ProntoNG (.PCF) etc, as a manual of most popular and complicated IMHO IR code format.

It is advisable for you to have a notion of modulated IR signals transmission [1], but I will also coin that terms for completeness. References to some concepts can be earlier than the description of theirs, so as not to touch on same concept doubly. I am not going to mention the details of realization which is not essential for the description of the format.

== Acknowledgments ==
I would like to thank Daniel Tonks, Stewart Allen, Barry Gordon, Marcel Majoor, Steven Keyser, Bertrand Gillis, Loran Richardson, Bernard Barrier, Barry Shaw, Rob Crowe, Andrea Whitlock, those, who reply at forums — for help and support, my wife — for indulgence and star50fiveoh — for sober intolerance to this article's subject :)

== Warning ==
Standard warning about “… your own risk” is in effect.

== Buttons, signals, commands and codes ==
In order to avoid involving in terms, I specify them precisely:

[[Image:Pronto-formats-buttons.jpg]] 
''Figure placeholder: Picture 1 — Interaction of buttons, IR signals, commands and IR codes''

The button, IR signal, command and IR code are not corresponding mutually:
* the same button can produce different IR signals (see Toggle Codes);
* different IR signals can be recognized by decoder as same command (see Clean and Dirty Codes);
* the same IR signal can be encoded as a number of IR codes in different formats.

== Modulated IR signal ==
For some reasons, mainly for simplicity and interference immunity, almost all IR signals, currently used to IR translation, have the same structure. IR transmitter includes a square-wave generator (oscillator), coder and IR LED. All the time of transfer oscillator generates square impulses with fixed (for this remote) carrier frequency; depending on pressed button (and, may be, remote mode), coder forms a code of command — sequence of conventional logical 0s and 1s; IR LED flashes this command modulated by generated impulses.

[[Image:Pronto-formats-2-IR.jpg]] 
''Figure placeholder: Picture 2 — IR LED replays modulated IR signal''

Any modulated IR signal can be fully characterized via carrier frequency and the sequence of period amounts when emitting is on and off. For picture 2 this sequence is 6–2–4–2–4–…

Sometimes remote emits the signal all the time until the button such as VOLUME+ will released. Another way it flashes once per press, or first, once emitted signal is not the same that repeating one, followed it. So, it is convenient to suppose that in the general way IR signal consists of once part, the start emitting sequence and repeat part. For example, endless IR signal 6-2-4-2-4-6-6-3-3-12-6-3-3-12- has the once sequence 6-2-4-2-4-6 and repeat sequence 6-3-3-12: 6-2-4-2-4-6 | 6-3-3-12. All currently used IR signals can be represented either as a union of once and repeat sequences or as the only once or only repeating sequence.

[[Image:Pronto-formats-3-IR.jpg]] 
''Figure placeholder: Picture 3 — Cutting IR signal into once sequence and repeat sequence''

Usually, IR codes, describing IR signal this way, are not so long. If learned IR code is not an air conditioner code, it can be completely go in “IR code:” field at ProntoEdit.

In the most of cases carrier frequencies are nearby 35KHz, but you will certainly be lucky enough to try a remote with 175KHz, 345KHz, 455KHz or 1.1MHz.

== “Clean” and “dirty” codes ==
[1: “Unclean” and “clean” IR commands (Working With Prontoedit: Learning & Infrared)]

It is not necessary to replay IR signal precisely, IR receiver will “identify” received IR signal as correct command, if it looks like real command adequately, say, carrier frequency and burst pairs’s lengths differ from original IR signal less than for 10%. I.e. there is precise, original IR signal for every command, may be not replay-able for Pronto, and also many IR signals that Pronto can replay and IR receiver can recognize as that command. The codes of those signals may have different lengths, and the shortest one is “clean” code, and the all other codes are “dirty” and very “dirty”.

Reasons to prefer “clean” codes:
* IR signal of “clean” IR code is more recognizable by IR receiver
* some “dirty” IR codes can lead IR receiver astray or halt it
* “clean” code is shorter, and replay of it takes less time in macros
* you can visually check “clean” IR code’s accuracy — the lengths of every “clean” IR codes per remote are the same, except, may be, buttons like VOLUME+
* “clean” code is more convenient to analyzing, in order to guess a discrete command, absent at this remote
* using of “clean” IR codes stirs ambitions of punctual Prontoyers

The ordinal way to obtain “clean” IR code is cutting from existing one [1]. Sometimes it is useful to develop special software — generator of all concrete type IR codes — in order to “discover” all possible commands, supported by that device, including those absent at remotes.

Note: There is no difference in IR learning to Pronto standalone or to computer via Pronto, but sometimes this process is faulted due a communication error.

== Toggle IR codes ==
[1: Why won’t my buttons work twice in a row? (Working With Prontoedit: Learning & Infrared)]

It is necessary not to mix up toggle IR codes and toggle IR commands. Toggle Command is a command with toggle function such as standby/on, see TOAD at [1]. In contrast to that, Toggle IR Code contains as minimal 1 toggle bit, see RC5 at [2].

There are many possible troubles and noises at IR transfer — sun, fluorescent lamps, interference with another IR transfer, dust, pets, household and tremor of hesitating hand, holding remote. First two troubles can be cured by signal modulation. Other problems, concerning temporary obstacle, are solved logically. Commonly they use two different IR signals per button — one for odd presses and another for even. As a rule, these codes differ in one or two logical bits (“toggle” bit or “parity”), and both of them encode the same command. When IR decoder receives IR signal such type, it ignores the same signals (or signals with the same “parity” bit) received twice, in order to avoid taking noise as double click.

Pronto IR learning procedure uses the only button pressing, and because of it Pronto can detect as toggle codes only codes of some predefined types, that look like known codes, for example, RC5. When Pronto replays these codes, it emits in turn odd and even IR signals for every type of predefined code format (and if existing, subformat). So repeating the same alias for “long button press” in macro is not effective for toggle codes; it is necessary to convert this code to format 0000 to do it.

If Pronto learns real toggle codes as ordinary, learn all codes in the same parity, and only the “blank” command (that does nothing, if it exists at remote) — in opposite parity, and give any Pronto button two actions — odd real command and even “blank” [1].

== Pronto IR code filling formats ==
[1: Type of code (Working With Prontoedit: Learning & Infrared)]

IR codes are kept in Pronto and in CCFs in bytes (as all data), but Pronto software uses two-byte hexadecimal words delimited by spaces at IR code view (editBox):
<code>0000 0070 0003 0002 0006 0002 0004 0002 0004 0006 0006 0003 0003 000C</code>

I will write all sizes and offsets in 16-bit words and all numbers in hex, if not specified otherwise. First word — '''wFmtID''' — identifies IR format.

Supported formats:
* 0000 — raw oscillated code
* 0100 — raw unmodulated code
* 5000 — RC5
* 5001 — RC5x
* 6000 — RC6 Mode 0
* 7000 — predefined code of variable length
* 8000 — index to UDB
* 9000, 900A, 900B, 900C, 900D, 900E — NEC
* 9001 — basic mode YAMAHA NEC code

[[Image:Pronto-formats-4-hierarchy.jpg]] 
''Figure placeholder: Picture 4 — hierarchy of Pronto IR formats''

= Raw formats (wFmtID = 0000 or 0100) =
They are simple, basic, most commonly used formats. Almost all IR signals can be represented (exactly or cognitive) either in 0000 or 0100 format. There is no way to encode toggle IR codes at these formats, but separately, odd and even IR code can be converted from toggle form to 0000 format.

== Raw oscillated code (wFmtID = 0000) ==
This is the format that is often implied, when they say “Pronto IR format”. It contains lengths while LED flashes and while
LED is off in carrier periods (“burst pairs”) in two optional parts - once and repeat sequences.

For example, code from pic.2 and 3 will encoded in this format as 0000 0070 0003 0002 0006 0002 0004 0002 0004
0006 0006 0003 0003 000С, where:

{| class="wikitable"
! offset !! size !! name !! type !! description !! sample
|-
| 0 || 1 || wFmtID || word, ID || Format ID. Must be 0000 || 0000
|-
| 1 || 1 || wFrqDiv || word, positive || Carrier frequency divider || 0070
|-
| 2 || 1 || nOnceSeq || word, length || Number of burst pairs at once sequence || 0003
|-
| 3 || 1 || nRepeatSeq || word, length || Number of burst pairs at repeat sequence || 0002
|-
| 4 || 2*nOnceSeq || aOnceSeq || array of rBurstPair || Once sequence || 0006 0002 0004 0002 0004 0006
|-
| 4+2*nOnceSeq || 2*nRepeatSeq || aRepeatSeq || array of rBurstPair || Repeat sequence || 0006 0003 0003 000C
|}

and rBurstPair consists of:

{| class="wikitable"
! offset !! size !! name !! type !! description !! sample
|-
| 0 || 1 || wLEDflash || word, positive || Periods when LED flashes with carrier || 0006
|-
| 1 || 1 || wLEDoff || word, positive || Periods when LED is off || 0002
|}

Details:
* wFmtID: word = 0000, Format ID
* wFrqDiv: word in range 0001..FFFF, wFrqDiv = 4,145146 MHz / <signal carrier>. So wFrqDiv = 0001 corresponds to signal carrier » 4,1 MHz, and wFrqDiv =FFFF ~ 63Hz. I have measured this constant indirectly and have obtained 4,1455±0,0006 MHz, which is close enough with magical number 4,145146 [2], and far enough from 4,194304 [5], but I can’t locate quartz oscillator with this nominal at catalogues.
* nOnceSeq: word in range 0000..0100, is equal to amount of burst pairs at once sequence
* nRepeatSeq: word in range 0000..0100, is equal to amount of burst pairs at repeat sequence
* wLEDflash: word in range 0001..FFFF, is amount of carrier frequency periods when LED flashes every first half-period and turned off for the last half-period
* wLEDoff: word in range 0001..FFFF, is amount of carrier frequency periods when the LED is off

Next picture will dispel all residuary questions:

[[Image:Pronto-formats-5-correspondence.jpg]] 
''Figure placeholder: Picture 5 — correspondence between IR-signal and IR-code at format 0000''

== Raw unmodulated code (wFmtID = 0100) ==
Same structure as 0000, but LED is continuously on for the first word of the burst pair (no carrier):

[[Image:Pronto-formats-6-difference.jpg]] 
''Figure placeholder: Picture 6 — difference between IR signals for 0000 vs 0100''

Differences:
{| class="wikitable"
! offset !! size !! name !! type !! description !! sample
|-
| 0 || 1 || wFmtID || word, ID || Format ID. Must be 0100 || 0100
|}

aBurstPair consists of:

{| class="wikitable"
! offset !! size !! name !! type !! description !! sample
|-
| 0 || 1 || wLEDon || word, positive || Periods when LED is on || 0006
|-
| 1 || 1 || wLEDoff || word, positive || Periods when LED is off || 0002
|}

This format completes format 0000 to universal description of all raw IR signals, but codes at format 0100 are rare – it is
exposed to sun light and other IR noises. I have learned only 2 devices with these codes – noname drape drive and Dish Satellite
Positioner. Nevertheless, sometimes it is useful to use IR signal without carrier, for example, for Sony Contol-S: you can replace an
IR probe at RX-77 to ordinal jack, change 0000 to 0100 at IR codes, and your Sony device will be controlled by Control-S. Some
other systems also support IR signals without carrier, like Crestron’s CstmFreq value = 43.

= Predefined formats (wFmtID = 5000, 5001, 6000, 7000, 8000, 9000, 9001, 900A, 900B, 900C, 900D, 900E) =
There are a number of additional, predefined IR formats, supported by some reasons. They can’t describe all IR signals, every type/subtype of this format represents only IR codes with specific structure, for custom “brand”. Also, we need additional data tables to replay these signals. These predefined formats are more compact than corresponding raw IR codes and, as a rule, simple and “clean”. I.e., if you learn IR as 5000 or 7000 and it is not a bug, then that and all other IR signals from this remote must be codes of this type.

Predefined formats have different structure, but for the reason of compatibility with format 0000, fields wFrqDiv, nOnceSeq, nRepeatSeq leave as dummy, so that code “looks” the same. aOnceSeq and aRepeatSeq are replaced with sCode, that consist real code info. Also, nOnceSeq and nRepeatSeq must meet the condition (nOnceSeq + nRepeatSeq) * 2 = sizeOf(sCode):

Template header:
{| class="wikitable"
! offset !! size !! name !! type !! description !! sample
|-
| 0 || 1 || wFmtID || word, ID || Format ID || 5000
|-
| 1 || 1 || wFrqDiv || word, dummy || Unused word for compatibility || 0000
|-
| 2 || 1 || nOnceSeq || word, dummy || Dummy code length || 0000
|-
| 3 || 1 || nRepeatSeq || word, dummy || Dummy code length || 0001
|-
| 4 || (nOnceSeq+nRepeatSeq)*2 || sCode || structure || Predefined code || 0000 0000
|}

Not all of the predefined formats are supported by any Pronto model – here a table of compatibility is:

{| class="wikitable"
! wFmtID !! RU-890/940/TS-1000/RC-5000/5000i !! TSU-2000 !! RC-5200/9200 !! TSU-6000/RU-970/USR-5 !! RAV-2000
|-
| 0000, 0100, 5000, 5001, 6000, 7000 || ✔ || ✔ || ✔ || ✔ || ✔
|-
| 8000 || || ✔ || || ✔ || ✔
|-
| 9000 || || || ✔ || ✔ || ✔
|-
| 9001 || || || || || ✔
|-
| 900A–900E || || || ✔ || ✔ ||
|}

Also, RC-3200 does not support all of this formats directly (except 0000), but RC-3200 Setup converts codes 0100, 5000, 5001 and 6000 codes into format 0000 automatically, and this feature can be used from elsewhere!

Note: 0000 format used by RC-3200 is extended by including support of unmodulated IR signals with special value of wFrqDiv = 0001.

When I describe these formats, I will translate them to format 0000, in anticipation of this converter is already exist.

= Template based formats (wFmtID = 5000, 5001, 6000, 7000, 9000, 9001, 900A, 900B, 900C, 900D, 900E) =
Template based formats are used for memory saving, for representing toggle IR codes, and for encoding IR signals with high
carrier frequency.

Segment SYS at Pronto Firmware contains 2 tables for encoding/decoding IR codes these types:

== SYS segment tables ==
{| class="wikitable"
! dID !! zSystem !! zTemplate !! zMask !! dFrqDiv !! bU1 !! dU2 !! dU3 !! dU4
|-
| 00 || rc5 || 1[01]{01}[01]%11R || 5000h + {4-8}{12,9-14} || 73 || 0 || 2 || 0 || 0A
|-
| 01 || rc6m0 || H1000ftT}[01]%16R || 6000h + {7-14}{15-22} || 73 || 0 || 0 || 0 || 0A
|-
| 02 || rc5e || 1 01]{01} [01]%5S[01]%12R || 5001h + {4-8}{12,10-15}{15-20} || 73 || 0 || 3 || 0 || 0A
|-
| 03 || b&o || 115[1234]*R?|<3[12345]* || 7000h || -09 || 0 || 5 || 0 || 14
|-
| 04 || kenwood || s$[01]%32e|rp || 7000h || -09 || 0 || 2 || 1 || 14
|-
| 05 || pioneer || o$[01]%32[RSTUo] r[01rRSTUo]* || 7000h || -04 || 0 || 4 || 1 || 14
|-
| 06 || ehrep || s[abcderst]%4[abcderst]* |s[abcderst]%4[abcderst]* || 7000h || -0C || 0 || 4 || 0 || 14
|-
| 07 || ehonce || s[abcderst]%4[abcderst]* || 7000h || -0C || 0 || 4 || 0 || 14
|-
| 08 || grundig 16ac || P{ac} [abcd]%7r || 7000h || 88 || 0 || 0 || 0 || 06
|-
| 09 || grundig 16bd || P{bd}[abcd]%7r || 7000h || 88 || 0 || 0 || 0 || 06
|-
| 0A || thomson1 || 2{12}[12]%9R || 7000h || 7C || 0 || 1 || 0 || 0E
|-
| 0B || thomson2 || {12}{12}[12]%9[RS] || 7000h || 7C || 0 || -1 || 0 || 0F
|-
| 0C || thomson3 || [12]%4{12}[12]%7[RST] || 7000h || 7C || 0 || -1 || 0 || 10
|-
| 0D || ferguson || s%2(01}[01]%9[RS] || 7000h || -0C || 1 || 4 || 0 || 0D
|-
| 0E || telefunken || (01} {01}[01]%9[RS || 7000h || -18 || 1 || -1 || 0 || 0E
|-
| 0F || echostar || T01]%5R || 7000h || 42 || 0 || -1 || 0 || 07
|-
| 10 || saba || (01}{01}[01]%9[RS || 7000h || -08 || 1 || -1 || 0 || 0E
|-
| 11 || crown || 2{12}[12]%9[RS] || 7000h || 6D || 0 || 2 || 0 || 0E
|-
| 12 || seleco || 2(12}[12]%9[RS || 7000h || 63 || 0 || 2 || 0 || 0E
|-
| 13 || nec1a || I[01]%32F|R || 900Ah + {8-1,16-9)}{24-17,32-25} || 6D || 0 || 0 || 0 || 0E
|-
| 14 || nec1b || I[01]%32F || 900Bh + {9-2,17-10}{25-18,33-26} || 6D || 0 || 0 || 0 || 0E
|-
| 15 || nec1c || I[01]%32FI[01]%32F|R || 900Ch + {8-1,16-9}{24-17,32-25} {42-35,50-43}{58-51,66-59} || 6D || 0 || 0 || 0 || 0E
|-
| 16 || nec1d || I[01]%32F|I[01]%32F || 900Dh + {8-1,16-9}{24-17,32-25} {43-36,51-44}{59-52,67-60} || 6D || 0 || 0 || 0 || 0E
|-
| 17 || nec1e || I[01]%32FI[01]%32F || 900Eh + {9-2,17-10}{25-18,33-26} {43-36,51-44}{59-52,67-60} || 6D || 0 || 0 || 0 || 0E
|-
| 18 || nec2a || I[01]%32FJR || 900Ah + {8-1,16-9}{24-17,32-25} || 68 || 0 || 0 || 0 || 0E
|-
| 19 || nec2b || I[01]%32F || 900Bh + {9-2,17-10}{25-18,33-26} || 68 || 0 || 0 || 0 || 0E
|-
| 1A || nec2c || I[01]%32FI[01]%32F|R || 900Ch + {8-1,16-9}{24-17,32-25} {42-35,50-43}{58-51,66-59} || 68 || 0 || 0 || 0 || 0E
|-
| 1B || nec2d || I[01]%32F|I[01]%32F || 900Dh + {8-1,16-9}{24-17,32-25} {43-36,51-44}{59-52,67-60} || 68 || 0 || 0 || 0 || 0E
|-
| 1C || nec2e || |I[01]%32FI[01]%32F || 900Eh + {9-2,17-10}{25-18,33-26} {43-36,51-44}{59-52,67-60} || 68 || 0 || 0 || 0 || 0E
|-
| 1D || nec || I[01]%32%F|R || 9000h + {8-1}{16-9}{24-17}{32-25} || 6D || 0 || 0 || 0 || 0E
|-
| * || rc6m6a-24 || H1110{tT}0[01]%23R || 6001h + {8-14)}{15-22}{23-30} || 73 || 0 || ? || 0 || ?
|-
| ** || rc6m6a-32 || H1110{tT} 1[01]%31R || 6001h + {8-22}{23-30}{31-38} || 73 || 0 || ? || 0 || ?
|-
| *** || yamahanec || ?I[01]%32F|R || ?9001h + {8-1}{24-17}, + {!16-19}{132 -! 25} || ?6D || 0 || 0 || 0 || ?
|}

{| class="wikitable"
! dID !! bCh !! [i] !! aBurstSeq !! dID !! bCh !! [i] !! aBurstSeq !! dID !! bCh !! [i] !! aBurstSeq
|-
| 00 || R || 0 || -0CA0 || 02 || R || 0 || -0AA0 || 03 || 1 || 5 || 005B -0546
|-
| 00 || 0 || 1 || 0020 -0020 || 02 || S || 1 || -0080 || 04 || p || 0 || 0103 -AD01
|-
| 00 || 1 || 2 || -0020 0020 || 02 || 0 || 2 || 0020 -0020 || 04 || e || 1 || 0103 -47D5
|-
| 01 || H || 0 || 0060 -0020 || 02 || 1 || 3 || -0020 0020 || 04 || s || 2 || 0103 -1745
|-
| 01 || T || 1 || 0020 -0020 || 03 || R || 0 || 005B -C422 || 04 || r || 3 || 1010 -040C
|-
| 01 || t || 2 || -0020 0020 || 03 || 5 || 1 || 005B -1BC0 || 04 || 0 || 4 || 0103 -0309
|-
| 01 || 0 || 3 || -0010 0010 || 03 || 4 || 2 || 005B -1622 || 04 || 1 || 5 || 0103 -0103
|-
| 01 || 1 || 4 || 0010 -0010 || 03 || 3 || 3 || 005B -1083 || 04 || s$ || 6 || 1010 -081E
|-
| 01 || R || 5 || -0BC0 || 03 || 2 || 4 || 005B -0AE4 || 05 || r || 0 || 227B -1160
|-
| 05 || R || 1 || 022C -8FFA || 0A || R || 0 || 0006 -0857 || 10 || S || 1 || 0009 -58D2
|-
| 05 || S || 2 || 022C -6108 || 0A || 2 || 1 || 0006 -011A || 10 || 0 || 2 || 0009 -0F3E
|-
| 05 || T || 3 || 022C -4165 || 0A || 1 || 2 || 0006 -00BB || 10 || 1 || 3 || 0009 -0A2A
|-
| 05 || o || 4 || 022C -31AF || 0B || R || 0 || 0010 -0857 || 11,12 || R || 0 || 0006 -0841
|-
| 05 || U || 5 || 022C -2C13 || 0B || S || 1 || 0010 -0642 || 11,12 || S || 1 || 0006 -065B
|-
| 05 || 0 || 6 || 022C -0684 || 0B || 2 || 2 || 0010 -0112 || 11,12 || 2 || 2 || 0006 -011A
|-
| 05 || 1 || 7 || 022C -022C || 0B || 1 || 3 || 0010 -00B1 || 11,12 || 1 || 3 || 0006 -00BB
|-
| 05 || o$ || 8 || 227B -1160 || 0C || R || 0 || 0010 -059D || 13–1D, *** || I || 0 || 0157 -00AB
|-
| 06,07 || r || 0 || 00FC -347B || 0C || S || 1 || 0010 -0417 || 13–1D, *** || F || 1 || 0016 -05E7
|-
| 06,07 || a || 1 || 00FC -00FC || 0C || T || 2 || 0010 -02FB || 13–1D, *** || 1 || 2 || 0016 -0040
|-
| 06,07 || e || 2 || 00FC -007E || 0C || 2 || 3 || 0010 -0099 || 13–1D || 0 || 3 || 0016 -0015
|-
| 06,07 || t || 3 || 007E -347B || 0C || 1 || 4 || 0010 -0044 || 13,15,18,1A || R || 4 || 0157 -0055 0016 -0E3B
|-
| 06,07 || s || 4 || 007E -0274 || 0D || R || 0 || 0008 -4B7B || * ** || H || 0 || 0070 -0020
|-
| 06,07 || b || 5 || 007E -017A || 0D || S || 1 || 0008 -3A74 || * ** || T? || 1 || 0020 -0020
|-
| 06,07 || c || 6 || 007E -00FC || 0D || 0 || 2 || 0008 -0A2B || * ** || t || 2 || -0020 0020
|-
| 06,07 || d || 7 || 007E -007E || 0D || 1 || 3 || 0008 -06C3 || * ** || 0 || 3 || -0010 0010
|-
| 08,09 || P || 0 || 0019 -005A 0028 || 0D || s || 4 || 0008 -0515 || * ** || 1 || 4 || 0010 -0010
|-
| 08,09 || a || 1 || -0044 0024 || 0E || R || 0 || 0008 -2BAE || * || R || 5 || -0AB0
|-
| 08,09 || b || 2 || -0036 0012 -000E 0012 || 0E || S || 1 || 0008 -2104 || ** || R || 5 || -09B0
|-
| 08,09 || c || 3 || -0022 0012 -0022 0012 || 0E || 0 || 2 || 0008 -05CA || 10 || R || 0 || 0009 -74F3
|-
| 08,09 || d || 4 || -000E 0012 -0036 0012 || 0E || 1 || 3 || 0008 -03D9 || || || ||
|-
| 08,09 || r || 5 || -07FC || 0F || R || 0 || 0019 -024C || || || ||
|-
| 0F || 0 || 1 || 0019 -010A || 0F || 1 || 2 || 0019 -00AF || || || ||
|}

At the first table: 
dID – subformat, used at format 7000 and for connection with second table
zSystem – unused string, “brand”-like description of dID
zTemplate – template of logical structure of IR signal of this type (dID)
:<letters> and <numbers> - are references as bCh to second table, where they (with dID) point out to a concrete aBurstSeq
:| – delimits once sequence and repeat sequence parts
:[<chars>] – means any of suggested characters
:{<char1><char2>} – corresponds to toggle bit: at odd replaying of IR code of this type must be <char1>, at even – <char2>
:%<number> - means <number> of duplicates of previous character/term
:<nowiki>*</nowiki> - any number of any previously defined characters at [<chars>]
:<char>$ - strange 2-byte name for char, nothing else :)
:?, < - garbage that must be ignored :)
zMask – mask, correspondence between zTemplate and IR code at Fixed Size Template Based Formats. Be described at these formats. zMask is used while learning only.
:Hexadecimal word is wFmtID
:{<expression>} – means description of corresponded word from sCode
:<number> - means index at forming String Code for corresponded bit at sCode word
:<number1>-<number2> - means a range (inversed range) of these bounds – <number1>, <number1+(-)1>, …,
::<number2>
:!<number> – means index at String Code for logical negation of corresponded bit at sCode
dFrqDiv – carrier frequency divider. “-“ means high (>58KHz?) frequency, that is need to be analyzed (when learning) with another filter, I think, so “-“ must be ignored.
bU1, dU2, dU3, dU4 – additional class/format characteristics. I suppose, they are used by recognition routine, or as additional info, like index of developer, who encodes special code for this format/subformat :), and must be ignored at replaying/converting.

At the second table: 
dID – same as at the first table
bCh – means index (char) from zTemplate or String Code
[i] – means index to aBurstSeq from aCode (same as wCIdx) at Predefined Codes of Variable Length (7000)
aBurstSeq – analogue of burst pair with variable length – from 1 to 4 words. Positive words mean time when LED flashes, negative – when LED is off.

= Template Based Formats of Fixed Size (wFmtID = 5000, 5001, 6000, 9000, 9001, 900A, 900B, 900C, 900D, 900E) =

Template based formats of fixed size represent strongly defined IR signals of common brands. As a rule, IR signal, leaned at this format, is the only and “clean” (but I have trouble with RC9200 + Onkyo DVD – it learns its IR codes as 900A mistakenly). IR codes at this format are short, sCode can be 2, 3 or 4 words length, and every of this word means anything like “System”, “Command” or “Data” but that meanings are not essential for converting.

Now, the ranges of that codes:

5000 0000 0000 0001 0000 0000 – 5000 0000 0000 0001 001f 007f

5001 0000 0000 0002 0000 0000 0000 0000 – 5001 0000 0000 0002 001f 007f 003f 0000 
Note: it looks like erratum at firmware table, really zMask for dID = 02 must be 5001h + {4-8}{!2,10-15}{16-21}. This bug causes
a real brain pain: any RC5x code can not be learned by any Pronto! But replaying of these codes works OK, because zMask is not
used for replay.

6000 0000 0000 0001 0000 0000 – 6000 0000 0000 0001 00ff 00ff 
Note: [2] contains description of RC6 Mode 6A as format 6001 with toggle bit, as all other RC-formats. Currently software
represents that codes at format 0000 without toggle bit. I have inserted corresponded (obsolete?) entries * and ** to the end of
firmware tables from [2] for considerations of universality: 
(<nowiki>*</nowiki>subformat of 6001, where first argument (Customer Code) is in range of 0000..007f)

6001 0000 0000 0002 0000 0000 0000 0000 – 6001 0000 0000 0002 007f 00ff 00ff 0000 
(<nowiki>**</nowiki>subformat of 6001, where first argument is in range of 8000..ffff)

6001 0000 0000 0002 8000 0000 0000 0000 – 6001 0000 0000 0002 ffff 00ff 00ff 0000

9000 0000 0000 0002 0000 0000 0000 0000 – 9000 0000 0000 0002 00ff 00ff 00ff 00ff

900a 0000 0000 0001 0000 0000 – 900a 0000 0000 0001 ffff ffff 
Note: These codes represent most common (may be, after RC) IR signal type (32bits NEC). Usually it consist of 8bit device code, 8bit device code binary compliment, 8bit function code and 8bit function code binary compliment [3,4]. All Pronto models, except RC5200, RC-9200, TSU-6000, RU-970, USR-5 must learn this type of IR signals as 0000 006* 0022 0002 0157 …, and it works fine. New Pronto models can replay formats 900A to 900E, but recognition routine is inclined to learn all NEC IR signals as format 900A, that often results in fsults.

900b 0000 0000 0001 0000 0000 – 900b 0000 0000 0001 ffff ffff

900c 0000 0000 0002 0000 0000 0000 0000 – 900c 0000 0000 0002 ffff ffff ffff ffff

900d 0000 0000 0002 0000 0000 0000 0000 – 900d 0000 0000 0002 ffff ffff ffff ffff

900e 0000 0000 0002 0000 0000 0000 0000 – 900e 0000 0000 0002 ffff ffff ffff ffff

9001 0000 0000 0001 0000 0000 – 9001 0000 0000 0001 00ff 00ff

Note: format 9001 is supported only by RAV-2000, but absent in all tables. I can’t check it, and I hope that codes, described at [3,4] are the same, so I have inserted it to firmware tables as ***. 

For converting that codes to format 0000 I offer this procedure: 
* Obtaining String Code from zTemplate, zMask and source code
* Obtaining raw IR data by indexing from String Code
* Forming IR code at format 0000 from raw IR data

= Predefined code of variable length (wFmtID = 7000) =
Structure (example: Grundig):
{| class="wikitable"
! offset !! size !! name !! type !! description !! sample
|-
| 0 || 1 || wFmtID || word, ID || Format ID = 7000 || 7000
|-
| 1 || 1 || wFrqDiv || word, dummy || Unused word || 0088
|-
| 2 || 1 || nOnceSeq || word, dummy || Dummy length || 0000
|-
| 3 || 1 || nRepeatSeq || word, dummy || Dummy length || 0007
|-
| 4 || 1 || wSubFmtID || word, ID || SubFormat ID (dID) || 0008
|-
| 5 || 1 || nCodeSeq || word, length || Length of aCode || 000B
|-
| 6 || nCodeSeq || aCode || array of wCIdx || Code indexes to String Code || 0010 0000 0017 0001 0001 0001 0001 0001 0001 0001 0005
|-
| 6+nCodeSeq || 0 or 1 || wRest || word, dummy || Present if nCodeSeq is odd || 0044
|}

Condition: (nOnceSeq + nRepeatSeq) * 2 = 2 + nCodeSeq + sizeOf(wRest)

String Code selection:
* if wCIdx < 0010: use firmware table (dID, bCh, [i]) where dID = wSubFmtID and [i] = wCIdx
* if wCIdx = 0010: bCh = “1”
* if wCIdx > 0010: toggle char; odd replay uses zTemplate[wCIdx - 14], even uses zTemplate[wCIdx - 13]

''Figure placeholder: Picture 8 — Forming String Code from 7000''

= Index to UDB (wFmtID = 8000) =
Some models support an internal IR database (UDB). Others rely on software DBs.

'''Database availability'''
{| class="wikitable"
! model !! DB type !! file !! size
|-
| TS-1000, RU-890, RU-940 || IR database at ProntoEdit || rcir.mdb (Jet) || 360,448
|-
| TSU-2000, TSU-6000 || UDB || UDP_int.hex || 362,711
|-
| RU-970 || UDB || UDP_int.hex || 662,090
|-
| TSU-500 || UDB as part of || TSU500.dat (Jet) || 5,851,136
|-
| RU-930 || UDB as part of || RU930.dat (Jet) || 7,299,072
|-
| TSU-3000 || UDB || UDB_TSU3000.bin || 422,622
|-
| RC-5000/5000i/5200/9200 || IR database at TSS || rcir.mdb (Jet) || 978,944
|-
| RC-3200 || — || — || —
|-
| RAV-2000 || UDB || ww_udp.idb || 662,090
|-
| USR-5 || UDB || ww_udp.idb || 661,011
|}

'''Code example (Power On for Amp Yamaha, code set 1):'''
<code>8000 0000 0002 0000 000a 23f0 0002 0000</code>

Structure:
{| class="wikitable"
! offset !! size !! name !! type !! description !! sample
|-
| 0 || 1 || wFmtID || word, ID || Must be 8000 || 8000
|-
| 1 || 1 || wFrqDiv || word, dummy || Unused || 0000
|-
| 2 || 1 || nOnceSeq || word, dummy || Dummy length || 0002
|-
| 3 || 1 || nRepeatSeq || word, dummy || Dummy length || 0000
|-
| 4 || 1 || wDevType || word, index || Device type (000A = Amp) || 000A
|-
| 5 || 1 || wBrandCodeSet || word, index || Brand/Code Set (23F0 = Yamaha-1) || 23F0
|-
| 6 || 1 || wFunction || word, index || Function (0002 = Power On) || 0002
|-
| 7 || 1 || wRest || word, dummy || Padding to even words || 0000
|}

Functions and device-type enumerations follow the UDB. Not all combinations are supported across all models.

= References =
There are a number of articles about IR formats applied to Pronto on the internet:
# Daniel Tonks “Unofficial Philips Pronto & Marantz RC5000 FAQ”, http://www.remotecentral.com
# Marcel Majoor “Communicating with the Pronto”, http://home.hccnet.nl/m.majoor
# Barry Gordon “ProntoEdit’s IR Display Format”, http://the-gordons.net:8080/, http://www.remotecentral.com/features/irdisp1.htm
# Barry Shaw, Rob Crowe, Andrea Whitlock “Yamaha extended IR codes”, http://darius.mobius-soft.com/~andrea/
# Stewart Allen, “The CCF file format”, http://giantlaser.com/tonto/

----
''Author note:'' Please excuse my poor English. For questions about Pronto IR you can reach me at eoulianov@hotbox.ru, and I will try to answer more clearly :)

Pronto IR Formats

2025-11-22T21:44:35Z

The Robman: /* Template based formats (wFmtID = 5000, 5001, 6000, 7000, 9000, 9001, 900A, 900B, 900C, 900D, 900E) */

= Pronto IR Formats =

== Preamble ==
This article describes in detail the formats of IR code filing for Pronto and ProntoPro models (RU-890, RU-940, RU-970, TS-1000, TSU-2000, TSU-6000, RC-5000, RC-5000i, RC-5200, RC-9200, RAV-2000, USR-5). It is supposed to be interesting for:
* those, who want to clean up his IR codes — in order to find out what all the numbers in field “IR code:” mean and for troubleshooting;
* those, who want to develop an IR code converter into other driver/configuration formats — Crestron (.IR), AMX (.IRL), Xantech (.PAL), Niles (.LIN), ADI Ocelot (.LIR), RedRat2 (.TXT), Denon RC-8000 (.RCX), ProntoNeo (.NCF), ProntoNG (.PCF) etc, as a manual of most popular and complicated IMHO IR code format.

It is advisable for you to have a notion of modulated IR signals transmission [1], but I will also coin that terms for completeness. References to some concepts can be earlier than the description of theirs, so as not to touch on same concept doubly. I am not going to mention the details of realization which is not essential for the description of the format.

== Acknowledgments ==
I would like to thank Daniel Tonks, Stewart Allen, Barry Gordon, Marcel Majoor, Steven Keyser, Bertrand Gillis, Loran Richardson, Bernard Barrier, Barry Shaw, Rob Crowe, Andrea Whitlock, those, who reply at forums — for help and support, my wife — for indulgence and star50fiveoh — for sober intolerance to this article's subject :)

== Warning ==
Standard warning about “… your own risk” is in effect.

== Buttons, signals, commands and codes ==
In order to avoid involving in terms, I specify them precisely:

[[Image:Pronto-formats-buttons.jpg]] 
''Figure placeholder: Picture 1 — Interaction of buttons, IR signals, commands and IR codes''

The button, IR signal, command and IR code are not corresponding mutually:
* the same button can produce different IR signals (see Toggle Codes);
* different IR signals can be recognized by decoder as same command (see Clean and Dirty Codes);
* the same IR signal can be encoded as a number of IR codes in different formats.

== Modulated IR signal ==
For some reasons, mainly for simplicity and interference immunity, almost all IR signals, currently used to IR translation, have the same structure. IR transmitter includes a square-wave generator (oscillator), coder and IR LED. All the time of transfer oscillator generates square impulses with fixed (for this remote) carrier frequency; depending on pressed button (and, may be, remote mode), coder forms a code of command — sequence of conventional logical 0s and 1s; IR LED flashes this command modulated by generated impulses.

[[Image:Pronto-formats-2-IR.jpg]] 
''Figure placeholder: Picture 2 — IR LED replays modulated IR signal''

Any modulated IR signal can be fully characterized via carrier frequency and the sequence of period amounts when emitting is on and off. For picture 2 this sequence is 6–2–4–2–4–…

Sometimes remote emits the signal all the time until the button such as VOLUME+ will released. Another way it flashes once per press, or first, once emitted signal is not the same that repeating one, followed it. So, it is convenient to suppose that in the general way IR signal consists of once part, the start emitting sequence and repeat part. For example, endless IR signal 6-2-4-2-4-6-6-3-3-12-6-3-3-12- has the once sequence 6-2-4-2-4-6 and repeat sequence 6-3-3-12: 6-2-4-2-4-6 | 6-3-3-12. All currently used IR signals can be represented either as a union of once and repeat sequences or as the only once or only repeating sequence.

[[Image:Pronto-formats-3-IR.jpg]] 
''Figure placeholder: Picture 3 — Cutting IR signal into once sequence and repeat sequence''

Usually, IR codes, describing IR signal this way, are not so long. If learned IR code is not an air conditioner code, it can be completely go in “IR code:” field at ProntoEdit.

In the most of cases carrier frequencies are nearby 35KHz, but you will certainly be lucky enough to try a remote with 175KHz, 345KHz, 455KHz or 1.1MHz.

== “Clean” and “dirty” codes ==
[1: “Unclean” and “clean” IR commands (Working With Prontoedit: Learning & Infrared)]

It is not necessary to replay IR signal precisely, IR receiver will “identify” received IR signal as correct command, if it looks like real command adequately, say, carrier frequency and burst pairs’s lengths differ from original IR signal less than for 10%. I.e. there is precise, original IR signal for every command, may be not replay-able for Pronto, and also many IR signals that Pronto can replay and IR receiver can recognize as that command. The codes of those signals may have different lengths, and the shortest one is “clean” code, and the all other codes are “dirty” and very “dirty”.

Reasons to prefer “clean” codes:
* IR signal of “clean” IR code is more recognizable by IR receiver
* some “dirty” IR codes can lead IR receiver astray or halt it
* “clean” code is shorter, and replay of it takes less time in macros
* you can visually check “clean” IR code’s accuracy — the lengths of every “clean” IR codes per remote are the same, except, may be, buttons like VOLUME+
* “clean” code is more convenient to analyzing, in order to guess a discrete command, absent at this remote
* using of “clean” IR codes stirs ambitions of punctual Prontoyers

The ordinal way to obtain “clean” IR code is cutting from existing one [1]. Sometimes it is useful to develop special software — generator of all concrete type IR codes — in order to “discover” all possible commands, supported by that device, including those absent at remotes.

Note: There is no difference in IR learning to Pronto standalone or to computer via Pronto, but sometimes this process is faulted due a communication error.

== Toggle IR codes ==
[1: Why won’t my buttons work twice in a row? (Working With Prontoedit: Learning & Infrared)]

It is necessary not to mix up toggle IR codes and toggle IR commands. Toggle Command is a command with toggle function such as standby/on, see TOAD at [1]. In contrast to that, Toggle IR Code contains as minimal 1 toggle bit, see RC5 at [2].

There are many possible troubles and noises at IR transfer — sun, fluorescent lamps, interference with another IR transfer, dust, pets, household and tremor of hesitating hand, holding remote. First two troubles can be cured by signal modulation. Other problems, concerning temporary obstacle, are solved logically. Commonly they use two different IR signals per button — one for odd presses and another for even. As a rule, these codes differ in one or two logical bits (“toggle” bit or “parity”), and both of them encode the same command. When IR decoder receives IR signal such type, it ignores the same signals (or signals with the same “parity” bit) received twice, in order to avoid taking noise as double click.

Pronto IR learning procedure uses the only button pressing, and because of it Pronto can detect as toggle codes only codes of some predefined types, that look like known codes, for example, RC5. When Pronto replays these codes, it emits in turn odd and even IR signals for every type of predefined code format (and if existing, subformat). So repeating the same alias for “long button press” in macro is not effective for toggle codes; it is necessary to convert this code to format 0000 to do it.

If Pronto learns real toggle codes as ordinary, learn all codes in the same parity, and only the “blank” command (that does nothing, if it exists at remote) — in opposite parity, and give any Pronto button two actions — odd real command and even “blank” [1].

== Pronto IR code filling formats ==
[1: Type of code (Working With Prontoedit: Learning & Infrared)]

IR codes are kept in Pronto and in CCFs in bytes (as all data), but Pronto software uses two-byte hexadecimal words delimited by spaces at IR code view (editBox):
<code>0000 0070 0003 0002 0006 0002 0004 0002 0004 0006 0006 0003 0003 000C</code>

I will write all sizes and offsets in 16-bit words and all numbers in hex, if not specified otherwise. First word — '''wFmtID''' — identifies IR format.

Supported formats:
* 0000 — raw oscillated code
* 0100 — raw unmodulated code
* 5000 — RC5
* 5001 — RC5x
* 6000 — RC6 Mode 0
* 7000 — predefined code of variable length
* 8000 — index to UDB
* 9000, 900A, 900B, 900C, 900D, 900E — NEC
* 9001 — basic mode YAMAHA NEC code

[[Image:Pronto-formats-4-hierarchy.jpg]] 
''Figure placeholder: Picture 4 — hierarchy of Pronto IR formats''

= Raw formats (wFmtID = 0000 or 0100) =
They are simple, basic, most commonly used formats. Almost all IR signals can be represented (exactly or cognitive) either in 0000 or 0100 format. There is no way to encode toggle IR codes at these formats, but separately, odd and even IR code can be converted from toggle form to 0000 format.

== Raw oscillated code (wFmtID = 0000) ==
This is the format that is often implied, when they say “Pronto IR format”. It contains lengths while LED flashes and while
LED is off in carrier periods (“burst pairs”) in two optional parts - once and repeat sequences.

For example, code from pic.2 and 3 will encoded in this format as 0000 0070 0003 0002 0006 0002 0004 0002 0004
0006 0006 0003 0003 000С, where:

{| class="wikitable"
! offset !! size !! name !! type !! description !! sample
|-
| 0 || 1 || wFmtID || word, ID || Format ID. Must be 0000 || 0000
|-
| 1 || 1 || wFrqDiv || word, positive || Carrier frequency divider || 0070
|-
| 2 || 1 || nOnceSeq || word, length || Number of burst pairs at once sequence || 0003
|-
| 3 || 1 || nRepeatSeq || word, length || Number of burst pairs at repeat sequence || 0002
|-
| 4 || 2*nOnceSeq || aOnceSeq || array of rBurstPair || Once sequence || 0006 0002 0004 0002 0004 0006
|-
| 4+2*nOnceSeq || 2*nRepeatSeq || aRepeatSeq || array of rBurstPair || Repeat sequence || 0006 0003 0003 000C
|}

and rBurstPair consists of:

{| class="wikitable"
! offset !! size !! name !! type !! description !! sample
|-
| 0 || 1 || wLEDflash || word, positive || Periods when LED flashes with carrier || 0006
|-
| 1 || 1 || wLEDoff || word, positive || Periods when LED is off || 0002
|}

Details:
* wFmtID: word = 0000, Format ID
* wFrqDiv: word in range 0001..FFFF, wFrqDiv = 4,145146 MHz / <signal carrier>. So wFrqDiv = 0001 corresponds to signal carrier » 4,1 MHz, and wFrqDiv =FFFF ~ 63Hz. I have measured this constant indirectly and have obtained 4,1455±0,0006 MHz, which is close enough with magical number 4,145146 [2], and far enough from 4,194304 [5], but I can’t locate quartz oscillator with this nominal at catalogues.
* nOnceSeq: word in range 0000..0100, is equal to amount of burst pairs at once sequence
* nRepeatSeq: word in range 0000..0100, is equal to amount of burst pairs at repeat sequence
* wLEDflash: word in range 0001..FFFF, is amount of carrier frequency periods when LED flashes every first half-period and turned off for the last half-period
* wLEDoff: word in range 0001..FFFF, is amount of carrier frequency periods when the LED is off

Next picture will dispel all residuary questions:

[[Image:Pronto-formats-5-correspondence.jpg]] 
''Figure placeholder: Picture 5 — correspondence between IR-signal and IR-code at format 0000''

== Raw unmodulated code (wFmtID = 0100) ==
Same structure as 0000, but LED is continuously on for the first word of the burst pair (no carrier):

[[Image:Pronto-formats-6-difference.jpg]] 
''Figure placeholder: Picture 6 — difference between IR signals for 0000 vs 0100''

Differences:
{| class="wikitable"
! offset !! size !! name !! type !! description !! sample
|-
| 0 || 1 || wFmtID || word, ID || Format ID. Must be 0100 || 0100
|}

aBurstPair consists of:

{| class="wikitable"
! offset !! size !! name !! type !! description !! sample
|-
| 0 || 1 || wLEDon || word, positive || Periods when LED is on || 0006
|-
| 1 || 1 || wLEDoff || word, positive || Periods when LED is off || 0002
|}

This format completes format 0000 to universal description of all raw IR signals, but codes at format 0100 are rare – it is
exposed to sun light and other IR noises. I have learned only 2 devices with these codes – noname drape drive and Dish Satellite
Positioner. Nevertheless, sometimes it is useful to use IR signal without carrier, for example, for Sony Contol-S: you can replace an
IR probe at RX-77 to ordinal jack, change 0000 to 0100 at IR codes, and your Sony device will be controlled by Control-S. Some
other systems also support IR signals without carrier, like Crestron’s CstmFreq value = 43.

= Predefined formats (wFmtID = 5000, 5001, 6000, 7000, 8000, 9000, 9001, 900A, 900B, 900C, 900D, 900E) =
There are a number of additional, predefined IR formats, supported by some reasons. They can’t describe all IR signals, every type/subtype of this format represents only IR codes with specific structure, for custom “brand”. Also, we need additional data tables to replay these signals. These predefined formats are more compact than corresponding raw IR codes and, as a rule, simple and “clean”. I.e., if you learn IR as 5000 or 7000 and it is not a bug, then that and all other IR signals from this remote must be codes of this type.

Predefined formats have different structure, but for the reason of compatibility with format 0000, fields wFrqDiv, nOnceSeq, nRepeatSeq leave as dummy, so that code “looks” the same. aOnceSeq and aRepeatSeq are replaced with sCode, that consist real code info. Also, nOnceSeq and nRepeatSeq must meet the condition (nOnceSeq + nRepeatSeq) * 2 = sizeOf(sCode):

Template header:
{| class="wikitable"
! offset !! size !! name !! type !! description !! sample
|-
| 0 || 1 || wFmtID || word, ID || Format ID || 5000
|-
| 1 || 1 || wFrqDiv || word, dummy || Unused word for compatibility || 0000
|-
| 2 || 1 || nOnceSeq || word, dummy || Dummy code length || 0000
|-
| 3 || 1 || nRepeatSeq || word, dummy || Dummy code length || 0001
|-
| 4 || (nOnceSeq+nRepeatSeq)*2 || sCode || structure || Predefined code || 0000 0000
|}

Not all of the predefined formats are supported by any Pronto model – here a table of compatibility is:

{| class="wikitable"
! wFmtID !! RU-890/940/TS-1000/RC-5000/5000i !! TSU-2000 !! RC-5200/9200 !! TSU-6000/RU-970/USR-5 !! RAV-2000
|-
| 0000, 0100, 5000, 5001, 6000, 7000 || ✔ || ✔ || ✔ || ✔ || ✔
|-
| 8000 || || ✔ || || ✔ || ✔
|-
| 9000 || || || ✔ || ✔ || ✔
|-
| 9001 || || || || || ✔
|-
| 900A–900E || || || ✔ || ✔ ||
|}

Also, RC-3200 does not support all of this formats directly (except 0000), but RC-3200 Setup converts codes 0100, 5000, 5001 and 6000 codes into format 0000 automatically, and this feature can be used from elsewhere!

Note: 0000 format used by RC-3200 is extended by including support of unmodulated IR signals with special value of wFrqDiv = 0001.

When I describe these formats, I will translate them to format 0000, in anticipation of this converter is already exist.

= Template based formats (wFmtID = 5000, 5001, 6000, 7000, 9000, 9001, 900A, 900B, 900C, 900D, 900E) =
Template based formats are used for memory saving, for representing toggle IR codes, and for encoding IR signals with high
carrier frequency.

Segment SYS at Pronto Firmware contains 2 tables for encoding/decoding IR codes these types:

== SYS segment tables ==
{| class="wikitable"
! dID !! zSystem !! zTemplate !! zMask !! dFrqDiv !! bU1 !! dU2 !! dU3 !! dU4
|-
| 00 || rc5 || 1[01]{01}[01]%11R || 5000h + {4-8}{12,9-14} || 73 || 0 || 2 || 0 || 0A
|-
| 01 || rc6m0 || H1000ftT}[01]%16R || 6000h + {7-14}{15-22} || 73 || 0 || 0 || 0 || 0A
|-
| 02 || rc5e || 1 01]{01} [01]%5S[01]%12R || 5001h + {4-8}{12,10-15}{15-20} || 73 || 0 || 3 || 0 || 0A
|-
| 03 || b&o || 115[1234]*R?|<3[12345]* || 7000h || -09 || 0 || 5 || 0 || 14
|-
| 04 || kenwood || s$[01]%32e|rp || 7000h || -09 || 0 || 2 || 1 || 14
|-
| 05 || pioneer || o$[01]%32[RSTUo] r[01rRSTUo]* || 7000h || -04 || 0 || 4 || 1 || 14
|-
| 06 || ehrep || s[abcderst]%4[abcderst]* |s[abcderst]%4[abcderst]* || 7000h || -0C || 0 || 4 || 0 || 14
|-
| 07 || ehonce || s[abcderst]%4[abcderst]* || 7000h || -0C || 0 || 4 || 0 || 14
|-
| 08 || grundig 16ac || P{ac} [abcd]%7r || 7000h || 88 || 0 || 0 || 0 || 06
|-
| 09 || grundig 16bd || P{bd}[abcd]%7r || 7000h || 88 || 0 || 0 || 0 || 06
|-
| 0A || thomson1 || 2{12}[12]%9R || 7000h || 7C || 0 || 1 || 0 || 0E
|-
| 0B || thomson2 || {12}{12}[12]%9[RS] || 7000h || 7C || 0 || -1 || 0 || 0F
|-
| 0C || thomson3 || [12]%4{12}[12]%7[RST] || 7000h || 7C || 0 || -1 || 0 || 10
|-
| 0D || ferguson || s%2(01}[01]%9[RS] || 7000h || -0C || 1 || 4 || 0 || 0D
|-
| 0E || telefunken || (01} {01}[01]%9[RS || 7000h || -18 || 1 || -1 || 0 || 0E
|-
| 0F || echostar || T01]%5R || 7000h || 42 || 0 || -1 || 0 || 07
|-
| 10 || saba || (01}{01}[01]%9[RS || 7000h || -08 || 1 || -1 || 0 || 0E
|-
| 11 || crown || 2{12}[12]%9[RS] || 7000h || 6D || 0 || 2 || 0 || 0E
|-
| 12 || seleco || 2(12}[12]%9[RS || 7000h || 63 || 0 || 2 || 0 || 0E
|-
| 13 || nec1a || I[01]%32F|R || 900Ah + {8-1,16-9)}{24-17,32-25} || 6D || 0 || 0 || 0 || 0E
|-
| 14 || nec1b || I[01]%32F || 900Bh + {9-2,17-10}{25-18,33-26} || 6D || 0 || 0 || 0 || 0E
|-
| 15 || nec1c || I[01]%32FI[01]%32F|R || 900Ch + {8-1,16-9}{24-17,32-25} {42-35,50-43}{58-51,66-59} || 6D || 0 || 0 || 0 || 0E
|-
| 16 || nec1d || I[01]%32F|I[01]%32F || 900Dh + {8-1,16-9}{24-17,32-25} {43-36,51-44}{59-52,67-60} || 6D || 0 || 0 || 0 || 0E
|-
| 17 || nec1e || I[01]%32FI[01]%32F || 900Eh + {9-2,17-10}{25-18,33-26} {43-36,51-44}{59-52,67-60} || 6D || 0 || 0 || 0 || 0E
|-
| 18 || nec2a || I[01]%32FJR || 900Ah + {8-1,16-9}{24-17,32-25} || 68 || 0 || 0 || 0 || 0E
|-
| 19 || nec2b || I[01]%32F || 900Bh + {9-2,17-10}{25-18,33-26} || 68 || 0 || 0 || 0 || 0E
|-
| 1A || nec2c || I[01]%32FI[01]%32F|R || 900Ch + {8-1,16-9}{24-17,32-25} {42-35,50-43}{58-51,66-59} || 68 || 0 || 0 || 0 || 0E
|-
| 1B || nec2d || I[01]%32F|I[01]%32F || 900Dh + {8-1,16-9}{24-17,32-25} {43-36,51-44}{59-52,67-60} || 68 || 0 || 0 || 0 || 0E
|-
| 1C || nec2e || |I[01]%32FI[01]%32F || 900Eh + {9-2,17-10}{25-18,33-26} {43-36,51-44}{59-52,67-60} || 68 || 0 || 0 || 0 || 0E
|-
| 1D || nec || I[01]%32%F|R || 9000h + {8-1}{16-9}{24-17}{32-25} || 6D || 0 || 0 || 0 || 0E
|-
| * || rc6m6a-24 || H1110{tT}0[01]%23R || 6001h + {8-14)}{15-22}{23-30} || 73 || 0 || ? || 0 || ?
|-
| ** || rc6m6a-32 || H1110{tT} 1[01]%31R || 6001h + {8-22}{23-30}{31-38} || 73 || 0 || ? || 0 || ?
|-
| *** || yamahanec || ?I[01]%32F|R || ?9001h + {8-1}{24-17}, + {!16-19}{132 -! 25} || ?6D || 0 || 0 || 0 || ?
|}

{| class="wikitable"
! dID !! bCh !! [i] !! aBurstSeq !! dID !! bCh !! [i] !! aBurstSeq !! dID !! bCh !! [i] !! aBurstSeq
|-
| 00 || R || 0 || -0CA0 || 02 || R || 0 || -0AA0 || 03 || 1 || 5 || 005B -0546
|-
| 00 || 0 || 1 || 0020 -0020 || 02 || S || 1 || -0080 || 04 || p || 0 || 0103 -AD01
|-
| 00 || 1 || 2 || -0020 0020 || 02 || 0 || 2 || 0020 -0020 || 04 || e || 1 || 0103 -47D5
|-
| 01 || H || 0 || 0060 -0020 || 02 || 1 || 3 || -0020 0020 || 04 || s || 2 || 0103 -1745
|-
| 01 || T || 1 || 0020 -0020 || 03 || R || 0 || 005B -C422 || 04 || r || 3 || 1010 -040C
|-
| 01 || t || 2 || -0020 0020 || 03 || 5 || 1 || 005B -1BC0 || 04 || 0 || 4 || 0103 -0309
|-
| 01 || 0 || 3 || -0010 0010 || 03 || 4 || 2 || 005B -1622 || 04 || 1 || 5 || 0103 -0103
|-
| 01 || 1 || 4 || 0010 -0010 || 03 || 3 || 3 || 005B -1083 || 04 || s$ || 6 || 1010 -081E
|-
| 01 || R || 5 || -0BC0 || 03 || 2 || 4 || 005B -0AE4 || 05 || r || 0 || 227B -1160
|-
| 05 || R || 1 || 022C -8FFA || 0A || R || 0 || 0006 -0857 || 10 || S || 1 || 0009 -58D2
|-
| 05 || S || 2 || 022C -6108 || 0A || 2 || 1 || 0006 -011A || 10 || 0 || 2 || 0009 -0F3E
|-
| 05 || T || 3 || 022C -4165 || 0A || 1 || 2 || 0006 -00BB || 10 || 1 || 3 || 0009 -0A2A
|-
| 05 || o || 4 || 022C -31AF || 0B || R || 0 || 0010 -0857 || 11,12 || R || 0 || 0006 -0841
|-
| 05 || U || 5 || 022C -2C13 || 0B || S || 1 || 0010 -0642 || 11,12 || S || 1 || 0006 -065B
|-
| 05 || 0 || 6 || 022C -0684 || 0B || 2 || 2 || 0010 -0112 || 11,12 || 2 || 2 || 0006 -011A
|-
| 05 || 1 || 7 || 022C -022C || 0B || 1 || 3 || 0010 -00B1 || 11,12 || 1 || 3 || 0006 -00BB
|-
| 05 || o$ || 8 || 227B -1160 || 0C || R || 0 || 0010 -059D || 13–1D, *** || I || 0 || 0157 -00AB
|-
| 06,07 || r || 0 || 00FC -347B || 0C || S || 1 || 0010 -0417 || 13–1D, *** || F || 1 || 0016 -05E7
|-
| 06,07 || a || 1 || 00FC -00FC || 0C || T || 2 || 0010 -02FB || 13–1D, *** || 1 || 2 || 0016 -0040
|-
| 06,07 || e || 2 || 00FC -007E || 0C || 2 || 3 || 0010 -0099 || 13–1D || 0 || 3 || 0016 -0015
|-
| 06,07 || t || 3 || 007E -347B || 0C || 1 || 4 || 0010 -0044 || 13,15,18,1A || R || 4 || 0157 -0055 0016 -0E3B
|-
| 06,07 || s || 4 || 007E -0274 || 0D || R || 0 || 0008 -4B7B || * ** || H || 0 || 0070 -0020
|-
| 06,07 || b || 5 || 007E -017A || 0D || S || 1 || 0008 -3A74 || * ** || T? || 1 || 0020 -0020
|-
| 06,07 || c || 6 || 007E -00FC || 0D || 0 || 2 || 0008 -0A2B || * ** || t || 2 || -0020 0020
|-
| 06,07 || d || 7 || 007E -007E || 0D || 1 || 3 || 0008 -06C3 || * ** || 0 || 3 || -0010 0010
|-
| 08,09 || P || 0 || 0019 -005A 0028 || 0D || s || 4 || 0008 -0515 || * ** || 1 || 4 || 0010 -0010
|-
| 08,09 || a || 1 || -0044 0024 || 0E || R || 0 || 0008 -2BAE || * || R || 5 || -0AB0
|-
| 08,09 || b || 2 || -0036 0012 -000E 0012 || 0E || S || 1 || 0008 -2104 || ** || R || 5 || -09B0
|-
| 08,09 || c || 3 || -0022 0012 -0022 0012 || 0E || 0 || 2 || 0008 -05CA || 10 || R || 0 || 0009 -74F3
|-
| 08,09 || d || 4 || -000E 0012 -0036 0012 || 0E || 1 || 3 || 0008 -03D9 || || || ||
|-
| 08,09 || r || 5 || -07FC || 0F || R || 0 || 0019 -024C || || || ||
|-
| 0F || 0 || 1 || 0019 -010A || 0F || 1 || 2 || 0019 -00AF || || || ||
|}

At the first table: 
dID – subformat, used at format 7000 and for connection with second table
zSystem – unused string, “brand”-like description of dID
zTemplate – template of logical structure of IR signal of this type (dID)
:<letters> and <numbers> - are references as bCh to second table, where they (with dID) point out to a concrete aBurstSeq
:| – delimits once sequence and repeat sequence parts
:[<chars>] – means any of suggested characters
:{<char1><char2>} – corresponds to toggle bit: at odd replaying of IR code of this type must be <char1>, at even – <char2>
:%<number> - means <number> of duplicates of previous character/term
:<nowiki>*</nowiki> - any number of any previously defined characters at [<chars>]
:<char>$ - strange 2-byte name for char, nothing else :)
:?, < - garbage that must be ignored :)
zMask – mask, correspondence between zTemplate and IR code at Fixed Size Template Based Formats. Be described at these formats. zMask is used while learning only.
:Hexadecimal word is wFmtID
:{<expression>} – means description of corresponded word from sCode
:<number> - means index at forming String Code for corresponded bit at sCode word
:<number1>-<number2> - means a range (inversed range) of these bounds – <number1>, <number1+(-)1>, …,
::<number2>
:!<number> – means index at String Code for logical negation of corresponded bit at sCode
dFrqDiv – carrier frequency divider. “-“ means high (>58KHz?) frequency, that is need to be analyzed (when learning) with another filter, I think, so “-“ must be ignored.
bU1, dU2, dU3, dU4 – additional class/format characteristics. I suppose, they are used by recognition routine, or as additional info, like index of developer, who encodes special code for this format/subformat :), and must be ignored at replaying/converting.

At the second table: 
dID – same as at the first table
bCh – means index (char) from zTemplate or String Code
[i] – means index to aBurstSeq from aCode (same as wCIdx) at Predefined Codes of Variable Length (7000)
aBurstSeq – analogue of burst pair with variable length – from 1 to 4 words. Positive words mean time when LED flashes, negative – when LED is off.

= Template Based Formats of Fixed Size (wFmtID = 5000, 5001, 6000, 9000, 9001, 900A, 900B, 900C, 900D, 900E) =

Template based formats of fixed size represent strongly defined IR signals of common brands. As a rule, IR signal, leaned at this format, is the only and “clean” (but I have trouble with RC9200 + Onkyo DVD – it learns its IR codes as 900A mistakenly). IR codes at this format are short, sCode can be 2, 3 or 4 words length, and every of this word means anything like “System”, “Command” or “Data” but that meanings are not essential for converting.

Now, the ranges of that codes:

5000 0000 0000 0001 0000 0000 – 5000 0000 0000 0001 001f 007f 
5001 0000 0000 0002 0000 0000 0000 0000 – 5001 0000 0000 0002 001f 007f 003f 0000 
Note: it looks like erratum at firmware table, really zMask for dID = 02 must be 5001h + {4-8}{!2,10-15}{16-21}. This bug causes
a real brain pain: any RC5x code can not be learned by any Pronto! But replaying of these codes works OK, because zMask is not
used for replay. 
6000 0000 0000 0001 0000 0000 – 6000 0000 0000 0001 00ff 00ff 
Note: [2] contains description of RC6 Mode 6A as format 6001 with toggle bit, as all other RC-formats. Currently software
represents that codes at format 0000 without toggle bit. I have inserted corresponded (obsolete?) entries * and ** to the end of
firmware tables from [2] for considerations of universality: 
(<nowiki>*</nowiki>subformat of 6001, where first argument (Customer Code) is in range of 0000..007f) 
6001 0000 0000 0002 0000 0000 0000 0000 – 6001 0000 0000 0002 007f 00ff 00ff 0000 
(<nowiki>**</nowiki>subformat of 6001, where first argument is in range of 8000..ffff) 
6001 0000 0000 0002 8000 0000 0000 0000 – 6001 0000 0000 0002 ffff 00ff 00ff 0000 
9000 0000 0000 0002 0000 0000 0000 0000 – 9000 0000 0000 0002 00ff 00ff 00ff 00ff 
900a 0000 0000 0001 0000 0000 – 900a 0000 0000 0001 ffff ffff 
Note: These codes represent most common (may be, after RC) IR signal type (32bits NEC). Usually it consist of 8bit device code, 8bit device code binary compliment, 8bit function code and 8bit function code binary compliment [3,4]. All Pronto models, except RC5200, RC-9200, TSU-6000, RU-970, USR-5 must learn this type of IR signals as 0000 006* 0022 0002 0157 …, and it works fine. New Pronto models can replay formats 900A to 900E, but recognition routine is inclined to learn all NEC IR signals as format 900A, that often results in fsults. 
900b 0000 0000 0001 0000 0000 – 900b 0000 0000 0001 ffff ffff 
900c 0000 0000 0002 0000 0000 0000 0000 – 900c 0000 0000 0002 ffff ffff ffff ffff 
900d 0000 0000 0002 0000 0000 0000 0000 – 900d 0000 0000 0002 ffff ffff ffff ffff 
900e 0000 0000 0002 0000 0000 0000 0000 – 900e 0000 0000 0002 ffff ffff ffff ffff 
9001 0000 0000 0001 0000 0000 – 9001 0000 0000 0001 00ff 00ff 

Note: format 9001 is supported only by RAV-2000, but absent in all tables. I can’t check it, and I hope that codes, described at [3,4] are the same, so I have inserted it to firmware tables as ***. 

For converting that codes to format 0000 I offer this procedure: 
* Obtaining String Code from zTemplate, zMask and source code
* Obtaining raw IR data by indexing from String Code
* Forming IR code at format 0000 from raw IR data

= Predefined code of variable length (wFmtID = 7000) =
Structure (example: Grundig):
{| class="wikitable"
! offset !! size !! name !! type !! description !! sample
|-
| 0 || 1 || wFmtID || word, ID || Format ID = 7000 || 7000
|-
| 1 || 1 || wFrqDiv || word, dummy || Unused word || 0088
|-
| 2 || 1 || nOnceSeq || word, dummy || Dummy length || 0000
|-
| 3 || 1 || nRepeatSeq || word, dummy || Dummy length || 0007
|-
| 4 || 1 || wSubFmtID || word, ID || SubFormat ID (dID) || 0008
|-
| 5 || 1 || nCodeSeq || word, length || Length of aCode || 000B
|-
| 6 || nCodeSeq || aCode || array of wCIdx || Code indexes to String Code || 0010 0000 0017 0001 0001 0001 0001 0001 0001 0001 0005
|-
| 6+nCodeSeq || 0 or 1 || wRest || word, dummy || Present if nCodeSeq is odd || 0044
|}

Condition: (nOnceSeq + nRepeatSeq) * 2 = 2 + nCodeSeq + sizeOf(wRest)

String Code selection:
* if wCIdx < 0010: use firmware table (dID, bCh, [i]) where dID = wSubFmtID and [i] = wCIdx
* if wCIdx = 0010: bCh = “1”
* if wCIdx > 0010: toggle char; odd replay uses zTemplate[wCIdx - 14], even uses zTemplate[wCIdx - 13]

''Figure placeholder: Picture 8 — Forming String Code from 7000''

= Index to UDB (wFmtID = 8000) =
Some models support an internal IR database (UDB). Others rely on software DBs.

'''Database availability'''
{| class="wikitable"
! model !! DB type !! file !! size
|-
| TS-1000, RU-890, RU-940 || IR database at ProntoEdit || rcir.mdb (Jet) || 360,448
|-
| TSU-2000, TSU-6000 || UDB || UDP_int.hex || 362,711
|-
| RU-970 || UDB || UDP_int.hex || 662,090
|-
| TSU-500 || UDB as part of || TSU500.dat (Jet) || 5,851,136
|-
| RU-930 || UDB as part of || RU930.dat (Jet) || 7,299,072
|-
| TSU-3000 || UDB || UDB_TSU3000.bin || 422,622
|-
| RC-5000/5000i/5200/9200 || IR database at TSS || rcir.mdb (Jet) || 978,944
|-
| RC-3200 || — || — || —
|-
| RAV-2000 || UDB || ww_udp.idb || 662,090
|-
| USR-5 || UDB || ww_udp.idb || 661,011
|}

'''Code example (Power On for Amp Yamaha, code set 1):'''
<code>8000 0000 0002 0000 000a 23f0 0002 0000</code>

Structure:
{| class="wikitable"
! offset !! size !! name !! type !! description !! sample
|-
| 0 || 1 || wFmtID || word, ID || Must be 8000 || 8000
|-
| 1 || 1 || wFrqDiv || word, dummy || Unused || 0000
|-
| 2 || 1 || nOnceSeq || word, dummy || Dummy length || 0002
|-
| 3 || 1 || nRepeatSeq || word, dummy || Dummy length || 0000
|-
| 4 || 1 || wDevType || word, index || Device type (000A = Amp) || 000A
|-
| 5 || 1 || wBrandCodeSet || word, index || Brand/Code Set (23F0 = Yamaha-1) || 23F0
|-
| 6 || 1 || wFunction || word, index || Function (0002 = Power On) || 0002
|-
| 7 || 1 || wRest || word, dummy || Padding to even words || 0000
|}

Functions and device-type enumerations follow the UDB. Not all combinations are supported across all models.

= References =
There are a number of articles about IR formats applied to Pronto on the internet:
# Daniel Tonks “Unofficial Philips Pronto & Marantz RC5000 FAQ”, http://www.remotecentral.com
# Marcel Majoor “Communicating with the Pronto”, http://home.hccnet.nl/m.majoor
# Barry Gordon “ProntoEdit’s IR Display Format”, http://the-gordons.net:8080/, http://www.remotecentral.com/features/irdisp1.htm
# Barry Shaw, Rob Crowe, Andrea Whitlock “Yamaha extended IR codes”, http://darius.mobius-soft.com/~andrea/
# Stewart Allen, “The CCF file format”, http://giantlaser.com/tonto/

----
''Author note:'' Please excuse my poor English. For questions about Pronto IR you can reach me at eoulianov@hotbox.ru, and I will try to answer more clearly :)

Pronto IR Formats

2025-11-22T21:21:56Z

The Robman: /* SYS segment tables */

= Pronto IR Formats =

== Preamble ==
This article describes in detail the formats of IR code filing for Pronto and ProntoPro models (RU-890, RU-940, RU-970, TS-1000, TSU-2000, TSU-6000, RC-5000, RC-5000i, RC-5200, RC-9200, RAV-2000, USR-5). It is supposed to be interesting for:
* those, who want to clean up his IR codes — in order to find out what all the numbers in field “IR code:” mean and for troubleshooting;
* those, who want to develop an IR code converter into other driver/configuration formats — Crestron (.IR), AMX (.IRL), Xantech (.PAL), Niles (.LIN), ADI Ocelot (.LIR), RedRat2 (.TXT), Denon RC-8000 (.RCX), ProntoNeo (.NCF), ProntoNG (.PCF) etc, as a manual of most popular and complicated IMHO IR code format.

It is advisable for you to have a notion of modulated IR signals transmission [1], but I will also coin that terms for completeness. References to some concepts can be earlier than the description of theirs, so as not to touch on same concept doubly. I am not going to mention the details of realization which is not essential for the description of the format.

== Acknowledgments ==
I would like to thank Daniel Tonks, Stewart Allen, Barry Gordon, Marcel Majoor, Steven Keyser, Bertrand Gillis, Loran Richardson, Bernard Barrier, Barry Shaw, Rob Crowe, Andrea Whitlock, those, who reply at forums — for help and support, my wife — for indulgence and star50fiveoh — for sober intolerance to this article's subject :)

== Warning ==
Standard warning about “… your own risk” is in effect.

== Buttons, signals, commands and codes ==
In order to avoid involving in terms, I specify them precisely:

[[Image:Pronto-formats-buttons.jpg]] 
''Figure placeholder: Picture 1 — Interaction of buttons, IR signals, commands and IR codes''

The button, IR signal, command and IR code are not corresponding mutually:
* the same button can produce different IR signals (see Toggle Codes);
* different IR signals can be recognized by decoder as same command (see Clean and Dirty Codes);
* the same IR signal can be encoded as a number of IR codes in different formats.

== Modulated IR signal ==
For some reasons, mainly for simplicity and interference immunity, almost all IR signals, currently used to IR translation, have the same structure. IR transmitter includes a square-wave generator (oscillator), coder and IR LED. All the time of transfer oscillator generates square impulses with fixed (for this remote) carrier frequency; depending on pressed button (and, may be, remote mode), coder forms a code of command — sequence of conventional logical 0s and 1s; IR LED flashes this command modulated by generated impulses.

[[Image:Pronto-formats-2-IR.jpg]] 
''Figure placeholder: Picture 2 — IR LED replays modulated IR signal''

Any modulated IR signal can be fully characterized via carrier frequency and the sequence of period amounts when emitting is on and off. For picture 2 this sequence is 6–2–4–2–4–…

Sometimes remote emits the signal all the time until the button such as VOLUME+ will released. Another way it flashes once per press, or first, once emitted signal is not the same that repeating one, followed it. So, it is convenient to suppose that in the general way IR signal consists of once part, the start emitting sequence and repeat part. For example, endless IR signal 6-2-4-2-4-6-6-3-3-12-6-3-3-12- has the once sequence 6-2-4-2-4-6 and repeat sequence 6-3-3-12: 6-2-4-2-4-6 | 6-3-3-12. All currently used IR signals can be represented either as a union of once and repeat sequences or as the only once or only repeating sequence.

[[Image:Pronto-formats-3-IR.jpg]] 
''Figure placeholder: Picture 3 — Cutting IR signal into once sequence and repeat sequence''

Usually, IR codes, describing IR signal this way, are not so long. If learned IR code is not an air conditioner code, it can be completely go in “IR code:” field at ProntoEdit.

In the most of cases carrier frequencies are nearby 35KHz, but you will certainly be lucky enough to try a remote with 175KHz, 345KHz, 455KHz or 1.1MHz.

== “Clean” and “dirty” codes ==
[1: “Unclean” and “clean” IR commands (Working With Prontoedit: Learning & Infrared)]

It is not necessary to replay IR signal precisely, IR receiver will “identify” received IR signal as correct command, if it looks like real command adequately, say, carrier frequency and burst pairs’s lengths differ from original IR signal less than for 10%. I.e. there is precise, original IR signal for every command, may be not replay-able for Pronto, and also many IR signals that Pronto can replay and IR receiver can recognize as that command. The codes of those signals may have different lengths, and the shortest one is “clean” code, and the all other codes are “dirty” and very “dirty”.

Reasons to prefer “clean” codes:
* IR signal of “clean” IR code is more recognizable by IR receiver
* some “dirty” IR codes can lead IR receiver astray or halt it
* “clean” code is shorter, and replay of it takes less time in macros
* you can visually check “clean” IR code’s accuracy — the lengths of every “clean” IR codes per remote are the same, except, may be, buttons like VOLUME+
* “clean” code is more convenient to analyzing, in order to guess a discrete command, absent at this remote
* using of “clean” IR codes stirs ambitions of punctual Prontoyers

The ordinal way to obtain “clean” IR code is cutting from existing one [1]. Sometimes it is useful to develop special software — generator of all concrete type IR codes — in order to “discover” all possible commands, supported by that device, including those absent at remotes.

Note: There is no difference in IR learning to Pronto standalone or to computer via Pronto, but sometimes this process is faulted due a communication error.

== Toggle IR codes ==
[1: Why won’t my buttons work twice in a row? (Working With Prontoedit: Learning & Infrared)]

It is necessary not to mix up toggle IR codes and toggle IR commands. Toggle Command is a command with toggle function such as standby/on, see TOAD at [1]. In contrast to that, Toggle IR Code contains as minimal 1 toggle bit, see RC5 at [2].

There are many possible troubles and noises at IR transfer — sun, fluorescent lamps, interference with another IR transfer, dust, pets, household and tremor of hesitating hand, holding remote. First two troubles can be cured by signal modulation. Other problems, concerning temporary obstacle, are solved logically. Commonly they use two different IR signals per button — one for odd presses and another for even. As a rule, these codes differ in one or two logical bits (“toggle” bit or “parity”), and both of them encode the same command. When IR decoder receives IR signal such type, it ignores the same signals (or signals with the same “parity” bit) received twice, in order to avoid taking noise as double click.

Pronto IR learning procedure uses the only button pressing, and because of it Pronto can detect as toggle codes only codes of some predefined types, that look like known codes, for example, RC5. When Pronto replays these codes, it emits in turn odd and even IR signals for every type of predefined code format (and if existing, subformat). So repeating the same alias for “long button press” in macro is not effective for toggle codes; it is necessary to convert this code to format 0000 to do it.

If Pronto learns real toggle codes as ordinary, learn all codes in the same parity, and only the “blank” command (that does nothing, if it exists at remote) — in opposite parity, and give any Pronto button two actions — odd real command and even “blank” [1].

== Pronto IR code filling formats ==
[1: Type of code (Working With Prontoedit: Learning & Infrared)]

IR codes are kept in Pronto and in CCFs in bytes (as all data), but Pronto software uses two-byte hexadecimal words delimited by spaces at IR code view (editBox):
<code>0000 0070 0003 0002 0006 0002 0004 0002 0004 0006 0006 0003 0003 000C</code>

I will write all sizes and offsets in 16-bit words and all numbers in hex, if not specified otherwise. First word — '''wFmtID''' — identifies IR format.

Supported formats:
* 0000 — raw oscillated code
* 0100 — raw unmodulated code
* 5000 — RC5
* 5001 — RC5x
* 6000 — RC6 Mode 0
* 7000 — predefined code of variable length
* 8000 — index to UDB
* 9000, 900A, 900B, 900C, 900D, 900E — NEC
* 9001 — basic mode YAMAHA NEC code

[[Image:Pronto-formats-4-hierarchy.jpg]] 
''Figure placeholder: Picture 4 — hierarchy of Pronto IR formats''

= Raw formats (wFmtID = 0000 or 0100) =
They are simple, basic, most commonly used formats. Almost all IR signals can be represented (exactly or cognitive) either in 0000 or 0100 format. There is no way to encode toggle IR codes at these formats, but separately, odd and even IR code can be converted from toggle form to 0000 format.

== Raw oscillated code (wFmtID = 0000) ==
This is the format that is often implied, when they say “Pronto IR format”. It contains lengths while LED flashes and while
LED is off in carrier periods (“burst pairs”) in two optional parts - once and repeat sequences.

For example, code from pic.2 and 3 will encoded in this format as 0000 0070 0003 0002 0006 0002 0004 0002 0004
0006 0006 0003 0003 000С, where:

{| class="wikitable"
! offset !! size !! name !! type !! description !! sample
|-
| 0 || 1 || wFmtID || word, ID || Format ID. Must be 0000 || 0000
|-
| 1 || 1 || wFrqDiv || word, positive || Carrier frequency divider || 0070
|-
| 2 || 1 || nOnceSeq || word, length || Number of burst pairs at once sequence || 0003
|-
| 3 || 1 || nRepeatSeq || word, length || Number of burst pairs at repeat sequence || 0002
|-
| 4 || 2*nOnceSeq || aOnceSeq || array of rBurstPair || Once sequence || 0006 0002 0004 0002 0004 0006
|-
| 4+2*nOnceSeq || 2*nRepeatSeq || aRepeatSeq || array of rBurstPair || Repeat sequence || 0006 0003 0003 000C
|}

and rBurstPair consists of:

{| class="wikitable"
! offset !! size !! name !! type !! description !! sample
|-
| 0 || 1 || wLEDflash || word, positive || Periods when LED flashes with carrier || 0006
|-
| 1 || 1 || wLEDoff || word, positive || Periods when LED is off || 0002
|}

Details:
* wFmtID: word = 0000, Format ID
* wFrqDiv: word in range 0001..FFFF, wFrqDiv = 4,145146 MHz / <signal carrier>. So wFrqDiv = 0001 corresponds to signal carrier » 4,1 MHz, and wFrqDiv =FFFF ~ 63Hz. I have measured this constant indirectly and have obtained 4,1455±0,0006 MHz, which is close enough with magical number 4,145146 [2], and far enough from 4,194304 [5], but I can’t locate quartz oscillator with this nominal at catalogues.
* nOnceSeq: word in range 0000..0100, is equal to amount of burst pairs at once sequence
* nRepeatSeq: word in range 0000..0100, is equal to amount of burst pairs at repeat sequence
* wLEDflash: word in range 0001..FFFF, is amount of carrier frequency periods when LED flashes every first half-period and turned off for the last half-period
* wLEDoff: word in range 0001..FFFF, is amount of carrier frequency periods when the LED is off

Next picture will dispel all residuary questions:

[[Image:Pronto-formats-5-correspondence.jpg]] 
''Figure placeholder: Picture 5 — correspondence between IR-signal and IR-code at format 0000''

== Raw unmodulated code (wFmtID = 0100) ==
Same structure as 0000, but LED is continuously on for the first word of the burst pair (no carrier):

[[Image:Pronto-formats-6-difference.jpg]] 
''Figure placeholder: Picture 6 — difference between IR signals for 0000 vs 0100''

Differences:
{| class="wikitable"
! offset !! size !! name !! type !! description !! sample
|-
| 0 || 1 || wFmtID || word, ID || Format ID. Must be 0100 || 0100
|}

aBurstPair consists of:

{| class="wikitable"
! offset !! size !! name !! type !! description !! sample
|-
| 0 || 1 || wLEDon || word, positive || Periods when LED is on || 0006
|-
| 1 || 1 || wLEDoff || word, positive || Periods when LED is off || 0002
|}

This format completes format 0000 to universal description of all raw IR signals, but codes at format 0100 are rare – it is
exposed to sun light and other IR noises. I have learned only 2 devices with these codes – noname drape drive and Dish Satellite
Positioner. Nevertheless, sometimes it is useful to use IR signal without carrier, for example, for Sony Contol-S: you can replace an
IR probe at RX-77 to ordinal jack, change 0000 to 0100 at IR codes, and your Sony device will be controlled by Control-S. Some
other systems also support IR signals without carrier, like Crestron’s CstmFreq value = 43.

= Predefined formats (wFmtID = 5000, 5001, 6000, 7000, 8000, 9000, 9001, 900A, 900B, 900C, 900D, 900E) =
There are a number of additional, predefined IR formats, supported by some reasons. They can’t describe all IR signals, every type/subtype of this format represents only IR codes with specific structure, for custom “brand”. Also, we need additional data tables to replay these signals. These predefined formats are more compact than corresponding raw IR codes and, as a rule, simple and “clean”. I.e., if you learn IR as 5000 or 7000 and it is not a bug, then that and all other IR signals from this remote must be codes of this type.

Predefined formats have different structure, but for the reason of compatibility with format 0000, fields wFrqDiv, nOnceSeq, nRepeatSeq leave as dummy, so that code “looks” the same. aOnceSeq and aRepeatSeq are replaced with sCode, that consist real code info. Also, nOnceSeq and nRepeatSeq must meet the condition (nOnceSeq + nRepeatSeq) * 2 = sizeOf(sCode):

Template header:
{| class="wikitable"
! offset !! size !! name !! type !! description !! sample
|-
| 0 || 1 || wFmtID || word, ID || Format ID || 5000
|-
| 1 || 1 || wFrqDiv || word, dummy || Unused word for compatibility || 0000
|-
| 2 || 1 || nOnceSeq || word, dummy || Dummy code length || 0000
|-
| 3 || 1 || nRepeatSeq || word, dummy || Dummy code length || 0001
|-
| 4 || (nOnceSeq+nRepeatSeq)*2 || sCode || structure || Predefined code || 0000 0000
|}

Not all of the predefined formats are supported by any Pronto model – here a table of compatibility is:

{| class="wikitable"
! wFmtID !! RU-890/940/TS-1000/RC-5000/5000i !! TSU-2000 !! RC-5200/9200 !! TSU-6000/RU-970/USR-5 !! RAV-2000
|-
| 0000, 0100, 5000, 5001, 6000, 7000 || ✔ || ✔ || ✔ || ✔ || ✔
|-
| 8000 || || ✔ || || ✔ || ✔
|-
| 9000 || || || ✔ || ✔ || ✔
|-
| 9001 || || || || || ✔
|-
| 900A–900E || || || ✔ || ✔ ||
|}

Also, RC-3200 does not support all of this formats directly (except 0000), but RC-3200 Setup converts codes 0100, 5000, 5001 and 6000 codes into format 0000 automatically, and this feature can be used from elsewhere!

Note: 0000 format used by RC-3200 is extended by including support of unmodulated IR signals with special value of wFrqDiv = 0001.

When I describe these formats, I will translate them to format 0000, in anticipation of this converter is already exist.

= Template based formats (wFmtID = 5000, 5001, 6000, 7000, 9000, 9001, 900A, 900B, 900C, 900D, 900E) =
Template based formats are used for memory saving, for representing toggle IR codes, and for encoding IR signals with high
carrier frequency.

Segment SYS at Pronto Firmware contains 2 tables for encoding/decoding IR codes these types:

== SYS segment tables ==
{| class="wikitable"
! dID !! zSystem !! zTemplate !! zMask !! dFrqDiv !! bU1 !! dU2 !! dU3 !! dU4
|-
| 00 || rc5 || 1[01]{01}[01]%11R || 5000h + {4-8}{12,9-14} || 73 || 0 || 2 || 0 || 0A
|-
| 01 || rc6m0 || H1000ftT}[01]%16R || 6000h + {7-14}{15-22} || 73 || 0 || 0 || 0 || 0A
|-
| 02 || rc5e || 1 01]{01} [01]%5S[01]%12R || 5001h + {4-8}{12,10-15}{15-20} || 73 || 0 || 3 || 0 || 0A
|-
| 03 || b&o || 115[1234]*R?|<3[12345]* || 7000h || -09 || 0 || 5 || 0 || 14
|-
| 04 || kenwood || s$[01]%32e|rp || 7000h || -09 || 0 || 2 || 1 || 14
|-
| 05 || pioneer || o$[01]%32[RSTUo] r[01rRSTUo]* || 7000h || -04 || 0 || 4 || 1 || 14
|-
| 06 || ehrep || s[abcderst]%4[abcderst]* |s[abcderst]%4[abcderst]* || 7000h || -0C || 0 || 4 || 0 || 14
|-
| 07 || ehonce || s[abcderst]%4[abcderst]* || 7000h || -0C || 0 || 4 || 0 || 14
|-
| 08 || grundig 16ac || P{ac} [abcd]%7r || 7000h || 88 || 0 || 0 || 0 || 06
|-
| 09 || grundig 16bd || P{bd}[abcd]%7r || 7000h || 88 || 0 || 0 || 0 || 06
|-
| 0A || thomson1 || 2{12}[12]%9R || 7000h || 7C || 0 || 1 || 0 || 0E
|-
| 0B || thomson2 || {12}{12}[12]%9[RS] || 7000h || 7C || 0 || -1 || 0 || 0F
|-
| 0C || thomson3 || [12]%4{12}[12]%7[RST] || 7000h || 7C || 0 || -1 || 0 || 10
|-
| 0D || ferguson || s%2(01}[01]%9[RS] || 7000h || -0C || 1 || 4 || 0 || 0D
|-
| 0E || telefunken || (01} {01}[01]%9[RS || 7000h || -18 || 1 || -1 || 0 || 0E
|-
| 0F || echostar || T01]%5R || 7000h || 42 || 0 || -1 || 0 || 07
|-
| 10 || saba || (01}{01}[01]%9[RS || 7000h || -08 || 1 || -1 || 0 || 0E
|-
| 11 || crown || 2{12}[12]%9[RS] || 7000h || 6D || 0 || 2 || 0 || 0E
|-
| 12 || seleco || 2(12}[12]%9[RS || 7000h || 63 || 0 || 2 || 0 || 0E
|-
| 13 || nec1a || I[01]%32F|R || 900Ah + {8-1,16-9)}{24-17,32-25} || 6D || 0 || 0 || 0 || 0E
|-
| 14 || nec1b || I[01]%32F || 900Bh + {9-2,17-10}{25-18,33-26} || 6D || 0 || 0 || 0 || 0E
|-
| 15 || nec1c || I[01]%32FI[01]%32F|R || 900Ch + {8-1,16-9}{24-17,32-25} {42-35,50-43}{58-51,66-59} || 6D || 0 || 0 || 0 || 0E
|-
| 16 || nec1d || I[01]%32F|I[01]%32F || 900Dh + {8-1,16-9}{24-17,32-25} {43-36,51-44}{59-52,67-60} || 6D || 0 || 0 || 0 || 0E
|-
| 17 || nec1e || I[01]%32FI[01]%32F || 900Eh + {9-2,17-10}{25-18,33-26} {43-36,51-44}{59-52,67-60} || 6D || 0 || 0 || 0 || 0E
|-
| 18 || nec2a || I[01]%32FJR || 900Ah + {8-1,16-9}{24-17,32-25} || 68 || 0 || 0 || 0 || 0E
|-
| 19 || nec2b || I[01]%32F || 900Bh + {9-2,17-10}{25-18,33-26} || 68 || 0 || 0 || 0 || 0E
|-
| 1A || nec2c || I[01]%32FI[01]%32F|R || 900Ch + {8-1,16-9}{24-17,32-25} {42-35,50-43}{58-51,66-59} || 68 || 0 || 0 || 0 || 0E
|-
| 1B || nec2d || I[01]%32F|I[01]%32F || 900Dh + {8-1,16-9}{24-17,32-25} {43-36,51-44}{59-52,67-60} || 68 || 0 || 0 || 0 || 0E
|-
| 1C || nec2e || |I[01]%32FI[01]%32F || 900Eh + {9-2,17-10}{25-18,33-26} {43-36,51-44}{59-52,67-60} || 68 || 0 || 0 || 0 || 0E
|-
| 1D || nec || I[01]%32%F|R || 9000h + {8-1}{16-9}{24-17}{32-25} || 6D || 0 || 0 || 0 || 0E
|-
| * || rc6m6a-24 || H1110{tT}0[01]%23R || 6001h + {8-14)}{15-22}{23-30} || 73 || 0 || ? || 0 || ?
|-
| ** || rc6m6a-32 || H1110{tT} 1[01]%31R || 6001h + {8-22}{23-30}{31-38} || 73 || 0 || ? || 0 || ?
|-
| *** || yamahanec || ?I[01]%32F|R || ?9001h + {8-1}{24-17}, + {!16-19}{132 -! 25} || ?6D || 0 || 0 || 0 || ?
|}

{| class="wikitable"
! dID !! bCh !! [i] !! aBurstSeq !! dID !! bCh !! [i] !! aBurstSeq !! dID !! bCh !! [i] !! aBurstSeq
|-
| 00 || R || 0 || -0CA0 || 02 || R || 0 || -0AA0 || 03 || 1 || 5 || 005B -0546
|-
| 00 || 0 || 1 || 0020 -0020 || 02 || S || 1 || -0080 || 04 || p || 0 || 0103 -AD01
|-
| 00 || 1 || 2 || -0020 0020 || 02 || 0 || 2 || 0020 -0020 || 04 || e || 1 || 0103 -47D5
|-
| 01 || H || 0 || 0060 -0020 || 02 || 1 || 3 || -0020 0020 || 04 || s || 2 || 0103 -1745
|-
| 01 || T || 1 || 0020 -0020 || 03 || R || 0 || 005B -C422 || 04 || r || 3 || 1010 -040C
|-
| 01 || t || 2 || -0020 0020 || 03 || 5 || 1 || 005B -1BC0 || 04 || 0 || 4 || 0103 -0309
|-
| 01 || 0 || 3 || -0010 0010 || 03 || 4 || 2 || 005B -1622 || 04 || 1 || 5 || 0103 -0103
|-
| 01 || 1 || 4 || 0010 -0010 || 03 || 3 || 3 || 005B -1083 || 04 || s$ || 6 || 1010 -081E
|-
| 01 || R || 5 || -0BC0 || 03 || 2 || 4 || 005B -0AE4 || 05 || r || 0 || 227B -1160
|-
| 05 || R || 1 || 022C -8FFA || 0A || R || 0 || 0006 -0857 || 10 || S || 1 || 0009 -58D2
|-
| 05 || S || 2 || 022C -6108 || 0A || 2 || 1 || 0006 -011A || 10 || 0 || 2 || 0009 -0F3E
|-
| 05 || T || 3 || 022C -4165 || 0A || 1 || 2 || 0006 -00BB || 10 || 1 || 3 || 0009 -0A2A
|-
| 05 || o || 4 || 022C -31AF || 0B || R || 0 || 0010 -0857 || 11,12 || R || 0 || 0006 -0841
|-
| 05 || U || 5 || 022C -2C13 || 0B || S || 1 || 0010 -0642 || 11,12 || S || 1 || 0006 -065B
|-
| 05 || 0 || 6 || 022C -0684 || 0B || 2 || 2 || 0010 -0112 || 11,12 || 2 || 2 || 0006 -011A
|-
| 05 || 1 || 7 || 022C -022C || 0B || 1 || 3 || 0010 -00B1 || 11,12 || 1 || 3 || 0006 -00BB
|-
| 05 || o$ || 8 || 227B -1160 || 0C || R || 0 || 0010 -059D || 13–1D, *** || I || 0 || 0157 -00AB
|-
| 06,07 || r || 0 || 00FC -347B || 0C || S || 1 || 0010 -0417 || 13–1D, *** || F || 1 || 0016 -05E7
|-
| 06,07 || a || 1 || 00FC -00FC || 0C || T || 2 || 0010 -02FB || 13–1D, *** || 1 || 2 || 0016 -0040
|-
| 06,07 || e || 2 || 00FC -007E || 0C || 2 || 3 || 0010 -0099 || 13–1D || 0 || 3 || 0016 -0015
|-
| 06,07 || t || 3 || 007E -347B || 0C || 1 || 4 || 0010 -0044 || 13,15,18,1A || R || 4 || 0157 -0055 0016 -0E3B
|-
| 06,07 || s || 4 || 007E -0274 || 0D || R || 0 || 0008 -4B7B || * ** || H || 0 || 0070 -0020
|-
| 06,07 || b || 5 || 007E -017A || 0D || S || 1 || 0008 -3A74 || * ** || T? || 1 || 0020 -0020
|-
| 06,07 || c || 6 || 007E -00FC || 0D || 0 || 2 || 0008 -0A2B || * ** || t || 2 || -0020 0020
|-
| 06,07 || d || 7 || 007E -007E || 0D || 1 || 3 || 0008 -06C3 || * ** || 0 || 3 || -0010 0010
|-
| 08,09 || P || 0 || 0019 -005A 0028 || 0D || s || 4 || 0008 -0515 || * ** || 1 || 4 || 0010 -0010
|-
| 08,09 || a || 1 || -0044 0024 || 0E || R || 0 || 0008 -2BAE || * || R || 5 || -0AB0
|-
| 08,09 || b || 2 || -0036 0012 -000E 0012 || 0E || S || 1 || 0008 -2104 || ** || R || 5 || -09B0
|-
| 08,09 || c || 3 || -0022 0012 -0022 0012 || 0E || 0 || 2 || 0008 -05CA || 10 || R || 0 || 0009 -74F3
|-
| 08,09 || d || 4 || -000E 0012 -0036 0012 || 0E || 1 || 3 || 0008 -03D9 || || || ||
|-
| 08,09 || r || 5 || -07FC || 0F || R || 0 || 0019 -024C || || || ||
|-
| 0F || 0 || 1 || 0019 -010A || 0F || 1 || 2 || 0019 -00AF || || || ||
|}

At the first table: 
dID – subformat, used at format 7000 and for connection with second table
zSystem – unused string, “brand”-like description of dID
zTemplate – template of logical structure of IR signal of this type (dID)
:<letters> and <numbers> - are references as bCh to second table, where they (with dID) point out to a concrete aBurstSeq
:| – delimits once sequence and repeat sequence parts
:[<chars>] – means any of suggested characters
:{<char1><char2>} – corresponds to toggle bit: at odd replaying of IR code of this type must be <char1>, at even – <char2>
:%<number> - means <number> of duplicates of previous character/term
:* - any number of any previously defined characters at [<chars>]
:<char>$ - strange 2-byte name for char, nothing else :)
:?, < - garbage that must be ignored :)
zMask – mask, correspondence between zTemplate and IR code at Fixed Size Template Based Formats. Be described at these formats. zMask is used while learning only.
:Hexadecimal word is wFmtID
:{<expression>} – means description of corresponded word from sCode
:<number> - means index at forming String Code for corresponded bit at sCode word
:<number1>-<number2> - means a range (inversed range) of these bounds – <number1>, <number1+(-)1>, …,
::<number2>
:!<number> – means index at String Code for logical negation of corresponded bit at sCode
dFrqDiv – carrier frequency divider. “-“ means high (>58KHz?) frequency, that is need to be analyzed (when learning) with another filter, I think, so “-“ must be ignored.
bU1, dU2, dU3, dU4 – additional class/format characteristics. I suppose, they are used by recognition routine, or as additional info, like index of developer, who encodes special code for this format/subformat :), and must be ignored at replaying/converting.

At the second table: 
dID – same as at the first table
bCh – means index (char) from zTemplate or String Code
[i] – means index to aBurstSeq from aCode (same as wCIdx) at Predefined Codes of Variable Length (7000)
aBurstSeq – analogue of burst pair with variable length – from 1 to 4 words. Positive words mean time when LED flashes, negative – when LED is off.

= Predefined code of variable length (wFmtID = 7000) =
Structure (example: Grundig):
{| class="wikitable"
! offset !! size !! name !! type !! description !! sample
|-
| 0 || 1 || wFmtID || word, ID || Format ID = 7000 || 7000
|-
| 1 || 1 || wFrqDiv || word, dummy || Unused word || 0088
|-
| 2 || 1 || nOnceSeq || word, dummy || Dummy length || 0000
|-
| 3 || 1 || nRepeatSeq || word, dummy || Dummy length || 0007
|-
| 4 || 1 || wSubFmtID || word, ID || SubFormat ID (dID) || 0008
|-
| 5 || 1 || nCodeSeq || word, length || Length of aCode || 000B
|-
| 6 || nCodeSeq || aCode || array of wCIdx || Code indexes to String Code || 0010 0000 0017 0001 0001 0001 0001 0001 0001 0001 0005
|-
| 6+nCodeSeq || 0 or 1 || wRest || word, dummy || Present if nCodeSeq is odd || 0044
|}

Condition: (nOnceSeq + nRepeatSeq) * 2 = 2 + nCodeSeq + sizeOf(wRest)

String Code selection:
* if wCIdx < 0010: use firmware table (dID, bCh, [i]) where dID = wSubFmtID and [i] = wCIdx
* if wCIdx = 0010: bCh = “1”
* if wCIdx > 0010: toggle char; odd replay uses zTemplate[wCIdx - 14], even uses zTemplate[wCIdx - 13]

''Figure placeholder: Picture 8 — Forming String Code from 7000''

= Index to UDB (wFmtID = 8000) =
Some models support an internal IR database (UDB). Others rely on software DBs.

'''Database availability'''
{| class="wikitable"
! model !! DB type !! file !! size
|-
| TS-1000, RU-890, RU-940 || IR database at ProntoEdit || rcir.mdb (Jet) || 360,448
|-
| TSU-2000, TSU-6000 || UDB || UDP_int.hex || 362,711
|-
| RU-970 || UDB || UDP_int.hex || 662,090
|-
| TSU-500 || UDB as part of || TSU500.dat (Jet) || 5,851,136
|-
| RU-930 || UDB as part of || RU930.dat (Jet) || 7,299,072
|-
| TSU-3000 || UDB || UDB_TSU3000.bin || 422,622
|-
| RC-5000/5000i/5200/9200 || IR database at TSS || rcir.mdb (Jet) || 978,944
|-
| RC-3200 || — || — || —
|-
| RAV-2000 || UDB || ww_udp.idb || 662,090
|-
| USR-5 || UDB || ww_udp.idb || 661,011
|}

'''Code example (Power On for Amp Yamaha, code set 1):'''
<code>8000 0000 0002 0000 000a 23f0 0002 0000</code>

Structure:
{| class="wikitable"
! offset !! size !! name !! type !! description !! sample
|-
| 0 || 1 || wFmtID || word, ID || Must be 8000 || 8000
|-
| 1 || 1 || wFrqDiv || word, dummy || Unused || 0000
|-
| 2 || 1 || nOnceSeq || word, dummy || Dummy length || 0002
|-
| 3 || 1 || nRepeatSeq || word, dummy || Dummy length || 0000
|-
| 4 || 1 || wDevType || word, index || Device type (000A = Amp) || 000A
|-
| 5 || 1 || wBrandCodeSet || word, index || Brand/Code Set (23F0 = Yamaha-1) || 23F0
|-
| 6 || 1 || wFunction || word, index || Function (0002 = Power On) || 0002
|-
| 7 || 1 || wRest || word, dummy || Padding to even words || 0000
|}

Functions and device-type enumerations follow the UDB. Not all combinations are supported across all models.

= References =
There are a number of articles about IR formats applied to Pronto on the internet:
# Daniel Tonks “Unofficial Philips Pronto & Marantz RC5000 FAQ”, http://www.remotecentral.com
# Marcel Majoor “Communicating with the Pronto”, http://home.hccnet.nl/m.majoor
# Barry Gordon “ProntoEdit’s IR Display Format”, http://the-gordons.net:8080/, http://www.remotecentral.com/features/irdisp1.htm
# Barry Shaw, Rob Crowe, Andrea Whitlock “Yamaha extended IR codes”, http://darius.mobius-soft.com/~andrea/
# Stewart Allen, “The CCF file format”, http://giantlaser.com/tonto/

----
''Author note:'' Please excuse my poor English. For questions about Pronto IR you can reach me at eoulianov@hotbox.ru, and I will try to answer more clearly :)