JP1 Remotes

[mike.s]

I've been searching for undocumented Roku commands. I was using IRScrutinizer with a GIRS board. It won't accept OBD codes above 127. I suppose because the IRP protocol definition has this: "F:7" Similarly, RMPB has this: "CmdParms=OBC:7", which I think limits that.

RMDU won't accept OBCs >127, either. But the strange thing is you can enter any hex code, even if the resulting OBC code is >127. And, it works. And, some functions aren't available using OBC codes 0-127! For example, I've been using these for a while, and can't find them in OBC 0-127:

Func;obc;hex
Page down;213;AB
Page up;180;2D

Now, I've also been using some that are similar, and they also work if I subtract 128 from the OBC code:

Streaming Store;151;E9 (obc 151-128=23 also works)
Amazon Prime;144;09 (obc 144-128=16 also works)

But subtracting 128 from the page up/down doesn't work. In fact, subtracting from the Page up OBC results in 52, which is Rewind.

Also, I downloaded the most recent Roku RMDU I could find here ( http://www.hifi-remote.com/forums/dload.php?action=file&file_id=26618 ) from @The Robman, and some of the functions defined in that don't work. What he calls Channel up/down, 125/BE and 126/7E don't work. I think they're describing what I called Page up/down, above. (because they don't change channels in LiveTV, but do large scrolls in the Home menu and the LiveTV guide)

I'm playing on a Walmart ONN 6 device remote, as a URC3660. Signature:369006, Processor: Samsung S3F8, Interface: JP1.4. No issues with other devices.

Perhaps someone much more knowledgeable than I can figure out what's going on. I suspect there's some issue with the OBC/HEX mapping in the driver.

Oh, I'm not sure how I originally got the >128 OBC Page up/down commands, I've been using them for years. That's all, it's making my brain hurt.

[The Robman]

If I remember correctly, the Roku signal flips an OBC bit with each repeat, so there's no point in letting the OBCs go up to 255. What flipping the bit means is this, if you program OBC 0, what the remote will send is 0-128-0-128-0-etc, so if we let you program OBC 128, it would send 128-0-128-0-etc.

So yes, for any OBCs that you think are 128 or above, just subtract 128 from them and that new OBC should work.

I can't explain why it doesn't work for all OBCs of 128+ that you claim work.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!

[mike.s]

I dont' pretend to understand it all, but according to this page ( http://www.hifi-remote.com/forums/viewtopic.php?t=4633 ), it's the hex which is sent, not the OBC:

"The Hex command is the data the protocol executor uses to transmit the signal."

[The Robman]

Yes, that's exactly right, so we could allow you to program OBCs all the way up to 255, which would account for all the possible hex values, but all letting you program an OBC like 128 would do is allow you to decide that OBC 128 goes first, rather than OBC 0 going first, which shouldn't make a difference.

This might help explain it better, one byte of hex can be represented by 8 bits of binary, so hex 0x00 (OBC 0) would be 00000000 and hex 0x80 (OBC 128) would be 10000000.

As I said earlier, the way that Roku sends the signal, when you hold the button to make the signal repeat, it keeps flipping a bit, so the signal for OBC 0 and 128 looks like this:

00000000
10000000
00000000
10000000
etc
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!

[mike.s]

I'm very familiar with hex and bit based operations. If it's the HEX which gets sent, and the most significant bit which doesn't matter to the function, then this needs explanation, taken from the RMDU you posted (which I linked to above) :

function;OBC;HEX
Arrow Left;30;78
App:Walmart Video;31;F8

Those two functions differ only in the MSB.

Then I noticed that when I look at your RMDU, all HEX codes are even (LSB always 0). So, perhaps that's it. That would mean that my Page up/down commands (HEX AB and 2D) should work as HEX AA and 2C (with LSB cleared). But HEX AA is Fast Forward and 2C is Rewind. Sure enough, FF and REW do move quickly through lists, and do the same thing. When searching for new codes, including "low OBC" versions of my Page up/down, I simply didn't test those, because they were already there. I didn't know FF/REW would move you quickly through lists.

So, it appears that the MSB of the OBC is the same as the LSB of the HEX. The rest of the mapping between the two isn't as straight forward.

Thanks for helping me work through this.

I do find it odd, though, that Roku has some functions grouped in OBC order (e.g. the numerals 1-6 are OBC 33-38, in order). I thought OBCs were a JP1 thing, so would have expected Roku to have that in HEX order. Perhaps they use JP1 based firmware in their remotes.

I should have a more complete RMDU to post here within a few days, I've found several things to add to your's. ex. AppleTV is OBC 22, Vol+/Vol-/Mute are OBC 9/10/11... and more.

[3FG]

[The Robman]

I'll admit that I haven't read the $021A executor code in a while, so my answer was just based on my memory, but if it is doing an OR rather than an XOR, Dave is right, that isn't exactly a flip.

Mike, as you understand hex and binary, let me throw some more knowledge at you. We try to keep the concepts of "protocols" and "executors" separate, though we do sometimes use the terms interchangeably. The Roku protocol exists separate to anything UEI or JP1 related, so you can capture the signals from your OEM Roku remote and document what they look like, and what you would be documenting is the "protocol", and when doing so you will notice that things like the numeric buttons are sequential, and when we notice that, that's how we determine how to read the OBC.

Now what do I mean by that last statement? We use the terms MSB and LSB to describe protocols. If we notice that the signals increment on the right, like normal binary, we call them MSB, which means the MSB gets sent first. But if we notice that they increment on the left, which implies the binary is being sent backwards, we call them LSB, meaning that the LSB gets sent first.

Regardless of whether a protocol is MSB or LSB, which itself can be subjective, you can certainly convert your captured signals into binary and you can convert that binary into hex. But you shouldn't confuse those hex codes with the hex codes that you send into a UEI executor. One reason for that is most UEI executors have the binary reversed.

When you convert your captured signals into binary, you have to decide which pair is a logical zero and which pair is a logical one, and that also is subjective. UEI typically gets the 1s and 0s backwards in their executors, and when they do this we refer to the executor as "COMP". So that's the main reason why the hex codes that you feed into an executor might be different to the hex codes that you derived from your captured signals.

Another possible reason is that sometimes there is additional logic in the executor that uses one or more bits of the input to control what it does. I don't believe the Roku executor does that, so that's not relevant here.

I hope that helps explain some of the terms that we use, and gives some insight into how a UEI executor works. If you're able to read and understand S3C8 assembler, we can help you read the code in some of these executors to help understand what they do.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!

[mike.s]

[The Robman]

This is what the $021A executor looks like:

[The Robman]

[The Robman]

[mike.s]

Function code and "F" as in the column labeled "F" in IRScrutinizer.

From the IRScrutinizer docs:

[The Robman]

Ah, you were talking about IRScrutinizer, not RM. You'll have to talk to Barf about that.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!

[Barf]