Pronto IR Formats
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:

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.

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.

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):
0000 0070 0003 0002 0006 0002 0004 0002 0004 0006 0006 0003 0003 000C
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
Figure placeholder: Picture 4 — hierarchy of Pronto IR formats
Raw formats (wFmtID = 0000 or 0100)
Almost all IR signals can be represented (exactly or cognitively) either in 0000 or 0100 format. Toggle IR codes cannot be encoded in these formats, but odd/even variants can be converted separately from toggle form to 0000.
Raw oscillated code (wFmtID = 0000)
Contains burst pairs (LED “flash”/“off” lengths, measured in carrier periods), in optional once and repeat sequences.
Example:
0000 0070 0003 0002 0006 0002 0004 0002 0004 0006 0006 0003 0003 000C
| 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 |
rBurstPair:
| 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:
- wFrqDiv in range 0001..FFFF, with: wFrqDiv = 4.145146 MHz / <signal carrier>. So 0001 ≈ ~4.1 MHz, FFFF ≈ ~63 Hz.
- nOnceSeq: 0000..0100 burst pairs in once sequence
- nRepeatSeq: 0000..0100 burst pairs in repeat sequence
- wLEDflash, wLEDoff: 0001..FFFF
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):
Figure placeholder: Picture 6 — difference between IR signals for 0000 vs 0100
Differences:
| offset | size | name | type | description | sample |
|---|---|---|---|---|---|
| 0 | 1 | wFmtID | word, ID | Format ID. Must be 0100 | 0100 |
aBurstPair:
| 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 is rare and more exposed to IR noise. It can be useful for systems expecting unmodulated signals (e.g., Sony Control-S).
Predefined formats (wFmtID = 5000, 5001, 6000, 7000, 8000, 9000, 9001, 900A, 900B, 900C, 900D, 900E)
These represent brand-specific structures; compact and typically “clean.” Fields wFrqDiv, nOnceSeq, nRepeatSeq remain as dummies for 0000-compatibility, and aOnceSeq, aRepeatSeq are replaced by sCode. Condition: (nOnceSeq + nRepeatSeq) * 2 = sizeOf(sCode).
Template header:
| 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 |
Model support matrix (summary)
| 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 | ✔ ☐ | ✔ ☐ |
Note: RC-3200 converts 0100, 5000, 5001, 6000 to 0000 automatically. RC-3200 extends 0000 with unmodulated support via wFrqDiv=0001.
Figure placeholders and detailed SYS tables omitted for brevity; can be added on request.
Template-based formats of fixed size
Ranges (examples):
- 5000 0000 0000 0001 0000 0000 — 5000 0000 0000 0001 001F 007F
- 6000 0000 0000 0001 0000 0000 — 6000 0000 0000 0001 00FF 00FF
- 9000 0000 0000 0002 0000 0000 0000 0000 — 9000 … 00FF 00FF 00FF 00FF
- 900A 0000 0000 0001 0000 0000 — 900A … FFFF FFFF
Notes:
- NEC 32-bit signals typically: 8-bit device, 8-bit device complement, 8-bit function, 8-bit function complement.
- Newer Pronto models may learn NEC as 900A–900E; recognition can misclassify. Older models learn NEC as 0000 006* …
Figure placeholder: Picture 7 — Converting fixed template to 0000
Predefined code of variable length (wFmtID = 7000)
Structure (example: Grundig):
| 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
| 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):
8000 0000 0002 0000 000a 23f0 0002 0000
Structure:
| 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 :)