First some background info.
Typical IR protocols repeat the same "frame" of the signal as long as the button is held.
Some protocols have a first frame that is different from the rest. So the first frame is sent once, then the repeating frame is sent as long the button is pressed.
In JVC protocol, the only difference between the first frame and the repeating frame is that there is one extra burst at the beginning of the first frame.
On December 2, 2007 at 21:34, sam.roberts said...
1) Are these codes the same?
On most Pronto's they are the same. But on at least some versions of the NG firmware, they aren't the same. The shorter one would be sent slightly incorrectly, and some JVC devices care about the difference.
The long one encodes the two frames seperately. But the short one encodes the extra burst as if it were the whole first frame, then encodes the repeating frame normally.
There is no marker in the signal for a frame boundary. The signal is just a sequence of bursts. So a Pronto might learn a JVC signal in either of those two forms depending on where it happens to try to see a frame boundary.
If a Pronto sends the short signal correctly, there is no important difference between the two. The initial burst would be immediately followed by the first "repeat" frame, which would look to the JVC device exactly like a correct "first" frame.
On a very short button press, the Pronto sends some minimum duration signal (longer than the actual press) including at leat one repeat frame. I'm not sure exactly how it decides the minimum and that might end up as a different number of frames for the short vs. long version of this Pronto Hex. But I don't think that is going to be a problem.
The problem is the some NG firmware injects some extra delay on frame boundaries, rather then delaying the exact amount encoded in the Pronto Hex for that boundary. Devices are not at all picky about the exact delay on a real frame boundary. But the boundary after the first burst in JVC is not a real frame boundary. The JVC device may reject the signal if the Pronto firmware adds delay.
2) Why does one start with 0000 006C and the other 0000
006D? This seems to be related to the frequency or something,
because I noticed that after decoding each with IR Tool,
it shows Carrier 006C 108 cycles = 38.381 for one and
006D 109 cycles = 38.029 for the other. Will either work
equally well, and why the difference?
Pronto's aren't very accurate about capturing frequency. But the IR sensor in the actual device isn't very picky about exact frequency either. It won't care about that tiny difference.
Is there some reason
to prefer one over the other?
In a Pronto that doesn't add random delays on frame boundaries, the short one might be considered better because it is shorter. On a Pronto that sends the short one incorrectly, the long one is clearly better. I don't know enough details about revs of the NG firmware to give a more specific answer.
3) Why is one longer than the other?
I think that's explained above.
4) What is the difference between "JVC" and "JVC{2}"
in the IR tool output?
JVC{2} means that DecodeIR sees a JVC repeat frame with enough separation from the JVC initial burst that it thinks the repeat frame occurs alone without the initial burst. It processes the raw data with a narrow enough focus that from its point of view that is a correct decode for this signal.
