Adding Slingbox support to RM

gfb107 · Post by **gfb107** » Fri Sep 23, 2005 12:01 pm

IF the only use for MaxCombinedUpgradeLength is for binary upgrades, and we want it to include the entire binary upgrade, I think we should call it MaxBinaryUpgradeLength.

Would it be OK if RM just computes the length of the upgrade without the setup code, and we just adjust the value in the RDF to compensate for it? Or we could add another variable to the RDF to tell RM that the setup code must be included in the length.

mr_d_p_gumby · Post by **mr_d_p_gumby** » Fri Sep 23, 2005 12:44 pm

gfb107 wrote:I'm not clear on whether or not the MaxLength includes the 2 bytes in the upgrade header. For a device upgrade, that's the device type, setup code and "Pid > 255", and for a protocol upgrade it's the PID.

For the existing MaxProtocolLength entries, the PID is not included in the size. It's just the actual number of bytes that are part of the protocol executor itself.

Post by **The Robman** » Fri Sep 23, 2005 3:54 pm

I would recommend keeping the MaxCombinedUpgradeLength as is, then we can use it for other purposes too when needed. For example, the device specific upgrades for the old Producer 8s use a similar format and while I don't know what limit there is to the size, I'm sure there is one.

Post by **The Robman** » Sun Oct 09, 2005 2:21 pm

Greg, would you have any interest in expanding the binary capabilities of RM to also format "OBJ" files for the old 2000/3000 series ReplayTV units?

It's not as easy to add an OBJ file to your Replay as it is to add a bin file to your Slingbox, but the question just surfaced over at AVS so I thought I'd ask. If you're willing to do the RM part, I'll create the RDF.

The format of the binary file is very slightly different to the Slingbox format (probably because this is a much older UEI chip).

bytes function
0-0: offset of protocol code (zero if no protocol upgrade needed)
1-2: setup code in hex format
3+: standard JP1 device upgrade
??: optional protocol upgrade - S3C8(old)

The files have names like "S1005_OBJ" with no suffix.

gfb107 · Post by **gfb107** » Mon Oct 10, 2005 5:10 pm

Seems pretty easy to do.

I assume you'll want to be able to read these files as well as write them.

I wonder what you think of this idea. Instead of having Advanced menu items for reading/writing special file formats, I thought it might be reasonable to use the standard File -> Open and File -> Save As... dialogs. If the remotes support formats other that .rmdu and .txt, I would add additional file types to the "Files of Type" drop-down.

Actually, I would always allow reading special format files, but only allow writing them if the selected RDF is compatible with them.

Post by **The Robman** » Mon Oct 10, 2005 5:23 pm

Sure, why not. And yes, I'm totally cool with the File --> Open idea.

Post by **The Robman** » Mon Oct 17, 2005 8:25 am

The Robman wrote:There's only one hex value that doesn't work using those formulas (a JU value of "7D" converts to "4E" rather than "CE").

Hey Greg, my PL box finally arrived and I have soldered in a 6-pin connector and have been able to get the complete picture as far as this encryption goes.

The only other value that doesn't follow the main formula is the flipside to the exception that we already spotted. In other words...

7D converts to 4E rather than CE, and
7F converts to CE rather than 4E.

Of course, we should have thought of that one right from the beginning, duh! But I can confirm that all the other values followed the formula.

However, I have a bug report for RM v1.37, the "export binary" function isn't working. It goes through all the steps to save the bin file, it just doesn't actually do it. I had to switch back to 1.35, which just happened to be the last version that I had set up in a seperate folder, over the weekend to do my testing.

Post by **The Robman** » Sat Nov 05, 2005 6:20 pm

Hey Greg,
I wonder if there's a way to improve the Import function a bit. If you take a look at this thread over in the Slingbox communnity, someone tried importing a binary upgrade and then re-saving it just to see if the process works, and with the file he happened to chose, it doesn't.

He chose to import the S0775_JU.bin file which just happens to use the 5-1 version of the Dish Network protocol, but RM substituted the 2-1 version and the resulting upgrade doesn't work.

The 5-1 version is supported by protocols.ini (it's variant 5) so I wonder if there's a way for RM to try and sync up the version being used in the upgrade file with the correct version from protocols.ini? In cases like this where the protocol code is supplied as part of the upgrade, you could compare the code to that stored in protocols.ini perhaps?

gfb107 · Post by **gfb107** » Sat Nov 05, 2005 8:51 pm

Rob,

I don't know if I'm looking at the wrong file, but my copy of S0775_ju.bin doesn't include the protocol code.

This means RM doesn't have enough information to pick the best match.

It can only pick the protocol by trying each one with a matching PID, until it finds one that generates fixed data from the device parms it imports from that fixed data.

Unfortunately, when there is no protocol code, RM doesn't even know the actual length of the fixed data, so it has to get that from the protocol it is testing. In this case it found a match that only used one byte of fixed data.

I suppose I could change it to check all variants, and choose the matching one with the longest fixed data.

Post by **The Robman** » Sat Nov 05, 2005 9:18 pm

gfb107 wrote:I don't know if I'm looking at the wrong file, but my copy of S0775_ju.bin doesn't include the protocol code.

That's weird, I mean either the JU box has the protocol built in or it doesn't. I've just loaded my copy of S0775_JU.bin to the Diagnosis Area so you can compare...

https://www.hifi-remote.com/forums/dload ... le_id=2404

Here's what the contents look like, where the protocol code is in green ...

0000 73 3d 33 07 02 00 fe fc f6 c0 08 fe 71 00 00 80 s=3...þüöÀ.þq...
0010 08 20 44 10 14 18 20 24 28 30 34 38 66 76 56 68 . D... $(048fvVh
0020 78 08 04 9c e5 2c 00 40 6c a4 48 68 78 70 60 5c x...å,.@l¤Hhxp`\
0030 50 3d 1d a7 0d 80 c5 c9 84 7c 48 dd d9 58 2b 5c P=.§..ÅÉ.|HÝÙX+\
0040 51 8b 16 b6 59 05 06 00 c5 03 32 00 c5 05 73 0b Q..¶Y...Å.2.Å.s.
0050 f2 00 c5 0b f2 05 02 43 8c 08 03 37 00 09 e6 22 ò.Å.ò..C...7..æ"
0060 02 c4 24 0e f6 01 55 18 08 56 c1 03 87 21 04 29 .Ä$.ö.U..VÁ..!.)
0070 04 8d 01 46

gfb107 · Post by **gfb107** » Sat Nov 05, 2005 9:47 pm

That doesn't match my version.

Strange, but protocol 00 02:5 doesn't produce the same fixed data as is present in that binary upgrade.

The fixed data in the .bin file is

Code: Select all

00 00 80 08 20

, but RM generates fixed data of

Code: Select all

00 00 80 08 00

That last byte is not computed by the translators coded in protocols.ini. It is taken directly from the default value for fixedData. Do we have the wrong default value in protocols.ini?

Looks like I have a bit of work to do. Here's where I'm planning to go wth this:

Code: Select all

If there is protocol code in the upgrade
  if there is a variant with matching protocol code
    use it
  else
    use a manual protocol with the protocol code from the upgrade
else
   for each variant of the protocol
     import the fixed data (length determined by the variant) into device parameters
     calculate the fixed data from the device parameters
     if the imported fixed data matches the calculated fixed data
       use the variant with the longest fixed data

Post by **The Robman** » Sun Nov 06, 2005 10:45 am

I like the idea of letting the protocol code in the upgrade override whichever version that RM was planning on using (assuming the code is different). However, in this case that's not the problem. I just took a closer look at the protocol code in the bin file and while it is different (which I hadn't noticed before), it's not significantly different. Here's the logic part of the old and new versions of the 5-1 version of $0002...

current version...

Code: Select all

FF1B: 18 08     LD     W1, R08
FF1D: 56 C1 03  AND    W1, #03H
FF20: 87 21 04  LD     W2, #04H[W1]
FF23: 29 04     LD     R04, W2
FF25: 8D 01 46  JP     0146H

version found in the Slingbox upgrade...

Code: Select all

FF1B: 08 03     LD     W0, R03
FF1D: 37 00 09  BTJRF  FF29H, W0.0
FF20: E6 22 02  LD     R22, #02H
FF23: C4 24 0E  LDW    R0E, R24
FF26: F6 01 55  CALL   0155H

FF29: 18 08     LD     W1, R08
FF2B: 56 C1 03  AND    W1, #03H
FF2E: 87 21 04  LD     W2, #04H[W1]
FF31: 29 04     LD     R04, W2
FF33: 8D 01 46  JP     0146H

In the new version, the additional code is at address FF20 thru FF26, but this is skipped if bit0 of the first fixed byte is 0, which it is in our upgrade. The rest of the code is the same.

As for the fixed data question, I just fired up KM, selected the Dish Network Combo protocol and found that the following values generate the fixed data in the upgrade...

unit code = 0
device0 = 0
device1 = 1
device2 = 16
device3 = 4

I then fired up RM to see what it would do and I can see the problem, it's only supporting 3 device codes, not 4, so all you need to do is add an additional device code (which is the 5th fixed byte) and you should be all set.

gfb107 · Post by **gfb107** » Sun Nov 06, 2005 1:39 pm

The problem with generating a manual protocol when the protocol code in the upgrade is unique, is that RM doesn't have anything to go on for naming the device and command parameters, or figuring out their translation. So it just punts.

It determines the number of fixed bytes and command bytes from the protocol code.

It will generate one device parameter for each fixed byte..
They will be named "Device 1", "Device 2", etc.
They will be 8 bits, and translation will be MSB.

It will generate one command parameter for each command byte.
They will be named "OBC" ( and "Byte 2" if there is a second byte).
They will be 8 bits and translation will be MSB.

Or, I could use the protocol variant that matches by PID and computed fixed data. I could even enhance it to attach the imported protocol code to the device upgrade. If the user chooses a different protocol, the imported protocol code would get discarded.

Post by **The Robman** » Sun Nov 06, 2005 2:56 pm

If the 3rd byte of the imported protocol is the same as the 3rd byte of any of the protocol variants of the protocol-id, I would suggest that you try using the translation mechanisms for that variant to see if you can get the same fixed data. But even so, still offer up the imported protocol rather than the one from protocols.ini

I must confess that I haven't tried to use Manual Settings in RM yet, but do you allow all the same controls that KM allows? Ie, can the user specify whether it's MSB, LSB, etc along with specifying how many bits to use for the device and command codes and stating whether the 2nd byte should go before or after the OBC byte?

gfb107 · Post by **gfb107** » Sun Nov 06, 2005 3:22 pm

Manual Setting support in RM is limited.

It can import KM upgrades that use Manual Settings, but only if there is protocol code in the notes.