proceedings - rochester institute of...

Multi-Disciplinary Senior Design ConferenceKate Gleason College of Engineering

Rochester Institute of TechnologyRochester, New York 14623

Project Number: P11210

WOCCS: RF TEST BENCH

Michael DeFrancis – Computer Engineer Demetrios Koukouves – Mechanical EngineerShaheer 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 and 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 BoardGUI – Graphical User InterfaceMOSFET – Metal Oxide Semiconductor Field Effect Transistor Op-amp – Operational AmplifierLED – Light Emitting DiodeDUT - Device Under TestADC - 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 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 of 8

Proceedings of the Multi-Disciplinary Senior Design Conference

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.

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.

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 Power Test:

1x LaptopArduino BoardArduino SoftwarePower testing boardPower Meter GUI Software

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

Figure 1 : System Architecture Block Diagram

2x LaptopsTest Bench Control Panel SoftwareSerial 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.

DESIGN METHODOLOGY

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 mission profile, a means to measure the

Project P0xxxx

voltage and current had to be designed. By measuring 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.

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 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 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 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 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 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.

Copyright © 2008 Rochester Institute of Technology

Figure 2: Power Testing Board Schematic


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.

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 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 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 the Arduino ground which was linked to the laptop ground.

Figure 4 :Test 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 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.

Project P0xxxx

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 milli-Watts.

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 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.

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 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 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 calculated 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

Project P0xxxx

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.

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 opened, the channel must be set, and the File Upload and File Download paths must be properly set.

Baud Rate 115200Stop Bits 1Data Bits 8Mode 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.

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-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/en-us/vbasic/default

[4] Quickturn PCB Manufacturer (n.d) [Online] Available: http://www.4pcb.com/

Project P0xxxx

http://www.4pcb.com/

proceedings - rochester institute of...

Documents