On Mon, Aug 02, 2010 at 06:42:00PM +0200, Christoph Bartelmus wrote: > Hi! > > Jon Smirl "jonsmirl@xxxxxxxxx" 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@xxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
