JP1 Remotes

Looking at the IODATA learns that K-park posted here:
https://www.hifi-remote.com/forums/dload ... le_id=6952

from this thread:
https://www.hifi-remote.com/forums/viewtopic.php?t=11177

I'm following along on this post as a Protocol practice problem. I took a look at the signals, and they seem pretty straight forward.

There is a Leadin Pair, followed by 40 bits of data. The first 28 bits are static, they don't change, so they must be the device/subdevice bits, and the last 12 bits would be the command. I assume you'd want to call this 3-8bit devices, and 2-8bit commands throwing thowing the last 4 static bits into the command. All seems to be pretty straight forward in protocol builder. You build the Protocol, copy it into the Notes section of KM, change the KM settings to MANUAL, change it to MSB, provide the decimal equivalents to the first 24 bits of data (8,8,8) for the three devices.

And then I got stuck. What do you do after that? How do you get the 2 cmd functions in?

Here's how you do it. Vicky got most of this, I'm just giving the full info for anyone else that's interested.

First, identify a good time to round everything to. In this case, I determined that 550 is a good value so I entered that. Then click on the new Times Summary button and copy/paste the times over to notepad.

Then you have to identify the pairs, which in this case are "+550 -550" and "+550 -1650". Deciding which is ONE and which is ZERO is subjective, but typically the pair with the longer OFF time is ONE. So, the next step is to convert the times into binary by editing the pairs to be 1 or 0.

So, so far you should have:

+9100 -4500 0000000100010111010010000000000001001100 +550 -40700 = Power
+9100 -4500 0000000100010111010010000000001011000110 +550 -35750 = CH+
+9100 -4500 0000000100010111010010000000101011001110 +550 -33550 = CH-
+9100 -4500 0000000100010111010010000000010101001001 +550 -35750 = Up
+9100 -4500 0000000100010111010010000000001101001111 +550 -33550 = Right
+9100 -4500 0000000100010111010010000000101101000111 +550 -33550 = Left
+9100 -4500 0000000100010111010010000000011001001010 +550 -35750 = Select
+9100 -4500 0000000100010111010010000000101001000110 +550 -35750 = Menu
+8800 -4500 0000000100010111010010000000100000000000 +550 -40700 = 1
+9100 -4500 0000000100010111010010000000010000001100 +550 -37950 = 2
+9100 -4500 0000000100010111010010000000110000000100 +550 -37950 = 3
+9100 -4500 0000000100010111010010000000001000001010 +550 -37950 = 4
+9100 -4500 0000000100010111010010000000101000000010 +550 -37950 = 5
+9100 -4500 0000000100010111010010000000011000001110 +550 -35750 = 6
+9100 -4500 0000000100010111010010000000111000000110 +550 -35750 = 7
+9100 -4500 0000000100010111010010000000000100001001 +550 -37950 = 8
+9100 -4500 0000000100010111010010000000100100000001 +550 -37950 = 9
+8800 -4500 0000000100010111010010000000010011000000 +550 -40700 = Enter
+9100 -4500 0000000100010111010010000000000000101010 +550 -37950 = Info
+9100 -4500 0000000100010111010010000000010100001101 +550 -35750 = 0
+9100 -4500 0000000100010111010010000000000100101011 +550 -35750 = Guide
+9100 -4500 0000000100010111010010000000110111001001 +550 -33550 = VOL+
+9100 -4500 0000000100010111010010000000110101000001 +550 -35750 = Down
+9100 -4500 0000000100010111010010000000001111000111 +550 -33550 = VOL-

Next step is to figure out the fixed data vs. variable data and to determine if the data is LSB or MSB. For the latter, it's usually a good idea to look at the binary data for the numeric buttons and that holds true in this case too. Looking at the numeric buttons you should be able to tell that the data is LSB because the data increments from the left and the OBCs for buttons 1 thru 9 and zero are 1 thru 10.

So where are we at so far? Based on what I've seen so far, I conclude that we have 28 bits of fixed data, followed by an 8 bit OBC and most likely a 4 bit checksum. The easiest way to format 28 bits is to treat it as 4 bytes of fixed data, with 7 bits per byte. At this point I should point out that Excel is a very useful tool for manipulating the data. When you copy the data from Notepad over to Excel, Excel should automatically format it into columns. Then you can use Data > "Text To Columns" to break the binary data out into 4 7-bit columns, an 8-bit column and a 4-bit column. So, now we have...

0000000 1000101 1101001 0000000 10000000 0000 = 1
0000000 1000101 1101001 0000000 01000000 1100 = 2
0000000 1000101 1101001 0000000 11000000 0100 = 3
0000000 1000101 1101001 0000000 00100000 1010 = 4
0000000 1000101 1101001 0000000 10100000 0010 = 5
0000000 1000101 1101001 0000000 01100000 1110 = 6
0000000 1000101 1101001 0000000 11100000 0110 = 7
0000000 1000101 1101001 0000000 00010000 1001 = 8
0000000 1000101 1101001 0000000 10010000 0001 = 9
0000000 1000101 1101001 0000000 01010000 1101 = 0
0000000 1000101 1101001 0000000 00000100 1100 = Power
0000000 1000101 1101001 0000000 10100100 0110 = Menu
0000000 1000101 1101001 0000000 01100100 1010 = Select
0000000 1000101 1101001 0000000 01010100 1001 = Up
0000000 1000101 1101001 0000000 11010100 0001 = Down
0000000 1000101 1101001 0000000 00110100 1111 = Right
0000000 1000101 1101001 0000000 10110100 0111 = Left
0000000 1000101 1101001 0000000 01001100 0000 = Enter
0000000 1000101 1101001 0000000 00101100 0110 = CH+
0000000 1000101 1101001 0000000 10101100 1110 = CH-
0000000 1000101 1101001 0000000 11011100 1001 = VOL+
0000000 1000101 1101001 0000000 00111100 0111 = VOL-
0000000 1000101 1101001 0000000 00000010 1010 = Info
0000000 1000101 1101001 0000000 00010010 1011 = Guide

The next step is to crack the formula for the checksum to see if it's worth building it into the executor. If you're unable to crack the code, you can skip adding logic to the executor and just use 2 bytes of variable data, where you have 1 byte of 8 bits and another of 4. In KM, you would use the byte2 column to enter the hex for the checksum byte.

However, in this case the assembler code needed to format the checksum will be quite small, so I think it's worth it to go that route.

To format the checksum, you need to XOR the left and right nibbles of the OBC byte together and then complement the leftmost bit. For example, let's look at the VOL+ binary (11011100):

1101 = vol+ (left nibble)
1100 = vol+ (right nibble)
------
0001 = XOR

0001 = result from above
1000 = flip the first bit
------
1001 = XOR

So, if we have 4 fixed bytes, those will be R03 thru R06 (in S3C8 assembler) and the variable byte will be R07. When you format the signal in PB, you'll want to say that you have 2 variable bytes where one is 8 bit and the other is 4 bit, then once you've generated the code, you'll want to edit the "4 dev, 2 cmd" data byte to be "4 dev, 1 cmd" instead.

Then, in the code you'll need:
(* in this case, it's not strictly necessary to increase R11 but in almost all other cases you would need to, so that's why I included it here).

Here's an upgrade, formatted for the URC-8910, that you can try...

Upgrade Code 0 = 6F D0 (Cable/2000) IODATA HVT-BT200 (KM v9.17)
FF 0A 76 FC 00 21 00 8A D2 00 DC 3C 3C 2C AC 04
02 54 D4 B4 34 64 A4 12 4C
End

Upgrade protocol 0 = 01 FF (S3C8+) IODATA HVT-BT200 (PB v4.01)
43 8C 41 8B 15 8B 45 07 08 01 13 03 25 01 13 00
FF 4E 20 11 C6 08 B6 FF FF 04 E4 07 08 F0 08 B4
07 08 B6 08 80 8D 01 46
End

Here's a KM file for it:
https://www.hifi-remote.com/forums/dload ... le_id=6955

And here's a zip file containing the KM file, the PB file and the spreadsheet that I used to decode the signal:
https://www.hifi-remote.com/forums/dload ... le_id=6954

WOW, I sure missed out on all the subtleties there. I could not see the pattern, but once I see it this makes perfect sense. All I could see was the 40 bytes, so I took a slege hammer approach. I divided it up into Dev,Dev,Dev, OBC, 2ndbyte and called it MSB because I couldn't see the counting which is evident in Robs.

I used Devices 1,23,72 to get my fixed data 1h,17h,48h set it up as a 2 comand after xx, 'xx' and then did the decimal of the 4th byte as the OBC and the HEX of the 5th byte as "the byte2 as required" to get my signals to come out. I had to do a bit of tweaking on the Lead-in times as they came out about 300us shorter than the times I put in on protocol builder.

dev1-----,dev2------,dev3-----, cmd1----, cmd2-----
00000001 00010111 01001000 00001000 00000000 = 1
00000001 00010111 01001000 00000100 00001100 = 2
00000001 00010111 01001000 00001100 00000100 = 3
00000001 00010111 01001000 00000010 00001010 = 4
00000001 00010111 01001000 00001010 00000010 = 5
00000001 00010111 01001000 00000110 00001110 = 6
00000001 00010111 01001000 00001110 00000110 = 7
00000001 00010111 01001000 00000001 00001001 = 8
00000001 00010111 01001000 00001001 00000001 = 9
00000001 00010111 01001000 00000101 00001101 = 0
00000001 00010111 01001000 00000000 01001100 = Power
00000001 00010111 01001000 00001010 01000110 = Menu
00000001 00010111 01001000 00000110 01001010 = Select
00000001 00010111 01001000 00000101 01001001 = Up
00000001 00010111 01001000 00001101 01000001 = Down
00000001 00010111 01001000 00000011 01001111 = Right
00000001 00010111 01001000 00001011 01000111 = Left
00000001 00010111 01001000 00000100 11000000 = Enter
00000001 00010111 01001000 00000010 11000110 = CH+
00000001 00010111 01001000 00001010 11001110 = CH-
00000001 00010111 01001000 00001101 11001001 = VOL+
00000001 00010111 01001000 00000011 11000111 = VOL-
00000001 00010111 01001000 00000000 00101010 = Info
00000001 00010111 01001000 00000001 00101011 = Guide

I used an extra byte for every key, which could add up, but are there any other shortcomings to this approach? Is this going to cause any problems with keymoves in any of those transitional remotes like the urc6131, where the keymoves were in that "inbetween" form?

vickyg2003 wrote:I used an extra byte for every key, which could add up, but are there any other shortcomings to this approach? Is this going to cause any problems with keymoves in any of those transitional remotes like the urc6131, where the keymoves were in that "inbetween" form?

Yes, the URC-6131 can only do true keymoves (ie, copying a key from the upgrade to another button) when the protocol uses 2-bytes, you can't enter keymoves for new functions. To do that you would need to create a "helper" upgrade.

Generally speaking, whenever you see more than 8 bits of variable data, it's a good idea to look for a checksum because, even if you don't intend to write any assembler to generate it automatically, you'll need to understand it if you want to try and generate any additional signals for discrete codes, etc.

If I wanted to create an upgrade for this without using assembler, I would still break the fixed data up using 7-bit bytes, then I would use 2 bytes of variable data with the protocol set to use one 8-bit byte and one 4-bit byte, because then the main variable byte would be the correct OBC in LSB format. The only difference would be that the checksum data would need to be specified.

Hey Vicky, would you be willing to test the protocol that I created to see if it generates the right signal. If there's anything wrong with it, would you like to try your hand at fixing it?

I tried to run your protocol, but apparently I've done something wrong. I am using a 6131 for the s383+ processor. I changed the protocol to 1FE so it wouldn't conflict with mine, and the "deocodes" don't show up the same. But the whole protocol looks screwy in IR. Nothing lines up the way it should.

{snip}

Actually the only one that came up with the same decode was the number 1 and on that one the checksum was off.

If there's anything wrong with it, would you like to try your hand at fixing it?

I'm not quite sure I follow the whole checksum thing, and definately not in s383+ language. I could probably do the HCS08 version though.

The use Assembly code box wasn't checked in Protocol builder.

Upgrade protocol 0 = 01 FF (S3C8+) IODATA HVT-BT200 (PB v4.01)
43 8C 41 8B 15 8B 45 07 08 01 13 03 25 01 13 00
FF 4E 20 11 C6 08 B6 FF FF 04 18 07 F0 C1 B4 07
C1 B6 C1 80 19 08 8D 01 46
End


Looks good if the protocol was loaded. I looked at a few keys and its pretty good.

{snip}

Upgrade protocol 0 = 01 FF (HCS08) IODATA HVT-BT200 (PB v4.01)
20 18 23 47 41 8B 45 07 08 01 13 03 39 01 13 01
13 4E 20 11 C6 08 CA FF FF 04 B6 64 62 B8 64 A8
80 B7 65 CC FF 5F
End
This is a translation and appears to work. I'm still going to have to sit down with a piece of paper and a pencil to figure out what you saw in the signal to get to this. That part of this is still voodoo, but when that part is done for me, the assembler translation is not a problem.

The Robman wrote:Vicky got most of this, I'm just giving the full info for anyone else that's interested.

Rob, you've got someone here who is VERY interested! I'm trying now to get into the nitty-gritty of protocols and worked examples are always a great source of help. This is a worked example par excellence. But it raises as many questions as it answers, though I suspect some of them may not have answers. Anyway, here goes.

As far as I can tell, regardless of how many bits are encoded in the protocol, it decodes into at most 3 items of data: device code, subdevice code and function (command) code. The OBC, Hex Code and EFC fields in DecodeIR are all various presentations of the function code. I can see no pattern such as comp relating your 4 7-bit fixed bytes but the first and last are zero, so is it reasonable to treat these zero bytes as really fixed and the other two as the device code and subdevice code? Could these instead be an 8-bit device code and 6-bit subdevice code? Is the distinction purely a JP1 matter or is there some absolute answer to which, if either, is right? Taking the 7-bit option I think the protocol in IRP notation would be:

IODATA HVT-BT200 {38k,550}<1,-1|1,-3>(16,-8,0:7,D:7,S:7,0:7,F:8,C:4,1,-60)+

where C is XOR of two nibbles of F with leftmost bit inverted.

Now to my experiment. With this interpretation I've added this into DecodeIR, successfully as far as I can tell. With apologies for the misalighment of the headings with the columns, the learned code data shows up as Which brings me to my next question. Is there any point in DecodeIR identifying protocols that do not correspond to any UEIC PID? But even more, how does one discover whether or not a new protocol such as this CAN be generated by any existing UEIC PID? There seem to be some very powerful UEIC protocol executors capable of generating a variety of distinct protocols or combinations of protocols and also a lot of UEIC PIDs to which JP1 has not ascribed a name, which I take it means that their purpose is unknown, so it doesn't seem to be a trivial task to determine whether one of them, with suitable fixed data, can generate some new protocol.

Wow! A lot of questions! Do any of them have answers?
_________________
Graham

mathdon wrote:regardless of how many bits are encoded in the protocol, it decodes into at most 3 items of data: device code, subdevice code and function (command) code.

I try to decode most data of most signals that way, but sometimes things don't fit and decodeir throws some significant data into the misc field or even into the protocol name.

Could these instead be an 8-bit device code and 6-bit subdevice code? Is the distinction purely a JP1 matter or is there some absolute answer to which, if either, is right?

Probably the designer of the original protocol had an absolute answer and probably we will never know what it was.

With this interpretation I've added this into DecodeIR, successfully as far as I can tell.

Do you want me to add it to my master copy of the source code, so when I next release decodeir your addition will be generally available?

Is there any point in DecodeIR identifying protocols that do not correspond to any UEIC PID?

Yes. We can consistently name a protocol and add support in decodeir.dll, and hopefully also in the protocols.ini file for RM, and maybe in a .irp file for makehex. In this case I assume there will be a custom upgrade usable in KM. That all can add up to enough support that later users who encounter this protocol don't need to even care that there is no UEI PID.

If we don't name it and use that name consistently in a few places in our tools, then every time someone finds in Rob needs to remember he's seen it before and dig up the thread (I don't know how he manages that so well).

John, thanks for all the info. At present, if you don't mind, I would like to continue to experiment and to add a few more protocols into my private version of DecodeIR. I can then give you a collected update for you to add into the master copy (if you are happy with my additions). Have you any timetable in mind for when you might issue a next release?
_________________
Graham

mathdon wrote:IODATA HVT-BT200 {38k,550}<1,-1|1,-3>(16,-8,0:7,D:7,S:7,0:7,F:8,C:4,1,-60)+

Is there anything in IRP that would tell us that this is LSB? Or am I confusing signal IRP with implimentation? Is the LSB thing just for the implementation? Since you are decoding the num 1 as OBC 1 which is from left to right shouldn't this all be written backwards with the LSB in front of it somewhere?

The_Robman wrote:Generally speaking, whenever you see more than 8 bits of variable data, it's a good idea to look for a checksum because, even if you don't intend to write any assembler to generate it automatically, you'll need to understand it if you want to try and generate any additional signals for discrete codes, etc.

After a good night's sleep this is has penetrated the brain. Thanks Rob. My decodes didn't make any sense, but they worked. However knowing the way these make sense would be very useful in discovering undocumented features in your equipment. That is the really "fun" part of JP1ing. My OEM remote didn't have many of the features that my JP1 remotes provide. My Samsung TV had lots of features that were not on the OEM remote, and my Sony DVD player didn't have a Record-Pause button on the original remote, but my JP1 remote does. So the sledgehammer was useful in the short-term, but it to truly reap the benefit I have to learn the art. And it definately is an art.

Vicky, I'm very new to this protocol business but my understanding is that IRP is LSB by default and that if MSB were intended then the first item would have to be {38k,550,msb}. Doubtless Rob or John will correct me if I am wrong - or at least, I hope they will!
_____________
Graham

vickyg2003 wrote:I'm still going to have to sit down with a piece of paper and a pencil to figure out what you saw in the signal to get to this. That part of this is still voodoo.

Here's how I did it. First, I created separate columns in the spreadsheet for each variable bit. If I've already determined the OBC, I'll sort the data by OBC. Next I try and generate the checksum, one bit at a time. In this case, it appeared that the data in the checksum was either a copy of, or the complement of, data in the obc byte, so I wrote formula to do this and repeated it down for the whole list of data. I then wrote a conditional formula that would make the data turn red if the generated checksum is different from the real checksum. Next, I look at the red data and see if it corresponds to a column in the original OBC data, and in this case I noticed that the generated code was wrong when a certain column in the OBC was set to 1. Based on this I was able to conclude that the checksum was an XOR of the two nibbles of the OBC, except that the first bit of the result was complimented.

mathdon wrote:As far as I can tell, regardless of how many bits are encoded in the protocol, it decodes into at most 3 items of data: device code, subdevice code and function (command) code.

I prefer to look at it as fixed data and variable data first, then I'll try and break it down further, but it's too restrictive to assume that all protocols follow the format you suggest. Some protocols have compliments, others don't. Some have sub-device codes, some don't. Some don't even have device codes (ie, the whole signal is variable). Some, like Panasonic and the have "OEM Codes". Some have toggle bits, some have checksums. The list goes on.

mathdon wrote:The OBC, Hex Code and EFC fields in DecodeIR are all various presentations of the function code.

Correct.

mathdon wrote:I can see no pattern such as comp relating your 4 7-bit fixed bytes but the first and last are zero, so is it reasonable to treat these zero bytes as really fixed and the other two as the device code and subdevice code?

We're basing everything we know about this protocol on a single sample, so so far we could certainly decide to treat the first and last fixed byte as hard coded zeroes, but you need to be flexible enough that when the next device comes along and those bytes are not zeroes, you're not screwed.

mathdon wrote:Could these instead be an 8-bit device code and 6-bit subdevice code? Is the distinction purely a JP1 matter or is there some absolute answer to which, if either, is right?

It's completely subjective, but we are also limited to what the IR engine can handle, which is all fixed bytes should be the same length, except if you have just 2 bytes in which case each can be unique. The same rule applies (separately) to the variable bytes.

mathdon wrote:Is there any point in DecodeIR identifying protocols that do not correspond to any UEIC PID?

Abso-friggin-lutely! Having DecodeIR recognize a non-UEI protocol saves me from accidentally decoding it more than once, and in the case of complicated protocols like XMP it would save me from having to do some really tedious time-consuming decodes.

mathdon wrote:But even more, how does one discover whether or not a new protocol such as this CAN be generated by any existing UEIC PID? There seem to be some very powerful UEIC protocol executors capable of generating a variety of distinct protocols or combinations of protocols and also a lot of UEIC PIDs to which JP1 has not ascribed a name, which I take it means that their purpose is unknown, so it doesn't seem to be a trivial task to determine whether one of them, with suitable fixed data, can generate some new protocol.

That's more tricky. I have a file which lists everything that I know about UEI protocols, so I will often check to see if there are any executors with the same frequency and same burst times, but I admit that I forgot to do that this time. I'll check it later.

The Robman wrote:

mathdon wrote:As far as I can tell, regardless of how many bits are encoded in the protocol, it decodes into at most 3 items of data: device code, subdevice code and function (command) code.

I prefer to look at it as fixed data and variable data first, then I'll try and break it down further, but it's too restrictive to assume that all protocols follow the format you suggest. Some protocols have compliments, others don't. Some have sub-device codes, some don't. Some don't even have device codes (ie, the whole signal is variable). Some, like Panasonic and the have "OEM Codes". Some have toggle bits, some have checksums. The list goes on.

I was thinking of three items of distinct information and was regarding complements, checksums, parity etc as part of the coding of that information, and the absence of any of these items as a null value for it. I knew, but had forgotten, about toggles (the MS Media Center Extender protocol uses a toggle and until I understood that, it was driving me crazy when I was testing my extender and getting weird behavior with macros!). But OEM codes are a new one to me. I presume they are part of the Misc data that John said shows up even in some decoded protocols. I'll look more at protocols.ini, though I find that very tough going.

The Robman wrote:you need to be flexible enough that when the next device comes along and those bytes are not zeroes, you're not screwed.

But as I'm not precognitive that flexibility has to remain in the mind rather than the protocol decode! At present (in my DecodeIR addition) those zeroes and the checksum formula are part of the way that the protocol is distinguished from others. So anything with different values there will show up again as unknown. At that point one would have a second set of fixed data and would try to generalize one's interpretation.
________________
Graham