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. libxbee / xbee module ===================== Library ------- xbee_dev = structure describing an xbee device xbee_channel = structure describing a channel, used to associates a req with its answer xbee.[ch]: main interface to libxbee, creation of dev, registeration of channels xbee_atcmd.[ch]: get an AT command from its name or small id string xbee_buf.[ch]: not used xbee_neighbor.[ch]: helper to add/delete neighbors, use malloc()/free() xbee_rxtx.[ch]: parse rx frames, provides xbee_proto_xmit() xbee_stats.[ch]: helper to maintain stats