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

RM import of Slingbox bin issue

 
Post new topic   Reply to topic    JP1 Remotes Forum Index -> JP1 - Software
View previous topic :: View next topic  
Author Message
The Robman
Site Owner


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

                    
PostPosted: Mon Feb 05, 2018 6:43 pm    Post subject: RM import of Slingbox bin issue Reply with quote

Graham,
If you take a look at the following thread, you will see that bin files that use the MCE protocol show up as RC6-6-32 if the bin file is imported into RM.

http://www.hifi-remote.com/forums/viewtopic.php?t=101151

Quoting from RM itself (well, protocols.ini), here is how MCE can be identified:

MCE is a form of RC6-6-32 The correspondence between fields of MCE and fields of RC6-M-32 is: . The RC6 M value is 6 because the protocol is RC6-6-32 . The RC6 Toggle bit is always zero in MCE . The RC6 Device is the OEM1 field of MCE, which always has the value 128 . The RC6 Subdevice is the MCE Device plus 256 times the OEM2 plus 128 times the MCE toggle bit for example in Microsoft MCE, device is 4 and OEM2 is 15, so the RC6-6-32 device is 128 and subdevice is 4+256*15+(either 128 or 0) = either 3844 or 3972 The MCE toggle bit actively toggles when this protocol is used, so you do not need the Windows registry change that disables debounce (to work with learned signals in which the toggle bit isn't active). The RC6 toggle bit is a different bit than the MCE toggle bit. The RC6 toggle bit is always zero in MCE signals.
_________________
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
mathdon
Expert


Joined: 22 Jul 2008
Posts: 4515
Location: Cambridge, UK

                    
PostPosted: Tue Feb 06, 2018 2:15 pm    Post subject: Reply with quote

Rob, I don't see a solution to this. The info that RM has is just the PID and the fixed data. Both MCE and RC6-6-32 have the same PID, and indeed the same executor. Not all RC6-6-32 fixed data values are also possible MCE fixed data values, so where this is not so, the protocol is definitely RC6-6-32. But in the Slingbox in question the fixed data values are possible for both protocols. In protocols.ini, the default device parameters for both protocols correspond to the same set of fixed data, so it isn't even possible to distinguish the two when the upgrade uses default fixed values, and in this case it does not.

RMIR has code that tries to identify the intended protocol where two protocols have the same PID and executor and the upgrade has fixed values that are possible for both. However, it relies on the default device parameters corresponding to different sets of fixed data. It works in the cases for which it was originally devised, in the early days of RMIR. For the MCE versus RC6-6-32 situation it will identify MCE only if the device parameters are precisely the default values given in protocols.ini. In this case they are not - the defaults are 4, 15 while in this upgrade they are the very different values 38, 80.

If all cases where the fixed data is compatible with both protocols were actually MCE, I could incorporate that into RM as a special case. I don't like special cases, but it would be possible. This is when the 2nd fixed data byte is 0x80, or equivalently the RC6-6-32 Device parameter is 128. But since protocols.ini says that is the default value for the Device parameter, even that seems to be ruled out.
_________________
Graham
Back to top
View user's profile Send private message
mathdon
Expert


Joined: 22 Jul 2008
Posts: 4515
Location: Cambridge, UK

                    
PostPosted: Tue Feb 06, 2018 6:35 pm    Post subject: Reply with quote

Rob, here is a work-around for the user concerned. Copy the file MCE38-80.prot to the AddOns subfolder of the RMIR installation folder. That subfolder should already exist - if it doesn't then RMIR needs upgrading to the latest version. This file effectively changes the default device parameters for MCE in protocols.ini without actually changing protocols.ini itself. As the new defaults are the values used in the bin file, the protocol will be recognised as MCE.
_________________
Graham
Back to top
View user's profile Send private message
The Robman
Site Owner


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

                    
PostPosted: Tue Feb 06, 2018 6:38 pm    Post subject: Reply with quote

I will look into it closer, I thought the file was using the MCE values.

If you select MCE as your protocol, are there any values that are hard coded behind the scenes, which might be variable if you select the RC6 version?

I know that I experimented by creating a bin file using MCE and then, when I tried re-importing it, it switched back to RC6.
_________________
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
mathdon
Expert


Joined: 22 Jul 2008
Posts: 4515
Location: Cambridge, UK

                    
PostPosted: Wed Feb 07, 2018 6:19 am    Post subject: Reply with quote

The more I look at this, the more it seems to be a non-issue. The PID is the same, the executors are the same, the code translators are the same. Both have four fixed bytes. The first is invariable at 0xE2. The third and fourth are freely variable except that the top bit of the fourth is 0. The difference lies in the second one. For MCE this is fixed at 0x80, for RC-6-6-32 it is freely variable and given by the Device parameter whose default it 128, i.e. 0x80 again.

Both protocols have two device parameters. For MCE they are Device (=4th fixed byte) and OEM2 (=3rd fixed byte). For RC6-6-32 they are Device (=2nd fixed byte) and Sub-Device (=4th fixed byte + 256*3rd fixed byte). So the only difference the user will see, when an MCE protocol is represented as RC6-6-32, is the value of the two device parameters. To force RM to show the protocol as MCE when the device parameters are other than their default values (Device=4, OEM2=15), copy the .prot file I posted yesterday into the AddOns folder after editing the MCE default values for the device parameters to be those of the upgrade concerned. Or, of course, edit protocols.ini in this way but the whole point of the recently introduced .prot files is to allow customisation of protocols.ini without actually editing it. When upgrading to a new version of RMIR, just copy the AddOns folder from old to new version.

BTW I have no idea where the RC6-6-32 and similar protocols come from, nor the mapping between the fixed bytes and device parameters or the default values for those parameters. It just seems weird to me that there are two protocols in protocols.ini which are identical in all respects when their device parameters take their default values (the RC6-6-32 defaults of Device=128, Sub-Device=3844 (=4 + 256*15) correspond exactly to the MCE defaults). It cannot be a surprise that RM gets confused in such circumstances.
_________________
Graham
Back to top
View user's profile Send private message
The Robman
Site Owner


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

                    
PostPosted: Wed Feb 07, 2018 1:07 pm    Post subject: Reply with quote

If they're so similar, is there a way to prioritize MCE over RC6 so that RM picks that one?
_________________
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
mathdon
Expert


Joined: 22 Jul 2008
Posts: 4515
Location: Cambridge, UK

                    
PostPosted: Wed Feb 07, 2018 1:40 pm    Post subject: Reply with quote

The Robman wrote:
If they're so similar, is there a way to prioritize MCE over RC6 so that RM picks that one?

I can write it in as a special case, in the code that attempts to resolve such ambiguities. A device upgrade that specifies RC6-6-32 and uses the device parameters specified as defaults in protocols.ini will then show as MCE, which is weird, but I can do it. It suggests to me, though, that the default values for RC6-6-32 should be changed to something that is not also interpretable as MCE and I have no idea what that should be. I am not a protocol expert and as I said before, I have no idea what RC6-6-32 is used for when it is not MCE. Perhaps nothing at all? Is it a legacy entry in protocols.ini that was really superseded by MCE? Do you want me to make this prioritization in the next build?
_________________
Graham
Back to top
View user's profile Send private message
The Robman
Site Owner


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

                    
PostPosted: Wed Feb 07, 2018 11:20 pm    Post subject: Reply with quote

I don't think it's something that you should put too much effort into, as it's not that important. I don't think it warrants special code, but it might be worth a tweak to 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
3FG
Expert


Joined: 19 May 2009
Posts: 3365

                    
PostPosted: Thu Feb 08, 2018 1:22 am    Post subject: Reply with quote

There's a couple of issues here, and neither involve changing RM or RMIR.

1. There are two variants of PID 012A. In general, any JP1.2 or new remote carries 012A:2 if it has 012A at all. As it happens the Slingbox PL has 012A:2 while the RV version has no 012A exectutor. So the RV version needs the 012A:2 protocol to be included in the bin file (012A:2 is shorter than plain 012A), which wouldn't be a problem except:

2. Protocols.ini has incomplete entries for both MCE and RC6-M-32. Both versions of PID 012A can send either MCE or RC6-M-32 signals by specifying the correct bit(s) in the fixed data. This has been done correctly for 012A:2 RC6-M-32 but only for HCS08 processors. That entry allows one to specify whether the T bit is toggled, or always set to 0 or 1; it also allows one to specify if the toggle bit is in the MCE or RC6 location. We need to add the executor code for S3C80, MAXQ and 2541 processors to this entry. The 012A:2 MCE entry sets the fixed data automatically to shoot MCE, so it should be simpler for the user. Except--it is missing the S3C80 executor code.

The 012A executor (4 bytes of fixed data) is less flexible, but it can select between MCE and RC6 by fixed data. The protocols.ini entry does have S3C80 code, so in the linked thread the RV bin file has the plain 012A executor code, while the PL file refers to the built-in 012A:2 executor.

I'll try to work on editing protocols.ini this weekend. I expect to add executor code to the 012A:2 entries, and to remove the S3C80 code from 012A, so that in future the shorter executor is built into RV bin files. The 012A entry for RC6-M-32 also needs a way to select RC6 versus MCE.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic       JP1 Remotes Forum Index -> JP1 - Software 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