JP1 Remotes

mathdon wrote:The problem is that there are two protocols, Panasonic Combo and Denon-K, in protocols.ini that have identical codes but different translations between hex and OBC. There is no way any software can distinguish which one is in the upgrade. RMIR identifies the first matching one that it finds in protocols.ini, which is Denon-K.

Can the user simply change the selected protocol to the correct one and have everything display correctly? I ask because it's my experience that RM doesn't change protocols very well as it will often blank out device codes and/or entire columns of data.

The Robman wrote:Can the user simply change the selected protocol to the correct one and have everything display correctly? I ask because it's my experience that RM doesn't change protocols very well

No, I tried it and it didn't work. I don't know how many cases there are in protocols.ini of two protocols with identical binaries but different translations between OBC and hex. Not many, I suspect. So I don't know how much effort it would be worth to sort out a solution, when there is so much more development waiting to be done. In this case I think that the Panasonic Combo should be made the default one in the issued protocols.ini in the way I suggested. That would deal with the vast majority of occurrences of this protocol in upgrades, I presume.

I tried it too. From Denon-K to Panasonic Combo. Didn't work, all subdevices became zero. Back to PanasonicCombo - all subdevices became FF.

Graham,
I do see what you're saying. Correct, IR does not give me OBC. But I can open KM file to get'm.

But think about this: I run RM, open a KM upgrade and see a perfect list of OBCs. No confusion because the protocol is identified.
Yet when I donwload from the remote, OBCs are not what I expect. Inconsistent really. I don't know what to think about this.

From decodeIR.html I see that Denon-K uses OEM codes 84 and 50, while Panasonic uses 3 and 32. Would that not distinguish them?
Or am I looking at an already tweaked algorithm in IR and perhaps KM as well?

Oh, and Vicky reminded us that sometimes we send the signals to Widget to check things like macros and of course protocol tweaking. I think an inacurate OBC list confuses.

ElizabethD wrote:I think an inacurate OBC list confuses.

You've lost me. Have you done what I suggested and moved the Panasonic Combo entry in protocols.ini to be above that for Denon-K? Do you still get wrong OBC's?

Sorry, putting PanasonicCombo in front of Denon-k does show the device upgrade just fine. But then what about Denon-K people?

In 2006 we discussed it (yikes it has beed 4 years) - several posts following this have a sad conclusion
http://www.hifi-remote.com/forums/viewt ... 7637#47637
Hmmm, so fixed bytes don't answer the problem. John Fine thought it might, but Greg did not because the ambiguity just got stuck

RM tries to eliminate the ones that don't reproduce the fixed data by converting the fixed data to protocol parameter values and back again.
Unfortunately, both Denon-K and Panasonic Combo pass that test. So RM gives up and just picks the first one defined in protocols.ini."

I wonder what the impact of this would be on a new user who just downloaded from a remote and tries to fix the upgrade and it won't work. I'm still not quite getting the exact point where things go wrong = different from what I'm used to = PanasonicCombo.

The OEM codes for Panasonic are 2 and 32, whereas for Denon-K they are 84 and 50, and those values are coded into the protocols.ini file, so surely there has to be a way to make any $00CD upgrade where the first 2 bytes of fixed data are "BF FB" to default to the Panasonic Combo, and $00CD any upgrade where the first 2 bytes of fixed data are "D5 B3" to default to Denon-K.

The Robman wrote:The OEM codes for Panasonic are 2 and 32, whereas for Denon-K they are 84 and 50, and those values are coded into the protocols.ini file....

Sure, as defaults. If you open RM and select a protocol, it opens with these defaults. You can then change the Device and OEM codes as you wish, so you can create a Panasonic Combo upgrade with the default OEM codes for Denon-K and vice versa.

To remove that possibility you would have to change the whole way we handle fixed data in protocols, so instead of fixed and variable bytes in a device upgrade, we would have fixed fixed bytes, variable fixed bytes and variable variable bytes. Like Donald Runsfeld's "there are known knowns, and known unknowns, but there are also unknown unknowns". (The press made great fun of this, but it's actually an important truth ).

... or an inconvenient truth!

All I'm saying is that there has to be a way to do it if you give it enough thought. Sure, those OEM values are just defaults, but all we're talking about here is having RM default to the best fit protocol.

And this doesn't have to be in the RM side of the program, it could be in the RMIR side as it passes data to RM.

Okay, I finally found something I like about RMIR. I like that when you import the RDMU file it automatically changes remotes for you. Not changing the remote is one of the most common user errors around, so this will be very helpful.


Bugs:
When you open RMIR by clicking on an RMIR file, you loose the NEW option so you can't create an RM or change to a new RMIR file.

In the Import function, if you choose KM files, it doesn't display the txt files, the only way to get that is to go to ALL supported file types.

I still find this new paradigm hard to handle. It is so device concentric, when RMIR should be a system control.

Managing upgrades is so hard when you only look at it from one device at a time. There are so many considerations that need to be used to manage a remote correctly. Keymoves are often the reason that macros don't work. Keymoves need to be orchestrated correctly when multiplexing. Protocols need to be managed to make sure that custom protocols are unique. Sometimes two upgrades use the same custom protocol, sometimes two upgrades use different custom protocols, the user has to keep track of this.

This trying to import and decipher a device upgrade from a download, is so overly complicated. I really don't understand why we are even trying to do it. But I guess the new paradigm requires it. Its just so confusing!

vickyg2003 wrote:Protocols need to be managed to make sure that custom protocols are unique. Sometimes two upgrades use the same custom protocol, sometimes two upgrades use different custom protocols, the user has to keep track of this.

This ties back to one of my earlier suggestions that RMIR could help the user manage this. I like to use $01FF for all custom protocols that I write by hand, because if I tried to give each custom protocol a unique id (that hasn't already been used by UEI, and won't ever be used by UEI) it would be impossible). In most cases, the chances of a single user needing to install two of my custom protocols is not great, but obviously it will happen from time to time. When it does, I would like RMIR to look at the two executors and if they're the same, just save one copy. If the new $01FF executor is different to the existing $01FF executor, RMIR should scan all the other executors to see if the code is the same as another executor (as the user could have added it already under a different PID). If no match is found, RMIR could either find the next free PID below $01FF and select it automatically, or it could give the user the opportunity to select a new PID. Maybe this could be configurable via an "expert" option.

Once a new PID is selected, the user should be asked to save the RMDU file so that the right PID is used next time the upgrade is modified.

vickyg2003 wrote:Bugs:
When you open RMIR by clicking on an RMIR file, you loose the NEW option so you can't create an RM or change to a new RMIR file.

Are you sure that double-clicking is opening the same version of RMIR? Check Help/About. The New button should never be disabled or made not visible.

Ok, into the fray again.

I do not think the RM-IR developers are insisting on "tie all parts together". Think about the following.

RM-IR could:

1. Not have all the features that IR has
2. Have all the features IR has, but not as easily visible
3. Have all the features IR has, and duplicate how data is presented
4. Have all the features IR has, and have a BETTER way to present the data.

In my opinion, (and boy does Greg have a lot of reading to do), Greg just wants us to think about #4 before he implements #3. Elizabeth's idea, for example, should be considered.

Regards,
xnappo

One thing that would make life easier working with upgrades would be to give KM files an extension that we could associate with RM. I'd like for KM to save and open files with an extension other than txt if possible. I realize this is a huge deal, but I think it would be worth the effort in the long run.

Back to the main topic, just to throw another huge monkey wrench into the works, I'm thinking of a totally different paradigm. I think when you open RMIR, the first thing you should see is a picture of the remote (the is one of the best things about RM), like the layout tab in RM. Then click a device button (or phantom device button) to assign a setup code or macro. Those details could show on the right like the general tab does today. The other stuff on the general tab (VPT, etc.) could be managed there too. Clicking buttons other than device buttons would let you manage macros, keymoves or learns associated with that button or the whole device upgrade for the active device mode. The other tabs we're used to seeing in IR are great summary views and should be accessible in one form or another, but the bulk of remote management should be accessed from that first graphical page.

A few more specifics on this home/main page I'm talking about. If you click a device button, that sets the active device. If you click any other button, it shows the layout tab in RM for that device upgrade with the button you clicked highlighted. If the button is associated with a device other than the active device, you're given the option to manage keymoves or macros (or learns or special protocols).

mathdon wrote:

vickyg2003 wrote:Bugs:
When you open RMIR by clicking on an RMIR file, you loose the NEW option so you can't create an RM or change to a new RMIR file.

Are you sure that double-clicking is opening the same version of RMIR? Check Help/About. The New button should never be disabled or made not visible.

You are right, when I was double clicking on the RMIR I was pulling up 1.99.

Chris, isn't it a reasonable compromise to say, go ahead and do all the cool development that you're doing, just don't take away any of the features that we have today? After all, someone must have had to write code to say "don't display these keymoves in the keymoves tab" or "don't display these protocols in the protocols tab". All I'm saying it, don't suppress the display of info, I really don't think that's asking for that much. I have no problem with the keymoves also being displayed as part of the upgrade, in fact I think it's a good idea. Likewise for the protocols.

I think it's pretty obvious that we're not going to convince you that it's a good idea to show the data that we want, and you're not going to convince us that we shouldn't see it, so let's just agree to disagree and go with the compromise that I've proposed.

And, I think Dave threw out some great ideas in his last post too.

Oh and one last thing, I will add my vote along with Alan that there still needs to be a direct link to a stand alone RM, without the need to go through RMIR first. There are many of us, myself included, that deal with upgrades far more often than we deal with remotes, so I find myself using KM and RM far more than I use IR.exe, with the exception being when someone gives me an IR file of learns that I need to convert into an upgrade. Alan does similar work, which is why he's in the same boat.