start receiver outlinemorse.colorado.edu/~timxb/dac.doc · web viewtable 1: mnr performance in the...

Wireless Communication Test BedDeployment and Checkout Report

Phase 2 Preliminary

Version 0.53 May 2004

Prepared Under Subcontract SC03-089-252 with L-3 ComCept. Contract Data Requirements List (CDRL) item A001, Deployment and Checkout Report

Prepared by:

Timothy X. Brown, University of Colorado at [email protected]

Brian M. Argrow, University of Colorado at [email protected]

1. INTRODUCTIONThis document describes the Wireless Communication Test Bed Deployment and

Checkout for Phase 2. It is written to meet the CDRL A001 requirement as described in the SOW:

"The University shall prepare a report that describes the specific test bed deployment and layout and results of checkout testing to include air, vehicle, dismounted personnel and remote access to and from 802.11B access points through the network layout."

It builds on the earlier documents: WiFi Test Bed Design and Interface Specification; and the WiFi Experimentation Plan.

The report is prepared by the University of Colorado (CU) to document the test bed as it has been deployed and to invite sponsor discussion of possible improvements and further uses of the test bed. The test bed is continually improving as it is being used and this document should be considered a snap shot of the current state. A final version of the document will be delivered in May, 2004.

The document details the components of the test bed as it has been deployed. The last section provides a schedule for completion of open issues in the test bed.

2. TEST BED COMPONENTSFive areas of the test bed are described: physical infrastructure; radio hardware and

software; UAV platform and control; test procedures; and, data collection and monitoring.

2.1. Physical Facilities The physical facilities include the test site, physical access, buildings, power, network

connectivity, and UAV flight takeoff and landing facilities. This section describes the state of these facilities for the test bed.

2.1.1. Test SiteThe test site is the Table Mountain National Radio Quiet Zone (NRQZ). The site is located

15km north of the University of Colorado campus. The dimensions of the site are approximately a 2.5km by 3.5km area with a north-south alignment. The site area is approximately 7km2. Most of the site is flat and level with steep sides dropping to the level of the surrounding plain. The top is unobstructed for longer distance communication while conversely radio range can be easily limited by placing the radio below the top on the steep sides. An aerial photograph of the site is shown in Figure 1. A map of the site showing facilities is in Figure 2. More details are given in following sections.

1

http://www.its.bldrdoc.gov/home/programs/tm_quiet_zone

Figure 1: Aerial photograph of the Table Mountain test site looking west.

Figure 2: Table Mountain facilities

B9

1000’300m

1000’300m

Building: inside access + power + networking Building: power only On-site road Surrounding public road

T22

A4

MainGate

UAVops

N

2

The University of Colorado is using the Table Mountain Site under a Memorandum of Agreement for Cooperative Research with the National Telecommunications and Information Administration, Institute of Telecommunication Sciences who administers the site. The agreement is managed through Ken Allen of ITS. The current agreement allows us to work at the site with 48 hours notice through August of 2004. ITS has shown much positive interest in our project and has expressed an intent to support our project as long as we need. Operational work at the test site is coordinated with John Ewan of ITS who is the Table Mountain on-site manager.

2.1.2. Physical AccessAccess to the site is reached by public roads and requires approximately 20 min. to drive

from the CU campus. The facility is surrounded by a fence and has a coded gate opener. The site is bisected by roads running north-south and east-west with additional roads branching off to buildings and other facilities. The roads are unpaved and can be easily traveled at 35 kph in a standard car. Buildings have coded locks. CU has the codes for the gates and three buildings.

2.1.3. BuildingsThe site has several buildings across the facility. CU has inside access to three of the

buildings, labeled A4, B9, and T22 in Figure 2. The three buildings are strategically located at different sides of the site. B9 is approximately 80m2 and CU has permission to store items in the building between experiments. All early experiments have been based in B9.

2.1.4. PowerCU has access to 115V AC power at all buildings at the site including buildings without

inside access. Inverters have been bought to power nodes via vehicle cigarette lighters. The plane provides power to the UAV nodes. A battery or solar system may be used if a need arises.

2.1.5. Network ConnectivityThe test site is served with a high-speed IP-based optical network that has connectivity to

the Internet. Buildings A4, B9, and T22 have connections to this network available to CU.

2.1.6. UAV FacilitiesA UAV airfield has been prepared at the north side of the site. It is approximately 100m

long and 12m wide with a NNE by SSW alignment. It is shown in Figure 3. No building is located at the site, but, a tent and/or small trailer has been offered by ITS if needed.

Figure 3: UAV airfield.

2.1.7. Remaining IssuesThe test site has been well prepared and is ready for experimentation. The network failed

on a recent experiment. The cause has not been determined and is being investigated to ensure reliable experimentation in the future. The runway may be paved to provide a more reliable surface. As a minimum it may be partially paved so that dust is minimized during engine start and run-up.

3

Issues to be closed by the May 17 report: Determine the throughput and delay from test bed to monitor server at CU over the high-

speed network Document test site IP address and access procedure.

2.2. Radio Hardware and Networking SoftwareThree areas of the radio hardware and networking software are described: mesh network

radio (MNR), MNR packages, and base performance.

2.2.1. Mesh Network Radio (MNR)The mesh network radio consists of ad hoc routing software and a hardware platform to

support the software. The software is Linux based and runs on any Linux platform with sufficient storage and memory. The software is designed to work with any Ethernet network interface supported by Linux. Most network interfaces are abstracted to appear as an Ethernet interface to the operating system. Therefore the software works with wired Ethernet and wireless 802.11, 802.11a, 802.11b, and 802.11g. Only 802.11b has been tested since this is the focus of the test bed research.

The hardware can be any platform that supports Linux and 802.11b. A specific hardware platform was developed for this testing. The platform uses commercial off the shelf components and is shown in Figure 4. It is comprised of a Soekris single board computer, Orinoco 802.11b card, a Fidelity-Comtech bidirectional amplifier with up to 1W output, and a GPS. The components can fit in a box of dimensions 16cm x 16cm x 5cm. The MNR can operate in the temperature range from 0-60 °C with no cooling fan. Power is 12V and provided via power over Ethernet.

Figure 4: Mesh Network Radio (MNR) (left). MNR mounted in environmental enclosure for vehicle or fixed ground mounting (center). MNR mounted in UAV (foreground right)

The GPS is included for monitoring purposes and is not necessary for the ad hoc routing protocol. Operationally, it streams NMEA format data to the Soekris serial port. This is parsed by a software process that stores the most current UTC time, latitude, longitude information in a file gpslat.dat. This file can be read by other applications, such as the monitoring software as needed. Fixed devices can have a static gpslat.dat file created without need of the GPS.

All software resides on a compact flash (CF) card. Each CF card is identical except for an IP address that defines a node. When powered on, the operating system boots from an image stored on the CF, a RAM file system is created, and the software operates only in RAM. This mode of operation was chosen for three reasons. First, the CF card has a limited read/write life

16cm

21cm

4

and this minimizes accesses to the card. Second, the hardware may be turned off at any time due to power interruptions and this avoids file system corruption due to partial file writes. Third, CF cards can be exchanged between nodes in any order since no operational state is stored on the card. This ability to exchange CF and to power cycle has been demonstrated as part of our testing. The size of the CF image is currently 8.4MB. The system RAM file system and tmp RAM file systems are set at 30MB each with typical utilizations of 37% and 0% respectively.

2.2.2. MNR PackagesThe MNR can be mounted in different packages. For fixed ground sites and on vehicles,

the MNR is mounted in the environmental enclosure shown in Figure 4. For the UAV, the MNR components are mounted on brackets inside the UAV as shown in Figure 4.

In addition to these versions, the ad hoc software can be operated on standard laptops running Linux. In this case, the software resides on hard disk and not on a CF. Such a node is used for the test bed gateway described in a later section. Laptops can also be given to personnel to be hand carried. These nodes need to be provided with either a GPS or the ability to report their current location if they are at a fixed position.

Similarly, the software can be mounted on handheld devices such as a PDA running Linux. This has not yet been implemented.

2.2.3. Base PerformanceSeveral factors were measured to assess the MNR performance and are listed below. These

are completed in the lab or at the test site as appropriate in order to establish expected network behavior.

Table 1: MNR Performance in the lab

Measure Result Remarksboot time (sec) 100/ MNR/Laptop Network formation time (sec) three nodes in the lab, dominated by boot timeGround-to-ground range 1200m at test site 2m above the ground Air-to-ground range at test site 2m and 150m above the groundRound trip delay See Figure 6 as a function of hopsthroughput (bps) See Figure 6 as a function of hopsthroughput (pkt/sec) in the lab one hop

The boot time is a measure of how fast we can turn on a node and start the network. The time is measured directly and was found to be 100sec with the MNR. For comparison, it was also measured on an xMHz laptop and found to be ysec.

The network formation time is a measure of how long before a set of nodes without any information about other nodes can deliver the first packet. It is measured by powering on four MNR arranged in a three-hop chain and measuring the round trip time of the first ping packet between the two furthest nodes. DSR is on-demand, and so it does not find a route (i.e. network) until the first ping packet is sent. The time was found to be Xmsec.

The ground-to-ground range is a measure of the radio footprint of a ground node. It is measured using one MNR placed 2m above the ground and the Berkeley Variatronics Yellow Jacket held 2m above the ground. The MNR was placed at building B9 and was transmitting short ping packets to a node inside of B9. The Yellow Jacket was placed at various places around the test site and measured the received signal strength of packets. The experiment was repeated with the MNR placed on the ground so that its antenna was 0.2m above the ground (but, the

5

Yellow Jacket still held 2m above the ground). The results are shown in Figure 5. From this data we see that the range is about 400m when the node is placed on the ground and 1200m when placed 2m above the ground.

-90

-80

-70

-60

-50

-40

-30

10 100 1000 10000

Transmitter Receiver Separation (m)

Rece

ived

Sig

nal P

ower

(dBm

)

0.2m2m

Figure 5: Received signal strength vs. distance.

Similarly, the air-to-ground range is a measure of the radio foot print of the plane. It is measured similar to the ground-to-ground range, except that the MNR is mounted in the UAV. The result is found to be xxxm

The two-ray ground model [Rap00] indicates that the received signal power is given by where K is some constant, h is the height of the transmitter, and d is the transmitter

receiver separation. If we require some specific received power, we can solve for the distance where c is some constant. Thus a factor of 10 increase in transmitter height will yield an

approximately factor of 3 increase in range. This is observed in the range experiment where a factor of 10 height increase from 0.2 to 2m yields a factor of 3 range increase from 400 to 1200m. Extrapolating this data (for purposes of estimating future performance) to the UAV operating height of 500ft (150m) and assuming that all other factors are equal suggests an approximately 10km range from UAV to ground.

The round trip delay is a measure of the delay added by the ad hoc network. It is measured by setting up the network with one to four hops and measuring the minimum, average, and maximum delay of 100 ping packets as a function of the number of hops in the lab. The results are shown in Figure 6. The delay is 13ms per hop for the first 3 hops. The fourth hop has less than 13ms, but, apparently packets occasionally skipped a hop.

The throughput in bps is a measure of the network’s ability to forward data from one user to another. It is measured by setting up the network with one to four hops and measuring the time to transfer a 2MB file using ftp. This implies that we are using TCP. TCP is not the most efficient protocol for maximizing the throughput since it uses bandwidth for acknowledgements and it packet losses cause the rate to back off, but, it is the typical protocol used for web browsing. Further, it automatically handles the rate probing to find the highest reliable rate. The results are shown in Figure 6. The rate is 500kbps for one hop out of a maximum of 2Mbps. This difference is similar to what is observed in ad hoc infrastructure networks. The loss is due to

6

inherent overhead in the 802.11 MAC hardware, the bandwidth used for TCP acknowledgements (short and long packets use similar bandwidth resources), and the transmission rate variability due to the rate probing in TCP. Together we expect these to account for the factor of four in difference in nominal and achieved bit rates. Going from one to two hops yields an approximate factor of two reduction in data rate since the middle node must divide its communication between the two hops. At three and four hops, there is a further reduction due to interference between the additional hops. At four hops, the throughput settles to 100kbps. The Lab results are slightly lower due to 802.11 access points installed in the building.

Figure 6: Delay (left) and throughput (right) as a function of the number of hops.

The throughput in packets per second is a measure of the router’s ability to process packets. It is computed by using ping to send short packets at increasing rates until the packet loss rate exceeds 10%. The rate is found to be XX packets per second.

2.2.4. Remaining IssuesThe MNR is operational now. We continue to optimize the software as we get feedback

from testing. Currently, packets are processed only if they have a DSR header. Additional security, yet to be implemented, will be provided by MAC filtering so that only designated MAC addresses can access the ad hoc network. The routing software also will be tested with alternate MAC protocols, likely 802.11g since it uses the same 2.4GHz band and is thus compatible with the MNR bidirectional amplifier.

Phase 3 will have further improvements. The routing protocols will be ported to the Zaurus PDA. UAV and ground nodes have different communication range. A two tier routing protocol can exploit these differences.

Issues to be closed by the May 17 report: Measure ad hoc throughput in packets/sec vs. number of nodes. Monitoring intervals are not synchronized. This requires setting system time with GPS

(to nearest ms) Measure range from ground to plane

2.3. UAV Platform and ControlThree areas of the UAV platform are described: airframe, avionics, and performance.

2.3.1. AirframeThe AP-1 air frame was built to the specifications listed in the below table. The plane has

been flown several times. One early flight resulted in a crash at takeoff with minor damage to the

7

plane, but, has since flown five times successfully. The MNR has been mounted inside the plane and additional weight and volume is available for more payloads. A second plane is under construction.

Table 2: UAV Properties

PropulsionWing Horizontal Vertical Propellor APC 20x8

Span (in) 95.0 32.0 10.0 Engine Power 5.0 hpArea (sq in) 1425.0 304.0 75.0 Fuel Volume 1.0 galAspect Ratio 6.33 3.37 2.67 Avg. Fuel Consumption 1.5 lb/hTaper Ratio 1.00 1.00 0.50 Max Runtime 231 minMAC (in) 15.00 9.50 7.78Dihedral (deg) 2.5 0.00 Flight ConditionsSweep (deg) 0.00 0.00 15.38 Wing Loading 42 oz/ft^2Moment Arm (in) 51.38 52.72 Takeoff Speed 58 ft/sTail Volume 0.731 0.185 Takeoff Distance 150 ftFuselage Length (in) 63.00 Cruise Speed 100 ft/s

Payload WeightsPayload Bay 5x6x10 in^3 Aircraft Empty Weight 16 lbPayload Weight 10 lb Fuel Weight 5.6 lb

Payload Weight 10 lbMax Takeoff Weight 32 lb

Raven AP-1 Properties

Geometric Data

2.3.2. AvionicsThe plane is controlled using standard 72MHz analog radio control (R/C) from Futaba. It is

anticipated that the R/C control will migrate to a 900MHz digital packet system (a so-called Piccolo from Cloud Cap Technology). For safe UAV control it is necessary to verify that there are no bad interactions between the R/C receiver and the 2.4 GHz 802.11 payload system. Based on the experiments described below, if R/C antennas are separated by more than 10cm from the MNR and antenna, no interference is expected.

Standard qualitative tests, as specified by Futaba [Fut04], were performed to determine if there where any loses in radio range for the 72MHz R/C system. A standard test performed on R/C radio systems to verify their range is to place the model on the ground, with the receiver antenna properly mounted, and to walk away from the aircraft with the transmitter antenna collapsed, varying the control input. A spotter at the aircraft watches and listens to determine when the servos in the aircraft begin to jitter and finally stop responding. If the point at which the servos stop responding is greater than 30m, than the radio system is determined to have significant range for standard R/C flight operations [Fut04].

This test was performed with varying locations of the receiver antenna, while the 802.11 radio was operating in an active ad hoc network. It was found from these tests that the 802.11 radio system gave no noticeable decrease upon the radio range and all tests provided a ground range test of more than 50m. However by varying the antenna location, it was found that the payload computer, which operates around 100 MHz, decreased the range when the receiver antenna was placed within close proximity to the CPU. Though the reduced range was not less than 30m, to ensure sufficient radio range for the R/C system the receiver antenna should be

8

placed sufficiently far from the payload computer. From these tests, more than 10 cm of separation of the receiver antenna and computer is sufficient.

An interference test was performed between the 900MHz system and the 2.4GHz 802.11 radio. The antennas for these radios were placed in close proximity to each other and packets were sent and received. A Berkeley Variatronics Yellow Jacket measured the 2.4 GHz band and a spectrum analyzer measured both the 2.4GHz and 900MHz bands. No signal was observed interfering between bands. Nor were any packets lost. From these tests, we conclude that interference between these radio bands will also not be an issue if placed more than 10 cm apart as above.

2.3.3. PerformanceFlight performance will be measured when the 900MHz Piccolo system is installed since

this will provide a downlink for collecting detailed flight data. Design values are given in the above table.

2.3.4. Remaining IssuesThe Piccolo system has also been purchased and will be integrated with the plane. At that

point we can collect telemetry data from the plane with detailed flight dynamics. Currently, we can only get position, altitude, and ground speed from the monitoring GPS data. The second plane is under construction and must be competed.

2.4. Test Procedures & ScriptsBased on the WiFi Test Bed Experimentation Plan [Bro04] the following functionalities

are necessary on the test bed. They are divided into three areas: basic network operation, exercise scripts, and procedures documentation.

2.4.1. Basic network operationMNR radios must be able to be set up and operated at fixed sites, on stationary or moving

vehicles, or in the UAV. The ad hoc routing must operate on conventional laptop computer and handheld PDA platforms. Successful communication has been demonstrated at the test site for arbitrary combinations of these types of radios (except with the yet to be implemented PDA node). Fixed site nodes have been operated using power over Ethernet connection cables up to 30m.

Several scenarios require multihop routes to be formed for 1-5 hops. Three hop routes have been demonstrated at the site and more hops can easily be created with more nodes. Other test scenarios require placements so that ground nodes are disconnected. This has also been demonstrated.

2.4.2. Exercise Scripts:Some tests require specific scripts to be run in order to measure some property of the

network or to exercise some aspect of the network. Throughput is measured by sending traffic from one node to another via TCP and measuring the time to complete the communication. Scripts are written and tested that send several megabytes of data representing 1000’s of packets exchanged. Delay statistics are measured using a script based on ping. The script sends ping packets between two nodes and the roundtrip time statistics are collected.

Another script sends data to random destinations in the ad hoc network. This script runs on several nodes and generates continuous patterns of traffic to exercise the network. This script has been written and tested.

9

The remaining script to be implemented will shut down the radio at random intervals for short periods of time to simulate network failures.

2.4.3. Procedures Documents:Three procedure documents have been created. A general experiment procedures document

organizes the tests that make up an experiment. This contains the high-level experimentation plan checklist. It is augmented by two sub-procedure documents for the UAV and Radios. A UAV procedures document organizes the preparation and operation of the UAV. A radio procedures document organizes the preparation and operation of the MNR and laptop based radios. These documents include checklists to ensure procedures are followed. They contain areas for recording the timing and sequence of events at an experiment. They contain areas for noting subjective and other performance/operational info. and comments that arise during experiments. These documents will help maintain orderly operation of experiments. They are also the basis for documenting the ease of deployment, ease of operation, and hardware reliability. The documents are included in Appendix A.

2.4.4. Remaining IssuesFull Phase 3 testing will require additional scripts and procedures to be written. These

include a script to shut down the MNR at random intervals; a procedure for measuring the time for the network to self form; a procedure to measure the time for node failure recovery; and a procedure for making subjective evaluation of network performance. Further we envision that meta-scripts that prepare for a test, run the test, and store results when done will facilitate efficient and reliable testing. Subjective evaluation will require the ability make VoIP phone calls to and from the wireless ad hoc network. Also needed is a procedure document for users to evaluate the subjective performance of VoIP and web browsing over the MNR.

Issues to be closed by the May 17 report: Demonstrate that a user can connect to the Internet across the ad hoc network. Procedure document for subjective test

2.5. Test Bed Data Collection and MonitoringThree areas of the test bed monitoring are described: data collection, performance

measures, and data display.

2.5.1. Data collectionThe routing software is encapsulated in a monitoring module that observes every packet

that enters and leaves the router. This software collects statistics about the routing. Periodically these statistics are packaged along with a GPS position and time stamp and sent back to a monitoring server. The data is routed to the server through a test bed gateway node that recognizes packets with a specific port number as being monitoring packets. These packets are sent over a wired Ethernet to the monitor server. At the gateway collection can be turned on and off as specific tests start and finish. At the server this raw data is collected and can be played back immediately or later. This functionality has been demonstrated.

2.5.2. Perfomance measuresFrom the raw data collected, performance measures are derived. The measures are listed

below. The table describes the associated measurement method. The methods are run via an application script on the nodes; collected directly in the raw monitoring data; computed from the raw data; or derived from test procedure documents. An X in the ‘Ready’ column indicates

10

that the method has been implemented, tested, and, if appropriate (i.e. is raw or computed), is displayed in the remote monitoring display.

Table 3: Monitoring Measurement Method Status

Measure Method ReadyData Throughput script XLatency (communication delay) script XJitter (delay variation) script XPacket Loss, Radio computedPacket Loss, Congestion raw XCommunication Availability computedRemote Connectivity computedHardware Reliability procedure XRange computedNetwork Self-forming scriptNode-failure Recovery scriptMobility Impact computeEase of Deployment/Transportability procedure XEase of Operation procedure XData, Voice, Video, Web Page Communication proced doc

2.5.3. Data Storage and Display (Remote Monitor)The data is stored in a data base on the server morse.colorado.edu. Data can be observed in

a java applet at the URL http://morse.colorado.edu:8888/uav/uav.html. The position of the nodes is displayed over time and performance graphs of raw data shown when a node is clicked on. A sample screen shot is shown in Figure X. The remote monitoring will display raw and computed measurements stored in records associated with the running of a script. For instance, a monitoring record will be collected and monitoring started for that record. Then a throughput script will be run to measure throughput. When completed a note will be added to the record indicating which script was run and the results.

Remaining IssuesCurrently the node positions and the packets sent, received, and lost due to congestion are

shown in the remote monitor. The remaining raw and computed measures are still being implemented. The monitoring packets can potentially be lost during backhaul. A reliable backhaul mechanism needs implemented that guarantees delivery. Availability and remote connectivity need to be implemented. The system also needs to be stress tested both to see its performance when monitoring data is collected from many test bed nodes and to see performance when many remote users simultaneously draw monitoring data. Currently there are no web links to the remote monitoring so that unintended users can not readily discover its existence. In the future, as the work is publicized, the remote monitoring also needs a password to protect against arbitrary access.

In Phase 3, we will experiment using an Iridium satellite based backhaul. This will demonstrate performance for remote test bed deployments. The current delay information is

11

http://morse.colorado.edu:8888/uav/uav.html

being measured with an application script. If more detail is desired, packet delays will be measured directly using time stamps placed on transmitted packets.

Issues to be closed for the May 17 report: Compute and display Link Loss Rate Compute and display Range Interface improvements for better visualization Extensible monitoring data encoding Collect control packet data

3. TEST BED DEPLOYMENT COMPLETION SCHEDULEThe table below shows the completion schedule for the remaining issues. These issues are

being addressed concurrently but have staggered completion times. Three completion times are given, May, June, and August. May 17 is the final Test Bed Deployment and Checkout Report. June 17 is the final Experimentation Rehearsals Report, August indicates items that will be completed under Phase 3.

Table 4: Remaining Issues Completion Schedule

Item May Jun AugPhysical Facilities

Throughput and delay from test site to CU XNetwork access procedure at test site X

Radio Hardware and Networking Software

Throughput in packets/sec vs. number of nodes X

Show setting system time with GPS (to nearest ms) XRange from ground to plane XTesting routing hardware with different MAC interfaces XMAC address security XTwo-tier routing protocol X

UAV Platform and ControlConstruction of the second aircraft XInstallation of Piccolo system XMeasuring performance: min/max speed, rate of climb, endurance

X

Test Procedures & ScriptsConnection to internet from a wireless ad hoc node XProcedure document for subjective test XVoIP to or from a wireless ad hoc node XScript to shut down and restart MNR at random intervals XNetwork Self-Forming Test XNode Failure Recovery Test X

Automated script mechanism XTest Bed Data Collection and Monitoring

12

Compute and display Link Loss Rate XCompute and display Range XInterface improvements for better visualization XExtensible monitoring data encoding XCollect control packet data XReliable monitor packet delivery XDatabase collection stress test X

Compute and display Availability/Remote connectivity XPassword protection of database XStress test multiple remote users to database XMeasure packet delays directly XIridium backhaul X

The ability to experiment with the test bed will be shown by completing the 16 experiments. A schedule for completing each experiment is given below. The number in the first column is a cross reference to the sections in [Bro04]. The dates indicate a test completion time. They may be run earlier. The last two UAV experiments are later to allow time to integrate the Piccolo system before final testing.

Table 5: Phase 2 Testing Schedule

Ref Test Description 5/22 5/29 6/5 6/125.1.1/1 Thruput and Delay script, 1-5 hops fixed nodes X5.1.1/2 Rand Src/Dest script for 6 fixed nodes X5.2.1 Mobile node circles TM while TX to node on mesa X5.2.2/1 Thuput and Delay script, 4 fixed and 2 nodes mobile X5.2.2/2 Rand Src/Dest script for 4 fixed and 2 mobile nodes X5.3.1/1 Repeat 5.1.1/1 with UAV X5.3.1/2 Repeat 5.1.1/2 with UAV X5.3.2 Repeat 5.2.1 with UAV X5.3.2/1 Repeat 5.2.2/1 with UAV X5.3.2/2 Repeat 5.2.2/2 with UAV X5.3.3/1 Repeat 5.1.1/1 but ground nodes are disconnected X5.3.3/2 Repeat 5.1.1/2 but ground nodes are disconnected X5.3.3/1u Repeat 5.3.3/1 with UAV X5.3.3/2u Repeat 5.3.3/2 with UAV X5.4.1 Throughput vs. range between UAV and ground X5.4.2 Throughput vs. range between two UAV’s X

13

4. REFERENCES[Bro04] Brown, T. X, Davey, K., WiFi Test Bed Experimentation Plan, Version 1.0, L3 Comcept

Subcontract SC03-034-191 CDRL item A002, 15 March 2004

[Fut04] Futaba Frequently Asked Questions, Range Testing Your Futaba R/C Aircraft System, http://www.futaba-rc.com/faq/faq-q331.html

[Rap00] Rappaport, T., Wireless Communications Principles and Practice, 2nd Ed. Prentice Hall, 2000.

14

http://www.futaba-rc.com/faq/faq-q331.html

APPENDIX A PROCEDURES DOCUMENTS

Three documents are included on the subsequent pages. They include forms to assist in planning, preparing, executing, and documenting test bed experiments.

General Documents: AUGNet Experimental Plan Sheet (2 pages)

Radio Documents: AUGNet Radio Experiment Sheet

UAV Documents: AUGNet Prefield Check AUGNet Tools and Supplies AUGNet GCS Equipment AUGNet Preflight Check (2 pages) AUGNet Mission Log

15

AUGNet Experiment Plan SheetExperiment Date:Reviewer:________________Precheck Initials: Postcheck initials:

Pre-Experiment Checklist Preped/Charged/PackedTable Mountain Walkie Talkies permission req CameraPersonnel notified Monitor gatewayAll Test PreExp Monitor serverRadio PreExpUAV PreExp

At Experiment: Checklist Post ExperimentPersonnel briefed Equipment packedMonitor Backhaul Doors/gates lockedRadios mounted

Test Plan Estimated times relative to experiment start time Actual TimesTest Name Start Time Duration End Start EndExperiment Setup1234567

Test 1: test name: Pre experiment

Lab experiment runEquipment list



Issues:Description:

Equipment: Est. Time to Complete

Equipment:

Issues:

Est. Time to Complete

Experimental Goals:

Experiment Summary: Number and Type of Radios:

Other Equipment:

Personnel:

Forecast Weather:

Issues:

Weather:

Number of UAV:

Description:

16









Issues:Description:


Issues:Description:


Issues:Description:


Issues:Description:


17

AUGNet Radio Experiment SheetExperimental Goals: Date:___________________

Reviewer:________________Precheck Initials__________Postcheck initials_________

Radio 1: IP address: Pre experiment Post experimentRole in Experiment Software Loaded Equipment packed

Power Cables Issues:Ethernet Cables

Mounting Mounting hardwarePower-level Set
















Version 0.2, May 31, 2004

18

Flight BoxTools & Supply Check ListPrepare fuel / oil mix Max Flight Time x 1 gal / hr = . Engine starter battery charged

Airplane (Inspect and correct as necessary)PropellorEngine mountEngine and ignitionLanding gear & wheelsServo mounts and wiringControl horns & linkagesControl surface hingesRadio receiver Model Used: R/C Reciever MicrohardAvionics system Model Used: None Naiad PiccoloBatteries charged (# needed for total operations) Ignition Servo Avionics PayloadPayload mountPayload Interface & Operation

R/C Radio Transmitter battery chargedRadio programmed with correct planeTrims set as needed (check last flight log)

NaiadNaiad battery chargedC&C Node TestServo Node TestGPS Node TestIMU Node Test

Piccolonot yet !

Ground StationLaptop batteries chargedVirtualCockpit configured as neededGCS equipment list

Reviewer :

AUGNet -- Pre-Field Check

19

ToolsSpark plug socket 1Socket drivers Metric xx English xxAllen wrenches Metric xx English xxBall drivers Metric xx English xxFlat-head screwdrivers Flat-head xx Phillips xxPliers Needle 1 Regular 1 Side-cutters 1Scissors 1X-Acto knife Knives 2 Blades 4Prop Balancer Finger xxProp reamer 1Tire air pump Pump Needle

Egine SystemsFueling Pump 1 Bulb 1PropellorsEngine starter Chicken stick Electric BatterySparkplug

Measure SystemsVoltmeter 1Measure Tape Measure 1 Ruler 1 Calipers 1Wing deflection meter 1Tachometer 1C.G. machine 1Scale

Mounting / BondingGlue Epoxy 2 C/A 2Tape Electrical 2 Leukaflex 2VelcroZip tiesRubber BandsFoam Rubber

PowerExtension cableAC-DC convertorPower strip

HardwareBolts Hatch Servo Panel WingBlind nutsSet screwPushrod endsControl Horns Servo Control SurfaceServos Wing StandardCollars

CleaningPaper towelsGrease cleaner

Reviewer :

AUGNet -- Tools & Supplies

20

ComputerLaptopBatteriesCDW discsPower cable

CommRadio modemSerial cablePower cableAntennaAntenna cable

JoystickControllerExtension Cord

Reviewer :

AUGNet -- GCS Equipment

21

GCS SetupPower convertor connected to battery supplyLaptop battery plugged inLaptop power cable connectedRadio modem power cable connectedComm antenna mountedSerial cable connectedJoystick connectedRun VirtualCockpitVerify / set joystick calibration file

Aircraft SetupInspect avionics installation and wiringInstall avionics battery VInstall servo battery VInstall Payload battery VInstall ignition battery VInstall empennageConnect wings and servo cablesConnect control rods and check all linkagesCheck surface trims Check surface deflectionsVerify panels and hatches are secureRecord empty weight lbRecord empty C.G. location (from wing L.E.) in

Comm & Control TestVerify antenna modem connectionPower avionics systemVerify communications with VirtualCockpitCheck servo / control channels and directionsCheck control surface trims Check control surface deflectionsCheck engine kill switchCheck throttle settings and throw

Payload Setup & TestVerify payload mounting and wiringPower on payload systemVerify payload operationsPower off payloadPower off avionics

AUGNet -- Preflight Check

22

Engine Check & FuelingInspect engine mountInspect propellor and spinner inFill aircraft with needed fuel lbRecord wet weight lbRecord wet location (from wing L.E.) in

Engine Test and TuneRecord timeStart engineSet caberater screws as necessaryRecord idle RPM RPMRecord max RPM RPMTest remote engine killRecord time

Mission StartPower on avionics systemPower on servosPower on payload systemVerify communications with VirtualCockpitVerify payload operationsRecord timeStart engine

Begin taxi for takeoff

: .

x

: .

: .

23

Aircraft Engine Wing

Flight Objective Date

Field Modifications (pre-flight)

Dry Weight TO Weight Fuel Weight C.G. (from wing L.E.)

Idle RPM Max RPM Propellorx

Mission Remarks TO Time

TD Time

Mission Time

TD Weight Fuel Consumed Fuel Consumption

Aircraft Integrity / General Notes

Aileron Trim Elevator Trim Rudder Trim Throttle Trim

AUGNet -- Mission Log

24