Ahh, yes! I forgot about the one-time burst and it is indeed 16 bits long. Therefore, you and Jason are correct in that the 2802 uses Sharp codes. Sounds like I need to spend some time understanding those.

Am I correct in assuming that some kind soul has converted these into Pronto from "clean" factory codes using Makehex or other?

Thanks,
Adnan

I ran DecodeCCF on that CCF file you linked. Comments on a few specific signals:

Vol- and Vol+ are the standard Denon double frame. The whole 32 pulses repeats and the two frames are in standard sequence. A few other signals also fit that pattern.

Mute is what you described, it has 48 pulses with 16 sent once then 32 repeating. The 16 sent once are the first frame and the repeating part is the second frame followed by the first frame. Several other signals have the same pattern. I hope you understand, that is not a feature of the actual signals. It is a glitch in the Pronto learning.

If you decode it yourself with DecodeCCF, you may see some garbage decoded in addition to the correct signals on "left", "direct", "up arrow", and "shift". In most cases where DecodeCCF is used garbage in addition to correct decodes on a single signal indicates a messy learn that is still understandable. But in this case it appears to be entirely a flaw in DecodeIr.dll. Either way, you would want to look at just the correct decode and ignore the garbage.



You could easily do that yourself. Use Denon.irp and run it once with Device=2 and once with device=12. Then select which function is which Pronto Hex string based on the output of DecodeCCF.

Healey3000,
can I ask why you're interested in the waveforms? I'm just curious; I've never educated myself as to the meanings of different hex words in the Pronto hex strings and I'd be more than totally lost with the waveforms. But it occurs to me that Pronto hex is like looking at an entry in a log such as "30,000 oranges" while the waveform is looking at an entire pile of 30,000 actual oranges... much harder to conceive of and do anything with.

I've also found by experimentation that in at least one case, NEC1 codes from a factory remote, learned several times by both a Pronto and an RTI learner, come up with different hex strings every time, all of which work. The explanation John gave about plus or minus ten percent falls well within what's reasonable seeing those different hex strings. If I were doing research and had a remote with codes built into it, I'd learn them, decode them, then generate perfect hex representations with MakeHex.