On Mon, Aug 2, 2010 at 12:42 PM, Christoph Bartelmus <lirc@xxxxxxxxxxxx> 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. ;-) If the remote is sending a weird protocol then there are several choices: 1) implement raw mode 2) make a Stream-Zap protocol engine (it would be a 14b version of RC-5). Standard RC5 engine will still reject the messages. 3) throw away your Stream-Zap remotes I'd vote for #3, but #2 will probably make people happier. > > Christoph > -- Jon Smirl jonsmirl@xxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
