JP1 Remotes

Posted: **Sat Sep 03, 2005 1:57 pm**

The Robman wrote:When you're next under the hod 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 requirig us to drage the "none" icon over it?

Good suggestion; could I ask for [ctrl] to allow multiple selections of buttons to delete or [shift] to select a range? BTW have you been drinking or do you have a head cold?

Posted: **Mon Sep 05, 2005 5:03 pm**

The Robman wrote: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.

I can fix the protocol offset being off by one.

I also noticed that RM is generating a different protocol upgrade than what is in the original file. Any idea what's going on there?

Posted: **Mon Sep 05, 2005 5:03 pm**

The Robman wrote: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?

No sweat.

Posted: **Mon Sep 05, 2005 5:40 pm**

gfb107 wrote:I also noticed that RM is generating a different protocol upgrade than what is in the original file. Any idea what's going on there?

RM gets the protocol code from protocols.ini The protocol in question is the standard Sharp/Denon protocol IIRC, and I think this is standard issue for all remotes. So my guess is that they tweeked it a little.

When they upgrade an exec, they virtually delete it from all the remotes that have the old version, so when they create upgrades for these old remotes, a protocol upgrade is automatically generated. They certainly don't go to the lengths that we do to support every variation of an exec.

Posted: **Mon Sep 05, 2005 8:36 pm**

underquark wrote:Good suggestion; could I ask for [ctrl] to allow multiple selections of buttons to delete or [shift] to select a range?

The Buttons tab already supports multiple selection using ctrl and shift. The delete key will work with multiple buttons selected.

Posted: **Mon Sep 05, 2005 8:39 pm**

I always found the - none - function rather non-intuitive. I'm tempted to get rid of it when I add support for the delete key. Thoughts? I could add a delete button next to the Auto assign button in addition to supporting the delete key.

BTW, I plan on adding this new delete support to the Layout tab in addition to the Buttons tab.

Posted: **Tue Sep 06, 2005 4:20 pm**

RM v1.35 is ready with all these changes.

Posted: **Tue Sep 06, 2005 4:26 pm**

Thanks Greg, I'll check it out.

Posted: **Wed Sep 14, 2005 7:45 pm**

Hey Greg,
Could you try loading this upgrade into RM and then select the PL Slingbox. This "manual settings" upgrade uses the $016C protocol, which is installed in the PL Slingbox, but RM is supllying a protocol upgrade anyway, which is tripping the size limit. Any clues as to why?

Also, is there any chance that you could support a size limit parameter of some sort if we were to add one to the RDFs. In my testing, the total upgrade size limit for the Slingbox is just 108 bytes.

Posted: **Thu Sep 15, 2005 8:36 am**

RM makes the (incorrect) assumption that any protocol used with "Manual Settings" must not be builtin, and therefore the protocol code is required.

Since this appears to be an official protocol, we should take the time to create a protocols.ini entry for it, which will resolve this.

You can start by just creating an placeholder for it like this:

Code: Select all

[pid: 01 6C]
PID=01 6C
Code.S3C80=43 8b 42 8b 05 00 00 6a 01 67 e4 07 09 e4 08 0a \
e4 03 07 e4 04 08 f0 08 56 08 0f f6 ff 90 f6 ff \ 
2f fb 0b 46 08 80 f6 ff 90 f6 ff 2f 7b fb af 28 \ 
03 f6 ff 68 28 04 f6 ff 68 28 05 f6 ff 68 28 06 \
f6 ff 88 c6 f8 19 64 f6 01 58 28 07 f6 ff 68 28 \
08 f6 ff 68 28 09 f6 ff 68 28 0a f6 ff 88 c6 f8 \
9b 47 f6 01 58 8d 01 0a 48 c2 f0 c2 f6 ff 74 28 \
c4 8d ff 74 1c 12 f6 01 4c 56 c2 0f 6b 09 c6 f8 \
00 3f f6 01 58 2a f7 af f6 ff 68 1c 12 8d 01 4c \
08 07 f0 c0 18 08 f6 ff b0 18 09 f6 ff b0 18 0a \
f6 ff b0 60 c0 0e 56 c0 0f 56 07 f0 44 c0 07 af \
28 c1 f0 c1 02 12 02 01 af

RM will figure out the number of device and command parameters by parsing the protocol code. Of course it will only have standard names for the parameters, with default translation (MSB). However, it'll work.

You will have to recreate the device upgrade, but that's easy to do using cut'n'paste.

As far as adding support for size limits, all we need is to come up with the RDF syntax for it. I suggest adding new entried to the [General] section.

Code: Select all

MaxDeviceUpgradeLength=<maximum size (bytes) for a device upgrade>
MaxProtocolUpgradeLength=<maximum size (bytes) for a protocol upgrade>
MaxCombinedUpgradeLength=<maximum size (bytes) for the device and protocol upgrades combined>

I can look at adding code to enforce those limits next week.

Posted: **Thu Sep 15, 2005 9:44 am**

For "manual settings" upgrades that include protocols, would it be possible for RM to first check the RDF to see whether there is a version of this p-id pre-installed, and when it finds that it is installed, offer the user the option of including the protocol.

Obviously, regular users have the option of copying the protocol or not, so this is just for Slingbox users who don't have any control over how the binary files are formatted.

Your suggested syntax for the size limits is totally fine with me, so I'll go ahead and add something to the Slingbox RDFs. We can also use these same controls for any other remotes that have size limitations. For the Slingbox, when I specify the size limit, do you want it to be to total size of the data that gets written to the binary file, or just the upgrade portion of the data (ie, minus the first 4 bytes)?

Posted: **Thu Sep 15, 2005 10:59 am**

gfb107 wrote:

Code: Select all

MaxDeviceUpgradeLength=<maximum size (bytes) for a device upgrade>
MaxProtocolUpgradeLength=<maximum size (bytes) for a protocol upgrade>
MaxCombinedUpgradeLength=<maximum size (bytes) for the device and protocol upgrades combined>

Greg, we already have

Code: Select all

MaxProtocolLength=<maximum size (bytes) for a protocol upgrade>

defined in current RDFs, and I had suggested previously that we use

Code: Select all

MaxUpgradeLength=<maximum size (bytes) for a device upgrade>

so maybe we could add the third item as you suggested

Code: Select all

MaxCombinedUpgradeLength=<maximum size (bytes) for the device and protocol upgrades combined>

Posted: **Fri Sep 16, 2005 9:35 am**

I haven't fully diagnosed how the $016C protocol works yet, but I tried learning some signals from it and DecodeIR recognises them as "Dreambox" with a device code of 18 and a sub-device code of 0. So, I have put a quick protocols.ini entry together that reflects those values. There are 3 bytes of fixed data before the device code byte, so for now I'm calling them "OEM" codes, I'll correct that later when I know what those values do.

[EDIT:] it's the same protocol used by the Fireball FCS discussed here...
https://www.hifi-remote.com/forums/viewtopic.php?t=3332

Here's the entry...

Code: Select all

[Dreambox] 
PID=01 6C 
DevParms=Device=18,OEM Dev1=6,OEM Dev2=15,OEM Dev3=68
DeviceTranslator=Translator(1,8,0) \
                 Translator(2,8,8) \
                 Translator(3,8,16) \
                 Translator(0,8,24)
FixedData=06 0F 44 12
CmdParms=OBC=0,Sub Device=0
CmdTranslator=Translator(1,8,0) Translator(0,8,8)
CmdIndex=1
DefaultCmd=00 00
Code.S3C80=43 8b 42 8b 05 00 00 6a 01 67 e4 07 09 e4 08 0a \ 
e4 03 07 e4 04 08 f0 08 56 08 0f f6 ff 90 f6 ff \ 
2f fb 0b 46 08 80 f6 ff 90 f6 ff 2f 7b fb af 28 \ 
03 f6 ff 68 28 04 f6 ff 68 28 05 f6 ff 68 28 06 \ 
f6 ff 88 c6 f8 19 64 f6 01 58 28 07 f6 ff 68 28 \ 
08 f6 ff 68 28 09 f6 ff 68 28 0a f6 ff 88 c6 f8 \ 
9b 47 f6 01 58 8d 01 0a 48 c2 f0 c2 f6 ff 74 28 \ 
c4 8d ff 74 1c 12 f6 01 4c 56 c2 0f 6b 09 c6 f8 \ 
00 3f f6 01 58 2a f7 af f6 ff 68 1c 12 8d 01 4c \ 
08 07 f0 c0 18 08 f6 ff b0 18 09 f6 ff b0 18 0a \ 
f6 ff b0 60 c0 0e 56 c0 0f 56 07 f0 44 c0 07 af \ 
28 c1 f0 c1 02 12 02 01 af

Posted: **Fri Sep 23, 2005 8:38 am**

I'm now working on adding support for MaxUpgradeLength, MaxProtocolLength and MaxCombinedUpgradeLength.

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.

Posted: **Fri Sep 23, 2005 11:07 am**

If you're talking about the MaxCombinedUpgradeLength variable for the Slingbox, it should include everything that goes in the binary file.

If you're talking about the MaxUpgradeLength and MaxProtocolLength variables for normal remotes, the setup code hex and pid hex are not part of regular upgrades, so my guess is that they should not be included.

However, when you create a device specific upgrade for the "Mits 740" remotes, the setup code hex is part of the complete upgrade (the format of these upgrades is very similar to the Slingbox format). I don't know if the size limits as currently defined include those bytes or not.

JP1 Remotes

Adding Slingbox support to RM