JP1 Remotes

mr_d_p_gumby wrote:I've posted XMP(JP1)RM.zip, which partially implements the XMP protocols as Rob had requested here. It uses 3FG's XMPsumCheck translator, and provides:
XMP (JP1)
XMP (Slingbox)
XMP (UEI)

alanrichey wrote:Any chance we can have an edit to the EXE version of Remotemaster ? Just adding the XMP(Slingbox) to Protocols.ini causes the program to crash and refuse to shut down when you select it.

mr_d_p_gumby wrote:I've posted XMP(JP1)RM.zip, which partially implements the XMP protocols as Rob had requested here. It uses 3FG's XMPsumCheck translator, and provides:
XMP (JP1)
XMP (Slingbox)
XMP (UEI)

DefaultCmd=00 00

DefaultCmd=00

The Robman wrote:I've been meaning to write something up for the XMP protocol to get decodeIR and RM in sync. I've just gotta say that I really hate this protocol, it's one of the most time consuming protocols to try and decode by hand. Plus, UEI learning remotes have a problem getting the learns just right and sometimes the burst pair that is saved is exactly half way between two valid pairs, so you don't know which to chose. They also manage to completely drop some of the pairs.

Furthermore, the Slingbox chips have a problem with it too. If it's not already in the Slingbox, it's too big to load as an upgrade. If it is in the Slingbox, the timings don't work properly, so I always have to create special protocols that adjust the timings. I think the Slingbox processor is faster than those in remote controls, therefore the timings need to be reduced, but this is just a guess.

This executor uses two variable bytes, but none of the devices that use it really need two variable bytes. They all either use var-byte1 or var-byte2 as the OBC byte, and the other byte is always zeroes. So, I think we should refer to this executor as XMP-1 and XMP-2, where XMP-1 uses the first variable byte and XMP-2 uses the second. (Of course, DecodeIR won't know which to pick when OBC zero is used).

There's a toggle in the signal and a couple of checksums.

Let's take a sample of the signal:

**part1* - **part2* - description
170F443E - 1A003200 - sent once
170F443E - 12803200 - repeating signal

The first 4 bytes are the fixed data that is fed into the executor. The 2nd nibble of each 4-byte set is a SUM of all the other seven nibbles in the set.

The toggle is the rightmost bit of the 3rd nibble of the 2nd part of the signal (ie, 0 changes to 8 in this example, which in turn causes the checksum to change from A to 2).

Nibbles 4-6 of part1 are always "F44", at least in every example that I've seen, so the only fixed data that varies is the 1st nibble, 3rd nibble and the 4th byte.

Part1:
The 1st nibble is variable (but it's usually 1).
The 2nd nibble is the checksum.
The 3rd nibble is variable (but it's usually 0).
The 4th nibble is always "F"
The 3rd byte is always "44"
The 4th byte is the main device code.

Part2:
The 1st nibble is a repeat of the 1st nibble from part1.
The 2nd nibble is the checksum.
The 3rd nibble is the toggle.
The 4th nibble is a repeat of the 3rd nibble from part1.

XMP-1
The 3rd byte is the OBC.
The 4th byte is zeroes.

XMP-2
The 3rd byte is zeroes.
The 4th byte is the OBC.

We could assign "device code 1" to the 4th fixed byte. We could combine the 1st and 3rd nibbles as "device code 2". The 4th nibble and 3rd byte could be OEM codes, that way we can change them if needed.

As very few remotes have the $016C executor built in, I would recommend that we provide a reduced version that uses 1 variable byte if it's requested for a remote that doesn't have it.

For remotes that do have it (like the 15-135), if the user selects XMP-1, the OBC data should get dropped into the 1st variable byte, and if the user selects XMP-2, it should get dropped into the 2nd variable byte.

For DecodeIR, as long as the middle portion of the fixed data is "F44", it could provide the data as described above. If the data is different, it could append the new data to the protocol name. For example, if the fixed data was "170D433E", it could display the protocol as XMP-170D433E-1 or XMP-170D433E-2 (depending on whether the 1st or 2nd OBC byte was used).

Given how hard it can be to differentiate between some pairs, expecially the $E and $F pairs, I think it would be a good idea for DecodeIR to use the checksum nibble as a way of validating the data. If the OBC byte is half way between 0E and 0F, for example, check which value would generate the value found in the checksum nibble and go with that one. Be aware, of course, that the checksum pair could also be between two values, so you would need to decide which pair you have the greater confidence in.

Here's how you can calculate the checksum:

1) convert each nibble (except for the checksum nibble) to decimal
2) ADD all the decimal values
3) subtract the result from 256
4) MOD it with 16 (ie, divide by 16 and keep the remainder)
5) convert the result back to 1 nibble of hex.

For anyone else who's interested, here are the 16 pairs used by this protocol:

0 = +210 -750
1 = +210 -890
2 = +210 -1030
3 = +210 -1170
4 = +210 -1310
5 = +210 -1450
6 = +210 -1590
7 = +210 -1730
8 = +210 -1870
9 = +210 -2010
A = +210 -2150
B = +210 -2290
C = +210 -2430
D = +210 -2570
E = +210 -2710
F = +210 -2850

So where is the subdevice?
What is the significance of nibble2 of part 2?