<%BANNER%>

Reconfigurable Multi-Node Wireless Communication Testbed


PAGE 1

RECONFIGURABLE MULTI-NODE WI RELESS COMMUNICATION TESTBED By B. SCOTT KENNEDY A THESIS PRESENTED TO THE GRADUATE SCHOOL OF THE UNIVERSITY OF FLOR IDA IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF MASTER OF SCIENCE UNIVERSITY OF FLORIDA 2004

PAGE 2

Copyright 2004 by B. Scott Kennedy

PAGE 3

This thesis is dedicated to my Mom, Dad, and Steven; for pushing and encouraging me.

PAGE 4

ACKNOWLEDGMENTS I would first like to thank Dr. Tan F. Wong for giving me this opportunity and for his guidance during the entire process. Without his continued support, this thesis would not have been a reality. When I was looking for a research topic, I went to Dr. Fang, who referred me to Dr. Wong. I would like to thank Dr. Fang for recognizing my desire to do research, and for being on my committee. I would also like to send my sincere thanks to Dr. Shea for being on my committee, and for his continued support. Special thanks go to Li Xin for helping me with the code, and all those long hours of debugging. Finally, I would like to thank my family. I have dedicated this thesis to them, for all of their love and support. iv

PAGE 5

TABLE OF CONTENTS page ACKNOWLEDGMENTS.................................................................................................iv LIST OF TABLES............................................................................................................vii LIST OF FIGURES.........................................................................................................viii ABSTRACT.........................................................................................................................x CHAPTER 1 INTRODUCTION........................................................................................................1 2 HARDWARE...............................................................................................................6 The RF Front End.........................................................................................................7 Antenna Design..........................................................................................................11 Data Acquisition (DAQ) Pad 6070E..........................................................................13 Laptop.........................................................................................................................17 Wireless Broadband Router........................................................................................18 3 SOFTWARE IMPLEMENTATION OF THE BASESTATION...............................19 LabView Overview.....................................................................................................19 DataSocket..................................................................................................................19 Random Data Generator.............................................................................................23 Encoder Code..............................................................................................................24 Synchronization and the M-sequence.........................................................................26 Analog Output............................................................................................................29 Receiver Statistics.......................................................................................................30 4 SOFTWARE IMPLEMENTATION OF THE RECEIVING NODE........................32 Initialization................................................................................................................32 Triggering...................................................................................................................35 Analog Input...............................................................................................................37 Correlating Detector...................................................................................................39 Normalizing the Data..................................................................................................40 Signal to Noise Ratio Measurement...........................................................................41 v

PAGE 6

Decoding Process........................................................................................................45 Exchange Protocol......................................................................................................46 Displaying Results......................................................................................................47 5 ENCODER AND DECODER....................................................................................49 Encoder.......................................................................................................................49 Viterbi Convolutional Decoding Algorithm...............................................................51 The MAP Decoder......................................................................................................54 6 TESTING....................................................................................................................56 7 CONCLUSION...........................................................................................................64 APPENDIX A LABVIEW CODE......................................................................................................70 B LABWINDOWS CODE.............................................................................................72 Receiver Code.............................................................................................................72 Basestation Code........................................................................................................82 Multi-Dimensional Parity Check Code......................................................................88 The CC.H Header File................................................................................................92 C PCB LAYOUT FOR THE RECEIVER AND TRANSMITTER.............................103 D TROUBLESHOOTING GUIDE..............................................................................106 LIST OF REFERENCES.................................................................................................107 BIOGRAPHICAL SKETCH...........................................................................................108 vi

PAGE 7

LIST OF TABLES Table page 4-1. Resulting array mask from the given m-sequence. ....................................................35 6-1. Sa mple of the statistics collected by the base station.................................................59 6-2. Final results. ...............................................................................................................63 vii

PAGE 8

LIST OF FIGURES Figure page 1-1. Reachback Communications scenario investigated......................................................1 1-2. Collaborative Reception...............................................................................................3 1-3. Basic structure of a single node....................................................................................4 2-1. Testbed node arrangement............................................................................................6 2-2. Laipac receiver, RLP916-A..........................................................................................8 2-3. Laipac transmitter, TLP916-A......................................................................................9 2-4. Antenna design and dimensions.................................................................................14 3-1. Flowchart of the base station code.............................................................................20 3-2. Connecting to LabWindows.......................................................................................22 3-3. VIs used to open a Datasocket connection.................................................................23 3-4. Random data generator using LabView.....................................................................24 3-5. Frame structure of 1 packet........................................................................................26 3-6. Linear output after an idle period...............................................................................28 3-7. Creating the array to be sent to the front end using LabView....................................29 3-8. Controlling the D/A using the AO Wave VI..............................................................30 4-2. Building the array mask from mesequence.txt...........................................................34 4-3. Buffering the sampled linear output of the receiver...................................................38 4-4. Correlating detector....................................................................................................41 4-5. Linear output with the DC removed..........................................................................43 4-6. Normalizing the data.................................................................................................43 viii

PAGE 9

4-7. Signal to Noise Ratio Estimate...................................................................................44 4-8. Calculating the estimated signal to noise ratio...........................................................45 4-9. The exchange protocol................................................................................................47 5-1. Convolutional encoder (rate K=3).........................................................................49 5-2. Trellis diagram for a rate K=3 encoder.................................................................52 6-1. Cart Locations in the New Engineering Building......................................................57 6-2. VI used to bin the receiver statistics...........................................................................60 6-3. BER vs SNR graph of the data given in table 6-2......................................................62 6-4. BER vs SNR graph of the computer simulation.........................................................62 A-1. Receiver Front Panel..................................................................................................70 A-2. Base station Front Panel............................................................................................71 C-1. Top layer for the receiver........................................................................................103 C-2. Bottom layer for the receiver..................................................................................104 C-3. Top layer for the transmitter...................................................................................104 C-4. Bottom Layer for the transmitter............................................................................105 ix

PAGE 10

Abstract of Thesis Presented to the Graduate School of the University of Florida in Partial Fulfillment of the Requirements for the Degree of Master of Science RECONFIGURABLE MULTI-NODE WIRELESS COMMUNICATION TESTBED By B. Scott Kennedy May 2004 Chair: Tan F. Wong Major Department: Electrical and Computer Engineering In a wireless network, multiple communications devices in close proximity form a natural distributed antenna array. If a group of such devices receive in some collaborative manner to exploit the inherent spatial diversity, then the system performance can be significantly improved. Computer simulations were performed to test this hypothesis. Simulation results confirmed that collaborative reception can be used to improve system performance. Designing a testbed to demonstrate collaborative reception in real-life is an imperative next step. By conducting experiments on network protocols and communications techniques over real-life wireless communication channels, the conclusions obtained from the computer simulation can be verified; and all considerations in making the theoretical design a practical, real-life communication system can be made clear. The goals of this research were to design a reconfigurable multi-node wireless communication testbed; to implement collaborative reception techniques into the testbed; x

PAGE 11

to show the usefulness of the testbed by gaining a better understanding of the collaborative techniques and how these techniques may be optimized; and to verify that collaborative reception can improve the receive capabilities of a real-life wireless network. The design of the testbed must be as general as possible, to allow experimental evaluation of different communication techniques and higher layer protocols. xi

PAGE 12

CHAPTER 1 INTRODUCTION Reachback communications is a military term for a mobile node or ground troop communicating with or reaching back to a command station. Reachback communications can also refer to the scenario of multiple nodes or a group of infantry men, for example, communicating back to a single base station. The group of mobile nodes form an ad hoc network. The base station will either transmit a broadcast message to the ad hoc network or receive individual messages from each mobile node within the ad hoc network (Figure 1-1). Figure 1-1. Reachback Communications scenario investigated. Reachback communications is not limited to military applications. Any scenario that requires mobile nodes to communicate back to a base station can benefit from improved reachback communications. Other applications that could benefit from improved reachback capabilities may include cellular networks, sensor networks, fire and rescue teams, and police units. With these obvious applications, the demand for improved reachback communications is constantly increasing. New 1

PAGE 13

2 Micro-Electro-Mechanical Systems or MEMS technology will allow sensors to be deployed in various applications. These Sensor Networks will needsort of reachback communications to receive instructions, and to report their collected data. As described earlier, very often the military will require groups of infantry to be sent out on special operations. These special operation troops will need to be able to transmit and receive voice, data, and full-motion video images in real time, without thadversary being able to detect the emission or reception of tactical operation signatures. Presently and in the future, a premium will be placed on higher bandwidth, increased range, and low probability of interception and detection, for these types of networks. Ostudy focuses on making these improvements to the reception capabilities of a mobile station in an ad hoc network, using a real-life communication testbed. Receive diversity is a communications technique that can be used thousands of some e ur to improve the receivme nnot ork, multiple communication devices in close proximity form e capabilities of a mobile node in an ad hoc network and was the focus of our study. Using antenna arrays to obtain receive diversity is an unattractive choice in sosystems. This is because, to obtain receive diversity, the array length should be several times the wavelength of the RF carrier, and the array elements should be physically connected to a central combiner. Small handsets carried by infantry, for example, casupport this size requirement. In a wireless ad hoc netw a natural distributed antenna array. If a group of such devices receive in some collaborative manner, to exploit the inherent spatial diversity, then the system performance of a single receiver can be significantly improved (Figure 1-2).

PAGE 14

3 A B Figure 1-2. Collaborative Reception. A) Each node individually decodes the received message and generates a reliability measure (soft outputs) of data bits. B) The nodes exchange the reliability information to improve decoding. Computer simulations were performed to test this hypothesis. Results showed that gains of over 30 dB are possible with clusters of more than 8 nodes. This implies a possible increase in transmission range by a factor of 5 to 32 (or translates into a decrease in transmitter power by a factor of 1000). Furthermore, diversity can be obtained with a fraction of the overhead involved in traditional combining schemes. Designing a testbed to demonstrate collaborative reception in real life is an imperative next step. By conducting experiments on network protocols and communications techniques over real-life wireless communication channels, the conclusions obtained from the computer simulation can be verified, and all considerations in making the theoretical design a practical, real-life communication system can be made clear. Designing a testbed to demonstrate collaborative reception in real life is an imperative next step. By conducting experiments on network protocols and communications techniques over real-life wireless communication channels, the conclusions obtained from the computer simulation can be verified, and all considerations in making the theoretical design a practical, real-life communication system can be made clear. The testbed under development consists of six reconfigurable transceiver nodes that operate in the 900 MHz ISM band. Each transceiver node is made up of a radio frequency The testbed under development consists of six reconfigurable transceiver nodes that operate in the 900 MHz ISM band. Each transceiver node is made up of a radio frequency

PAGE 15

4 (RF) front end, a software-processing (SP) baseband unit containing a data acquisition (DAQ) unit and a notebook computer (Figure 1-3). Each node or computer has an 802.11 wireless network card. The ad hoc network is controlled by a wireless broadband router, which allows high-speed data transfer among individual nodes. DAQ ISM-Band Laptop (A/D-D/A) RF Frontend Computer Figure 1-3. Basic structure of a single node The programs used to write the code are National Instruments Labview and Labwindows/CVI (National Instruments, Austin, TX). Labview was used to control the DAQ, acquire and normalize the data, verify triggers, pass data to LabWindows, and be the user interface to the node. LabWindows was used to integrate the decoder and encoder (written in C) into the Labview code. Users in the future may fully integrate the decoder and encoder directly into the Labview code, and eliminate the need for LabWindows altogether, to be discussed later. Our goals were to design a reconfigurable multi-node wireless communication testbed, to implement collaborative reception techniques into the testbed, to show the usefulness of the tested by gaining a better understanding of the collaborative techniques and how these techniques may be optimized, and to verify that collaborative reception can improve the receive capabilities of a real-life wireless network. To make the design successful, all electrical and physical specifications must be considered. Also, a significant amount of code must be developed, to make the testbed

PAGE 16

5 truly reconfigurable (adjustable packet size, data rate, modulation, collaboration techniques, etc.). Our study only addressed the physical layer considerations of receiving one packet, no network protocol was designed. The next chapters describe the design of the testbed and the implementation of collaboration techniques. It is important to note that the collaboration techniques used in this study can be modified or completely replaced. Collaboration techniques described in the next chapters are used to better understand the testbed design, and to show how the testbed can give practical feedback about different decoding processes and collaborative techniques.

PAGE 17

CHAPTER 2 HARDWARE The testbed is made up of individual nodes. Each node comprises an RF front end, an antenna, a data-acquisition unit, and a laptop computer. As stated earlier, the hardware configuration is the same for both the mobile receiving nodes and the transmitting base station. Figure 2-1 shows the testbed configuration and its components. A more detailed diagram of the individual node is shown Figure 1-4. Again, the physical make up is the same for both the receiving nodes and the single transmitter or basestation. The software design differences between the mobile nodes and the base station are discussed in Chapters 3 and 4. DAQ DAQ DAQ Transmitting Basestation DAQ Receiving Ad hoc Network Figure 2-1. Testbed node arrangement 6

PAGE 18

7 As mentioned in the introduction, this chapter will explain the motivation for choosing each component used in the testbed along with the important specifications and their implications concerning maintenance and future upgrades. This chapter describes the individual hardware components of the testbed. They include the RF front end, antenna, data-acquisition (DAQ) pad, laptop computer, and wireless broadband router. The RF Front End When choosing the RF frontend, a few key factors need to be considered. The frontend needs to have low power consumption, be low cost, be easy to use, have typical operating voltages, operate in a frequency range in the ISM band, and most importantly provide a receive signal strength indicator (RSSI) output. Low power consumption is desired because the mobile nodes will be battery operated. Testing can take several hours and even though the main power consumption will be from the DAQ and laptop, minimizing the power consumption of the frontend will make the nodes more efficient in providing a long duration of operation. One goal of the research is to demonstrate the ability of collaborative reception techniques to improve the transmission range. This will be demonstrated by placing the receiving nodes at distances near the limits of the frontends range. Having a high power long range frontend is not necessary for this purpose. In fact, long range coverage would make testing more difficult because the receiving nodes would have to be placed further away from the basestation. This would require more area and more time to set up the testbed. Although this research focuses on improving the receive capabilities, future work will also address transmission capabilities. It is important that the frontend is a transceiver, capable of both transmitting and receiving data.

PAGE 19

8 The RSSI output is the most important requirement. The RSSI is used to calculate the signal to noise ratio, decode the received data, and determine the reliability of each bit. Without access to this output, the collaborative techniques can not be implemented. The RF frontend initially chosen was the RF2905-H evaluation board from RF Micro Devices. The RF2905 met all of the key requirements, however, it was not very stable and only two of the five evaluation boards would consistently work together. For this reason a change was made. One of Laipacs transmitter receiver pairs, the TLP916A and RLP916A, met most of the key requirements. The Laipac frontend is not a transceiver which is adequate for this research. Future operators that want to research collaborative transmition may decide to design a board with a transmitter and a receiver. These boards can be used as the transceiver for each node. This transmitter receiver pair was much more stable and easy to use compared to the RF2905. The Laipac chipset was designed for 916.5 MHz applications with data rates up to 200Kbps and typical range of 300 feet open area. A schematic for both the receiver and transmitter are given in Figure 2-2 and 2-3 respectively. Figure 2-2. Laipac receiver, RLP916-A. Frequency: 916.5 MHz, Modulation: ASK, Supply Voltage: 2.7 to 5.0 VDC, Output: Digital and Linear, Chip Set Technology Sensitivity: -104dBm.

PAGE 20

9 Figure 2-3. Laipac transmitter, TLP916-A. Frequency: 916.5 MHz, Modulation: ASK, Operation Voltage: 2 to 12 VDC, RF Output Power: 10mW. The operating and control voltage range has a minimum of 2 volts and a maximum of 12 volts DC. The standard TTL operating voltage of 5 volts is used which is well within the range. The power consumption is relatively low. For the transmitter the peak current at 5 volts is about 5 mA. For the receiver the peak current at 5 volts is about 10 mA. The transmitter and receiver are easily controlled. A 5 Volt square wave serial data stream is used to drive the transmitters data in pin. As mentioned it is in the 915 MHz ISM band [1]. Most importantly, the receiver has a linear output which will give a received signal strength or RSSI output. The collaboration code was written for BPSK modulation. The frontend is incapable of BPSK, however, this is not a problem because the outputs of an OOK signal can be easily manipulated to resemble the outputs of a BPSK signal. BPSK outputs can are unipolar and can be represented by the equation, b i = (-1) i A binary 1 or b 1 = -1 and a binary 0 or b 0 = 1. The linear output of the receiver has a constant DC voltage, therefore the output is not unipolar. The first step to converting this output to BPSK is to remove the DC voltage. This can be done by using a DC blocking capacitor. If the DC blocking capacitor is too big it will have a larger time constant or slow settling time. This will distort the liner output. If the DC blocking capacitor is too small then it cant produce the appropriate voltage level and will attenuate the signal. A 68 pF

PAGE 21

10 capacitor had a good response time and did not attenuate the signal too badly. However, there was some signal attenuation. An amplifier was used to compensate for the attenuation. Because the signal and the noise were both attenuated by the capacitor an amplifier proved to be an acceptable solution. Experimentation showed that using just a DC blocking capacitor was not sufficient. It was observed that the pulse width for a binary 1 was more narrow than the pulse width for a binary 0 (i.e., the linear output did not have a 50% duty cycle). For this reason the capacitor could not completely remove the DC. Because of the duty cycle, the average was around 100 mV instead of 0 V and therefore not unipolar. A second step had to be performed to convert the linear output to a unipolar signal. Using code an average linear output can be determined and be subtracted from each voltage sample. By subtracting the average, the linear output was now unipolar. It was also observed that the receiver required a significant amount of settling time. When transmission began after a long idle period the receivers linear output would ramp up until it settled. This ramping effect was observed even without the DC blocking capacitor. One solution would be to continuously transmit a square wave which would keep the channel at a settled state. Because of power consumption and interference, this solution would be extremely inefficient. Another solution would be to take a local average and subtract it from its corresponding samples. This is easily implemented in code. The code would break the sampled data into blocks. The first block can be brought in and averaged. This average is then subtracted from each sample in that block. This process is repeated for each block of data and hence a local average is subtracted

PAGE 22

11 from the entire sampled data stream. This process eliminates the ramping effect observed. The code used to implement this process is discussed in Chapter 4. As discussed, the Laipac frontend has some drawbacks. These drawbacks can be dealt with making the Laipac frontend a good choice. The TLP916 and RLP916 are more robust and much easier to use compared to the RF2905. Overall the Laipac fontend meets most of the key factors and will be used in the testbed design. Antenna Design The key factors to consider when designing the antenna are the weatherproofing of the antenna, desired coverage, impedance of the RF frontend, complexity of the entire system, and cost. Weather proofing the antenna is not a concern because all of the testing would be done either inside or outdoors in favorable conditions. The desired coverage is omni-directional in azimuth. The impedance of the frontend is 50. The antenna needs to be simple, cheap, reproducible, fairly rugged, and with repeatable standard characteristics. These considerations lead to a simple ground plane vertical wave antenna. The antenna is fed with 50 coaxial cable. It is an "unbalanced" antenna, such that the shield is connected to the ground plane and the vertical portion is connected to the center conductor. The free space wavelength, at 915 MHz is about 0.33 meters calculated by the equation: = C / F[Hz] where C = 2.998E8 m/s (speed of light).

PAGE 23

12 The vertical portion, L, is wavelength long and is therefore resonant at that frequency (i.e., L = /4). Therefore L = 0.0819 meters or about 3 inches when calculated using the free space speed of light. In reality the element ends up being about 10% shorter due to the "end effect" of the wire or about 3 inches in total length above the ground plane. It is at this frequency that this element will efficiently accept radio frequency power and "convert" it into electromagnetic fields. Its impedance is about 35 and therefore a good match for 50 cable and the frontend. Of course, other vertical lengths that result in zero reactance at the feed can also be used. The length of wavelength is the next useful length above wavelength; it is at this length that a current maximum again appears at the feed. The wavelength case has a voltage maximum and therefore an impedance which is prohibitively high to be fed directly by 50 ohm coaxial cable. Also, the elevation antenna pattern for the wave vertical is a horizontal "donut" with the vertical antenna at the center. The pattern is uniform in azimuth. The wavelength vertical has an elevation pattern which has an additional null at around 70 from the vertical, making it less than useful for most applications. These factors made the wave antenna the obvious choice. The vertical antenna is fed by the ground plane. The ground plane acts as a "counterpoise", that is, it provides the ground reference by having an impedance at its center which, if measured against the environment, is quite low. The impedance is quite low because it is wavelength in radius, that is the outer edge of the ground plane is wavelength away from the center. Transmission line theory states that the impedance at the center is now a short to ground and thus a great place to terminate the outer conductor of the coaxial cable.

PAGE 24

13 The ground plane antenna should have a minimum ground plane radius of about free space wavelength (i.e., about 3 inches). Therefore, a 6 inch circle copper plate was used as the ground plane. A BNC bulkhead connector was used as a vertical mount. The connector has an exposed terminal which was used as the feed. The connector was mounted upside down on the copper ground plane, that is the BNC portion facing down and the solder terminal facing up. The center conductor is just a solid copper wire. The wire is thick in diameter so that it can fit in the BNC terminal. The center conductor is soldered into the solder cup of the connector. The solid copper conductor acts as the vertical element. The "end effect" which causes the vertical radiator to be about 10% shorter than the free space value results in a total length, again, of about 3 inches for the vertical element, including the length of the solder terminal above the surface of the ground plane. Figure 2-4 shows a diagram of the antenna and its dimensions. Data Acquisition (DAQ) Pad 6070E A data acquisition (DAQ) device is necessary to programmatically acquire signals, send data, and control the RF frontend. It is important that the DAQ is portable, has easy I/O connections, and can interface with the laptop. National Instruments DAQPad 6070E is a high-performance multifunction analog, digital, and timing I/O device for computers with IEEE 1394 (firewire) ports. Supported functions in the DAQPad-6070E include analog input (AI), analog output (AO), digital I/O (DIO), and timing I/O (TIO). The two most important features of the DAQPad 6070E are the 12-bit A/D converter (ADC) with 16 analog inputs and the two 12-bit D/A converters (DACs) with two voltage outputs. The ADC will be used to

PAGE 25

14 sample the RSSI output of the frontend. One of the DACs will be used to drive the frontend with the output waveform. 3 6.5 Side View 6.5 6.5 Top View Figure 2-4. Antenna design and dimensions National Instruments portable E Series DAQ delivers the same functionality available in PCI and PXI E Series DAQ devices in a portable format. The DAQPad devices are hot swappable and available in up to three different configurations. The IEEE 1394 automatically handles the assignment of all host resources, so the user can install the device without powering down the computer. The 15 cm enclosure is a low-profile package that fits under the laptop computer. It features a 68-pin shielded connector were the control lines, RSSI output, and data pins of the frontend are connected.

PAGE 26

15 The DAQPad comes with a software package, Measurement and Automation Explorer (MAX). MAX allows the user to configure the DAQ, add new channels, add new interfaces, add virtual instruments, execute system diagnostics, view devices and instruments connected to the laptop, and schedule updates to the National Instruments software. MAX is used, most importantly, to configure the DAQ. Before running any collaborative code the user should open MAX and make sure the DAQ is recognized and configured appropriately. This is done by selecting the Devices and interfaces folder in the configuration window. Under this folder the DAQ pad 6070E should be listed. The user should right-click on the DAQ 6070E and select properties. This will open the configuration window for the DAQ pad 6070E. The three tabs of importance are System, Analog Input (AI), Analog Output (AO), and Accessories. The DAQ pad 6070E has three input modes nonreferenced single-ended (NRSE) input, referenced single-ended (RSE) input, and differential (DIFF) input. A channel configured in the NRSE mode uses one analog channel input line, which connects to the positive input of the programmable gain instrumentation amplifier (PGIA). The negative input of the PGIA connects to the analog input sense (AISENSE) input. A channel configured in the RSE mode uses one analog channel input line, which connects to the positive input of the PGIA. The negative input of the PGIA is internally tied to the analog input ground (AIGND). A channel configured in the DIFF mode uses two analog channel input lines. One line connects to the positive input of the device PGIA, and the other connects to the negative input of the PGIA [2]. For the testbed configuration the appropriate input mode is RSE.

PAGE 27

16 The DAQPad 6070E has two input polarity settings unipolar and bipolar. Unipolar input polarity means that the input voltage range is between 0 and Vref, where Vref is a positive reference voltage. Bipolar input polarity means that the input voltage range is between Vref/2 and +Vref/2. The DAQ pad 6070E has a unipolar input range of 10V (0V to 10V) and a bipolar input range of 10V (-5V to 5V). There is also a software-programmable gain on the DAQ pad 6070E, however, this gain will be left at 1 for the testbed configuration. The input polarity and range setting is based on the expected range of the incoming signal. A large input range can accommodate a large signal variation but reduces the voltage resolution. Choosing a smaller input range improves resolution but may result in the input signal going out of range. For the best results the input range is matched as closely as possible to the expected range of the input signal [2]. The DAQPad 6070E allows the user to enable dither. With dither enabled approximately 0.5 LSB rms of white Gaussian noise is added to the signal to be converted by the ADC. Enabling dither will artificially increase the resolution of the signal. This is undesired for our system because the collaborative technique requires an estimation of the signal to noise ratio. With dither enabled this estimation will appear better than it actually is, therefore dither is disabled for the testbed configuration. The DAQPad 6070E supplies two channels of AO voltage at the I/O connector. The reference and range are selected in MAX. The reference can either be internal or external, and the range can be either bipolar or unipolar [2]. An internal reference is the appropriate setting for the testbed configuration. A unipolar configuration has a range of 0 to Vref at the AO. A bipolar configuration has a range of Vref to +Vref at the AO.

PAGE 28

17 Vref is the +10V onboard reference because the internal reference is used. The frontend requires a unipolar baseband data signal therefore, a unipolar range is selected for the testbed configuration. In the Accessories tab the SCB-68 should be selected. This is the mass terminal block to which all of the control lines and the input/output connections are wired. It is important that the user selects this accessory in the accessories tab. MAX also allows the user to test the DAQ pad. A quick diagnostic is performed by pressing the test resources button in the System tab. The user may also choose to run the test panel and generate outputs or view inputs. This is a very helpful debugging tool. The user should initially check the configurations and test the resource every time the testbed is used. Laptop The testbed is reconfigurable with a laptop as the software processing baseband unit. The laptop will run all of the software and control the DAQ pad. The operator will use the laptop to modify packet size, change the amount of exchange data bits, enter the number of receivers, etc. It is important that the laptop is fast, reliable, has Windows operating system to run LabView and LabWindows, an IEEE 1394 firewire port, and an 802.11 wireless network card. The laptops chosen were from Dell. There are two models of Dell laptops used, the Inspiron 8200 and the Inspiron 5150. Both laptops meet all of the desired specifications. The Inspiron 8200 has an Intel Pentium 4 processor at 2.00 GHz, 512 MB of RAM, Windows XP operating system, one IEEE 1394 port, and the True Mobile 1300 802.11 b/g3 wireless Mini-PCI card.

PAGE 29

18 The Inspiron 5150 has an Intel Pentium 4 processor at 3.2 GHz, 1 GB of RAM, Windows XP operating system, one IEEE 1394 port, and an internal True Mobile 1400 Dual Band Mini-PCI card. Wireless Broadband Router In order for the mobile nodes to collaboratively decode the received signal they need to be connected to a high-speed ad hoc network. The ad hoc network is easily implemented using the 802.11 wireless cards and a wireless router. The router is used as a DHCP server and assigns an IP address to each computer or node. The Dell True Mobil 1184 Wireless Broadband Router was used to implement the ad hoc network. The Wireless Broadband Router supports up to 252 clients. Up to 16 of the 252 clients can be wireless. The Network Address Translation (NAT) feature allows 64 clients to simultaneously communicate out to the Internet [3]. Future operators are limited to 16 mobile receiving nodes using this router. The code was written for a maximum of 4 mobile nodes, well under the maximum capacity of the router. The built-in Ethernet wireless access point runs at 11 Megabits per second (Mbps). The maximum distance between the Broadband Router and each computer is 300 feet. This distance may be less depending on the environment [3]. The connection speed and distance specifications of the 1184 wireless broadband router will be sufficient for the high-speed ad hoc network.

PAGE 30

CHAPTER 3 SOFTWARE IMPLIMENTATION OF THE BASESTATION As explained in the introduction this chapter will describe the code written to implement the single transmitter or base station. This chapter will follow the flowchart describing the base station implementation given in Figure 3-1. Individual sections will include LabView Overview, Datasocket, Random Data Generator, Encoder code, Synchronization and the M-sequence, Analog Output, and Receiver Statistics. LabView Overview LabView is a graphical development environment designed specifically for building testing and measurement applications. LabView is often compared to programming languages because it shares many of the same characteristics as a programming language. With LabView the user can control the Daq and perform other useful functions inherent in other programming languages. These two capabilities make LabView an obvious choice for the testbed design. LabView is used in the base station implementation to generate the random data bits, pass the random data to an encoder written in C, send the data to the RF front end, and analyze the data received by each mobile node. The entire LabView code is given in Appendix A. DataSocket DataSocket is an Internet programming technology used by National Instruments that simplifies data exchange between computers and applications. DataSocket allows a user to efficiently pass data over the Internet or network, and respond to multiple users 19

PAGE 31

20 Send initializing data to LabWindows Wait for encode button no E n code y es Gener a te r a ndo m d ata a nd send to encoder Build Arra y of data to be transmitted Wait for transmit button no Transmi t y es Output data waveform Analyze or Transmit Transmit Analyze # o f r eceivers 1 2 3 4 Stats for station 1 Stats for station 1 and 2 Stats for station 1,2,and 3 Stats for station 1,2,3,and 4 Display Statistics Figure 3-1. Flowchart of the base station code

PAGE 32

21 without the complexity of low-level TCP programming. DataSocket makes the sharing of scientific and engineering data between software applications and between networked computers as easy as reading and writing data to files [4]. There are two types of Datasocket connections used in the testbed. One type of connection is between two different applications running on the same laptop. The other type of connection is between different computers on the wireless network. In both cases a Datasocket server is needed. All nodes on the network should have their Datasocket servers running before starting the testbed. The Datasocket server on each node will act as a localhost server to manage all Datasocket connections between applications. One node should be designated as the server to manage Datasocket connections from node to node. The Datasocket server on this designated computer should be configured using the Datasocket server manager. In the Datasocket server manager under Permission Groups the IP addresses, assigned by the router, of each computer should be entered under Default Readers, Default Writers, and Creators. This will give permission to the other nodes to create Datasocket connections and read data from or write data to these connections. The localhost DataSocket is used to pass data from LabView to the encoder. The encoder is written in C and runs in LabWindows. Referring to the flowchart in Figure 3-1, the first two functions of the base station code are to pass the initializing data and the random data to LabWindows. This is done by simply opening a Datasocket connection on the local host between the two applications. The Datasocket transfer protocol (dstp) uses a standard URL assignment. For example the URL for a localhost connection

PAGE 33

22 between two applications is dstp://localhost/connection_name. This is easily done with LabView using virtual instruments (VIs) (Figure 3-2). Figure 3-2. Connecting to LabWindows on the loacalhost and sending the initializing data As mentioned earlier, DataSocket is also used to pass data from node to node over the wireless network. A Datasocket connection between the base station and mobile nodes is unnecessary for collaborative reception. However, to analyze the performance of each mobile node there is a connection created between the mobile nodes and the base station. The mobile nodes will need a Datasocket connection to exchange data and perform collaborative reception. This will be discussed in the chapter on mobile nodes. Opening a Datasocket connection between computers is similar to opening a Datasocket connection between applications. The difference is the IP address of the node designated as the Datasocket server is used in the URL instead of localhost. For example consider the scenario that node 1 is designated as the Datasocket server and is assigned the IP address 192.168.2.4. In order to pass data from node 3 to the base station the URL would be dstp://192.168.2.4/connection_name. Notice the IP address of node 2 and the base stations IP address is not used in the URL, only the IP address of the Datasocket sever is used. This is the URL assignment for all connections from node to node regardless if they are designated as the server or not. Figure 3-3 shows an example of how data is passed from node 1 to the base station.

PAGE 34

23 Figure 3-3. VIs used to open a Datasocket connection between node1 and the base station and pass the Signal to Noise Ratio measurement to the base station for analysis. Datasocket connections can also be made by setting an indicator, or an array for example, to subscribe to a Datasocket connection. This is done by right-clicking on the indicator and selecting data operations >> Datasocket connection. In the Datasocket connections window the URL of the connection can be entered and the options of publish, subscribe, or publish and subscribe may be selected. By subscribing to a Datasocket connection the indicator will be updated every time the Datasocket is updated. This is very helpful and reduces some of the code that needs to be written in LabView. Overall DataSocket is a very helpful National Instruments application. The collaboration process between nodes is made very simple using DataSocket. The Datasocket connections are very robust and the server will allow up to 10000 connections. Random Data Generator Referring back to the flowchart in Figure 3-1, the next operation after passing the initializing data to the encoder is to pass the actual random data that is to be transmitted to the encoder. The user has the ability to make a transmitted packet any size he or she desires. On the front panel of the Base station VI under number of data bits the user should enter the desired packet size. The packet size is first sent to LabWindows to

PAGE 35

24 initialize the arrays in the encoder code. When the encode button is pressed a packet of random data is generated and stored in the array Random Data (Figure 3-4). Figure 3-4. Random data generator using LabView As shown in the figure the LabViews random number generator is used to build the random data packet. The random number generator produces a uniformly distributed random number between 0 and 1. The random number generator is called by a For-Loop the number of times specified by number of data bits. If the random number is greater than 0.5 a zero is generated and if the random number is less then 0.5 a 1 is generated. These random 1s and 0s make up the data packet to be encoded. The data packet is then passed to the encoder through a Datasocket connection on the localhost. The encoder receives this data and encodes it. The encoder code will be discussed in the following section. Encoder Code National Instruments LabWindows/CVI is an ANSI C development environment that among other features includes NIs DataSocket networking architecture and a Graphical User Interface (GUI). The encoder used in the testbed was written in C, which makes LabWindows a natural choice in implementing the encoder. As mentioned earlier

PAGE 36

25 the C code could have been directly integrated into the LabView code using a Formula Node. However, to make both the decoder and encoder code compatible with the testbed, they needed to be modified. Because of the complexity of both codes and because LabWindows provides a better debugging environment it was decided that using LabWindows and just passing the data using a Datasocket connection was more feasible. Since the code has been modified and all the bugs have been worked out, future operators may decide to just directly embed the code in LabView. The Datasocket connections in LabWindows can be configured to work like an interrupt. Whenever data is written to the Datasocket a function will fire and retrieve the data from the Datasocket. The Datasocket function that retrieves the data will also include the encoder function. The encoder function will generate the encoded data. There are three localhost Datasocket connections involved in passing data back and forth between LabView and LabWindows. One connection will be used to send the initializing data, a second connection is for LabView to send the random data to LabWindows, and a third connection is for LabWindows to send the encoded data back to LabView. The URL for the initializing data is the same as the one mentioned above, dstp://localhost/initialize. It is important for the LabWindows code to be as dynamic as possible. After opening the localhost Datasocket server, the user only needs to open the LabWindows code once. The LabWindows code should dynamically update itself to match the data coming from LabView. In order to operate this way the size of the data to be encoded needs to be sent every time, unless it stays the same. The code will be able to identify any change in the data size and update its arrays accordingly.

PAGE 37

26 The URL of the Datasocket connection for LabView to send the random data to LabWindows is dstp://localhost/encode. As mentioned earlier whenever this Datasocket is updated by LabView the function to read the data will execute automatically. This is done by setting the Datasocket connection to DSConst_ReadAutoUpdate. Upon receiving the data it is saved in an array rdata. The data is displayed in a table on the user interface. Displaying the data in a table is not completely necessary, it was only done to verify the correct data was read from the Datasocket. The array rdata is then passed to the function trellis_enc. This function will take the random data and encode it. It implements a rate trellis encoder. The encoding process doubles the original data and adds 4 bits. For example, if the random data is 1000 bits the encoded data will be 2004 bits. The size of the encoded data and the encoded data itself are put in an array tdata. The array tdata is sent back to LabView using the Datasocket connection dstp://localhost/encoded. Synchronization and the M-sequence The encoded data cannot just be simply passed to the front end for transmission. There are two more important arrays that need to be added to the encoded data before transmission can begin. An array of synchronizing data and a 63 bit m-sequence need to be added to the encoded data. A diagram of the frame structure can be seen in Figure 3-5. The encoded data was discussed in the previous section. This section will explain the synchronizing data and the 63 bit m-sequence and will also explain the importance of transmitting this way. 1010 63 bit m-sequence Encoded Data Figure 3-5. Frame structure of 1 packet

PAGE 38

27 When transmission begins after an idle period the linear output will rise significantly before it settles. The rising and settling effect can be seen in Figure 3-6. The long array of alternating 1s and 0s gives the receiver time to settle. The receiver does not completely settle before the data is sent, but the significant rise is at the beginning of the transmission and this is taken out by the alternating 1s and 0s. Another reason for the long array of alternating 1s and 0s is to ensure that no data was missed. The receiver waits in a while loop for the trigger. The execution of the while loop is dependent on the processing speed of the receiver. If the receivers reaction to the Boolean trigger is slow then the first few data bits can be missed. Adding 1s and 0s to the beginning will ensure that the receiver does not miss any data. The array of alternating 1s and 0s is saved in a text file junk.txt. This file is opened by LabView and added to the beginning of the transmitted array. In order to normalize the received data the exact beginning of the packet must be determined. This is done using a correlating detector. The correlating detector searches for the 63 bit m-sequence. An m-sequence is used because it can be easily distinguished from other sequences and from a time-shifted version of itself. An m-sequence is just a spreading sequence often used in CDMA applications. The reason the m-sequence is easily distinguished from other sequences and from a time shifted version of itself is because it has a good discrete-time periodic crosscorrelation and autocorrelation function [5]. For BPSK, sequences that have these properties can be generated with a binary linear feedback shift register. A barker sequence would serve the same purpose as the m-sequence, however, there are not any barker sequences as long as

PAGE 39

28 the 63 bit m-sequence. A long sequence was required to make a signal-to-noise ratio estimate. The signal-to-noise ratio estimate will be explained in Chapter 4. Linear Output-0.200.20.40.60.811.21.41141728334249566570818497991311329127451416115577169931840919825212412265724073254892690528321samplesvoltage Figure 3-6. Linear output after an idle period. The output rises significantly at the beginning of transmission and then begins to settle. Using the m-sequence will assure that each mobile node can determine the beginning of the data packet. The m-sequence is generated using MatLab and saved in a file m-sequence.txt. The file is opened in LabView and added after the array of alternating 1s and 0s and just before the encoded data. The MatLab file works like a binary linear feedback shift register. The polynomial used is x 6 +x+1 with the initial state = 101010. Since this is a 6 degree polynomial the sequence will be 63 bits long (N = 2 n -1). A copy of the MatLab file is given in appendix B. LabView was used to combine the alternating 1s and 0s and the m-sequence with the encoded data (Figure 3-7).

PAGE 40

29 Figure 3-7. Creating the array to be sent to the front end using LabView Analog Output Now that the data array to be sent to the front end has been assembled, the next step in the flowchart is to transmit this data. This is done in LabView with the Analog Output Waveform VI. When the transmit button is pressed a Boolean true is sent to the receivers to notify that data transmission is about to begin. This is followed by a short pause to allow the receivers to begin acquiring data and ensure that no data is missed. After the pause the Analog Output Waveform is called. This VI requires the device number (Daq number assigned in MAX), the update rate (baud rate), channel number (there are two DACs), and the data to be output. The data is passed to an output buffer. The VI returns control to the LabView diagram only when the generation is complete, that is when the buffer is emptied. After the data is output the same VI is called again to return the output line to 0 volts. This is done so that the receiver will remain or idle in a low state. One triggering technique considered was for the receiver to begin acquiring data when a voltage threshold was passed. This requires the receiver to idle at a known voltage level. For this reason the output line is always returned to 0 volts after every transmission. This technique was not very robust, therefore a Boolean trigger was implemented, but for

PAGE 41

30 uniformity the line was still returned to 0 volts. This will be discussed in Chapter 4. Figure 3-8 shows the Analog Output Waveform VI. Figure 3-8. Controlling the D/A using the AO Wave VI Receiver Statistics The final function of the base station code is to generate the receiver statistics so that results can be verified and conclusions can be formed. The goal of this research is to verify that collaborative reception improves the error correction capabilities of an individual node. To show that this capability is improved three sets of data need to be generated and compared. The three sets are the received data before decoding, the decoded data before exchange, and the decoded data after exchange. To show the transmission errors the received data is compared to the transmitted data. To show the errors corrected without collaboration the decoded data before exchange is compared to the generated data. To show the errors corrected with collaboration the decoded data after exchange is compared to the generated data. The three sets of data along with the signal to noise ratio measurement are generated by the receiving nodes and passed back to the base station. These three comparisons are displayed on the base station front panel. The base station can record these statistics and repeat the transmission over and over again. For example the base station can transmit 1000 packets of data and record statistics of each transmission. The results can be graphed and an average number of

PAGE 42

31 errors received and corrected can be calculated. If the average number of errors corrected with collaboration is greater than the average number of errors corrected without collaboration then the results of the computer simulation and this research will be verified. The code described in this chapter was written to send one packet at a time. To do the final analysis just described, the code has to be slightly modified. This is easily done by adding a For-loop and a user input for the number of transmissions to perform.

PAGE 43

CHAPTER 4 SOFTWARE IMPLIMENTATION OF THE RECEIVING NODE This chapter will explain the code written to implement the receiving node. The sections of this chapter will be broken up into the individual functions of the mobile node presented in order on the flowchart given in Figure 4-1. The individual section titles will be Initialization, Triggering, Analog Input, Correlating Detector, Normalizing the Data, Signal to Noise Ratio Measurement, Decoding Process, Exchange Protocol, and Displaying Results. Initialization The first function of the receiving node is to setup the Datasocket connections. The Datasocket connections will be used to pass data from LabView to LabWindows, pass data between receivers, and pass the results back to the base station. The connections made will be based on the Receiver ID (Rid). For example node 1, Rid = 1, will open the Datasocket connection dstp://192.168.2.4/snr1 to pass the signal to noise ratio measurements back to the base station. Node 2 opens Datasocket connection dstp://192.168.2.4/snr2, and so on. This naming convention is carried throughout the entire testbed. Once the appropriate Datasocket connections have been opened the code will then send the initialization data to the decoder in LabWindows. The initializing data for the decoder includes the Rid, number of receivers, number of exchange data bits, and the number of encoded data bits. With this data the decoder can initialize its variables. 32

PAGE 44

33 Set up data socket connection based on RID Initialize local variables Send Initializin g data to LabWindows Open msequence.txt and set up array mask Wait for Trigger Trigger Read in Samples Find Data Beginning Normalize Data and Calculate Signal to Noise Ratio Pass data and SNR to decoder No. o f nodes Exchange with 4 nodes Exchange with 3 nodes Exchange with 2 nodes No exchange Decode with exchange data Display Results Figure 4-1. Flowchart of the receiver code

PAGE 45

34 The next initialization task is to build the array mask using the m-sequence discussed in Chapter 3. This mask is used to search the buffered data for an exact beginning of the encoded packet. The incoming data is sampled at 10 times the baud rate, that is, each bit will be represented by 10 samples. In order to match the m-sequence exactly the mask has to resemble the sampled data. For each bit in the m-sequence there will be a block of 10 numbers in the array mask, therefore a 63 bit m-sequence creates a 630 bit array mask. For example a binary in the m-sequence will add a block of 10 s to the array mask and a binary in the m-sequence will add a block of 10 -1s to the array mask. The reason a 0 translates to a -1 is because after the DC is removed from the sampled data the binary 0s become negative. Figure 4-2 shows the LabView code for building the array mask. To help clarify this process a table showing part of the m-sequence and the resulting array is given in Table 4-1. Understanding the array mask will be helpful in understanding how the correlating detector works. The correlating detector will be discussed in detail later in this chapter. Figure 4-2. Building the array mask from mesequence.txt

PAGE 46

35 Table 4-1. Resulting array mask from the given m-sequence. M-sequence Array Mask 0 1 1 1 2 1 3 1 4 1 5 1 6 1 7 1 8 1 1 9 1 10 -1 11 -1 12 -1 13 -1 14 -1 15 -1 16 -1 17 -1 18 -1 0 19 -1 Triggering There were two triggering techniques considered when designing the testbed. The first technique used LabViews analog hardware trigger and the other technique was to trigger from a Boolean logic true sent by the base station through a Datasocket connection. In practice the Boolean technique would not be an option because this requires the base station and the receiving nodes to be on an existing network, which would defeat the purpose of improving communications between them. Using LabViews analog hardware trigger is more realistic, however it is not robust and it is not suitable for practical use. In practice the receiving node constantly samples and searches the incoming data for the m-sequence. Because of processing limitations of the laptop and LabView this technique could not be implemented. To implement this technique a hardware processing unit, such as an FPGA or ASIC, would be required.

PAGE 47

36 LabViews Analog Input VI can be configured for an analog hardware trigger. The Analog Input Start VI has the options for a digital trigger, an analog trigger, or scan clock gating. When configured as an analog hardware trigger with a rising edge the AI Start VI will begin acquiring analog input when a rising edge exceeds a specified threshold. The idea was to idle the receiver low and when data started the threshold would be passed and the Daq would begin buffering samples. This would work in an ideal situation were the linear output of the receiver always idled at the same voltage level and there was no other applications near by using this frequency that could produce a false trigger, however, this is not the case. The linear output of the receiver is an indicator of the signal strength. At different ranges this voltage level changes dramatically. In some instances the analog input would not trigger if the signal strength is too low. Further more, the presence of a 915 MHz signal will cause the linear output of the receiver to rise based on the strength of that signal. This would lead to false triggers because the 915 MHz ISM band is used in many applications. Other devices on this frequency could cause the receiving nodes to begin acquiring data even though transmission had not begun. For these reasons this technique was abandoned. In the future, testbed users may choose to implement an FPGA circuit that would continuously sample and check for the m-sequence and then provide a trigger to the processor to begin sampling and buffering the linear output of the receiver. The solution to this issue was to cheat the triggering process. Because the base station and receiving nodes are on the same wireless network, for statistical analysis, a Datasocket connection for triggering could be created. The transmit button on the base station is configured to publish its Boolean value to a Datasocket connection. The

PAGE 48

37 receiving nodes will continuously loop until the transmit button is pressed. When the transmit button is true the receiving nodes will begin sampling and buffering the linear output of the receiver. Although this is not a realistic solution, triggering is not the focus of this research. Using this technique will not invalidate the experimental results. This triggering technique is very robust eliminating the concern of false triggers and assuring that the active receivers will begin buffering data when they should. Analog Input Upon receiving the Boolean trigger, the mobile node will acquire an entire buffer of data and then remove the DC from the samples. The reason for removing the DC is to make the samples resemble BPSK outputs. The buffering is done using the AI Config, AI Start, AI Read, and AI Clear VIs. The DC is removed by using a simple for loop. Figure 4-3 shows the VI arrangement in LabView for configuring the AI, acquiring data, clearing the AI buffer, and removing the DC voltage from the sampled data. The AI Config VI configures the AI buffer, the DAQ device number, and the analog input channel number. The buffer size is determined by the number of encoded data bits to be received. The user must input this value on the front panel. To assure the synchronizing data, m-sequence, and all encoded data is received and buffered, 5000 extra bits are sampled in addition to user input number of encoded data bits. The incoming data is sampled at 10 times the rate so this number is then multiplied by 10, the resulting equation for determining the buffer size is: AI Buffer size = (number of encoded data bits + 5000) 10 The DAQ device number is assigned in MAX and should be verified every time before using the testbed. There are 16 analog input channels to choose from. The operator may choose any one of the analog input channels. The DAQ device and channel

PAGE 49

38 number are both inputs on the front panel. The operator should set them accordingly. All other inputs to the AI Config VI are left as their default values. The AI Start VI is used to begin sampling the channel specified in the AI Config VI. The configuration settings input to the AI Config VI are passed to the AI Start VI through the task ID. The AI Start VI requires the scan rate to be set by the operator. Figure 4-3. Buffering the sampled linear output of the receiver into a 1D array and removing the DC When the operator enters the baud rate on the front panel this number is multiplied by 10 which sets the scan rate to 10 times the baud rate. The operator should be certain that the baud rate setting on the base station is the same for every receiving node. The input number of scans to acquire is the total number of scans LabView acquires before the acquisition completes. A scan is one point per channel. When the default input is -1, LabView acquires exactly one buffer of data, this default is left unchanged. As mentioned in the triggering section the inputs for triggering are not set because the Boolean trigger is used. All other inputs to the AI Start VI are left as there default settings. The AI Read VI does not require any user inputs. All of the configurations from AI Config and AI Start are passed through the task ID. When the buffer is full AI Read outputs the samples into a scaled array. The scaled data is a 2D array that contains analog input data in scaled data units. The data appears in columns, where each column

PAGE 50

39 contains the data for a single channel. Since there is only one channel used there is only one column of data but it is still a 2D array. This 2D array has to first be converted into a 1D array before being processed. The AI Clear VI simply clears the input buffer. The AI buffer is cleared every time to assure there is no old data in the buffer. This VI does not require any user inputs, only the task ID is needed to clear the appropriate buffer. The next step is to remove the DC voltage from the sampled data. The decoder program requires BPSK inputs. Removing the DC will give negative values for 0s and positive values for 1s. Multiplying all of these values by -1 will result in a BPSK output -1s for 1s and 1s for 0s. As mentioned in Chapters 2 and 3, the receiver will ramp up when data transmission begins after an idle period. The addition of a DC blocking capacitor helped to dampen this ramping effect but did not completely prevent it from occurring. As described in Chapter 2, one can remove the DC by finding a local average and subtracting it from the corresponding samples. The code used to subtract the local average from the samples is also given in Figure 4-3. The receiving node starts buffering samples just before the data transmission begins. Samples are brought into a for-loop 400 at a time. An average is calculated and then subtracted from the 400 samples. This is repeated for the entire buffer. This process will remove the DC from each sample even in the presence of the ramping effect. Correlating Detector Now that the channel has been sampled and saved in a 1D array, the exact beginning of the transmitted packet must be determined. This is done using a correlating detector. The correlating detector is implemented using a For-loop. The operation can be

PAGE 51

40 visualized as sliding a window along the received data and finding the best match. The window that is being compared to the received data is the array mask created from the m-sequence. The array mask is multiplied by the first 630 samples in the received data array and the output array is summed. This sum is the weight of the first position and it is stored in another array that holds all of the weights. The received data array is shifted by one sample and is again multiplied by the array mask and summed. This sum is inserted into the array holding the weights as the next element and represents the weight of the second position. The received data array is shifted again by one sample and the process continues until a weight is calculated for the first 10000 samples or positions. The position with the highest weight represents the beginning of the m-sequence. Since the m-sequence is of known length, 63 bits, and the sample rate is 10 times per bit, the exact beginning of the data packet is 630 samples from the position with the highest weight (Figure 4-4). In order for the data to be decoded each bit must be represented by a single value, this is referred to normalizing the data. The normalizing process is described in the next section. Normalizing the Data The correlating detector finds the exact beginning of the data. The next step is to represent each data bit with one voltage level. Each bit is sampled 10 times. By averaging these samples a single voltage value can be calculated for each bit. It was observed that a binary 1 did not have the same pulse width as a binary 0. The pulse width for the binary 1 was more narrow than the binary 0 and therefore, did not have 10 samples that represented the entire bit. Because of this more narrow pulse width and because the index of each bit may be off a few samples, only the middle 4 samples are averaged (Figure 4-5).

PAGE 52

41 This average is used as the voltage level representation for each bit. This is easily done in LabView using a For-loop. Blocks of 10 samples are input into the For-loop. The middle 4 samples are taken out of the block of 10 samples and averaged. The average is stored in an array. The next 10 samples are brought into the For-loop and again only the middle 4 samples are averaged to determine the voltage level of the bit. The average is again inserted into the array. This process is repeated for the entire length of the received data packet (Figure 4-6). Figure 4-4. Correlating detector The resulting normalized array is the received data before decoding. The normalized data is used to build an array of 1s and 0s. If the voltage level is greater than 0 it is saved as a 1, if the voltage level is less than 0 it is saved as a 0. This array of 1s and 0s is sent back to the base station using a Datasocket to compare the transmitted array and determine if there were any transmission errors. The generated array is then multiplied by -1 to obtain the BPSK outputs discussed earlier. The BPSK outputs are stored in an array that will be sent to the decoder. Signal to Noise Ratio Measurement The code written to implement the signal to noise ratio measurement is similar to the code written to normalize the data. The m-sequence is a known pattern and is

PAGE 53

42 therefore used to determine the signal noise ratio. The 630 samples that best matched the m-sequence are multiplied by the array mask. If a good match is found then this multiplication will result in all positive voltages. This is demonstrated in Figure 4-7. The line received m-sequence represents the received data that most resembled the m-sequence, the line array mask is the data being compared to the received data, and the line array mask m-sequence is the resulting multiplication of the two. The average and variance of array mask m-sequence is used to calculate the signal to noise ratio. Again, because of the more narrow pulse width for binary s and because the index of each data bit may be off a few samples, only the middle 4 samples are used in this calculation. The importance of using the middle four samples is shown in Figure 4-7. The narrow pulse width of the 1s result in some negative values after multiplying the array mask times the received m-sequence. As in the normalization process, a For-loop is used to extract the middle 4 samples. The middle 4 samples of each bit are saved in an array. The following equations are used to determine the average, variance, and signal to noise ratio. AVG = sum of the samples / number of samples VAR = Average[(sample AVG) 2 ] SNR = AVG 2 / VAR The LabView code written to determine the signal to noise ratio is given in Figure 4-8. The array to be used in the calculations is multiplied by 10. This was done because the values can be relatively small and LabView will round them off. Multiplying by 10

PAGE 54

43 does not affect the signal to noise ratio measurement because it is a ratio. The factor of 10 is only used to give a more accurate measurement. Figure 4-5. Linear output with the DC removed showing how an average voltage per bit is calculated using four middle samples. Notice if all 10 samples were used the average would be distorted. Figure 4-6. Normalizing the data and sending the received 1s and 0s back to the Base station.

PAGE 55

44 A B Figure 4-7. Signal to Noise Ratio Estimate A) Part of the received m-sequence and corresponding part of array mask. B) The m-sequence multiplied by the array mask.

PAGE 56

45 Figure 4-8. Calculating the estimated signal to noise ratio Decoding Process The decoder, written in C, executes in LabWindows. To work properly the code needs to know if it is the first or second iteration, the signal to noise ratio, the received data, the index of the exchange data from the other receivers, and the actual exchange data from the other receivers. This information is passed to LabWindows through a Datasocket connection in an array. The arrangement of the data within the array is the same in which it was listed. The code was written as general as possible. The decoder variables are initialized at the beginning of the code. The code will know exactly how many received data bits and exchange data to expect. During the first iteration, the nodes first attempt at decoding the data with no help, the exchange data will be initialized to all zeros. Like the encoder, when LabView writes the data to the Datasocket the code will fire, like an interrupt, and begin reading the data from the Datasocket into the array rdata. The variable init, SNR, the rssi array, index array, and exdata array, are pulled out of the array rdata in that order. Again, on the first iteration the arrays index and exdata are set to all zeros. After the variables have been set, the decoder function is called. The decoder returns the exchange information (the index array and the exdata array) and the decoded bits (Rxb). The index array, exdata array and the Rxb array are combined in the array

PAGE 57

46 tdata. In order for LabView to know that the data sent back is valid the variable init is inserted at the top of the array tdata. The tdata array is passed back to LabView using the Datasocket connection dstp://localhost/analyed. LabView will loop until the first value in the array matches the variable init. On the first iteration the variable init is set to 1 and on the second iteration init is set to 0. During the first iteration LabView will wait until it receives a 1 back from the decoder. On the second iteration LabView will wait until it receives a 0 back from the decoder. On the first iteration, after LabView has verified that the data is valid, the node will then pass its exchange information to the other nodes. This process is explained in the next section. Exchange Protocol Now that each node has made an attempt to decode the data independently and generated some exchange information, the collaboration process will follow. Each node receives its exchange data from the decoder in LabWindows. Once this data is received each node will write its exchange data to a Datasocket connection. The other active nodes subscribe to this Datasocket connection to obtain the exchange data from that node. By subscribing to the Datasocket connection the subscribing array will automatically update whenever data is written to that connection. Each node may process the data at slightly different times, therefore a protocol is needed to determine when the data in the subscribing array is valid. Each individual node will have an rts (request to send) Boolean value that will be set true when the initial decoding process is complete. After publishing the Boolean true, the node will wait for rtss from the other receiving nodes. The individual node knows

PAGE 58

47 how many nodes are on the network and the node knows its Rid, therefore it can determine which and how many nodes to wait for (Figure 4-9). Figure 4-9. The exchange protocol. In this example node1 (Rid =1) knows there are 4 receivers, therefore it waits for rts2, rts3, and rts4. After the exchange process is complete a second decoding iteration is performed with the exchange data from the active nodes. The decoder is called the same way as before during the first iteration. Instead of having all zeros, as in the first iteration, the exchange data will be replaced by the values provided by the other nodes. The decoded data after the second iteration is saved in an array decoded data after exchange. Displaying Results The second iteration should improve the correction capabilities of the node. This is the goal of the research. To show the transmission errors the received data is compared to the transmitted data. To show the errors corrected without collaboration the decoded data before exchange is compared to the generated data. To show the errors corrected with collaboration the decoded data after exchange is compared to the generated data. These comparisons are done by the base station as described in Chapter 3. However,

PAGE 59

48 each node will show the received data and the decoded data before and after the exchange. The receiver will also show how many bits were corrected by the second iteration, if any, and their index. Each node displays its statistics to provide more information to the operator and to verify that the base station is receiving the correct data from each node.

PAGE 60

CHAPTER 5 ENCODER AND DECODER This chapter will explain the encoder and decoder used in the testbed. The encoder is a simple convolutional encoder with a rate k/n = and constraint length K = 3. The decoder is basically a maximum a posteriori (MAP) decoder. To better understand the decoding algorithm a background on the Viterbi convolutional decoding algorithm and soft decision decoding will be discussed before the MAP decoder is explained. The three sections of this chapter will be the convolutional encoder, the Viterbi convolutional decoding algorithm and soft decision decoding, and finally the MAP decoder. Encoder As mentioned the encoder is a rate convolutional encoder with constraint length K=3 (Figure 5-1). The rate is determined by k/n where n is the encoded bits and k is the message bits, that is, k/n message bits per encoded bit, where k
PAGE 61

50 At each input bit time, a bit is shifted into the leftmost stage or the register and the bits in the register are shifted one position to the right. The two symbol branches are the result of an exclusive OR between the values in the register denoted by the connecting arrows. The output switch then samples the output of each code symbol, first from the upper then from the lower. The final output is the code symbol pair making up the branch word associated with the bit that is just input into the encoder. This process is repeated for each bit in the input sequence. The connections from the register to the exclusive OR determine the characteristics of the encoder output. Different connections will yield different codes. These connections are not randomly chosen. The process of choosing connections that yield good distance properties is complicated and has not been solved in general. Good codes have been found by computer search for all constraint lengths less than about 20. The connections used in the testbed are the ones shown in Figure 5-1. At the end of the input bit stream the shift register must be cleared. Clearing the shift register requires a series of 0s to be appended to the end of the bit stream. This will add to the encoded message which causes the effective code rate to fall below k/n. As mentioned earlier, the convolutional encoder used in the base station has a constraint length K=3. The clearing process will add 4 bits to the end of the encoded data. The actual output will be determined by the equation N = (2 k) + 4 where N is the size of the encoded data and k is the size of the message bits to be encoded. The encoder used in the base station is just the simple convolutional encoder as described above. The decoder is a bit more complicated. In order to understand the

PAGE 62

51 MAP decoder, it is important to understand the Viterbi convolutional decoding algorithm. The next section will explain the Viterbi convolutional decoding algorithm and soft decision decoding. Viterbi Convolutional Decoding Algorithm This section will discuss soft decision decoding and the Viterbi convolutional decoding algorithm. The decoder used in the testbed is actually a MAP decoder, but it is important to first understand the Viterbi algorithm. A tree diagram can be used to map out the encoder transitions as a function of time. Observation of the tree diagram will reveal that the tree repeats itself after K branchings, where K is the constraint length. In the case of the testbed, the encoder has a constraint length of K=3, therefore the tree will repeat itself after three branchings. Because of this repetitive structure, the tree diagram can be significantly simplified thereby making a more manageable decoder description. This reduced tree diagram is referred to as a trellis diagram (Figure 5-2). The trellis diagram is a fixed periodic structure. The entire structure is realized after a depth K is reached. At this point and thereafter, each of the states can be entered from either of two preceding states and can transition to one of two states. With this knowledge a decoder can find the path through the trellis diagram that has the maximum likelihood of being the received bit sequence. The Viterbi decoding algorithm works by calculating a measure of similarity, or distance, between the received signal, at time t i and all the trellis paths entering each state at time t i The Viterbi algorithm removes from consideration those trellis paths that could not possibly be candidates for the maximum likelihood choice. When two paths enter the same state, the one having the best metric is chosen; this path is called the

PAGE 63

52 surviving path. This selection continues in this way to advance deeper into the trellis, making decisions by eliminating the least likely paths. Figure 5-2. Trellis diagram for a rate K=3 encoder As stated above, the path with the best metric is chosen. The metric is determined by the Hamming distance between the received code symbols and each of the branch words for that time interval. For example referring to the trellis diagram in Figure 5-2, if the decoder is in sate 00 the two possible transitions are 00 to 00 and 00 to 10. In order to go from 00 to 00 the received code symbol has to be 00. In order to go from 00 to 10 the received code symbol has to be 11. Because of the encoder structure, these are the only two possible transitions. The received code word is compared to these two possible transitions and the difference or metric is calculated. If 11 was the received code symbol, then the metric for 00 to 00 is 2 and the metric for 00 to 01 is 0. Notice that this technique is a hard decision technique because it requires the receiver or demodulator to tell the decoder that the received code symbol is 11. A metric is calculated for each

PAGE 64

53 transition. When any two paths in the trellis merge to a single state, the metrics of both paths are summed and the one with the maximum sum is eliminated. Finding the path with the minimum metric is the same technique used for both hard and soft decision decoding. A soft decision decoder is very similar to the hard decision decoder except that the soft decision decoder uses the soft output of the receiver and hard decision decoder uses the hard decision output of the receiver. In the hard decision case, the receiver output for a binary signal is either a 1 or a 0. This hard decision is fed into the decoder and the resulting decoding process is called hard decision decoding. In the soft decision case, the receiver output is more than two levels. For example, eight levels of quantization requires 3 bits to describe a single binary symbol. In effect, sending such a 3-bit word in place of a single binary symbol is equivalent to sending the decoder a measure of confidence along with the code-symbol decision. If the receiver sends the decoder 111, this is tantamount to declaring the code symbol to be a one with very high confidence. If the receiver sends the decoder 100, this is tantamount to declaring the code symbol to be a one with very low confidence [6]. For the soft-decision decoder, the quantized output of the receiver is used to calculate the metrics of each transition. The decoder still eliminates the path with the higher metric, however the metric is more accurate because it uses more information to make this calculation. In the testbed the linear output of the receiver is used to perform soft decision decoding. The linear output varies with the signal strength. The voltage level of the linear output is used as a confidence measure in the symbol decision. A higher voltage means higher signal strength which translates into a higher confidence in the decision.

PAGE 65

54 The confidence in each bit, given by the linear output, along with the estimated signal to noise ratio can be used to determine the reliability of each received binary symbol. This reliability is used to determine the exchange data to be shared with the other nodes in the ad hoc network. A decoder that uses a priori probability information that is independent of its own decisions is called a MAP decoder. The MAP decoder is used in the testbed to decode the data using the exchange data from other nodes. This decoder will be discussed in the next section. The MAP Decoder The MAP decoder is a maximum a posteriori decoder. The algorithm uses the same technique as the Viterbi algorithm except it employs a priori probability information about each bit, while the Viterbi algorithm implements Maximum Likelihood (ML) decoding. In ML decoding the decoder chooses the symbol sequence whose likelihood, given the channel observation is greater than the likelihood of all other possible symbol sequences. This can be stated as maximizing P(y/x j ), where y is the channel observation and x j is the j possible symbol sequences. The MAP decoder has information about the a priori probability of each bit and can therefore be written as maximizing P(y/ x n )P(x n ), where y is the channel symbol observation and x n is the n possible symbol decisions. This priori probability information allows the MAP decoder to outperform the ML decoder. Note that a fundamental difference between the ML decoder and the MAP decoder is that the ML decoder works to maximize the likelihood of the whole observed sequence while the MAP decoder maximizes the a posteriori probability of a bit. During the first attempt at decoding the data, none of the nodes have any priori probability information. As mentioned earlier the exchange data from the other nodes on

PAGE 66

55 the first decoding attempt is all 0s. A zero translates into a probability of 0.5 for each P(x n ),therefore the capabilities of the MAP decoder during the first attempt is equivalent to that of the ML decoder. After the first decoding attempt, the a posteriori information of each bit is generated by each node by observing the whole packet. After the a posteriori probabilities are determined the code ranks them in a descending order. A percentage of the most reliable bits is chosen as the exchange data. The percentage taken out is set by the operator. Again, the testbed was designed to allow the operator to vary the amount of exchange data. The data is exchanged and then the existing receivers on the ad hoc network each have new a priori probability information that will allow them to perform the MAP decoding algorithm again. The exchange technique described is called the MRB or most reliable bits scheme. This technique works well with more than 8 receivers. Another technique referred to as the LRB or least reliable bits scheme may also be used. LRB differs from MRB in that it determines which bits have the lowest a posteriori probability and request that information from the other nodes. After the request is performed then the node can perform MAP decoding with the new a priori probability information that it requested from the other nodes. A disadvantage to the LRB technique is that it requires more exchanges than the MRB technique. However, when there are only a few receivers in the ad hoc network, the LRB technique performs better than the MRB technique. The testbed is designed using the MRB technique. Future operators may choose to integrate the LRB technique into the testbed.

PAGE 67

CHAPTER 6 TESTING After the testbed was completely configured and the code debugged, tests were performed to hopefully verify that collaborative reception would improve the receive capabilities of each individual node. The verification was done by calculating the bit error rate (BER) for various signal-to-noise ratios (SNR). This chapter will discuss the testing procedure, the problems encountered during testing, solutions to these problems, and the final results. As described earlier the base station code is implemented in a for-loop. The for-loop allows the base station to continually transmit a number of packets. For each packet sent the base station would record the statistics from each node in the network. The statistics collected included the SNR, the errors received (hard decision errors), the decoder errors without collaboration, and the decoder errors with collaboration. The scenario that this research seeks to improve is one in which all receiving nodes in the ad hoc network consistently make independent decoding errors. The hope is that this scenario would require the collaboration process to eliminate these errors. The bulk of the testing was done indoors where the SNR fluctuated significantly. This made it difficult to find a perfect spot in which all three nodes would consistently make errors. There were some locations, however, that for the most would provide the desired environment to show the capabilities of the collaborative reception techniques. There were three receiving nodes, each placed on a cart. The carts were moved to the spots in the engineering building, outside of the wireless communications lab, that 56

PAGE 68

57 would provide the desired environment. The base station or transmitter was left in the lab on a desk. A diagram of the cart orientation in the New Engineering Building on the 4 th floor is given in Figure 6-1. New Engineering Building 4 th Floor North En d Location of Transmitter Lab Lab 50 Offices Class Room Offices Receivin g nodes Womens Mens 70 Figure 6-1. Cart Locations in the New Engineering Building on the 4 th floor. All interior walls are sheet rock with steel studs. The carts were approximately 86 apart. As discussed in chapter 5 the collaborative technique used was MRB. This technique is good when there are more than 8 receivers. In order to make the MRB technique show reasonable results with three receivers more data needed to be exchanged. For the test the data size was 1000 bits and the exchange data was set to 500 bits or half of the data. Both of these numbers can be varied by the operator, but for testing purposes they were fixed. This is a high number of bits to exchange. Future operators may choose to either build more stations or implement the LRB technique so that a more practical amount of bits can be exchanged.

PAGE 69

58 Initially the transmitter and receiver were placed on a breadboard and connected to the DAQ. This did not allow the use of an antenna because the antenna connector was either BNC or SMA which could not be plugged into a breadboard. After running tests with the transmitter and receivers connected this way, it was observed that the receivers were very unstable. The SNR would fluctuate significantly. It seemed that the communications link was disturbed quite easily by traffic in the room or hallways. Furthermore, the breadboard may not have provided a sufficient ground for the receiver and transmitter. The solution to this issue was to design and mill a printed circuit board (PCB). A simple board was laid out in Protel and milled on double sided copper. The bottom layer of the PCB was used as a ground plain for both the transmitter and the receiver. An SMA connector was soldered onto the PCB to allow an antenna to be connected. The PCB made the transmitter and receivers much more consistent and less easily disturbed by passers by. The PCB layout can be seen in Appendix C. Each cart had the capability to be completely battery operated, however, the battery-life of the laptops were only a couple of hours and one of the laptops would only stay on for about half an hour. This made testing somewhat difficult because it took some time to gather enough statistics to perform an accurate analysis. The only solution was to plug carts into the wall which required the carts to be placed next to an outlet. Making the mobile nodes completely battery operated is possible, but would require each laptop to have an extra battery. The battery life of the DAQ was sufficient. As mentioned earlier the statistics collected from each receiving node after each packet transmission were the SNR, the hard decision errors, the decoder errors before

PAGE 70

59 exchange, and the decoder errors after the exchange. Over 600 packets were transmitted with 1000 random data bits and 500 exchange bits. This allowed for over 2000 data points to be collected and averaged for each type of error. The statistics collected after each packet are tabularized by the base station. A portion of the collected statistics is given in table 6-1. Each row corresponds to a packet. Table 6-1. Sample of the statistics collected by the base station. Node1 Node2 Node3 SNR Hard Dec Errs Errs no Exch Errs with Exch SNR Hard Dec Errs Errs no Exch Errs with Exch SNR Hard Dec Errs Errs no Exch Errs with Exch 13.564 0 0 0 8.918 0 0 0 6.488 0 0 0 11.01 0 0 0 10.259 0 0 0 6.992 0 0 0 10.243 0 0 0 10.604 0 0 0 4.908 0 0 0 5.018 200 25 0 12.445 3 0 0 6.808 0 0 0 -2.182 978 369 56 8.748 6 0 0 7.521 0 0 0 -3.641 871 298 67 0.492 73 0 0 7.707 4 0 0 The statistics were placed in bins according to their SNR and the BER for each bin was calculated. A separate LabView VI was written to place the collected data into their respective bins and calculate the BER. This VI is given in Figure 6-2. The VI will read in the file with the SNRs and the number of errors for each packet. For each SNR, from -9 dB to 35 dB with a bin size of 1 dB, the corresponding bit errors are put into their respective bin. These bins are then added up and divided by the number of bits sent. For example if the collected data from two consecutive packets is 5.6 dB with 2 errors and 5.8 dB with 3 errors. Both of theses bit errors would be placed in the bin 6 dB and the bit error rate would be 5/2000 = 0.0025. The sum of the bit errors is divided by 2000 because there are two packets that are 1000 bits long.

PAGE 71

60 Figure 6-2. VI used to bin the receiver statistics so that a BER vs SNR graph could be generated. The output of this data is saved to a spreadsheet file designated by the user. This VI must be executed on each set of data (i.e., on the hard decision, decoded data without exchange, and decoded data with exchange). This process will create three files. Each file can then be concatenated to produce the final table to be graphed. The final table can be seen in Table 6-2. The data in Table 6-2 was graphed using a scatter plot. The scatter plot is given in Figure 6-3. Each point represents the BER for each bin. The data from each bin comes from the receive statistics generated by each individual node. The graph does not necessarily reflect the performance of the other nodes during each transmission. This is because the SNR is not necessarily the same for each node during the same packet transmission. For example node 1 could receive packet 1 with a SNR of 1 dB and at the same time node 2 receives packet 1 with a SNR of 10 dB. Of course in this scenario if node 1 makes some errors, and at 1 dB SNR it probably will, then node 2 could

PAGE 72

61 potentially correct a number of node 1s errors. This is not particularly the scenario these schemes aim to improve, however, this scenario is very relevant to real life situations so it is therefore not discarded. Again this is not reflected in the SNR vs BER graph. The graph clearly shows that collaborative reception improves receiver performance. The performance is significantly better at extremely low SNRs. For reasons of comparison the results of the computer simulation for 3 receivers, 1000 data bits, 500 exchange data bits, MRB, and AWGN channel is given in Figure 6-4. The simulation results also included a second exchange which was not implemented in the testbed and can therefore be neglected. The overall performance of the computer simulation was much better than the testbed. This was to be expected because theoretical results are difficult to achieve, however, collaborative reception did shown an improvement in the BER. Other packet sizes and exchange data sizes could have been plotted and compared, but this was not the scope of the research. The goal was to prove that collaborative reception could improve the receive capabilities of each individual node in an ad hoc network. This was done as shown above in the BER vs SNR graph. Comparing different collaborative methods, packet sizes, data rates, exchange bits, etc would be the next step for operators that choose to continue this research. The future uses along with weak points, strong points, and obstacles overcome during the design will be discussed in the final chapter, Conclusions.

PAGE 73

62 0.000010.00010.0010.010.11-9-8-7-6-5-4-3-2-1012345678910111213141516SNR (dB)BER Single receiver 3 receivers 1 exchange Figure 6-3. BER vs SNR graph of the data given in table 6-2. Collaborative reception with 3 receivers outperforms a single receiver. Figure 6-4. BER vs SNR graph of the computer simulation.

PAGE 74

63 Table 6-2. Final results for 3 receivers, 1000 bits per packet, and 500 exchange bits. BER SNR (dB) Hard Decision Single Receiver 1 Exchange -8 0.52794412 0.503 0.253 -7 0.49301396 0.48566668 0.11666667 -6 0.31836328 0.2895 0.0465 -5 0.40186296 0.32433334 0.056333335 -4 0 0 0 -3 0.31786428 0.24933334 0.037333333 -2 0 0 0 -1 0.30713572 0.2335 0.05075 0 0.25434844 0.19342858 0.050714285 1 0.30439122 0.214 0.0425 2 0.1 0.082 0.0184 3 0.11338434 0.10022222 0.015555555 4 0.11958226 0.10042857 0.013714286 5 0 0 0 6 0.10882996 0.09209524 0.016285714 7 0.031257485 0.026 0.00408 8 0.033221435 0.024030303 0.006454546 9 0.037662175 0.029875 0.005625 10 0.018463074 0.01825 0.002666667 11 0.010774504 0.010868421 0.001131579 12 0.008505461 0.007101124 0.001595506 13 0.007101796 0.006624 0.002032 14 0.002112891 0.001684685 0.00209009 15 0.00011705 8.64198E-05 0 16 0 0 0

PAGE 75

CHAPTER 7 CONCLUSION This chapter discusses the weak points of the testbed, strong points of the testbed, the future uses of the testbed, and the overall conclusions. Most of the weak points have been discussed throughout the paper. These weak points are not failures of the design. When starting this research it was anticipated that going from a theoretical design to a real life system would create some design issues that would be otherwise unknown. In some cases, simple solutions are proposed and could have been implemented if there were more time. Future operators should review these weak points and try to remedy them for future operation. As discussed earlier the triggering mechanism is a weak point in the testbed. The triggering implementation takes advantage of the fact that the base station and receiving nodes are on the same network. A Boolean logic true is passed to all the stations just before packet transmission begins. This is a weak point because this approach could not be used in practical situations. As discussed earlier if the receiving nodes are on an existing network with the basestation then there is no need to improve a second communications link. Future operators may choose to use hardware, such as an ASIC or FPGA to constantly scan the output of the receiver and generate the trigger. It was observed that the SNR varies significantly. Switching from a breadboard circuit to a PCB circuit helped to stabilize this measurement but the SNR estimate would still fluctuate. This could potentially skew the data because a slow data rate was used. The data rate used was 4000 bits per second. At this rate the packet, that is over 3000 64

PAGE 76

65 bits, takes over half a second to completely transmit. In this time frame the SNR can vary and will not accurately reflect the SNR for the entire packet. The data rate of 4000 bps was much lower than the maximum rate for the transmitter and receiver which is 200 Kbps. It was observed that when data rates approached around 10K the linear output became distorted. More than likely this is a receiver design issue. The hard decision output of the receiver at these higher rates was not nearly as distorted, however, the decoder required the soft outputs and therefore a lower rate was used. Future operators may choose to investigate techniques to overcome the distorting linear output so that the data rates can be increased. One such technique may be to use an equalizer to combat the distorting effect. The packet utilization is very inefficient. The receivers will rise and then settle upon receiving data after an idle period. To combat the rising effect a long stream of alternating 1s and 0s are sent before the m-sequence and the actual encoded data. The length of the alternating 1s and 0s is about the same as the length of the m-sequence and encoded data (i.e., the alternating 1s and 0s double the packet size). Sending twice the necessary data is very inefficient. The only solution to this would be to replace the transmitter and receiver pair with a pair that does not have the rising effect. The Datasockets have some issues. Each nodes Datasocket connections must contain the Datasocket servers IP address. When the wireless router is unplugged and moved to a different location the router will reassign an IP address to all of the nodes. This often occurs because the router must be unplugged and moved whenever the testing location changes, when going from indoors to outdoors for example. If the node that acted as the Datasocket server is reassigned a different IP address, then the operator has

PAGE 77

66 two choices. The operator can either reconfigure the Labview code on each node with the new Datasocket server IP address or the operator can setup the node that has been given the old Datasocket server IP address as the new Datasocket server. An attempt was made to allow the operator to enter the Datasocket server IP address on each node one time and the entire system would be reconfigured. This attempt was unsuccessful because the arrays that were setup to automatically update could not be configured to change based on a user input. It was thought that by using a property node this problem would be overcome, but this was not the case. Future operators may choose to setup each node, using the Datasocket server manager, to include every IP address in the ad hoc network. This might cause IP conflicts but it would eliminate the server dependency. There was not enough time to test this idea. Another issue with the Datasocket connections is that they would often crash. Both the localhost and the node to node Datasocket connections would randomly stop working. The reason behind this was never discovered. It was first thought that the wireless connection would become unstable and cause the Datasocket to crash, but when it was observed that the localhost connections would also crash this idea was ruled out. Future operators may consult National Instruments about this issue. As mentioned earlier the collaboration technique used was most reliable bits (MRB). This technique required that each node rank the reliability of each bit and share the best based on the number of exchange data requested by the operator. This technique is efficient when there are over 8 receivers in the ad hoc network. The testbed is comprised of 3 receivers. The least reliable bits (LRB) technique would have been better. To implement this technique would require some significant changes in the code and

PAGE 78

67 because of time constraints was not implemented. Future operators may choose to implement this technique to see if the same or better results can be obtained with fewer exchange data. With only 3 receivers, the MRB technique would also cause the receivers to change correct bits to incorrect bits and hence yield worse results! This is also possible with LRB but the chances would be reduced. The battery life of the laptops was only a couple of hours which is not sufficient for a long amount of testing. In order for each node to be completely mobile extra batteries must be added to each cart. Another solution might be to place a car battery with a DC to AC inverter on each cart. This would allow each laptop and DAQ to be plugged in all the time. The car batteries could then be recharged after each testing period. A final weak point of the testbed worth mentioning is the typical Windows operating system issues. All of the software runs on a Windows platform, which has the tendency to crash after running long tests. This can cause loss of data and can be very frustrating. Windows may even be the cause of the Datasocket crashes. Future operators may choose a MAC or Linux based software platform which may increase the robustness of the entire testbed. Despite the weak points listed above the testbed was a success! The tests verified that collaborative reception can improve the receive capabilities of a single receiver in an ad hoc network in a real life system. The computer simulations were verified by showing that the bit error rate can be reduced with collaboration. This translates into a lower transmit power or increased range. Receivers that would normally make errors by themselves can reduce or eliminate those errors with collaboration. The testbed was designed in a way that will allow future operators to manipulate packet size, baud rate,

PAGE 79

68 number of receivers, and the number of exchange data bits. The testbed will be very helpful to researches than plan on continuing the work in the future. This research focused on collaborative reception, the next step for the testbed is to implement collaborative transmission techniques. In order to do this a board with both a transmitter and receiver needs to be designed or a different frontend that has both receive and transmit capabilities must be substituted. Future operators should address the weak points discussed in this chapter. For some of the weak points solutions were suggested. These suggested solutions may be enough to fix these problems making the overall testbed more robust and user friendly. After the testbed has robust transmission and reception capabilities a natural next step would be the design of higher layer protocols. The current testbed design dealt with the physical layer only, the transmission of one packet. Future operators may want to design a protocol that will allow multiple packets to be transmitted with a form of error check. Again the overall goals of this research were met. The testbed demonstrated that the collaborative reception techniques could improve communications for a real life system. Transforming the theoretical ideas into a real life system made clear the practical considerations that would otherwise be unclear. Dealing with triggering, power consumption, SNR estimates, PCB layout, etc were all issues that were not considered in theoretical design. There are solutions to these issues and correcting them will ultimately prove the practicality of the collaborative reception techniques.

PAGE 80

69 For future operators a troubleshooting guide is given in Appendix D. The troubleshooting guide should be referenced by users in case the testbed is not working properly.

PAGE 81

APPENDIX A LABVIEW CODE Appendix A includes the LabView frontpanel for both the receiver and the transmitter. The frontpanel is what is seen by the operator. The frontpanel is just a GUI that is supported by LabView code called a diagram. The diagram for each frontpanel is not included in the appendix. Figure A-1. Receiver Front Panel 70

PAGE 82

71 Figure A-2. Base station Front Panel

PAGE 83

APPENDIX B LABWINDOWS CODE Appendix B contains the LabWindows code. The four files included are the receiver code, the basestation code, mdpc_core.c, and cc.h. All the code is written in ANSI C. Receiver Code // ---------------------------------------------------------------------// This code launches a data socket connection on the local host upon start up // the initial connection is for Labview to send the parameters (receiver ID, data size) so //that the variables and the array lengths can be initialized. The code then waits for //labview to send the received data. Upon receiving the data the code will decode and //determine the exchange data along with the hard decisions and then send this data back //to Labview. Code will work with 1 to 4 receiving stations // --------------------------------------------------------------------#include #include #include /* Needed if linking in external compiler; harmless otherwise */ #include #include #include #include "ANALYZE5.h" #include "dataskt.h" #include "cc.h" #include "mdpc_core.c" //#include "decoder.c" #define Max_K 100000 static int panelHandle; static DSHandle dsHandle; static DSHandle dsHandle_2; static DSHandle dsHandle_T; static int singleX = 0; static int no_of_params = 4; 72

PAGE 84

73 static int rdata_size, tdata_size, Rid; static int params[4] = {0,0}; //this holds the initial parameters Rid and data_size int old_Rid = 0; int initial_open = 1; int M; // # of receivers int K; // size of exdata int N; // size of encoded data int Nb; // size of orginal bit stream double *rdata; double *tdata; double appu[Max_K]; int rec[Max_K]; double old_rdata_size = 0; st_table *state_tbl; /* This is the callback function for the DataSocket */ void DSCallback (DSHandle dsHandle, int event, void *pUserData); void DSCallback_2 (DSHandle dsHandle_2, int event, void *pUserData); /* user interface loop */ int main (int argc, char *argv[]) { int i; if (InitCVIRTE (0, argv, 0) == 0) /* Needed if linking in external compiler; harmless otherwise */ return -1; /* out of memory */ if ((panelHandle = LoadPanel (0, "ANALYZE4.uir", PANEL)) < 0) return -1; state_tbl = read_st_tbl("c:\\conv1.st",30); DisplayPanel (panelHandle); DS_Open ("dstp://localhost/initialize", DSConst_ReadAutoUpdate, DSCallback, NULL, &dsHandle); // DS_Open ("dstp://localhost/valid", DSConst_WriteAutoUpdate, NULL, NULL, &dsHandle_V); RunUserInterface (); return 0; } int MRB2(int N,int nx,double *si,int *ind,int *rec) {

PAGE 85

74 int i,*index,*pt1,z; double *abssi,*pt2,*pt3; pt1 = index = (int *) malloc(N*sizeof(int)); pt2 = abssi = (double *) malloc(N*sizeof(double)); pt3 = si; for(i=0;i=0; i--) { z += 1-rec[index[i]]; if (rec[index[i]] != 1) { //*(pt2 ++) = (*(si + index[i])); //*(ind ++) = index[i]; ind[index[i]] = 1; } } free(index); free(abssi); return z; } void decode(st_table *state_tbl,int Rx_ID,int Rx,int K,int N,int Ne,double Ec_N0,double *rxs, double *appu,int **exindex,double **exchng,int *Rxb,int *rec) { int i,m,rx; int *index,*rxb; double *exc,*exu,*sou; Rx_ID--; exu = (double *) calloc(K+state_tbl->m,sizeof(double)); sou = (double *) calloc(K+state_tbl->m,sizeof(double)); exc = (double *) calloc(N,sizeof(double)); index = (int *) calloc(K,sizeof(int)); scalellr(N,Ec_N0,rxs,0); for (rx=0;rx
PAGE 86

75 { if (rx != Rx_ID) { for (m=0;m
PAGE 87

76 /* When the Quit button is pressed, call Close and Quit */ int CVICALLBACK QuitBtn (int panel, int control, int event, void *callbackData, int eventData1, int eventData2) { switch (event) { case EVENT_COMMIT: if (dsHandle) { DS_DiscardObjHandle(dsHandle); dsHandle = 0; } if (dsHandle_2) { DS_DiscardObjHandle(dsHandle_2); dsHandle_2 = 0; DS_DiscardObjHandle(dsHandle_T); dsHandle_T = 0; } singleX = 0; QuitUserInterface (0); break; } return 0; } /* This is the callback that fires whenever the initializing data or status is updated */ void CVICALLBACK DSCallback (DSHandle dsHandle, int event, void *pUserData) { HRESULT hr = S_OK; double singleFloat; char message[1000]; char *URL; unsigned int sz; unsigned type; switch (event) { case DS_EVENT_DATAUPDATED: hr = DS_GetDataType (dsHandle, &type, NULL, NULL); if (type & CAVT_ARRAY) { hr = DS_GetDataValue (dsHandle, CAVT_INT|CAVT_ARRAY, params, no_of_params*sizeof(double), &sz, NULL);

PAGE 88

77 Rid = (int)params[0]; //Rid must be defined before the IF statement so that the appropriate URL can be assigned M = (int)params[1]; K = (int)params[2]; N = (int)params[3]; Nb = N/2 state_tbl->m; rdata_size = 2+N+2*K*M; tdata_size = Nb+K*2+1; if (rdata_size != old_rdata_size) { if (initial_open == 0){ DeleteTableRows (panelHandle, PANEL_TABLE, 1, old_rdata_size); DeleteTableColumns (panelHandle, PANEL_TABLE, 1, 1); }else { //If Rid changes and it is the initial run just open the connection DS_Open ("dstp://localhost/analyze", DSConst_ReadAutoUpdate, DSCallback_2, NULL, &dsHandle_2); DS_Open ("dstp://localhost/analyzed", DSConst_WriteAutoUpdate, NULL, NULL, &dsHandle_T); initial_open = 0; } }else { //If Rid did not change then just delete the tables. This is not necessary when you get rid of the tables. DeleteTableRows (panelHandle, PANEL_TABLE, 1, old_rdata_size); DeleteTableColumns (panelHandle, PANEL_TABLE, 1, 1); } old_rdata_size = rdata_size; old_Rid = Rid; rdata = (double *) calloc(rdata_size,sizeof(double)); tdata = (double *) calloc(tdata_size,sizeof(double)); //Create the rows and columns that are necessary. 2 rows and 2 columns of string type cells.

PAGE 89

78 InsertTableRows (panelHandle, PANEL_TABLE, 1, rdata_size, VAL_CELL_NUMERIC); InsertTableColumns (panelHandle, PANEL_TABLE, 1, 1, VAL_CELL_NUMERIC); } else { hr = DS_GetDataValue (dsHandle, CAVT_DOUBLE, &singleFloat, sizeof(double), NULL, NULL); if (singleX >= no_of_params) singleX = 0; params[singleX] = singleFloat; singleX++; sz = singleX; } return; break; case DS_EVENT_STATUSUPDATED: hr = DS_GetLastMessage (dsHandle, message, 1000); if (SUCCEEDED(hr)) SetCtrlVal (panelHandle, PANEL_STATUS, message); break; } return; } /* This is the callback that fires whenever rdata or the status of the rdata connection is updated */ void CVICALLBACK DSCallback_2 (DSHandle dsHandle_2, int event, void *pUserData) { HRESULT hr = S_OK; double singleFloat; char message[1000]; unsigned int sz; unsigned type; int i,j,init; double valid=1; double SNR; double *rssi; int **index; double **exdata; int *Rxb;

PAGE 90

79 int *txb, Err; switch (event) { case DS_EVENT_DATAUPDATED: hr = DS_GetDataType (dsHandle_2, &type, NULL, NULL); if (type & CAVT_ARRAY) { hr = DS_GetDataValue (dsHandle_2, CAVT_DOUBLE|CAVT_ARRAY, rdata, rdata_size*sizeof(double), &sz, NULL); //Insert the array of strings into the table. SetTableCellRangeVals (panelHandle, PANEL_TABLE, MakeRect (1, 1, rdata_size, 1), rdata, //this was just to show the transmited data in the table. VAL_ROW_MAJOR); Rxb = (int *) calloc(Nb,sizeof(int)); txb = (int *) calloc(Nb,sizeof(int)); rssi = (double *) calloc(N,sizeof(double)); index = (int **) calloc(M,sizeof(int)); exdata = (double **) calloc(M,sizeof(double)); for (i=0;i
PAGE 91

80 } } /* for (i=0;i= rdata_size) singleX = 0;

PAGE 92

81 rdata[singleX] = singleFloat; singleX++; sz = singleX; } return; break; case DS_EVENT_STATUSUPDATED: hr = DS_GetLastMessage (dsHandle_2, message, 1000); if (SUCCEEDED(hr)) SetCtrlVal (panelHandle, PANEL_STATUS_2, message); break; } return; } /* Call DS_DiscardObjHandle when the Disconnect button is pressed */ int CVICALLBACK OnDisconnect (int panel, int control, int event, void *callbackData, int eventData1, int eventData2) { switch (event) { case EVENT_COMMIT: SetCtrlVal (panelHandle, PANEL_STATUS, "Unconnected."); SetCtrlVal (panelHandle, PANEL_STATUS_2, "Unconnected."); if (dsHandle) { DS_DiscardObjHandle(dsHandle); dsHandle = 0; } if (dsHandle_2) { DS_DiscardObjHandle(dsHandle_2); dsHandle_2 = 0; DS_DiscardObjHandle(dsHandle_T); dsHandle_T = 0; } singleX = 0; break; } return 0; } /* when the panel is closed, close the connection and exit */ int CVICALLBACK PanelCallback (int panel, int event, void *callbackData, int eventData1, int eventData2)

PAGE 93

82 { switch (event) { case EVENT_CLOSE: if (dsHandle) { DS_DiscardObjHandle(dsHandle); dsHandle = 0; } if (dsHandle_2) { DS_DiscardObjHandle(dsHandle_2); dsHandle_2 = 0; DS_DiscardObjHandle(dsHandle_T); dsHandle_T = 0; } singleX = 0; QuitUserInterface (0); break; } return 0; } Basestation Code // This code launches a data socket connection on the local host upon start up the initial //connection is for Labview to send the parameters number of bits to encode so that the //variables and the array lengths can be initialized. The code then waits for labview to //send the random data packet. Upon receiving the data the code will encode the data //and send the data back to Labview. #include #include #include /* Needed if linking in external compiler; harmless otherwise */ #include #include #include "ecoder.h" #include "dataskt.h" #include "cc.h" int N; // sizeof of encoded bits int *txc; //encoded bits array pointer static int panelHandle; static DSHandle dsHandle; static DSHandle dsHandle_2; static DSHandle dsHandle_T; //static DSHandle dsHandle_V;

PAGE 94

83 static int singleX = 0; static int no_of_params = 1; static int data_size; //size of information bits static int params[1]; //this holds the initial parameters Rid and data_size int old_data_size = 0; int initial_open = 1; double *rdata; double *tdata; st_table *state_tbl; /* This is the callback function for the DataSocket */ void DSCallback (DSHandle dsHandle, int event, void *pUserData); void DSCallback_2 (DSHandle dsHandle_2, int event, void *pUserData); /* user interface loop */ int main (int argc, char *argv[]) { if (InitCVIRTE (0, argv, 0) == 0) /* Needed if linking in external compiler; harmless otherwise */ return -1; /* out of memory */ if ((panelHandle = LoadPanel (0, "ANALYZE3.uir", PANEL)) < 0) return -1; state_tbl = read_st_tbl("c:\\conv1.st",30); DisplayPanel (panelHandle); DS_Open ("dstp://localhost/initialize", DSConst_ReadAutoUpdate, DSCallback, NULL, &dsHandle); // DS_Open ("dstp://localhost/valid", DSConst_WriteAutoUpdate, NULL, NULL, &dsHandle_V); RunUserInterface (); return 0; } /* When the Quit button is pressed, call Close and Quit */ int CVICALLBACK QuitBtn (int panel, int control, int event, void *callbackData, int eventData1, int eventData2) { switch (event) { case EVENT_COMMIT: if (dsHandle) { DS_DiscardObjHandle(dsHandle); dsHandle = 0;

PAGE 95

84 } if (dsHandle_2) { DS_DiscardObjHandle(dsHandle_2); dsHandle_2 = 0; DS_DiscardObjHandle(dsHandle_T); dsHandle_T = 0; } singleX = 0; QuitUserInterface (0); break; } return 0; } /* This is the callback that fires whenever the initializing data or status is updated */ void CVICALLBACK DSCallback (DSHandle dsHandle, int event, void *pUserData) { HRESULT hr = S_OK; double singleFloat; char message[1000]; char *URL; unsigned int sz; unsigned type; // double valid = 0; switch (event) { case DS_EVENT_DATAUPDATED: hr = DS_GetDataType (dsHandle, &type, NULL, NULL); if (type & CAVT_ARRAY) { hr = DS_GetDataValue (dsHandle, CAVT_INT|CAVT_ARRAY, params, no_of_params*sizeof(double), &sz, NULL); data_size = params[0]; if (data_size != old_data_size) { if (initial_open == 0){ DeleteTableRows (panelHandle, PANEL_TABLE, 1, old_data_size); DeleteTableColumns (panelHandle, PANEL_TABLE, 1, 1);

PAGE 96

85 }else { //If data_size changes and it is the initial run just open the connection DS_Open ("dstp://localhost/encode", DSConst_ReadAutoUpdate, DSCallback_2, NULL, &dsHandle_2); DS_Open ("dstp://localhost/encoded", DSConst_WriteAutoUpdate, NULL, NULL, &dsHandle_T); initial_open = 0; } }else { //If Rid did not change then just delete the //tables. This is not necessary when you get rid of the tables. DeleteTableRows (panelHandle, PANEL_TABLE, 1, data_size); DeleteTableColumns (panelHandle, PANEL_TABLE, 1, 1); } old_data_size = data_size; rdata = (double *) calloc(data_size,sizeof(double)); // DS_SetDataValue (dsHandle_V, CAVT_DOUBLE, &valid, 0, 0); //Create the rows and columns that are necessary. 2 rows and 2 columns of string type cells. InsertTableRows (panelHandle, PANEL_TABLE, 1, data_size, VAL_CELL_NUMERIC); InsertTableColumns (panelHandle, PANEL_TABLE, 1, 1, VAL_CELL_NUMERIC); } else { hr = DS_GetDataValue (dsHandle, CAVT_DOUBLE, &singleFloat, sizeof(double), NULL, NULL); if (singleX >= no_of_params) singleX = 0; params[singleX] = singleFloat; singleX++; sz = singleX; } return; break; case DS_EVENT_STATUSUPDATED:

PAGE 97

86 hr = DS_GetLastMessage (dsHandle, message, 1000); if (SUCCEEDED(hr)) SetCtrlVal (panelHandle, PANEL_STATUS, message); break; } return; } /* This is the callback that fires whenever rdata or the status of the rdata connection is updated */ void CVICALLBACK DSCallback_2 (DSHandle dsHandle_2, int event, void *pUserData) { HRESULT hr = S_OK; double singleFloat; char message[1000]; unsigned int sz; unsigned type; int i; int *txb; // double valid=1; switch (event) { case DS_EVENT_DATAUPDATED: hr = DS_GetDataType (dsHandle_2, &type, NULL, NULL); if (type & CAVT_ARRAY) { hr = DS_GetDataValue (dsHandle_2, CAVT_DOUBLE|CAVT_ARRAY, rdata, data_size*sizeof(double), &sz, NULL); //Insert the array of strings into the table. SetTableCellRangeVals (panelHandle, PANEL_TABLE, MakeRect (1, 1, data_size, 1), rdata, //this was just to show the transmited data in the table. VAL_ROW_MAJOR); txb = (int *) calloc((int)data_size,sizeof(int)); for (i=0;i<(int)data_size;i++) txb[i] = rdata[i]; N = trellis_enc(state_tbl,(int)data_size,txb,&txc); free(txb); tdata = (double *) calloc(N+1,sizeof(double));

PAGE 98

87 tdata[0] = N; for (i=0; i= data_size) singleX = 0; rdata[singleX] = singleFloat; singleX++; sz = singleX; } return; break; case DS_EVENT_STATUSUPDATED: hr = DS_GetLastMessage (dsHandle_2, message, 1000); if (SUCCEEDED(hr)) SetCtrlVal (panelHandle, PANEL_STATUS_2, message); break; } return; } /* Call DS_DiscardObjHandle when the Disconnect button is pressed */ int CVICALLBACK OnDisconnect (int panel, int control, int event, void *callbackData, int eventData1, int eventData2) { switch (event) { case EVENT_COMMIT: SetCtrlVal (panelHandle, PANEL_STATUS, "Unconnected."); SetCtrlVal (panelHandle, PANEL_STATUS_2, "Unconnected."); if (dsHandle) { DS_DiscardObjHandle(dsHandle); dsHandle = 0; }

PAGE 99

88 if (dsHandle_2) { DS_DiscardObjHandle(dsHandle_2); dsHandle_2 = 0; DS_DiscardObjHandle(dsHandle_T); dsHandle_T = 0; } singleX = 0; break; } return 0; } /* when the panel is closed, close the connection and exit */ int CVICALLBACK PanelCallback (int panel, int event, void *callbackData, int eventData1, int eventData2) { switch (event) { case EVENT_CLOSE: if (dsHandle) { DS_DiscardObjHandle(dsHandle); dsHandle = 0; } if (dsHandle_2) { DS_DiscardObjHandle(dsHandle_2); dsHandle_2 = 0; DS_DiscardObjHandle(dsHandle_T); dsHandle_T = 0; } singleX = 0; QuitUserInterface (0); break; } return 0; } Multi-Dimensional Parity Check Code /* Multi-dimensional parity check code 1/23/01 T. Wong group all core routines together */

PAGE 100

89 #define INF 1.0e90 #define Dmax 11 void addexinfo(int N,double *si,double *ex,double *so,int zero,int negative) { int i; double *pt1,*pt2,*pt3; pt1 = si; pt2 = ex; pt3 = so; if (zero) { if (negative) { for (i=0;i
PAGE 101

90 for (i=0;i
PAGE 102

91 if (left >= right) // Do nothing if array contains < 2 elements return; // move partition elem to position 0 swap(permuter,randarray,left,(left+right)/2); last = left; for(i=left+1;i<=right;i++) if(*(randarray+i) < *(randarray+left)) swap(permuter,randarray,++last,i); swap(permuter,randarray,left,last); qsort1(permuter,randarray,left,last-1); qsort1(permuter,randarray,last+1,right); } /*void find_rand_permuter(blocksize,permuter,depermuter) int blocksize; int *permuter,*depermuter; { int i; double *randarray; // First make an array of reals that we will sort to find // the permutation matrices. Fill the permuter array with // the original indices of these reals. randarray = (double *) malloc(blocksize*sizeof(double)); for(i=0;i
PAGE 103

92 The CC.H Header File /* Multi-dimensional parity check code No corner parity as suggested by Hagenauer use tanh (true MAP) decoder T. Wong 1/23/01 */ /*#include #include #include #include #include "random.c" #include "common.c" #include "mdpc_core.c"*/ #define INF 1.0e90 typedef struct { int ni; int nk; int ns; int no; int nd; int np; double *sig; int *next_state; int *sig_tag; int cur_state; int m; int q; } st_table; typedef struct { int from; int input; int competing_input; int competing_from; double path_met; double delta_met; } tb_entry; /*********************************************************************/ /* This routine reads and sets up the trellis state table for both */ /* the Viterbi encoder and the decoder. */

PAGE 104

93 /* Typical usage: st_table *state_tbl; */ /* state_tbl = read_st_tbl("state_file",np); */ /* where np is the truncation path length of the Viterbi decoder */ /* It assumes a parameter files in the following format: */ /*+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++*/ /* */ /* ------------*/ /* ... ns*ni entries */ /* ------------*/ /* ... */ /* ... */ /* ... */ /* ... */ /*+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++*/ /* In above, */ /* n -# of Tx signals (no) = 2^n (same in metric table) */ /* k -# of input bits, ni = 2^k */ /* ns -# of trellis states */ /* nd -signal dimension (should be 2 in MPSK and QAM) */ /* S(t) -state at time t, 0 <= S(t) <= ns-1 */ /* I(t) -input at time t, 0 <= I(t) <= ni-1 */ /* O(t) -Tx (o/p) signal at time t, 0 <= O(t) <= no-1 */ /* ss(i,j) -j-th co-ordinate of the i-th Tx signal */ /*********************************************************************/ st_table *read_st_tbl(char *st_file,int np) { FILE *fs; st_table *spt; double *pt3; register int i,k,*pt1,*pt2; int l,n,cs,in,ns,out,m,q; spt = (st_table *) malloc(sizeof(st_table)); fs = fopen(st_file,"r"); fscanf(fs,"%d %d %d %d",&n,&(spt->nk),&(spt->ns),&(spt->nd)); spt->ni = 1 << spt->nk; spt->no = 1<ns spt->ni; n = spt->nd spt->no; spt->sig = pt3 = (double *) malloc(n*sizeof(double)); spt->sig_tag = pt1 = (int *) malloc(l*sizeof(int)); spt->next_state = pt2 = (int *) malloc(l*sizeof(int)); for (i=0;i
PAGE 105

94 fscanf(fs,"%d %d %d %o",&cs,&in,&ns,&out); k = spt->ni cs + in; *(pt2+k) = ns; *(pt1+k) = out; } for (i=0;icur_state = 0; spt->np = np; /* Calculate the # of trellis_enc memery, m (ns=2^m)*/ m = 0; while (!(((spt->ns) >> m) & 0x01)) m++; spt->m = m; /* Calculate the # of output bits for each input bit, m (no=2^q)*/ q = 0; while (!(((spt->no) >> q) & 0x01)) q++; spt->q = q; fclose(fs); return(spt); } /*********************************************************************/ /* This routine performs TCM or convolutional code encoding. */ /* Typical usage: long int m; */ /* m = trellis_enc(state_tbl,n,in,&sig); */ /* where */ /* state_tbl : state table set up by the function "read_st_tbl()" */ /* in : ptr to an array storing the input bit sequence */ /* n : length of the array pointed to by in */ /* sig : ptr to an array of integers which are the symbol #s of the */ /* coded symbol sequence */ /* m : length of the array pointed to by sig */ /*********************************************************************/ long int trellis_enc(st_table *state_tbl,long int n,int *in,INT **sig) { register int input,*pt1,*pt2,j,nk,m,q; long int nsig,i; m = state_tbl->m; q = state_tbl->q; nk = state_tbl->nk; pt1 = (int *) malloc((n+m*nk)*sizeof(int));

PAGE 106

95 for (j=0;jcur_state state_tbl->ni; state_tbl->cur_state = *(state_tbl->next_state + input); for (j=0;jsig_tag + input) >> j) & 0x01; } free(pt1); return(nsig); } /* Find the LLR metric for each branch */ double LLRmetric(double *coded_bit,double *ch,int q) { double met=0; int i; for (i=0;i
PAGE 107

96 void MAX_log_MAP_old(st_table *state_tbl, int n, double *pc, double *pu, double *exc, double *exu) { tb_entry *alpha,*beta,*pt1,*pt2,*pt5; int i,j,k,ni,no,ns,nk,*crts,*nxts,*inb,*outb,*index,m,q; double *b_met,pmet,*met; int tmp1; m = state_tbl->m; q = state_tbl->q; n=n/q; nk = state_tbl->nk; ns = state_tbl->ns; ni = state_tbl->ni; no = state_tbl->no; alpha = (tb_entry *) calloc((n+1)*ns,sizeof(tb_entry)); beta = (tb_entry *) calloc((n+1)*ns,sizeof(tb_entry)); b_met = (double *) malloc(n*ni*ns*sizeof(double)); crts = (int *)malloc(ns*ni*sizeof(int)); nxts = (int *)malloc(ns*ni*sizeof(int)); inb = (int *)malloc(ns*ni*sizeof(int)); outb = (int *)malloc(2*ns*ni*sizeof(int)); met = (double *) malloc(ni*ns*sizeof(double)); index = (int *) malloc(ni*ns*sizeof(int)); for(i=0;inext_state + i*ni+j); inb[i*ni+j] = 1-2*j; tmp1 = *(state_tbl->sig_tag + i*ni+j); for(k=0;k>(1-k))&1); } } for(k=0;k<(n+1)*ns;k++) { (alpha+k)->path_met = -INF; (beta+k)->path_met = -INF; } alpha->path_met = 0; (beta+n*ns)->path_met = 0;

PAGE 108

97 for(k=0;kpath_met + b_met[k*ni*ns+i]; if (pmet > (pt2+nxts[i])->path_met) (pt2+nxts[i])->path_met = pmet; } pt1 += ns; } pt1 = beta + n*ns; for(k=n-1;k>=0;k--) { pt2 = pt1 ns; for(i=0;ipath_met + b_met[k*ni*ns+i]; if (pmet > (pt2+crts[i])->path_met) (pt2+crts[i])->path_met = pmet; } pt1 -= ns; } for(k=0;kpath_met + b_met[k*ni*ns+i] + (pt2+nxts[i])->path_met; } for(i=0;i
PAGE 109

98 { if(met[j]
PAGE 110

99 { int i,j,k,m,kc,nc,ni,ns; double **bm,*met,pmet,**alpha,**beta; int *u,*v,*crts,*nxts,*index,tmp1; /*---------------------------------------------------------*/ m = state_tbl->m; kc = state_tbl->nk; nc = state_tbl->q; ns = state_tbl->ns; ni = state_tbl->ni; N = N/nc; /*---------------------------------------------------------*/ alpha = (double **) calloc(ns,sizeof(double)); beta = (double **) calloc(ns,sizeof(double)); bm = (double **) calloc(ns*ni,sizeof(double)); for (i=0;inext_state + i*ni+j); u[i*ni+j] = 1-2*j; tmp1 = *(state_tbl->sig_tag + i*ni+j); for(k=0;k>(1-k))&1); } } /*---------------------------------------------------------*/ for(k=0;k
PAGE 111

100 for (i=0;i alpha[nxts[i]][k+1]) alpha[nxts[i]][k+1] = pmet; } } for(k=N-1;k>=0;k--) { for(i=0;i beta[crts[i]][k]) beta[crts[i]][k] = pmet; } } for(k=0;k
PAGE 112

101 } for(i=0;i
PAGE 113

102 free(index); free(met); free(u); free(v); free(nxts); free(crts); }

PAGE 114

APPENDIX C PCB LAYOUT FOR THE RECEIVER AND TRANSMITTER This appendix will include the PCB layouts, done in Protel DXP for the transmitter and receiver. Figure C-1. Top layer for the receiver. 103

PAGE 115

104 Figure C-2. Bottom layer for the receiver. Figure C-3. Top layer for the transmitter

PAGE 116

105 Figure C-4. Bottom Layer for the transmitter.

PAGE 117

APPENDIX D TROUBLESHOOTING GUIDE 1) Make sure DAQ is recognized and configured properly in MAX. The configuration settings should be: Analog Input => Refrenced Single Ended Analog Output => Unipolar Accessories => SCB-68 2) Check IP address on each node. Make sure each node is connected to the wireless router and that the Datasocket server includes the IP address for each node. 3) Check baud rate on each node. Make sure it is the same for all nodes. 4) Check each Rid. Make sure each node has a unique Rid. 5) Make sure each node is set up for the same number of exchange data bits. 6) Check the number of data bits on the basestation, make sure it corresponds with the number of encoded data bits that each receiver expects to receive. Use the equation N = 2*Nb + 4, where N is the number of encoded data bits and Nb is the number of random data bits generated by the basestation. 106

PAGE 118

LIST OF REFERENCES 1. Laipac Technology Incorporation, TLP/RLP916 RF ASK OOK High Speed Hybrid Modules for Radio Control and Telemetry and Applications, http://www.laipac.com/Downloads/Easy/TLPRLP916.pdf Accessed: February 10, 2004. 2. National Instruments, DAQPad 6070E User Manual Multifunction I/O Device for 1394 Bus Computers, Part Number 322205B-01, April 2002. 3. Dell Inc. Introduction: Dell TrueMobile 1184 Wireless Broadband Router User's Guide, http://docs.us.dell.com/docs/network/r48972/en/intro/index.htm Accessed: February 28, 2004. 4. National Instruments, Data Socket Overview, NI Developer Zone, http://zone.ni.com/devzone/conceptd.nsf/webmain/14F3B2BC11811DC186256A9D0068B2D1?opendocument Accessed February 28, 2004. 5. D.V. Sarwate and M.B. Pursley, Crosscorrelation properties of pseudorandom and related sequences, Proc. IEEE, vol. 68, no. 5, pp. 593 619, May 1980. 6. Bernard Sklar, Digital Communications Fundamentals and Applications, second edition, 2001 Prentice Hall PTR, Upper Saddle River, New Jersey 07458, pp. 382 422. 107

PAGE 119

BIOGRAPHICAL SKETCH Brian Scott Kennedy was born in Tampa Florida, to Bruce and Pam Kennedy, on April 29, 1979. Scott attended King High School in Tampa, where he graduated 10 th in his class out 495, was a member of the National Honors Society, played varsity baseball and football, and was the football team captain his senior year. Scott went on to Jacksonville University, where he received a Bachelor of Science degree in physics, graduated Magnum Cum Laude, was a member of the football team, and was football team captain his last two seasons. Scott then transferred to the University of Florida, where he continued his undergraduate education, received a Bachelor of Science degree in electrical engineering, and graduated with honors. Scott is currently pursuing a Master of Science degree in electrical engineering, with a specialization in communications. 108


Permanent Link: http://ufdc.ufl.edu/UFE0004832/00001

Material Information

Title: Reconfigurable Multi-Node Wireless Communication Testbed
Physical Description: Mixed Material
Copyright Date: 2008

Record Information

Source Institution: University of Florida
Holding Location: University of Florida
Rights Management: All rights reserved by the source institution and holding location.
System ID: UFE0004832:00001

Permanent Link: http://ufdc.ufl.edu/UFE0004832/00001

Material Information

Title: Reconfigurable Multi-Node Wireless Communication Testbed
Physical Description: Mixed Material
Copyright Date: 2008

Record Information

Source Institution: University of Florida
Holding Location: University of Florida
Rights Management: All rights reserved by the source institution and holding location.
System ID: UFE0004832:00001


This item has the following downloads:


Full Text













RECONFIGURABLE MULTI-NODE WIRELESS COMMUNICATION TESTBED


By

B. SCOTT KENNEDY















A THESIS PRESENTED TO THE GRADUATE SCHOOL
OF THE UNIVERSITY OF FLORIDA IN PARTIAL FULFILLMENT
OF THE REQUIREMENTS FOR THE DEGREE OF
MASTER OF SCIENCE

UNIVERSITY OF FLORIDA


2004
































Copyright 2004

by

B. Scott Kennedy


































This thesis is dedicated to my Mom, Dad, and Steven; for pushing and encouraging me.















ACKNOWLEDGMENTS

I would first like to thank Dr. Tan F. Wong for giving me this opportunity and for

his guidance during the entire process. Without his continued support, this thesis would

not have been a reality.

When I was looking for a research topic, I went to Dr. Fang, who referred me to Dr.

Wong. I would like to thank Dr. Fang for recognizing my desire to do research, and for

being on my committee. I would also like to send my sincere thanks to Dr. Shea for

being on my committee, and for his continued support. Special thanks go to Li Xin for

helping me with the code, and all those long hours of debugging.

Finally, I would like to thank my family. I have dedicated this thesis to them, for

all of their love and support.





















TABLE OF CONTENTS


page


ACKNOWLEDGMENT S .............. .................... iv


LI ST OF T ABLE S ................. ................. vii........ ....


LIST OF FIGURES ................. ..............viii...............


AB S TRAC T ......_ ................. ............_........x


CHAPTER


1 INTRODUCTION ................. ...............1.......... ......


2 HARDWARE .............. ...............6.....


The RF Front End .............. ...............7.....

Antenna Design ................. ..........__ ...............11...
Data Acquisition (DAQ) Pad 6070E .............. ...............13....

Laptop .............. .. ........_ ............... 17....
Wireless Broadband Router ............. ...... ._ ...............18....


3 SOFTWARE IMPLEMENTATION OF THE BASESTATION ............... .... ...........19


LabView Overview............... ...............19
DataSocket .................. ...............19.................
Random Data Generator ................. ...............23................
Encoder Code................ .... ...............2

Synchronization and the M-sequence ................. ...............26................
Analog Output .............. ...............29....
Receiver Statistics............... ...............3


4 SOFTWARE IMPLEMENTATION OF THE RECEIVING NODE ........................32


Initialization............... .............3

Triggering .............. ...............35....
Analog Input ................. ...............37.......... .....
Correlating Detector .............. ...............39....
Normalizing the Data............... ...............40.

Signal to Noise Ratio Measurement ................ ...............41........... ...












Decoding Process............... ...............45
Exchange Protocol .............. ...............46....

Displaying Results ................. ...............47.................


5 ENCODER AND DECODER ................. ...............49................


Encoder ............... ... ......... .... .......... .............4

Viterbi Convolutional Decoding Algorithm ................. ...............................51
The MAP Decoder ................. ...............54........... ....


6 TES ETI G ................. ...............56................


7 CONCLU SION................ ..............6


APPENDIX


A LABVIEW CODE ................. ...............70........... ....


B LABWINDOWS CODE............... ...............72..


Receiver Code............... ...............72..
Basestation Code .................. .... ...... ............8
Multi-Dimensional Parity Check Code .............. ...............88....
The CC.H Header File ................ ...............92........... ...


C PCB LAYOUT FOR THE RECEIVER AND TRANSMITTER. ................... .........103


D TROUBLESHOOTING GUIDE ................. ...............106................


LIST OF REFERENCES ................. ...............107................


BIOGRAPHICAL SKETCH ................. ...............108......... ......


















LIST OF TABLES

Table pg

4-1. Resulting array mask from the given m-sequence. ............. .....................3

6-1. Sample of the statistics collected by the base station. ................ ..................5

6-2. Final results. ............ ..............63......



















LIST OF FIGURES


Figure pg

1-1. Reachback Communications scenario investigated. .....__.___ ........_._ ...............1

1-2. Collaborative Reception. ............. ...............3.....

1-3. Basic structure of a single node ................. ...............4...._...._..

2-1. Testbed node arrangement ................. ...............6...............

2-2. Laipac receiver, RLP916-A ............._ ....._.. ...............8....

2-3. Laipac transmitter, TLP916-A ............. ...... ._ ...............9..

2-4. Antenna design and dimensions ............ .....___ ...............14.

3-1. Flowchart of the base station code .........._._ ...._.._ .. ...............20


3 -2. Connecting to LabWindows ................. ...............22.._.... ...

3-3. VIs used to open a Datasocket connection ...._.._.._ ..... .._._. ... .._.._.........2

3-4. Random data generator using LabView .............. ...............24....

3-5. Frame structure of 1 packet .............. ...............26....

3-6. Linear output after an idle period. ............. ...............28.....

3-7. Creating the array to be sent to the front end using LabView................. ...............2

3-8. Controlling the D/A using the AO Wave VI ...._.._.._ ..... .._._. ......._.. ....3

4-2. Building the array mask from mesequence.txt ................. .............................34

4-3. Buffering the sampled linear output of the receiver ................. ........................3 8

4-4. Correlating detector ................. ...............41.......... .....

4-5. Linear output with the DC removed. .............. ...............43....

4-6. Normal izing the data .............. ...............43....




V111












4-7. Signal to Noise Ratio Estimate ................. ...............44...............

4-8. Calculating the estimated signal to noise ratio ................ ...............45.............


4-9. The exchange protocol............... ...............47

5-1. Convolutional encoder (rate '/, K=3)............... ...............49..


5-2. Trellis diagram for a rate '/, K=3 encoder .............. ...............52....

6-1. Cart Locations in the New Engineering Building .............. ...............57....

6-2. VI used to bin the receiver statistics ...._._._.. ..... ... .___ ...............60.


6-3. BER vs SNR graph of the data given in table 6-2. ......____ .......__ ..............62


6-4. BER vs SNR graph of the computer simulation. ......____ ..... .. ...............62

A-1. Receiver Front Panel............... ...............70.


A-2. Base station Front Panel .............. ...............71....


C-1. Top layer for the receiver ................. ...............103.............


C-2. Bottom layer for the receiver. .............. ...............104....

C-3. Top layer for the transmitter .............. ...............104............ ...


C-4. Bottom Layer for the transmitter. ............. ...............105....















Abstract of Thesis Presented to the Graduate School
of the University of Florida in Partial Fulfillment of the
Requirements for the Degree of Master of Science

RECONFIGURABLE MULTI-NODE WIRELESS COMMUNICATION TESTBED

By

B. Scott Kennedy

May 2004

Chair: Tan F. Wong
Major Department: Electrical and Computer Engineering

In a wireless network, multiple communications devices in close proximity form a

natural distributed antenna array. If a group of such devices receive in some

collaborative manner to exploit the inherent spatial diversity, then the system

performance can be significantly improved. Computer simulations were performed to

test this hypothesis. Simulation results confirmed that collaborative reception can be

used to improve system performance.

Designing a testbed to demonstrate collaborative reception in real-life is an

imperative next step. By conducting experiments on network protocols and

communications techniques over real-life wireless communication channels, the

conclusions obtained from the computer simulation can be verified; and all

considerations in making the theoretical design a practical, real-life communication

system can be made clear.

The goals of this research were to design a reconfigurable multi-node wireless

communication testbed; to implement collaborative reception techniques into the testbed;









to show the usefulness of the testbed by gaining a better understanding of the

collaborative techniques and how these techniques may be optimized; and to verify that

collaborative reception can improve the receive capabilities of a real-life wireless

network. The design of the testbed must be as general as possible, to allow experimental

evaluation of different communication techniques and higher layer protocols.















CHAPTER 1
INTTRODUCTION

Reachback communications is a military term for a mobile node or ground troop

communicating with or "reaching back" to a command station. Reachback

communications can also refer to the scenario of multiple nodes or a group of infantry

men, for example, communicating back to a single base station. The group of mobile

nodes form an ad hoc network. The base station will either transmit a broadcast message

to the ad hoc network or receive individual messages from each mobile node within the

ad hoc network (Figure 1-1).









Figue 1-. Rechbak Comuniatios scnari invstigted












Fimproed 1.reachback communications is cnsantly inreasting.New









Micro-Electro-Mechanical Systems or MEMS technology will allow thousands of

sensors to be deployed in various applications. These "Sensor Networks" will need some

sort of reachback communications to receive instructions, and to report their collected

data. As described earlier, very often the military will require groups of infantry to be

sent out on special operations. These special operation troops will need to be able to

transmit and receive voice, data, and full-motion video images in real time, without the

adversary being able to detect the emission or reception of tactical operation signatures.

Presently and in the future, a premium will be placed on higher bandwidth, increased

range, and low probability of interception and detection, for these types of networks. Our

study focuses on making these improvements to the reception capabilities of a mobile

station in an ad hoc network, using a real-life communication testbed.

Receive diversity is a communications technique that can be used to improve the

receive capabilities of a mobile node in an ad hoc network and was the focus of our

study. Using antenna arrays to obtain receive diversity is an unattractive choice in some

systems. This is because, to obtain receive diversity, the array length should be several

times the wavelength of the RF carrier, and the array elements should be physically

connected to a central combiner. Small handsets carried by infantry, for example, cannot

support this size requirement.

In a wireless ad hoc network, multiple communication devices in close proximity

form a natural distributed antenna array. If a group of such devices receive in some

collaborative manner, to exploit the inherent spatial diversity, then the system

performance of a single receiver can be significantly improved (Figure 1-2).




















Figre1-. olabraiv Rcetin.A)Eac ndeinivdull dcoesth rceve
mesae ndgneats elabliymesue sotoupus)o dtabis


B)Th nds xcageth elabltyinoraio t mpov ecdig


Comutr imlaios er prfrmd o estths ypthsi. eslt sowd ha












Diuesinn a-2 tete odeosrtollaborative reception A a nd in reid all lifde e is anve

imeatv extstgep Bycnducrtinga exeriait ments on neotwr pouptols o dandbi

commnicaion techniques ovaner rel-ie wrelesslit cnommuiation channroels theoi

cocluin bandfo computer simulations eepromdt cant bei vyterified andalls consideratin





in aktiong the theorhetdicaldesign a raciticnal, real-life comncationsyse a emd







clear.

The testbed under development consists of six reconfigurable transceiver nodes that

operate in the 900 MHz ISM band. Each transceiver node is made up of a radio frequency









(RF) front end, a software-processing (SP) baseband unit containing a data acquisition

(DAQ) unit and a notebook computer (Figure 1-3). Each node or computer has an 802.11

wireless network card. The ad hoc network is controlled by a wireless broadband router,

which allows high-speed data transfer among individual nodes.






ISlhl-Band1C
RF Fronitenid



Figure 1-3. Basic structure of a single node

The programs used to write the code are National Instruments' Labview and

Labwindows/CVI (National Instruments, Austin, TX). Labview was used to control the

DAQ, acquire and normalize the data, verify triggers, pass data to LabWindows, and be

the user interface to the node. LabWindows was used to integrate the decoder and

encoder (written in C) into the Labview code. Users in the future may fully integrate the

decoder and encoder directly into the Labview code, and eliminate the need for

LabWindows altogether, to be discussed later.

Our goals were to design a reconfigurable multi-node wireless communication

testbed, to implement collaborative reception techniques into the testbed, to show the

usefulness of the tested by gaining a better understanding of the collaborative techniques

and how these techniques may be optimized, and to verify that collaborative reception

can improve the receive capabilities of a real-life wireless network.

To make the design successful, all electrical and physical specifications must be

considered. Also, a significant amount of code must be developed, to make the testbed










truly reconfigurable (adjustable packet size, data rate, modulation, collaboration

techniques, etc.). Our study only addressed the physical layer considerations of receiving

one packet, no network protocol was designed.

The next chapters describe the design of the testbed and the implementation of

collaboration techniques. It is important to note that the collaboration techniques used in

this study can be modified or completely replaced. Collaboration techniques described in

the next chapters are used to better understand the testbed design, and to show how the

testbed can give practical feedback about different decoding processes and collaborative

techniques.














CHAPTER 2
HARDWARE

The testbed is made up of individual nodes. Each node comprises an RF front end,

an antenna, a data-acquisition unit, and a laptop computer. As stated earlier, the

hardware configuration is the same for both the mobile receiving nodes and the

transmitting base station. Figure 2-1 shows the testbed configuration and its components.

A more detailed diagram of the individual node is shown Figure 1-4. Again, the physical

make up is the same for both the receiving nodes and the single transmitter or basestation.

The software design differences between the mobile nodes and the base station are

discussed in Chapters 3 and 4.







DAQQ



DAQ



Transmitting
Basestation
DAQ,


Receiving Ad hoc
Network

Figure 2-1. Testbed node arrangement









As mentioned in the introduction, this chapter will explain the motivation for

choosing each component used in the testbed along with the important specifications and

their implications concerning maintenance and future upgrades. This chapter describes

the individual hardware components of the testbed. They include the RF front end,

antenna, data-acquisition (DAQ) pad, laptop computer, and wireless broadband router.

The RF Front End

When choosing the RF frontend, a few key factors need to be considered. The

frontend needs to have low power consumption, be low cost, be easy to use, have typical

operating voltages, operate in a frequency range in the ISM band, and most importantly

provide a receive signal strength indicator (RSSI) output.

Low power consumption is desired because the mobile nodes will be battery

operated. Testing can take several hours and even though the main power consumption

will be from the DAQ and laptop, minimizing the power consumption of the frontend

will make the nodes more efficient in providing a long duration of operation.

One goal of the research is to demonstrate the ability of collaborative reception

techniques to improve the transmission range. This will be demonstrated by placing the

receiving nodes at distances near the limits of the frontend' s range. Having a high power

long range frontend is not necessary for this purpose. In fact, long range coverage would

make testing more difficult because the receiving nodes would have to be placed further

away from the basestation. This would require more area and more time to set up the

testbed.

Although this research focuses on improving the receive capabilities, future work

will also address transmission capabilities. It is important that the frontend is a

transceiver, capable of both transmitting and receiving data.










The RSSI output is the most important requirement. The RSSI is used to calculate

the signal to noise ratio, decode the received data, and determine the reliability of each

bit. Without access to this output, the collaborative techniques can not be implemented.

The RF frontend initially chosen was the RF2905-H evaluation board from RF

Micro Devices. The RF2905 met all of the key requirements, however, it was not very

stable and only two of the five evaluation boards would consistently work together. For

this reason a change was made. One of Laipac's transmitter receiver pairs, the TLP916A

and RLP916A, met most of the key requirements. The Laipac frontend is not a

transceiver which is adequate for this research. Future operators that want to research

collaborative transition may decide to design a board with a transmitter and a receiver.

These boards can be used as the transceiver for each node.

This transmitter receiver pair was much more stable and easy to use compared to

the RF2905. The Laipac chipset was designed for 916.5 MHz applications with data

rates up to 200Kbps and typical range of 300 feet open area. A schematic for both the

receiver and transmitter are given in Figure 2-2 and 2-3 respectively.

43III









Figure 2-2. Laipac receiver, RLP916-A. Frequency: 916.5 MHz, Modulation: ASK,
Supply Voltage: 2.7 to 5.0 VDC, Output: Digital and Linear, Chip Set
Technology Sensitivity: -104dBm.



















Figure 2-3. Laipac transmitter, TLP916-A. Frequency: 916.5 MHz, Modulation: ASK,
Operation Voltage: 2 to 12 VDC, RF Output Power: 10mW.

The operating and control voltage range has a minimum of 2 volts and a maximum

of 12 volts DC. The standard TTL operating voltage of 5 volts is used which is well

within the range. The power consumption is relatively low. For the transmitter the peak

current at 5 volts is about 5 mA. For the receiver the peak current at 5 volts is about 10

mA. The transmitter and receiver are easily controlled. A 5 Volt square wave serial data

stream is used to drive the transmitter' s "data in" pin. As mentioned it is in the 915 MHz

ISM band [1]. Most importantly, the receiver has a linear output which will give a

received signal strength or RSSI output.

The collaboration code was written for BPSK modulation. The frontend is

incapable of BPSK, however, this is not a problem because the outputs of an OOK signal

can be easily manipulated to resemble the outputs of a BPSK signal. BPSK outputs can

are unipolar and can be represented by the equation, bi = (-1)'. A binary 1 or bl = -1 and

a binary 0 or bo = 1. The linear output of the receiver has a constant DC voltage,

therefore the output is not unipolar. The first step to converting this output to BPSK is to

remove the DC voltage. This can be done by using a DC blocking capacitor.

If the DC blocking capacitor is too big it will have a larger time constant or slow

settling time. This will distort the liner output. If the DC blocking capacitor is too small

then it can't produce the appropriate voltage level and will attenuate the signal. A 68 pF










capacitor had a good response time and did not attenuate the signal too badly. However,

there was some signal attenuation. An amplifier was used to compensate for the

attenuation. Because the signal and the noise were both attenuated by the capacitor an

amplifier proved to be an acceptable solution.

Experimentation showed that using just a DC blocking capacitor was not sufficient.

It was observed that the pulse width for a binary 1 was more narrow than the pulse width

for a binary 0 (i.e., the linear output did not have a 50% duty cycle). For this reason the

capacitor could not completely remove the DC. Because of the duty cycle, the average

was around 100 mV instead of 0 V and therefore not unipolar. A second step had to be

performed to convert the linear output to a unipolar signal. Using code an average linear

output can be determined and be subtracted from each voltage sample. By subtracting

the average, the linear output was now unipolar.

It was also observed that the receiver required a significant amount of settling time.

When transmission began after a long idle period the receiver's linear output would ramp

up until it settled. This ramping effect was observed even without the DC blocking

capacitor. One solution would be to continuously transmit a square wave which would

keep the channel at a settled state. Because of power consumption and interference, this

solution would be extremely inefficient. Another solution would be to take a "local

average" and subtract it from its corresponding samples. This is easily implemented in

code. The code would break the sampled data into blocks. The first block can be

brought in and averaged. This average is then subtracted from each sample in that block.

This process is repeated for each block of data and hence a local average is subtracted










from the entire sampled data stream. This process eliminates the ramping effect

observed. The code used to implement this process is discussed in Chapter 4.

As discussed, the Laipac frontend has some drawbacks. These drawbacks can be

dealt with making the Laipac frontend a good choice. The TLP916 and RLP916 are more

robust and much easier to use compared to the RF2905. Overall the Laipac fontend

meets most of the key factors and will be used in the testbed design.

Antenna Design

The key factors to consider when designing the antenna are the weatherproofing of

the antenna, desired coverage, impedance of the RF frontend, complexity of the entire

system, and cost.

Weather proofing the antenna is not a concern because all of the testing would be

done either inside or outdoors in favorable conditions. The desired coverage is

omni-directional in azimuth. The impedance of the frontend is 5002. The antenna needs

to be simple, cheap, reproducible, fairly rugged, and with repeatable "standard"

characteristics. These considerations lead to a simple ground plane vertical '/ wave

antenna.

The antenna is fed with 50 0Z coaxial cable. It is an "unbalanced" antenna, such that

the shield is connected to the ground plane and the vertical portion is connected to the

center conductor. The free space wavelength, h, at 915 IVHz is about 0.33 meters

calculated by the equation:

h= C /F[Hz]


where C = 2.998E8 m/s (speed of light).









The vertical portion, L, is '/ wavelength long and is therefore resonant at that

frequency (i.e., L = h/4). Therefore L = 0.0819 meters or about 3 '/ inches when

calculated using the free space speed of light. In reality the element ends up being about

10% shorter due to the "end effect" of the wire or about 3 inches in total length above the

ground plane. It is at this frequency that this element will efficiently accept radio

frequency power and "convert" it into electromagnetic fields. Its impedance is about 35

0Z and therefore a good match for 50 0Z cable and the frontend.

Of course, other vertical lengths that result in zero reactance at the feed can also be

used. The length of %/ wavelength is the next useful length above '/ wavelength; it is at

this length that a current maximum again appears at the feed. The '/ wavelength case has

a voltage maximum and therefore an impedance which is prohibitively high to be fed

directly by 50 ohm coaxial cable. Also, the elevation antenna pattern for the '/ wave

vertical is a horizontal "donut" with the vertical antenna at the center. The pattern is

uniform in azimuth. The %/ wavelength vertical has an elevation pattern which has an

additional null at around 700 from the vertical, making it less than useful for most

applications. These factors made the '/ wave antenna the obvious choice.

The vertical antenna is fed by the ground plane. The ground plane acts as a

"counterpoise", that is, it provides the ground reference by having an impedance at its

center which, if measured against the environment, is quite low. The impedance is quite

low because it is 1/ wavelength in radius, that is the outer edge of the ground plane is '/

wavelength away from the center. Transmission line theory states that the impedance at

the center is now a short to ground and thus a great place to terminate the outer conductor

of the coaxial cable.










The ground plane antenna should have a minimum ground plane radius of about '/

free space wavelength (i.e., about 3 '/ inches). Therefore, a 6 '/ inch circle copper plate

was used as the ground plane.

A BNC bulkhead connector was used as a vertical mount. The connector has an

exposed terminal which was used as the feed. The connector was mounted upside down

on the copper ground plane, that is the BNC portion facing down and the solder terminal

facing up. The center conductor is just a solid copper wire. The wire is thick in diameter

so that it can fit in the BNC terminal. The center conductor is soldered into the solder

cup of the connector. The solid copper conductor acts as the vertical element. The "end

effect" which causes the vertical radiator to be about 10% shorter than the free space

value results in a total length, again, of about 3 inches for the vertical element, including

the length of the solder terminal above the surface of the ground plane. Figure 2-4 shows

a diagram of the antenna and its dimensions.

Data Acquisition (DAQ) Pad 6070E

A data acquisition (DAQ) device is necessary to programmatically acquire signals,

send data, and control the RF frontend. It is important that the DAQ is portable, has easy

I/O connections, and can interface with the laptop.

National Instruments DAQPad 6070E is a high-performance multifunction

analog, digital, and timing I/O device for computers with IEEE 1394 (firewire) ports.

Supported functions in the DAQPad-6070E include analog input (AI), analog output

(AO), digital I/O (DIO), and timing I/O (TIO). The two most important features of the

DAQPad 6070E are the 12-bit A/D converter (ADC) with 16 analog inputs and the two

12-bit D/A converters (DACs) with two voltage outputs. The ADC will be used to























6.5"

Side View


sample the RSSI output of the frontend. One of the DACs will be used to drive the

frontend with the output waveform.


6.5"


Top View

Figure 2-4. Antenna design and dimensions

National Instruments portable E Series DAQ delivers the same functionality

available in PCI and PXI E Series DAQ devices in a portable format. The DAQPad

devices are hot swappable and available in up to three different configurations. The

IEEE 1394 automatically handles the assignment of all host resources, so the user can

install the device without powering down the computer. The 15 cm enclosure is a

low-profile package that fits under the laptop computer. It features a 68-pin shielded

connector were the control lines, RSSI output, and data pins of the frontend are

connected.









The DAQPad comes with a software package, Measurement and Automation

Explorer (MAX). MAX allows the user to configure the DAQ, add new channels, add

new interfaces, add virtual instruments, execute system diagnostics, view devices and

instruments connected to the laptop, and schedule updates to the National Instruments

software.

MAX is used, most importantly, to configure the DAQ. Before running any

collaborative code the user should open MAX and make sure the DAQ is recognized and

configured appropriately. This is done by selecting the Devices and interfaces folder in

the configuration window. Under this folder the DAQ pad 6070E should be listed. The

user should right-click on the DAQ 6070E and select properties. This will open the

configuration window for the DAQ pad 6070E. The three tabs of importance are System,

Analog Input (AI), Analog Output (AO), and Accessories.

The DAQ pad 6070E has three input modes nonreferenced single-ended (NRSE)

input, referenced single-ended (RSE) input, and differential (DIFF) input. A channel

configured in the NRSE mode uses one analog channel input line, which connects to the

positive input of the programmable gain instrumentation amplifier (PGIA). The negative

input of the PGIA connects to the analog input sense (AISENSE) input. A channel

configured in the RSE mode uses one analog channel input line, which connects to the

positive input of the PGIA. The negative input of the PGIA is internally tied to the

analog input ground (AIGND). A channel configured in the DIFF mode uses two analog

channel input lines. One line connects to the positive input of the device PGIA, and the

other connects to the negative input of the PGIA [2]. For the testbed configuration the

appropriate input mode is RSE.









The DAQPad 6070E has two input polarity settings unipolar and bipolar.

Unipolar input polarity means that the input voltage range is between 0 and Vref, where

Vref is a positive reference voltage. Bipolar input polarity means that the input voltage

range is between -Vref/2 and +Vref/2. The DAQ pad 6070E has a unipolar input range

of 10V (0V to 10V) and a bipolar input range of 10V (-5V to 5V). There is also a

software-programmable gain on the DAQ pad 6070E, however, this gain will be left at 1

for the testbed configuration. The input polarity and range setting is based on the

expected range of the incoming signal. A large input range can accommodate a large

signal variation but reduces the voltage resolution. Choosing a smaller input range

improves resolution but may result in the input signal going out of range. For the best

results the input range is matched as closely as possible to the expected range of the input

signal [2].

The DAQPad 6070E allows the user to enable dither. With dither enabled

approximately 0.5 LSB rms of white Gaussian noise is added to the signal to be

converted by the ADC. Enabling dither will artificially increase the resolution of the

signal. This is undesired for our system because the collaborative technique requires an

estimation of the signal to noise ratio. With dither enabled this estimation will appear

better than it actually is, therefore dither is disabled for the testbed configuration.

The DAQPad 6070E supplies two channels of AO voltage at the I/O connector.

The reference and range are selected in MAX. The reference can either be internal or

external, and the range can be either bipolar or unipolar [2]. An internal reference is the

appropriate setting for the testbed configuration. A unipolar configuration has a range of

0 to Vref at the AO. A bipolar configuration has a range of -Vref to +Vref at the AO.









Vref is the +10V onboard reference because the internal reference is used. The frontend

requires a unipolar baseband data signal therefore, a unipolar range is selected for the

testbed configuration.

In the Accessories tab the SCB-68 should be selected. This is the mass terminal

block to which all of the control lines and the input/output connections are wired. It is

important that the user selects this accessory in the accessories tab.

MAX also allows the user to test the DAQ pad. A quick diagnostic is performed by

pressing the "test resources" button in the System tab. The user may also choose to run

the test panel and generate outputs or view inputs. This is a very helpful debugging tool.

The user should initially check the configurations and test the resource every time the

testbed is used.

Laptop

The testbed is reconfigurable with a laptop as the software processing baseband

unit. The laptop will run all of the software and control the DAQ pad. The operator will

use the laptop to modify packet size, change the amount of exchange data bits, enter the

number of receivers, etc. It is important that the laptop is fast, reliable, has Windows

operating system to run LabView and LabWindows, an IEEE 1394 firewire port, and an

802.11 wireless network card.

The laptops chosen were from Dell. There are two models of Dell laptops used, the

Inspiron 8200 and the Inspiron 5150. Both laptops meet all of the desired specifications.

The Inspiron 8200 has an Intel Pentium 4 processor at 2.00 GHz, 5 12 MB of RAM,

Windows XP operating system, one IEEE 1394 port, and the True Mobile 1300 802.11

b/g3 wireless Mini-PCI card.









The Inspiron 5150 has an Intel Pentium 4 processor at 3.2 GHz, 1 GB of RAM,

Windows XP operating system, one IEEE 1394 port, and an internal True Mobile 1400

Dual Band Mini-PCI card.

Wireless Broadband Router

In order for the mobile nodes to collaboratively decode the received signal they

need to be connected to a high-speed ad hoc network. The ad hoc network is easily

implemented using the 802. 11 wireless cards and a wireless router. The router is used as

a DHCP server and assigns an IP address to each computer or node.

The Dell True Mobil 1184 Wireless Broadband Router was used to implement the

ad hoc network. The Wireless Broadband Router supports up to 252 clients. Up to 16 of

the 252 clients can be wireless. The Network Address Translation (NAT) feature allows

64 clients to simultaneously communicate out to the Internet [3]. Future operators are

limited to 16 mobile receiving nodes using this router. The code was written for a

maximum of 4 mobile nodes, well under the maximum capacity of the router.

The built-in Ethernet wireless access point runs at 11 Megabits per second (Mbps).

The maximum distance between the Broadband Router and each computer is 300 feet.

This distance may be less depending on the environment [3]. The connection speed and

distance specifications of the 1 184 wireless broadband router will be sufficient for the

high-speed ad hoc network.















CHAPTER 3
SOFTWARE IMPLEMENTATION OF THE BASESTATION

As explained in the introduction this chapter will describe the code written to

implement the single transmitter or base station. This chapter will follow the flowchart

describing the base station implementation given in Figure 3-1. Individual sections will

include LabView Overview, Datasocket, Random Data Generator, Encoder code,

Synchronization and the M-sequence, Analog Output, and Receiver Statistics.

LabView Overview

LabView is a graphical development environment designed specifically for

building testing and measurement applications. LabView is often compared to

programming languages because it shares many of the same characteristics as a

programming language. With LabView the user can control the Daq and perform other

useful functions inherent in other programming languages. These two capabilities make

LabView an obvious choice for the testbed design. LabView is used in the base station

implementation to generate the random data bits, pass the random data to an encoder

written in C, send the data to the RF front end, and analyze the data received by each

mobile node. The entire LabView code is given in Appendix A.

DataSocket

DataSocket is an Internet programming technology used by National Instruments

that simplifies data exchange between computers and applications. DataSocket allows a

user to efficiently pass data over the Internet or network, and respond to multiple users












































Transmit


Figure 3-1. Flowchart of the base station code










without the complexity of low-level TCP programming. DataSocket makes the

sharing of scientific and engineering data between software applications and between

networked computers as easy as reading and writing data to Hiles [4].

There are two types of Datasocket connections used in the testbed. One type of

connection is between two different applications running on the same laptop. The other

type of connection is between different computers on the wireless network. In both cases

a Datasocket server is needed.

All nodes on the network should have their Datasocket servers running before

starting the testbed. The Datasocket server on each node will act as a localhost server to

manage all Datasocket connections between applications.

One node should be designated as the server to manage Datasocket connections

from node to node. The Datasocket server on this designated computer should be

configured using the Datasocket server manager. In the Datasocket server manager under

Permission Groups the IP addresses, assigned by the router, of each computer should be

entered under Default Readers, Default Writers, and Creators. This will give permission

to the other nodes to create Datasocket connections and read data from or write data to

these connections.

The localhost DataSocket is used to pass data from LabView to the encoder. The

encoder is written in C and runs in LabWindows. Referring to the flowchart in Figure

3-1, the first two functions of the base station code are to pass the initializing data and the

random data to LabWindows. This is done by simply opening a Datasocket connection

on the local host between the two applications. The Datasocket transfer protocol (dstp)

uses a standard URL assignment. For example the URL for a localhost connection










between two applications is dstp ://localhost/connection~name. This is easily done with

LabView using virtual instruments (VIs) (Figure 3-2).

dstpffloalh stliitiaize Local





Figure 3-2. Connecting to LabWindows on the loacalhost and sending the initializing
data

As mentioned earlier, DataSocket is also used to pass data from node to node over

the wireless network. A Datasocket connection between the base station and mobile

nodes is unnecessary for collaborative reception. However, to analyze the performance

of each mobile node there is a connection created between the mobile nodes and the base

station. The mobile nodes will need a Datasocket connection to exchange data and

perform collaborative reception. This will be discussed in the chapter on mobile nodes.

Opening a Datasocket connection between computers is similar to opening a

Datasocket connection between applications. The difference is the IP address of the node

designated as the Datasocket server is used in the URL instead of localhost. For example

consider the scenario that node 1 is designated as the Datasocket server and is assigned

the IP address 192.168.2.4. In order to pass data from node 3 to the base station the URL

would be dstp://192. 168.2.4/connection~name. Notice the IP address of node 2 and the

base station' s IP address is not used in the URL, only the IP address of the Datasocket

sever is used. This is the URL assignment for all connections from node to node

regardless if they are designated as the server or not. Figure 3-3 shows an example of

how data is passed from node 1 to the base station.















Figure 3-3. VIs used to open a Datasocket connection between nodel and the base station
and pass the Signal to Noise Ratio measurement to the base station for
analysis.

Datasocket connections can also be made by setting an indicator, or an array for

example, to subscribe to a Datasocket connection. This is done by right-clicking on the

indicator and selecting data operations >> Datasocket connection. In the Datasocket

connections window the URL of the connection can be entered and the options of

publish, subscribe, or publish and subscribe may be selected. By subscribing to a

Datasocket connection the indicator will be updated every time the Datasocket is

updated. This is very helpful and reduces some of the code that needs to be written in

LabView.

Overall DataSocket is a very helpful National Instruments application. The

collaboration process between nodes is made very simple using DataSocket. The

Datasocket connections are very robust and the server will allow up to 10000

connections.

Random Data Generator

Referring back to the flowchart in Figure 3-1, the next operation after passing the

initializing data to the encoder is to pass the actual random data that is to be transmitted

to the encoder. The user has the ability to make a transmitted packet any size he or she

desires. On the front panel of the Base station VI under "number of data bits" the user

should enter the desired packet size. The packet size is first sent to LabWindows to










initialize the arrays in the encoder code. When the encode button is pressed a packet of

random data is generated and stored in the array Random Data (Figure 3-4).
















Figure 3-4. Random data generator using LabView

As shown in the figure the LabView' s random number generator is used to build

the random data packet. The random number generator produces a uniformly distributed

random number between 0 and 1. The random number generator is called by a For-Loop

the number of times specified by "number of data bits". If the random number is greater

than 0.5 a zero is generated and if the random number is less then 0.5 a 1 is generated.

These random 1's and 0's make up the data packet to be encoded.

The data packet is then passed to the encoder through a Datasocket connection on

the localhost. The encoder receives this data and encodes it. The encoder code will be

discussed in the following section.

Encoder Code

National Instruments LabWindows/CVI is an ANSI C development environment

that among other features includes NI' s DataSocket networking architecture and a

Graphical User Interface (GUI). The encoder used in the testbed was written in C, which

makes LabWindows a natural choice in implementing the encoder. As mentioned earlier










the C code could have been directly integrated into the LabView code using a Formula

Node. However, to make both the decoder and encoder code compatible with the testbed,

they needed to be modified. Because of the complexity of both codes and because

LabWindows provides a better debugging environment it was decided that using

LabWindows and just passing the data using a Datasocket connection was more feasible.

Since the code has been modified and all the bugs have been worked out, future operators

may decide to just directly embed the code in LabView.

The Datasocket connections in LabWindows can be configured to work like an

interrupt. Whenever data is written to the Datasocket a function will "fire" and retrieve

the data from the Datasocket. The Datasocket function that retrieves the data will also

include the encoder function. The encoder function will generate the encoded data.

There are three localhost Datasocket connections involved in passing data back and

forth between LabView and LabWindows. One connection will be used to send the

initializing data, a second connection is for LabView to send the random data to

LabWindows, and a third connection is for LabWindows to send the encoded data back

to LabView.

The URL for the initializing data is the same as the one mentioned above,

dstp ://localhost/initialize. It is important for the LabWindows code to be as dynamic as

possible. After opening the localhost Datasocket server, the user only needs to open the

LabWindows code once. The LabWindows code should dynamically update itself to

match the data coming from LabView. In order to operate this way the size of the data to

be encoded needs to be sent every time, unless it stays the same. The code will be able to

identify any change in the data size and update its arrays accordingly.









The URL of the Datasocket connection for LabView to send the random data to

LabWindows is dstp://localhost/encode. As mentioned earlier whenever this Datasocket

is updated by LabView the function to read the data will execute automatically. This is

done by setting the Datasocket connection to "DSConstReadAutoUpdate". Upon

receiving the data it is saved in an array "rdata". The data is displayed in a table on the

user interface. Displaying the data in a table is not completely necessary, it was only

done to verify the correct data was read from the Datasocket. The array "rdata" is then

passed to the function "trellis_enc". This function will take the random data and encode

it. It implements a V/2 rate trellis encoder. The encoding process doubles the original data

and adds 4 bits. For example, if the random data is 1000 bits the encoded data will be

2004 bits. The size of the encoded data and the encoded data itself are put in an array

"tdata". The array "tdata" is sent back to LabView using the Datasocket connection

dstp://localhost/encoded.

Synchronization and the M-sequence

The encoded data cannot just be simply passed to the front end for transmission.

There are two more important arrays that need to be added to the encoded data before

transmission can begin. An array of synchronizing data and a 63 bit m-sequence need to

be added to the encoded data. A diagram of the frame structure can be seen in Figure

3-5. The encoded data was discussed in the previous section. This section will explain

the synchronizing data and the 63 bit m-sequence and will also explain the importance of

transmitting this way.


1010...10101 63 bit m-sequence Encoded Data

Figure 3-5. Frame structure of 1 packet









When transmission begins after an idle period the linear output will rise

significantly before it settles. The rising and settling effect can be seen in Figure 3-6.

The long array of alternating l's and 0's gives the receiver time to settle. The receiver

does not completely settle before the data is sent, but the significant rise is at the

beginning of the transmission and this is taken out by the alternating l's and 0's. Another

reason for the long array of alternating l's and 0's is to ensure that no data was missed.

The receiver waits in a while loop for the trigger. The execution of the while loop is

dependent on the processing speed of the receiver. If the receiver' s reaction to the

Boolean trigger is "slow" then the first few data bits can be missed. Adding l's and 0's

to the beginning will ensure that the receiver does not miss any data. The array of

alternating l's and 0's is saved in a text fie "junk.txt". This file is opened by LabView

and added to the beginning of the transmitted array.

In order to normalize the received data the exact beginning of the packet must be

determined. This is done using a correlating detector. The correlating detector searches

for the 63 bit m-sequence. An m-sequence is used because it can be easily distinguished

from other sequences and from a time-shifted version of itself.

An m-sequence is just a spreading sequence often used in CDMA applications.

The reason the m-sequence is easily distinguished from other sequences and from a time

shifted version of itself is because it has a "good" discrete-time periodic crosscorrelation

and autocorrelation function [5]. For BPSK, sequences that have these properties can be

generated with a binary linear feedback shift register. A barker sequence would serve the

same purpose as the m-sequence, however, there are not any barker sequences as long as











the 63 bit m-sequence. A long sequence was required to make a signal-to-noise ratio

estimate. The signal-to-noise ratio estimate will be explained in Chapter 4.


Linear Output



12-




08-




04-

02-





sam ples

Figure 3-6. Linear output after an idle period. The output rises significantly at the
beginning of transmission and then begins to settle.

Using the m-sequence will assure that each mobile node can determine the

beginning of the data packet. The m-sequence is generated using MatLab and saved in a

fie "m-sequence.txt". The Eile is opened in LabView and added after the array of

alternating l's and 0's and just before the encoded data. The MatLab fie works like a

binary linear feedback shift register. The polynomial used is x6 X 1 With the initial state

= 101010. Since this is a 6 degree polynomial the sequence will be 63 bits long


(N = 2n-1). A copy of the MatLab file is given in appendix B. LabView was used to

combine the alternating l's and 0's and the m-sequence with the encoded data


(Figure 3-7).






















Figure 3-7. Creating the array to be sent to the front end using LabView

Analog Output

Now that the data array to be sent to the front end has been assembled, the next step

in the flowchart is to transmit this data. This is done in LabView with the Analog Output

Waveform VI. When the transmit button is pressed a Boolean true is sent to the receivers

to notify that data transmission is about to begin. This is followed by a short pause to

allow the receivers to begin acquiring data and ensure that no data is missed. After the

pause the Analog Output Waveform is called. This VI requires the device number (Daq

number assigned in MAX), the update rate (baud rate), channel number (there are two

DACs), and the data to be output. The data is passed to an output buffer. The VI returns

control to the LabView diagram only when the generation is complete, that is when the

buffer is emptied.

After the data is output the same VI is called again to return the output line to 0

volts. This is done so that the receiver will remain or idle in a low state. One triggering

technique considered was for the receiver to begin acquiring data when a voltage

threshold was passed. This requires the receiver to idle at a known voltage level. For

this reason the output line is always returned to 0 volts after every transmission. This

technique was not very robust, therefore a Boolean trigger was implemented, but for










uniformity the line was still returned to 0 volts. This will be discussed in Chapter 4.

Figure 3-8 shows the Analog Output Waveform VI.

-hannls 0 dvce 1)



data ~ ~ se sett fotn





Figure 3-8. Controlling the D/A using the AO Wave VI

Receiver Statistics

The final function of the base station code is to generate the receiver statistics so

that results can be verified and conclusions can be formed. The goal of this research is to

verify that collaborative reception improves the error correction capabilities of an

individual node. To show that this capability is improved three sets of data need to be

generated and compared. The three sets are the received data before decoding, the

decoded data before exchange, and the decoded data after exchange. To show the

transmission errors the received data is compared to the transmitted data. To show the

errors corrected without collaboration the "decoded data before exchange" is compared to

the generated data. To show the errors corrected with collaboration the "decoded data

after exchange" is compared to the generated data. The three sets of data along with the

signal to noise ratio measurement are generated by the receiving nodes and passed back

to the base station. These three comparisons are displayed on the base station front panel.

The base station can record these statistics and repeat the transmission over and over

again. For example the base station can transmit 1000 packets of data and record

statistics of each transmission. The results can be graphed and an average number of









errors received and corrected can be calculated. If the average number of errors corrected

with collaboration is greater than the average number of errors corrected without

collaboration then the results of the computer simulation and this research will be

verified. The code described in this chapter was written to send one packet at a time. To

do the final analysis just described, the code has to be slightly modified. This is easily

done by adding a For-loop and a user input for the number of transmissions to perform.















CHAPTER 4
SOFTWARE IMPLEMENTATION OF THE RECEIVING NODE

This chapter will explain the code written to implement the receiving node. The

sections of this chapter will be broken up into the individual functions of the mobile node

presented in order on the flowchart given in Figure 4-1. The individual section titles will

be Initialization, Triggering, Analog Input, Correlating Detector, Normalizing the Data,

Signal to Noise Ratio Measurement, Decoding Process, Exchange Protocol, and

Displaying Results.

Initialization

The first function of the receiving node is to setup the Datasocket connections. The

Datasocket connections will be used to pass data from LabView to LabWindows, pass

data between receivers, and pass the results back to the base station. The connections

made will be based on the Receiver ID (Rid). For example node 1, Rid = 1, will open the

Datasocket connection dstp://192.168.2.4/snrl to pass the signal to noise ratio

measurements back to the base station. Node 2 opens Datasocket connection

dstp://192.168.2.4/snr2, and so on. This naming convention is carried throughout the

entire testbed.

Once the appropriate Datasocket connections have been opened the code will then

send the initialization data to the decoder in LabWindows. The initializing data for the

decoder includes the Rid, number of receivers, number of exchange data bits, and the

number of encoded data bits. With this data the decoder can initialize its variables.


























































Figure 4-1. Flowchart of the receiver code









The next initialization task is to build the array mask using the m-sequence

discussed in Chapter 3. This mask is used to search the buffered data for an exact

beginning of the encoded packet. The incoming data is sampled at 10 times the baud

rate, that is, each bit will be represented by 10 samples. In order to match the

m-sequence exactly the mask has to resemble the sampled data. For each bit in the

m-sequence there will be a block of 10 numbers in the array mask, therefore a 63 bit

m-sequence creates a 630 bit array mask. For example a binary "1" in the m-sequence

will add a block of 10 "I's" to the array mask and a binary "O" in the m-sequence will

add a block of 10 "-1's" to the array mask. The reason a 0 translates to a -1 is because

after the DC is removed from the sampled data the binary O's become negative. Figure

4-2 shows the LabView code for building the array mask. To help clarify this process a

table showing part of the m-sequence and the resulting array is given in Table 4-1.

Understanding the array mask will be helpful in understanding how the correlating

detector works. The correlating detector will be discussed in detail later in this chapter.


Figure 4-2. Building the array mask from mesequence.txt












Table 4-1. Resulting array mask from
the iven m-sequence.
M-seqence Arry Mask
1 0 1
1 1
2 1
3 1
4 1
5 1
6 1
7 1
8 1
9 1
0 10 -1
11 -1
12 -1
13 -1
14 -1
15 -1
16 -1
17 -1
18 -1
19 -1


Triggering

There were two triggering techniques considered when designing the testbed. The


first technique used LabView' s analog hardware trigger and the other technique was to


trigger from a Boolean logic "true" sent by the base station through a Datasocket

connection. In practice the Boolean technique would not be an option because this


requires the base station and the receiving nodes to be on an existing network, which

would defeat the purpose of improving communications between them. Using

LabView' s analog hardware trigger is more realistic, however it is not robust and it is not


suitable for practical use. In practice the receiving node constantly samples and searches

the incoming data for the m-sequence. Because of processing limitations of the laptop


and LabView this technique could not be implemented. To implement this technique a

hardware processing unit, such as an FPGA or ASIC, would be required.









LabView' s Analog Input VI can be configured for an analog hardware trigger. The

Analog Input Start VI has the options for a digital trigger, an analog trigger, or scan clock

gating. When configured as an analog hardware trigger with a rising edge the AI Start VI

will begin acquiring analog input when a rising edge exceeds a specified threshold. The

idea was to idle the receiver low and when data started the threshold would be passed and

the Daq would begin buffering samples. This would work in an ideal situation were the

linear output of the receiver always idled at the same voltage level and there was no other

applications near by using this frequency that could produce a false trigger, however, this

is not the case. The linear output of the receiver is an indicator of the signal strength. At

different ranges this voltage level changes dramatically. In some instances the analog

input would not trigger if the signal strength is too low. Further more, the presence of a

915 IVHz signal will cause the linear output of the receiver to rise based on the strength

of that signal. This would lead to false triggers because the 915 IVHz ISM band is used

in many applications. Other devices on this frequency could cause the receiving nodes to

begin acquiring data even though transmission had not begun. For these reasons this

technique was abandoned. In the future, testbed users may choose to implement an

FPGA circuit that would continuously sample and check for the m-sequence and then

provide a trigger to the processor to begin sampling and buffering the linear output of the

receiver.

The solution to this issue was to "cheat" the triggering process. Because the base

station and receiving nodes are on the same wireless network, for statistical analysis, a

Datasocket connection for triggering could be created. The transmit button on the base

station is configured to publish its Boolean value to a Datasocket connection. The









receiving nodes will continuously loop until the transmit button is pressed. When the

transmit button is "true" the receiving nodes will begin sampling and buffering the linear

output of the receiver. Although this is not a realistic solution, triggering is not the focus

of this research. Using this technique will not invalidate the experimental results. This

triggering technique is very robust eliminating the concern of false triggers and assuring

that the active receivers will begin buffering data when they should.

Analog Input

Upon receiving the Boolean trigger, the mobile node will acquire an entire buffer of

data and then remove the DC from the samples. The reason for removing the DC is to

make the samples resemble BPSK outputs. The buffering is done using the AI Config,

AI Start, AI Read, and AI Clear VIs. The DC is removed by using a simple for loop.

Figure 4-3 shows the VI arrangement in LabView for configuring the AI, acquiring data,

clearing the AI buffer, and removing the DC voltage from the sampled data.

The AI Config VI configures the AI buffer, the DAQ device number, and the

analog input channel number. The buffer size is determined by the number of encoded

data bits to be received. The user must input this value on the front panel. To assure the

synchronizing data, m-sequence, and all encoded data is received and buffered, 5000

extra bits are sampled in addition to user input "number of encoded data bits". The

incoming data is sampled at 10 times the rate so this number is then multiplied by 10, the

resulting equation for determining the buffer size is:

AI Buffer size = (number of encoded data bits + 5000) 10

The DAQ device number is assigned in MAX and should be verified every time

before using the testbed. There are 16 analog input channels to choose from. The

operator may choose any one of the analog input channels. The DAQ device and channel









number are both inputs on the front panel. The operator should set them accordingly. All

other inputs to the AI Config VI are left as their default values.

The AI Start VI is used to begin sampling the channel specified in the AI Config

VI. The configuration settings input to the AI Config VI are passed to the AI Start VI

through the task ID. The AI Start VI requires the scan rate to be set by the operator.










Figure 4-3. Buffering the sampled linear output of the receiver into a 1D array and
removing the DC

When the operator enters the baud rate on the front panel this number is multiplied

by 10 which sets the scan rate to 10 times the baud rate. The operator should be certain

that the baud rate setting on the base station is the same for every receiving node. The

input "number of scans to acquire" is the total number of scans LabView acquires before

the acquisition completes. A scan is one point per channel. When the default input is -1,

LabView acquires exactly one buffer of data, this default is left unchanged. As

mentioned in the triggering section the inputs for triggering are not set because the

Boolean trigger is used. All other inputs to the AI Start VI are left as there default

settings.

The AI Read VI does not require any user inputs. All of the configurations from

AI Config and AI Start are passed through the task ID. When the buffer is full AI Read

outputs the samples into a scaled array. The scaled data is a 2D array that contains

analog input data in scaled data units. The data appears in columns, where each column









contains the data for a single channel. Since there is only one channel used there is only

one column of data but it is still a 2D array. This 2D array has to first be converted into a

1D array before being processed.

The AI Clear VI simply clears the input buffer. The AI buffer is cleared every

time to assure there is no old data in the buffer. This VI does not require any user inputs,

only the task ID is needed to clear the appropriate buffer.

The next step is to remove the DC voltage from the sampled data. The decoder

program requires BPSK inputs. Removing the DC will give negative values for O's and

positive values for l's. Multiplying all of these values by -1 will result in a BPSK output

-1's for l's and 1's for O's.

As mentioned in Chapters 2 and 3, the receiver will ramp up when data

transmission begins after an idle period. The addition of a DC blocking capacitor helped

to dampen this ramping effect but did not completely prevent it from occurring. As

described in Chapter 2, one can remove the DC by finding a "local average" and

subtracting it from the corresponding samples. The code used to subtract the "local

average" from the samples is also given in Figure 4-3. The receiving node starts

buffering samples just before the data transmission begins. Samples are brought into a

for-loop 400 at a time. An average is calculated and then subtracted from the 400

samples. This is repeated for the entire buffer. This process will remove the DC from

each sample even in the presence of the ramping effect.

Correlating Detector

Now that the channel has been sampled and saved in a 1D array, the exact

beginning of the transmitted packet must be determined. This is done using a correlating

detector. The correlating detector is implemented using a For-loop. The operation can be









visualized as sliding a window along the received data and finding the best match. The

window that is being compared to the received data is the array mask created from the

m-sequence. The array mask is multiplied by the first 630 samples in the received data

array and the output array is summed. This sum is the weight of the first position and it is

stored in another array that holds all of the weights. The received data array is shifted by

one sample and is again multiplied by the array mask and summed. This sum is inserted

into the array holding the weights as the next element and represents the weight of the

second position. The received data array is shifted again by one sample and the process

continues until a weight is calculated for the first 10000 samples or positions. The

position with the highest weight represents the beginning of the m-sequence. Since the

m-sequence is of known length, 63 bits, and the sample rate is 10 times per bit, the exact

beginning of the data packet is 630 samples from the position with the highest weight

(Figure 4-4). In order for the data to be decoded each bit must be represented by a single

value, this is referred to normalizing the data. The normalizing process is described in

the next section.

Normalizing the Data

The correlating detector finds the exact beginning of the data. The next step is to

represent each data bit with one voltage level. Each bit is sampled 10 times. By

averaging these samples a single voltage value can be calculated for each bit. It was

observed that a binary 1 did not have the same pulse width as a binary 0. The pulse width

for the binary 1 was more narrow than the binary 0 and therefore, did not have 10

samples that represented the entire bit. Because of this more narrow pulse width and

because the index of each bit may be off a few samples, only the middle 4 samples are

averaged (Figure 4-5).









This average is used as the voltage level representation for each bit. This is easily

done in LabView using a For-loop. Blocks of 10 samples are input into the For-loop.

The middle 4 samples are taken out of the block of 10 samples and averaged. The

average is stored in an array. The next 10 samples are brought into the For-loop and

again only the middle 4 samples are averaged to determine the voltage level of the bit.

The average is again inserted into the array. This process is repeated for the entire length

of the received data packet (Figure 4-6).















Figure 4-4. Correlating detector

The resulting normalized array is the received data before decoding. The

normalized data is used to build an array of l's and 0's. If the voltage level is greater

than 0 it is saved as a 1, if the voltage level is less than 0 it is saved as a 0. This array of

l's and 0's is sent back to the base station using a Datasocket to compare the transmitted

array and determine if there were any transmission errors. The generated array is then

multiplied by -1 to obtain the BPSK outputs discussed earlier. The BPSK outputs are

stored in an array that will be sent to the decoder.

Signal to Noise Ratio Measurement

The code written to implement the signal to noise ratio measurement is similar to

the code written to normalize the data. The m-sequence is a known pattern and is









therefore used to determine the signal noise ratio. The 630 samples that best matched the

m-sequence are multiplied by the array mask. If a good match is found then this

multiplication will result in all positive voltages. This is demonstrated in Figure 4-7.

The line "received m-sequence" represents the received data that most resembled the

m-sequence, the line "array mask" is the data being compared to the received data, and

the line "array mask m-sequence" is the resulting multiplication of the two. The

average and variance of "array mask m-sequence" is used to calculate the signal to

noise ratio.

Again, because of the more narrow pulse width for binary I's" and because the

index of each data bit may be off a few samples, only the middle 4 samples are used in

this calculation. The importance of using the middle four samples is shown in Figure

4-7. The narrow pulse width of the l's result in some negative values after multiplying

the array mask times the received m-sequence. As in the normalization process, a

For-loop is used to extract the middle 4 samples. The middle 4 samples of each bit are

saved in an array. The following equations are used to determine the average, variance,

and signal to noise ratio.

AVG = sum of the samples / number of samples

VAR = Average[(sample AVG)2]

SNR = AVG2 / VAR

The LabView code written to determine the signal to noise ratio is given in Figure

4-8. The array to be used in the calculations is multiplied by 10. This was done because

the values can be relatively small and LabView will round them off. Multiplying by 10



















~ T~,4 1.:.llr 3)1 ~ i 3 dT 3141 1:1 1114m(r,4 1~~ 1:~1311 1~ II










4 7 '10 1X'18 '19'122 ~5 28 311T34 3+ 40 43 48 4a 52 55 58 BYB4 87 70 73 78 78


does not affect the signal to noise ratio measurement because it is a ratio. The factor of

10 is only used to give a more accurate measurement.


Samples


Figure 4-5.


Linear output with the DC removed showing how an average voltage per bit
is calculated using four middle samples. Notice if all 10 samples were used
the average would be distorted.


Figure 4-6. Normalizing the data and sending the received 1's and 0's back to the Base
station.
























| A



n-a




-n I+









II;















0.. B



4 10 3lt 16 19ll 2f 25 2El a 31 r 34 lr 37 4 3 sti ti9 52 seiS 6 161 67 7 73 76 79E





-1 .


Sample I
B


Figure 4-7. Signal to Noise Ratio Estimate A) Part of the received m-sequence and
corresponding part of array mask. B) The m-sequence multiplied by the array
mask.



















Figure 4-8. Calculating the estimated signal to noise ratio

Decoding Process

The decoder, written in C, executes in LabWindows. To work properly the code

needs to know if it is the first or second iteration, the signal to noise ratio, the received

data, the index of the exchange data from the other receivers, and the actual exchange

data from the other receivers. This information is passed to LabWindows through a

Datasocket connection in an array. The arrangement of the data within the array is the

same in which it was listed.

The code was written as general as possible. The decoder variables are initialized

at the beginning of the code. The code will know exactly how many received data bits

and exchange data to expect. During the first iteration, the node's first attempt at

decoding the data with no help, the exchange data will be initialized to all zeros. Like the

encoder, when LabView writes the data to the Datasocket the code will "fire", like an

interrupt, and begin reading the data from the Datasocket into the array rdata. The

variable init, SNR, the rssi array, index array, and exdata array, are pulled out of the array

rdata in that order. Again, on the first iteration the arrays index and exdata are set to all

zeros.

After the variables have been set, the decoder function is called. The decoder

returns the exchange information (the index array and the exdata array) and the decoded

bits (Rxb). The index array, exdata array and the Rxb array are combined in the array










"tdata". In order for LabView to know that the data sent back is valid the variable init is

inserted at the top of the array "tdata". The tdata array is passed back to LabView using

the Datasocket connection dstp ://localhost/analyed.

LabView will loop until the first value in the array matches the variable "init". On

the first iteration the variable "init" is set to 1 and on the second iteration "init" is set to 0.

During the first iteration LabView will wait until it receives a 1 back from the decoder.

On the second iteration LabView will wait until it receives a 0 back from the decoder.

On the first iteration, after LabView has verified that the data is valid, the node will then

pass its exchange information to the other nodes. This process is explained in the next

section.

Exchange Protocol

Now that each node has made an attempt to decode the data independently and

generated some exchange information, the collaboration process will follow. Each node

receives its exchange data from the decoder in LabWindows. Once this data is received

each node will write its exchange data to a Datasocket connection. The other active

nodes subscribe to this Datasocket connection to obtain the exchange data from that node.

By subscribing to the Datasocket connection the subscribing array will automatically

update whenever data is written to that connection. Each node may process the data at

slightly different times, therefore a protocol is needed to determine when the data in the

subscribing array is valid.

Each individual node will have an rts (request to send) Boolean value that will be

set true when the initial decoding process is complete. After publishing the Boolean true,

the node will wait for rts's from the other receiving nodes. The individual node knows










how many nodes are on the network and the node knows its Rid, therefore it can

determine which and how many nodes to wait for (Figure 4-9).




















Figure 4-9. The exchange protocol. In this example nodel (Rid =1) knows there are 4
receivers, therefore it waits for rts2, rts3, and rts4.

After the exchange process is complete a second decoding iteration is performed

with the exchange data from the active nodes. The decoder is called the same way as

before during the first iteration. Instead of having all zeros, as in the first iteration, the

exchange data will be replaced by the values provided by the other nodes. The decoded

data after the second iteration is saved in an array "decoded data after exchange".

Displaying Results

The second iteration should improve the correction capabilities of the node. This is

the goal of the research. To show the transmission errors the received data is compared

to the transmitted data. To show the errors corrected without collaboration the "decoded

data before exchange" is compared to the generated data. To show the errors corrected

with collaboration the "decoded data after exchange" is compared to the generated data.

These comparisons are done by the base station as described in Chapter 3. However,







48


each node will show the received data and the decoded data before and after the

exchange. The receiver will also show how many bits were corrected by the second

iteration, if any, and their index. Each node displays its statistics to provide more

information to the operator and to verify that the base station is receiving the correct data

from each node.















CHAPTER 5
ENCODER AND DECODER

This chapter will explain the encoder and decoder used in the testbed. The encoder

is a simple convolutional encoder with a rate k/n = '/ and constraint length K = 3. The

decoder is basically a maximum a posteriori (MAP) decoder. To better understand the

decoding algorithm a background on the Viterbi convolutional decoding algorithm and

soft decision decoding will be discussed before the MAP decoder is explained. The three

sections of this chapter will be the convolutional encoder, the Viterbi convolutional

decoding algorithm and soft decision decoding, and finally the MAP decoder.

Encoder

As mentioned the encoder is a 1/ rate convolutional encoder with constraint length

K=3 (Figure 5-1). The rate is determined by k/n where n is the encoded bits and k is the

message bits, that is, k/n message bits per encoded bit, where k
K is the size of the shift register.

First code
symbol


Input bits Output
a branch word

Second code
symbol


Figure 5-1. Convolutional encoder (rate '/, K=3)









At each input bit time, a bit is shifted into the leftmost stage or the register and the

bits in the register are shifted one position to the right. The two symbol branches are the

result of an exclusive OR between the values in the register denoted by the connecting

arrows. The output switch then samples the output of each code symbol, first from the

upper then from the lower. The final output is the code symbol pair making up the

branch word associated with the bit that is just input into the encoder. This process is

repeated for each bit in the input sequence. The connections from the register to the

exclusive OR determine the characteristics of the encoder output. Different connections

will yield different codes. These connections are not randomly chosen. The process of

choosing connections that yield good distance properties is complicated and has not been

solved in general. Good codes have been found by computer search for all constraint

lengths less than about 20. The connections used in the testbed are the ones shown in

Figure 5-1.

At the end of the input bit stream the shift register must be cleared. Clearing the

shift register requires a series of O's to be appended to the end of the bit stream. This will

add to the encoded message which causes the effective code rate to fall below k/n. As

mentioned earlier, the convolutional encoder used in the base station has a constraint

length K=3. The clearing process will add 4 bits to the end of the encoded data. The

actual output will be determined by the equation

N =(2 *k) +4

where N is the size of the encoded data and k is the size of the message bits to be

encoded. The encoder used in the base station is just the simple convolutional encoder as

described above. The decoder is a bit more complicated. In order to understand the









MAP decoder, it is important to understand the Viterbi convolutional decoding algorithm.

The next section will explain the Viterbi convolutional decoding algorithm and soft

decision decoding.

Viterbi Convolutional Decoding Algorithm

This section will discuss soft decision decoding and the Viterbi convolutional

decoding algorithm. The decoder used in the testbed is actually a MAP decoder, but it is

important to first understand the Viterbi algorithm.

A tree diagram can be used to map out the encoder transitions as a function of time.

Observation of the tree diagram will reveal that the tree repeats itself after K branchings,

where K is the constraint length. In the case of the testbed, the encoder has a constraint

length of K=3, therefore the tree will repeat itself after three branchings. Because of this

repetitive structure, the tree diagram can be significantly simplified thereby making a

more manageable decoder description. This reduced tree diagram is referred to as a

trellis diagram (Figure 5-2).

The trellis diagram is a fixed periodic structure. The entire structure is realized

after a depth K is reached. At this point and thereafter, each of the states can be entered

from either of two preceding states and can transition to one of two states. With this

knowledge a decoder can find the path through the trellis diagram that has the maximum

likelihood of being the received bit sequence.

The Viterbi decoding algorithm works by calculating a measure of similarity, or

distance, between the received signal, at time ti, and all the trellis paths entering each

state at time ti. The Viterbi algorithm removes from consideration those trellis paths that

could not possibly be candidates for the maximum likelihood choice. When two paths

enter the same state, the one having the best metric is chosen; this path is called the










surviving path. This selection continues in this way to advance deeper into the trellis,

making decisions by eliminating the least likely paths.


State 0 1 2 3 4 4-- Stage
00 0 0 0
(00)
0 0
1 (11) 1 1



1 1 1 1

(10)



0 0
(00)

1 UI


Figure 5-2. Trellis diagram for a rate V/2, K=3 encoder

As stated above, the path with the best "metric" is chosen. The metric is

determined by the Hamming distance between the received code symbols and each of the

branch words for that time interval. For example referring to the trellis diagram in Figure

5-2, if the decoder is in sate 00 the two possible transitions are 00 to 00 and 00 to 10. In

order to go from 00 to 00 the received code symbol has to be 00. In order to go from 00

to 10 the received code symbol has to be 11. Because of the encoder structure, these are

the only two possible transitions. The received code word is compared to these two

possible transitions and the difference or metric is calculated. If 11 was the received code

symbol, then the metric for 00 to 00 is 2 and the metric for 00 to 01 is 0. Notice that this

technique is a hard decision technique because it requires the receiver or demodulator to

tell the decoder that the received code symbol is 11. A metric is calculated for each









transition. When any two paths in the trellis merge to a single state, the metrics of both

paths are summed and the one with the maximum sum is eliminated. Finding the path

with the minimum metric is the same technique used for both hard and soft decision

decoding. A soft decision decoder is very similar to the hard decision decoder except that

the soft decision decoder uses the soft output of the receiver and hard decision decoder

uses the hard decision output of the receiver.

In the hard decision case, the receiver output for a binary signal is either a 1 or a 0.

This hard decision is fed into the decoder and the resulting decoding process is called

hard decision decoding. In the soft decision case, the receiver output is more than two

levels. For example, eight levels of quantization requires 3 bits to describe a single

binary symbol. In effect, sending such a 3-bit word in place of a single binary symbol is

equivalent to sending the decoder a measure of confidence along with the code-symbol

decision. If the receiver sends the decoder 1 11, this is tantamount to declaring the code

symbol to be a one with very high confidence. If the receiver sends the decoder 100, this

is tantamount to declaring the code symbol to be a one with very low confidence [6].

For the soft-decision decoder, the quantized output of the receiver is used to

calculate the metrics of each transition. The decoder still eliminates the path with the

higher metric, however the metric is more accurate because it uses more information to

make this calculation.

In the testbed the linear output of the receiver is used to perform soft decision

decoding. The linear output varies with the signal strength. The voltage level of the

linear output is used as a confidence measure in the symbol decision. A higher voltage

means higher signal strength which translates into a higher confidence in the decision.









The confidence in each bit, given by the linear output, along with the estimated signal to

noise ratio can be used to determine the reliability of each received binary symbol. This

reliability is used to determine the exchange data to be shared with the other nodes in the

ad hoc network. A decoder that uses a priori probability information that is independent

of its own decisions is called a MAP decoder. The MAP decoder is used in the testbed to

decode the data using the exchange data from other nodes. This decoder will be

discussed in the next section.

The MAP Decoder

The MAP decoder is a maximum a posteriori decoder. The algorithm uses the

same technique as the Viterbi algorithm except it employs a priori probability

information about each bit, while the Viterbi algorithm implements Maximum Likelihood

(ML) decoding. In ML decoding the decoder chooses the symbol sequence whose

likelihood, given the channel observation is greater than the likelihood of all other

possible symbol sequences. This can be stated as maximizing P(y/xj), where y is the

channel observation and xj is the j possible symbol sequences. The MAP decoder has

information about the a priori probability of each bit and can therefore be written as

maximizing P(y/ xn)P(xn), where y is the channel symbol observation and xn is the n

possible symbol decisions. This priori probability information allows the MAP decoder

to outperform the ML decoder. Note that a fundamental difference between the ML

decoder and the MAP decoder is that the ML decoder works to maximize the likelihood

of the whole observed sequence while the MAP decoder maximizes the a posteriori

probability of a bit.

During the first attempt at decoding the data, none of the nodes have any priori

probability information. As mentioned earlier the exchange data from the other nodes on










the first decoding attempt is all O' s. A zero translates into a probability of 0.5 for each

P(xn),therefore the capabilities of the MAP decoder during the first attempt is equivalent

to that of the ML decoder.

After the first decoding attempt, the a posteriori information of each bit is generated

by each node by observing the whole packet. After the a posteriori probabilities are

determined the code ranks them in a descending order. A percentage of the most reliable

bits is chosen as the exchange data. The percentage taken out is set by the operator.

Again, the testbed was designed to allow the operator to vary the amount of exchange

data.

The data is exchanged and then the existing receivers on the ad hoc network each

have new a priori probability information that will allow them to perform the MAP

decoding algorithm again. The exchange technique described is called the MRB or most

reliable bits scheme. This technique works well with more than 8 receivers.

Another technique referred to as the LRB or least reliable bits scheme may also be

used. LRB differs from MRB in that it determines which bits have the lowest a posteriori

probability and request that information from the other nodes. After the request is

performed then the node can perform MAP decoding with the new a priori probability

information that it requested from the other nodes. A disadvantage to the LRB technique

is that it requires more exchanges than the MRB technique. However, when there are

only a few receivers in the ad hoc network, the LRB technique performs better than the

MRB technique. The testbed is designed using the MRB technique. Future operators

may choose to integrate the LRB technique into the testbed.















CHAPTER 6
TESTING

After the testbed was completely configured and the code debugged, tests were

performed to hopefully verify that collaborative reception would improve the receive

capabilities of each individual node. The verification was done by calculating the bit

error rate (BER) for various signal-to-noise ratios (SNR). This chapter will discuss the

testing procedure, the problems encountered during testing, solutions to these problems,

and the final results.

As described earlier the base station code is implemented in a for-loop. The

for-loop allows the base station to continually transmit a number of packets. For each

packet sent the base station would record the statistics from each node in the network.

The statistics collected included the SNR, the errors received (hard decision errors), the

decoder errors without collaboration, and the decoder errors with collaboration.

The scenario that this research seeks to improve is one in which all receiving nodes

in the ad hoc network consistently make independent decoding errors. The hope is that

this scenario would require the collaboration process to eliminate these errors. The bulk

of the testing was done indoors where the SNR fluctuated significantly. This made it

difficult to find a perfect spot in which all three nodes would consistently make errors.

There were some locations, however, that for the most would provide the desired

environment to show the capabilities of the collaborative reception techniques.

There were three receiving nodes, each placed on a cart. The carts were moved to

the spots in the engineering building, outside of the wireless communications lab, that










would provide the desired environment. The base station or transmitter was left in the lab

on a desk. A diagram of the cart orientation in the New Engineering Building on the 4th

floor is given in Figure 6-1.


New Engineering
Building 4th Floor
North End
Location of
Transmitter
Lab

Lab *
O ', / 50

SOffices '\,'Ro


Receiving nodes


Women's Men's








Figure 6-1. Cart Locations in the New Engineering Building on the 4th flOOr. All interior
walls are sheet rock with steel studs. The carts were approximately 86' apart.

As discussed in chapter 5 the collaborative technique used was MRB. This

technique is good when there are more than 8 receivers. In order to make the MRB

technique show reasonable results with three receivers more data needed to be

exchanged. For the test the data size was 1000 bits and the exchange data was set to 500

bits or half of the data. Both of these numbers can be varied by the operator, but for

testing purposes they were fixed. This is a high number of bits to exchange. Future

operators may choose to either build more stations or implement the LRB technique so

that a more practical amount of bits can be exchanged.









Initially the transmitter and receiver were placed on a breadboard and connected to

the DAQ. This did not allow the use of an antenna because the antenna connector was

either BNC or SMA which could not be plugged into a breadboard. After running tests

with the transmitter and receivers connected this way, it was observed that the receivers

were very unstable. The SNR would fluctuate significantly. It seemed that the

communications link was disturbed quite easily by traffc in the room or hallways.

Furthermore, the breadboard may not have provided a suffcient ground for the receiver

and transmitter.

The solution to this issue was to design and mill a printed circuit board (PCB). A

simple board was laid out in Protel and milled on double sided copper. The bottom layer

of the PCB was used as a ground plain for both the transmitter and the receiver. An SMA

connector was soldered onto the PCB to allow an antenna to be connected. The PCB

made the transmitter and receivers much more consistent and less easily disturbed by

passers by. The PCB layout can be seen in Appendix C.

Each cart had the capability to be completely battery operated, however, the

battery-life of the laptops were only a couple of hours and one of the laptops would only

stay on for about half an hour. This made testing somewhat dimfcult because it took

some time to gather enough statistics to perform an accurate analysis. The only solution

was to plug carts into the wall which required the carts to be placed next to an outlet.

Making the mobile nodes completely battery operated is possible, but would require each

laptop to have an extra battery. The battery life of the DAQ was suffcient.

As mentioned earlier the statistics collected from each receiving node after each

packet transmission were the SNR, the hard decision errors, the decoder errors before










exchange, and the decoder errors after the exchange. Over 600 packets were transmitted

with 1000 random data bits and 500 exchange bits. This allowed for over 2000 data

points to be collected and averaged for each type of error. The statistics collected after

each packet are tabularized by the base station. A portion of the collected statistics is

given in table 6-1. Each row corresponds to a packet.

Table 6-1. Sample of the statistics collected by the base station.

Nodel Node2 Node3

Hard Errs Errs Hard Errs Errs Hard Errs Errs
Dec no with Dec no with Dec no with
SNR Errs Exch Exch SNR Errs Exch Exch SNR Errs Exch Exch
13.564 0 0 0 8.918 0 0 0 6.488 0 0 0
11.01 0 0 0 10.259 0 0 0 6.992 0 0 0
10.243 0 0 0 10.604 0 0 0 4.908 0 0 0
5.018 200 25 0 12.445 3 0 0 6.808 0 0 0
-2.182 978 369 56 8.748 6 0 0 7.521 0 0 0
-3.641 871 298 67 0.492 73 0 0 7.707 4 0 0

The statistics were placed in bins according to their SNR and the BER for each bin

was calculated. A separate LabView VI was written to place the collected data into their

respective bins and calculate the BER. This VI is given in Figure 6-2. The VI will read

in the file with the SNRs and the number of errors for each packet. For each SNR, from

-9 dB to 35 dB with a bin size of 1 dB, the corresponding bit errors are put into their

respective bin. These bins are then added up and divided by the number of bits sent. For

example if the collected data from two consecutive packets is 5.6 dB with 2 errors and

5.8 dB with 3 errors. Both of theses bit errors would be placed in the bin 6 dB and the bit

error rate would be 5/2000 = 0.0025. The sum of the bit errors is divided by 2000

because there are two packets that are 1000 bits long.
































Figure 6-2. VI used to bin the receiver statistics so that a BER vs SNR graph could be
generated.

The output of this data is saved to a spreadsheet fie designated by the user. This

VI must be executed on each set of data (i.e., on the hard decision, decoded data without

exchange, and decoded data with exchange). This process will create three Hiles. Each

fie can then be concatenated to produce the Einal table to be graphed. The final table can

be seen in Table 6-2.

The data in Table 6-2 was graphed using a scatter plot. The scatter plot is given in

Figure 6-3. Each point represents the BER for each bin. The data from each bin comes

from the receive statistics generated by each individual node. The graph does not

necessarily reflect the performance of the other nodes during each transmission. This is

because the SNR is not necessarily the same for each node during the same packet

transmission. For example node 1 could receive packet 1 with a SNR of 1 dB and at the

same time node 2 receives packet 1 with a SNR of 10 dB. Of course in this scenario if

node 1 makes some errors, and at 1 dB SNR it probably will, then node 2 could










potentially correct a number of node l's errors. This is not particularly the scenario these

schemes aim to improve, however, this scenario is very relevant to real life situations so

it is therefore not discarded. Again this is not reflected in the SNR vs BER graph.

The graph clearly shows that collaborative reception improves receiver

performance. The performance is significantly better at extremely low SNRs.

For reasons of comparison the results of the computer simulation for 3 receivers,

1000 data bits, 500 exchange data bits, MRB, and AWGN channel is given in Figure 6-4.

The simulation results also included a second exchange which was not implemented in

the testbed and can therefore be neglected. The overall performance of the computer

simulation was much better than the testbed. This was to be expected because theoretical

results are difficult to achieve, however, collaborative reception did shown an

improvement in the BER.

Other packet sizes and exchange data sizes could have been plotted and compared,

but this was not the scope of the research. The goal was to prove that collaborative

reception could improve the receive capabilities of each individual node in an ad hoc

network. This was done as shown above in the BER vs SNR graph. Comparing different

collaborative methods, packet sizes, data rates, exchange bits, etc would be the next step

for operators that choose to continue this research. The future uses along with weak

points, strong points, and obstacles overcome during the design will be discussed in the

final chapter, Conclusions.


















.-r I

r-'t i7


iiiiii~iiiiii3Iiiiii3IiiiiiiEiiiiii~iiii
~~~~~~I~~~~~~~~~~~~~?~~~~~~~C~~~~~~I~~~~
~~~~~~I~~~~~~~IIIIII~III~~~~C~~~~~~I~~~~
~~~~c~~~~~~l~~~~~~~~~~~~~~~~~~~~~c~~~~~~
I-----
~r.r -- ---
::::-~T~~iH'' i'' i i i i uii~ i i i i i i i i i I i i i i i i ~ i i i i i i i i i i i i i i i i i i i i i ~ i i i i i i i
' ' ; '-~-1~-----------1~ : - - - - - - - - - - --
-,-, -
......:......:.. U. ~-,.......... u'.~-,............. ~Kl~l~(i;;l~i -

111111:11 ~""j'~~~~~"
iiiiii" -C
--r----- -----,-------r------r-------
------r------,----- --l--;-----r--cr--r -------~-----.----- --r------r-------
I;ilIIIIIIII~IIIII ~f~I;IIII, I~;x~a~4Cii,
~ i """" ""'iiiiii:iiiiiii
::"'~j~~~~~~
I i
II::::::::::::

i i i i i i I i i i i i i t i i i i i i i.i i i i i i i.i i i i i i I i i i i i i t i i i i i i'i~.i i i i i
TTTTTT TTTTTT TT~TTT T~TTT T iiiii iiiiii
iii iii~iii iiii-------l-------r-~- -;;1------.------,- -

:::':i::::'::::::~
13
iiiiii iii iiiiiiiii"i~8~6"r~f~siii i:~::::iiiii..



~~~~~~;~~~rrr~rrrr rr~rrrrrrrrrrr, IIIIISr~~~~~;~~~~~ ~~c~~~~~~;~~~~r~

~~~~~~T~~~~~~~~~~~~~~~~~~~~~T~~~~~~T~~~~


-I


0.001





0.0001


t

j
t

L


0.00001


-9 -8 -7 -6 -5 -4 -3 -2 -1 0


12 34 5 6
SNR (dB)


7 8 9 10 11 12 13 14 15 16


Figure 6-3. BER vs SNR graph of the data given in table 6-2. Collaborative reception
with 3 receivers outperforms a single receiver.


-3


-2 -1 0 1i 2

ENo (d B)


3 4 56


Figure 6-4. BER vs SNR graph of the computer simulation.


0.01-
I 10!c











Table 6-2. Final results for 3 receivers, 1000 bits per packet, and
500 exchange bits.

BER
SNR (dB) Hard Decision Single Receiver 1 Exchange
-8 0.52794412 0.503 0.253
-7 0.49301396 0.48566668 0.11666667
-6 0.31836328 0.2895 0.0465
-5 0.40186296 0.32433334 0.056333335
-4 0 0 0
-3 0.31786428 0.24933334 0.037333333
-2 0 0 0
-1 0.30713572 0.2335 0.05075
0 0=.25434844 0=.19342858 0=.050714285
1 0.30439122 0=.214 0.0425
2 0.1 0.082 0.0184
3 0.11338434 0.10022222 0.015555555
4 0.11958226 0.10042857 0.013714286
5 0 0 0
6 0.10882996 0.09209524 0.016285714
7 0.031257485 0.026 0.00408
8 0.033221435 0.024030303 0.006454546
9 0.037662175 0.029875 0.005625
10 0.018463074 0.01825 0.002666667
11 0.010774504 0.010868421 0.001131579
12 0.008505461 0.007101124 0.001595506
13 0.007101796 0.006624 0.002032
14 0.002112891 0.001684685 0.00209009
15 0.00011705 8.64198E-05 0
16 0 0 0















CHAPTER 7
CONCLUSION

This chapter discusses the weak points of the testbed, strong points of the testbed,

the future uses of the testbed, and the overall conclusions.

Most of the weak points have been discussed throughout the paper. These weak

points are not failures of the design. When starting this research it was anticipated that

going from a theoretical design to a real life system would create some design issues that

would be otherwise unknown. In some cases, simple solutions are proposed and could

have been implemented if there were more time. Future operators should review these

weak points and try to remedy them for future operation.

As discussed earlier the triggering mechanism is a weak point in the testbed. The

triggering implementation takes advantage of the fact that the base station and receiving

nodes are on the same network. A Boolean logic true is passed to all the stations just

before packet transmission begins. This is a weak point because this approach could not

be used in practical situations. As discussed earlier if the receiving nodes are on an

existing network with the basestation then there is no need to improve a second

communications link. Future operators may choose to use hardware, such as an ASIC or

FPGA to constantly scan the output of the receiver and generate the trigger.

It was observed that the SNR varies significantly. Switching from a breadboard

circuit to a PCB circuit helped to stabilize this measurement but the SNR estimate would

still fluctuate. This could potentially skew the data because a slow data rate was used.

The data rate used was 4000 bits per second. At this rate the packet, that is over 3000










bits, takes over half a second to completely transmit. In this time frame the SNR can

vary and will not accurately reflect the SNR for the entire packet.

The data rate of 4000 bps was much lower than the maximum rate for the

transmitter and receiver which is 200 Kbps. It was observed that when data rates

approached around 10K the linear output became distorted. More than likely this is a

receiver design issue. The hard decision output of the receiver at these higher rates was

not nearly as distorted, however, the decoder required the soft outputs and therefore a

lower rate was used. Future operators may choose to investigate techniques to overcome

the distorting linear output so that the data rates can be increased. One such technique

may be to use an equalizer to combat the distorting effect.

The packet utilization is very inefficient. The receivers will rise and then settle

upon receiving data after an idle period. To combat the rising effect a long stream of

alternating l's and 0's are sent before the m-sequence and the actual encoded data. The

length of the alternating l's and 0's is about the same as the length of the m-sequence and

encoded data (i.e., the alternating l's and 0's double the packet size). Sending twice the

necessary data is very inefficient. The only solution to this would be to replace the

transmitter and receiver pair with a pair that does not have the rising effect.

The Datasockets have some issues. Each node's Datasocket connections must

contain the Datasocket server' s IP address. When the wireless router is unplugged and

moved to a different location the router will reassign an IP address to all of the nodes.

This often occurs because the router must be unplugged and moved whenever the testing

location changes, when going from indoors to outdoors for example. If the node that

acted as the Datasocket server is reassigned a different IP address, then the operator has










two choices. The operator can either reconfigure the Labview code on each node with

the new Datasocket server IP address or the operator can setup the node that has been

given the old Datasocket server IP address as the new Datasocket server. An attempt was

made to allow the operator to enter the Datasocket server IP address on each node one

time and the entire system would be reconfigured. This attempt was unsuccessful

because the arrays that were setup to automatically update could not be configured to

change based on a user input. It was thought that by using a property node this problem

would be overcome, but this was not the case. Future operators may choose to setup each

node, using the Datasocket server manager, to include every IP address in the ad hoc

network. This might cause IP conflicts but it would eliminate the server dependency.

There was not enough time to test this idea.

Another issue with the Datasocket connections is that they would often crash. Both

the localhost and the node to node Datasocket connections would randomly stop working.

The reason behind this was never discovered. It was first thought that the wireless

connection would become unstable and cause the Datasocket to crash, but when it was

observed that the localhost connections would also crash this idea was ruled out. Future

operators may consult National Instruments about this issue.

As mentioned earlier the collaboration technique used was most reliable bits

(MRB). This technique required that each node rank the reliability of each bit and share

the best based on the number of exchange data requested by the operator. This technique

is efficient when there are over 8 receivers in the ad hoc network. The testbed is

comprised of 3 receivers. The least reliable bits (LRB) technique would have been better.

To implement this technique would require some significant changes in the code and










because of time constraints was not implemented. Future operators may choose to

implement this technique to see if the same or better results can be obtained with fewer

exchange data. With only 3 receivers, the MRB technique would also cause the receivers

to change correct bits to incorrect bits and hence yield worse results! This is also

possible with LRB but the chances would be reduced.

The battery life of the laptops was only a couple of hours which is not sufficient for

a long amount of testing. In order for each node to be completely mobile extra batteries

must be added to each cart. Another solution might be to place a car battery with a DC to

AC inverter on each cart. This would allow each laptop and DAQ to be plugged in all the

time. The car batteries could then be recharged after each testing period.

A final weak point of the testbed worth mentioning is the typical Windows

operating system issues. All of the software runs on a Windows platform, which has the

tendency to crash after running long tests. This can cause loss of data and can be very

frustrating. Windows may even be the cause of the Datasocket crashes. Future operators

may choose a MAC or Linux based software platform which may increase the robustness

of the entire testbed.

Despite the weak points listed above the testbed was a success! The tests verified

that collaborative reception can improve the receive capabilities of a single receiver in an

ad hoc network in a real life system. The computer simulations were verified by showing

that the bit error rate can be reduced with collaboration. This translates into a lower

transmit power or increased range. Receivers that would normally make errors by

themselves can reduce or eliminate those errors with collaboration. The testbed was

designed in a way that will allow future operators to manipulate packet size, baud rate,









number of receivers, and the number of exchange data bits. The testbed will be very

helpful to researches than plan on continuing the work in the future.

This research focused on collaborative reception, the next step for the testbed is to

implement collaborative transmission techniques. In order to do this a board with both a

transmitter and receiver needs to be designed or a different frontend that has both receive

and transmit capabilities must be substituted.

Future operators should address the weak points discussed in this chapter. For

some of the weak points solutions were suggested. These suggested solutions may be

enough to fix these problems making the overall testbed more robust and user friendly.

After the testbed has robust transmission and reception capabilities a natural next

step would be the design of higher layer protocols. The current testbed design dealt with

the physical layer only, the transmission of one packet. Future operators may want to

design a protocol that will allow multiple packets to be transmitted with a form of error

check.

Again the overall goals of this research were met. The testbed demonstrated that

the collaborative reception techniques could improve communications for a real life

system. Transforming the theoretical ideas into a real life system made clear the practical

considerations that would otherwise be unclear. Dealing with triggering, power

consumption, SNR estimates, PCB layout, etc were all issues that were not considered in

theoretical design. There are solutions to these issues and correcting them will ultimately

prove the practicality of the collaborative reception techniques.









For future operators a troubleshooting guide is given in Appendix D. The

troubleshooting guide should be referenced by users in case the testbed is not working

properly .



















APPENDIX A
LABVIEW CODE


Appendix A includes the LabView frontpanel for both the receiver and the


transmitter. The frontpanel is what is seen by the operator. The frontpanel is just a GUI


that is supported by LabView code called a diagram. The diagram for each frontpanel is


not included in the appendix.


1:~ ,. -4
dtvictil~
ri.
11'
chnnck i~] ~
~lr;











~.m li,jil
b.ar





jri I;i j~r~~i~j
tii


~,~j~j ~j~j



scan ~atc(l: ju 1
rj[i i
~kooo.oo I

i~!lu~ r~l~u~
0" 0"
~ r_4 :ul: O
0"


F -;~.jl :1 I:jt Illll~lyj d ~ j

4 10 00 ":'

I:je

10 00

j.j
ii liii


rur.b r r e 75r.3.


Figure A-1. Receiver Front Panel

















IVud Irile


It rO I


I: -. I 1ICIC


asI I- I














rsd~ilprerrerr re-ri 1





r; illF rnl ro ni tare~ mi L1T










.,nr.r I itrrerr~tfr rrdangel



nonir.sl. ?blr mrrt7ed












n~ma error: Iu~ni t

.rdi. if aTIr: I-r~llr.1



BER intsor.1


pl -ii I 1 dP) i


;no~de L,, e~rd *






nd lcr or:r li d _










rrarer pn r borr; jshr.'.






laboreror:~p carrod 1 LlniI












BEF on2 m lR;


arrode ddr, nee






Imrvieolf error rFI-








R m i ira. c rrr iIanqi









.nenfr or~ itr~nce














n~n~Fllrror- ;nnon

rii. -rr ( a



11ET Io3


1I I







ei=>.1









0- p*-









71n4 Ob:CrrTi



n Embr~ rol~r- r rrecr=















05m bo4 I i ti


Figure A-2. Base station Front Panel















APPENDIX B
LABWINDOWS CODE

Appendix B contains the LabWindows code. The four files included are the

receiver code, the basestation code, mdpc_core.c, and cc.h. All the code is written in

ANSI C.

Receiver Code



// This code launches a data socket connection on the local host upon start up
// the initial connection is for Labview to send the parameters (receiver ID, data size) so
//that the variables and the array lengths can be initialized. The code then waits for
//labview to send the received data. Upon receiving the data the code will decode and
//determine the exchange data along with the hard decisions and then send this data back
//to Labview. Code will work with 1 to 4 receiving stations


#include
#include
#include /* Needed if linking in external compiler; harmless otherwise */
#include
#include
#include
#include "ANALYZE5.h"
#include "dataskt.h"

#include "cc.h"
#include "mdpc_core.c"
//#include "decoder.c"

#define Max K 100000

static int panelHandle;
static DSHandle dsHandle;
static DSHandle dsHandle 2;
static DSHandle dsHandle T;
static int singleX = 0;
static int no~of_params = 4;









static int rdata size, tdata size, Rid;
static int params[4] = {0,0}; //this holds the initial parameters Rid and data~size
int old Rid = 0;
int initial_open = 1;
int M; // # of receivers
int K; // size of exdata
int N; // size of encoded data
int Nb; // size of original bit stream
double *rdata;
double *tdata;
double appu[Max K];
int rec[Max K];
double old rdata size = 0;

st table *state tbl;

/* This is the callback function for the DataSocket */
void DSCallback (DSHandle dsHandle, int event, void *pUserData);
void DSCallback_2 (DSHandle dsHandle_2, int event, void *pUserData);

/* user interface loop */
int main (int argc, char *argy[])

1 nt i;

if (InitCVIRTE (0, argy, 0) == 0) /* Needed if linking in external compiler; harmless
otherwise */
return -1; /* out of memory */
if ((panelHandle = LoadPanel (0, "ANALYZE4.uir", PANEL)) < 0)
return -1;

state~tbl = read st tbl("c:\\conv1 .st",30);

DisplayPanel (panelHandle);

DS_Open ("dstp://localhost/initialize", DSConstReadAutoUpdate, DSCallback, NULL,
&dsHandle);
// DS_Open ("dstp://localhost/valid", DSConstWriteAutoUpdate, NULL, NULL,
&dsHandleV);

RunUserInterface ();
return 0;


int MRB2(int N,int nx,double *si,int *ind,int *rec)









int i,*index,*ptl,z;
double *abssi,*pt2,*pt3;

pt1 = index = (int *) malloc(N~sizeof(int));
pt2 = abssi = (double *) malloc(N~sizeof(double));
pt3 = si;
f or (i= 0; i
(ptl ++) = i;
*(pt2++) = fabs(*(pt3++));
ind[i] = 0;

qsortl (index,abssi,0,N-1);
pt1 = ind;
for (i=N-1,z=0; z=0; i--)

z += 1-rec[index[i]];
if (rec[index[i]] != 1)

//*(pt2 ++) = (*(si + index[i]));
//*(ind ++) = index[i];
ind[index[i]] = 1;


free(index);
free(abssi);
return z;


void decode(st table *state~tbl,int RxID,int Rx,int K,int N,int Ne,double EcNO,double
*rxs, double *appu,int **exindex,double **exchng,int *Rxb,int *rec)

mnt i,m,rx;
int *index,*rxb;
double *exc,*exu,*sou;

Rx ID--;

exu = (double *) calloc(K+statetbl->m,sizeof(double));
sou = (double *) calloc(K+state~tbl->m,sizeof(double));
exc = (double *) calloc(N, sizeof(double));
index = (int *) calloc(K,sizeof(int));

scal ellr(N,Ec NO,rxs,0O);


for (rx=0;rx









if (rx != Rx ID)

for (m=0;m
appu[exindex[rx][m]] += exchng[rx][m];
if (exchng[rx][m] != 0.0)
rec[exindex[rx][m]] |= 1;




appu[K]=100000;
appu [K+1]=100000;
MAX_10gMAP(state~tbl,N, rx s,appu, exc, exu);
addexinfo(K, appu, exu, sou, 0,0);
harddec(K,sou,&rxb,0);
for (m=0;m Rxb[m] = rxb[m];

MRB2(K,Ne, exu,index, rec);
i = 0;
for (m=0;m
if (index[m] != 0)

exindex[RxID][i] = m;
exchng[RxID][i] = exu[m];
rec[m] |= 1;
1++;


for (m=i;m
exindex[RxID][m] = 0;
exchng[RxID][m] = 0;


free(rxb);
free(index);
free(sou);
free(exu);
free(exc);









/* When the Quit button is pressed, call Close and Quit */
int CVICALLBACK QuitBtn (int panel, int control, int event,
void *callbackData, int eventDatal, int eventData2)

switch (event) {
case EVENT CONIMIT:
if (dsHandle) {
D SDisc ard Obj Handl e(d sHandl e);
dsHandle = 0;


if (dsHandle_2) {
D SDiscardObj Handl e(d sHandle_2);
dsHandle 2 = 0;

D SDiscardObj Handl e(d sHandl e_T);
dsHandle T = 0;



singleX = 0;
QuitUserInterface (0);
break;

return 0;


/* This is the callback that fires whenever the initializing data or status is updated */
void CVICALLBACK DSCallback (DSHandle dsHandle, int event, void *pUserData)

RESULT hr = S OK;
double singleFloat;
char message[1000];
char *URL;
unsigned int sz;
unsigned type;

switch (event) {
case DS EVENT DATAUPDATED:

hr = DS_GetDataType (dsHandle, &type, NULL, NULL);
if (type & CAVTARRAY) {
hr = DS_GetDataValue (dsHandle, CAVTINT|CAVTARRAY, params,
no_of_params~sizeof(double), &sz, NULL);









Rid = (int)params[0]; //Rid must be defined before the IF statement so that the
appropriate URL can be assigned
M =(int)params[1];
K =(int)params[2];
N= (int)params[3];

Nb = N/2 state tbl->m;
rdata size = 2+N+2*K*M;
tdata size = Nb+K*2+1;

if (rdata~size != old~rdata~size) {
if (initialnopen == 0) {

DeleteTableRows (panelHandle, PANEL_TABLE, 1, oldtrdata~size);
DeleteTableColumns (panelHandle,
PANEL_TABLE, 1, 1);

}else { //If Rid changes and it is the initial run just
open the connection

DS_Open ("dstp ://localhost/analyze",
DSConstReadAutoUpdate, DSCallback_2, NULL, &dsHandle_2);

DS_Open ("dstp://localhost/analyzed",
DSConstWriteAutoUpdate, NULL, NULL, &dsHandle_T);

initial_open = 0;

}else { //If Rid did not change then just delete the
tables. This is not necessary when you get rid of the tables.

DeleteTableRows (panelHandle,
PANEL_TABLE, 1, oldtrdata~size);
DeleteTableColumns (panelHandle,
PANEL_TABLE, 1, 1);


old rdata size = rdata size;
old Rid = Rid;

rdata = (double *) calloc(rdata_size, sizeof(double));
tdata = (double *) calloc(tdata~size,sizeof(double));

//Create the rows and columns that are necessary. 2 rows and 2 columns of string type
cells.









InsertTableRows (panelHandle, PANEL_TABLE, 1, rdata~size,
VAL_CELLUMERIC);
InsertTableColumns (panelHandle, PANEL_TABLE, 1, 1,
VAL_CELLUMERIC);

} else {
hr = DS_GetDataValue (dsHandle, CAVTDOUBLE, &singleFloat,
sizeof(double), NULL, NULL);
if (singleX >= no_of params)
singleX = 0;
params[singleX] = singleFloat;
singleX++;
sz = singleX;


return;
break;
case DS EVENT STATUSUPDATED:

hr = DS_GetLastMessage (dsHandle, message, 1000);
if (SUCCEEDED(hr))
SetCtrlVal (panelHandle, PANEL_STATUS, message);

break;

return;


/* This is the callback that fires whenever rdata or the status of the rdata connection is
updated */
void CVICALLBACK DSCallback_2 (DSHandle dsHandle_2, int event, void
*pUserData)

RESULT hr = S OK;
double singleFloat;
char message[1000];
unsigned int sz;
unsigned type;
int j,],1mt;
double valid=1;

double SNR;
double *rssi;
int **index;
double **exdata;
int *Rxb;









int *txb, Err;

switch (event) {
case DS EVENT DATAUPDATED:

hr = DS_GetDataType (dsHandle_2, &type, NULL, NULL);
if (type & CAVTARRAY) {
hr = D S_GetD ata~ralue (d sHandle_2, CAVTDOUBLE|ICAVTARRAY,
rdata,
rdata~size~sizeof(double), &sz, NULL);

//Insert the array of strings into the table.
SetTableCellRangeVal s (panelHandle, PANEL_TABLE,
MakeRect (1, 1, rdata~size, 1), rdata, //this was just to show the transmitted data in the
table.
VALROWMAJOR);

Rxb = (int *) calloc(Nb,sizeof(int));
txb = (int *) calloc(Nb, sizeof(int));
rssi = (double *) calloc(N, sizeof(double));
index = (int **) calloc(M, sizeof(int));
exdata = (double **) calloc(M, sizeof(double));
for (i=0;i
index[i] = (int *) calloc(K, sizeof(int));
exdata[i] = (double *) calloc(K, sizeof(double));


init = rdata[0];
if (init == 1)

for (i=0;i
appu[i] = 0;
rec[i] = 0;


SNR = rdata[1];
for (i=0; i rssi[i] = rdata[2+i];
for (i=0;i
for (j=0;j
index[i][j] = (int)rdata[2+N+i*K*2+j];
exdata[i] [j] = (int)rdata[2+N+i*"K*2+K+j];












/* for (i=0; i
txb[i]= (int) rdata[2+N+2*M*K+i];


decode(state~tbl,Rid,M,Nb,N,K, SNR,rssi,appu,index, exdata,Rxb,rec);
tdata[0] = init;
for (i=0;i tdata[i+1] = index[Rid-1][i];
for (i=0;i tdata[K+i+1] = exdata[Rid-1][i];
for (i=0; i tdata[K*2+i+1] = Rxb[i];

/* Err = 0;
for (i=0;i
if (Rxb[i] != txb[i])
Err++;



for (i=0;i
free(index[i]);
free(exdata[i]);
}retx)
free(txb);
free(rssi);
free(index);
free(exdata);

DS_SetDataValue (dsHandle_T, CAVTDOUBLE | CAVTARRAY,
tdata, tdata_size, 0); //this writes the tdata array to labview

// DS_SetDataValue (dsHandleV, CAVTDOUBLE, &valid, 0, 0);

} else {
hr = DS_GetDataValue (dsHandle_2, CAVTDOUBLE, &singleFloat,
sizeof(double), NULL, NULL);
if (singleX >= rdata_size)
singleX = 0;









rdata[singleX] = singleFloat;
singleX++;
sz = singleX;


return;
break;
case DS EVENT STATUSUPDATED:
hr = DS_GetLastMessage (dsHandle_, message, 1000);
if (SUCCEEDED(hr))
SetCtrlVal (panelHandle, PANEL_STATUS_2, message);
break;

return;


/* Call DSDiscardObjHandle when the Disconnect button is pressed */
int CVICALLBACK OnDisconnect (int panel, int control, int event,
void *callbackData, int eventDatal, int eventData2)

switch (event) {
case EVENT CO1V1VIT:
SetCtrlVal (panelHandle, PANEL_STATUS, "Unconnected.");
SetCtrlVal (panelHandle, PANEL_STATUS_2, "Unconnected.");
if (dsHandle) {
D SDisc ard Obj Handl e(d sHandl e);
dsHandle = 0;


if (dsHandle_2) {
D SDiscardObj Handl e(d sHandle_2);
dsHandle 2 = 0;

D SDiscardObj Handl e(d sHandl e_T);
dsHandle T = 0;


singleX = 0;
break;

return 0;


/* when the panel is closed, close the connection and exit */
int CVICALLBACK PanelCallback (int panel, int event, void *callbackData,
int eventDatal, int eventData2)











switch (event) {
case EVENT CLOSE:
if (dsHandle) {
D SDisc ard Obj Handl e(d sHandl e);
dsHandle = 0;

if (dsHandle_2) {
D SDiscardObj Handl e(d sHandle_2);
dsHandle 2 = 0;

D SDiscardObj Handl e(d sHandl e_T);
dsHandle T = 0;

singleX = 0;
QuitUserInterface (0);
break;

return 0;



Basestation Code

// This code launches a data socket connection on the local host upon start up the initial
//connection is for Labview to send the parameters number of bits to encode so that the
//variables and the array lengths can be initialized. The code then waits for labview to
//send the random data packet. Upon receiving the data the code will encode the data
//and send the data back to Labview.

#include
#include
#include /* Needed if linking in external compiler; harmless otherwise */
#include
#include
#include "ecoder.h"
#include "dataskt.h"
#include "cc.h"

int N; // sizeof of encoded bits
int *txc; //encoded bits array pointer

static int panelHandle;
static DSHandle dsHandle;
static DSHandle dsHandle 2;
static DSHandle dsHandle T;
//static DSHandle dsHandle V;









static int singleX = 0;
static int no~of_params = 1;
static int data size; //size of information bits
static int params[1]; //this holds the initial parameters Rid and data~size
int old~data~size = 0;
int initial_open = 1;
double *rdata;
double *tdata;

st table *state tbl;

/* This is the callback function for the DataSocket */
void DSCallback (DSHandle dsHandle, int event, void *pUserData);
void DSCallback_2 (DSHandle dsHandle_2, int event, void *pUserData);

/* user interface loop */
int main (int argc, char *argy[])

if (InitCVIRTE (0, argy, 0) == 0) /* Needed if linking in external compiler; harmless
otherwise */
return -1; /* out of memory */
if ((panelHandle = LoadPanel (0, "ANALYZE3.uir", PANEL)) < 0)
return -1;

state~tbl = read st tbl("c:\\conv1 .st",30);

DisplayPanel (panelHandle);

DS_Open ("dstp://localhost/initialize", DSConstReadAutoUpdate, DS Callback,
NULL, &dsHandle);
// DS_Open ("dstp://localhost/valid", DSConstWriteAutoUpdate, NULL, NULL,
&dsHandleV);

RunUserInterface ();
return 0;


/* When the Quit button is pressed, call Close and Quit */
int CVICALLBACK QuitBtn (int panel, int control, int event,
void *callbackData, int eventDatal, int eventData2)

switch (event) {
case EVENT CONIMIT:
if (dsHandle) {
D SDisc ard Obj Handl e(d sHandl e);
dsHandle = 0;












if (dsHandle_2) {
D SDiscardObj Handl e(d sHandle_2);
dsHandle 2 = 0;

D SDiscardObj Handl e(d sHandl e_T);
dsHandle T = 0;



singleX = 0;
QuitUserInterface (0);
break;

return 0;



/* This is the callback that fires whenever the initializing data or status is updated */
void CVICALLBACK DSCallback (DSHandle dsHandle, int event, void *pUserData)

RESULT hr = S OK;
double singleFloat;
char message[1000];
char *URL;
unsigned int sz;
unsigned type;
// double valid = 0;

switch (event) {
case DS EVENT DATAUPDATED:

hr = DS_GetDataType (dsHandle, &type, NULL, NULL);
if (type & CAVTARRAY) {
hr = DS_GetDataValue (dsHandle, CAVTINT|CAVTARRAY, params,
no_of_params~sizeof(double), &sz, NULL);

data~size = params[0];

if (data~size != old_data~size) {
if (initial_open == 0) {

DeleteTableRows (panelHandle, PANEL_TABLE, 1, old_data_size);
DeleteTableColumns (panelHandle,
PANEL TABLE, 1, 1);











}else { //If data~size changes and it is the initial run
just open the connection

DS_Open ("dstp ://localhost/encode"',
DSConstReadAutoUpdate, DSCallback_2, NULL, &dsHandle_2);

DS_Open ("dstp ://localhost/encoded",
DSConstWriteAutoUpdate, NULL, NULL, &dsHandle_T);

initial_open = 0;

}else { //If Rid did not change then just delete the
//tables. This is not necessary when you get rid of the tables.


DeleteTableRows (panelHandle, PANEL_TABLE, 1, data~size);
DeleteTableColumns (panelHandle, PANEL_TABLE, 1, 1);


old data size = data size;

rdata = (double *) calloc(data~size,sizeof(double));

// DS_SetDataValue (dsHandleV, CAVTDOUBLE, &valid, 0, 0);

//Create the rows and columns that are necessary. 2 rows and 2
columns of string type cells.
InsertTableRows (panelHandle, PANEL_TABLE, 1, data~size,
VAL_CELLUMERIC);
InsertTableColumns (panelHandle, PANEL_TABLE, 1, 1, VAL_CELLUMERIC);


hr = DS_GetDataValue (dsHandle, CAVTDOUBLE, &singleFloat,
sizeof(double), NULL, NULL);
if (singleX >= no_of params)
singleX = 0;
params[singleX] = singleFloat;
singleX++;
sz = singleX;


return;
break;
case DS EVENT STATUSUPDATED:









hr = DS_GetLastMessage (dsHandle,
if (SUCCEEDED(hr))
SetCtrlVal (panelHandle, PANEL_


message, 1000);

STATUS, message);


break;


return;


/* This is the callback that fires whenever rdata or the status of the rdata connection is
updated */
void CVICALLBACK DSCallback_2 (DSHandle dsHandle_2, int event, void
*pUserData)

RESULT hr = S OK;
double singleFloat;
char message[1000];
unsigned int sz;
unsigned type;
1 nt i;
int *txb;
// double valid=1;

switch (event) {
case DS EVENT DATAUPDATED:

hr = DS_GetDataType (dsHandle_2, &type, NULL, NULL);
if (type & CAVTARRAY) {
hr = D S_GetD ata~ralue (d sHandle_2, CAVTDOUBLE|ICAVTARRAY,
rdata,
data~size" sizeof(double), &sz, NULL);

//Insert the array of strings into the table.
SetTableCellRangeVal s (panelHandle, PANEL_TABLE,
MakeRect (1, 1, data~size, 1), rdata, //this was just to show the transmitted data in the
table.
VALROWMAJOR);


txb =
for (iI


(int *) calloc((int)data~size, sizeof(int));
=0;i<(int)data~size;i++)
txb[i] = rdata[i];


N = trellis_enc(state tbl,(int)data~size,txb,&x)
free(txb);

tdata = (double *) calloc(N+1 ,sizeof(double));










tdata[0] = N;
for (i= 0;i tdata[i+1] = txc[i];

DS_SetDataValue (dsHandle_T, CAVTDOUBLE | CAVTARRAY,
tdata, N+1, 0); //this writes the tdata array to labview
// DS_SetDataValue (dsHandleV, CAVTDOUBLE, &valid, 0, 0);

free(txc);

} else {
hr = DS_GetDataValue (dsHandle_2, CAVTDOUBLE, &singleFloat,
sizeof(double), NULL, NULL);
if (singleX >= data~size)
singleX = 0;
rdata[singleX] = singleFloat;
singleX++;
sz = singleX;


return;
break;
case DS EVENT STATUSUPDATED:
hr = DS_GetLastMessage (dsHandle_, message, 1000);
if (SUCCEEDED(hr))
SetCtrlVal (panelHandle, PANEL_STATUS_2, message);

break;

return;


/* Call DSDiscardObjHandle when the Disconnect button is pressed */
int CVICALLBACK OnDisconnect (int panel, int control, int event,
void *callbackData, int eventDatal, int eventData2)

switch (event) {
case EVENT COMMIT:
SetCtrlVal (panelHandle, PANEL_STATUS, "Unconnected.");
SetCtrlVal (panelHandle, PANEL_STATUS_2, "Unconnected.");
if (dsHandle) {
D SDisc ard Obj Handl e(d sHandl e);
dsHandle = 0;









if (dsHandle_2) {
D SDiscardObj Handl e(d sHandle_2);
dsHandle 2 = 0;

D SDiscardObj Handl e(d sHandl e_T);
dsHandle T = 0;


singleX = 0;
break;

return 0;


/* when the panel is closed, close the connection and exit */
int CVICALLBACK PanelCallback (int panel, int event, void *callbackData,
int eventDatal, int eventData2)

switch (event) {
case EVENT CLOSE:
if (dsHandle) {
D SDisc ard Obj Handl e(d sHandl e);
dsHandle = 0;

if (dsHandle_2) {
D SDiscardObj Handl e(d sHandle_2);
dsHandle 2 = 0;

D SDiscardObj Handl e(d sHandl e_T);
dsHandle T = 0;

singleX = 0;
QuitUserInterface (0);
break;

return 0;




Multi-Dimensional Parity Check Code

/* Multi-dimensional parity check code
* 1/23/01 T. Wong
* group all core routines together









#define INF 1.0e90
#define Dmax 11

void addexinfo(int N,double *si,double *ex,double *so,int zero,int negative)

1 nt i;
double *ptl,*pt2,*pt3;


pt1 = si;
pt2 = ex;
pt3 = so;
if (zero)

if (negative)


for (i=0; i *(pt3++) =- *(ptl++);



for (i=0; i *(pt3++) = *(ptl++);


else
{


else


if (negative)
{


for (i=0; i *(pt3++) = *(ptl++) *(pt2++);



for (i=0; i *(pt3++) = *(ptl++) + *(pt2++);


else


void harddec(int K,double *in,int **out,int printflag)

int i,*pt2;
double *ptl;

pt1 = in;
pt2 = *out = (int *) malloc(K" sizeof(int));