On February 22, 2008 at 03:28, ltlbigchief said...
I thought that once IREdit decoded the IR Hex codes, that
you could then change the command value and hit Encode
IR, this doesn't work for me, the Hex code stays the same??
I assume you mean IrTool. I don't know any IREdit.
IrTool was written including its own decoder and encoder, but they aren't very good.
I wrote DecodeIR.dll which serves as a decoding component for a bunch of different IR programs.
Someone modified a copy of IrTool to call DecodeIr.dll before calling IrTool's internal decoder, so you get the DecodeIr decode in a pop up dialog. If you dismiss that dialog, you get the decode from IrTool's internal decoder.
DecodeIr.dll only decodes, it doesn't encode. The encoder in IrTool only coordinates with its internal decoder, not with DecodeIr.dll. It is only usefuly for a few protocols and then only for restricted subdevice values.
Also is the a list of what the function codes are? Do
all companies use a predefined list, or is always different
and you just have to test them all?
When RCA uses its own protocol, they have a very consistent set of function numbering across many different types of devices.
When Philips and many other brands use RC5, they have nearly consistent numbering for a bunch of basic functions, but the advanced functions have totally inconsistent numbering, not just from brand to brand, but even from model to model within a brand.
Most brands are less consistent than the above. A brand might or might not reuse a mapping of function number to function name for a related model of the same device, but they don't have any overall consistency to the numbering.
Several brands are consistent within brand across model in how they number discrete functions, but then are very inconsistent about which models support which discrete functions.
