JP1 Remotes Forum Index JP1 Remotes


FAQFAQ SearchSearch 7 days of topics7 Days MemberlistMemberlist UsergroupsUsergroups RegisterRegister
ProfileProfile Log in to check your private messagesLog in to check your private messages Log inLog in

Something strange with Roku Official protocol and RMDUs.

 
Post new topic   Reply to topic    JP1 Remotes Forum Index -> JP1 - Protocol Decodes
View previous topic :: View next topic  
Author Message
mike.s



Joined: 03 Feb 2017
Posts: 25

                    
PostPosted: Thu Sep 07, 2023 4:57 pm    Post subject: Something strange with Roku Official protocol and RMDUs. Reply with quote

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.
Back to top
View user's profile Send private message
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 21234
Location: Chicago, IL

                    
PostPosted: Thu Sep 07, 2023 7:35 pm    Post subject: Reply with quote

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!
Back to top
View user's profile Send private message Visit poster's website
mike.s



Joined: 03 Feb 2017
Posts: 25

                    
PostPosted: Thu Sep 07, 2023 7:59 pm    Post subject: Reply with quote

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."
Back to top
View user's profile Send private message
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 21234
Location: Chicago, IL

                    
PostPosted: Thu Sep 07, 2023 8:57 pm    Post subject: Reply with quote

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!
Back to top
View user's profile Send private message Visit poster's website
mike.s



Joined: 03 Feb 2017
Posts: 25

                    
PostPosted: Thu Sep 07, 2023 11:41 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
3FG
Expert


Joined: 19 May 2009
Posts: 3367

                    
PostPosted: Fri Sep 08, 2023 1:57 am    Post subject: Reply with quote

The Robman wrote:
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,
The 021A executor doesn't actually work like that. Instead for the first frame it sends whatever 8 bits were sent to the executor. For repeat frames, it ORs bit 7 (or bit 0, depending on how you number the bits) with a 1 and of course sends the complement of those 8 bits in byte 4. So it's not a "flip".

In RMProtocols.html, Roku is described as
Code:
{38.0k,564}<1,-1|1,-3>(16,-8,D:8,S:8,F:7,0:1,~F:7,1:1,1,^108m, (16,-8,D:8,S:8,F:7,1:1,~F:7,0:1,1,^108m)*)[D:0..255,S:0..255=255-D,F:0..127]
while the UEI executor sends
Code:
{38.0k,564}<1,-1|1,-3>(16,-8,D:8,S:8,F:8,~F:8,1,^108m, (16,-8,D:8,S:8,F:7:1,1:1,~F:7:1,0:1,1,^108m)*)[D:0..255,S:0..255=255-D,F:0..255]
I'm pretty rusty with IRP, so the later expression is probably not right, but I hope you can get the flavor.

The entry in Protocols.ini permits the behavior that mike.describes: OBCs can only be entered as 7 bit values, but if the hex is edited to 8 bits, the 8 bits are sent to the executor. I don't know if that is a feature or a bug.

Based on the experiments mike.s has done, I think it is probable that our understanding of the Roku protocol is incorrect, and UEI is closer.
Back to top
View user's profile Send private message
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 21234
Location: Chicago, IL

                    
PostPosted: Fri Sep 08, 2023 12:45 pm    Post subject: Reply with quote

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!
Back to top
View user's profile Send private message Visit poster's website
mike.s



Joined: 03 Feb 2017
Posts: 25

                    
PostPosted: Fri Sep 08, 2023 1:25 pm    Post subject: Reply with quote

Quote:
If we notice that the signals increment on the right, like normal binary, we call them MSB

That would be exactly backwards, if by "right" you're referring how binary/hex numerals are written. The bits at the right are the least significant (represent the smallest numbers), and are called LSB:

00000001 = 1(dec)

Bits at the left represent the largest numbers, so are most significant (MSB):

10000000 = 128(dec)

I understand that different protocols may send them MSB or LSB first.

BTW, I wasn't working with any captured signals, just using IRScrutinizer to generate and send stuff using the Roku protocol. Change "F", send a code, see what it does.

I have a lot of respect for those who put all these tools together, but there are big mis-matches. When I imported an RMDU, it wouldn't send any codes because it knows the "Roku" protocol, while RMDUs use the "Roku Official" one. Editing some files fixed that, but still made it a hassle. It also doesn't read the function code ("F") from an RMDU. I notice newer versions (I was using 2.10) don't even try to support "RemoteMaster" files.
Back to top
View user's profile Send private message
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 21234
Location: Chicago, IL

                    
PostPosted: Fri Sep 08, 2023 1:27 pm    Post subject: Reply with quote

This is what the $021A executor looks like:
Code:
        REMOTE  S3C8+       
        DB      43h,8Bh     ;38.095 kHz 32.857%
        DB      21h         ;2 dev, 1 cmd
        JR      Start       
        DB      CFh         ;pf0:     11001111=devs,cmds,dev-cmd,OffAsTotal
        DB      44h         ;pf1:     01000100=LI-same,1on-LO (no repeats)
        DB      08h         ;pd00:    DevBits1=8
        DB      08h         ;pd01:    CmdBits1=8
        DW      0121h       ;pd02/03: 1-burst on=578 uS
        DW      0330h       ;pd04/05: 1-burst off=1672 uS
        DW      0121h       ;pd06/07: 0-burst on=578 uS
        DW      00FDh       ;pd08/09: 0-burst off=546 uS
        DW      D2DCh       ;pd0A/0B: Leadout off=107960 uS
        DW      1194h       ;pd0C/0D: Leadin on=9000 uS
        DW      08B6h       ;pd0E/0F: Leadin off=4500 uS
                           
Start:  LD      R06,R05     ;copy OBC byte to OBC2 position
        COM     R06         ;comp OBC2
        INC     R11         ;increase # of variable bytes to 2
        CALL    0146h       ;send signal
        CALL    010Ah       ;check if button held
        JRC     Repeat      ;if no, exit, otherwise continue
        RET                 
Repeat: OR      R05,#01h    ;set MSB if not set already
        AND     R06,#FEh    ;do the same for OBC2
        OR      R29,#01h    ;turn on repeats
        JP      0146h       ;send signal while held and exit

Based on this, I do agree that the entry in protocols.ini is wrong. The way this appears to work is, if you use OBCs 0-127, it sends the signal once, then it adds 128 to the OBC and sends that as a repeat. But if you send OBCs 128-255, it sends the same signal in the repeats. Seems kinda odd, but that's what the code appears to do.

Just FYI, the format of this protocol is very similar to NEC2, except for the handling of the MSB in the repeats. Untypically, UEI got the binary right in this one, so it's not COMP like the NEC2 executor is, but it is LSB.

To fix protocols.ini all you should need to do is change:

CmdParms=OBC:7

to

CmdParms=OBC:8

If you make that change and confirm that OBCs over 127 do work and are different to their <128 counterparts, we will fix protocols.ini
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!
Back to top
View user's profile Send private message Visit poster's website
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 21234
Location: Chicago, IL

                    
PostPosted: Fri Sep 08, 2023 1:30 pm    Post subject: Reply with quote

mike.s wrote:
Quote:
If we notice that the signals increment on the right, like normal binary, we call them MSB

That would be exactly backwards, if by "right" you're referring how binary/hex numerals are written. The bits at the right are the least significant (represent the smallest numbers), and are called LSB:

00000001 = 1(dec)

Bits at the left represent the largest numbers, so are most significant (MSB):

10000000 = 128(dec)


By increment on the right, I mean like this:

00000000
00000001
00000010
00000011
---------> right

Whereas an LSB protocol would increment like this:

00000000
10000000
01000000
11000000
<--------- left

Or to put it another way, when a signal sends its most significant bit first (ie, the bit on the left when you write it down), the LSB (ie, the bit that increments) is on the right.

When a signal sends its least significant bit first (ie, the bit on the left when you write it down), the LSB (ie, the bit that increments) is on the left.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!
Back to top
View user's profile Send private message Visit poster's website
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 21234
Location: Chicago, IL

                    
PostPosted: Fri Sep 08, 2023 1:38 pm    Post subject: Reply with quote

mike.s wrote:
I have a lot of respect for those who put all these tools together, but there are big mis-matches. When I imported an RMDU, it wouldn't send any codes because it knows the "Roku" protocol, while RMDUs use the "Roku Official" one. Editing some files fixed that, but still made it a hassle.

You need to have some understanding of how these things develop and as much as we try to keep everything current, nobody's getting paid here, we're all volunteers. When we first came across the Roku signal, there was no UEI executor for it, so we had to write our own, which was simply called Roku, but eventually UEI wrote one and there were probably some differences in their version to our version, so this new one was called Roku (Official). If some things are a hassle, just imagine if there was no JP1 to start with, that would be much more hassle, no?

mike.s wrote:
It also doesn't read the function code ("F") from an RMDU. I notice newer versions (I was using 2.10) don't even try to support "RemoteMaster" files.

What does the term "function code" mean in this context? If it's the same as OBC, those are decimal so of course it wouldn't understand "F". If you mean something else, please explain.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!
Back to top
View user's profile Send private message Visit poster's website
mike.s



Joined: 03 Feb 2017
Posts: 25

                    
PostPosted: Fri Sep 08, 2023 4:42 pm    Post subject: Reply with quote

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

From the IRScrutinizer docs:
Quote:
The "Generate" pane
In the upper part of this pane, an IR protocol is selected, identified by name, and the parameters D ("device", in almost all protocols), S ("sub-device", not in all protocols), F ("function", also called command number or OBC, present in almost all protocols), as well as T, "toggle" (in general 0 or 1, only in a few protocols). These number can be entered as decimal numbers, or, by prepending "0x", as hexadecimal numbers.


What I was saying is that when it imports an RMDU, it doesn't pick up the function code ("F" there, "OBC" here). That column is just empty. When generating signals, you can fill in "F" (OBC), then transmit, to go through all codes.
Back to top
View user's profile Send private message
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 21234
Location: Chicago, IL

                    
PostPosted: Fri Sep 08, 2023 5:09 pm    Post subject: Reply with quote

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!
Back to top
View user's profile Send private message Visit poster's website
Barf
Expert


Joined: 24 Oct 2008
Posts: 1414
Location: Munich, Germany

                    
PostPosted: Fri Sep 08, 2023 5:18 pm    Post subject: Reply with quote

mike.s wrote:
What I was saying is that when it imports an RMDU, it doesn't pick up the function code ("F" there, "OBC" here). That column is just empty. When generating signals, you can fill in "F" (OBC), then transmit, to go through all codes.

You are obviously using a very old version of IrScrutinizer. Import of RMDU files was removed several years ago. Instead, you make a "Girr" export in RMDU/RMIR, which can flawlessly be imported in IrScrutinizer. (Girr is the native format of IrScrutinizer.)

The rationale is that interpreting RMDU files requires a ton of UEI domain knowledge, and RMIR/RMDU is the program containing that domain knowledge. Duplicating this domain knowledge would not be very good software engineering. As you noted, the implementations in the ancient versions were not very good, so it was junked.
Back to top
View user's profile Send private message Send e-mail Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic       JP1 Remotes Forum Index -> JP1 - Protocol Decodes All times are GMT - 5 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


 

Powered by phpBB © 2001, 2005 phpBB Group
Top 7 Advantages of Playing Online Slots The Evolution of Remote Control