Sleep mode
From Tuxisalive
Contents |
[edit] Goal
The only reason of the sleep mode is to extend the battery life of your TuxDroïd.
Right now the RF and all 3 CPU's are constantly running. It takes around 10 hours to get the batteries completely flat. Using the sleep mode will reduce the RF and CPU activity when it's not needed. We hope to get a few days of battery life that way.
Another limitation is that if you forget your tux powered but unplugged, you'll probaly find it completely flat the following day. This is not really recommended for the battery health so we should avoid that this would happen too often. We could try to get a battery level from which tux would enter a deep sleep mode which would minimize power consumption to a bare minimum while completely dropping any functionality. In this mode you'll have to reset tux to get it back on life but at least the batteries will have been spared.
[edit] Specifications
[edit] Batteries
- battery pack of 4 NiMH AAA cells
- 4.8V
- 750mAh
[edit] Charger
- AC Adaptor Output: 7.5V DC 0.5A (outside ring: minus; inside contact: plus)
- NiCD/NiMH Fast-Charge Management ICs: BQ2002T from TI (Texas Instruments)
- Design constant charge current: 200mA
TODO: add charging curves of voltage-current/time
[edit] Detailed consumption
Note: these measurements were made on a single tux and are only here to get an idea of the consumption. There are many factors that can influence these results, mainly from the mechanical variations between the gearboxes and electronic components tolerances (leds, resistors, speaker, amplifier, RF, etc.)
| Part | Normal | Sleep | Deep sleep |
|---|---|---|---|
| mainboard | 19.7mA | 310µA | 310µA |
| rf board | connected: 46.1mA
disconnected: 66.3mA *** | ||
| IR receiver | ~1.3mA | ||
| head motor * | ~140mA | ||
| flipper motor * | ~230mA | ||
| spinning motor ** | tux lifted: 230mA
wheels blocked: 320mA | ||
| blue leds | 3.5mA per led
7mA for both |
* The current consumption of the motors changes with the battery voltage (or battery charge level).
** The current consumption strongly depends on the surface on which Tux is spinning. The spinning current should be lying between the 2 values shown, depending on the surface resistance to motion.
*** We don't know the exact reason why the current is higher when the RF is disconnected though the reception mode is continuous when it's disconnected while reception/emission is pulsed when connected. We certainly should improve that point in the future.
[edit] Battery life
TODO explain some calculations to get estimates of the battery life in different conditions.
The following table shows approximative total power consumption and estimated battery life in different cases.
| Condition | Current | Battery Life | Notes |
|---|---|---|---|
| Turned off | 0mA | 6 months | There's no standby, the switch is directly cutting off the battery so the current is null, but the self-discharge rate of NiMH batteries is quite high |
| Connected, no motors | 74mA | 10 hours | |
| Not connected, no motors | 86mA | 8 hours | |
| Sleep mode | |||
| Deep sleep mode | |||
| Regular usage, sound and movements | |||
| All motors continuously |
[edit] Implementation
There are 3 CPUs inside tux. We need to set them all in sleep mode and be able to wake them up simultaneously. As they closely communicate together, shutting down the communication channels and restarting them is quite tricky.
For handling sleep and wake up, we use the sleep command from tux's API and 2 bits from the connection frame: 'S' - sleep bit and 'W' - wake-up bit.
[edit] Sleep mode
The sleep mode will affect all 3 CPUs. In the sleep function, they will drop all functionalities and communications channels. Tuxcore and tuxaudio will stay in sleep unless a wake-up condition is met. The RF module (tuxrf) will wake-up regularly to check if the computer has issued a wake-up command. If so, it will wake-up the other CPU's.
<not implemented yet>It's possible to detect if your tux is asleep by sending a connection request with the sleep bit set. Tux will acknowledge the connection with its sleep bit set and return into sleep.
D: [ ID(16) | 0xXXXX | S-xxxxxx ] (Dongle sends a 16 bits ID) T: [ ID(16) | S-xxxxxx ] (Tux sends its 16 bits ID)
<not implemented yet/>
[edit] Entering 'sleep' mode
The command to enter sleep mode is always sent from tuxcore to tuxaudio, tuxrf and the computer. In this way, the daemon can track when tux is going to sleep.
If the command is issued from the computer, it is then sent to tuxcore which forwards it to the other 2 CPUs and finally the daemon should get it back as an acknowledge.
The command can also be issued by the standalone behavior of tux when the following conditions are met:
- sleep mode action : sleep key of the remote or manually close the eyes
- timeout without any user interaction on tux or on the computer
- different timeout when the battery level is low
- different timeout in dark light
- etc.
The default standalone behavior when entering sleep mode will be to play a 'sleep' sound and close the eyes.
[edit] Waking up from 'sleep' mode
We want to wake up from sleep by sending a 'wake-up' order from the computer or by pressing the head button.
Regularly, the RF CPU will reinitialize the RF module and wait for a connection request. The connection request should have the correct ID
TODO check if there's a way to wake up from a remote key, that would be very nice. First, there's some extra power consumption, second any glitch will wake-up tux, if that's not what we want, we should wqake-up the CPU's, check the IR signal, and return to sleep when the IR signal is stopped if it's not a wake-up condition.
[edit] Deep sleep mode
In 'deep sleep', power saving is the only goal. All CPUs will stay in sleep mode until you hard reset tux. The rf module will never wake-up to check the commands from the computer.
[edit] Entering 'deep sleep' mode
'deep sleep' can be entered in the same way as entering sleep mode. A different parameter of the sleep command can be used to differentiate the 2 sleep modes.
[edit] Waking up from 'deep sleep' mode
There's no way to wake up from this mode, you have to reset tux by cycling the power. If tux entered 'deep sleep' mode, it means that the batteries were very flat so you better plug tux to the wall adapter at this stage.
[edit] Efforts
- [DONE] Rework tuxrf firmware to free some place for the sleep functions
- [DONE] Add sleep functions in all CPU's
- [DONE] Add new commands in the dongle to manage connections with sleep and wake-up bits
- Test the whole thing
- Refactor the RF code in order to further reduce power consumption
- Disable the watchdog of the RF CPU in deep sleep mode
