Your Universal Remote Control Center
RemoteCentral.com
URC's Consumer Remotes Forum - View Post
Previous section Next section Previous page Next page Up level
Up level
The following page was printed from RemoteCentral.com:

Login:
Pass:
 
 

Page 1 of 2
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
PChek
Long Time Member
Joined:
Posts:
May 2003
206
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
PChek
Long Time Member
Joined:
Posts:
May 2003
206
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
PChek
Long Time Member
Joined:
Posts:
May 2003
206
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
PChek
Long Time Member
Joined:
Posts:
May 2003
206
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
PChek
Long Time Member
Joined:
Posts:
May 2003
206
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
PChek
Long Time Member
Joined:
Posts:
May 2003
206
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
PChek
Long Time Member
Joined:
Posts:
May 2003
206
John, thanks for that helpful information. :-)
Pchek
OP | Post 15 made on Saturday July 22, 2006 at 23:25
PChek
Long Time Member
Joined:
Posts:
May 2003
206
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
Page 1 of 2


Jump to


Protected Feature 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.

Hosting Services by ipHouse