|
JP1 Remotes
|
View previous topic :: View next topic |
Author |
Message |
mathdon Expert
Joined: 22 Jul 2008 Posts: 4530 Location: Cambridge, UK |
Posted: Fri Mar 06, 2015 11:05 am Post subject: |
|
|
ElizabethD wrote: | Yes, it is the X-Shift issue. I changed the first one to $C0, deleted second one and all is well now with the ext3.02 Atlas and I suppose all the other remotes with that extender. |
Thanks, Liz, for that confirmation. I have replaced the entry XShift=$40 by XShift=$C0 in the 26 JP1.3 extender RDFs that included it, and have deleted the duplicate entry in the 8 of these that had it twice. I have posted these corrections in the SVN and they will be in the next build of Alpha 28. _________________ Graham |
|
Back to top |
|
|
ruidosobruce
Joined: 04 Jan 2015 Posts: 91 Location: New Mexico |
Posted: Fri Mar 06, 2015 11:33 am Post subject: |
|
|
Graham
The 258203 (URC-8820BC1.3).rdf distributed with build 14 of Alpha 28 does not invoke the DSM Special Protocol, so RMIR doesn't have that tab, and it mis-handles DSM segments, treating them as Macros.
Code: | SpecialProtocols
DSM=Internal:0 | Thanks,
Bruce |
|
Back to top |
|
|
mathdon Expert
Joined: 22 Jul 2008 Posts: 4530 Location: Cambridge, UK |
Posted: Fri Mar 06, 2015 11:54 am Post subject: |
|
|
Thanks, Bruce. I had already spotted this further addition and it is now done, again for the next build. See my latest posts in this thread. _________________ Graham |
|
Back to top |
|
|
mathdon Expert
Joined: 22 Jul 2008 Posts: 4530 Location: Cambridge, UK |
Posted: Sun Mar 08, 2015 9:57 am Post subject: |
|
|
Liz and Bruce, build 16 of RMIR v2.03 Alpha 28 is now available and includes the corrections mentioned above. _________________ Graham |
|
Back to top |
|
|
ElizabethD Advanced Member
Joined: 09 Feb 2004 Posts: 2348
|
Posted: Mon Mar 09, 2015 10:40 pm Post subject: |
|
|
Graham,
build 14-16 look good. RMIR should be RC by now
Baseline feature seems to be great. I used it only once or twice in IR. And this one with the colors is even nicer.
Delete adjacent keymoves and delete device+handle orphans are wonderful.
There might be a slight issue with display of EFCs for 6131-extended.
I deleted a Panasonic combo device and told RMIR to keep the orphans.
And now the orphans have long numbers, such as 60927, 60867, etc. in the EFC/Function Name column.
They match the efc-5 values in KM, but when I click Device Upgrade or when I use just RM, only efc-3 numbers show.
I don't care, but wondered if it's supposed to be like that since 6131-extended uses the 5 digit efc (which was the reason, ages ago, why you could never convert a standard upgrade to extender).
Edit:
Graham,
False alarm. I goofed big time.
It's the other way around. Unextended 6131 used efc-5. Mike built the extender for efc-3.
In KM you can switch. In RM/RMIR I don't see that option. Nor that I care, since never used EFCs. _________________ Liz
Tweeking 8910, HTPro/9811, C7-7800, 6131o, 6131n, AtlasOCAP-1056B01, RCA-RCRP05B and enjoying the ride |
|
Back to top |
|
|
mathdon Expert
Joined: 22 Jul 2008 Posts: 4530 Location: Cambridge, UK |
Posted: Tue Mar 10, 2015 1:03 pm Post subject: |
|
|
ElizabethD wrote: | I deleted a Panasonic combo device and told RMIR to keep the orphans.
And now the orphans have long numbers, such as 60927, 60867, etc. in the EFC/Function Name column.
They match the efc-5 values in KM, but when I click Device Upgrade or when I use just RM, only efc-3 numbers show. |
The unextended URC-6131 stored keymove data as EFC-3 values, which prevented it from supporting keymoves with 2-byte commands, even with JP1 tools. Bill's extender changed it to store keymove data as raw command hex. This was, in fact, an earlier format used by UEI which allowed keymoves with 2-byte commands to be created with JP1 tools, even though they could not be created from the keypad. Both these formats pre-dated UEI's invention of 5-digit EFCs, so there was in fact no valid EFC for these two-byte commands. What IR.exe and RMIR displayed as the EFC was the EFC representing just the second of the two command bytes.
RMIR still does this in the EFC-3 column of RM and the function tab of the device upgrade editor even though it does not properly represent the full 2-byte command. If the RDF for the remote has the entry "EFCDigits=5" in the [General] section, it also displays the EFC-5 value that does represent the full command.
The Key Moves tab of RMIR behaves slightly differently for remotes that store keymove data as raw hex. It works from knowledge of the keymove format, and the format used by the URC-6131 extender is that used by remotes with 3-digit EFCs. So when there is a 1-byte command, the Name/Function/EFC column (when displaying an EFC) displays the 3-digit one. For a two-byte command it displays the only truly valid EFC, the 5-digit one. So the column may finish up displaying a mixture of both 3-digit and 5-digit values but they all properly represent the command concerned.
If anything is wrong with all this, it is that RM and the Device Upgrade Editor should not display 3-digit EFCs for 2-byte commands, but as this goes right back to the start of RM I think it hallowed by use and should not be messed with. Should the URC-6131 extenders also show the EFC-5 column? Possibly. This is easily done. Adding the entry "EFCDigits=5" in the RDF will achieve this and will not have any effect on anything else. Is it worth changing the RDFs for all Bill's extenders to do this? Personally I doubt it, as it would still leave unextended remotes with this storage format displaying only EFC-3 values. Those EFC-5 values can't be used in those remotes (or Bill's extenders) and they will be displayed if the choice of remote in RM is changed to one that does use 5-digit EFCs.
So, Liz, it is a long and complicated story. I hope this provides at least some clarification.
Edit: In reply to your edit, I don't think you goofed. I think you were right first time. _________________ Graham |
|
Back to top |
|
|
ElizabethD Advanced Member
Joined: 09 Feb 2004 Posts: 2348
|
Posted: Tue Mar 10, 2015 11:16 pm Post subject: |
|
|
1. 6131 unextended keymoves. I tried reading old, old, threads and got the final (edit2) impression that's likely wrong. "New keymoves", "Old keymoves", yikes.
Thank you so much for this long description. I'm sure you speak the truth.
2. RM: minor GUI issue on the Setup tab. Protocol notes section is huge. Could it be made smaller and get a scrollbar in case a novel is written there.
The reason is that the parameters section above is too short. I bumped into it playing with a Pioneer Mix device and had to scroll all the time to see the fixed bytes. Inconvenient. Especially when the parameter names mean nothing to me. _________________ Liz
Tweeking 8910, HTPro/9811, C7-7800, 6131o, 6131n, AtlasOCAP-1056B01, RCA-RCRP05B and enjoying the ride |
|
Back to top |
|
|
mathdon Expert
Joined: 22 Jul 2008 Posts: 4530 Location: Cambridge, UK |
Posted: Wed Mar 11, 2015 10:38 am Post subject: |
|
|
ElizabethD wrote: | 2. RM: minor GUI issue on the Setup tab. Protocol notes section is huge. Could it be made smaller and get a scrollbar in case a novel is written there.
The reason is that the parameters section above is too short. I bumped into it playing with a Pioneer Mix device |
It is the size of the Protocol Parameters section that is calculated, and Protocol Notes just fills the spare space. My investigations show that the Protocol Parameters section can only be too short for the Pioneer Mix protocol if either the Alternate PID field is showing (which depends on your setup) or the Preserve field is showing (turned on from the Options menu). I presume at least one of these applies in your case. Each of them reduces the maximum number of fields in the Protocol Parameters panel by one, and Pioneer Mix needs the unreduced maximum number of fields (which is 7).
I suspect these reductions date from the time when screen resolutions tended to be smaller. I should remember, as the Alternate PID and Preserve fields date from my time maintaining RMIR, but I don't remember. However, I see no reason to keep these reductions occurring, so I have removed them in the jar file of Alpha 28 build 17.
Please replace the jar file in build 16 with this one and let me know if it solves your problem. If so, I will leave it like that until someone else complains that they can't see the Protocol Notes . _________________ Graham |
|
Back to top |
|
|
ElizabethD Advanced Member
Joined: 09 Feb 2004 Posts: 2348
|
Posted: Wed Mar 11, 2015 2:51 pm Post subject: |
|
|
Build 17
Nice and much more convenient, many thanks
Alt PID and Preserve field were not showing yesterday, nor are they now.
How did you determine that 7 is the max number of parameters?
I tried to find something like that myself, looked at protocols.ini for P-Mix, and several other, gasped, and that was that. _________________ Liz
Tweeking 8910, HTPro/9811, C7-7800, 6131o, 6131n, AtlasOCAP-1056B01, RCA-RCRP05B and enjoying the ride |
|
Back to top |
|
|
mathdon Expert
Joined: 22 Jul 2008 Posts: 4530 Location: Cambridge, UK |
Posted: Wed Mar 11, 2015 5:47 pm Post subject: |
|
|
ElizabethD wrote: | How did you determine that 7 is the max number of parameters? |
I don't know that there are not protocols with more than 6 parameters (plus the FixedData field making 7). What I meant is that the code for the setup page creates a Protocol Parameters section with space for 7 parameter fields - with a scroll bar appearing if there are more than 7. Previously this number was reduced if either the Alternate PID or Preserve fields were showing, but in build 17 it remains at 7.
The required space is carefully calculated, so if you had fewer than 7 fields showing without either Alternate PID or Preserve fields showing, then I don't understand it. If you are still able to reproduce that behaviour, I would be interested in a screenshot to see what was going on. But if all is now well, don't go to any trouble to try to reproduce it. _________________ Graham |
|
Back to top |
|
|
ElizabethD Advanced Member
Joined: 09 Feb 2004 Posts: 2348
|
Posted: Wed Mar 11, 2015 8:24 pm Post subject: |
|
|
I reverted to build 16, then back, so here you go, builds 16,17 composite:
http://www.hifi-remote.com/forums/dload.php?action=file&file_id=13241
it's as tall as I can make it top to bottom. Same situation with height of 700 or so. _________________ Liz
Tweeking 8910, HTPro/9811, C7-7800, 6131o, 6131n, AtlasOCAP-1056B01, RCA-RCRP05B and enjoying the ride |
|
Back to top |
|
|
mathdon Expert
Joined: 22 Jul 2008 Posts: 4530 Location: Cambridge, UK |
Posted: Tue Mar 17, 2015 1:43 pm Post subject: |
|
|
Liz, thanks for the screenshots. The one from build 16 puzzles me enormously. I have looked carefully at the code and as far as I can see, that is impossible . I won't worry about it, though, since build 17 resolved your problem.
You will see that build 18 is now posted, but you should see no difference from build 17 in Windows. The changes are primarily to assist Linux users, though there is always the possibility that something has been affected detrimentally in Windows. I am sure you will let me know if you find anything . _________________ Graham |
|
Back to top |
|
|
ElizabethD Advanced Member
Joined: 09 Feb 2004 Posts: 2348
|
Posted: Tue Mar 17, 2015 10:25 pm Post subject: |
|
|
Unrelated to build 18. Related to the first post on this page regarding X-shift.
mathdon wrote: | I have replaced the entry XShift=$40 by XShift=$C0 in the 26 JP1.3 extender RDFs that included it, and have deleted the duplicate entry in the 8 of these that had it twice. I have posted these corrections in the SVN and they will be in the next build of Alpha 28. |
26 files? throw the baby away with the water?
I hope I'm wrong in what follows.
I just got hit with a goofy keymove in Atlas config under extender 2.11 where X-shift should be $40. In fact all Atlas OCAP 1056 prior to version 3.02 (that common one) do need to keep $40 for x-shift.
I then rechecked RCA old 3A79 files prior to 3.02 - they all used $C0 for x-shift, so are OK.
I tried to be useful, but I don't know how to check quickly what needs a change back. I had to point IR back at the old directory from 2010-2011 to see what was going on.
I see 27 RDFs with March 6 2015 date. Few that I think are Bill's I compared with my old RDF files. I think that these need to RETAIN $40 for x-shift:
3A00,3A33,3A39,3E85,3F85 but I can't be sure, and that's only 10 files. _________________ Liz
Tweeking 8910, HTPro/9811, C7-7800, 6131o, 6131n, AtlasOCAP-1056B01, RCA-RCRP05B and enjoying the ride |
|
Back to top |
|
|
mathdon Expert
Joined: 22 Jul 2008 Posts: 4530 Location: Cambridge, UK |
Posted: Wed Mar 18, 2015 10:28 am Post subject: |
|
|
Thanks, Liz. There are 26 RDFs dated March 6, 2015 that are for extenders and I thought all of these were Bill's. All 26 had entries XShift=$40 and were changed to XShift=$C0. I presumed there was a systematic error as I thought all extenders that used XShift had bits 6 and 7 both set for XShifted keys. It seems that I was wrong and have made a boo-boo .
Bill's v3.02 extender release has 10 RDFs. Of those, 3 have no XShift entries and 2 have XShift=$C0. The remaining 5 had XShift=$40 and are included in the 26 that were changed to $C0. All 5 have phantom buttons that would be identified as XShifted if XShift=$40 were correct, so I presume the change of those 5 to $C0 is correct.
I have looked through the other 21 RDFs that were changed, checking the button keycodes to see which of $40 or $C0 would lead to mis-identification of buttons as XShifted and unfortunately it seems that all 21 of them really should be $40. I will change them back for the next build and will give a grovelling apology . _________________ Graham |
|
Back to top |
|
|
ElizabethD Advanced Member
Joined: 09 Feb 2004 Posts: 2348
|
Posted: Wed Mar 18, 2015 4:56 pm Post subject: |
|
|
Graham, I did some comparisons as well, and came up with 21 to rollback to build 14 state, I think, and keep 5 with the March 6 changes to $C0. _________________ Liz
Tweeking 8910, HTPro/9811, C7-7800, 6131o, 6131n, AtlasOCAP-1056B01, RCA-RCRP05B and enjoying the ride |
|
Back to top |
|
|
|
|
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
|