RMIR Xsight Support
Moderator: Moderators
Thanks Dave. There is something puzzling me in that .rmir file. The macros for all your Activities have an entry "DeviceIndex=15". If I create a new Activity and then a power macro for it with Alpha 22 Test 5, I get the value of "DeviceIndex" to be the same as the value of "KeyCode", which is what I expect to happen. I don't understand that value of 15. It doesn't make sense and I would like to get to the bottom of it. Did you create those Activity power macros in some other way?
Graham
Hi Dave
No, I think I've just found it. If I load my .rmir file into the remote, download it and then save it again as a .rmir file, the entry for my new Activity macro has changed to "DeviceIndex=15". Have you done that, is the .rmir file you sent created from a download of the remote (at any stage in its production, as once that value changes, it stays changed.)
No, I think I've just found it. If I load my .rmir file into the remote, download it and then save it again as a .rmir file, the entry for my new Activity macro has changed to "DeviceIndex=15". Have you done that, is the .rmir file you sent created from a download of the remote (at any stage in its production, as once that value changes, it stays changed.)
Graham
Thanks. I've found and fixed the bug that caused that behaviour. It probably doesn't make any difference to the operation of the remote, but it was not what I intended. It was a value 15 in the Lights macro, which was not an activity macro, that caused my earlier trouble. There it did matter. I still don't know what caused that, but the value was correct in the new file you sent so I am hoping the cause is no longer present.
If you want to correct your .rmir file, use a text editor to edit the DeviceIndex value in the macro entries. These almost immediately follow the long section of hex code. Where it is 15, change it to the same value as the KeyCode entry (which will be >= 240 for activity macros). It will stay at the new value with Test5 if you avoid doing another upload/download sequence.
Sorry, Chris. Mixing your name with mdavej
.
If you want to correct your .rmir file, use a text editor to edit the DeviceIndex value in the macro entries. These almost immediately follow the long section of hex code. Where it is 15, change it to the same value as the KeyCode entry (which will be >= 240 for activity macros). It will stay at the new value with Test5 if you avoid doing another upload/download sequence.
Sorry, Chris. Mixing your name with mdavej
.Graham
This is a question of the internal working of the remote, not of RMIR. I see no reason why macros should not operate in Activity mode, but it has been reported before that in some (possibly all?) UEI remotes with Activities, macros don't work in this mode. See for example this post which saysxnappo wrote:Any comment on the keygroup/macro thing? Should that have worked?
I presume this must be so of the Touch, also. However, it was not necessary for you to create multiple identical AllOff macros to get round this. The Device Upgrade Editor allows you to put an existing macro on to additional buttons (of any device). The right hand panel of this editor has radio buttons to choose between it showing Functions or Macros. So you only need create the macro once, for one of the buttons, and then use the editor to put the same macro on the other buttons.Only remaining problem with the URC-7960 is the fact that macros don't work in activity mode.
Doing this does not create new copies of the macro. At present, putting the same function on multiple buttons of the same device does create new copies of the function. I regard this as a defect and am working to avoid this happening.
Graham
Same, here. Tested with two different PC, desktop and notebook, with Win 8.1 64bit. I have to say that I had same issue with Windows 8.0 No problem with another notebook and Windows 7 64 bit.mdavej wrote:I have found that in Win 8.1, I can't do a full upload or download even from EZ-RC site. I think something got broken in the USB driver. All still works fine on Win 7. Doesn't sound like your issue, just FYI.
Here at last is RMIR v2.03 Alpha 22 Test 6. There are substantial changes from Test 5, so in case of problems I have left Test 5 available. The main changes are:
1. Revised handling of functions for XSight remotes. The multiple copies of certain functions, notably Discrete On and Discrete Off in Chris's setups, should have disappeared. If those .rmir files are loaded into Test 6, these functions will only occur once. These changes also resolve a number of other subtle issues with functions that I had identified, but which no-one else seems to have spotted
.
2. Because of (1) there are changes to the structure of a .rmir file for XSights (both Touch/Color and Lite/Plus) so the compatibility is only one-way. Setup files for these remotes created with Test 6 will not load properly into Test 5, so please keep them separately.
3. RDF files for XSight remotes contain entries that are incompatible with RMIR v2.02a, and both these and those for JP2 and JP3 remotes are incompatible with any earlier versions of RMIR, and probably all versions of IR.exe. Since RMIR reads all RDFs, not just the one for the remote in question, their presence in an RDF folder can cause these earlier versions to throw error messages. I have revised the RDF handling so that new RDFs for these remotes are possible that should no longer cause conflict with any earlier applications. New versions for those remotes concerned that I am aware of are included in the package. Also included are map and image files for the XSights, though these have not been changed.
4. You may note, in particular, that in remotes with a MAXQ processor there is a spurious entry in the new RDF that says Processor=S3C80. This is followed by a correct entry saying Processor+=MAXQxxx. Earlier versions and other applications will only parse the first line. This change is needed to avoid an unknown processor type causing a null pointer exception.
5. For the XSight Lite and clones there are other changes to the RDF, so the new ones MUST be used for those remotes. Both old and new ones should work for other remotes but please try the new ones.
6. There is one downside to (3), because of (4). RMIR v2.02a supports JP2 remotes, but only with the current RDFs, not the new ones.
7. A number of minor bugs that I found in my testing have been fixed.
This version has had some testing on my XSight Touch and XSight Lite but very little on any other remotes. Be aware that last-minute fixes can cause new bugs, as happened with Test 4
, so there may be major issues with it. I hope there will only be minor ones, but please report them all.
1. Revised handling of functions for XSight remotes. The multiple copies of certain functions, notably Discrete On and Discrete Off in Chris's setups, should have disappeared. If those .rmir files are loaded into Test 6, these functions will only occur once. These changes also resolve a number of other subtle issues with functions that I had identified, but which no-one else seems to have spotted
.2. Because of (1) there are changes to the structure of a .rmir file for XSights (both Touch/Color and Lite/Plus) so the compatibility is only one-way. Setup files for these remotes created with Test 6 will not load properly into Test 5, so please keep them separately.
3. RDF files for XSight remotes contain entries that are incompatible with RMIR v2.02a, and both these and those for JP2 and JP3 remotes are incompatible with any earlier versions of RMIR, and probably all versions of IR.exe. Since RMIR reads all RDFs, not just the one for the remote in question, their presence in an RDF folder can cause these earlier versions to throw error messages. I have revised the RDF handling so that new RDFs for these remotes are possible that should no longer cause conflict with any earlier applications. New versions for those remotes concerned that I am aware of are included in the package. Also included are map and image files for the XSights, though these have not been changed.
4. You may note, in particular, that in remotes with a MAXQ processor there is a spurious entry in the new RDF that says Processor=S3C80. This is followed by a correct entry saying Processor+=MAXQxxx. Earlier versions and other applications will only parse the first line. This change is needed to avoid an unknown processor type causing a null pointer exception.
5. For the XSight Lite and clones there are other changes to the RDF, so the new ones MUST be used for those remotes. Both old and new ones should work for other remotes but please try the new ones.
6. There is one downside to (3), because of (4). RMIR v2.02a supports JP2 remotes, but only with the current RDFs, not the new ones.
7. A number of minor bugs that I found in my testing have been fixed.
This version has had some testing on my XSight Touch and XSight Lite but very little on any other remotes. Be aware that last-minute fixes can cause new bugs, as happened with Test 4
, so there may be major issues with it. I hope there will only be minor ones, but please report them all.Graham
Using either the RCA RCRP05B (JP1.3) or Atlas 1056B03 (JP2), when the device upgrade editor is opened for an existing device, the button assignments are all seemingly erased, and the upgrade contains no button assignments.
For all the RDF files, protocol 006A should be 006A:4 (wrong in the unextended 1056B03 rdf, and the URC-8820BC1). Also 01A4 should be 01A4:2. I haven't checked any other PIDs.
The URC-8820BC1 now comes in two versions, both with battery stickers that say URC-8820BC1, but which have different signatures. URCSupport.com lists the earlier as Cox 8820 version 1.1 and the later one as version 1.2. Version 1.1 tried to implement some of the Simple Set concepts, and version 1.2 reverts to "look up a setup code and enter it". Excepting for signature and name, the RDF files and maps are apparently identical. So besides 253602 (URC-8820BC1), we need a second nearly identical RDF named 253701 (URC-8820BC1.2).
Here's revised protocols.ini entries for 01A4. The 01A4:2 version allows one to choose among 4 device numbers, and optionally to send a second signal with a fixed OBC.
For all the RDF files, protocol 006A should be 006A:4 (wrong in the unextended 1056B03 rdf, and the URC-8820BC1). Also 01A4 should be 01A4:2. I haven't checked any other PIDs.
The URC-8820BC1 now comes in two versions, both with battery stickers that say URC-8820BC1, but which have different signatures. URCSupport.com lists the earlier as Cox 8820 version 1.1 and the later one as version 1.2. Version 1.1 tried to implement some of the Simple Set concepts, and version 1.2 reverts to "look up a setup code and enter it". Excepting for signature and name, the RDF files and maps are apparently identical. So besides 253602 (URC-8820BC1), we need a second nearly identical RDF named 253701 (URC-8820BC1.2).
Here's revised protocols.ini entries for 01A4. The 01A4:2 version allows one to choose among 4 device numbers, and optionally to send a second signal with a fixed OBC.
Code: Select all
[Mitsubishi Alt Delay]
PID=01 A4
CmdTranslator=Translator(lsb,comp)
CmdParms=OBC=0
DevParms=Device Number
DeviceTranslator=Translator(lsb,comp)
FixedData=ff
Notes=Same as Mitsubishi, except a quarter second delay is added after every two frames.\n\
That might be useful in case ordinary Mitsubishi is doubling commands and/or ramping too \
fast in Vol, etc.
Code.S3C80=4E A2 11 8B 0E 85 40 08 08 00 96 01 B8 00 96 04 1A 68 7E A6 0D 02 EB 03 E6 0D 06 B0 0C F6 01 73 B0 C7 46 CB 40 F6 01 70 F6 FF 67 C6 F8 01 13 F6 01 58 56 CB BF F6 01 70 F6 01 67 6C 02 F6 FF 5E C6 F8 D1 EC F6 01 58 6A F4 C6 F8 3C 8C F6 01 58 F6 01 67 F6 FF 5E 44 0C 0C EB 02 8B C3 AF F6 01 0A 7B 03 46 0C 01 AF 08 D0 A4 D1 C0 7B F9 AF
Code.HCS08=20 11 28 52 11 C5 40 08 08 00 95 01 CC 00 95 04 2E 68 F6 CD FF 5F CD FF 5F C6 01 11 4C 4C C7 01 11 45 FF DC CD FF 74 45 FF DC CD FF 74 CD FF 92 25 E1 81
[Mitsubishi Alt Delay]
PID=01 A4
VariantName=2
DevParms=Dev1=71, Dev2=255, Dev3=255, Dev4=255, 2nd OBC=39
DeviceTranslator=Translator(lsb,comp,0,8,0) Translator(lsb,comp,1,8,8) Translator(lsb,comp,2,8,16) Translator(lsb,comp,3,8,24) Translator(lsb,comp,4,8,32)
FixedData=1D 00 00 00 1B
CmdParms= Dev:0|1|2|3, OBC=0, OBC2 :None|Send=0
CmdParmInit=PickInitializer(0,0,1,2,3)
CmdTranslator=Translator(lsb,comp,1) Translator(2,1,8) Translator(0,2,14)
DefaultCmd=00 00
Notes=Same as Mitsubishi, except a quarter second delay is added after every two frames, and commands can be sent with 2 signals.\n\
The second signal has fixed OBC2, and seems to be used for Vol+/- and Ch+/-
Code.S3C80=4E A2 52 8B 0E C5 40 08 08 00 96 01 B8 00 96 04 1A 69 00 A6 0D 02 EB 03 E6 0D 06 08 09 68 C0 56 C0 03 87 10 03 19 03 B0 0C F6 01 73 77 F1 B0 C7 77 BD F6 01 70 F6 FF 83 77 BC F6 01 70 F6 01 67 5C 02 C6 F8 D1 C4 F6 01 58 F6 FF 7A 37 6E 05 44 0C 0C EB 18 5A EC C6 F8 3A 7F F6 01 58 F6 01 67 F6 FF 7A 44 0C 0C 6B C6 37 6F 01 AF E4 07 08 B0 C7 77 BD F6 01 46 F6 01 46 AF F6 01 0A 7B 03 46 0C 01 AF 08 D0 A4 D1 C0 7B F9 AF
Code.HCS08=20 11 28 52 52 C5 40 08 08 00 95 01 CC 00 95 04 2E 68 F6 B6 B2 A1 02 26 03 6E 06 B2 B6 66 B7 56 A4 03 97 8C E6 60 B7 60 3F 69 CD FF 86 1D AB 1C A2 CD FF 62 CD FF 56 1D A2 CD FF 62 6E 02 55 AD 3B 0F 56 03 00 69 20 45 D1 60 CD FF 74 3B 55 EF 45 3C 8C CD FF 74 45 00 01 CD FF 74 11 25 AD 1C 01 69 CA 0E 56 01 81 4E 64 65 1D AB 1C A2 45 00 01 CD FF 74 11 25 CD FF 5F CC FF 5F CD FF 92 25 02 10 69 81
Code.MAXQ610=3B 7A 52 10 0A 00 1E 00 0A 00 46 00 F2 06 0A 00 41 06 28 20 00 80 08 16 D7 D6 03 53 D0 D0 D7 E2 04 22 70 75 0C 56 0C BA 01 16 BA BA FE 5A 1D 00 00 E3 08 82 80 70 75 08 5A 0D 00 00 30 94 C3 0A E3 04 02 01 70 74 08 55 08 D6 80 15 BB BB 01 33
Test 6 now updated to RMIR v2.03 Alpha 22 Test 7, which should have fixed the bug with the Device Editor.
The Device Editor works with a copy of the upgrade and a bug crept into the part of the copy process dealing with copying button assignments when I updated it to deal with the new function handling for XSights.
[Edit: This doesn't deal with the changes to RDFs and protocols.ini advised by 3FG, due to lack of time at the moment. I've done this bugfix as a matter of urgency.]
The Device Editor works with a copy of the upgrade and a bug crept into the part of the copy process dealing with copying button assignments when I updated it to deal with the new function handling for XSights.
[Edit: This doesn't deal with the changes to RDFs and protocols.ini advised by 3FG, due to lack of time at the moment. I've done this bugfix as a matter of urgency.]
Graham
I have amended the Protocol sections of the RDFs according to 3FG's proposed changes, and have also made his change to protocols.ini. These will be in the next Test version. However, there is at least one other protocol that has already caused confusion for the Touch, the Lutron protocol (PID=00E7) as reported by xnappo. I should like to resolve this one also.
Chris, has this been resolved, and if so what should the RDF entry be? Protocol 00E7 in the Touch has 4 fixed and 2 variable bytes while that in protocols.ini has 2 fixed and 2 variable, so they are certainly not the same. Is there a proposed protocols.ini entry for the 4 fixed, 2 variable version?
You were also having an issue with getting spurious signature mismatch messages. Have these disappeared since you did a factory reset on your Touch, or is it still an issue? If so, have you been able to identify the circumstances in which it occurs?
Chris, has this been resolved, and if so what should the RDF entry be? Protocol 00E7 in the Touch has 4 fixed and 2 variable bytes while that in protocols.ini has 2 fixed and 2 variable, so they are certainly not the same. Is there a proposed protocols.ini entry for the 4 fixed, 2 variable version?
You were also having an issue with getting spurious signature mismatch messages. Have these disappeared since you did a factory reset on your Touch, or is it still an issue? If so, have you been able to identify the circumstances in which it occurs?
Graham
No - not yet resolved. I just modified the RDF to a :2 variant which does not exist in protocols.ini.mathdon wrote: Chris, has this been resolved, and if so what should the RDF entry be? Protocol 00E7 in the Touch has 4 fixed and 2 variable bytes while that in protocols.ini has 2 fixed and 2 variable, so they are certainly not the same. Is there a proposed protocols.ini entry for the 4 fixed, 2 variable version?
Yes - this still happens. My only guess is it is something to do with USB going into low power mode or something. If it starts happening, I can make it go away by downloading from the remote. Then the next write to the remote works fine (loading back a .rmir file).You were also having an issue with getting spurious signature mismatch messages. Have these disappeared since you did a factory reset on your Touch, or is it still an issue? If so, have you been able to identify the circumstances in which it occurs?
I still need to try on another computer.
xnappo