Your Universal Remote Control Center
RemoteCentral.com
Discrete Code Hunter Forum - View Post
Previous section Next section Up level
Up level
The following page was printed from RemoteCentral.com:

Login:
Pass:
 
 

Topic:
IR Question
This thread has 1 response. Displaying all posts.
Post 1 made on Sunday December 2, 2007 at 21:34
sam.roberts
Lurking Member
Joined:
Posts:
November 2007
6
Hi. I'm hoping someone (John?) can explain the following regarding JVC TV IR codes. In the files section, under discrete codes, the following is listed as the VIDEO 1 discrete for JVC TVs:

0000 006c 0012 0011 0142 00a2 0014 003d 0014 003d 0014 0014 0014 0014 0014 0014 0014 0014 0014 0014 0014 0014 0014 003d 0014 0014 0014 0014 0014 0014 0014 003d 0014 0014 0014 0014 0014 0014 0014 03c5 0014 003d 0014 003d 0014 0014 0014 0014 0014 0014 0014 0014 0014 0014 0014 0014 0014 003d 0014 0014 0014 0014 0014 0014 0014 003d 0014 0014 0014 0014 0014 0014 0014 03d2

The pronto IR tool decodes this as:

Protocol: JVC
Device: 3
OBC: 17
EFC: 121

Protocol:JVC{2}
Device: 3
OBC: 17
EFC: 121

The JVC Discrete IR Code PDF lists VIDEO/INPUT 1 as Custom Code 3, Data Code 11 (HEX) (= 17 DECIMAL).

When I generate the code using makehex and device 3, function 17, I get the following IR code:

0000 006D 0001 0011 0141 00A0 0014 003C 0014 003C 0014 0014 0014 0014 0014 0014 0014 0014 0014 0014 0014 0014 0014 003C 0014 0014 0014 0014 0014 0014 0014 003C 0014 0014 0014 0014 0014 0014 0014 03AE

Which IR Tool decodes as:

Protocol: JVC
Device: 3
OBC: 17
EFC: 121

So my questions are:

1) Are these codes the same?

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? Is there some reason to prefer one over the other?

3) Why is one longer than the other?

4) What is the difference between "JVC" and "JVC{2}" in the IR tool output?

Thanks!
Post 2 made on Monday December 3, 2007 at 09:03
johnsfine
IR Expert
Joined:
Posts:
September 2002
5,159
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.

Jump to


Protected Feature Before you can reply to a message...
You must first register for a Remote Central user account - it's fast and free! Or, if you already have an account, please login now.

Please read the following: Unsolicited commercial advertisements are absolutely not permitted on this forum. Other private buy & sell messages should be posted to our Marketplace. For information on how to advertise your service or product click here. Remote Central reserves the right to remove or modify any post that is deemed inappropriate.

Hosting Services by ipHouse