notes.txt

   1 dump xbee stats
   2 ===============
   3
   4 read rf-errors
   5 read good-packets
   6 read tx-errors
   7 read tx-ack-errors # does not work
   8 read rx-signal-strength
   9 read duty-cycle
  10 read rssi-for-channel # does not work
  11
  12 configure xbee module
  13 =====================
  14
  15 write bcast-multi-xmit 0
  16 write unicast-retries 0
  17 write power-level 0
  18
  19 radio protocol
  20 ==============
  21
  22 - tout en network order
  23 - avoir le paquet le plus petit possible
  24 - grouper les informations en un paquet si possible. certaines infos
  25   non critiques pourraient attendre en file qu'un paquet de même
  26   puissance sorte
  27
  28 Octet 1: type
  29
  30 - si type est < 0x3f, alors il s'agit du bitmask des servos qui seront
  31   présents dans le corps. Les servos sont présents par blocs de 10bits.
  32   la puissance d'émission est également embarquée sur 3 bits.
  33   Cette commande doit être bien compacte car c'est celle qui va être
  34   envoyée le plus souvent.
  35
  36   Exemple, on veut envoyer le servo 0 (=0x123) et 4 (=0x234). Puissance = 2.
  37
  38   type = 0x5
  39   seq_num sur 5 bits
  40   puis pow sur 3 bits
  41   puis val[0] sur 10 bits
  42   puis val[2] sur 10 bits
  43   padding à 0 pour arondir sur un octet
  44
  45   -> 0x11 0x9 0x1c 0x68
  46
  47 - sinon, type correspond à la commande qui est mappée sur une structure
  48
  49 rc_command
  50 ----------
  51
  52 - on récupère l'état du PPM provenant de la télécommande en tache de
  53   fond (période 20ms pour chaque servo, et les servos arrivent les
  54   uns après les autres)
  55
  56 - toutes les 1 à 5ms
  57
  58   - on compare les valeurs ppm aux dernières valeurs envoyées: si
  59     elles sont différentes:
  60
  61     - on les stoque en mémoire dans "valeurs à envoyer"
  62     - on incrémente un numéro de séquence de cette structure sauf si
  63       le dernier numéro d'acquitement reçu est trop ancien
  64
  65   - si le numéro de séquence est différent du numéro de seq reçu,
  66     et que le dernier paquet a été émis il y a plus de 30ms, on émet
  67     les nouvelles valeurs et le numéro de séquence local
  68
  69 - lorsqu'on reçoit un paquet d'acquitement, on stoque le numéro de
  70   séquence
  71
  72 - lorsqu'on reçoit un paquet de stats, on le traite (affichage, beep,
  73   log, osd)
  74
  75 - lorsqu'on reçoit un paquet de "ping", on note le RSSI et la puissance
  76   à laquelle il a été émis.
  77
  78 - la puissance d'émission est choisi avec l'algorithme suivant:
  79
  80   - si on n'a pas reçu d'acquitement ou de ping depuis 500ms, alors
  81     on émet alternativement à 0 et 4.
  82
  83   - sinon, on émet à la puissance la plus faible qui a un RSSI supérieur
  84     à un seuil, ce que l'on peut déterminer grâce au ping.
  85
  86 wing
  87 ----
  88
  89 - lorsqu'on reçoit un paquet de commande
  90
  91   - on met à jour les valeurs des servos
  92   - si le dernier paquet d'acquitement a été émis il y a plus de 200ms
  93     on émet un paquet d'acquitement. La puissance d'émission du paquet
  94     d'acquitement est la même que la puissance du paquet reçu.
  95
  96 - toutes les 500ms, on émet un paquet de "ping" à une puissance
  97   différente (0 à 4). La puissance est contenue dans le message.
  98
  99 - toutes les 100ms, on émet un paquet de stats à la puissance du dernier
 100   paquet reçu.
 101
 102 interrupt, software interrupts and background tasks
 103 ===================================================
 104
 105 problem description
 106 -------------------
 107
 108 Today, both command line code, xbee char reception and callout events
 109 are handled in the main loop, with the lowest priority. Therefore, the
 110 command line cannot block, else the timers + xbee rx won't be executed.
 111
 112 A typical example where the command line blocks is the completion with
 113 many choices.
 114
 115 solution
 116 --------
 117
 118 xbee rx and timers should be executed in a low prio scheduler
 119 event. With this modification, the command line can block. However we
 120 must prevent a xbee transmission to be interrupted by a task doing
 121 another xbee transmission. For that, we will use scheduler_set_prio().
 122
 123 The problem with that is that we can loose precision for low prio
 124 events if the scheduler interrupt occurs when the scheduler priority
 125 is low. It could be fixed in scheduler, but maybe we don't need it.
 126
 127 Priorities
 128 ----------
 129
 130 From highest to lowest priority.
 131
 132 - Interrupts:
 133
 134   - timer
 135   - uart
 136   - spi
 137   - i2c
 138
 139 - Events, called from timer interrupt after a call to sei():
 140
 141   - LED_PRIO: led blink
 142   - BEEP_PRIO: process beep requests and modifies the beep_mask
 143   - SPI_PRIO: send and receive SPI data to the atmega168p
 144   - CS_PRIO: do the control system of the wing, reading infos from a
 145     structure updated by i2c, and writing commands using
 146     spi_set_servo()
 147   - XBEE_PRIO: read pending chars on xbee serial line and process xbee commands,
 148     send xbee commands.
 149   - I2C_PRIO: send requests and read answers on i2c slaves
 150   - CALLOUT_PRIO: calls low priority events using the callout
 151     code. This method allows to execute timers with a fixed period
 152     without drift. Even if the event cannot be executed during some
 153     time, periodical events will keep the proper period.
 154
 155 - Main loop:
 156
 157   - command line
 158
 159 Rules
 160 -----
 161
 162 Calling a xbee function needs to set prio to XBEE_PRIO only.
 163 Calling i2c_send_command must be done from a lower prio than I2C_PRIO.
 164
 165 libxbee / xbee module
 166 =====================
 167
 168 Library
 169 -------
 170
 171 xbee_dev = structure describing an xbee device
 172 xbee_channel = structure describing a channel, used to associates a req
 173   with its answer
 174
 175 xbee.[ch]: main interface to libxbee, creation of dev, registeration of channels
 176 xbee_atcmd.[ch]: get an AT command from its name or small id string
 177 xbee_buf.[ch]: not used
 178 xbee_neighbor.[ch]: helper to add/delete neighbors, use malloc()/free()
 179 xbee_rxtx.[ch]: parse rx frames, provides xbee_proto_xmit()
 180 xbee_stats.[ch]: helper to maintain stats
 181
 182 App
 183 ---
 184
 185 move this in library ?
 186
 187 xbeeapp_send(addr, data, len, timeout, cb, arg)
 188 XXX to detail
 189
 190 Timeout for xbee commands
 191 =========================
 192
 193 - send_atcmd or send_msg (xbee_prio)
 194
 195   - allocate a channel and a context
 196   - fill the context with info
 197   - send the message
 198   - load a timeout (xbee_prio)
 199
 200 - on timeout (xbee_prio)
 201
 202   - log error
 203   - call the cb with retcode == TIMEOUT
 204   - unregister channel
 205   - remove timer
 206   - this could be a critical error
 207     - if it's a comm error, it's ok
 208     - but if the channel is registered again and 1st callback finally occurs...
 209
 210 - on rx (xbee_prio)
 211
 212   - if there is a context, it's related to a query:
 213     - remove the timeout
 214     - unregister channel
 215   - do basic checks on the frame
 216   - log (hexdump)
 217   - the frame must be checked in the cb, we can provide helpers
 218
 219 Tests to do
 220 ===========
 221
 222 ::
 223
 224   Radio Controller      )))     xbee      ((( WING
 225      /
 226     /
 227    PC with command line
 228    (through serial)
 229
 230 Test 1: send data, unidirectional
 231 ---------------------------------
 232
 233 Periodically send data from RC to WING (every 20 to 100 ms). The WING sends its
 234 statistics every second.
 235
 236 Variables:
 237
 238 - period: from 20ms to 200ms
 239 - packet size: from 1 byte to 20 bytes
 240 - total number of packets: 1K for short tests, 100K for robustness
 241
 242 If the test is long, take care about maximum duty cycles (10%).
 243
 244 Output:
 245
 246 - local and peer statistics for each test (packet size, pps, number of packets)
 247 - at the end we will know what is the highest speed we can support for a given
 248   packet size, and how reliable is the xbee
 249
 250 Test 2: send data, bidirectional
 251 --------------------------------
 252
 253 Same than above, except that the WING replies to each received packet with a
 254 packet of same size.
 255
 256 Same kind of output.
 257
 258 Test 3: test wing control on ground
 259 -----------------------------------
 260
 261 On the ground, try to control the wing with the RC board. We also use the 2.4
 262 Ghz controller as a fallback (bypass mode).
 263
 264 Check that the bypass mode is enabled when we ask it (for instance on the
 265 channnel 5 switch) or when we switch off the RC board.
 266
 267 Test 4: embed in WING and send dummy servo commands
 268 ---------------------------------------------------
 269
 270 Test in real conditions: the WING board is embeded during a flight. The RC board
 271 sends dummy servo values at a specified rate (choosen from results of test 1 and
 272 2). The WING sends statistics and "power probes" allowing the RC board to choose
 273 its tx power level.
 274
 275 Check how the wing distance impacts:
 276 - the tx power level of the RC board
 277 - the statistics
 278 - the RX DB
 279
 280 Maybe check with and without the 433Mhz beacon.
 281
 282 Output:
 283
 284 After this test, we should be confident that xbee is useable in real conditions.
 285
 286 Test 5: control the wing with the RC board
 287 ------------------------------------------
 288
 289 Same than test 3, but in real flight conditions.