WOCCS: RF TEST BENCH

faithfulparsleyΛογισμικό & κατασκευή λογ/κού

2 Νοε 2013 (πριν από 3 χρόνια και 7 μήνες)

119 εμφανίσεις






Multi
-
Disciplinary
Senior

Design Conference

Kate Gleason College of Engineering

Rochester Institute of Technology

Rochester
,

New York

14623




Copyright © 2011 Rochester Institute of Technology

Page
1

of 8

Project Number
:
P11210
WOCCS: RF TEST BENCH






Michael DeFrancis


Computer Engineer


Demetrios Koukouves


Mechanical Engineer


Shaheer Khan


Electrical Engineer



Andrew Nosal


Electrical Engineer




ABSTRACT




The primary objective of the RF Test Bench
project is to design and develop a testing device
capable of testing a wireless RF communication
system for its performance characteristics. The project
is a part of Wireless Open Architecture/Open Source
Command
& Control System (WOCCS) family of
projects, which aim to develop a wireless RF
communication system. The team aims to provide
Harris Corporation, the customer, an easy to use
mobile device capable of testing a RF module for its
transmission performance a
nd power capabilities.



The final device tests a RF module using both
software and hardware components and displays to the
required data by the user through a laptop. In this
paper, the overview of test bench and WOCCS, the
design process for hardware and software components,
and

the results of testing WOCCS system will be
described in detail.


NOMENCLATURE


WOCCS


Wireless
Open Source
/Open
Architecture

Command and Control System.

RF


Radio Frequency

PCB


Printed Circuit Board

GUI


Graphical User Interface

MOSFET


Metal Ox
ide Semiconductor Field Effect
Transistor

Op
-
amp


Operational Amplifier

LED


Light Emitting Diode

DUT
-

Device Under Test

A
DC

-

Analog
-
to
-
Digital Converter

'Serial Port'
-

Serial Emulation over USB

USB
-

Universal Serial Bus


INTRODUCTION



Harris
Corporation is world renowned for its
products for various defense, government and
professional organizations in the field of
communication and control. With the development of
wireless technologies, the demand for its application in
commun
icating and cont
rolling
equipment has also
increased. In the present world, the need to
communicate and the ability to remotely control
applications and equipment is a major strategic
weapon for any military and also finds uses in
educational, medical and commercial purp
oses. The
ability to control a device in the field while sitting in
secured location not only reduces human casualties but
also provides strategic control.



The primary purpose of the WOCCS system is to
enable wireless command and control of a remote
de
vice through a base station. The WOCCS project
family is a continuation of the P10205 LV
-
1 Wireless
Command and Control System project, which
implemented a preliminary RF transceiver modem on
a LV
-
1 Land Vehicle robot aiming to send user
commands and recei
ve sensory data. The primary
purpose of the present WOCCS system is to further
enhance the model and enable wireless transmission of
data over different ranges between a remote device
through a base station. The system aims to transmit
basic telemetry data

between the two units at different
ranges with minimal data and bandwidth loss. The
system consists of a portable base station, which uses
an RF module to transmit and receive data. The remote
unit also consists of an RF module for transmission



and recept
ion of data. The remote unit RF module
design aims to easily interface with mobile units or
vehicles on land, water or air. The WOCCS system on
the whole is designed to be portable and is powered
through a rechargeable Li
-
ion battery.



The RF Test Bench,

as a part of the WOCCS system,
is responsible for demonstrating the functionality of
the system. In industry, every major product design
requires extensive testing before the product is deemed
fit for use. A test bench is general is designed and used
in i
ndustry to provide validation of the theoretical
concepts and demonstrate the successful working of
any system. The RF test bench for the WOCCS system
tests the system for the data transmission and the
power usage. Further, the design for the test bench
ai
ms to incorporate future compatibility for testing
other communication products.



In the paper, we further explain the overview of the
RF Test Bench, its overall process, the tests to be
performed on various subsystems. The Design
Methodology section exp
lains the design process for
hardware (Power Board & Arduino), the enclosure and
the software GUI programmed for the testing of the
system. The paper also gives the overview of
subsystem tests, the experimental setup, and the results
obtained from the test
s.



OVERVIEW


The RF Test Bench consists of two distinct features:
the Hardware and the Software. The hardware of the
test bench includes the Power testing board, the
Arduino board and the enclosure.
The software
component includes the Power Meter GUI and Control
Panel

GUI.
The test bench as a device to test
functionality

of the WOCCS system, occupies an
unique position in the family.
Figure 1 displays the
overview of the test bench in relation to the
WOCCS
system.


The WOCCS Test Bench tests the power, data loss,
latency, bandwidth, and range of the WOCCS system.
Due to the different requirements for each of these
tests, the test bench consists of several components.
These components are:


For the Pow
er Test:


1x Laptop

Arduino Board

Arduino Software

Power testing board

Power Meter GUI Software


For the Latency, Bandwidth, Data Loss, and Range
Tests:




















Figure 1 : System Architecture Block Diagram


2x Laptops

Test Bench Control Panel
Software

Serial Communication Protocol over USB


The Power Test allows the user to view the voltage
across the device's battery, the current being
drawn by
the system, and the

power used by the system. This is
accomplished by measuring voltages on the WOCC
S
system using an external test bench device consisting
of a power test board that formats the voltages, and an
Arduino board which reads them
through its ADC
converter and outputs them to the PC for real
-
time
display by the power meter GUI.


The Test Benc
h Control Panel Software allows
t
he
user to simulate input to the WOCCS System, and
measure output. This GUI interacts with the RF
devices according to a Serial Communication designed
by the Test Bench team in collaboration with the RF
teams.



DESIGN METH
ODOLOGY


Hardware


Hardware


Power Testing Board



The goals of the hardware design were to
measure instantaneous power consumption and report
the measurements back to the computer through USB
communications. In order to monitor power
consumption throughout the operating time test as
defined by the missio
n profile, a means to measure the
voltage and current had to be designed. By measuring

Copyright ©
200
8
Rochester Institute of Technology


the voltage of the battery, as well as the current drawn
by the system, instantaneous power consumption can
be calculated. Once measurements were taken, the

values re
turned should be communicated over USB to
the computer so that the results can be displayed
graphically
.

Figure 2
displays the circuit schematic for the Power
Testing board.
In order to take accurate
measurements
of system performance, the Test Bench should not
impose much of a load on the system. The current
measurement had to be done with a sense resistor that
was to be placed in between the battery and the system
connected in series to the system.

This sense resistor
had to be small enough so that it did not drop too
much voltage across it, but had to be big enough for
the voltage being dropped across it to be measurable.
The voltage developed across the sense resistor was
expected to be very smal
l during normal operation, so
an operational amplifier (op
-
amp), configured in a
differencing configuration, was used to amplify the
voltage difference across the resistor. The
differencing op
-
amp was setup to have a voltage gain
of 5.24 by using 82k

res
istors on the inputs, and a
~430k

trim potentiometer on the feedback. To
ensure that the Test Bench imposed minimal load on
the system, a pair of voltage
-
followers were used prior
to the differencing op amp to isolate the Test Bench
from the WOCCS system
.



The battery voltage was measured using another op
-
amp in a differencing configuration. The op
-
amp was
setup to have a gain of 1 by using a 220k


resistors on
the inputs, and a ~220k

trim potentiometer in the
feedback. The output of the op
-
amp was d
ivided
down by ~5.3 by using a voltage divider circuit that
consists of a 430k
Ω resistor and a 100
k

resistor in
series to ground. The output from the voltage divide
was then sent to the microcontroller for processing and
forwarding. In order to ensure t
hat the Test Bench
imposed a minimal load on the WOCCS system, a P
-
channel MOSFET was used as a switch. When on, the
MOSFET will act as a short, and the battery
measuring circuitry is now connected; and when off,
the MOSFET is an open, and the battery vol
tage
measuring circuitry is not connected to the WOCCS
system. The MOSFET was chosen as a PMOS since
it was going to be switching high voltages and not to
ground.



Op
-
amps served two main purposes in the design of
the Test Bench; they isolated the Test
Bench from the
WOCCS system, as well as took differences between
two voltages. The sense resistor allowed the Test
Bench to measure current as a voltage.


Hardware


PCB
Layout


Figure
1

: PCB layout for the Power Meter


The PCB layout for the power meter board
was done through the
PCB Artist

CAD software.
Keeping in mind in the needs and budget of the
system, and the circuit layout, a 2
-
layer board was
selected as it provided enough room for placement of
components. The b
oard was designed to be 3" x 2.5"
in dimension and uses one
-
ounce copper. The board
also contains spacer holes to mount the Arduino board
on top.


The final board, as shown in Fig (), required some
adjustments due to introduction of a resistor. The
initial

prototype board while testing did not output the
required voltage levels due the floating pin of one of
the op
-
amp. A quick and easy modification was made
on the board, which required the connection of a 10
kΩ resistor between V
batt
+

and the ground.


The
board required extensive time to design and was
verified by experienced professors. It was also
manufactured for cheap using the student discounts
available through the circuit fabrication company
.




Figure
2
: Power Testing Board Schematic




Hardware


Arduino



When looking for a microcontroller
, the top
priorities were that the microcontroller be capable of
USB communication with the computer, and to have
an Analog to Digital converter on board. The main
tasks of the microcontroller were going to be using an
analog to digital converter to read
a voltage, and
perform minor arithmetic on it, and to send the new
value over USB to the computer so that it can be
graphically displayed.



The Arduino was a no brainer selection thanks to
its

built in USB communication capabilities, on
-
board
analog to digital converter, and the fact that the whole
Arduino platform is open
-
source. The Arduino also
comes in a demo
-
board format, which requires no
PCB layout or additional board design to be done
.


Hardware


Enclosure

and Packaging



The goal of the enclosure was to provide
suitable housing for the
base and remote
RF Test
Bench

units

that would protect the internal circuitry
from mild environmental conditions. The WOCCS
project was not designed f
or severe weather and
environmental conditions and the RF Test Bench
remained similar in scope. An extruded aluminum
enclosure was selected for the ease and practicality it
offered.
The enclosure can be seen in Figure 4.

The
aluminum enclosure features ra
ils internally on both
sides that allow the power testing board to slide in and
out of the enclosure with minimal effort. The face
plate of the enclosure was machined to allow the
power testing board to interface with the power board
via a 4
-
pin Molex con
nector. The face plate was also
machined to allow for a USB connection between the
Arduino and the laptop. A small hole was drilled for
the
LED.

The dimensions of the enclosure were
selected to specifically fit the power testing board
which is 3 in by 2
.5 in (76.2 mm by 63.5 mm) in size.
The rails allow easy sliding for a two layer PCB which
has a thickness of 0.0625 in (1.59 mm).


The Arduino board is mounted to the power testing
board using 4 non
-
conductive plastic standoffs with
plastic screws. To interface the power testing board
with the Arduino, 6
-
pin and 8
-
pin flex cables were
used which were soldered into the power testing b
oard
and
then inserted into the pin headers of the Arduino.
In order to connect the power testing board with the
power board, a b
undled cable

was fashioned using
crimping terminals and keyed 4
-
pin Molex connectors.


The enclosure was grounded by tying a w
ire internally
to the aluminum. The wire was then soldered to a
point in the ground plane of the power testing board.
Grounding for the power testing board was linked to
the Arduino ground which was linked to the laptop
ground.















Figure 4 :
T
est Bench

Enclosure



Software


The software for this project can be divided into two
groups. The first set of software is the software that
controls and interfaces with the power meter. The
second group of software is the software that generates
data
input, and quantifies system properties by
measuring data output.


Software


Power Meter


The software written for the power meter can be
further

divided into two sub
-
categories. First, there is
the software written for the Arduino micro
-
controller.
Second, there is the PC software written to interface
with the Arduino micro
-
controller, and provide
feedback to the user.


Software


Arduino


The fre
e and open source programming environment
provided by Arduino is the technology used to
program the Arduino. It was chosen due to its high
volume of public sample code, it's relatively simple
learning curve, and its high quality support
documentation. Writ
ing code using this tool is very
similar to writing in C, except that instead of the
standard template library (STL) used in C, the Arduino
programming environment uses its own library.


The software written for the Arduino completes
several time
-
critical
tasks: it needs to grab incoming
data over the serial port, switch operating modes,
perform analog to digital conversions, and output data
back over the serial port. For this software, a M
o
ore
State Machine was designed to perform the needed
functionality.

Mo
o
re State Machines control output as
a function of the current state alone. The state machine
switches between four modes of operation: idle,

Copyright ©
200
8
Rochester Institute of Technology


reading power, reading voltage, and reading current.
The commands that the PC sends to the Arduino are
the foll
owing: 'W'
-
revert to idle state, 'V'
-
switch to
voltage reading state, 'C'
-
switch to current reading
state, 'P'
-
switch to power reading state. The Arduino
software was designed with robustness in mind. The
software was tested by using a serial packet an
alyzer
to check the data flowing from the Arduino to the PC.
In particular, the type of data received on the PC was
examined to ensure that the Arduino was operating in
the proper state for every possible use case.
Additionally, the frequency of data recei
ved on the PC
from the Arduino was examined to ensure that the
device was streaming data in real
-
time according to
specifications.


Upon reset, the power meter begins operation in the
idle state. When in the idle state, the machine simply
sets the LED on

the power test board to green
indicating that no tests are being performed, and polls
for command data over the serial port indicating that it
needs to change its state. Whenever the software
enters the power reading, voltage reading, or current
reading s
tates, it sets the LED on the power test board
to red indicating that tests are being performed.


When in the voltage reading state, the software
enables a gate transistor on the power test board which
enables reading of battery voltage, waits for any
capa
citance to be mitigated, takes a voltage reading
using the
ADC
, and then outputs the data over the
serial port. This operation is performed continuously.
In addition, the software delays for 100 ms after
beginning a read over the
ADC

to ensure that the
cal
culation has settled. Furthermore, the Arduino uses
a linear regression curve to map the voltage received
to the equivalent voltage seen at the battery. When in
the current reading state, the software performs the
same calculation as for voltage, except th
at the gate
transistor is not enabled, no regression curve is used,
and current is measured instead of voltage. Current is
calculated by measuring the voltage drop over a sense
resistor that is input to analog pin three on the
Arduino, and referencing it t
o the exact resistance of
this sense resistor to obtain current. Current is output
over the serial port in m
illiamps.

Finally, when in the
power reading state, the software performs both the
voltage calculation and the current calculation
described above;
however, instead of outputting the
current and voltage separately over the serial port, in
this case the software computes the power in m
illi
-
W
atts
.


S
oftware


Power Testing GUI



The free and open source programming
environment known as 'Processing' was
chosen as the
technology for use by the GUI software that interfaces
with the power meter. There were several reasons for
this. The primary reason for this was due to the
numerous libraries provided by Processing that allow
for custom display of data, mani
pulation of individual
pixels on the screen, etc. This was important because
the power meter GUI needed to graph power data in
real
-
time. The other reasons were: the Processing
development kit was designed by the same people that
created the Arduino develo
pment kit, and the
Processing tool provided instant access to numerous
examples.



The GUI software for the power meter performs
several tasks: It polls for incoming data over the serial
port, updates the real
-
time graph and data display
according to data
received, checks for user input
(mouse clicks on buttons), and sends command data to
the power meter over the serial port if necessary. Due
to the nature of the tasks that had to be completed, the
GUI software used polling, instead of events, to grab
data
from the serial port. Therefore, there is a delay
between when data is received and when it is
displayed by the GUI. Testing was performed to
ensure that this delay was not detectable by the user.

Figure 5 shows the power testing GUI.

Figure 5 :

Power Testing GUI



The processing tool does not provide any tools for
creating buttons or detecting button presses, and so all
button handling needed to be implemented manually.
Code that detected collision detection between the
mouse and the buttons nee
ded to be developed for
each button. Additionally, all of the graphical elements
of the GUI needed to be drawn manually (each line on
th
e screen, all of the text,
one instruction at a time).
The advantage of this is it allows for much more
control over the

graph, while the disadvantage is it
requires more code space.


The GUI for the power meter operates according to a
Mealy State Machine. Mealy State Machines control
output as a function of both the current state and any
other input. This type of state mac
hine was necessary
in order to control the output of command data over



the serial port according to user input. The states of
this machine are: idle, displaying power, displaying
voltage, and displaying current. The GUI changes
states according to user inp
ut alone. When the user
presses the 'Stop' button, the program enters the idle
state, and sends a 'W' command to the Arduino over
the serial port indicating that no tests are in progress.
When the user presses the voltage, current, or power
buttons, the so
ftware switches to the corresponding
state, and issues the corresponding character('V', 'C', or
'P') command to the Arduino over the serial port.
Additionally, the GUI begins operation in the idle
state. When the user presses the start button, the GUI
ente
rs the displaying voltage state, and issues a 'V'
command to the Arduino. Additionally, when the GUI
for the power meter switches display modes, it resets
the graph, changes the scale of the graph, and updates
the display. The GUI uses a different graphing

color
for each type of value to be displayed: red for voltage,
green for current, and blue for power.


Software


Control Panel

GUI



The control panel software for this project
encompassed approximately 50% of the entire project,
and involved the design
and implementation of a very
extensive GUI application in VB.net. VB.net was
chosen due to the number of examples available on the
internet, some familiarity with the tool, the ease of
programming GUIs with the tool, and the
professionalism associated with

the tool.


The Control Panel Software provides the tester with a
means of testing data error rate, bandwidth, and
latency. This is accomplished by analyzing all data
flowing over the serial port,

therefore, the primary
component of this software is a packet analyzer.
Because responsiveness is critical in order to ensure
accurate calculations of latency, etc, event driven
programming was used for the packet analyzer.
Additionally, the software is r
equired to simulate data
and transmit it over the serial port. Because of this, the
next component is a serial writer. The serial writer was
accessed each time the user pressed a button on the
GUI, and therefore did not need event
-
driven
programming. All o
f the software required to initialize
the serial port and configure R
equest
-
to
-
S
end

serial
transmission over it was found online via example
code. Finally, the GUI is required to read, write,
convert, and parse files. For this reason, the third
component o
f the GUI is a file reader/writer.


The graphical elements of the GUI were not a primary
component of the software developed for this portion
of the project, because VB.net provides the event
layering for all of the buttons, text boxes, etc. This
means th
at the programmer does not need to develop
code to detect button presses, key
-
strokes, etc. These
elements were added to the GUI using a drag and drop
method in visual studio.
Figure 6 shows the overview
of the control panel GUI.


Figure 6: Control Panel
GUI


To run the data error rate test, the GUI uses the file
reader/writer to read
-
in a specified file at the base PC,
converts the file to binary, and output's it over the
serial port. Then, at the receiving PC, the file is
received via the packet analyzer
, and written to a
specified file location on the receiving PC. Next, a bit
-
wise comparison of the sent file and the received file is
performed by reading in both files, converting them to
binary, and counting the number of bits that are
different between
the files using
Exclusive
-
OR (
XOR
)

operations. Note: the receiving PC for this test must
have on its hard drive a copy of the original file sent to
it in order to perform the comparison. Careful testing
was performed to ensure that bit error rate was
calcu
lated correctly by using the bit
-
wise comparator
to compare files with known bit
-
error rates.


To run the bandwidth test, the GUI uses the file
reader/writer to read
-
in a specified file at the test PC,
converts the file to binary, and output's it over the
serial port. After the file is transmitted, a special
command is sent to the RF micro
-
controller requesting
that it return its transmission time. The packet analyzer
then reads the transmission time, converts it to
bandwidth according to the length of the
file most
recently sent to the RF micro
-
controller, and displays
it on the screen. Testing was performed to ensure that
bandwidth was consistent from one transmission to the
next.


To run the latency test, the GUI uses the file
reader/writer to read
-
in a s
pecified file at the base PC,
converts the file to binary, takes a snapshot of the
current time, and output's the file over the serial port,
in that order. For this test, the file must contain a
special character, a capital 'Q', at its first index. Then,
a
t the receiving PC, the file is received via the packet

Copyright ©
200
8
Rochester Institute of Technology


analyzer. Upon receiving the file, the packet analyzer
parses it, discovers the 'Q' present at index one, and
enters phase two. In phase two, the packet analyzer
creates a local copy of the file, repl
aces the 'Q' with a
'P', and retransmits the new file back to the base PC.
When the GUI on the base PC receives the 'P' file, its
packet analyzer identifies the 'P', and immediately
takes a new time snapshot. This GUI then calculates
the latency by subtrac
ting this new time from the
original time
-
stamp taken at the beginning of the test.
Latency in m
illi
s
econds

is then displayed to the screen
of the base PC. Because delays are introduced by the
USB and the conversion/retransmit process on the
remote PC, careful timing analysis was performed for
this test in order to ensure its accuracy.



Table 1 :
Serial Proto
col Specification for PC
-
RF board
communication.



EXPERIMENTAL SETUP


The Test Bench requires two external connections for
proper operation for most of the tests that are to be run
by the system. In order to test the operating time, as
defined by the mis
sion profile, the test bench requires
the connection to the WOCCS battery board through
the Test Bench cable. This cable will provide the
voltages needed so that the correct measurements can
be made. The second connection needed for this test
is the USB
connection that has to be established
between the Test Bench and the laptop used for
testing. The software on the laptop is a Power Meter
GUI that displays the measured voltage, current and
instantaneous power consumption.


In order to run the data loss
, latency, bandwidth and
range tests, the USB cable must now be connected
between the DUT and the laptop. The laptop must be
running the RF Testing GUI (WOCCS Control
Station). In the GUI

the settings must be set to the
settings shown in Table
2

below
.
Once the proper
settings are insured, the USB connection must be
opened, the channel must be set, and the File Upload
and File Download paths must be properly set.


Baud Rate

115200

Stop Bits

1

Data Bits

8

Mode

Text

Table
2
:
Test Settings


RESULTS


A
test plan was written to perform design verificatio
n
testing. This allowed our team to verify that test
bench capabilities met engineering specifications and
in turn satisfied customer needs. The test plan has
validated that the test bench can successful
ly test
bandwidth, data loss, latency, and range of the
WOCCS project. At the present state, the operating
time test is not fully functional due to a complex
grounding issue. Under certain, controlled conditions,

the operating time test can successfully

measure the
voltage, current, and power of the WOCCS system
and therefore ensure operating time. However, until
this grounding issue can be resolved
, the operating
time test is not ready for final implementation.


For a 222 byte file the calculated bandw
idth was
64.571
Kbit
/s and bandwidth was consistent 9 out of
10 times. We believe there is an issue with how the
RF microcontroller is calculated bandwidth and we are
working with the RF teams to resolve this.


The data loss test showed a 0% data loss for

a file sent
over the RF link as expected. To verify that we were
correctly calculated data loss, the data was modified
after it was received such that it would be 10%
incorrect. The data loss test accurately reported a 10%
data loss.


For a 111 byte fil
e the calculated
latency was 182 ms,
204 ms, and 200 ms. For a 202 byte file the latency
was 178 ms, 188 ms, and 188 ms. This indicated that
the latency test consistently measures latency. The
accuracy of the latency test is dependent on accuracy
of the

time stamps taken on the RF microcontroller.
We are working with the RF teams to improve
accuracy of the time stamps.


The range test is simply a combination of the previous
test at a specified range. It was successfully tested that
at a range of 25 m using a midrange RF board, the
bandwidth was 16.507
Kbit
/s, the data loss was 0%,
the latency was 195 ms.



CONCLUSION


Currently the test bench
is capable of testing
bandwidth, latency, data loss, and range of the mid
-



range 1 module
. The operating time test which
measures voltage, current, and power draw is not fully
functional due to issue that result from two different
grounds that our test bench must interface with.
Interfacing with the mid
-
range 2 was not possible due
to the technical issues they had with their boards.
Testing long range was not possible due to difficulties
interfacing with the long range microcontro
ller.

Future teams should pay attention to the high and low
side of test capabilities. For example, due to a lack of
interfacing specifications the test bench was not able
to measure a current draw below 5 mA because it was
designed to measure current dr
aws above 30 mA.


One of the major achievements of the RF Test Bench
team was laying the foundations for future test
benches. Many of the difficulties faced by our team
were due to a poorly defined project. Given the task
of testing WOCCS functionality a
t the system level we
developed five tests (bandwidth, latency, data loss,
range, and operating time) that would accomplish this
goal. Another issue we faced was working
concurrently with the WOCCS system that was
actively being designed and manufactured.

This
meant that in order to proceed with our design we
were dependent on the other teams which lead to
delays in our schedule. This required a great deal of
flexibility in our part
, patience,

and a willingness to
rework many parts of our design so that
the test bench
would be compatible with the changing WOCCS
modules.

It would be very advantageous that the next
generation of WOCCS use common architecture,
namely the same microcontrollers.


Much of the ambiguity of our project has been
removed. In the
next generation of WOCCS, we
recommend that a future test bench team look closely
at the documentation we have created to help

define
their project scope and increase the capabilities of
what a test bench should be able to accomplish. We
also recommend th
at a future test bench team run one
quarter after the main WOCCS sequence so that they
do not have to deal with the frequent design change
s
inherent in

WOCCS.


ACKNOWLEDGEMENTS


The RF Test Bench team would like to sincerely thank
everyone that provided th
eir guidance and assistance
along the way. We would like to thank Philip Bryan,
Leo Farnand, and Vince Burolla for their role as
faculty guide
s
. Mark Smith, Chris Fisher, and the rest
of the MSD staff for their assistance and support. Dr.
Dorin Patru as

our faculty consultant for his technical
assistance.

Dr. Andreas Savakis for his assistance and
for attending our design reviews. Dave Hathaway,
Robert Kraynik, and Steve Kosciol for their a
ssistance
in the machine shop.
We would also like to
acknowled
ge the use the Senior Design Center, and
the electrical and mechanical engineering labs of the
Kate Gleason College of Engineering that we used.

Finally, we would like to thank Harris Corporation for
sponsoring and funding the WOCCS project.


REFERENCES


[1] processing.org (n.d.) Processing Tools Download
and Reference Guide [Online] Available:
http://processing.org/reference/



[2] arduino.cc (n.d.) Arduino Tools Download and
Reference Guide [Online] Available:
http://arduino.cc/en/Guide/HomePage



[3] mi
crosoft.com (n.d.) VB.net and Reference Guide
[Online] Available: http://msdn.microsoft.com/en
-
us/vbasic/default


[4]
Quickturn PCB Manufacturer (n.d)
[Online]

Available:

http://www.4pcb.com
/