Adding Slingbox support to RM

[The Robman]

Tell me if I'm following the java code correctly...

val &= 0xFF; = val AND 0xFF (convert val to hex?)
int val1 = ( val >> 2 | val << 6 ) + 111; = Rotate left 6 times & add 111
val1 &= 0xFF; = val AND 0xFF (convert val1 to hex?)
int val2 = ( val & 0x80 ) grab bit-7 from val
& ( val << 7 ); then AND with bit-0 from val
int rc = ( val1 ^ val2 ); = XOR val1 with val2

That certainly seems to be correct.

And yes, you are correct that it was 7D that didn't convert correctly. I'll need to take another look at the upgrade to see where that byte fell to see if it made much of a difference. If it's just a button code, then he probably didn't notice that one button wasn't working.

[The Robman]

I'm so bad at Excel I don't even know how to see the formulas.

Most of the work sheets are hidden, to reveal them do this...

Format > Sheet > Unhide (then select a hidden sheet to reveal)

What I do is open a bin file using FRHED and export it to the clipboard, then I copy the contents to the "PL in" or "JU in" input sheets.

Then, I parse out the individual hex bytes using the PLw and JUw sheets. The formula to do this is probably irrelevant, but it's stored in named items: pl_hex and ju_hex. To see the contents of a named item, do this...

Insert > Name > Define (then select the item to view)

Next, I convert the JU hex code to PL hex code in the "JU to PL" sheet, using the ju_conv named item. I also convert the PL hex to JU hex in the "PL to JU" sheet using the pl_conv named item.

Finally, all the code ends up in the "debug" sheet where I compare it to find differences.

The code to convert JU hex to PL hex is as follows:

ju_conv: =IF(TRIM(JUw!K8)="","",juw2)
That just says that if the input cell is blank, the output cell should also be blank. The converted hex code comes from the "juw2" named item.

juw2: =DEC2HEX(MOD((BIN2DEC(MID(juw1,7,2)&MID(juw1,1,6))+111)+(MID(juw1,1,1)*MID(juw1,8,1)*128),256),2)

juw1: =HEX2BIN(JUw!K8,8)

So first I convert the hex to binary in the juw1 item, then in juw2 is do the rotate, add 111, and XOR bit-7 if both bit-0 and bit-7 are set in the original binary.

The code to convert the PL hex back to JU hex is as follows:

pl_conv: =IF(TRIM(pl_hex)="","",BIN2HEX(MID(plw2,3,6)&MID(plw2,1,2),2))

plw2: =DEC2BIN(MOD(BIN2DEC(plw1)+(MID(plw1,2,1)*MID(plw1,3,1)*128),256),8)

plw1: =DEC2BIN(MOD(HEX2DEC(PLw!K8)+145,256),8)

plw1 is subtracting 111 from the decimal value. In order to avoid negative numbers, I'm actually adding 256 and then subtracting 111 (ie, +145 = +256 - 111). I'm then MODing the value with 256 to make sure it's in the range 000 thru 255. Finally, I convert it to binary.

plw2 takes care of the XOR when needed.

[gfb107]

Code: Select all

val &= 0xFF;

& is the bitwise AND operator, so what this does is mask off all high order bits, leaving only the low order 8 bits. It is equivalent to MOD 256.

[The Robman]

Code: Select all

val &= 0xFF;

& is the bitwise AND operator, so what this does is mask off all high order bits, leaving only the low order 8 bits. It is equivalent to MOD 256.

Thanks, I figured out the AND part, but it didn't occur to me that it could be used as a MOD.

[gfb107]

OK, after some more investigation, I found that RM produces the same output that your spreadsheet does. However, this does not match your hand-coded PL file, for the JU values I documented above.

I'll release the new code shortly.

[The Robman]

OK, after some more investigation, I found that RM produces the same output that your spreadsheet does. However, this does not match your hand-coded PL file, for the JU values I documented above.

That doesn't make sense. When the user said the PL upgrade wasn't accepted as a valid code by the Slingplayer software, here's what I did.

I used FRHED to convert both the JU and PL versions to text and I copied both of these to the relevant input sheets of my validation spreadsheet. Then I went to the "debug" sheet and found the differences.

I then edited the PL binary file using FRHED so that it matched the output of the spreadsheet. Then I re-exported it to text and re-validated it.

[gfb107]

I don't know what to tell you.

Here's what the improved RM generates:

Code: Select all

806FBC74 056F2E2E 2D2AAD2E C877EDEA
B6E040D0 6ECE5E66 C656DE3E E6D636EE
EEEE4E4C 3844E2EA ECE8DC3C E4D43242
D636464A 483A30D2 34D8DA52 BECA5AC2
62ECBA6A B2

Here's your hand-coded file:

Code: Select all

806FBC74 056F2E2E 2D2AAD2E C877EDEA
B6E040D0 6ECE5E66 C656DE3E E6D636EE
EEEE4E4C 3844E2EA ECE8DC3C E4D43242
D636464A 483A30D2 34D8DAD2 BECADAC2
E2ECBAEA B2

Note that the mismatches don't happen til very close to the end of the upgrade. I had to extend the formulas in the Debug sheet down to row 70 before I could see them.

[The Robman]

Maybe I grabbed an older copy of one of the files or something. As I can't test RM at work, could you try this for me. Open the RMDU file from the zip that I posted and create a JU and a PL file then post them in the file section. (Don't email them to me as my work server will block the email, it doesn't like bin files).

[gfb107]

Here you go: https://www.hifi-remote.com/forums/dload ... le_id=2141

[The Robman]

You're right, the two files you created do match up correctly. I'll have to re-test this at home, I guess it's possible that we're using different versions of RM.

The reason that you had to extend the range in my validation spreadsheet is because your bin files include protocol upgrades, which tells me that you don't have the most recent versions of the RDFs.

Regarding the 7D/4E code, as I don't know how soon I'll get the data to let me come up with the definitive formula, you might want to add some hard coding for those values so we know that that code at least is formatted correctly.

[The Robman]

I just downloaded v1.34 and the PL encoding looks good (I see you added the 7D/4C code). However, I'm getting a protocol in the upgrades now, even though I have specified that both the PL and JU chips have the $005A protocol in the RDFs. (The $005A protocol is not listed in the last version of the JU RDF that I posted. That's because it was not included in the list that I was given of exec that are included, which is obviously wrong, so I am investigating).

Also, RM is still not remembering the folder that you last used to save the binary files, so you have to re-navigate there every time.

[gfb107]

Try RM v1.34a.

[The Robman]

That's better. Protocols only when needed, it remembers the export folder and the SAVE button now reads "SAVE". Once I get some data to complete the JU/PL encryption formula, we might be almost there! This is good stuff, thanks Greg.

[The Robman]

I just found a slight bug in the code that generates a binary upgrade. The problem occurs when a protocol upgrade is required. The length that RM calculates for the 2nd byte of the binary file is 1 greater than it should be.

To verify this, try importing the D0037_JU.bin upgrade file, then try exporting it and save it with a different name. You'll see that in the original the length byte is 0x29 and in the generated code it's 0x2A.

[The Robman]

When you're next under the hood of RM, could I make a request? Would it be possible to allow the DELETE button on the PC keyboard delete button assignments (in the Buttons sheet), rather than requiring us to drag the "none" icon over it?