From 77bb6b12d54cdf65955a57cb897727b156685a82 Mon Sep 17 00:00:00 2001
From: Olivier Matz <zer0@droids-corp.org>
Date: Thu, 31 Oct 2013 19:50:03 +0100
Subject: [PATCH] save some documentation in notes.txt

---
 notes.txt  | 161 +++++++++++++++++++++++++++++++++++++++++++++++++++++
 rc_proto.c |   3 -
 2 files changed, 161 insertions(+), 3 deletions(-)
 create mode 100644 notes.txt

diff --git a/notes.txt b/notes.txt
new file mode 100644
index 0000000..f8c697a
--- /dev/null
+++ b/notes.txt
@@ -0,0 +1,161 @@
+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.
diff --git a/rc_proto.c b/rc_proto.c
index 528fa84..a910b47 100644
--- a/rc_proto.c
+++ b/rc_proto.c
@@ -16,9 +16,6 @@
 #include "rc_proto.h"
 #include "main.h"
 
-
-
-
 struct power_levels {
 	int ttl;
 	int power_db;
-- 
2.39.5