- log (hexdump)
- the frame must be checked in the cb, we can provide helpers
+Tests to do
+===========
+::
+
+ 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.
git.droids-corp.org / protos / xbee-avr.git / blobdiff