The WHAT and WHY of JP-1

A few months ago, my coffee table was littered with remote controls. The one most used was a Millenium 4 provided by my cable company to control the DCT-2000 digital cable converter. The “Mil 4” (without JP1) was capable of controlling three other devices, and I had programmed it to do so – sort of. But, many of the functions on my TV still weren’t available. It was the same with the VCR. And, every time I pressed one of several number keys on the remote while in the Audio mode, my receiver would switch to another input. Something had to change.

Then one day I stumbled across “remotecentral.com” and, from there, “hifi-remote.com”. It wasn’t long before I discovered the JP1 Forums (Forums) and the Yahoo! Groups JP1. I had found Nirvana.

Within hours, I’d ordered a JP1 cable, downloaded every file in sight and, over the next few days, read just about every post to the Forums – learning about other peoples’ problems. But where was the “system documentation”? I had read and re-read Tommy Tyler’s “JP1 for Beginners” and found it very helpful. It told me what tools to use and how to use them. But, with my programming and system engineering (and other things) background, I felt I needed more. I wanted to better understand what I was trying to do – from a system perspective – and why it was necessary. For a “newbie”, having to infer everything from descriptions in the Forums of other peoples’ problems and the experts’ solutions was not ideal. There had to be a better way!

To make a long story short, after programming my Mil 4 using JP1 and still finding it wanting, I purchased a new One-For-All URC 8911. With the extender, my 8911 allowed me to do everything I wanted in controlling my expanding home theater system – but implementation was not without difficulty as several of my early posts to the Forums will attest.

Then, I started looking “behind the scenes” to learn the “whats” and “whys” of JP1. And that’s what I would like to pass along.

Before going on to that, however, I want to offer my thanks to the current set of JP1 experts and, presumably, a few of their predecessors, who have “hacked” their way to the present state of JP1 and who patiently “held my hand” as I found my way through Nirvana. This manual is my way of giving back a little. I also want to thank the experts who took the time to read this manual and offer constructive criticism – in particular Jon Armstrong, who reviewed two draft versions in detail and made a number of suggestions for improvement. “The WHAT and WHY of JP1” is a better document because of them.

2. JP1 Remote ControlS

Regardless of what label is on the front of your JP1 remote control, it was made by Universal Electronics Inc. (UEI). UEI markets its remotes to consumers under the “One-for-All” (OFA) brand name. The individual model numbers are usually preceded by “URC”, presumably standing for “universal remote control”. Radio Shack JP1-enabled remotes and those sold under other names are somewhat different in appearance from the OFA remotes. In some cases, they are also electronically different (e.g., some of the Radio Shack models have two IR LEDs (transmitters) while OFA remotes have only one). But, these remotes too are manufactured by UEI. UEI also markets another series of remotes, called OEM remotes, to manufacturers and marketers of cable converters, satellite receivers and other home theater components. These remotes generally will bear the name of, and may have otherwise been customized by, the component manufacturer/marketer.

2.1 Codes and Protocols

“Out of the box”, a JP1 remote control is pre-programmed with a variety of manufacturer’s codes and protocols.

A manufacturer’s code defines:

· the infrared (IR) signal that the remote is to send to the associated equipment when a button on the remote is pressed, and

· the protocol, or signalling scheme, to be used.

A manufacturer’s code has two specifiers:

· device type, e.g., TV, Cable, DVD, etc., which selects a particular button configuration on the remote, and

· a four-digit identifier known as the setup code.

Each device button on the remote, i.e., one of a set buttons that determines the home theater equipment component with which the remote communicates at any point in time (the active device) may be assigned a specific manufacturer’s code. The device type is inherent in the name of the device button to which the manufacturer’s code is assigned (though remotes often have provisions for changing the device type of a button). So, assigning a manufacturer’s code to a device button involves pressing the remote’s “Setup” key (sometimes designated the “P” key) until the remote gives a specific response, followed by a device button, thereby selecting a device type, and then entering the numeric setup code. This sequence is one of a series known as long-Setup-keypresses.

It should be noted that, while UEI refers to the stored data pertaining to specific devices as manufacturer’s codes and, generally, that the term is so used in this manual, in the JP1 “world”, the term setup code is sometimes used synonymously with manufacturer’s code as well as referring just to the numeric identifier of a manufacturer’s code .

A protocol is a program that momentarily takes control of the remote while it transmits (over the IR link) the button code specified in the manufacturer’s code for the pressed key. Such protocols are sometimes called executors by UEI and in the Forums. The term protocol is also used to refer to the characteristics, or signature, of the IR signal. Consequently, one must be aware of the context in which the term is used.

Different home theater equipment requires the information transmitted by the protocol to be presented in different ways. There are one-byte protocols and two-byte protocols, i.e., protocols where all the information required to control a particular device operation (the command) is stored in a single byte and others where two bytes are transmitted . Some protocols transmit the least significant bit (LSB) of the command first, others transmit the most significant bit (MSB) first. Still others transmit in one’s complement form, i.e., a binary 1 is replaced by a binary 0, and vice versa. Some protocols address a single device, others address multiple devices. And, of course, there are various information signalling schemes. The topic is so diverse that proper coverage is well beyond the scope of this manual.

Fortunately, so long as your equipment uses standard protocols, most of this complexity will be transparent. For example, each manufacturer’s code completely specifies the protocol to be used in dealing with the physical device. So, when you program the manufacturer’s code for a piece of equipment, you are inherently specifying the associated protocol – without having to worry about all its idiosyncrasies. If the setup code has been pre-programmed in the remote, the required protocol also will be pre-programmed. Even if you add to or replace the pre-programmed manufacturer’s codes using device upgrades (see Section 5.5), in many cases, you will still make use of pre-programmed protocols. Should it be necessary to add a protocol to your remote, the JP1 tools make this a relatively painless affair.

Generally, the difficult part is in determining which protocol(s) and variants are required for a new piece of equipment, i.e., one not yet in broad use. (Learning remotes are very handy for this purpose.) However, for their own benefit, (and, also, fortunately for ours) home theater equipment manufacturers tend to be consistent in their use of protocols and key code schemes. Once a manufacturer selects a protocol for its equipment, it generally will use that same protocol and, often, the same key code arrangement across its then-current range of products of the same type. For example, most current Panasonic TVs use the TV/0250 setup code. Most new Toshiba home entertainment products (and a number of others) make use of the standard NEC1 protocol; but, the setup code number may vary between equipment types.

Nonetheless, from time to time this manual will remind you of the complexity noted above – but usually as a means to demonstrate some capability of JP1. For those who are interested in more detail, there are a number of articles on the web addressing the topic of IR generally and signalling schemes for home theater equipment. A good place to start is the Infrared section at hifi-remote.com.

2.2 Basic Operation

A JP1 remote control, like any other universal remote, is a microprocessor-controlled device. Its main program, the operating system, responds to button presses, decodes the information in the remote’s memory associated with the buttons that are pressed, including the codes to be sent to the physical device being controlled, and sends those codes to the appropriate device via an infrared (IR) signal.

In a remote’s most basic operation, when a button other than a device button is pressed, the operating system:

· accesses the manufacturer’s code assigned to the active device (generally, the device whose device button was pressed most-recently)

· determines from the manufacturer’s code the information to be sent for the button that was pressed and the protocol that is to send it

· calls (prepares to execute) the program associated with the specified protocol, passing that information to the program and

· turns control over to the program which, using the IR transmitter, sends the information to the equipment using the specified protocol.

Once the protocol has done its job, it relinquishes control to the operating system which then idles, awaiting the next button press.

That’s all there is to it! Of course, LEDs flash and LCDs get updated and backlights go on and off, but that’s all incidental.

2.3 Programming the Remote Directly

Without JP1, the operation of JP1-enabled remotes may be altered in three main ways, other than by assigning setup codes to device buttons (as discussed above) and by learning as described in the manual (for those remotes that support that capability):

· by using a 9-9-4 long-Setup-keypress to enter an advanced code that will alter the code transmitted to the equipment from that specified in the manufacturer’s code

· by using a 9-9-5 long-Setup-keypress to enter a macro, i.e., a series of keystrokes, on certain keys other that device keys; (when the key to which the macro is assigned is later pressed, it will effectively repeat the series of entered keystrokes)

· by having UEI upgrade the remote either by returning the remote to the factory or, in the case of present-day remotes, via telephone using the remote’s built-in acoustic adapter.

Depending on the remote, other 9-x-x long-Setup-keypresses may be documented in the manual, but these are the main ones.

In the OFA manuals, at least, the 9-9-4 long-Setup-keypress is not documented at all and the 9-9-5 entry is noted as being applicable only to setting-up FAV lists and “Tune-In” keys. So, it’s clear that UEI never intended for users to perform these expanded functions – perhaps for fear of the product support burden it would generate.

3. JP1 – The System

JP1 builds on the 9-9-4 and 9-9-5 long-Setup-keypress capabilities described in the previous section to allow the development of advanced code entries (also known as keymoves), macros and, indeed, complete device upgrades on a personal computer and their uploading into a JP1-enabled remote control.

Several weeks after this manual was first introduced, Rob Crowe published his “JP1 – Just How Easy is It?”, in which he also deals with getting started with JP1.

3.1 System Components

JP1 is a system comprising:

· a JP1-enabled remote control

· a JP1 cable (parallel, serial and USB versions supported) for communication between computer and remote, and

· a personal computer on which the following programs/files are available:

· RDF files, which defines the characteristics of the remote controls of interest

· IR.exe program to format the data to be uploaded to the remote and handle the communications between computer and remote

· either Keymap-Master (a MS Excel-based tool commonly referred to as “KM”) or the still-under-development RemoteMaster (a Java-based tool referred to as “RM”), both of which support the development of device and protocol upgrade files

· Devices4, another MS Excel-based tool that provides, for a given device setup code, the associated protocol details and the enhanced function codes and

· if planning to use an extender:

· ExtenderCodeCalc, a MS-Excel-based tool that is useful in setting up and debugging some of the features useable with extenders and

· ExtInstall, a special installation program that will consolidate your remote’s existing configurations, i.e., keymoves, macros, etc. with an extender and its special protocols.

All these software tools are available from the Files section of Yahoo! Groups JP1. ExtInstall can be downloaded from the Files|Extenders subsection; most of the others can be found in the Files|Tools subsection. Note that the actual names of the program files stored at Yahoo! Groups JP1 may include a version number.

Each of these programs has one or more ReadMe files which, among other things, describe the installation and operating procedures and identifies other special requirements. As well, “JP1 for Beginners”, available from the Files|Help subsection includes detailed downloading and operating instructions for IR.exe, KM and Devices4.

The JP1 tools are continually being enhanced and otherwise upgraded. To minimize preventable difficulties, you should always use the most recent version.

There are also a number of other utility programs that have been developed for specialized use in JP1 programming, including:

· ProtocolBuilder, for experienced JP1 users who wish to create new protocols, e.g., for IR controlled appliances around the home and home theater equipment not pre-programmed in the remote or supported by KM or RM

· ccf2efc - decodes Pronto ccf files into device, protocol and OBC/EFC, and provides Pronto hex useful for manual decoding by advanced users

· cml2efc – decodes RTI TheatreTouch files

· DecodeCCF – decodes a ccf file into a formatted text file that can be pasted into a spreadsheet. This is the most useful decoder of Pronto ccf files since it eliminates much of the information that would be returned by ccf2efc. It also works with all versions of ccf files

· IRTool – decodes Pronto hex text files typical of those found at remotecentral.com in that website’s Files|Pronto|Discrete section.

The latter four programs require DecodeIR.dll to be present in the Windows\system directory. These tools also are available from the Files section of Yahoo! Groups JP1.

If you are simply programming a JP1 remote to manage devices for which you have, or can learn, the advanced codes and that use protocols already pre-programmed in the remote or supported by KM/RM, you will have no need for these specialized utilities.

3.2 The JP1 Cable

A JP1 cable is available from a number of mail-order sources (see hifi-remote.com). Being a relatively simple device, the cable can also be built “from scratch” with a minimum of parts. Full instructions are available from Yahoo! Groups JP1, in the Files|Interface Designs subsection.

3.3 The JP1 Connector

Most JP1-enabled remotes will have a six-pin connector mounted on the printed circuit board. The connector is accessible once the battery compartment cover is removed. However, some recently-introduced OFA remotes are no longer equipped at the factory with the connector (presumably to make hackers’ lives more difficult) and instead, have only the six holes in the PCB where the connector would be mounted.

If a ready-made JP1 cable is purchased, it will probably be delivered with a pin header plugged into the cable – to avoid the pin header getting lost in the packing material. (If you don’t look carefully, the header together with the connector at the remote end of the cable appears to be a male connector, rather than the female type required for connection to the remote, and you may assume that “they” sent the wrong cable.) If your remote already has a connector on its PCB, simply remove the header and set it aside. If your remote does not have a JP1 connector, you may either solder the pin header onto the PCB – if you or a friend are appropriately skilled (the Robman says you must use flux) – or simply leave it plugged into the cable and, when you want to upload or download data to/from the remote, press the (effectively male) connector into the mating holes in the PCB. Unfortunately, this latter practice sometimes does not result in a good electrical connection. An alternative is a “pogo pin adapter”, which will allow better contact and which may be purchased from the same sources as JP1 cables.

3.4 Where Does the Uploaded Data Go?

The JP1 connection on the PCB allows direct access to the remote’s eeProm – the non-volatile memory where keymoves, macros, learned instructions, and protocol and device upgrades are stored. Using the JP1 connection, keymoves and macros may be entered directly from a computer, rather than by long-Setup keypresses on the remote. Pre-programmed manufacturer’s codes can be effectively modified using device upgrades and entirely new codes can be entered into the remote – all without reference to EUI.

4. RDF Files

RDF stands for remote definition file. As the name implies, a RDF describes the characteristics of a particular JP1-enabled remote. Among other things, a RDF declares a remote’s eeProm memory allocations, identifies the key numbers assigned to every button on the remote, specifies the mapping of groups of buttons (the button map), and lists the IR protocols pre-programmed on the remote and the standard digit maps (sequences of codes for the numeric keys) supported by the remote.

The MSWord file “RDF3Spec.doc”, available from the Files|Tools subsection of Yahoo! Groups JP1, provides a detailed description of the contents of current (version 4) RDF files. An important (and unalterable, unless you really want to make your life difficult) feature of each RDF is its name which, in part, is the signature of the remote it defines. The signature, which is stored in eeProm in the remote, is how JP1 identifies which remote it is dealing with.

While “RDF3Spec.doc” goes into great detail on certain aspects of the RDF, it is somewhat brief in two areas, i.e., button maps and digit maps.

A button map is a series of key numbers. Some of these key numbers are collected together between parenthesis, indicating keys that are treated as a group. On the URC 8911, the first set of key numbers is the numeric keys. These are followed by two more groups: the Vol+, Vol- and Mute keys and then the Ch+ and Ch- keys. The remaining keys in the series are treated individually. A RDF file may include several button maps, the button map to be used for any particular device being based on the device type assigned to the equipment. (This is one of the purposes of the [DeviceTypes] section of the RDF file.) A button map:

· defines the keys that may be programmed

· as will be described later, establishes the sequence of the data in setup codes and device upgrades.

Button maps may differ from remote to remote.

Digit maps are predefined, popular sequences of OBCs for the number keys. Instead of individually specifying the OBCs for the number keys in manufacturer’s codes and device upgrades for every device, only the index of the appropriate sequence for the particular device need be provided. Of course, if the device doesn’t conform to any of the predefined sequences for number keys, the OBCs must be specified individually in the device upgrade.

5 JP1 DATA FORMATS, DATA STRUCTURES AND OTHER ENTITIES

JP1 allows a very significant expansion in the “native” capabilities of JP1-enabled remotes. But, to be able to implement and those addition capabilities, some appreciation of JP1’s data structures and terminology is necessary.

5.1 Key Numbers

Each key on a JP1 remote is assigned a key number. This is the number used for internal (to the remote) references to that key. The association between key and key number is defined in hardware and is unalterable. Key numbers are reflected in a remote’s RDF file. If a remote supports shifted and/or x-shifted keys (see Section 5.10), each shifted and x-shifted key will also have an assigned key number, but that assignment will be handled via software. The key number of the unshifted key is often referred to as the base key number. When a macro or keymove is assigned to a key, it is not assigned to the physical key directly; it is really assigned to that key’s key number. A physical keypress causes the operating system to search for a function assigned to the associated key number.

5.2 Advanced Codes, EFCs, OBCs and Hex

There are three fundamental data formats in JP1:

· extended function codes (EFC)

· original button codes (OBC)

· hex codes.