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

RMIR: Prototype IR function in RM
Goto page Previous  1, 2, 3 ... 56, 57, 58, 59  Next
 
Post new topic   Reply to topic    JP1 Remotes Forum Index -> JP1 - Software
View previous topic :: View next topic  
Author Message
mathdon
Expert


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

PostPosted: Fri Mar 06, 2015 11:05 am    Post subject: Reply with quote

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
View user's profile Send private message
ruidosobruce



Joined: 04 Jan 2015
Posts: 91
Location: New Mexico

PostPosted: Fri Mar 06, 2015 11:33 am    Post subject: Reply with quote

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
View user's profile Send private message
mathdon
Expert


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

PostPosted: Fri Mar 06, 2015 11:54 am    Post subject: Reply with quote

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
View user's profile Send private message
mathdon
Expert


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

PostPosted: Sun Mar 08, 2015 9:57 am    Post subject: Reply with quote

Liz and Bruce, build 16 of RMIR v2.03 Alpha 28 is now available and includes the corrections mentioned above.
_________________
Graham
Back to top
View user's profile Send private message
ElizabethD
Advanced Member


Joined: 09 Feb 2004
Posts: 2269

PostPosted: Mon Mar 09, 2015 10:40 pm    Post subject: Reply with quote

Graham,
build 14-16 look good. RMIR should be RC by now Smile
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 Smile
Back to top
View user's profile Send private message
mathdon
Expert


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

PostPosted: Tue Mar 10, 2015 1:03 pm    Post subject: Reply with quote

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
View user's profile Send private message
ElizabethD
Advanced Member


Joined: 09 Feb 2004
Posts: 2269

PostPosted: Tue Mar 10, 2015 11:16 pm    Post subject: Reply with quote

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 Smile
Back to top
View user's profile Send private message
mathdon
Expert


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

PostPosted: Wed Mar 11, 2015 10:38 am    Post subject: Reply with quote

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 Smile .
_________________
Graham
Back to top
View user's profile Send private message
ElizabethD
Advanced Member


Joined: 09 Feb 2004
Posts: 2269

PostPosted: Wed Mar 11, 2015 2:51 pm    Post subject: Reply with quote

Build 17
Nice and much more convenient, many thanks Smile
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 Smile
Back to top
View user's profile Send private message
mathdon
Expert


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

PostPosted: Wed Mar 11, 2015 5:47 pm    Post subject: Reply with quote

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
View user's profile Send private message
ElizabethD
Advanced Member


Joined: 09 Feb 2004
Posts: 2269

PostPosted: Wed Mar 11, 2015 8:24 pm    Post subject: Reply with quote

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 Smile
Back to top
View user's profile Send private message
mathdon
Expert


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

PostPosted: Tue Mar 17, 2015 1:43 pm    Post subject: Reply with quote

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 Rolling Eyes . 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 Smile .
_________________
Graham
Back to top
View user's profile Send private message
ElizabethD
Advanced Member


Joined: 09 Feb 2004
Posts: 2269

PostPosted: Tue Mar 17, 2015 10:25 pm    Post subject: Reply with quote

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 Smile
Back to top
View user's profile Send private message
mathdon
Expert


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

PostPosted: Wed Mar 18, 2015 10:28 am    Post subject: Reply with quote

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

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 Embarassed.
_________________
Graham
Back to top
View user's profile Send private message
ElizabethD
Advanced Member


Joined: 09 Feb 2004
Posts: 2269

PostPosted: Wed Mar 18, 2015 4:56 pm    Post subject: Reply with quote

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 Smile
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
Goto page Previous  1, 2, 3 ... 56, 57, 58, 59  Next
Page 57 of 59

 
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
Get Smart! the band's official homepage Rockabilly Central