XMP

XMP

XMP, XMP-1 and XMP-2

UEI protocol: 016C
IRP notation (without final frame): {38k,136,msb}<210,-760
             (<0:1|0:1,-1|0:1,-2|0:1,-3|0:1,-4|0:1,-5|0:1,-6|0:1,-7|0:1,-8|0:1,-9|0:1,-10|0:1,-11|0:1,-12|0:1,-13|0:1,-14|0:1,-15> \
             (T=0,(S:4:4,C1:4,S:4,15:4,OEM:8,D:8,210u,-13.8m,S:4:4,C2:4,T:4,S:4,F:16,210u,-80.4m,T=8)+)) \
             {C1=-(15+S+S::4+15+OEM+OEM::4+D+D::4),C2=-(15+S+S:4+T+F+F::4+F::8+F::12)} \
IRP notation (with final frame):{38k,136,msb}<210,-760
             (<0:1|0:1,-1|0:1,-2|0:1,-3|0:1,-4|0:1,-5|0:1,-6|0:1,-7|0:1,-8|0:1,-9|0:1,-10|0:1,-11|0:1,-12|0:1,-13|0:1,-14|0:1,-15> \
             (T=0,((S:4:4,C1:4,S:4,15:4,OEM:8,D:8,210u,-13.8m,S:4:4,C2:4,T:4,S:4,F:16,210u,[-80.4m][-80.4m][-13.8m],T=8)+,T=9)2)) \
             {C1=-(S+S::4+15+OEM+OEM::4+D+D::4),C2=-(S+S:4+T+F+F::4+F::8+F::12)}

XMP uses one burst pair to encode numbers 0 to 15, with an on duration of 210uS, and off duration of 760uS + n*136uS where n takes on values of 0 to 15. The checksum nibble is the complement of 15 plus the sum of the other 7 nibbles, mod 16

The Device code is D, the SubDevice code is S and there are two OBC values. OBC1 is the high byte of F, OBC2 is the low byte of F. The OEM code is normally 0x44 and is reported in the Misc field only if it has a different value. The XMP-1 protocol is XMP with OBC2 = 0. The OBC field in DecodeIR then shows OBC1. The XMP-2 protocol is XMP with OBC1 = 0. The OBC field in DecodeIR then shows OBC2.

This protocol has a 4-bit toggle T that is 0 for the first frame and normally 8 for all repeat frames. There is, however, a variant in which a further frame with T=9 is sent after the button is released, separated from the preceding frame by the short leadout of 13.8m that is used between two half-frames rather than the long lead-out of 80.4m used at the end of all other frames. When this frame is detected then the Misc field displays "With Final Frame". For this to be shown in a learned signal, the button must be released before the learning process times out, so a short button press is needed.

These are problem decodes because JP1 remotes don't typically learn these signals accurately enough for a correct decode. NG Prontos also do a rotten job of learning these signals. Older Prontos seem to do fairly well. DecodeIR v2.40 includes algorithms that attempt to reconstruct a valid XMP signal from a corrupt learn, but it is impossible to correct all learning errors and there can be no certainty that a reconstruction is actually correct.

In a correctly learned or fully reconstructed signal there will be an "XMP", "XMP-1" or "XMP-2" decode with device, subdevice and OBC values that can be used with RemoteMaster or any similar program to regenerate a clean signal. The Misc field shows which algorithms, if any, have been applied, as a list in brackets after any decode data in this field. There are notes below on the reliability of the various algorithms. When the protocol shows as (unqualified) XMP, both OBC values are non-zero. The OBC and Hex fields show OBC1. The corresponding values for OBC2 are shown in the Misc field.

The learned signal itself will certainly not be valid if any reconstruction algorithms have been applied and it may not be so even if it has been decoded without reconstruction. The possible algorithm indicators in the Misc field are as follows:

• End (= Endpoint): The lead-out burst is missing and has been inserted. This is almost certainly correct.
• Rec (= Recovery): Look-ahead has been used to recover a missing burst from the following repeat frame. This is very likely to be correct.
• Cor (= Correction): Two bursts have been coalesced in the learning process, e.g. those for hex digits C and D, causing a C to appear as D or vice versa. The error has been identified and corrected. This is probably correct.
• Cal (= Calculated): A missing digit has been calculated from a checksum. The digit is probably correct but it may be in the wrong place. The most likely error in the reconstruction is that the two digits of the OBC are the wrong way round.
• Cal2 (= Calculated 2) Two consecutive missing zero digits have been identified, corresponding to a zero OBC. When this happens, the signal will always be shown as XMP-1. The most likely error in the reconstruction is that it should actually be XMP-2.

If a learned signal is good enough to be recognised as XMP but not good enough to be fully reconstructed, the protocol will display with a name of the form

XMP:136.218-0F0F441A0A800F00

In IR.exe you'll need to widen the Protocol column to see the whole thing. This represents intermediate data from an unsuccessful attempt to decode a XMP signal. The number in the position where the 136 is in this example represents the time scale. A number (like this example) that is near 137 is reasonable. A number much further from 137 indicates a more serious learning or decoding problem. The number in the position where the .218 is in this example (it is not part of the 136) represents the level of inconsistency in the individual hex digit decodes. A value greater than .100 means the hex digits aren't very reliable.

The hex string, where the 0F0F441A0A800F00 is, is the decoded data. At least one digit is almost certainly wrong or the whole decode wouldn't be displayed in this form. With a JP1 learning remote, the most common errors are that a digit is actually missing, in which case the string will have fewer than 16 hex digits, or that two or more digits which are decoded the same are actually different, so some of them are correct and some are one value higher or lower. Although the reconstruction algorithms attempt to correct these types of errors, it is not always possible. In this example I happen to know the correct signal. One of the three F's is really an E and one of the two A's is really a 9. The correct string is 0E0F441A09800F00.

Almost all examples we've seen start with "0E0F441A0" or "060F44120". But we've also seen upgrades from UEI for "0D1F441A0" and "0C2F441A0" and "0B3F441A0". The last 4 digits of the whole 16 digit string (if they are correct) represent the Hex command needed to reproduce the signal in a JP1 upgrade or KeyMove. DecodeIR shows them as two 8-bit OBC values, as described with the IRP notation above.