JP1 Remotes

3FG wrote:

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

The subdevice is the combination of the 1st and 3rd nibbles of the first part ($10 in the above example = 16 decimal)

Rob wrote:
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.

Okay that makes sense. Those are USUALLY so we create them.

Nibble 2 in both parts is the checksum of the other 7 nibbles.

You've quoted Rob's post where he lists a 5 step algo to calculate the checksum near the end.

I couldn't get that to work, (I was trying that hex to dec calculator) and I'm so afraid of hex, but looking at how simple those numbers are

170F443E - 1A003200 - sent once
170F443E - 12803200 - repeating signal

1+0+0+3+2+0+0 = 6
256-6 = 250
Mod(250,16) = 10
10 = Ah

1+8+0+3+2+0+0 = 14
256-14 = 242
Mod(242,16) = 2
2 = 2h

Thanks for clarifying

3FG wrote:Use Mike's XMP add-in . Follow the instructions in ReadMe.txt.
You need to modify protocols.ini and change the contents of RemoteMaster.jar

More instructions are here:
http://www.hifi-remote.com/forums/viewtopic.php?t=11828

Vicky, see the XMP entry in the version of DecodeIR.html that was with v2.40 of DecodeIR.DLL for an explanation of (Rec) and (Cor). They refer to the correction algorithms that DecodeIR applied in order to get a meaningful decode, and the notes there explain how reliable, or otherwise, the decode is.
________________
Graham

Thanks Graham. I thought I checked that, but apparently I had two DecodeIR.HTml's on my machine. The other one didn't have the IRP for the xmp there, so it must have been very old.

Is this one of the places where Gary's suggestion of using the decode rules would have given me better UEI learns? Or why did using Exported learns that decoded IRScope as XMP2 turn up as learns as XMP2(Cor) when the were exported? Is this a UEI limitation?

As you can see, I'm very confused here. This is all too mathy for me. I have more of an etch-a-sketch aproach to signals.

Edit:

I went back to really read the DecodeIR Html and I got a little confused
about what you meant with the timing detail. I understand that there are 15 values here, I know that they change by about 135 units for each number, but the syntax is over my head. I know you are showing me the values for 0, 1,2,3,4,5,6,,8,9,a,b,c,d,e,f but I can't figure out how to read this.

}<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>


As a non-math person, I liked the way the Nokia protocol showed the timings for 0, 1, 2, 3.
}<164,-276|164,-445|164,-614|164,-783>(


Edit Again:
Oh I remember John commenting on how difficult it was to tell an E from an F. Now I can see with 16 different values in time increments of 135, if the processor time was off by 10%, by the time you got to A you'd be having severe troubles decoding based on timing pairs. I don't know what the usual tolerance is for remote signals, but I do know that I've helped people who were "using" other types of signals that were 10% out of whack and their equipment was still responding. I wonder how much tolerance XMP equipment has. I'm more than a little amazed at how complicated this must have been to decode, by hand and manually. Yuck! That first Dreambox must have been a NIGHTMARE!

XMP is very time consuming to decode by hand. What I used to do is put all the results into a spreadsheet, then enter a formula that will calculate the checksum so I could compare it to the checksum found in the data. If the callculated checksum didn't match the found checksum, I'd look for high value nibbles (eg, D,E,F) and try bumping them up or down by 1 to see if that made the checksums match. So I imagine that the receiver does something similar because it does seem that XMP receivers are very forgiving.

And just converting the data to hex was always tricky because many of the pairs would be smack in the middle of two valid pairs, so it's a 50/50 guess as to which pair it's supposed to be.

{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>

What this is saying is that "+210 -760" is the base pair and -136 is extra amount added to each value. For example...

0 = +210 -760
1 = +210 -760 (plus -136) = +210 -896
2 = +210 -760 (plus two times -136) = +210 -1032
etc

It could have been written as ...
<+210 -760|+210 -896|+210 -1032|etc>

Thanks Rob, I still had to look at this and look at this to parse the IRP,

{38k,136,msb}<210,-760>(<0:1|0:1,-1|0:1,-2|0:1,-3|0:1,-4|0:1,-5 ....
So the | reads as or
the 0:1 reads as 210, -760
and then the - number reads -number *136.

Way, way too mathy. I couldn't figure that out even knowing what the signal looked like.

Just remember that the XMP protocol is advanced math compared to normal IR signals, so even if you never completely get it, I wouldn't feel too bad.

Though, having said that, if you DO get it and want to try your hand at something else, take a look at the Lutron signal where they use 4 bits to represent 3.

I loaded up a Lutron protocol to have a look. Who would have thought a wave form with so few bumps had so much data! I guess I'm not going to have to get a sudoku book any time soon.

The Lutron
IRP notation: {40k,2300,msb}<-1|1>(255:8,X:24,0:4)+
EFC translation: MSB of decoded signal.
This is an unusual protocol in that an 8-bit device code and 8-bit OBC are encoded in a 24-bit error-correcting code as the X of the IRP notation. This is constructed as follows. First two parity bits are appended to the 16 data bits to give even parity for the two sets of 9 bits taken alternately. The resulting 18-bit sequence is then treated as 6 octal digits (0-7) expressed in 3-bit binary code. These are then re-coded in the 3-bit Gray code (also called, more descriptively, the reflected-binary code) with a parity bit to give odd parity, so giving 6 4-bit groups treated as a single 24-bit sequence. The whole thing allows any single-bit error in transmission to be identified and corrected.

Just to let everyone know that I have now produced four different remotes using the XMP(Slingbox) protocol for Slingbox users with unsupported devices and they have all worked flawlessly.

So many thanks to everyone involved, you have made at least 4 people happy

The Robman wrote:{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>

What this is saying is that "+210 -760" is the base pair and -136 is extra amount added to each value. For example...

0 = +210 -760
1 = +210 -760 (plus -136) = +210 -896
2 = +210 -760 (plus two times -136) = +210 -1032
etc

To add a little more explanation, the lists enclosed in < > give the encoding of digits 0,1,2,... with the encodings of successive digits separated by |. In <210,-760> there is no | so it gives the encoding of only one digit, 0. In the long list in the next set of < >, 0:1 means encode a 0 as one bit in the previous encoding, ie as 210,-760. (0:2 would mean encode 00, ie 210,-760,210,-760.) The -1, -2, etc with no colon mean gaps (the minus sign) of 1,2... of the base unit given in the initial { }, ie of 136. So for example a nibble value 2 (nibbles as there are 16 encodings in the second < >) is 210,-760 from the 0:1 followed by a gap of 2 units of 136, giving an encoding of 210,-760,-272. The two successive gaps can't be distinguished so you add the timings to give 210,-1032 as Rob showed.

The Robman wrote:It could have been written as ...
<+210 -760|+210 -896|+210 -1032|etc>

Why do I prefer the new form to this? I think Vicky answered that question herself:

vickyg2003 wrote:I understand that there are 15 values here, I know that they change by about 135 units for each number

You have to do a lot of arithmetic on the gap values -760, -896, -1032 ... to see that they increase by 136 each time. That figure of 136 does not occur anywhere in the notation. My version of the IRP for XMP (which is in bog-standard John Fine IRP, not some new addition of mine) shows at a glance that the successive gap values increase by the base unit of 136 each time.

I hope this helps - but realise it may just have added to the confusion!
_______________
Graham

Why do I prefer the new form to this? I think Vicky answered that question herself:

Would that be because you are the mathdon? I've been playing with IRScope and seeing that I can clean up the signals in my ICT before transferring Exporting them to use as UEI Learns. All in all this has been a good learning experience for me.

Here is a version of RM (v1.98 Beta 7) with the XMP protocol already added:
http://www.hifi-remote.com/forums/dload ... le_id=8438

As the XMP protocol wasn't added to RM 1.98, I have updated the patched RM/XMP file above to use RM version 1.98.

Rob: I am running the release version of V1.98 and I have the XMP Protocol showing. Is that because I am using a PROTOCOLS.INI that has it included ? Or do you need to make any changes to the actual program itself ?

Does it work? It's not enough to add all the XMP variations to protocols.ini, you also need to add the class files to the jar file.