Re: Remote that breaks current system

Jon Smirl
2010-08-02T17:13:24Z

On Mon, Aug 2, 2010 at 12:42 PM, Christoph Bartelmus <lirc@bartelmus.de> 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. ;-)

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@gmail.com