--- /dev/null
+dump xbee stats
+===============
+
+read rf-errors
+read good-packets
+read tx-errors
+read tx-ack-errors # does not work
+read rx-signal-strength
+read duty-cycle
+read rssi-for-channel # does not work
+
+configure xbee module
+=====================
+
+write bcast-multi-xmit 0
+write unicast-retries 0
+write power-level 0
+
+radio protocol
+==============
+
+- tout en network order
+- avoir le paquet le plus petit possible
+- grouper les informations en un paquet si possible. certaines infos
+ non critiques pourraient attendre en file qu'un paquet de même
+ puissance sorte
+
+Octet 1: type
+
+- si type est < 0x3f, alors il s'agit du bitmask des servos qui seront
+ présents dans le corps. Les servos sont présents par blocs de 10bits.
+ la puissance d'émission est également embarquée sur 3 bits.
+ Cette commande doit être bien compacte car c'est celle qui va être
+ envoyée le plus souvent.
+
+ Exemple, on veut envoyer le servo 0 (=0x123) et 4 (=0x234). Puissance = 2.
+
+ type = 0x5
+ seq_num sur 5 bits
+ puis pow sur 3 bits
+ puis val[0] sur 10 bits
+ puis val[2] sur 10 bits
+ padding à 0 pour arondir sur un octet
+
+ -> 0x11 0x9 0x1c 0x68
+
+- sinon, type correspond à la commande qui est mappée sur une structure
+
+rc_command
+----------
+
+- on récupère l'état du PPM provenant de la télécommande en tache de
+ fond (période 20ms pour chaque servo, et les servos arrivent les
+ uns après les autres)
+
+- toutes les 1 à 5ms
+
+ - on compare les valeurs ppm aux dernières valeurs envoyées: si
+ elles sont différentes:
+
+ - on les stoque en mémoire dans "valeurs à envoyer"
+ - on incrémente un numéro de séquence de cette structure sauf si
+ le dernier numéro d'acquitement reçu est trop ancien
+
+ - si le numéro de séquence est différent du numéro de seq reçu,
+ et que le dernier paquet a été émis il y a plus de 30ms, on émet
+ les nouvelles valeurs et le numéro de séquence local
+
+- lorsqu'on reçoit un paquet d'acquitement, on stoque le numéro de
+ séquence
+
+- lorsqu'on reçoit un paquet de stats, on le traite (affichage, beep,
+ log, osd)
+
+- lorsqu'on reçoit un paquet de "ping", on note le RSSI et la puissance
+ à laquelle il a été émis.
+
+- la puissance d'émission est choisi avec l'algorithme suivant:
+
+ - si on n'a pas reçu d'acquitement ou de ping depuis 500ms, alors
+ on émet alternativement à 0 et 4.
+
+ - sinon, on émet à la puissance la plus faible qui a un RSSI supérieur
+ à un seuil, ce que l'on peut déterminer grâce au ping.
+
+wing
+----
+
+- lorsqu'on reçoit un paquet de commande
+
+ - on met à jour les valeurs des servos
+ - si le dernier paquet d'acquitement a été émis il y a plus de 200ms
+ on émet un paquet d'acquitement. La puissance d'émission du paquet
+ d'acquitement est la même que la puissance du paquet reçu.
+
+- toutes les 500ms, on émet un paquet de "ping" à une puissance
+ différente (0 à 4). La puissance est contenue dans le message.
+
+- toutes les 100ms, on émet un paquet de stats à la puissance du dernier
+ paquet reçu.
+
+interrupt, software interrupts and background tasks
+===================================================
+
+problem description
+-------------------
+
+Today, Both command line code, xbee char reception and callout events
+are handled in the main loop, with the lowest priority. Therefore, the
+command line cannot block, else the timers + xbee rx won't be executed.
+
+solution
+--------
+
+xbee rx and timers should be executed in a low prio scheduler
+event. With this modification, the command line can block. However we
+must prevent a xbee transmission to be interrupted by a task doing
+another xbee transmission. For that, we will use scheduler_set_prio().
+
+The problem with that is that we can loose precision for low prio
+events if the scheduler interrupt occurs when the scheduler priority
+is low. It could be fixed in scheduler, but maybe we don't need it.
+
+Priorities
+----------
+
+From highest to lowest priority.
+
+- Interrupts:
+
+ - timer
+ - uart
+ - spi
+ - i2c
+
+- Events, called from timer interrupt after a call to sei():
+
+ - LED_PRIO: led blink
+ - TIME_PRIO: monitor time
+ - BEEP_PRIO: process beep requests and modifies the beep_mask
+ - SPI_PRIO: send and receive SPI data to the atmega168p
+ - CS_PRIO: do the control system of the wing, reading infos from a
+ structure updated by i2c, and writing commands using
+ spi_set_servo()
+ - XBEE_PRIO: read pending chars on xbee serial line and process xbee commands,
+ send xbee commands.
+ - I2C_PRIO: send requests and read answers on i2c slaves
+ - CALLOUT_PRIO: calls low priority events using the callout
+ code. This method allows to execute timers with a fixed period
+ without drift. Even if the event cannot be executed during some
+ time, periodical events will keep the proper period.
+
+- Main loop:
+
+ - command line
+
+Rules
+-----
+
+Calling a xbee function needs to set prio to XBEE_PRIO only.
+Calling i2c_send_command must be done from a lower prio than I2C_PRIO.