PID $016C: XMP Protocol

[3FG]

Here's an attempt at an an addition to Protocols.ini and RemoteMaster.jar which provides support for the XMP protocol. The addition to Protocols.ini requires a new class file in RM.jar to generate the XMP arithmetic checksum.

The approach is to adopt the same device.subdevice nomenclature that DecodeIR uses, and to allow the user to change OEM Parm1/2 from the default 15 and 68. The user has to decide whether to use XMP-1 or XMP-2, although it appears to me that XMP-1 is far more common. [I'm not sure I have the labels 1 and 2 correct or reversed.]

As an aside, DecodeIR seems to assume that signals are XMP-1; XMP-2 decode with reported OBC values > 256. So if the OBC of the original signal is 13, and the protocol is XMP-1, DecodeIR reports 13 ($0D). If the signal is XMP-2, DecodeIR reports the OBC as 3328 ($0D00).

A user of RM can in most cases determine if an upgrade should be XMP-1 or 2 by examining learns from the original remote, or by plugging a known 5 digit EFC into RM.

BTW, in checking this, I found three setup codes in the Lookup Tool which have 0 in the checksum nibble although the actual checksum is non-zero-- as Rob had said.

[vickyg2003]

As an aside, DecodeIR seems to assume that signals are XMP-1; XMP-2 decode with reported OBC values > 256. So if the OBC of the original signal is 13, and the protocol is XMP-1, DecodeIR reports 13 ($0D). If the signal is XMP-2, DecodeIR reports the OBC as 3328 ($0D00).

A user of RM can in most cases determine if an upgrade should be XMP-1 or 2 by examining learns from the original remote, or by plugging a known 5 digit EFC into RM.

Yes, that's what you, 3FG, were helping me with the other day. When I got the huge OBC's it became apparent that I needed to enter my numbers into the "subdevice" column to get the kind of information I needed. It was the actual subdevice that was a killer. I never ever would have figured that one out. A nibble here a nibble there, sheesh!

BTW, in checking this, I found three setup codes in the Lookup Tool which have 0 in the checksum nibble although the actual checksum is non-zero-- as Rob had said.

I assume since we've been talking about precalculating the checksum to keep the executor small, you'll be wanting those checksum nibbles computed in the device lookup tool. I guess I will have to figure out what you guys are talking about there after all. Please hit me over the head when this device lookup tool should have the XMP data changed to reflect the new data entry required for KM and RM.

[binky123]

BTW, can you give me any idea of how small the executor needs to be for the Slingboxes? Do you have any hunches on how the timing differs?

I believe a single slingbox upgrade(includes executor + data) can be up to 252(255-3byte header) bytes.

A user in this thread reported the default timing values worked.

This thread found a Pause value of 003E worked for that slingbox. Johnsfine thought the XMP executor on the slingbox was running about 2.5% slower than on the dreambox remote.

I've seen these values in remotes:
S3C80 PB BurstOn=006A 212uS, BurstOff=0167 758uS Pause=003F
HCS08 DM600 BurstOn=0068 208uS, BurstOff=017B 758uS Pause=0043
HCS08 BurstOn=005F 190uS, BurstOff=0182 772uS Pause=0044

[mathdon]

It's not really about the topic of this thread, but since 3FG has started the ball rolling in uploading an RM add-on that provides a new translator, here is my Grundig16 add-on. I've taken the liberty of copying 3FG's ReadMe file with appropriate changes.

I have included the Java source code for the GrundigXlator class file. It would be nice if 3FG could add the source code for his XMP one to his XMP package.
_________________
Graham

[mathdon]

I've read Rob's info on why UEI remotes can't learn XMP signals properly. The same should not apply to the Widget. Has anyone tried getting XMP codes by using the Widget and IRScope, and if so, are there any problems with that? My brief experiment with the set-up codes in the URC-7781 that use XMP protocol don't show up any problems, but equally they don't show any OBCs > 255.

Should I be thinking of making DecodeIR report XMP-1 and XMP-2 separately? At the moment I seem to get XMP and XMP-R, both from the same signal.
______________
Graham

[The Robman]

Should I be thinking of making DecodeIR report XMP-1 and XMP-2 separately?

That would be my preference. The only case where you won't be able to tell the difference is where the OBC is zero, in which case just report it as XMP. Likewise, if we ever see a signal where both of the last two bytes are non-zero, this should also just be reported as XMP.

At the moment I seem to get XMP and XMP-R, both from the same signal.

What is XMP-R?

[3FG]

I'll post the source code tonight. I based XMPsumCheck on XorCheck.java, and in order to read the code easily, I found it useful to strip out the comments. I have to put them back in so that it matches the coding format used in the RM project.

I don't know how to use learns into a remote in conjunction with IR.exe to determine if a signal has the OBC in the first (msb side) variable byte or in the second. My understanding of Rob's comments is that we're defining XMP-1 as OBC in the first variable byte. I've assumed that C1982 is XMP-1, but the output of DecodeIR gives OBC < 256 for C1982, while protocols which I've assumed are XMP-2 give OBCs > 255. So I'm not sure if my assumption is correct.

Rob, I have been assuming XMP-R is the repeating part of XMP.

[johnsfine]

I have been assuming XMP-R is the repeating part of XMP.

Since XMP is so rarely learned correctly, I made the decision to report the two different frames as "XMP" and "XMP-R" so if either is learned correctly you have a usable decode (either frame alone contains all the required information for a full decode).

In other protocols with two different frames, the decoder generally looks for the complete correct signal including both frames.

So if XMP had been learned well more often, I probably would have reported "XMP" for the whole signal including both frames and "XMP{1}" or "XMP{2}" for a partial signal that decodes to complete information.

[The Robman]

I don't see any need to differentiate between the two different frames because, apart from the checksum nibbles, the only difference is a toggle bit. Plus, judging from the JVC vs. JVC2 experience, I think it will only serve to confuse people.

Given the 10 pair limitation in UEI learning remotes, it's very likely that the 2nd frame will not be complete. The spurious decodes that sometimes come from these incomplete frames also add to the confusion, so I'd like to see those eliminated if possible.

I realize this may be too complicated to be practical, but if it can be done, I'd like to see DecodeIR keep track of how many unique burst pairs have been used so far and once ten unique pairs have been found, it should treat the rest of the stream with suspicion. If the first pair is complete, it can use the data to calculate what the second pair should look like and it should be able to predict which "new" pairs will be dropped.

Taking things a stage further, once both frames have been read, it would be nice if DecodeIR were to compare the data between the two frames and use the checksum nibbles to verify that all the high-order nibbles have been decoded correctly. This is the process that I follow manually when I'm decoding XMP signals by hand. The closer a nibble gets to "F" the less reliable it is (and conversely, the closer it is to "0" the more reliable it is), so if a checksum appears to be "E" but I calculate it to be "D", I'll assume that I'm right and I'll go with "D". But, if the checksum appears to be "2" and I calculate it to be something else, I'll look at the OBC byte. If one of the nibbles is a "D", I'll try changing it to a "C" or an "E" to see if that generates the correct checksum, and if it does, I'll change the OBC.

[mr_d_p_gumby]

Should I be thinking of making DecodeIR report XMP-1 and XMP-2 separately?

That would be my preference.

Not to complicate the XMP terminology any further, but UEI has a blurb on their site that indicates they have XMP, XMP-2, XMP-4 and XMP-32 variations. The AccessHD site also claims their remote uses the "XMP-1" protocol.

I know the one we are discussing here is the just-plain-XMP variety, but do you think using the XMP-1 and XMP-2 names will cause any confusion? Should we come up with some other names?

[The Robman]

Should I be thinking of making DecodeIR report XMP-1 and XMP-2 separately?

That would be my preference.

Not to complicate the XMP terminology any further, but UEI has a blurb on their site that indicates they have XMP, XMP-2, XMP-4 and XMP-32 variations. The AccessHD site also claims their remote uses the "XMP-1" protocol.

I know the one we are discussing here is the just-plain-XMP variety, but do you think using the XMP-1 and XMP-2 names will cause any confusion? Should we come up with some other names?

Yes, let's not re-use their names. Any suggestions for the new names.

Also, do we know what the differences are between the XMP variations?

[The Robman]

Here's how UEI described the 4 versions of XMP on their web site:

• XMP This unidirectional protocol applies to wireless keyboards and remote controls, and supports multiple pointing devices.
• XMP-2 This bi-directional infrared protocol can be used for signal detection and correction in a wireless keyboard environment.
• XMP-4 Designed for interactive gaming applications, up to four players can play the same game, each with their own wireless controller.
• XMP-32 Designed for large scale multi-user applications, up to 32 users can interact with the same device or application.

And here's an "IrTek" page on XMP as it's used by Comcast:
http://irtek.wikidot.com/remote-comcast-xmp

[3FG]

I uploaded a new zip file of the XMP add-in which includes the source code XMPsumCheck.java.

I think we could rename our XMP-1 and XMP-2 to XMPsmall1 and XMPsmall2, while retaining XMP for "just-plain-XMP". From my point of view all three protocols produce the same form of IR signal, with 2 bytes of variable data. The point of the non-plain versions is primarily the reduction in the size of the data to be input to the executor, and perhaps in the executor itself.

[The Robman]

The main point of the two new versions of XMP is to reduce the variable bytes to 1 as that will cut the size of the device upgrade almost in half.

[mathdon]

I have modified DecodeIR for the XMP protocol to enable it to extract data from corrupted signals. It now detects all the signals in Rob's six sample files as XMP and provides decodes for all of them. For the four files where Rob's spreadsheet gives the "correct answers", the decodes all agree with those answers. Here is its decode of the file 2.ir



The Misc column shows which of four algorithms have been used to reconstruct the signal and extract the data. More than one may be used for a single signal. They are, in the order in which they are applied, which is also the order of decreasing confidence in the result,

* 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, eg those for hex digits C and D, have been coalesced in the learning process, so somewhere a C appears 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 an OBC are the wrong way round. In certain circumstances this algorithm also identifies a missing zero OBC, i.e. two consecutive missing zero bursts. In that case the two OBCs may be the wrong way round.

I think it unlikely that hand decoding of XMP signals could do better than this. I need to do some more checking and tidying of the program but will post a DecodeIR 2.40 Beta with this in shortly.
__________________
Graham