tux-droid-user — tuxdroid-user

[tuxdroid-user] Who's who for developers on the wiki

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

Hi all,

After many adventures to contact "neimad" I decided to create a who's 
who page so everybody willing to give some contact info can do so (be 
careful at email suckers, mangle yours).

http://www2.tux-is-alive.com/wiki/Who%27s_who

Feel free to edit and provide the info you're ok to give (email, jabber, 
IRC nickname, bank account for generous donators,... just kidding)

Phil

Re: [tuxdroid-user] last gtdi half broken

[Damien <ror...@gm...>]

Le samedi 14 avril 2007,
Philippe Teuwen <ph...@te...> a =C3=A9crit :

> Sometimes the refresh of the GUI doesn't happen, I can click and the
> tux reacts but the gui is not updated.
> When it happens, it happens from the start of the launch of gtdi,=20
> sometimes frozen with still the red cross on the ttsdaemon status.

Haven't witnessed this, but I didn't use gtdi much lately.

> If I click on radio button flips down, it does down,up,down
> If I click on radio button flips up, it does up,down,up,down,small
> pause,up
> If I click flap (1), it does up+down or down+up so 2
> movements (compared to 1 talk or 1 blink)

Same bug here.

Damien

[tuxdroid-user] last gtdi half broken

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

Hello,

I just tried the updated gtdi with the new python API and I've much more 
problems than before (the version still with the daemon buttons).

Sometimes the refresh of the GUI doesn't happen, I can click and the tux 
reacts but the gui is not updated.
When it happens, it happens from the start of the launch of gtdi, 
sometimes frozen with still the red cross on the ttsdaemon status.

If I click on radio button flips down, it does down,up,down
If I click on radio button flips up, it does up,down,up,down,small pause,up
If I click flap (1), it does up+down or down+up so 2 movements (compared 
to 1 talk or 1 blink)

Phil

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

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 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

[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

[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

[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.

[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] Daemon updates on svn

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

Thanks, forwarded to remi.

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

wrote:

>
>> Feel free to commit whatever you think is good on svn.
> ok ;-)
>> Will ask remi to do the same for the tuxttsdaemon.
> Ok but there will be some more changes for tuxttsdaemon.
> If we want to use the same least privileges principle we've to:
> - have sufficient privileges to open the ALSA channel
> - drop the privileges just after opening the channel
>
> But from this little test I can see that tuxttsdaemon
> tries to open the channel only when some text is rendered.
>
> nobody@mercure:/$ tuxttsdaemon
> -----------------------------------
> Tux TTS Daemon V0.2.9
> Acapela group Text to speech system
> Kysoh 2007.
> -----------------------------------
> Voice list:
> [Ryan8k]
> [Bruno8k]
> [Julie8k]
> [Heather8k]
> TCP server : started
> TCP server : client incomming
> ### oops little typo to fix here: *incoming*
>
> ### now from gtdi I try to play sth:
> ALSA lib pcm_hw.c:1357:(_snd_pcm_hw_open) Invalid value for card
> cannot open audio device hw:2,1 (No such device)
> Erreur de segmentation
> ### Some better error handling than core dump is welcome too ;-)
>
> And if the channel is not maintained opened all the time but
> reopened each time a text is rendered we cannot drop
> the privileges :-(
>
> There is a separate alsa channel only for tts, you could open
> the channel at startup, drop privs and keep it opened.
>
> Phil
>
>
> ----------------------------------------------------------------------=
---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to shar=
e  =

> your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=
=3DDEVDEV
> _______________________________________________
> tux-droid-user mailing list
> tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tux-droid-user

Re: [tuxdroid-user] Daemon updates on svn

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

> Feel free to commit whatever you think is good on svn. 
ok ;-)
> Will ask remi to do the same for the tuxttsdaemon.
Ok but there will be some more changes for tuxttsdaemon.
If we want to use the same least privileges principle we've to:
- have sufficient privileges to open the ALSA channel
- drop the privileges just after opening the channel

But from this little test I can see that tuxttsdaemon
tries to open the channel only when some text is rendered.

nobody@mercure:/$ tuxttsdaemon
-----------------------------------
Tux TTS Daemon V0.2.9
Acapela group Text to speech system
Kysoh 2007.
-----------------------------------
Voice list:
[Ryan8k]
[Bruno8k]
[Julie8k]
[Heather8k]
TCP server : started
TCP server : client incomming
### oops little typo to fix here: *incoming*

### now from gtdi I try to play sth:
ALSA lib pcm_hw.c:1357:(_snd_pcm_hw_open) Invalid value for card
cannot open audio device hw:2,1 (No such device)
Erreur de segmentation
### Some better error handling than core dump is welcome too ;-)

And if the channel is not maintained opened all the time but
reopened each time a text is rendered we cannot drop
the privileges :-(

There is a separate alsa channel only for tts, you could open
the channel at startup, drop privs and keep it opened.

Phil

Re: [tuxdroid-user] Daemon updates on svn

[Srikanta P. <sri...@gm...>]

On 4/12/07, David Bourgeois <da...@ja...> wrote:
> current daemon. Srikanta, I don't forget you but I still didn't get time
> to read and test your cpp daemon, but I'll do it for sure. But I keep
> looking at your commits with attention ;-)
>

Never mind (yet :-).
It still needs to walk quite a way to reach its end.
Haven't been able to work much on it from past 6
days, as I was a bit tied up in my work. Hoping to
get more time after this weekend! :-)

[tuxdroid-user] Daemon updates on svn

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

Philippe, I saw your commits for dropping privileges, I just tried the  
head revision and it works fine here. Feel free to commit whatever you  
think is good on svn. I don't manage the daemon myself and anyway you're  
much better than me so I don't see why I should review your patches for  
acceptance :-) Will ask remi to do the same for the tuxttsdaemon.

Also thanks to Damien (neimad) who also made some great job cleaning the  
current daemon. Srikanta, I don't forget you but I still didn't get time  
to read and test your cpp daemon, but I'll do it for sure. But I keep  
looking at your commits with attention ;-)

david

Re: [tuxdroid-user] Wiki server seems to be down :-(

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

On Thu, 12 Apr 2007 13:58:35 +0200, Srikanta Prasanna  
<sri...@gm...> wrote:

> Even the server which is hosting IRC logsis down.
> Unable to reach since morning!

Argh, it's holidays at the university where our lab is and they shut down  
the power supply for the complete day for some maintenance. I wasn't aware  
of that and went to work early this morning but I had that surpsrise  
around 8AM. I'm now back at home where at least I can power my computer :-)

Sorry for that, things should be available again tomorrow.

Re: [tuxdroid-user] Wiki server seems to be down :-(

[Srikanta P. <sri...@gm...>]

Even the server which is hosting IRC logsis down.
Unable to reach since morning!

[tuxdroid-user] Wiki server seems to be down :-(

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

Re: [tuxdroid-user] fuxusb sources?

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

On Tue, 10 Apr 2007 23:02:12 +0200, Philippe Teuwen <ph...@te...>  
wrote:

>
>> There's even not a lot of ressources for the 8051 though that CPU has
>> been there for ages and is still widely used. When you see how great
>> avr-libc and the avrfreaks community are, I just can't stand using the
>> 8051 anymore.
> Yes very surprising indeed.
>> I lately made an update of the fux firmware to change the product and
>> manufacturer usb names to "Tux Droid" and "Kysoh".
>> That should remove the extra space :-) (hex file attached)
> Yep it works.
> BTW why 2 USB-audio playback devices?
> What's the difference between them?
>
That's the last solution they came on for the tts. The tts daemon can't  
output on any sound card, the Acapela license only allows output to tux  
itself. That means tuxttsdaemon is connected to the audio port directly,  
not going through dmix and other stuff. So when the tuxttsdaemon was  
running, it was impossible to use the audio port from another application.

Now tuxttsdaemon will use the second port and the daemon itself decides of  
which channel is active. You can't have mixing inside the dongle so you  
either have one or the other. From what I heard, it seems the daemon is  
monitoring the tts queue and when there's something in it, sends the  
command to switch to the tts channel, then comes back to the default  
channel.

david

Re: [tuxdroid-user] IR question

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

> And, very funny, when pressing any key on Sat mode (addr 0x8) the Tux
> replies with its greeting msg :-D
>
That's a great feature :-D

I'll change that for the next firmware release.

Re: [tuxdroid-user] Event handling chain?

[Martin T. <ma...@ma...>]

On Tue, 2007-04-10 at 15:47 +0200, David Bourgeois wrote:
> On Tue, 10 Apr 2007 14:50:52 +0200, Martin Thomas  
> <ma...@ma...> wrote:
> 
> > On Tue, 2007-04-10 at 08:57 +0200, David Bourgeois wrote:
> >> On Mon, 09 Apr 2007 23:55:23 +0200, martin <ma...@ma...>  
> >> wrote:
> >>
> >> > Are button presses (like wing or head or RC) always passed on by the
> >> > firmware or can they be 'swallowed'?
> >> >
> >> > I am thinking of adding a function to the firmware so that I can tap  
> >> the
> >> > head button to mute sound.. but I am not sure if the button event will
> >> > still
> >> > be propagated to the daemon, overloading the button.  Maybe I could  
> >> just
> >> > do
> >> > everything on the pc.. but I would like to play with the firmware a
> >> > little
> >> > more.
> >>
> >> That depends on what you want to handle locally and from the computer. I
> >> would say that muting the sound requires to have sound sent from the
> >> computer so I would find it more logical to have the computer get the  
> >> head
> >> button event and decide to do the mute (by siftware or send the mute
> >> command). But in case you just use the usb audio device and don't have  
> >> the
> >> daemon running, that makes sense to have it locally by firmware.
> > You might also want to mute locally stored sounds which Tux will play
> > regardless of a host computer. So perhaps a mute button is not as simple
> > as it appears.
> 
> You're right, it might be intersting to mute the local sounds easily. On  
> the other hand the internal sound flash can only store 1 minute of sounds  
> so you're not likely to play local songs and you can also turn off the  
> volume dial.
Both good points.
> But anyway the above solution is still convenient if you store the mute  
> funciton associated with the head button event in eeprom, then even if the  
> computer is disconnected and you restart tux, you'll be able to mute with  
> the head button. That makes me think we need a toggle_mute() function  
> otherwise you'll only be able to mute and not unmute with this method :-)
Or a method to query mute status maybe?
> 
> >> In such a case, I think the standalone behavior proposal I already
> >> explained a bit would be a good solution. You could associate the mute
> >> function to the head button event in the eeprom (when this will be
> >> possible to do from the api in the near future) and easily  
> >> enable/disable
> >> that event from the computer. When disabled,the status of the button  
> >> would
> >> still be sent to the computer but the sequence won't be played. So even  
> >> if
> >> your applications need to use the head button at a certain point, they
> >> could still disable the standalone head button event momentarily. Though
> >> the daemon/api should handle that instead of the application.
> > It probably is an application level behaviour to associate buttons and
> > behaviours.
> 
> Yep but what I mean is that some of your your applications (let's say  
> VOIP) aren't supposed to know that you associated the mute function with  
> the head button locally on tux or from another application. So to avoid  
> muting at the same time you pick up the call, the api or a manager  
> application needs to deal with that.
I think you are right that other applications don't need to know what
other applications have done.  It may be that it is useful for them to
be able to see what the daemon or the firmware is setup to do - I am
thinking in terms of a stack with the app at the top and the local
firmware at the bottom.  If the daemon has associated a mute function
and a button then the app does not need to.
Maybe I should just play with tux for a while :-)

Thanks // M
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________ tux-droid-user mailing list tux...@li... https://lists.sourceforge.net/lists/listinfo/tux-droid-user

Re: [tuxdroid-user] fuxusb sources?

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

> There's even not a lot of ressources for the 8051 though that CPU has 
> been there for ages and is still widely used. When you see how great 
> avr-libc and the avrfreaks community are, I just can't stand using the 
> 8051 anymore.
Yes very surprising indeed.
> I lately made an update of the fux firmware to change the product and 
> manufacturer usb names to "Tux Droid" and "Kysoh".
> That should remove the extra space :-) (hex file attached)
Yep it works.
BTW why 2 USB-audio playback devices?
What's the difference between them?

Phil

Re: [tuxdroid-user] IR question

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

Ok I tried the Kiss one and te digits are working.
> You're sure it uses RC5? Because Philips also uses other protocols. If 
> it's not exactly 26kHz, it should not be the problem, the receiver 
> should get it too.
Well actually it came with my television but is kind of universal as it 
can control
TV / Tuner / VCR / CD / DVD / Tape / Sat / CDR devices
and TV mode is apparently not RC5 but when on CD mode most of the keys work.
And, very funny, when pressing any key on Sat mode (addr 0x8) the Tux 
replies with its greeting msg :-D

Phil

Re: [tuxdroid-user] IR question

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

> I've a KISS too but I didn't try that remote yet.
Only the digits are RC5 on mine

> The one I tried is a Philips, the inventors of RC5, should be compliant
> with the spec ;-)
> http://www.vatelectronic.cz/photogallery/Philips/Philips%20RC2030%20RC2031%20RC2032%20RC2033%20RC2044.jpg
>
> Probably some timing issues.
> Maybe someone is not following exactly 36kHz in sending of receiving  
> part.

You're sure it uses RC5? Because Philips also uses other protocols. If  
it's not exactly 26kHz, it should not be the problem, the receiver should  
get it too.

david

Re: [tuxdroid-user] IR question

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

> So if your remote is RC5, it should be seen by tux. I don't know why it
> doesn't, would need to have your remote to debug that. I have a KISS DVD
> remote control that mixes RC5 and other protocol keys (weird) but the RC5
> keys work just fine.

I've a KISS too but I didn't try that remote yet.
The one I tried is a Philips, the inventors of RC5, should be compliant
with the spec ;-)
http://www.vatelectronic.cz/photogallery/Philips/Philips%20RC2030%20RC2031%20RC2032%20RC2033%20RC2044.jpg

Probably some timing issues.
Maybe someone is not following exactly 36kHz in sending of receiving part.

Phil

Re: [tuxdroid-user] Event handling chain?

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

On Tue, 10 Apr 2007 14:50:52 +0200, Martin Thomas  
<ma...@ma...> wrote:

> On Tue, 2007-04-10 at 08:57 +0200, David Bourgeois wrote:
>> On Mon, 09 Apr 2007 23:55:23 +0200, martin <ma...@ma...>  
>> wrote:
>>
>> > Are button presses (like wing or head or RC) always passed on by the
>> > firmware or can they be 'swallowed'?
>> >
>> > I am thinking of adding a function to the firmware so that I can tap  
>> the
>> > head button to mute sound.. but I am not sure if the button event will
>> > still
>> > be propagated to the daemon, overloading the button.  Maybe I could  
>> just
>> > do
>> > everything on the pc.. but I would like to play with the firmware a
>> > little
>> > more.
>>
>> That depends on what you want to handle locally and from the computer. I
>> would say that muting the sound requires to have sound sent from the
>> computer so I would find it more logical to have the computer get the  
>> head
>> button event and decide to do the mute (by siftware or send the mute
>> command). But in case you just use the usb audio device and don't have  
>> the
>> daemon running, that makes sense to have it locally by firmware.
> You might also want to mute locally stored sounds which Tux will play
> regardless of a host computer. So perhaps a mute button is not as simple
> as it appears.

You're right, it might be intersting to mute the local sounds easily. On  
the other hand the internal sound flash can only store 1 minute of sounds  
so you're not likely to play local songs and you can also turn off the  
volume dial.
But anyway the above solution is still convenient if you store the mute  
funciton associated with the head button event in eeprom, then even if the  
computer is disconnected and you restart tux, you'll be able to mute with  
the head button. That makes me think we need a toggle_mute() function  
otherwise you'll only be able to mute and not unmute with this method :-)

>> In such a case, I think the standalone behavior proposal I already
>> explained a bit would be a good solution. You could associate the mute
>> function to the head button event in the eeprom (when this will be
>> possible to do from the api in the near future) and easily  
>> enable/disable
>> that event from the computer. When disabled,the status of the button  
>> would
>> still be sent to the computer but the sequence won't be played. So even  
>> if
>> your applications need to use the head button at a certain point, they
>> could still disable the standalone head button event momentarily. Though
>> the daemon/api should handle that instead of the application.
> It probably is an application level behaviour to associate buttons and
> behaviours.

Yep but what I mean is that some of your your applications (let's say  
VOIP) aren't supposed to know that you associated the mute function with  
the head button locally on tux or from another application. So to avoid  
muting at the same time you pick up the call, the api or a manager  
application needs to deal with that.