RM Setup Codes.

[eferz]

Hi, I need a little help to understand how RM configures its setup codes. This is how it was explained to me.

"The setup code occupies 2 bytes, where the top nibble is the device type and the top bit of the remaining 3 nibbles is the first byte of the protocol id. So that just leaves 11 bits for the setup code, which gives you a max value of 2047."

Unfortunately, that description confuses me slightly. So, I'd like to get reconfirmation of how I interpret it.

The setup code is a 16 bit code. The device type is defined by bits 13-16, the Protocol ID is defined by bits 5-12, and the setup is defined from bit 1-11. This would mean that the Protocol ID overlays the setup. Is this correct?

My other question is what is the four bit equivalent to define a device type of Laserdisc?

[The Robman]

Let's say that the following represents the binary for a 2 byte setup code:

abcdefgh ijklmnop

the device type is represented by abcd, which gives you 16 possible device types.

e will become the first byte of the protocol id, so the byte only has two possible values, 01 and 00 (the second byte of the protocol id is the first byte of the device upgrade data).

fghijklmnop form the actual setup code.

[gfb107]

I have to ask: why do you think you need to know this level of detail?
For one thing, there are two different ways for encoding this information, depending on what remote you are using (some remotes allow setup codes up to 4097), Some remotes allow 2-byte PIDs, while others use 9bits.

All the tools (KM, IR, RM/RMIR) will do this for you. Why not let them do it?

[vickyg2003]

I have to ask: why do you think you need to know this level of detail?

All the tools (KM, IR, RM/RMIR) will do this for you. Why not let them do it?

Greg, has it been so long that you don't recognize the first stages of jp1 fever! I remember tearing KM to pieces trying to figure out how this was all done.

[gfb107]

Believe me, I remember. It's why I'm still here after all these years.

But, when I asked these kinds of questions, I always tried to explain what I was trying to accomplish, or where I was headed. A little more information around the question helps get better answers, especially for a first time poster.

Within the last week, we had someone trying to create LKP keymoves without using the special protocols/function tab, and was asking detailed question about how the keymoves should be formatted. He thought that's what he needed to know. But what he really needed to know was how to get things setup so the tools would do the low level work for him.

[vickyg2003]

Yes it would be nice to get information up front. It is really easy for users to get crazy ideas

Remember this guy?
https://www.hifi-remote.com/forums/viewt ... =wonderful

[eferz]

Yes it would be nice to get information up front. It is really easy for users to get crazy ideas

I have to ask: why do you think you need to know this level of detail?

Okay, so my crazy idea has to do with the Slingbox. It has a UEI chip inside as you probably know. It has its own remote code library. We've been creating device update using Remote Master. Using the Slingplayer software to upload the bin files to the Slingbox. Working with the upload tool, we've come to understand that the setup (offset 02h 03h in the file) needs to match the filename. For example, if the filename is C1234_PL.bin, then the setup code needs to match"C1234".

We've recently found out that the Slingbox has the ability to learn IR codes. Just like a learning remote control. Once you're finished learning the codes, the remote profile is uploaded to the Slingbox as "L9999". So. I'm trying to spoof that setup code to see if I can upload my own file and see how it affects the previously learned code.

I've understood the RM can only create a setup code from 1-2047 since it uses the 11 bits of chomp. However, 9999 requires 14 bits to represent the number in binary. "10011100001111". If I take the 11 bits from that, "11100001111" its decimal would be 1807. This leaves the rest with the Device ID and the first bit of the Protcol ID. So, basically "DeviceID.ProtocolID.SetupCode" = "??10.0.11100001111". I realize that its just two bits left unknown and only 4 possible combinations. I just wanted to get an idea of how RM calculated the setup code.

[vickyg2003]

ezera, perhaps it would help to know that learns don't have a protocol ID.
When a learn is done there is some analysis done, but it doesn't try to figure out which protocol executor (subroutine) can send that kind of signal and what parameters that executor needs to send that kind of signal. So your L9999 is not going to hold that kind of information.

When a learning remote learns a signal, it records the frequency and the a series of ON/OFF times. The signal is then analyzed as to what is sent once, and what is sent repeatedly. When the learn is stored it has a device mode, keycode, frequency on offs for the sent once part, on offs for the repeat part, and on-offs for the part sent after repeating is finished.

[gfb107]

Does the Slingbox dump the learned signals to a file? If you have a file containing the learns upload it to the diagnosis area, and we can probably figure out the format of the file.

[The Robman]

I suspected this might be what he was trying to do because I recognized my own words in the quote in the original post (though I said them to someone else).

My assumption is that UEI added special logic to their chip to look for files called L9999, and when they find such a file, they know to look for learned signals rather than an upgrade.

So, bottom line, your current exercise to try and figure out how to format an upgrade file so that it's called L9999 is pointless.

What you need to do is try and get your hands on an L9999 file.

If you can't find it in the SBAV folders anywhere, it's possible that Sling has hidden it, in which case try the forums for Hava to see if those guys have found it.

[eferz]

Thanks guys for your response. I've come to understand that you're the brain trust behind this forum. So, I do appreciate your time for the feedback. I hope you guys understand that I'm not trying to solve everything at once. Just trying to feed the Slingbox and look at its excrement to understand it better.

So when Rob says...

So, bottom line, your current exercise to try and figure out how to format an upgrade file so that it's called L9999 is pointless.

I don't agree. The pursuit of knowledge and understanding is never pointless. Even if the paths I take lead me to a dead end, at least I would have the knowledge that there's a dead end at the end of the path. Instead of wondering what might lie at the end of the path.

Since my current intent at this point is to upload my own "L9999" file and see if it erases the learned configuration. This will help me understand how the data is stored. If I am able to upload such a file and it does not affect the learn programming then I will know to turn back and try another path. Getting a working file is an entirely different pursuit.

ezera, perhaps it would help to know that learns don't have a protocol ID.

Yes, that's would be my understanding. There would be no sense in having a global profile ID if you can learn multiple functions of several remotes. Since each might have their own protocol. Instead, I believe what it learns is a "raw" IR stream, but I don't know if that's how its represented or stored.

But again, if the representation of the L9999 takes up 16 bits of information then it doesn't matter to me. The 14 bits of information required to make 9999 would overwrite it anyways. I was merely trying to understand the how RM calculated the 16 bits of information to by pass the file name checks.

Does the Slingbox dump the learned signals to a file? If you have a file containing the learns upload it to the diagnosis area, and we can probably figure out the format of the file.

Actually, better than that. I can actually see a log file of the information that it does obtain while I learn each code. The file itself isn't stored stored on the computer. I've been monitoring open file descriptors on my computer during the process. The only related data is the logfile which I'm tailing at the same time.

My port sniffer would have me believe the Slingbox is uploading the leaned codes to Sling Media central repository which is tied to my Sling Account. The information that is stored as xml file which is appended with new information each time a new button is learned. It allows me to see the interpreted data for each button press. I assume once the process is complete, the Slingbox then downloads this data and is stored as a "L9999" file since that's what the logs seem to indicate.

Through the web tools, I can download a representation of this file as a MyRemote.lrz file. However, I haven't really played with it that much. It doesn't look anything like the bin created by RM master. Alan Richey tried to upload another users file into his Sling Account but it wouldn't let him. It actually didn't give him any response. I'll have to get back to you with my findings as I tail the log while trying to import them myself.

Anyways, what I'll do is create two files. One with each button all programmed with the "Select" from the Scientific Atlanta 8300 remote. The other one with "Play" from the same remote. Since you guys have this remote on your own database, you'll at least have some reference data. Its easier to see patterns when you know there is one. I'll also attach the xml files associated with each one to have an even better reference information.

Thanks again for your time and feed back.

[eferz]

Here an archive, with all files as listed in the previous post.
https://www.hifi-remote.com/forums/dload ... le_id=8655

[binky123]

Your xml file seems to include the data in UEI Learned format. You can cut and paste this data into IR.exe's learned data and add spaces between every 2 characters. Some of the longer learns are not recognized but the shorter ones are recognized as Panasonic_Old protocol and the correct OBC for play(51) and select(12).

[The Robman]

Here are the XML learns converted into an IR file...
https://www.hifi-remote.com/forums/dload ... le_id=8657

[eferz]

Thanks Rob and binky123 for that information. I actually didn't need the protocol decoded. I knew what they were before uploading them. I already have the RMDU for the Scientific Atlanta 8300's remote control which I used for the baseline files.

As mentioned in an earlier post, I recorded "play" for all the buttons in one file, and "select" on the other file. I was just trying to make it easier in case someone wanted to try to decipher the format of the MyRemote.lrz file. Probably I miscomprehended what gfb107 was saying.

Anyways, special thanks to binky123 whom let me know the format of the codes in the xml file, and for letting me know how to use them in IM.exe. I did find it interesting that even though it was the same key throughout the file, they all were recorded with different numbers. I would probably have to learn the UEI Learned Format to understand that better.

So, far I haven't quite figured out why Alan couldn't import the MyRemote.Irz file of another user. In another test, someone else was able to upload my files in their account. But, I'm still going to keep cracking at it.

I haven't yet tried to bypass the file name check, since I don't know what the which bits need to be off or on in the device id for setup code. The idea of uploading 16 different files doesn't seem very fun at the moment. Maybe someone will enlighten me which binary combination will represent the laserdisc in the device ID.