DecodeIR (Readme)

DecodeIR: Main Document, Read me, Index

Introduction

The primary purpose of this document is to explain any peculiarities of the decoding of each protocol. Click in the list above on each protocol name to get any information specific to decodes with that name.

If you don't understand the advanced information (IRP notation, etc.) at the start of each of those entries, don't worry about that and please don't let it stop you from reading the text below that. In many cases there is important protocol-specific information you will need in order to use the data from the decode.

Decode problems

The decoder only looks at one IR signal at a time. Sometimes it gives contradictory results for a signal. The best way to determine which result is correct is to compare with the decodes of other signals for the same device.

Spurious decodes and non-robust protocols

Most IR protocols have enough internal consistency checks that the decoder can reliably tell whether that protocol is present in a learned signal and can reliably decode the device, subdevice and OBC numbers. If the signal is learned badly enough, the decoder may fail to find that protocol in the signal. But it is very unlikely to decode it with the wrong numbers or to imagine that protocol is a bad learn of something else.

Some protocols are not robust. A totally unrelated IR signal can accidentally fit the pattern of such a protocol resulting in a spurious decode. When you get a decode for a non-robust protocol you need to exercise some judgment about whether to believe or ignore that decode. Usually you can decide based on decodes of other signals of the same device.

EFC, JP1, KeyMoves, Upgrades, etc.

Much of this document assumes DecodeIr is being used with JP1 or at least with a JP1 capable remote. But some people will be using DecodeIr with other types of remote.

If your remote is not OneForAll brand and is not one of the models of Radio Shack (or a few other brands) that uses the same design as OneForAll, then everything this document says about JP1, KeyMoves, Upgrades, KM, RM (RemoteMaster), and EFC numbers has no meaning for your use. Just ignore those references and the rest of this doc should apply to your use. Also ignore the EFC numbers in the actual output from DecodeIr.

If you are using a OneForAll type remote but have neither a JP1 cable nor a remote model that can be upgraded by .wav file, then nothing about Upgrades, KM, RM, and OBC numbers applies to your use. If the decodes you get include EFC numbers and you know (or can ask in a forum) which setup code is right (corresponds to the protocol, device and subdevice of the decode) then you can use those EFC numbers in KeyMoves. Note that the decoding process cannot directly tell you which setup code is needed to generate the signal. If you post a question in an appropriate forum with the protocol name, device number, subdevice number, and which model OneForAll type remote you have, someone will probably identify the setup code for you.

Toggle bits

Several different protocols include something called a toggle bit. This means that each command has two or more different forms. Some protocols (e.g. RC5) alternate the toggle on each key press, while others change the toggle to indicate a start or end frame.

An alternating toggle lets the device receiving the commands distinguish between a long press of a button and two short presses. For example, if you press and hold the '1' button the remote continuously sends repeats of a single form of the '1' command. But if you press '1', release it and press it again the remote will switch to the other form of the command for the second press.

When you learn such a command you are capturing just one form of the command and every use will send that same form. If you use that learned signal and press the same button twice in a row, the device receiving the signal will see that as one long press rather than two short ones. For keys, such as digits, where one long press has a different meaning than two short presses, that gets quite inconvenient.

With OneForAll type remotes, using an upgrade or KeyMove will solve that problem.

For some of these protocols, for some models of Pronto remote, there is a condensed encoding of the Pronto Hex that will solve the problem.

Repeat frames and dittos

DecodeIR v2.37 and later versions have a look-ahead facility that is not present in earlier ones. This distinguishes between two styles of data passed to them by the calling application. The remote control programming applications IR.exe and RMIR pass signals learned by a UEI remote that has itself performed a partial analysis of the signal. The data is passed in a structured form, divided into Once, Repeat and Extra sections. The data in each of these sections can be viewed in IR.exe if the "Force Learned Timings" option on the Advanced menu is selected. Because of this analysis, DecodeIR does not see the original signal in full and cannot determine such things as the number of repeats of the signal that were sent. Other applications such as the IRScope software for the IR Widget send the entire signal as unstructured data, which enables IR.exe to identify the number of repeats.

The look-ahead facility checks successive frames within a single signal to see if they are repeats – either identical repeats or, in certain protocols, frames of a repeat sequence that have a distinctive marker in either the start or end frame, or both, of the sequence. If a protocol has distinctive start or end frame markers and either or both of the start and end frames are missing, this is reported in the Misc field of the decode (but at present this may not be implemented for all protocols with such markers). If the data has been passed in an unstructured form then the number of repeats in the signal will also be reported in the Misc field in a form like "4 frames", or in version 2.39 and later, "+ 3 copies".

In the case of unstructured data, DecodeIR v2.38 extends the look-ahead to protocols in which repeat action is signalled not by a full repeat of the frame but by a much shorter frame that does not carry the signal data (or occasionally carries just part of this data). These frames serve as "ditto marks". If present then the number of such frames is reported in the Misc field in a form like "3 dittos", or in version 2.39 and later, "+ 3 dittos". If there are no repeat frames or ditto marks, then to avoid ambiguity this is reported as "no repeat".

Mini Combos

Some UEI protocol executors are "mini-combos". This means they support more than one device number within one setup code using single-byte hex commands. There will be more than one possible EFC number for each OBC number. DecodeIr can't determine the correct EFC number by looking at the IR signal, because it isn't a characteristic of the signal. It is a characteristic of the fixed data used in creation of the setup code.

DecodeIr will list two or three different EFC numbers for each OBC number. The sequence of those two or three EFC numbers is consistent across all the decodes. So once you find out which position in that list is correct for one OBC of a given device number and setup code, that position will be correct for the EFC list of any other OBC of the same device and setup code (except that for RC-5 the decision of whether or not the OBC number is above 63 is treated as being part of the device number).

Brief and incomplete guide to reading IRP

General

{carrier frequency, time unit, sequencing rule} Mitsubishi:{32.6k,300}<1,-3|1,-7>(D:8,F:8,1,-80)+

Carrier Frequency

Hz; e.g. 38.3k; default is 0k--no modulation

Time Unit

Integer that can represent durations. Suffix u (default) is microseconds, p denotes number of pulses of the carrier.

Sequencing Rule

lsb|msb; lsb (default) means the least significant bit of a binary form is sent first.

BitSpec

Rule for the translating bit sequences to duration sequences. <ZeroPulseSeq|OnePulseSeq|TwoPulseSeq....>. Most IR protocols use only <ZeroPulseSeq|OnePulseSeq>, and the sequence is simply OnDuration,OffDuration. Example: NEC uses <1,-1|1,-3>

Bitfield

D:NumberOfBits:StartingBit. E.g. if D=71= 01000111, D:2:5 means x10xxxxx. D:2:5 = 10b = 2. ~ is the bitwise complement operator. ~D =10111000. Specifying the StartingBit is optional. D:6 is equivalent to D:6:0.

IRStream

The sequence of data. Enclosed in parentheses, items separated by commas. A trailing + means send one or more times. A trailing 3 means send 3 times; 3+ means at least 3 times. A trailing * means send zero or more times. NEC2: {38.4k,564}<1,-1|1,-3>(16,-8,D:8,S:8,F:8,~F:8,1,-78)+

Durations

no suffix means duration is expressed in Time Units, as defined above. m is milliseconds, u microsec, p pulses. No prefix means a flash, a preceding - (minus) means a gap.

Extent

A gap which trails a signal. The trailing gap is adjusted to make the total length of signal plus trailing gap equal to the extent. Notation is like a gap duration, except ^ replaces the minus sign. RC-5:(1:1,~F:1:6,T:1,D:5,F:6,^114m)+

Expressions

names, numbers and bitfields connected by standard symbols for arithmetic and logical operations. Enclosed in parentheses. Panasonic: {37k,432}<1,-1|1,-3>(8,-4,2:8,32:8,D:8,S:8,F:8,(D^S^F):8,1,-173)+

Permitted operators in decreasing order of precedence

unary – (negation)
∗∗ (exponentiation)
∗ /, % (multiplication, integer division, modulo) (* is also used in IRStreams)
+, – (addition, subtraction (+ is also used in IRStreams)
& (bitwise AND)
^ (exclusive OR) (also used in extents)
| (OR)
~ (complement) is permitted in Bitfields

Definitions

Expressions separated by commas, enclosed in curly brackets.

GI Cable: :{38.7k,490}<1,-4.5|1,-9>(18,-9,F:8,D:4,C:4,1,-84,(18,-4.5,1,-178)*) {C = -(D + F:4 + F:4:4)}

Assignments

For example T=T+1, which can be used to describe the RC-5 toggle bit.

Variations

Up to 3 expressions enclosed in square brackets. The first variation is sent on the first transmission, second for middle transmissons, and the third for the final transmission. E.g. the Zaptor toggle bit is zero until the last frame: [T=0] [T=0] [T=1]

DecodeIR (Readme)

Contents