Freaks Asking Questions
From Tuxisalive
Contents |
[edit] Introduction
Yet another FAQ but this one is not really for frequent questions, but for questions by people willing to understand the very last bit of their lovely Tux.
When some Q/A make sense to a larger audience, they can be rolled out to the official FAQ
Thanks to especially the team as most of the questions are/will be answered by them ;-)
[edit] Q/A
[edit] Radio
[edit] How a Tux and a Dongle are paired?
At the moment, when the dongle is plugged, it sends an initialization frame. Then when you switch on Tux, it initializes in receiving mode looking for that frame. When it gets it, they exchange a code which is kept all the time the connection stays stable. When the connection drops (tux switched off or too far), the dongle resets itself in init mode.
So now you have to power your dongle and tux simultaneously and when they're connected, you can power another set of tux/dongle, otherwise you may mix them.
[edit] Could one single dongle command several tuxes?
One dongle will never be able to control several tux with the current RF protocol. Right now, audio frames are taking the complete bandwidth continuously. It's a major rewrite of the RF modules to do such a thing and you won't be able to use the audio simultaneously on 2 tux anyway. And if you have 2 tux, you also have 2 dongles.
I personally don't think it's interesting to do that work, but to have a daemon that uses 2 dongles correctly would be great. One of my proposals were to be able to set a name inside a tux (in eeprom somewhere) from the computer interface, then whenever you reconnect the same tux, the daemon could get that name whatever dongle it's connected to and you can control your tux by it's name.
[edit] IR
[edit] How to get an IR RC5 code from the API?
> I saw only commands to send RC5 but I'd like to learn the codes from my own remote unit.
It's sent in the status. Whenever a code is received, there's a IR status sent back that the daemon should capture.
But currently only the IR command is sent back to the PC, not the address.
All the commands are listed in remote.h.
When looking to a complete Ir frame (addr+command), don't forget the toggle bit, whenever you push a key, the toggle bit get toggled. So if you push the same key, you get A then B then A then B where A is the code + togle low, and B is the same code and toggle high
Address of the Kysoh remote is 0x1D
For more info on the RC5 protocol, see
Examples (if you've a Philips television or one compatible with RC5...):
- Volume up on television: tux.cmd.ir_send(0,16)
- Volume down on television: tux.cmd.ir_send(0,17)
[edit] How tuxes "see" each other?
It's IR but it doesn't work correctly.
We didn't have enough time to fix that before production and since priorities have changed.
I think this feature should be handled by the standalone behavior and the event manager in the firmware instead of the ir functions directly. As I'm planning to rewrite the ir functions at some point, I didn't try to fix the greeting event.
Normally, you should have 1 tux that sends a code, the other one sees it, says greet1 and send another code, the first tux receives that code, says greet2 and sends a thirs code that the second tux detects again and says greet3.
But usually you'll get greet1 and occasionally greet2 but that's all.
Tuxes are pinging in IR regularly, this can be seen with a webcam or a digital video camera, the led is in the right eye.
RC5 greeting codes are: addr 0x4 + random command (light level sampling) addr 0x8 + random command (light level sampling) addr 0xC + random command (light level sampling)
But they could have bad effects on the devices mapped to those addresses:
addr 0x4 is a Laser Vision Player addr 0x8 is Sat1 addr 0xC is a CD-Video
Indeed when I use my Philips remote control in Sat mode and press any key the tux replies to the "greeting" :-)
[edit] Can we use lirc with Tux?
Not yet but that would be great.
See LIRC driver
[edit] Motors
[edit] Is it possible to control the speed of the motors?
Yes.
There's 5 values for the PWM of the wings and the spinning.
0 is stopped, 1 is slow and 5 is maximum speed.
[edit] How fine rotation can be controlled?
We don't use step-by-step motors but standard ones.
The motor is stopped whenever a tooth pushes on a position switch and we can only detect 4th of turns that way.
It's possible though to use the motors in another way from the software side by running the motor only for a specific time period instead of running it for a specific angle. Start-wait-stop motor with a smaller PWM should give you finer movements, but the position will never be very accurate I'm afraid.
[edit] Would it be possible to do linear modulation to get smoother actions?
Sth like 1 - 2 - 3 - 4 - 5 - 5 - 5 - 5 - 4 - 3 - 2 - 1
Well, movements look rough because I wanted to stop the movement on the switch. When the eyes are closed, they need to be stopped very quickly otherwise they reopen. So I had to do braking by reverting the motor for a short time. The mouth is less critical as going a bit too far doesn't open the mouth completely but if we want the switch to have a correct meaning, it should be pushed so we again need to stop very fast. For the wings, there's maybe a slight braking but I'm not sure, and there's nothing for spinning.
So it should be possible to start more smoothly but stopping smoothly will be much more complex. That's to be inplemented in firmware anyway.
[edit] Audio
[edit] How can we use the line-in/out at the back of the Tux?
Line-out is in fact just a headphone output.
And line-in is even not connected to the computer, it's just a link to the amplifier so you can use tux as a small speaker box for your mp3 player. There's no frequency limitation on the line-in, it's just plain analog so you should get a better quality when using your portable player. The quality is limited by the speaker in this case.
[edit] Why 2 USB-audio playback devices?
(cf aplay -l|grep card)
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.
