X-Git-Url: http://git.droids-corp.org/?p=protos%2Fxbee-avr.git;a=blobdiff_plain;f=notes.txt;h=882dbc377f1b4f365fafcbe2109596e9c2c9430a;hp=33cab7b5f45a243a2b62927ef3ee2e2cc2b77580;hb=HEAD;hpb=e39c5d534eaa4d29fea56d7851343612fdab9a23 diff --git a/notes.txt b/notes.txt index 33cab7b..882dbc3 100644 --- a/notes.txt +++ b/notes.txt @@ -216,11 +216,288 @@ Timeout for xbee commands - log (hexdump) - the frame must be checked in the cb, we can provide helpers +Tests to do +=========== -Todo -==== +:: -- move callout in an aversive module -- move xbeeapp in xbee module + Radio Controller ))) xbee ((( WING + / + / + PC with command line + (through serial) +Test 1: send data, unidirectional +--------------------------------- +Periodically send data from RC to WING (every 20 to 100 ms). The WING sends its +statistics every second. + +Variables: + +- period: from 20ms to 200ms +- packet size: from 1 byte to 20 bytes +- total number of packets: 1K for short tests, 100K for robustness + +If the test is long, take care about maximum duty cycles (10%). + +Output: + +- local and peer statistics for each test (packet size, pps, number of packets) +- at the end we will know what is the highest speed we can support for a given + packet size, and how reliable is the xbee + +Test 2: send data, bidirectional +-------------------------------- + +Same than above, except that the WING replies to each received packet with a +packet of same size. + +Same kind of output, ans also measure latency. + +Test 3: test wing control on ground +----------------------------------- + +On the ground, try to control the wing with the RC board. We also use the 2.4 +Ghz controller as a fallback (bypass mode). + +Check that the bypass mode is enabled when we ask it (for instance on the +channnel 5 switch) or when we switch off the RC board. + +Test 4: embed in WING and send hello +------------------------------------ + +The WING board is embeded during a flight. The RC board sends hello message at a +specified rate (choosen from results of test 1 and 2). The WING sends +statistics. + +Check how the wing distance impacts: +- the statistics +- the RX DB + +Maybe check with and without the 433Mhz beacon. + +Test 5: embed in WING and send dummy servo commands +--------------------------------------------------- + +Test in real conditions: the WING board is embeded during a flight. The RC board +sends dummy servo values at a specified rate (choosen from results of test 1 and +2). The WING sends statistics and "power probes" allowing the RC board to choose +its tx power level. + +Check how the wing distance impacts: +- the tx power level of the RC board +- the statistics +- the RX DB + +Maybe check with and without the 433Mhz beacon. + +Output: + +After this test, we should be confident that xbee is useable in real conditions. + +Test 6: control the wing with the RC board +------------------------------------------ + +Same than test 3, but in real flight conditions. + + +----------------------- + +test report +=========== + +test1 +===== + +no stats sent from wing (except if contrary specified) +don't forget to run read duty-cycle +to reset duty-cycle, use "write soft-reset" + +Be careful, some packets are dropped even with power level = 0 due to over +power. Need to use a faraday cage. + +50ms +------- + +1 byte per msg +20B/s (160b/s) of useful bandwidth +mainboard > rc_proto_hello wing 50 1000 x + 1000/1000 + 1000/1000 + 1000/1000 + +each test (50s) eats ~5% of duty cycle + +10 bytes per msg +200B/s (1.6Kb/s) of useful bandwidth +mainboard > rc_proto_hello wing 50 1000 0123456789 +with stats send every second: + 950/1000 + 994/1000 + 950/1000 + 1000/1000 + 999/1000 +without stats: + 1000/1000 + 1000/1000 + 1000/1000 + +20 bytes per msg +400B/s (3.2Kb/s) of useful bandwidth +mainboard > rc_proto_hello wing 50 1000 01234567890123456789 + 1000/1000 + 1000/1000 + +40 ms +------- + +1 byte per msg +25B/s (200b/s) of useful bandwidth +mainboard > rc_proto_hello wing 40 1000 x + 1000/1000 + 1000/1000 + 1000/1000 + +10 bytes per msg +250B/s (2Kb/s) of useful bandwidth +mainboard > rc_proto_hello wing 40 1000 0123456789 + 998/1000 + 1000/1000 + 1000/1000 + +20 bytes per msg +500B/s (4Kb/s) of useful bandwidth +mainboard > rc_proto_hello wing 40 1000 01234567890123456789 + 1000/1000 + 1000/1000 + 1000/1000 + +30 ms +------- + +1 byte per msg +33B/s (300b/s) of useful bandwidth +mainboard > rc_proto_hello wing 30 1000 x + 1000/1000 + 1000/1000 + 1000/1000 + +10 bytes per msg +333B/s (3Kb/s) of useful bandwidth +mainboard > rc_proto_hello wing 30 1000 0123456789 + 1000/1000 + 1000/1000 + 1000/1000 + +20 bytes per msg +666B/s (6Kb/s) of useful bandwidth +mainboard > rc_proto_hello wing 30 1000 01234567890123456789 + 1000/1000 + 1000/1000 + 1000/1000 + +20 ms +------- + +1 byte per msg +50B/s (400b/s) of useful bandwidth +mainboard > rc_proto_hello wing 20 1000 x + 991/1000 + 991/1000 + 991/1000 + +10 bytes per msg +500B/s (4Kb/s) of useful bandwidth +mainboard > rc_proto_hello wing 20 1000 0123456789 + 863/1000 + 864/1000 + 864/1000 + +20 bytes per msg +1000B/s (8Kb/s) of useful bandwidth +mainboard > rc_proto_hello wing 20 1000 01234567890123456789 + 763/1000 + 763/1000 + 763/1000 + +25 ms +------- + +1 byte per msg +40B/s (320b/s) of useful bandwidth +mainboard > rc_proto_hello wing 25 1000 x + 1000/1000 + 1000/1000 + 1000/1000 + +10 bytes per msg +400B/s (3.2Kb/s) of useful bandwidth +mainboard > rc_proto_hello wing 25 1000 0123456789 + 1000/1000 + 1000/1000 + 1000/1000 + +20 bytes per msg +800B/s (6.4Kb/s) of useful bandwidth +mainboard > rc_proto_hello wing 25 1000 01234567890123456789 + 950/1000 + 950/1000 + 950/1000 + + +With stats +=============== + +25 ms +------- + +1 byte per msg +40B/s (320b/s) of useful bandwidth +mainboard > rc_proto_hello wing 25 1000 x + 1000/1000 + 952/1000 + 1000/1000 + +10 bytes per msg +400B/s (3.2Kb/s) of useful bandwidth +mainboard > rc_proto_hello wing 25 1000 0123456789 + 966/1000 + 974/1000 + 964/1000 + +20 bytes per msg +800B/s (6.4Kb/s) of useful bandwidth +mainboard > rc_proto_hello wing 25 1000 01234567890123456789 + 898/1000 + 898/1000 + + +Latency +=============== + +the ECHO command contains a timestamp, allowing latency measurement. +the structure is a but larger than a HELLO message. + +mainboard > rc_proto_stats reset +mainboard > rc_proto_echo wing 50 50 x +mainboard > rc_proto_stats show + echo_ans_latency_ms: 80 + +mainboard > rc_proto_stats reset +mainboard > rc_proto_echo wing 50 50 0123456789 +mainboard > rc_proto_stats show + echo_ans_latency_ms: 95 + +mainboard > rc_proto_stats reset +mainboard > rc_proto_echo wing 50 50 01234567890123456789 +mainboard > rc_proto_stats show + echo_ans_latency_ms: 125 + +The latency is probably small enough for our RC application, but it is +not as small as expected. + +serial from uc to xbee at 57600 = ~3ms for 20 bytes +radio rate is 24000: ~6.66ms for 20 bytes + +the progression of latency is not linear.