RC6 decoding

The current decoder for the RC6 IR protocol supports mode 0 (16 bit) and
mode 6A.  In mode 6A the decoder supports either 32-bit data (for
Microsoft's MCE RC) or 24 bit.

I would like to support a Sky/Sky+ standard RC which transmits RC6-6-20
i.e. 20 bit data.  The transmitted frame format is identical to the 24
bit form so I'm curious as to what remotes transmit 24 bit data or was
this an error and it should be 20?

RC6-6-20 is explained here:
http://www.guiott.com/wrc/RC6-6.html

If 24-bit mode is in use, is there a way to select between 20 and 24 bit
operation?

I made the following simple mod to ir-rc6-decoder.c and my Sky/Sky+ RCs
decode correctly (with a custom keytable):
  

Em 19-09-2011 08:12, Lawrence Rust escreveu:
> The current decoder for the RC6 IR protocol supports mode 0 (16 bit) and
> mode 6A.  In mode 6A the decoder supports either 32-bit data (for
> Microsoft's MCE RC) or 24 bit.
> 
> I would like to support a Sky/Sky+ standard RC which transmits RC6-6-20
> i.e. 20 bit data.  The transmitted frame format is identical to the 24
> bit form so I'm curious as to what remotes transmit 24 bit data or was
> this an error and it should be 20?
> 
> RC6-6-20 is explained here:
> http://www.guiott.com/wrc/RC6-6.html
> 
> If 24-bit mode is in use, is there a way to select between 20 and 24 bit
> operation?

You'll need to figure out a way to detect between them. It is probably not
hard to detect, and add support for both at the decider.
Maybe you can find something useful here:
	http://www.sbprojects.com/knowledge/ir/rc6.php


> 
> I made the following simple mod to ir-rc6-decoder.c and my Sky/Sky+ RCs
> decode correctly (with a custom keytable):
> 
> --- a/drivers/media/rc/ir-rc6-decoder.c	2011-05-19 06:06:34.000000000 +0200
> +++ b/drivers/media/rc/ir-rc6-decoder.c	2011-09-19 13:02:35.000000000 +0200
> @@ -17,14 +17,14 @@
>  /*
>   * This decoder currently supports:
>   * RC6-0-16	(standard toggle bit in header)
> - * RC6-6A-24	(no toggle bit)
> + * RC6-6A-20	(no toggle bit)
>   * RC6-6A-32	(MCE version with toggle bit in body)
>   */
>  
>  #define RC6_UNIT		444444	/* us */
>  #define RC6_HEADER_NBITS	4	/* not including toggle bit */
>  #define RC6_0_NBITS		16
> -#define RC6_6A_SMALL_NBITS	24
> +#define RC6_6A_SMALL_NBITS	20
>  #define RC6_6A_LARGE_NBITS	32
>  #define RC6_PREFIX_PULSE	(6 * RC6_UNIT)
>  #define RC6_PREFIX_SPACE	(2 * RC6_UNIT)
> @@ -231,7 +231,7 @@ again:
>  				scancode = data->body & ~RC6_6A_MCE_TOGGLE_MASK;
>  			} else {
>  				toggle = 0;
> -				scancode = data->body & 0xffffff;
> +				scancode = data->body;
>  			}
>  
>  			IR_dprintk(1, "RC6(6A) scancode 0x%08x (toggle: %u)\n",
> 
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
  

On Fri, 2011-09-23 at 20:43 -0300, Mauro Carvalho Chehab wrote:
> Em 19-09-2011 08:12, Lawrence Rust escreveu:
> > The current decoder for the RC6 IR protocol supports mode 0 (16 bit) and
> > mode 6A.  In mode 6A the decoder supports either 32-bit data (for
> > Microsoft's MCE RC) or 24 bit.
> > 
> > I would like to support a Sky/Sky+ standard RC which transmits RC6-6-20
> > i.e. 20 bit data.  The transmitted frame format is identical to the 24
> > bit form so I'm curious as to what remotes transmit 24 bit data or was
> > this an error and it should be 20?
> > 
> > RC6-6-20 is explained here:
> > http://www.guiott.com/wrc/RC6-6.html
> > 
> > If 24-bit mode is in use, is there a way to select between 20 and 24 bit
> > operation?
> 
> You'll need to figure out a way to detect between them. It is probably not
> hard to detect, and add support for both at the decider.
> Maybe you can find something useful here:
> 	http://www.sbprojects.com/knowledge/ir/rc6.php

Lawrence:

Some RC-6 explanations with more detail could be found here:
 
http://slycontrol.ru/scr/kb/rc6.htm (dead; not in the Wayback machine :( )
http://www.picbasic.nl/info_rc6_uk.htm

You might also find this thread of interest for some history:
http://www.spinics.net/lists/linux-input/msg07983.html

The take away is that the data length is, in theory, OEM dependent for
RC-6 Mode 6A, limited to a max of 24 bits (3 bytes) after a short
customer code and 128 bits (16 bytes) after a long customer code.

In that previous thread, I suggested it might be better to look for the
signal free time of 6 RC6_UNITs to declare the end of reception, instead
of a bit count.  Maybe that is a way to deal with the current problem.

Regards,
Andy

> > 
> > I made the following simple mod to ir-rc6-decoder.c and my Sky/Sky+ RCs
> > decode correctly (with a custom keytable):
> > 
> > --- a/drivers/media/rc/ir-rc6-decoder.c	2011-05-19 06:06:34.000000000 +0200
> > +++ b/drivers/media/rc/ir-rc6-decoder.c	2011-09-19 13:02:35.000000000 +0200
> > @@ -17,14 +17,14 @@
> >  /*
> >   * This decoder currently supports:
> >   * RC6-0-16	(standard toggle bit in header)
> > - * RC6-6A-24	(no toggle bit)
> > + * RC6-6A-20	(no toggle bit)
> >   * RC6-6A-32	(MCE version with toggle bit in body)
> >   */
> >  
> >  #define RC6_UNIT		444444	/* us */
> >  #define RC6_HEADER_NBITS	4	/* not including toggle bit */
> >  #define RC6_0_NBITS		16
> > -#define RC6_6A_SMALL_NBITS	24
> > +#define RC6_6A_SMALL_NBITS	20
> >  #define RC6_6A_LARGE_NBITS	32
> >  #define RC6_PREFIX_PULSE	(6 * RC6_UNIT)
> >  #define RC6_PREFIX_SPACE	(2 * RC6_UNIT)
> > @@ -231,7 +231,7 @@ again:
> >  				scancode = data->body & ~RC6_6A_MCE_TOGGLE_MASK;
> >  			} else {
> >  				toggle = 0;
> > -				scancode = data->body & 0xffffff;
> > +				scancode = data->body;
> >  			}
> >  
> >  			IR_dprintk(1, "RC6(6A) scancode 0x%08x (toggle: %u)\n",
> > 
> > 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
  

On Sat, 2011-09-24 at 09:16 -0400, Andy Walls wrote:
> On Fri, 2011-09-23 at 20:43 -0300, Mauro Carvalho Chehab wrote:
> > Em 19-09-2011 08:12, Lawrence Rust escreveu:
> > > The current decoder for the RC6 IR protocol supports mode 0 (16 bit) and
> > > mode 6A.  In mode 6A the decoder supports either 32-bit data (for
> > > Microsoft's MCE RC) or 24 bit.
> > > 
> > > I would like to support a Sky/Sky+ standard RC which transmits RC6-6-20
> > > i.e. 20 bit data.  The transmitted frame format is identical to the 24
> > > bit form so I'm curious as to what remotes transmit 24 bit data or was
> > > this an error and it should be 20?
> > > 
> > > RC6-6-20 is explained here:
> > > http://www.guiott.com/wrc/RC6-6.html
> > > 
> > > If 24-bit mode is in use, is there a way to select between 20 and 24 bit
> > > operation?
> > 
> > You'll need to figure out a way to detect between them. It is probably not
> > hard to detect, and add support for both at the decider.
> > Maybe you can find something useful here:
> > 	http://www.sbprojects.com/knowledge/ir/rc6.php
> 
> Lawrence:
> 
> Some RC-6 explanations with more detail could be found here:
>  
> http://slycontrol.ru/scr/kb/rc6.htm (dead; not in the Wayback machine :( )

I found where the above website moved: :)

http://slydiman.narod.ru/scr/kb/rc6.htm

-Andy

> http://www.picbasic.nl/info_rc6_uk.htm
> 
> You might also find this thread of interest for some history:
> http://www.spinics.net/lists/linux-input/msg07983.html
> 
> The take away is that the data length is, in theory, OEM dependent for
> RC-6 Mode 6A, limited to a max of 24 bits (3 bytes) after a short
> customer code and 128 bits (16 bytes) after a long customer code.
> 
> In that previous thread, I suggested it might be better to look for the
> signal free time of 6 RC6_UNITs to declare the end of reception, instead
> of a bit count.  Maybe that is a way to deal with the current problem.
> 
> Regards,
> Andy
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
  

On Sat, 2011-09-24 at 09:39 -0400, Andy Walls wrote:
> On Sat, 2011-09-24 at 09:16 -0400, Andy Walls wrote:
> > On Fri, 2011-09-23 at 20:43 -0300, Mauro Carvalho Chehab wrote:
> > > Em 19-09-2011 08:12, Lawrence Rust escreveu:
> > > > The current decoder for the RC6 IR protocol supports mode 0 (16 bit) and
> > > > mode 6A.  In mode 6A the decoder supports either 32-bit data (for
> > > > Microsoft's MCE RC) or 24 bit.
> > > > 
> > > > I would like to support a Sky/Sky+ standard RC which transmits RC6-6-20
> > > > i.e. 20 bit data.  The transmitted frame format is identical to the 24
> > > > bit form so I'm curious as to what remotes transmit 24 bit data or was
> > > > this an error and it should be 20?
> > > > 
> > > > RC6-6-20 is explained here:
> > > > http://www.guiott.com/wrc/RC6-6.html
> > > > 
> > > > If 24-bit mode is in use, is there a way to select between 20 and 24 bit
> > > > operation?
> > > 
> > > You'll need to figure out a way to detect between them. It is probably not
> > > hard to detect, and add support for both at the decider.
> > > Maybe you can find something useful here:
> > > 	http://www.sbprojects.com/knowledge/ir/rc6.php
> > 
> > Lawrence:
> > 
> > Some RC-6 explanations with more detail could be found here:
> >  
> > http://slycontrol.ru/scr/kb/rc6.htm (dead; not in the Wayback machine :( )
> 
> I found where the above website moved: :)
> 
> http://slydiman.narod.ru/scr/kb/rc6.htm
> 
> -Andy
> 
> > http://www.picbasic.nl/info_rc6_uk.htm
> > 
> > You might also find this thread of interest for some history:
> > http://www.spinics.net/lists/linux-input/msg07983.html
> > 
> > The take away is that the data length is, in theory, OEM dependent for
> > RC-6 Mode 6A, limited to a max of 24 bits (3 bytes) after a short
> > customer code and 128 bits (16 bytes) after a long customer code.
> > 
> > In that previous thread, I suggested it might be better to look for the
> > signal free time of 6 RC6_UNITs to declare the end of reception, instead
> > of a bit count.  Maybe that is a way to deal with the current problem.

Andy,

Many thanks for the pointers - they confirm that the Sky RC is just
using a shortened but permissible form of 24 bit.  So your suggestion of
looking for a stop sequence is probably the only/best way.  In fact it
would actually correct the current implementation which assumes a fixed
length of 24 or 32 bits.

If I wrote a patch that handles variable data lengths (up to 24 or 128
bits) would you be willing to review it?

I can test with a Sky RC and I also have a MCEUSB RC on order which
should hopefully arrive next week.  So that should test the current
32-bit case.
  

On Sat, 2011-09-24 at 18:42 +0200, Lawrence Rust wrote:
> On Sat, 2011-09-24 at 09:39 -0400, Andy Walls wrote:
> > On Sat, 2011-09-24 at 09:16 -0400, Andy Walls wrote:
> > > On Fri, 2011-09-23 at 20:43 -0300, Mauro Carvalho Chehab wrote:
> > > > Em 19-09-2011 08:12, Lawrence Rust escreveu:
> > > > > The current decoder for the RC6 IR protocol supports mode 0 (16 bit) and
> > > > > mode 6A.  In mode 6A the decoder supports either 32-bit data (for
> > > > > Microsoft's MCE RC) or 24 bit.
> > > > > 
> > > > > I would like to support a Sky/Sky+ standard RC which transmits RC6-6-20
> > > > > i.e. 20 bit data.  The transmitted frame format is identical to the 24
> > > > > bit form so I'm curious as to what remotes transmit 24 bit data or was
> > > > > this an error and it should be 20?
> > > > > 
> > > > > RC6-6-20 is explained here:
> > > > > http://www.guiott.com/wrc/RC6-6.html
> > > > > 
> > > > > If 24-bit mode is in use, is there a way to select between 20 and 24 bit
> > > > > operation?
> > > > 
> > > > You'll need to figure out a way to detect between them. It is probably not
> > > > hard to detect, and add support for both at the decider.
> > > > Maybe you can find something useful here:
> > > > 	http://www.sbprojects.com/knowledge/ir/rc6.php
> > > 
> > > Lawrence:
> > > 
> > > Some RC-6 explanations with more detail could be found here:
> > >  
> > > http://slycontrol.ru/scr/kb/rc6.htm (dead; not in the Wayback machine :( )
> > 
> > I found where the above website moved: :)
> > 
> > http://slydiman.narod.ru/scr/kb/rc6.htm
> > 
> > -Andy
> > 
> > > http://www.picbasic.nl/info_rc6_uk.htm
> > > 
> > > You might also find this thread of interest for some history:
> > > http://www.spinics.net/lists/linux-input/msg07983.html
> > > 
> > > The take away is that the data length is, in theory, OEM dependent for
> > > RC-6 Mode 6A, limited to a max of 24 bits (3 bytes) after a short
> > > customer code and 128 bits (16 bytes) after a long customer code.
> > > 
> > > In that previous thread, I suggested it might be better to look for the
> > > signal free time of 6 RC6_UNITs to declare the end of reception, instead
> > > of a bit count.  Maybe that is a way to deal with the current problem.
> 
> Andy,
> 
> Many thanks for the pointers - they confirm that the Sky RC is just
> using a shortened but permissible form of 24 bit.  So your suggestion of
> looking for a stop sequence is probably the only/best way.  In fact it
> would actually correct the current implementation which assumes a fixed
> length of 24 or 32 bits.
> 
> If I wrote a patch that handles variable data lengths (up to 24 or 128
> bits) would you be willing to review it?

Yes, I can.  Review will probably need to include a quick skim of all
the current IR hardware drivers and RC infrastructure, to ensure a final
space is propagated to the RC-6 decoder.

Today I'll have time.

My next available date for doing Linux stuff will likely be on 10
October and then 15 October.  (A benefit of a very full schedule is
knowing when I won't have time for things. :P )

Regards,
Andy

> I can test with a Sky RC and I also have a MCEUSB RC on order which
> should hopefully arrive next week.  So that should test the current
> 32-bit case.



--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html