tux-droid-user

[tuxdroid-user] RC5 again

[Philippe T. <ph...@te...>]

Hi,

I think there should still be some problems in RC5 reception:

I see that for some of the codes my Philips remote send, the tux can see 
them if I don't point directly the remote to it but points in a 
different direction and I've consistent results replaying the experience.
So my guess is that there is some detection issue when the signal is too 
bright for some bit patterns, e.g. especially if address = 0 (TV)
There is no reason the codes of my remote wouldn't be RC5 for TV but RC5 
for CD/VCR/Sat etc
and moreover my TV accepts RC5 sent by the Tux.

Now how could we debug that?

Phil

Re: [tuxdroid-user] RC5 again

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

On Thu, 12 Apr 2007 23:57:51 +0200, Philippe Teuwen <ph...@te...>  =

wrote:

> Hi,
>
> I think there should still be some problems in RC5 reception:
>
> I see that for some of the codes my Philips remote send, the tux can s=
ee
> them if I don't point directly the remote to it but points in a
> different direction and I've consistent results replaying the experien=
ce.
> So my guess is that there is some detection issue when the signal is t=
oo
> bright for some bit patterns, e.g. especially if address =3D 0 (TV)
> There is no reason the codes of my remote wouldn't be RC5 for TV but R=
C5
> for CD/VCR/Sat etc
> and moreover my TV accepts RC5 sent by the Tux.
>
> Now how could we debug that?
>

Well, when I go to Brussels, I can take my oscilloscope with me and have=
 a  =

look at your tux :-)

Or as I have plans to change that to be a kind of universal  =

receiver/emitter, the thing to do is sample the received code at a highe=
r  =

frequency and send the raw data to the computer. That should give us an =
 =

idea of the signal your tux receives.

Re: [tuxdroid-user] RC5 again

[Philippe T. <ph...@te...>]

> Well, when I go to Brussels, I can take my oscilloscope with me and 
> have a look at your tux :-)
I've an oscillo, but simple 25MHz analog, no screenshot capa :-(
> Or as I have plans to change that to be a kind of universal 
> receiver/emitter, the thing to do is sample the received code at a 
> higher frequency and send the raw data to the computer. That should 
> give us an idea of the signal your tux receives.
Yep.
I can try also to sample it via my soundcard but I'm not sure the analog 
input bandwith is good enough.

Sth else: I opened my Tux and noticed one of the cables was dangerously 
squeezed by a screw, I'll send you the picture in private, no reason to 
pollute the mailing-list.

Phil

Re: [tuxdroid-user] RC5 again

[Philippe T. <ph...@te...>]

> Or as I have plans to change that to be a kind of universal 
> receiver/emitter, the thing to do is sample the received code at a 
> higher frequency and send the raw data to the computer. That should 
> give us an idea of the signal your tux receives.
I remember of a quite efficient way a program on my HP48 worked to act 
as universal remote:
It encodes the stream as a succession of counter values, each of them 
being the duration of a receiving/non-receiving state. If a duration 
exceeds 256 then special value is used to code duration on more than one 
byte (thinks of UTF-8 coding style).
The result still takes some bytes, could take quite a lot of time to 
transmit with the small packets of the radio :-/
We could also have a look at the way lirc encodes learned codes and use 
directly that coding on the tux.

BTW what is the IR receiver hardware? Does it demodulates already the 
36kHz and outputs in TTL?
In other words, do we have to sample the modulation or just the 
bits/Manchester-bits?

Phil

Re: [tuxdroid-user] RC5 again

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

On Fri, 13 Apr 2007 00:34:30 +0200, Philippe Teuwen <ph...@te...>  
wrote:

>
>> Or as I have plans to change that to be a kind of universal
>> receiver/emitter, the thing to do is sample the received code at a
>> higher frequency and send the raw data to the computer. That should
>> give us an idea of the signal your tux receives.
> I remember of a quite efficient way a program on my HP48 worked to act
> as universal remote:
> It encodes the stream as a succession of counter values, each of them
> being the duration of a receiving/non-receiving state. If a duration
> exceeds 256 then special value is used to code duration on more than one
> byte (thinks of UTF-8 coding style).
> The result still takes some bytes, could take quite a lot of time to
> transmit with the small packets of the radio :-/

I once found an application note of cypress that did just that, that's  
pretty neat imo. I'll try to find the link again.

> We could also have a look at the way lirc encodes learned codes and use
> directly that coding on the tux.

That's what I'd like to know before changing the IR emiter/receiver  
functions. We certainly want to benefit from lirc and there are already  
some simple homemade IR receivers for lirc. It's maybe better to do  
something compatible with that instead of having a custom coding and  
writing a specific lirc driver.

> BTW what is the IR receiver hardware? Does it demodulates already the
> 36kHz and outputs in TTL?
> In other words, do we have to sample the modulation or just the
> bits/Manchester-bits?

It uses a common IR receiver module which demodulates the 37.9kHz and  
outputs the logical signal bits directly. Actually it's the 940nm IR light  
wave which is modulated at 37.9kHz and pulsed with the logical signal for  
the coding and protocol which is RC5 here (manchester coding.)

david

Re: [tuxdroid-user] RC5 again

[Florent T. <ft...@gm...>]

> > BTW what is the IR receiver hardware? Does it demodulates already the
> > 36kHz and outputs in TTL?
> > In other words, do we have to sample the modulation or just the
> > bits/Manchester-bits?
>
> It uses a common IR receiver module which demodulates the 37.9kHz and
> outputs the logical signal bits directly. Actually it's the 940nm IR light
> wave which is modulated at 37.9kHz and pulsed with the logical signal for
> the coding and protocol which is RC5 here (manchester coding.)

Does it mean that the fux does recieve the digital raw output exactly
like as if the IR transceiver was on board, which would mean the
possibility of having a /dev/lirc and a tty?

Florent

Re: [tuxdroid-user] RC5 again

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

On Fri, 13 Apr 2007 10:41:16 +0200, Florent THIERY <ft...@gm...>  
wrote:

>> > BTW what is the IR receiver hardware? Does it demodulates already the
>> > 36kHz and outputs in TTL?
>> > In other words, do we have to sample the modulation or just the
>> > bits/Manchester-bits?
>>
>> It uses a common IR receiver module which demodulates the 37.9kHz and
>> outputs the logical signal bits directly. Actually it's the 940nm IR  
>> light
>> wave which is modulated at 37.9kHz and pulsed with the logical signal  
>> for
>> the coding and protocol which is RC5 here (manchester coding.)
>
> Does it mean that the fux does recieve the digital raw output exactly
> like as if the IR transceiver was on board, which would mean the
> possibility of having a /dev/lirc and a tty?

No, Tux gets it but needs to send that through the RF frames so the  
received signal has to be coded somehow. But then on the other side (fux)  
we could expand the code into something lirc can accept, or that can be  
done n the computer by the daemon or anything else.

david