New documentation for DecodeIr.dll

[johnsfine]

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.

[jon_armstrong]

A nit:
You use OBC without relating it to F or Function.

A suggestion:
Include the explanation of the new IRP format as an appendix.

A question:
Will the new version of DecodeIR.dll decode the dreambox/force/escient protocol with the 16 different burst pairs that represent 0-F?

I'll try to get the time to check the IRP definitions more carefully. What I did look at, all seemed correct. In RECS80 you mention the 0 frequency variant, but I didn't see that IRP definition and IIRC it's different but I could find it right off in my files. I'll try to locate that.

[johnsfine]

A nit:

Thankyou for reviewing it (even though I disagree with your nit).

You use OBC without relating it to F or Function.

A suggestion:
Include the explanation of the new IRP format as an appendix.

The IRP notation is in this document just for expert use. Anyone who didn't know F was OBC wouldn't be reading the IRP notation anyway. At some point I'll add a link to documentation for IRP format (Which first means I need to clean THAT up a little and post it on my web space).

A question:
Will the new version of DecodeIR.dll decode the dreambox/force/escient protocol with the 16 different burst pairs that represent 0-F?

No new protocols are in this version. Just improvements to old one. That one is on my "to do" list.

In RECS80 you mention the 0 frequency variant, but I didn't see that IRP definition and IIRC it's different but I could find it right off in my files. I'll try to locate that.

I added that because I saw it in KM and because I've seen unmodulated RECS80. But I didn't take time to research it (to make sure that pid really is unmodulated RECS80, etc.) I just checked that that pid is unmodulated and that its '0' and '1' timing is as described.