RCA RCRP05B Extender
Moderator: Moderators
-
unclemiltie
- Expert
- Posts: 1819
- Joined: Wed Jan 21, 2004 12:50 pm
- Location: Pittsburgh, PA
RCA RCRP05B Extender
This topic is for availability of the current extender for the RCA RCRP05B JP1.3 remote. This base topic will be updated to reflect the most current version of the remote as well as its availability.
Edit: 3/8/11 - Updated to version 1.01
download link removed for V1.01
Edit: 4/11/11 - update to version 1.03
fixes bug that ignores set_menu command and bug that won't allow any key with value over $3F to work (DVR key on this remote) unless there is a macro or key move on it.
Edit: 4/12/11 - update to version 1.04
fix bug in LDKP processing for all JP1.3 extenders
Edit: 11/4/11 - update to version 1.05
fix bug introduced in 1.03 cloaking fix
http://www.hifi-remote.com/forums/dload ... e_id=10079
merging with Extinstall in IR will erase your setup codes and will add extra "default" macros. This is a bug in Extinstall. Please remove the extra macros on the device buttons and re-enter your setup codes after merging.
Edit: 3/8/11 - Updated to version 1.01
download link removed for V1.01
Edit: 4/11/11 - update to version 1.03
fixes bug that ignores set_menu command and bug that won't allow any key with value over $3F to work (DVR key on this remote) unless there is a macro or key move on it.
Edit: 4/12/11 - update to version 1.04
fix bug in LDKP processing for all JP1.3 extenders
Edit: 11/4/11 - update to version 1.05
fix bug introduced in 1.03 cloaking fix
http://www.hifi-remote.com/forums/dload ... e_id=10079
merging with Extinstall in IR will erase your setup codes and will add extra "default" macros. This is a bug in Extinstall. Please remove the extra macros on the device buttons and re-enter your setup codes after merging.
Last edited by unclemiltie on Fri Nov 04, 2011 10:43 pm, edited 6 times in total.
this JP1 stuff is a sickness!
-
unclemiltie
- Expert
- Posts: 1819
- Joined: Wed Jan 21, 2004 12:50 pm
- Location: Pittsburgh, PA
Version 1.0 of the extender is the first version for this remote. Many thanks to the beta testers who provided great feedback as well as some suggestions for enhancements to the extender.
Specifically, I'd like to thank:
VickyG for her thoughts around flashing the LED's for the phantom devices
ElizabethD for her suggestion to take that one step further and flash the phantom devices twice and the real devices once
mdavej for his work in chasing down a couple of bugs in the RDF
-bill
Specifically, I'd like to thank:
VickyG for her thoughts around flashing the LED's for the phantom devices
ElizabethD for her suggestion to take that one step further and flash the phantom devices twice and the real devices once
mdavej for his work in chasing down a couple of bugs in the RDF
-bill
this JP1 stuff is a sickness!
-
ElizabethD
- Advanced Member
- Posts: 2348
- Joined: Mon Feb 09, 2004 12:07 pm
A fix is needed in the readme file.
Readme says
http://www.hifi-remote.com/forums/viewt ... 5691#95691
In the beta version it was AUD, but is back on DVR.
One other thing - readme does not describe when/how to use the .IR file in the v1.0 distribution. Bill will likely write about it. Most likely is for starting extender mode from scratch.
Readme says
It actually flashes DVR, as described here:"dev6 flashes the AUD button"
http://www.hifi-remote.com/forums/viewt ... 5691#95691
In the beta version it was AUD, but is back on DVR.
One other thing - readme does not describe when/how to use the .IR file in the v1.0 distribution. Bill will likely write about it. Most likely is for starting extender mode from scratch.
Liz
Tweeking 8910, HTPro/9811, C7-7800, 6131o, 6131n, AtlasOCAP-1056B01, RCA-RCRP05B and enjoying the ride
Tweeking 8910, HTPro/9811, C7-7800, 6131o, 6131n, AtlasOCAP-1056B01, RCA-RCRP05B and enjoying the ride
-
unclemiltie
- Expert
- Posts: 1819
- Joined: Wed Jan 21, 2004 12:50 pm
- Location: Pittsburgh, PA
There's at least one bug in the RDF that I've found that is not going to cause anyone any real issues, but it should be fixed.
Right now, in RM and IR you can put macros, keymoves and assign functions to the Dev_xxx keys, which you shouldn't be able to do.
The RDF needs to change from
to
I'm packaging up some other comments on the readme and some other things that are still causing me to scratch my head and when I get those done I'll release 1.01 with the changes.
BTW, to those of you who sync your RDF directory with the SourceForge repository, I committed the above change to the RDF about a half hour ago.
Right now, in RM and IR you can put macros, keymoves and assign functions to the Dev_xxx keys, which you shouldn't be able to do.
The RDF needs to change from
Code: Select all
Dev_CBL=$71:Shift+XShift
Code: Select all
Dev_CBL=$71:AllBind
BTW, to those of you who sync your RDF directory with the SourceForge repository, I committed the above change to the RDF about a half hour ago.
this JP1 stuff is a sickness!
-
unclemiltie
- Expert
- Posts: 1819
- Joined: Wed Jan 21, 2004 12:50 pm
- Location: Pittsburgh, PA
-
unclemiltie
- Expert
- Posts: 1819
- Joined: Wed Jan 21, 2004 12:50 pm
- Location: Pittsburgh, PA
There is an issue with RM that mdavej reported a while back that confuses the dev5 key and DiscreteOff
dev5 can't be shifted or Xshifted, and I did specifiy that in the RDF. however, for some reason Xshift-dev5 shows up as Discrete off as they are both the same key value (which is why dev5 can't be xshifted)
greg is looking at this in RM to see what's going on.
In the mean time, if you put something on DiscreteOff, you'll get two keymoves show up in the output section. While you're importing into IR you'll have to delete one of them to keep IR from complaining.
dev5 can't be shifted or Xshifted, and I did specifiy that in the RDF. however, for some reason Xshift-dev5 shows up as Discrete off as they are both the same key value (which is why dev5 can't be xshifted)
greg is looking at this in RM to see what's going on.
In the mean time, if you put something on DiscreteOff, you'll get two keymoves show up in the output section. While you're importing into IR you'll have to delete one of them to keep IR from complaining.
this JP1 stuff is a sickness!
-
ElizabethD
- Advanced Member
- Posts: 2348
- Joined: Mon Feb 09, 2004 12:07 pm
Interesting.unclemiltie wrote:Right now, in RM and IR you can put macros, keymoves and assign functions to the Dev_xxx keys, which you shouldn't be able to do.
Just FYI, in 8910 extender target key cannot be a phantom device as it's not in IR dropdown key list. But for 6131 ext IR permits.
Liz
Tweeking 8910, HTPro/9811, C7-7800, 6131o, 6131n, AtlasOCAP-1056B01, RCA-RCRP05B and enjoying the ride
Tweeking 8910, HTPro/9811, C7-7800, 6131o, 6131n, AtlasOCAP-1056B01, RCA-RCRP05B and enjoying the ride
-
ElizabethD
- Advanced Member
- Posts: 2348
- Joined: Mon Feb 09, 2004 12:07 pm
Using KM, both in Atlas and here, the best solution for me was to just not put anything on DiscreteOn/Off, nor on the phantoms. Things got too confusing after import into IR. So I assigned things to other buttons and then in IR put'm where I'd like them to be. And then it was no longer an issueunclemiltie wrote:There is an issue with RM that mdavej reported a while back that confuses the dev5 key and DiscreteOff
...
In the mean time, if you put something on DiscreteOff, you'll get two keymoves show up in the output section. While you're importing into IR you'll have to delete one of them to keep IR from complaining.
However, I had no issue with anything dealing with dev5 like you described. Just the phantoms and discretes.
Liz
Tweeking 8910, HTPro/9811, C7-7800, 6131o, 6131n, AtlasOCAP-1056B01, RCA-RCRP05B and enjoying the ride
Tweeking 8910, HTPro/9811, C7-7800, 6131o, 6131n, AtlasOCAP-1056B01, RCA-RCRP05B and enjoying the ride
-
unclemiltie
- Expert
- Posts: 1819
- Joined: Wed Jan 21, 2004 12:50 pm
- Location: Pittsburgh, PA
Another addition to the RDF
It appears that the FAV device on the bottom of the FAV tab in IR doesn't really do anything when AdvCodeBindFormat=Long (i.e. long format Advance Codes) is set in the RDF. The old short format stored the device as part of the advance code, but the new one doesn't.
To fix this you can do one of two things:
1: put Dev_xx commands in your FAV macros to make sure you are setting the right device
2: add the following to the [settings] section in the RDF, which will put a FAV device in the general tab that will be used for FAV processing.
Until we get to the bottom of the FAV device in the FAV tab this will allow you to set the FAV device.
It appears that the FAV device on the bottom of the FAV tab in IR doesn't really do anything when AdvCodeBindFormat=Long (i.e. long format Advance Codes) is set in the RDF. The old short format stored the device as part of the advance code, but the new one doesn't.
To fix this you can do one of two things:
1: put Dev_xx commands in your FAV macros to make sure you are setting the right device
2: add the following to the [settings] section in the RDF, which will put a FAV device in the general tab that will be used for FAV processing.
Code: Select all
Fav Device = $039.7.1.0.0 DeviceButtons
Until we get to the bottom of the FAV device in the FAV tab this will allow you to set the FAV device.
this JP1 stuff is a sickness!
-
unclemiltie
- Expert
- Posts: 1819
- Joined: Wed Jan 21, 2004 12:50 pm
- Location: Pittsburgh, PA
another missing point from the RDF. not a huge issue.
Add the line:
PauseParams=Pause,2/1,10
to the general section of the RDF. This tells IR how to compute the right hex for the pause value. Right now if you put a pause in for 6.5 seconds, you'll actually get 10 seconds since the default value is a bit off for this extender.
Each $01 of hex in the first byte of the hex that you see is 100ms on this extender. Thus $64 is the right value for 10 seconds. Again, not a huge issue, but it's not right.
This is fixed in the V1.01 RDF that some day I'm going to upload and release to you all.
-bill
Add the line:
PauseParams=Pause,2/1,10
to the general section of the RDF. This tells IR how to compute the right hex for the pause value. Right now if you put a pause in for 6.5 seconds, you'll actually get 10 seconds since the default value is a bit off for this extender.
Each $01 of hex in the first byte of the hex that you see is 100ms on this extender. Thus $64 is the right value for 10 seconds. Again, not a huge issue, but it's not right.
This is fixed in the V1.01 RDF that some day I'm going to upload and release to you all.
-bill
this JP1 stuff is a sickness!
-
unclemiltie
- Expert
- Posts: 1819
- Joined: Wed Jan 21, 2004 12:50 pm
- Location: Pittsburgh, PA
Version 1.01 has been uploaded and the original topic link updated to point to the new version.
What is in this version:
you should be able to download the hex and upgrade your remote configuration with the following qualifiers:
What is in this version:
- Numerous bugs in the RDF have been fixed
Added FAV device entry on general tab to overcome IR shortcoming
Added interruptible pause protocol, any key press during pause will terminate the pause, any playing macro will continue
Added variable delay between keys in macro, set from general tab
you should be able to download the hex and upgrade your remote configuration with the following qualifiers:
- all of your setup codes and comments on the devices will be deleted
the "default" macros will be installed, first, so you will have to delete them if you have created new ones
Last edited by unclemiltie on Wed Mar 09, 2011 7:12 pm, edited 1 time in total.
this JP1 stuff is a sickness!
Attaboy
Bill,
I waited for extender ver 1.00 before trying the install - the remote is for a friend, but I am the one doing the programming and learning. I appreciate the effort you have gone to in squashing the RDF bugs. Will now install ver 1.01 and continue.
My feeling is that extenders make the organization of macros and keymoves more logical, not to mention more flexible. And the additional devices, DSM, Toadtog, Pause are options that I can no longer do without.
Ever Onward!
I waited for extender ver 1.00 before trying the install - the remote is for a friend, but I am the one doing the programming and learning. I appreciate the effort you have gone to in squashing the RDF bugs. Will now install ver 1.01 and continue.
My feeling is that extenders make the organization of macros and keymoves more logical, not to mention more flexible. And the additional devices, DSM, Toadtog, Pause are options that I can no longer do without.
Ever Onward!
Tom Carlson
Thanks for this - makes this remote much more powerful. I've tried quite a bit of it out and it works as expected.
I have found one oddity - the Set_Menu function doesn't seem to do anything, while the Set_Other function sets the menu keys as well as the other keys. For v1.00 and v1.01, I've set up the devices without using Set_Menu and have full use of arrows, OK, Menu, and surrounding buttons as well as the 4 ABCD buttons.
I have found one oddity - the Set_Menu function doesn't seem to do anything, while the Set_Other function sets the menu keys as well as the other keys. For v1.00 and v1.01, I've set up the devices without using Set_Menu and have full use of arrows, OK, Menu, and surrounding buttons as well as the 4 ABCD buttons.
-
unclemiltie
- Expert
- Posts: 1819
- Joined: Wed Jan 21, 2004 12:50 pm
- Location: Pittsburgh, PA
-
unclemiltie
- Expert
- Posts: 1819
- Joined: Wed Jan 21, 2004 12:50 pm
- Location: Pittsburgh, PA
you may have found a bug... I suspect that no one really separates the menu keys from the other keys and thus this never showed up.
Do me a favor, can you test by changing the value at $0761 from $04 to $05 in the raw data, then APPLY that change and upload to your remote. Let's see if that fixes it. I may not be searching all of the keylists, and of course since Menu is the next to last, that's the one that is falling off the list.
I need to also go back and figure out if this same bug exists in ALL of the JP1.3 extenders so far. It may since the same code is used in all of them.
The background:
In the extender, every time a key is pressed, the extender CALLs a routine that will search the lists of keys for each of the keysets. And when it finds it, it returns an index into a table of device numbers that is used to look up the device to use to process the key. I never search the "other" key list so if the extender doesn't find the key in any of the defined list, I assume that it must be other.
Now, if I stop searching and never search the Menu table, the extender will fall through and will fall back on the default of other. I think that's what is going on here.
That change that I asked you to make changes the number of keylists that are searched from 4 to 5 before it gives up.
Do me a favor, can you test by changing the value at $0761 from $04 to $05 in the raw data, then APPLY that change and upload to your remote. Let's see if that fixes it. I may not be searching all of the keylists, and of course since Menu is the next to last, that's the one that is falling off the list.
I need to also go back and figure out if this same bug exists in ALL of the JP1.3 extenders so far. It may since the same code is used in all of them.
The background:
In the extender, every time a key is pressed, the extender CALLs a routine that will search the lists of keys for each of the keysets. And when it finds it, it returns an index into a table of device numbers that is used to look up the device to use to process the key. I never search the "other" key list so if the extender doesn't find the key in any of the defined list, I assume that it must be other.
Now, if I stop searching and never search the Menu table, the extender will fall through and will fall back on the default of other. I think that's what is going on here.
That change that I asked you to make changes the number of keylists that are searched from 4 to 5 before it gives up.
this JP1 stuff is a sickness!