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, ans also measure latency.
 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 hello
 268 ------------------------------------
 269
 270 The WING board is embeded during a flight. The RC board sends hello message at a
 271 specified rate (choosen from results of test 1 and 2). The WING sends
 272 statistics.
 273
 274 Check how the wing distance impacts:
 275 - the statistics
 276 - the RX DB
 277
 278 Maybe check with and without the 433Mhz beacon.
 279
 280 Test 5: embed in WING and send dummy servo commands
 281 ---------------------------------------------------
 282
 283 Test in real conditions: the WING board is embeded during a flight. The RC board
 284 sends dummy servo values at a specified rate (choosen from results of test 1 and
 285 2). The WING sends statistics and "power probes" allowing the RC board to choose
 286 its tx power level.
 287
 288 Check how the wing distance impacts:
 289 - the tx power level of the RC board
 290 - the statistics
 291 - the RX DB
 292
 293 Maybe check with and without the 433Mhz beacon.
 294
 295 Output:
 296
 297 After this test, we should be confident that xbee is useable in real conditions.
 298
 299 Test 6: control the wing with the RC board
 300 ------------------------------------------
 301
 302 Same than test 3, but in real flight conditions.
 303
 304
 305 -----------------------
 306
 307 test report
 308 ===========
 309
 310 test1
 311 =====
 312
 313 no stats sent from wing (except if contrary specified)
 314 don't forget to run read duty-cycle
 315 to reset duty-cycle, use "write soft-reset"
 316
 317 Be careful, some packets are dropped even with power level = 0 due to over
 318 power. Need to use a faraday cage.
 319
 320 50ms
 321 -------
 322
 323 1 byte per msg
 324 20B/s (160b/s) of useful bandwidth
 325 mainboard > rc_proto_hello wing 50 1000 x
 326   1000/1000
 327   1000/1000
 328   1000/1000
 329
 330 each test (50s) eats ~5% of duty cycle
 331
 332 10 bytes per msg
 333 200B/s (1.6Kb/s) of useful bandwidth
 334 mainboard > rc_proto_hello wing 50 1000 0123456789
 335 with stats send every second:
 336   950/1000
 337   994/1000
 338   950/1000
 339   1000/1000
 340   999/1000
 341 without stats:
 342   1000/1000
 343   1000/1000
 344   1000/1000
 345
 346 20 bytes per msg
 347 400B/s (3.2Kb/s) of useful bandwidth
 348 mainboard > rc_proto_hello wing 50 1000 01234567890123456789
 349   1000/1000
 350   1000/1000
 351
 352 40 ms
 353 -------
 354
 355 1 byte per msg
 356 25B/s (200b/s) of useful bandwidth
 357 mainboard > rc_proto_hello wing 40 1000 x
 358   1000/1000
 359   1000/1000
 360   1000/1000
 361
 362 10 bytes per msg
 363 250B/s (2Kb/s) of useful bandwidth
 364 mainboard > rc_proto_hello wing 40 1000 0123456789
 365   998/1000
 366   1000/1000
 367   1000/1000
 368
 369 20 bytes per msg
 370 500B/s (4Kb/s) of useful bandwidth
 371 mainboard > rc_proto_hello wing 40 1000 01234567890123456789
 372   1000/1000
 373   1000/1000
 374   1000/1000
 375
 376 30 ms
 377 -------
 378
 379 1 byte per msg
 380 33B/s (300b/s) of useful bandwidth
 381 mainboard > rc_proto_hello wing 30 1000 x
 382   1000/1000
 383   1000/1000
 384   1000/1000
 385
 386 10 bytes per msg
 387 333B/s (3Kb/s) of useful bandwidth
 388 mainboard > rc_proto_hello wing 30 1000 0123456789
 389   1000/1000
 390   1000/1000
 391   1000/1000
 392
 393 20 bytes per msg
 394 666B/s (6Kb/s) of useful bandwidth
 395 mainboard > rc_proto_hello wing 30 1000 01234567890123456789
 396   1000/1000
 397   1000/1000
 398   1000/1000
 399
 400 20 ms
 401 -------
 402
 403 1 byte per msg
 404 50B/s (400b/s) of useful bandwidth
 405 mainboard > rc_proto_hello wing 20 1000 x
 406   991/1000
 407   991/1000
 408   991/1000
 409
 410 10 bytes per msg
 411 500B/s (4Kb/s) of useful bandwidth
 412 mainboard > rc_proto_hello wing 20 1000 0123456789
 413   863/1000
 414   864/1000
 415   864/1000
 416
 417 20 bytes per msg
 418 1000B/s (8Kb/s) of useful bandwidth
 419 mainboard > rc_proto_hello wing 20 1000 01234567890123456789
 420   763/1000
 421   763/1000
 422   763/1000
 423
 424 25 ms
 425 -------
 426
 427 1 byte per msg
 428 40B/s (320b/s) of useful bandwidth
 429 mainboard > rc_proto_hello wing 25 1000 x
 430   1000/1000
 431   1000/1000
 432   1000/1000
 433
 434 10 bytes per msg
 435 400B/s (3.2Kb/s) of useful bandwidth
 436 mainboard > rc_proto_hello wing 25 1000 0123456789
 437   1000/1000
 438   1000/1000
 439   1000/1000
 440
 441 20 bytes per msg
 442 800B/s (6.4Kb/s) of useful bandwidth
 443 mainboard > rc_proto_hello wing 25 1000 01234567890123456789
 444   950/1000
 445   950/1000
 446   950/1000
 447
 448
 449 With stats
 450 ===============
 451
 452 25 ms
 453 -------
 454
 455 1 byte per msg
 456 40B/s (320b/s) of useful bandwidth
 457 mainboard > rc_proto_hello wing 25 1000 x
 458   1000/1000
 459   952/1000
 460   1000/1000
 461
 462 10 bytes per msg
 463 400B/s (3.2Kb/s) of useful bandwidth
 464 mainboard > rc_proto_hello wing 25 1000 0123456789
 465   966/1000
 466   974/1000
 467   964/1000
 468
 469 20 bytes per msg
 470 800B/s (6.4Kb/s) of useful bandwidth
 471 mainboard > rc_proto_hello wing 25 1000 01234567890123456789
 472   898/1000
 473   898/1000