|
|
|
The following page was printed from RemoteCentral.com:
How to get HEX codes into MX Editor/IRPan...
| |
|
Topic: | How to get HEX codes into MX Editor/IRPanels problem? This thread has 17 replies. Displaying posts 1 through 15. |
|
Post 1 made on Monday July 17, 2006 at 03:21 |
How can one get the discrete hex codes from the Pronto section of remotecentral into the MX Editor?
I've read about using MakeHex and IRPanels, both of which I downloaded from this site (IRPanels is listed as CCF Panels). As an example, I found the Sony Receiver power discretes in a thread on this site, and using the supplied codes, MakeHex generated hex strings which matched those in the thread. So far, so good.
But when I paste them into IRPanels and click 'Generate CCF File...', I get an error dialog, "Run-time error '5': Invalid procedure call or argument." This is on XP SP2. Is the problem with the hex strings, or with the IRPanels program?
Is there another method I can use?
ADVthanksANCE
|
Pchek |
|
Post 2 made on Monday July 17, 2006 at 09:10 |
johnsfine IR Expert |
Joined: Posts: | September 2002 5,159 |
|
|
IrPanels has a few undocumented stupid restrictions on details of its input. I forget which error message you get if the input violates one of those restrictions, but it was something like the error you quoted. What .irp file and did you use and what edit did you make in the .irp file (device, etc.)? I can try the same thing. If the Irpanels problem doesn't duplicate, you did something wrong. If it does duplicate, I can probably tweak the .irp file details in some way to sidestep the flaw in IrPanels. On July 17, 2006 at 03:21, PChek said...
Is there another method I can use? About a year ago, someone posted a replacement program for IrPanels, with a different set of flaws, but generally better. Unfortunately, they didn't provide any documentation or even announcement, etc. I forget where that is in the RC file area.
|
|
OP | Post 3 made on Monday July 17, 2006 at 18:31 |
Hi John, thanks for the reply. I used the new Sony AV2 On/Off discretes posted by Jon Armstrong in this thread. I wasn't sure which Sony .irp to use, so I first tried Sony12.irp, and the results didn't match those in the thread, so I tried Sony15.irp and the results matched exactly. The only changes I made in the .irp were to change Device=48, and Function=46..47, as per that thread. Then I just copied the entire contents of the generated .hex file (is that correct?) and pasted into IRPanels. On July 17, 2006 at 09:10, johnsfine said...
About a year ago, someone posted a replacement program for IrPanels, with a different set of flaws, but generally better. Unfortunately, they didn't provide any documentation or even announcement, etc. I forget where that is in the RC file area. Hmm... I didn't notice anything while searching through the files, but could easily have missed it. :-( Thanks for your help, John
|
Pchek |
|
Post 4 made on Tuesday July 18, 2006 at 06:56 |
johnsfine IR Expert |
Joined: Posts: | September 2002 5,159 |
|
|
I'll test later, but in the past I've gotten bad results from IrPanels when trying any set of functions other than the original full set starting at 0.
The extra buttons wouldn't get in the way of dragging the ones you want via Universal Browser.
|
|
Post 5 made on Tuesday July 18, 2006 at 07:57 |
johnsfine IR Expert |
Joined: Posts: | September 2002 5,159 |
|
|
I tested. Function=46..47 causes IrPanels to crash Function=0..47 works.
|
|
Post 6 made on Tuesday July 18, 2006 at 11:59 |
silverado15000 Long Time Member |
Joined: Posts: | February 2006 11 |
|
|
Another option is to load the hex into pronto edit. Then you can pull the codes directly from the .ccf file using the MX Editor's Universal Browser.
|
|
OP | Post 7 made on Tuesday July 18, 2006 at 18:33 |
Thanks a lot, John. It worked! Thinking there might be other useful codes in the set, I set it to the full 0..127 and IRPanels generated the .ccf file fine.
However, when opening the file in Universal Browser, it gave three consecutive "File reading error" dialogs? After clicking through those, the file did open and all the buttons where there. I dragged 46 and 47 over, and they work!
silverado, thanks for the suggestion. That would have been a later resort, but since I don't have a Pronto and IRPanels is now working for me, I don't need the heavy guns :-).
|
Pchek |
|
Post 8 made on Wednesday July 19, 2006 at 08:59 |
johnsfine IR Expert |
Joined: Posts: | September 2002 5,159 |
|
|
On July 18, 2006 at 18:33, PChek said...
However, when opening the file in Universal Browser, it gave three consecutive "File reading error" dialogs? After clicking through those, the file did open and all the buttons where there. When I first started getting those error dialogs, I intended to check previous versions of various things to try to determine what changed to cause that. I never got around to it. I don't use Universal Browser much, but as well as I recall, those errors have occurred every time since they first started. Those errors are just an annoyance. They don't seem to affect the signals that you drag out of the CCF. Only MakeHex is under my control and I'm pretty sure MakeHex is not the cause of those errors. Assuming it is a defect in IrPanels or the Universal Browser, there isn't much I could do about it.
|
|
OP | Post 9 made on Wednesday July 19, 2006 at 18:48 |
Hi John. No, I don't think it is caused my MakeHex; rather by either IRPanels or Universal Browser. As you say, just an annoyance, since the codes work.
Here's another odd thing I found which is certainly a problem of either IRPanels or Universal Browser, rather than MakeHex: I've used MakeHex/IRPanels/UB to import several full code sets (0..127) for testing. With every one of them, the last three function codes (125, 126, 127), when transmitted by the MX-850, have sent *very* long transmissions, *much* longer than any other IR command, even longer than the Sony System All Off code.
These transmissions don't have any affect on my system, nor is there any indication that they should [as mentioned, I was testing codesets, looking for functions additional to the OEM remotes].
But when imported from MakeHex to IRPanels, those last three codes are seemingly no different (certainly no longer) than any of the other codes. The only difference I see is that IRPanels creates panels of 25 buttons each (five rows by five columns), so those last three codes end up being in the sixth panel, along with 22 other buttons which have no data.
All of these codesets I've tried so far have been using the Sony12.irp. I hope to next try some codesets for my Toshiba RPTV. Since there isn't a Toshiba.irp, which .irp should I use? Or in general, how does one know which .irp to use for any given piece of equipment?
One final weirdness I noticed in the IRPanels generated .ccf as viewed by UB, is that in every panel of every codeset, the fourth column (counting left to right) is in descending order, as contrasted with all the other columns in ascending order, i.e.:
00 05 10 19 20 01 06 11 18 21 02 07 12 17 22 03 08 13 16 23 04 09 14 15 24
and so on... :-)
|
Pchek |
|
Post 10 made on Wednesday July 19, 2006 at 19:07 |
johnsfine IR Expert |
Joined: Posts: | September 2002 5,159 |
|
|
On July 19, 2006 at 18:48, PChek said...
Here's another odd thing I found which is certainly a problem of either IRPanels or Universal Browser, rather than MakeHex: I've used MakeHex/IRPanels/UB to import several full code sets (0..127) for testing. With every one of them, the last three function codes (125, 126, 127), when transmitted by the MX-850, have sent *very* long transmissions, *much* longer than any other IR command, even longer than the Sony System All Off code. I never heard of that one before. difference I see is that IRPanels creates panels of 25 buttons each (five rows by five columns), so those last three codes end up being in the sixth panel, along with 22 other buttons which have no data. In MakeHex you can specify function=0..149 There are no Sony function numbers above 127, but MakeHex has no knowledge of that. When it tries to generate function 128 it will produce a copy of function 0 labeled 128 and so on for 129 through 149 matching 1 through 21. Then IrPanels would make an ordinary sixth panel rather than the partially populated one. If that fixes things, your theory is correct about either IrPanels or Universal Browser failing for a partially populated panel. codesets for my Toshiba RPTV. Since there isn't a Toshiba.irp, which .irp should I use? Or in general, how does one know which .irp to use for any given piece of equipment? Toshiba almost always uses the NEC1 protocol. So you just need the device number. Ordinary Toshiba TV's always use device number 64. I don't recall device numbers of other Toshiba devices, but they aren't hard to find online. Before testing any unknown commands on a Toshiba TV, do a few web searches for the results others have found. Some models of Toshiba TV can be permanently destroyed by sending certain commands. I hope those are only the commands for which you can find online warnings, and I hope Toshiba entirely stopped making that mistake several years ago. But I'm not sure that is the case. One final weirdness I noticed in the IRPanels generated .ccf as viewed by UB, is that in every panel of every codeset, the fourth column (counting left to right) is in descending order, as contrasted with all the other columns in ascending order, i.e.:
00 05 10 19 20 01 06 11 18 21 02 07 12 17 22 03 08 13 16 23 04 09 14 15 24 Do the functions match the labels and just the physical position is wrong? Or what?
|
|
OP | Post 11 made on Wednesday July 19, 2006 at 19:19 |
On July 19, 2006 at 19:07, johnsfine said...
In MakeHex you can specify function=0..149 Then IrPanels would make an ordinary sixth panel rather than the partially populated one. Okay, I'll try 0..149. Toshiba almost always uses the NEC1 protocol. So you just need the device number. Ordinary Toshiba TV's always use device number 64. I don't recall device numbers of other Toshiba devices, but they aren't hard to find online. Thanks. So would I use the nec1.irp or the NECx1.irp? Before testing any unknown commands on a Toshiba TV, do a few web searches for the results others have found. Some models of Toshiba TV can be permanently destroyed by sending certain commands. I hope those are only the commands for which you can find online warnings, and I hope Toshiba entirely stopped making that mistake several years ago. But I'm not sure that is the case. Thanks for that warning! I'll try to be careful. :-) Do the functions match the labels and just the physical position is wrong? Or what? Yes, the functions match the labels, so there is no real problem... it is just a weirdness. :-)
|
Pchek |
|
OP | Post 12 made on Wednesday July 19, 2006 at 21:27 |
Hmm... another question: On July 19, 2006 at 19:07, johnsfine said...
Ordinary Toshiba TV's always use device number 64. I don't have a Pronto, but I'm guessing that 64 would be the device number in the Pronto database, since that would be what MakeHex would want? But the same device would have a different number in the database of each different remote's manufacturer, yes? So for example hifi-remote.com, which deals with OFA/RS remotes, lists Toshiba TVs as devices 0156, 0060, and 0154. I'm wondering which of those three corresponds to the Pronto's 64? Or more precisely, I'm wondering in general how one can tell which device number in one database corresponds to a given number in a different database? In any case, given your earlier warning (and there is a similar caution at hifi-remote.com), I think I'll pass on indiscriminate testing of my Toshiba HDTV. None of the three codesets at hifi-remote.com listed what I was looking for [discretes for inputs and theatrewide modes], and presumably they would be there if they existed :-(.
|
Pchek |
|
Post 13 made on Thursday July 20, 2006 at 09:27 |
johnsfine IR Expert |
Joined: Posts: | September 2002 5,159 |
|
|
On July 19, 2006 at 19:19, PChek said...
So would I use the nec1.irp or the NECx1.irp? nec1.irp NECx1 is another protocol that is very similar to nec1, but not quite the same. Samsung usually uses NECx1. On July 19, 2006 at 21:27, PChek said...
I don't have a Pronto, but I'm guessing that 64 would be the device number in the Pronto database, No. 64 is the device number encoded into the actual IR signal. It is not the database number of the code set. since that would be what MakeHex would want? MakeHex knows nothing about anyone's database of code sets. MakeHex needs the actual number that is encoded in the signal. But the same device would have a different number in the database of each different remote's manufacturer, yes? Correct, though several universal remote brands, including Pronto, license their database from the company behind the OneForAll brand. In those cases there is a simple relationship between the OneForAll setup code number and the other brand's database number. But neither has any systematic relationship to the device number encoded in the signal. So for example hifi-remote.com, which deals with OFA/RS remotes, lists Toshiba TVs as devices 0156, 0060, and 0154. OneForAll has at least 28 different setup codes for NEC1:64, because a setup code carries the whole list of associations of function numbers to buttons, in addition to the protocol and device number. TV/0156 is the most connonly used of those. 0060 and 0154 are not NEC1:64. I didn't double check that page at hifi-remote, but I think 0060 and 0154 are other brands. Maybe Toshiba rebranded a few TV's of other brands so OneForAll listed those brands' code sets under Toshiba. I'm wondering in general how one can tell which device number in one database corresponds to a given number in a different database? Usually you can't. But if a CCF file uses a database code from that licensed database and you decode it with DecodeCCF, DecodeCCF will display the OneForAll setup code number. DecodeCCF does not contain the actual database and the CCF doesn't contain the actual IR signal for database signals, so you get that setup code number instead of (not in addition to) a normal decode.
|
|
OP | Post 14 made on Thursday July 20, 2006 at 19:31 |
John, thanks for that helpful information. :-)
|
Pchek |
|
OP | Post 15 made on Saturday July 22, 2006 at 23:25 |
John, just to keep you updated: I tried using 0..149, and codes 125, 126, 127 from that .ccf file did not generate very long IR transmissions--they seemed to work normally, though they don't correspond to any function I have, so I can't be absolutely sure that they are correct. But it does appear that that was the problem.
However, using 0..149 caused IRPanels to generate *seven* panels instead of six. This isn't a problem, it seems to be just another quirkyness of IRPanels.
Regarding the 'other' program that does IRPanels' job--would it have been Hex2CCF? I stumbled across that in another thread, and gave it a try. It does the job, and the resultant .ccf file does _not_ cause UB to give three errors when opening, the way that the IRPanels .ccf files do. Hex2CCF generates only 15 buttons per panel as opposed to IRPanels' 25, so require more panels. What were those shortcommings you observed of Hex2CCF (if that indeed is the other program you mentioned)?
|
Pchek |
|
|
Before you can reply to a message... |
You must first register for a Remote Central user account - it's fast and free! Or, if you already have an account, please login now. |
Please read the following: Unsolicited commercial advertisements are absolutely not permitted on this forum. Other private buy & sell messages should be posted to our Marketplace. For information on how to advertise your service or product click here. Remote Central reserves the right to remove or modify any post that is deemed inappropriate.
|
|