JP1 Remotes

3FG · Expert Joined: 19 May 2009 Posts: 3367

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 · Posted: Mon Jan 04, 2010 7:16 am Post subject:

binky123 · Expert Joined: 14 Feb 2004 Posts: 1292

mathdon · Posted: Mon Jan 04, 2010 11:15 am Post subject:

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 · Posted: Mon Jan 04, 2010 11:58 am Post subject:

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 · Posted: Mon Jan 04, 2010 12:40 pm Post subject:

3FG · Expert Joined: 19 May 2009 Posts: 3367

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 · Posted: Mon Jan 04, 2010 1:38 pm Post subject:

The Robman · Posted: Mon Jan 04, 2010 3:06 pm Post subject:

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.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!

mr_d_p_gumby · Posted: Mon Jan 04, 2010 4:09 pm Post subject:

The Robman · Posted: Mon Jan 04, 2010 6:37 pm Post subject:

The Robman · Posted: Mon Jan 04, 2010 10:55 pm Post subject:

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

3FG · Expert Joined: 19 May 2009 Posts: 3367

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 · Posted: Tue Jan 05, 2010 8:25 am Post subject:

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.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!

mathdon · Posted: Fri Jan 08, 2010 12:13 pm Post subject:

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