On February 25, 2009 at 00:50, Healey3000 said...
I forgot about the one-time burst and it is indeed 16 bits long.
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.
Am I correct in assuming that some kind soul has converted these into Pronto from "clean" factory codes using Makehex or other?
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.
