JP1 Remotes

Posted: **Sat Apr 19, 2014 11:28 am**

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?

Posted: **Sat Apr 19, 2014 11:32 am**

Hi Graham,

No - I created them in RMIR - however they were from maybe Alpha2.

Would you like me to delete them and recreate them?

xnappo
(Chris

)

Posted: **Sat Apr 19, 2014 11:48 am**

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.)

Posted: **Sat Apr 19, 2014 11:58 am**

Yes - I didn't mean to - but started editing a downloaded image and it worked so I kept going with it.

Chris (*cough*)

Posted: **Sat Apr 19, 2014 12:09 pm**

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

.

Posted: **Sat Apr 19, 2014 12:12 pm**

Thanks Graham - and no problem - I have almost typed Greg several times

Any comment on the keygroup/macro thing? Should that have worked? Again having a macro on the XBMC power button, then expecting that if I assign XBMC as the power group for all activities the macro should be executed?

Chris

Posted: **Sun Apr 20, 2014 6:27 am**

xnappo wrote:Any comment on the keygroup/macro thing? Should that have worked?

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 says

Only remaining problem with the URC-7960 is the fact that macros don't work in activity mode.

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.

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.

Posted: **Sun Apr 20, 2014 7:16 am**

Thanks Graham - just wanted to be sure to report all the problems I saw as my duty as a tester

Obviously it works fine as is - and not like I am going to run out of memory on these things!

Chris

Posted: **Mon Apr 21, 2014 12:43 am**

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.

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.

Posted: **Sun Apr 27, 2014 12:31 pm**

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.

Posted: **Sun Apr 27, 2014 11:31 pm**

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.

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

Posted: **Mon Apr 28, 2014 2:12 am**

3FG wrote: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.

Sorry about that. I'll look into it.

Posted: **Mon Apr 28, 2014 4:31 am**

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.]

Posted: **Mon Apr 28, 2014 12:26 pm**

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?

Posted: **Mon Apr 28, 2014 1:08 pm**

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?

No - not yet resolved. I just modified the RDF to a :2 variant which does not exist in protocols.ini.

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?

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).

I still need to try on another computer.

xnappo

JP1 Remotes

RMIR Xsight Support