Content-Type: multipart/alternative; boundary="------------070700040201020108080501" --------------070700040201020108080501 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 >> I saved some traces in a google doc. You can see them here: >> >> http://goo.gl/sHAAHc >> >> To me it looks like a modified RC6 protocol. The Toggle bit seems to be >> moved to about 2/3 of the way through the trace. Any thoughts? >> >> Jason > Hello Jason, > > Your receiver provides mark and space timing data as shown by the ability of irrecord to create raw_codes data and the fact that xmode2 and mode2 work therefore all the protocol decoding is performed by the lirc daemon or kernel depending on your configuration (it should handle all supported protocols). The problem is that it is missing chunks of the data. > > The logic analyser traces look good, they won't be the same as described in my links above they are using a different RC6 mode (6) which provides 32 bits, see my annotated trace attached. > > The header and bit timing look to be standard but there is no trace showing the gap so you will have to provide a value in the template configuration file attached. Details of the configuration file are given in: > http://winlirc.sourceforge.net/technicaldetails.html > > Martin > > Hi Martin, After much mucking around and lirc deteriorating from being able to at least make traces to not doing anything, I tested the receiver on my other linux box where it seems to work perfeclty. Your pointers as to it being rc6 was great. irrecord managed to record it almost flawlessly, except it seemed to get the toggle_bit_mask wrong. I learning the same key twice and xored the two values to get the correct bitmask. Now it seems to work perfectly on this machine which is running: Linux 3.2.0-2-486 and lircd 0.9.0-pre1 On the machine where lirc doesn't seem to work correctly, its running: Linux rachid 3.2.0-4-amd64 and lircd 0.9.0-pre1 any ideas why it might work fine on one machine and not on the other? I've attached copy of the config file I generated in case someone finds it useful. Thanks again for your help. Jason -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSRuciAAoJEPpXHsdQXnZOdD8QAJ+iYuvNd+WRkpwhyqsLcvJv hhkyOvxNHvH3jYk+x+FOY1F6uVigkGF25SxAAD7K8TzORnnqDnlv9t7ZS/6xZrIj fk5CRq50iUg0s/N3GGIhU1TW7h+jla0xx4tjNKJzm2pIMJGgdhontKZoq4bLaQ1i yv6BdYcq8iSYnB6ph7P/k4vVDbVAm4KDnPguDYKj8j2cYwK7dmvra27J8nsHMFAD PK3hthsPfaKgbBbm2zRBVrTrPENej7kHKrL2+yc5fb6Slgx8Vl8lWwnTf/iU8Z/f Ur4HAtZ48ozIElM6UkicDEaHd3YfIU3fhl1R93HHwamqMD2ZEfAxjybPaw41tK32 k0NpJtuOQ/N4gE2ePHkhnp0tUafgMQkQVKBQxzojIXjvuHlq8TIEopCBbBTMEhV1 quIuIaFDR1D2alcxPH5VwczWFgk7RdhBY8HgbzrgQv2QQaqxwC8N8qqq08+00kFn gDZVajw6+0Qrx9JfRefesmyzF9T98yCOXpx41Famm8Otg92J6iFjjc5P45yXPZCK o4wg+/10IFtpixMJF/M+tkpvZFwA9n6V3/Jqy3QPaTl/Ke0eKzqbHDHLEhprDx4S SU6rzpELwNV16gTVyvvv2pRR9lrznvShuL9s161XAZV1a3xOC6YUDWNBhLUyI4jj Gi2Okpgn1oZV1omyaCUV =7Se6 -----END PGP SIGNATURE----- --------------070700040201020108080501 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

>> I saved some traces in a google doc. You can see them here:
>>
>> http://goo.gl/sHAAHc
>>
>> To me it looks like a modified RC6 protocol. The Toggle bit seems to be
>> moved to about 2/3 of the way through the trace. Any thoughts?
>>
>> Jason
> Hello Jason,
>
> Your receiver provides mark and space timing data as shown by the ability of irrecord to create raw_codes data and the fact that xmode2 and mode2 work therefore all the protocol decoding is performed by the lirc daemon or kernel  depending on your configuration (it should handle all supported protocols). The problem is that it is missing chunks of the data.
>
> The logic analyser traces look good, they won't be the same as described in my links above they are using a different RC6 mode (6) which provides 32 bits, see my annotated trace attached.
>
> The header and bit timing look to be standard but there is no trace showing the gap so you will have to provide a value in the template configuration file attached. Details of the configuration file are given in:
> http://winlirc.sourceforge.net/technicaldetails.html
>
> Martin
>
>

Hi Martin,

After much mucking around and lirc deteriorating from being able to at least make traces to not doing anything, I tested the receiver on my other linux box where it seems to work perfeclty. Your pointers as to it being rc6 was great. irrecord managed to record it almost flawlessly, except it seemed to get the toggle_bit_mask wrong. I learning the same key twice and xored the two values to get the correct bitmask.

Now it seems to work perfectly on this machine which is running:
Linux  3.2.0-2-486 and lircd 0.9.0-pre1

On the machine where lirc doesn't seem to work correctly, its running:
Linux rachid 3.2.0-4-amd64 and lircd 0.9.0-pre1

any ideas why it might work fine on one machine and not on the other?

I've attached copy of the config file I generated in case someone finds it useful.

Thanks again for your help.

Jason
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (Darwin)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJSRuciAAoJEPpXHsdQXnZOdD8QAJ+iYuvNd+WRkpwhyqsLcvJv
hhkyOvxNHvH3jYk+x+FOY1F6uVigkGF25SxAAD7K8TzORnnqDnlv9t7ZS/6xZrIj
fk5CRq50iUg0s/N3GGIhU1TW7h+jla0xx4tjNKJzm2pIMJGgdhontKZoq4bLaQ1i
yv6BdYcq8iSYnB6ph7P/k4vVDbVAm4KDnPguDYKj8j2cYwK7dmvra27J8nsHMFAD
PK3hthsPfaKgbBbm2zRBVrTrPENej7kHKrL2+yc5fb6Slgx8Vl8lWwnTf/iU8Z/f
Ur4HAtZ48ozIElM6UkicDEaHd3YfIU3fhl1R93HHwamqMD2ZEfAxjybPaw41tK32
k0NpJtuOQ/N4gE2ePHkhnp0tUafgMQkQVKBQxzojIXjvuHlq8TIEopCBbBTMEhV1
quIuIaFDR1D2alcxPH5VwczWFgk7RdhBY8HgbzrgQv2QQaqxwC8N8qqq08+00kFn
gDZVajw6+0Qrx9JfRefesmyzF9T98yCOXpx41Famm8Otg92J6iFjjc5P45yXPZCK
o4wg+/10IFtpixMJF/M+tkpvZFwA9n6V3/Jqy3QPaTl/Ke0eKzqbHDHLEhprDx4S
SU6rzpELwNV16gTVyvvv2pRR9lrznvShuL9s161XAZV1a3xOC6YUDWNBhLUyI4jj
Gi2Okpgn1oZV1omyaCUV
=7Se6
-----END PGP SIGNATURE-----

--------------070700040201020108080501--