JP1 Remotes

Something I'd forgotten about until now....

Greg Bush initially mentioned this in another thread, where I was questioning the need for putting button code prefixes in map files.

I later questioned his comment because I didn't quite understand what was going on, but never saw any more discussion about it.

But I now need to address this head-on.

The 'URC-6131nw.map' file that's in the most recent distribution has these lines: It's odd to me how those lines could have been put into (and left in) a map file that the users of unmodified URC-6131n remotes have apparently been using for some time now if they were based on someone's hardware hack.

The question now is: Assuming that the $45/CC code was a hardware hack by one person (which Liz's tests will hopefully help confirm), what do I do with the map file? I assume I should change the $45 to $37, making 2 physical buttons with the same button code, to match the firmware. Greg, would that work as expected in RM?

And also, assuming that the current map file is in error for users of unmodified URC-6131n remotes, how would that error manifest itself in RM for those users? What effect would that error have? I'd like to see it in action before I "fix" it. And I'd generally just like to understand the whole issue (i.e. how these button code prefixes work with respect to RM) better.

Bill

Don't we have to consider the possibility that at some point UEI changed the workings of the 6131n(w)? We know from another thread that the Kameleon 8308 has 3 different versions of firmware. Seems to me that the 6131n(w) is, since it is sold at RS and other retailers, likely to have been sold in large numbers, and there were probably multiple manufacturing runs of the micro.

It also seems to me unlikely that UEI put two buttons on the remote with the intent to always have them wire-OR'd together. The only way I can see that scenario is if the button sheet is shared with some other remote.

Now about the thread in which pasha shows how he modified the PCB to to apparently make the CC and Audio buttons separate. He reports that after the mod, the Audio button generated $38. But according to both RDF files $38 is associated with button dev8 (a phantom device). And a subsequent post by a different user seems to imply that the mod didn't work. So I wonder if his mod really accomplished the intent. But in any case the mod, as documented by pasha, would not cause CC to appear as $45.

So, it seems unlikely that someone would go to the trouble of making and submitting a new RDF file which would function properly only with an unposted and unknown one-off modification.

One possible explanation is a change in the as-manufactured behavior of the 6131n(w).

I failed again making a macro using 995.
So back to keymoves. This time I reversed the sequence - programmed CC first then Audio with the same values as here:
https://www.hifi-remote.com/forums/viewt ... 1084#p81084

IRscope sees the same OBC put out whether I press CC or Audio.
Raw data says $37 83 10 2F 1A
Note the change from my previous post, where the button was 1B.

The keymoves sheet shows
DVD/Audio=TV,TV,0047,$1A, keycode or efc = 5 which is the button I used.

So, "the last one wins".
In my opinion $45 should be deleted.[/b]

3FG wrote:Don't we have to consider the possibility that at some point UEI changed the workings of the 6131n(w)?

It may not be obvious, but it was always (and still is) under consideration:

WagonMaster wrote:Basically, it looks like someone created a so-called "FIXED" version of the RDF which supports a variant of the URC-6131n which seems to have the "Audio" and "CC" buttons with unique codes ($37 and $45) instead of both buttons using the same $37 code (...)

That's why I referred to a "variant" of the URC-6131n, thinking that there may have been more than 1 at some point. If someone has any evidence of that, I'd be delighted to see it. But until then, I have to assume things based on the facts at hand. Actually, I thought the URC-6131n{w} was quite popular, so I'm surprised I haven't heard more people commenting. Maybe I just need to wait a week or so.

3FG wrote:So, it seems unlikely that someone would go to the trouble of making and submitting a new RDF file which would function properly only with an unposted and unknown one-off modification.

I agree. But at the same time, I need evidence of that to make a sound decision and I'm working with very little.

Side rant: This is one of the many reasons why these RDFs (and map files) need some sort of documented authorship and version history. This "wild west" style of anyone updating the RDF and rarely documenting who/when/why is not acceptable. I intend to address this eventually, as well as possible at this late stage of the game.

3FG wrote:One possible explanation is a change in the as-manufactured behavior of the 6131n(w).

Agreed. All you URC-6131n{w} users out there -- please (PLEASE!) run Liz's keymove test so this can be resolved conclusively!

Bill

Thanks a million for running those tests, Liz! I appreciate your patience. I think you've proved conclusively that your variant of the URC-6131n clearly uses button code $37 for both the "Audio" and "CC" buttons. This is very helpful.

Now if I could just hear from some other URC-6131n{w} users to confirm that there are/aren't other variants out in the wild.

Thanks again!

Bill

Seems to me that this question was raised here 2 years ago.

It definately sounds like FIXED was a bad choice. I'd think something like Rewired-CC-Hack would need to be in the name to make it less confusing. I can't understand why the change was made to the keymap. I would think that any upgrades created in RM that included the last two keys in the keymap would crash the 6131, but what do I know.

Thanks for the link, Vicky. I somehow never saw that thread in my searches. Unfortunately, the file referred to in that thread, which supposedly had an explanation in the "Description:" section, no longer exists! And Rob's final question was left unanswered.

vickyg2003 wrote:I can't understand why the change was made to the keymap.

Well, the possibility staring us in the face (as aptly pointed out by '3FG') is that there really is a variant of the URC-6131n with just such a distinct $45 button code for "CC" and just such a firmware 'button map' setup. But I'd really like to see some evidence of that. If such a variant is out there, I don't think it should be that hard to find, but as you say, "What do I know?".

Bill

3FG wrote:Don't we have to consider the possibility that at some point UEI changed the workings of the 6131n(w)? We know from another thread that the Kameleon 8308 has 3 different versions of firmware. Seems to me that the 6131n(w) is, since it is sold at RS and other retailers, likely to have been sold in large numbers, and there were probably multiple manufacturing runs of the micro.

True, we do always have to consider these possibilities. However, I am unaware of any variation in the URC-6131n(w) being reported previously. I think it is highly unlikely in this case.

3FG wrote:It also seems to me unlikely that UEI put two buttons on the remote with the intent to always have them wire-OR'd together. The only way I can see that scenario is if the button sheet is shared with some other remote.

It may have been more of a styling choice in the case of the URC-61631n(w) to make it look more like the then new URC-6820/8820/10820 series. Also, in the past, it has not been uncommon for UEI to do this. For example, look at the 15-1925 or the early Navigators, which each share the same firmware with several other remotes, and have buttons wired together.

3FG wrote:So, it seems unlikely that someone would go to the trouble of making and submitting a new RDF file which would function properly only with an unposted and unknown one-off modification.

That may be, but it also seems likely than a novice JP1 user could modify an RDF file, see the results "working" in IR, and then post the file in the RDF folder without being reviewed by a JP1 expert. The RDF then gets included in the next release simply because it is there.

3FG wrote:One possible explanation is a change in the as-manufactured behavior of the 6131n(w).

A possibility, yes, but again, I disagree in this case. We have no evidence of any change in the remote in question. I have a fairly complete set of data on this remote, as I ported the 2K extender to the 1K extender.

vickyg2003 wrote:Seems to me that this question was raised here 2 years ago.

Good point. Even Robman doubted the validity of the RDF in question. (Now, if someone could just rouse him from his JP1 slumber to weigh in on this... )

vickyg2003 wrote:I would think that any upgrades created in RM that included the last two keys in the keymap would crash the 6131, but what do I know.

That won't crash the remote, but their presence in an upgrade would simply be ignored. The remote only processes as many keys as are defined in the internal keymap.

WagonMaster wrote:Well, the possibility staring us in the face (as aptly pointed out by '3FG') is that there really is a variant of the URC-6131n with just such a distinct $45 button code for "CC" and just such a firmware 'button map' setup. But I'd really like to see some evidence of that. If such a variant is out there, I don't think it should be that hard to find, but as you say, "What do I know?".

Based on the evidence I have, there has not been any other variant of the URC-6131n(w). You are, of course, welcome to wait until others offer other evidence before making your decision, but if it were me, I'd drop it from the distribution.

Thanks for the input, Mike! Since it will be a while before I have to make the final decision, I'll "keep my ear to the rail" for any evidence to the contrary, but based on Liz's experiment, your experience/history, and both your suggestions, I'll plan to remove that so-called "FIXED" RDF with the $45/CC code from the next RDF/map/image file release.

Of course, if someone does come up with an unmodified '$45=CC' remote, it's easy enough for me to quickly support it with a new release, so there should be no serious ramifications of doing as you suggest.

And, just for the record (not that Mike was suggesting I'd do otherwise), no RDF in my distribution will be added to the set without reasonable scrutiny, which is partly why this process is taking so long. A bad existing RDF (like this so-called "FIXED" URC-6131n version, which was already in the last set and which I could have easily missed) might slip through the cracks, but I'm making every effort to avoid that too by semi-exhaustive comparisons of various RDF/map/image files and trying to understand (and in many cases, resolve) why most non-cosmetic discrepancies exist. I've just started working my way through the extender RDFs/maps/images and I'm already running into a lot of little discrepancies that need to be addressed. A long, slow slog....

Thanks to everyone for their inputs!

Any URC-6131n{w} users with something other than Liz's case ("sticker inside the battery compartment is G052501") -- your input would be greatly appreciated too, especially if you can program a couple of "Audio" and "CC" keymoves manually via the '994' code and download/save the EEPROM into a '.ir' file for quick analysis.

Bill

I've never owned a URC-6131n{w}, so I can't help with the testing. I use URC-6131's.

I am only aware of the URC-6131 (single Audio/CC button), the URC-6131n (separate Audio and CC buttons hard-wired to use the same button code), and the modded URC-6131n (modded to have different button codes for the Audio and CC buttons).

It does sound to me like FIXED was a poor choice for naming the .rdf and .map. HACKED or MODDED would been more appropriate.

In RM, the .map file is used only for the layout panel. Shapes (defined in the .map file) on the image are mapped to buttons (defined in the .rdf file) by button code (if specified) or name. That's all the .map file is used for. Each shape can map to at most one button, but multiple shapes can map to the same button.

The reason for using button codes is simple - they are unambiguous.
In the first few iterations of an RDF file, button names often change. Using button codes means the .map file doesn't have to change.

Any URC-6131n{w} users with something other than Liz's case ("sticker inside the battery compartment is G052501") -- your input would be greatly appreciated too, especially if you can program a couple of "Audio" and "CC" keymoves manually via the '994' code and download/save the EEPROM into a '.ir' file for quick analysis.

My URC-6131n has the same G052501 sticker so I don't think I can add any new info. But if there is something you'd like for me to try, give a shout.

Just for the record, in the zip file are the two keymove tests as described above.
https://www.hifi-remote.com/forums/dload ... le_id=7475
In both instances I filled the remote with zeros and did 981 reset before making the keymoves from the keyboard using the 994 command.

Hi Ellen, 7800 is still a favorite here (my husband can only use 7800, not capable of any other!). I would have never had it were it not for your encouragement.

If you ever did a macro from the keyboard let me know, 'cause I failed miserably. What would we do without jp1!

Thanks for the info, Greg -- much appreciated! A confirmation and a clarification still needed though, please bear with me:

1. It sounds like RM will be OK if I make this sort of entry in the map file:

   Code: Select all

   circle $37:Audio  70,382 78,390 
   circle $37:CC{Closed_Caption}  46,381 54,389
   

   Correct?
2. Speaking more generally, just out of curiosity, what would happen if a map file specified a button code with the name of a button matching the name of a button in the RDF file but with a different button code? How would RM deal with that? Where would I see the ramifications of that sort of conflict? Would one code be universally ignored? If so, which one?

Many thanks for the offer to help, Ellen! As you suspect, testing your (same) model of URC-6131n probably wouldn't add much to the equation, but it's always nice to know about willing testers with various remotes, in case I need another test and Liz isn't around. Thanks much!

Bill

WagonMaster wrote:Thanks for the info, Greg -- much appreciated! A confirmation and a clarification still needed though, please bear with me:

1. It sounds like RM will be OK if I make this sort of entry in the map file:

Code: Select all

circle $37:Audio  70,382 78,390 
circle $37:CC{Closed_Caption}  46,381 54,389

Correct?

Yes. Multiple shapes can have the same button code. When a button code is used, it is the only thing used to determine the associated button. The name then becomes a display name used in place of the button's name from the RDF, on the Layout panel only.

2. Speaking more generally, just out of curiosity, what would happen if a map file specified a button code with the name of a button matching the name of a button in the RDF file but with a different button code? How would RM deal with that? Where would I see the ramifications of that sort of conflict? Would one code be universally ignored? If so, which one?

As explained above, when there's a button code, it's the only thing used for determining the associated button. No conflict is possible.

gfb107 wrote:As explained above, when there's a button code, it's the only thing used for determining the associated button. No conflict is possible.

Got it. Thanks for the clarification!

Bill