Has anybody created or have access to Adcom receiver codes that include all discrete sound modes, on/off and inputs for zone 2, etc.? Adcom has published these codes but of course all we get is the 3 digit hex code for the function itself with no way (or understanding?) of creating learnable or flashable codes. So...

1. Does anybody have these codes learned into a URC file? OR
2. Is there software (or tutorial) to learn what more we can do with the hex codes only?

RobZ

Take a look in the Pronto files. You can use the Universal browser to import the files into the Remote

I have scoured all the files on remotecentral...although there is a small handful of useful files, nothing even close to what I'm looking for (there is a published protocol of all their discrete codes available direct from the manufacturer...but of course no actual learned codes). Thanks anyway...

try inputing the hex code into the pronto software, then save the file as a .ccf. Then open the configuration in the URC software, then use the file manager to acces the pronto codes. This seems to work the best.

Mike

Well the hex codes are literally just 3 characters long (83h, 56h, etc.) and pronto hex codes are several sets of 4 characters (002b 004a etc.) so there's no real "way" to simply cut and paste the codes.

We've gone down this road before in years past and always arrived at the same dead-end ... i seem to remember a piece of software (MakeHex or something like that) that we believed would be useful, but never got it to work for us.

Why do manufacturers think that a list of simple hex codes will help us? There's more to the code than just this one bit of data, and even if we knew the whole code in hex format, we would still need it converted to 1's and 0's and learned into a remote or database to be useful. What are we (or they) missing?

MakeHex is the right tool for this task.

The several CCF files I've downloaded for Adcom all use NEC1 or NEC2 protocol with a device number of 26. If your Adcom device is the same, that plus the hex function numbers they gave you is all the information required.

If you had trouble with MakeHex in the past you should have asked questions in these forums until you got the answer.

You may also want or need to use IrPanels with MakeHex. I understand there is URC software that allows direct inport of Pronto Hex. But I don't have a copy. I don't know whether you have it and if you do whether it's easier to use than Irpanels followed by dragging from the CCF in Universal browser.

If you use MakeHex the ordinary way (which is the only way if you also use IrPanels) the functions will be labeled in decimal. But the function numbers you got from the manufacturer are in hex. That is an inconvenience, but it shouldn't be a big problem.

I'm not certain about the NEC1 vs. NEC2 issue with Adcom, so I don't know which you should use with MakeHex. For discrete codes it probably doesn't matter which you use. I suggest trying NEC2 first. NEC1 and NEC2 are the same for short presses and only differ for long presses. If NEC1 was correct and you use NEC2 instead, short presses will be correct and longer presses of some functions (especially digits and toggle functions) will double commands that you didn't want doubled. For discrete codes, accidentally doubling the command would be a totally invisible error.


I do often wonder why so many manufacturers give just the function numbers and not the protocol type or the "custom code". That does force you to get extra information elsewhere in order to use a tool such as MakeHex. Of course, I'm not sure Adcom did that to you. They might have mentioned the protocol and/or custom code and you just didn't notice it.

I understand you wanted them to go all the way to Pronto Hex. Several manufacturers do and that is more convenient for those using various remotes that can be programmed with Pronto Hex. But Pronto Hex is not nearly universal enough for that to be a clear cut decision for a manufacturer publishing their IR signals. Besides, they're in the amplifier business not the remote control business, so they might not even know how to generate Pronto Hex. They probably license from some other company the chips and/or firmware to send and receive NEC signals, so all they know about their own IR signals might be the hex function numbers as they exist on the boundary between their firmware and the licensed NEC receiver firmware.

I took another look at Adcom files available at RC. Have you seen this one:

[Link: remotecentral.com]

It has a CCF with generated signals for NEC device 26 (which they call custom code 1AE5) and device 26.232 (which they call custom code 1AE8).

It has a doc file listing function numbers in decimal with meanings by model for many different Adcom devices.

You might be able to use that CCF directly. If not, you might use that doc file with a CCF produced by MakeHex and Irpanels.

That CCF file has a short-press-only version of NEC protocol (only the part that is in common between NEC1 and NEC2). In a Pronto and certain compatible remotes, that will send the same short signal regardless of how long you press the button.

But in previous tests I've observed that the URC Universal Browser doesn't understand short-press-only Pronto signals. It always tries to extend them to signals that send more for a long press than for a short press and it extends them incorrectly producing garbage. If that happens to you as well, you can avoid that problem by producing correct NEC1 or NEC2 signals with MakeHex. The important thing is the doc file with decimal function numbers.

That zip also contains a txt file that seems to indicate that some functions are custom code 1AE5 while others are 1AE8. I can't find any mention of 1AE8 in that doc file, but a few of the functions in a few of the posted Adcom CCF files are device 26.232 (which corresponds to custom code 1AE8) instead of device 26. Of course MakeHex could be used to generate all the 26.232 codes as well.

Thank you very much for the wealth of information, I'm thinking we will try again to use the software to "make" the codes we need.

For the record I would hardly want or expect manufacturers to give us codes in ProntoHex format or any format for that matter on paper...what we need are the codes themselves learned into an actual remotes, included on their factory remotes or distributed in a downloadable file. Pronto .ccf is how we "usually" see manufacturers doing this...but if more started distributing codes in .rcc or .mxd files we would gladly accept that.

In any event Adcom i'm sure has no knowledge or understanding of MakeHex or Irpanels, so it's kinda silly for them to expect that we would, when some of us don't even employ full-time programmers or infrared code engineers, yet still want to sell reliable systems.

And we certainly don't mind going the extra mile and figuring out how to engineer their codes into a usable format...but if we don't all tell manufacturers what we want we will always spend OUR $$$ and spin OUR wheels on something they could do once and distribute freely.

Providing a .ccf file is just a way of providing Pronto Hex. The .ccf file is just a container. It isn't significantly different from providing the Pronto Hex in a text file or an Excel file or a pcf or whatever. Obviously it would be nuts to provide Pronto Hex on paper (though I've seen that done).

You might be happy with a .rcc or .mxd file, but I'm sure most of their customers would like that a whole lot less than .ccf.

What about a .lirc file or a jp1 upgrade file. Lots of their customers would like that a LOT better than a ccf file. I expect you wouldn't like those at all.

There is no industry standard form for providing IR data. In the world of custom installers a .ccf file may be as close to an industry standard as you can get. In the world of end users a .lirc file might be closer to a common standard.

I guess none of that means they shouldn't provide a CCF file, just that they should provide it in addition to the more concise form of the info not instead of the more concise form.


Most manufacturers don't use Pronto's and don't know about CCF files, so if you're asking them to provide a CCF file you're really saying they should learn to use tools like MakeHex and IrPanels instead of custom installers learning to. But if they view you as their customer or the path to their customer, that is what they should do.