Re: Can I expect in-kernel decoding to work out of box?

[Andy Walls <awalls@md.metrocast.net>]

On Wed, 2010-07-28 at 09:46 -0400, Jon Smirl wrote:
> Let's be really sure it is NEC and not JVC.
> 
> > >    8850     4350      525     1575      525     1575
> > >     525      450      525      450      525      450
> > >     525      450      525     1575      525      450
> > >     525     1575      525      450      525     1575
> > >     525      450      525      450      525     1575
> > >     525      450      525      450      525    23625
> 
> 
> NEC timings are 9000 4500 560 1680 560 560 etc
> 
> JVC timings are 8400 4200 525 1575 525 525
> 
> It is a closer match to the JVC timing.  But neither protocol uses a
> different mark/space timing -- 450 vs 525

I assume you mean "different mark/space timing for the symbol for which
they are the same length" (in NEC that's the '0' symbol IIRC).
  

I've noticed different mark/space timings for the '0' symbol from NEC
remotes and with some RC-5 remotes.  I usually attribute it to cheap
remote designs, weak batteries, capacitive effects, receiver pulse
measurement technique, etc.

Here's an example of NEC remote from a DTV STB remote as measured by the
CX23888 IR receiver on an HVR-1850:

8257296 ns  mark
4206185 ns  space
        leader
 482926 ns  mark
 545296 ns  space
        0
 481296 ns  mark
1572259 ns  space
        1
 481148 ns  mark
 546333 ns  space
        0
 479963 ns  mark
 551815 ns  space
        0
 454333 ns  mark
1615519 ns  space
        1
 435074 ns  mark
 591370 ns  space
[...]

I don't know the source of the error.  I would have to check the same
remote against my MCE USB receiver to try and determine any receiver
induced measurement errors.

But, in Maxim's case, the difference isn't bad: 450/525 ~= 86%.  I would
hope a 15% difference would still be recognizable.


> Also look at the repeats. This is repeating at about 25ms. NEC repeat
> spacing is 110ms. JVC is supposed to be at 50-60ms. NEC does not
> repeat the entire command and JVC does. The repeats are closer to
> following the JVC model.
> 
> I'd say this is a JVC command. So the question is, why didn't JVC
> decoder get out of state zero?

Is JVC enabled by default?  I recall analyzing that it could generate
false positives on NEC codes.

Regards,
Andy