Re: [tuxdroid-user] Tuxdroid gamepad interface

[David B. <da...@ja...>]

On Tue, 10 Apr 2007 00:51:34 +0200, Philippe Teuwen <ph...@te...>  
wrote:

>>> - IR codes
>>>
>>
>> Should use the GNU/Linux IR API (don't know it).
>>
> I agree we could beneficiate from a separate API for the IR part.
> I had a look to LIRC but it looks like there isn't much of common API  
> here.
> And we get directly RC5 codes while usually LIRC gets more raw data
> and is therefore capable to understand a larger set of remote controls.
> But we definitively need to find a way to hook the tuxdroid to lirc!
> Note that looking to the firmware gives me the confidence the tuxdroid  
> could
> also receive more than just RC5 codes and the firmware could be as smart
> as lirc to decode a variety of rc or pipe raw IR data to lirc.
>
The firmware currently decodes the RC5 protocol. Out of this, only the  
command is sent back to the computer, the address is not but that  
shouldn't be a problem to send it too. The advantage of decoding directly  
is to get a single byte out of the IR event and be able to handle it  
locally like in the remote mode.

I planned to change this by a universal emitter/receiver where the IR  
signal would be sampled much more quickly and the raw code would be  
compressed (optioanl) and sent to the computer for decoding. There are  
numerous application notes describing this for various microcontrollers. I  
think it would be better to mimic what some of the already existing  
homemade IR peripherals do as we could benefit from its LIRC driver  
without much modifications.

The only problem I see is the RF bandwidth, for commands we can send 4  
bytes each 2 ms maximum but I believe the current spi protocol between the  
audio CPU and the RF only allows 4 bytes each 4ms (tbc). We need the first  
byte for the command identification, the second byte for the index and the  
last 2 bytes for the data, which means it will take a lot of time to send  
a raw code to the computer. That's one part of the RF protocol I didn't  
like from the beginning. All frames holds 64 bytes or so which most of  
them are just audio data, leaving only 4 bytes for commands. This is fine  
in most cases but I would have preferred to have different kind of frames,  
some of which could be data only in order to have a much bigger data  
bandwidth.

david