New documentation for DecodeIr.dll
Posted: Mon Jan 31, 2005 6:02 pm
I'm about half way through writing new documentation for DecodeIr.dll
http://www.hifi-remote.com/johnsfine/DecodeIr.html
It's an html file this time (ReadMe.txt files, like I normally write are easier to write but harder to read).
It's main focus is the individual peculiarities of each protocol and how those affect the process of using the decode info in a JP1 upgrade or KeyMove.
If you provide any constructive comments soon, they'll probably influence the writing of the other half of this and I might even fix the parts I've already written.
I'd especially appreciate a review for accuracy by the other experts.
This document is supposed to warn you when the OBC numbering in KM is different from that in the decodes (so you're better off using EFCs). It does so in a few cases. But I'm sure I missed a few.
It's supposed to warn you when there are multiple varients of a protocol floating around with incompatible EFC numbering (so you're better off using OBCs). It does so in a few cases. But I'm sure I missed a bunch.
It should also warn of various other glitches in the smooth transfer between DecodeIr and KM, such as one side calls it "subdevice" and the other "unit", or one has zero based unit numbering and the other one based, etc. Again I'm sure I remembered and documented just a fraction of the protocol specific glitches that are out there.
The "half done" means over half the total number of protocols are mentioned and I hope well over half of the info for each of the mentioned ones is there. But some common and important protocols aren't there yet, so save review comments about missing protocols till after I have time to add those. Please comment mainly on missing, wrong or incomprehensible info in the entries that are there.
It documents a new version of DecodeIr, that I'm not quite ready to release yet. But the changes in KM compatibility in that new version are small, so that shouldn't affect reviewing the doc now. The new DecodeIr significantly improves the decoding of badly learned signals (more correct decodes and fewer spurious decodes) but shouldn't change much about the decoding of good signals. It takes on average twice as long to decode than the previous version did. I might improve that before release, but I doubt that it matters to anyone but me. I throw some very large libraries of IR signals at it repeatedly for test purposes (on a very fast computer). The difference between 2 minutes and 4 minutes to decode a whole library of signals matters to my work flow. But if you just use something like DecodeCCF or IR's summary feature to decode one remote's worth of signals, I doubt you could even measure the time the actual decoding takes.
http://www.hifi-remote.com/johnsfine/DecodeIr.html
It's an html file this time (ReadMe.txt files, like I normally write are easier to write but harder to read).
It's main focus is the individual peculiarities of each protocol and how those affect the process of using the decode info in a JP1 upgrade or KeyMove.
If you provide any constructive comments soon, they'll probably influence the writing of the other half of this and I might even fix the parts I've already written.
I'd especially appreciate a review for accuracy by the other experts.
This document is supposed to warn you when the OBC numbering in KM is different from that in the decodes (so you're better off using EFCs). It does so in a few cases. But I'm sure I missed a few.
It's supposed to warn you when there are multiple varients of a protocol floating around with incompatible EFC numbering (so you're better off using OBCs). It does so in a few cases. But I'm sure I missed a bunch.
It should also warn of various other glitches in the smooth transfer between DecodeIr and KM, such as one side calls it "subdevice" and the other "unit", or one has zero based unit numbering and the other one based, etc. Again I'm sure I remembered and documented just a fraction of the protocol specific glitches that are out there.
The "half done" means over half the total number of protocols are mentioned and I hope well over half of the info for each of the mentioned ones is there. But some common and important protocols aren't there yet, so save review comments about missing protocols till after I have time to add those. Please comment mainly on missing, wrong or incomprehensible info in the entries that are there.
It documents a new version of DecodeIr, that I'm not quite ready to release yet. But the changes in KM compatibility in that new version are small, so that shouldn't affect reviewing the doc now. The new DecodeIr significantly improves the decoding of badly learned signals (more correct decodes and fewer spurious decodes) but shouldn't change much about the decoding of good signals. It takes on average twice as long to decode than the previous version did. I might improve that before release, but I doubt that it matters to anyone but me. I throw some very large libraries of IR signals at it repeatedly for test purposes (on a very fast computer). The difference between 2 minutes and 4 minutes to decode a whole library of signals matters to my work flow. But if you just use something like DecodeCCF or IR's summary feature to decode one remote's worth of signals, I doubt you could even measure the time the actual decoding takes.