Re: Remote that breaks current system

[Jarod Wilson <jarod@redhat.com>]

On Mon, Aug 02, 2010 at 06:42:00PM +0200, Christoph Bartelmus wrote:
> Hi!
> 
> Jon Smirl "jonsmirl@gmail.com" wrote:
> [...]
> >> Got one. The Streamzap PC Remote. Its 14-bit RC5. Can't get it to properly
> >> decode in-kernel for the life of me. I got lirc_streamzap 99% of the way
> >> ported over the weekend, but this remote just won't decode correctly w/the
> >> in-kernel RC5 decoder.
> 
> > Manchester encoding may need a decoder that waits to get 2-3 edge
> > changes before deciding what the first bit. As you decode the output
> > is always a couple bits behind the current input data.
> >
> > You can build of a table of states
> > L0 S1 S0 L1  - emit a 1, move forward an edge
> > S0 S1 L0 L1 - emit a 0, move forward an edge
> >
> > By doing it that way you don't have to initially figure out the bit clock.
> >
> > The current decoder code may not be properly tracking the leading
> > zero. In Manchester encoding it is illegal for a bit to be 11 or 00.
> > They have to be 01 or 10. If you get a 11 or 00 bit, your decoding is
> > off by 1/2 a bit cycle.
> >
> > Did you note the comment that Extended RC-5 has only a single start
> > bit instead of two?
> 
> It has nothing to do with start bits.
> The Streamzap remote just sends 14 (sic!) bits instead of 13.
> The decoder expects 13 bits.
> Yes, the Streamzap remote does _not_ use standard RC-5.
> Did I mention this already? Yes. ;-)

D'oh, yeah, sorry, completely forgot you already mentioned this. That
would certainly explain why the rc5 decoder isn't happy with it. So the
*receiver* itself is perfectly functional, its just a goofy IR protocol
sent by its default remote. Blah. So yet another reason having ongoing
lirc compatibility is a Good Thing. ;)

-- 
Jarod Wilson
jarod@redhat.com