Download Technical Paper - Edge - Rochester Institute of Technology

Multi-Disciplinary Senior Design Conference
Kate Gleason College of Engineering
Rochester Institute of Technology
Rochester, New York 14623
Project Number: P11210
WOCCS: RF TEST BENCH
Michael DeFrancis – Computer Engineer
Shaheer Khan – Electrical Engineer
Demetrios Koukouves – Mechanical Engineer
Andrew Nosal – Electrical Engineer
ABSTRACT
USB - Universal Serial Bus
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 and power capabilities.
INTRODUCTION
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 Oxide Semiconductor Field Effect
Transistor
Op-amp – Operational Amplifier
LED – Light Emitting Diode
DUT - Device Under Test
ADC - Analog-to-Digital Converter
'Serial Port'- Serial Emulation over USB
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
communicating and controlling 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 purposes. 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
device 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 receive 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
Copyright © 2011 Rochester Institute of Technology
Page 1 of 8
and reception 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.
For the Latency, Bandwidth, Data Loss, and Range
Tests:
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 industry 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
aims 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 explains 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 tests.
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.
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 WOCCS
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 Bench Control Panel Software allows the
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.
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:
DESIGN METHODOLOGY
For the Power Test:
Hardware – Power Testing Board
1x Laptop
Arduino Board
Arduino Software
Power testing board
Power Meter GUI Software
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 mission profile, a means to measure the
voltage and current had to be designed. By measuring
Hardware
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 returned should be communicated over USB to
the computer so that the results can be displayed
graphically.
imposed a minimal load on the WOCCS system, a Pchannel 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 voltage
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 2: Power Testing Board Schematic
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 small 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Ω resistors 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 opamp 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 divided
down by ~5.3 by using a voltage divider circuit that
consists of a 430kΩ resistor and a 100kΩ 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 that the Test Bench
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 board 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 Vbatt+ 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.
Copyright © 2008 Rochester Institute of Technology
Hardware – Arduino
the Arduino ground which was linked to the laptop
ground.
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.
Figure 4 :Test Bench Enclosure
Hardware – Enclosure and Packaging
Software
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 for 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 rails 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 connector. 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 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.
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 board
and then inserted into the pin headers of the Arduino.
In order to connect the power testing board with the
power board, a bundled cable was fashioned using
crimping terminals and keyed 4-pin Molex connectors.
The enclosure was grounded by tying a wire 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
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 free 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. Writing 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 Moore
State Machine was designed to perform the needed
functionality. Moore State Machines control output as
a function of the current state alone. The state machine
switches between four modes of operation: idle,
reading power, reading voltage, and reading current.
The commands that the PC sends to the Arduino are
the following: '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 analyzer
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 received 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 states, 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
capacitance 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
calculation 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 that 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 to the exact resistance of
this sense resistor to obtain current. Current is output
over the serial port in milliamps. 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 milliWatts.
Software – 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, manipulation 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 development 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 needed to be developed for
each button. Additionally, all of the graphical elements
of the GUI needed to be drawn manually (each line on
the 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 machine was necessary
in order to control the output of command data over
Copyright © 2008 Rochester Institute of Technology
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 input 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 software 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
enters 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.
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.
Software – 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 bitwise 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
calculated correctly by using the bit-wise comparator
to compare files with known bit-error rates.
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 required 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 of the software required to initialize
the serial port and configure Request-to-Send 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 of 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 that the programmer does not need to develop
code to detect button presses, key-strokes, etc. These
Figure 6: Control Panel GUI
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 specified 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,
at the receiving PC, the file is received via the packet
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, replaces 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 subtracting this new time from the
original time-stamp taken at the beginning of the test.
Latency in milliseconds 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.
opened, the channel must be set, and the File Upload
and File Download paths must be properly set.
Baud Rate
Stop Bits
Data Bits
Mode
115200
1
8
Text
Table 2: Test Settings
RESULTS
A test plan was written to perform design verification
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 successfully 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 bandwidth 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.
Table 1 : Serial Protocol 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 mission 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
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 file 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-
Copyright © 2008 Rochester Institute of Technology
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 microcontroller.
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 draws 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 at 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 that 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 changes
inherent in WOCCS.
ACKNOWLEDGEMENTS
The RF Test Bench team would like to sincerely thank
everyone that provided their guidance and assistance
along the way. We would like to thank Philip Bryan,
Leo Farnand, and Vince Burolla for their role as
faculty guides. 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 assistance
in the machine shop.
We would also like to
acknowledge 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] microsoft.com (n.d.) VB.net and Reference Guide
[Online] Available: http://msdn.microsoft.com/enus/vbasic/default
[4] Quickturn PCB Manufacturer (n.d)
[Online] Available: http://www.4pcb.com/