Adaptive Wireless Transmission System

(1)

Independent Project in Electrical Engineering Adaptive Wireless Transmission-System

Author:

Elias Ericsson Supervisor:

Mikael Sternad

TVE-E; 19007

Examinor - Mikael Bergkvist, Subject examiner - Mats Ekberg Uppsala University, June 22, 2019

(2)

Abstract

This project centers around creating a wireless transmission system for mobile devices like drones or bikes to transmit data to a receiver. Wirelessly sending data can create errors in the received information. By changing transmitter settings and filtering the received data the output’s error probability can be decreased.

Using an evaluation board, transceivers and coding in MatLab the final product could transmit logged gps coordinates and display them as a path on a graph.

(3)

Introduction

The field of radio frequency is practised in science at most universities today but it wasn’t many years ago that the field of radio frequency skyrocketed. We went from transatlantic communication to the high speed wifi and 4G phone systems of today in a short period of time. The advancement has brought great tools to our everyday lives and industries. Today’s technology combines multiple users with broadband transmission which would have astonished us 20 years ago. In the picture underneath a swarm of Intel LED drones communicate and maneuver together to create an image of our planet in the sky.

Thank you to the supervisor of this project, Mikael Sternad, and thank you to Ping Wu for contributing with hardware. Information regarding wiresless transmission was gathered from the book Wireless Commu- nications by Andrea Goldsmith [1].

Figure 1.1: LED lights on Intel drones on July 15, 2018.

(5)

1.1 Purpose

The outline of this project was to assemble a wireless transmission-system connected to a sensor or tracker, and to build an infrastructure to showcase how it could be built into a product model. The transmitter part, attached to a drone or an automated lawn mower, would emit a signal containing its current data such as gps coordinates or altitude. The receiving module reads the signal and displays or saves the transmitted data. Wireless transmission introduces disturbances in its signals, especially during movement, which alters the received data. There are ways of minimizing this noise by changing the transmitters settings and there are ways of minimizing the impact of it by filtering the received data.

A final product could be a system that relays the real time gps coordinates of one or more automated com- bine harvester to its controller unit which in turn calculates their routes on the fields for best efficiency and safety. In this project a few stages of this system were tested, from a gps tracker to the received data that can be displayed or logged into a system. Factories are becoming more and more dependant on machines and these machines often require wireless communication with each other or a base station to work efficiently and without interruption.

Systems like these are used all over the world in business, factories and in peoples homes. A company buying machines for their factory might find themselves stuck between not having all the features they need or paying for a lot of unnecessary ones by upgrading to another tier of the product. A third party transmission-system would allow them to add the sensor or feature needed while paying for the cheaper product and ending up with the features required at a lower price. An effective and efficient solution would be very profitable for an electronics company if done correctly. Therefore the secondary motive to creating a functional system is to conserve energy in the transmitter, as it is often attached to a moving object running on a battery. In figure1.2a flowchart displays how a typical transmission system could be designed.

Figure 1.2: Typical flowchart of expected system

(6)

Chapter 2

Procedure

The scope of the project is quite large and only portions will be operational and tested. In combination with the parts that were created and tested there were a lot of ideas that could be implemented in the future.

The parts that were built and tested had to be made with these ideas in mind. The procedure of this project was threefold, the first stage was testing the transmission system and how it worked. The second stage was creating a code in MatLab simulating the scenario of reading, sending, receiving and filtering gps coordinates. The third and last stage was to apply the code and using the transmission setup hardware to test the system. During stage two and three a lot of ideas were discussed, their input and output requirements as well as their purpose had to be taken into consideration when creating other parts of the system even though they weren’t actually developed.

2.1 Transmission test

The transmission hardware used was a set of transceivers and evaluation boards from Texas Instruments.

Transceivers CC2520EM [2] and CC1120 were good candidates for the tasks but due to the simplicity of the CC2520EM it was used throughout the project. Connected to the Transceiver Evaluation Board rev1.7 [3]

and through USB to a computer running SmartRF studio 7.0 the transmission could be tested. A feature already implemented in the CC2520EM and SmartRF studio called "Continuous TX/RX" was used to create graphical representations of signal strength over time. A few different environments were tested and documented. A standard test were the receiver and transmitter were stationary and in line of sight of each other was done first and gradually the test-conditions were made worse. The last test was done by having the transmitter enter a moving elevator.

(7)

2.2 System design

While being very user friendly the chosen transmission system was also constricting. Without extended knowledge of coding and this type of hardware the length of the transmitted data was confined to a 128 character long hexadecimal message which would then manually have to be changed to transmit the next set of data. This removed the option of real time transmission but not the first or secondary goal of the project.

The data used for testing were GPS coordinates, longitude and latitude. The first dataset was taken from the homepage GPSVisualizer.com and used for software testing without wireless transmission. For live testing through the transmission system and app called GPSLogger v102 [4] for android was used to log GPS coordinates to a phone while riding a bike through town. The app logs GPS coordinates once every time interval and saves them to a GPX file that can be read as a text document or read by the MatLab software through its Mapping toolbox. MatLab is good at handling matrices and was the software used for encoding, decoding, reading and writing files.

To create the 128 long hexadecimal messages a script was created. It read the GPX file, extracted the interesting information and then created a long string with longitude and latitude values. The string was then translated to hexadecimal numbers and divided up to the appropriate sizes for transmission. In this case the optimal sending structure ended up being 39 sets containing 6 hexadecimal numbers each. The document’s content was transferred into SmartRF studio and sent from the transmitter to the receiver one part at the time. A feature in SmartRF studio allowed the data to be saved to another text document. Unfortunately this document was not standardized, as the GPX file was, and the scanning of the received data had to be manually scripted with MatLab’s file scanning capabilities.

With the encoding scripts settled a decoding script could be created to retain decimal values from the received hexadecimal strings. The received data could now be translated and displayed as a graph next to the original data from the GPX file. The first goal of the project was now reached and the secondary motivate of reducing noise and power consumption was addressed.

The CC2520EM gave the ability to change the power of the transmitted signal from -18 to +5 dBm. When the transmitter sends a signal it reads the input and matches each sign to a map, in this case a hexadecimal map. The receiver then tries to match the incoming signal to the same map to determine what was sent.

Having a noisy signal could make the receiver assign the signal to the incorrect value on the map. Increasing the power used to transmit the signal increases the part of the received signal that is not noise and the receiver will have an easier time finding the correct values. Changing the power levels required an interruption of the transmission so a different method was introduced to portray the consumption of energy and noise levels. While the smart RFstudio was restricted in the length of the data that could be sent in succession without a reconfiguration it did have the ability to send multiples of the same message. Sending the same message more than once can be both a hardware and a software solution to reduce noise. The regulatory factor of consuming energy to reduce noise became based on how many samples of the same signal that were sent. This also opened up for sending many more samples than needed and then only reading the amount assigned for different tests.

Two ways of reading multiple samples of the same string, with eventual errors spread out through the messages, were developed. The first one was calculating the mean of the strings and presenting it as the final message. The second one was to find the string that was most common of them and use that one as the final message.

(8)

There are many ways of filtering the data stream that gets transmitted, a lot of them were discussed and tested and a few of them were implemented into the final case. The noise applied to the signal was added on top of hexadecimal numbers divided into separated parts which means that an error of one step on the hexadecimal map could return either an error at the sixth decimal point of the longitude or latitude value or it could change the value from the first digit of a value and move the location from one side of the earth to the other. A filter was developed to deal with these kinds of errors.

The data related filter did its filtering based on the information that was sent, not based on the transmission information. It was an iterative function made to remove all GPS coordinates that were unreachable based on the position of the last received coordinates. The GPS coordinates done for live testing were logged when riding a bike and therefore the speed of which it would move should never go above a threshold, above 20m a second was assigned as an absolute error. This introduces a problem in the case of the first message being corrupted and so the UpLink message was created, which will be mentioned later on. With UpLink implemented the filter could be certain that the first value was correct and could continue to throw away values that are out of reach. This filter was applied right as the signal was translated from hexadecimal numbers to decimal numbers. It was applied to each single string in the list of repeat transmissions containing the same message as to not interfere with the fore mentioned “most common” technique.

The second part of the filter was written as a way of skipping data points if they were not within the bounds of the filters. If a data point were to surpass the previous noise-reducing techniques the data set would instead wait for the following data point and draw a line between the last accepted one and the one after that, skipping the corrupted ones between them. This prevents the structure of the GPS coordinates from becoming out of phase if they are going to be saved with a timestamp. This filter also requires UpLink to function.

The data related filters are based on comparing values to earlier values. To make sure that the first value is correct, a function called UpLink was created. Adding a segment to transmit before the stream of data, containing only the first value of longitude and latitude. The UpLink was sent in 39 hexadecimal numbers including a filler bit to balance the numbers, the same amount of numbers as every other segment. This established the first coordinate with high accuracy so that the filters could function as intended afterwards.

The UpLink function creates a delay in the system and could be seen as a start-up time which most technology already have today so it wouldn’t be noticeable.

With the filters applied, a full test of the system was conducted. The data from the bike ride was encoded and put into a TX input file, transmitted and received. Once received the data was decoded and filtered and then plotted as the result. Gradually worsening the environment used for each test to find the breaking point of the combined safety mechanisms.

These four points are what the decoding of the received signal goes through before the result is presented as a plot.

• Transmission filter, removal of strings with incorrect number of values.

• Data filter, removal of strings with outrageous values.

• "Mean" or "most common" technique to evaluate repeat transmission.

• Data filter, skipping data sets that were removed to generate a readable result.

(9)

Chapter 3

Results

The transmission tests were done in and around an apartment building. Figure 3.1 shows the results of each test. The receiver was always stationary and the transmitter’s placement and movement was changed depending on the test. The magnitude measured was signal strength in decibel-milliwatts, or dBm for short.

The dBm is not shown in the result as it was only the relative change in magnitude that was interesting.

1. Stationary test with clear sight between the transmitter and receiver.

2. Distance test, the transmitter was moved about 20 meters away and then back towards the receiver.

3. Entering and exiting a metal plated elevator with the receiver.

4. The transmitter was kept about 5 meters away and moved slightly around objects.

5. The transmitter was moved back and forth through an apartment to create heavy noise.

6. The transmitter was moved up and down a flight of stairs and into a corridor of a concrete building.

Figure 3.1: Graphic representation of transmission tests.

(10)

3.1 Transmission system test

Using the gps visualizer homepage the logged bike ride could be displayed on top of a map and was confirmed as correct. The ride was a two way trip and to visually display the data easier on a map only one was used in testing. The GPX file used was 249 seconds long and had a vector of data containing longitude and latitude for each one second interval. The GPX file is attached to the files accompanying the report. Here you can also see that the start and end values, furthest to the left, has a lot of unpredictable behaviour. This is due to the phones gps reader needing time to configure where it is before it can give more accurate data and it being bad at tracking targets that are staying still.

Figure 3.2: Visual of GPX file.

For a visually pleasing and easy to work with data the vectors used in the tests were from number 32 to 135, making it a 103 seconds long path out of the 249 long GPX file. Plotting this in MatLab shows a slightly stretched but accurate path drawn from the GPX file. The first test done was sending one of each line of data once, with the transmission at max energy and clear sight to find a successful and noise free first result.

This was done without any filters or self made techniques applied.

(11)

Figure 3.3: Successfully transmitted noise-free coordinates.

Running the same test again with lower power settings, further away and moving the transmitter during transmission created errors that made the data completely unreadable from the graph. In figure3.4an error struck on the hexadecimal number carrying the most significant value of a coordinate.

Figure 3.4: One error creating huge differences.

(12)

The method of sending multiple signals of the same segment of code, repeat transmission, was tested internally in MatLab by manually altering the hexadecimal documents generated from the earlier tests. The result of sending a segment more than once and taking the mean of the received signals did increase accuracy but only decreasing errors and not removing them. An error applied to the signal would always impact the final data in some way. The technique of transforming multiple segments of the same data into one by picking the most common one of them was used instead. In cases where the correct string of data came through most times, it was picked as the final data. In the cases where more strings containing errors than not came through the system would still pick the correct string unless the errors had been applied in exactly the same way to each separate segment sent. Only in cases where the correct string didn’t come through more than once is where it failed to find the correct string. It would still be possible to generate signals that would create errors even with many correct strings received. This increased the chance of finding the correct data by a large margin and the risk of errors striking the sequentially sent data in the exact same way seemed low. For tests with five or more transmissions of the same segment the system managed to remove almost all errors. At two, three or four repeat transmissions the system still performed but at a lesser rate. It would sometimes get stuck trying to find the most common value when there were no multiples of the same string.

Errors here would be of the same kind as the one in 3.4. The tests of this filter were done by altering the already correctly transmitted documents from before, internally in MatLab.

the

The more data related filter was applied. The gpx file was generated by biking through town so an absolute maximum speed was decided to be 20 meters per second. This restriction coefficient was applied to the data related filter and it removed all data sets that had an increase in speed over the limit allowed. This was tested in the test environment in MatLab and when applied without a repeat transmission system its performance would not correct errors. In contrary to errors ending up like3.4it would remove the error and skip that data set. In 3.5 two errors big enough to trigger this filter were removed and the received data draws the route between the data points that do pass the filter instead, creating a more accurate picture than3.4.

Figure 3.5: Errors removed by data related filter.

(13)

The final test was to go through the whole system, from a logged GPX file to a graph of the transmitted coordinates in MatLab. All the received data is attached in the project file including a few versions that are not mentioned here as they didn’t give any new information. To run this test all segments were sent with 100 repeat transmissions and then shortened to the desired length. The first transmission was made in considerably good condition, comparable to number 4 in figure3.1.

Reading the complete segments with all 100 packages each, excluding the ones received at different length, the gps coordinates could be found without error. The system managed to remove any error even when reducing the number of packets of each segment. Only when manually picking the worst ones errors could be found. Figure 3.6shows the transmitted data and table 3.1 shows transmit and error rates. The package error contains both corrupted packages that were received and the packages not fully transmitted and therefore thrown away. Somehow the 5th segment managed to receive 91 correct packages and 10 corrupted ones from the 100 originally sent, this was checked twice.

Figure 3.6: Successful system test.

Table 3.1: Error data of first test transmission.

Segment Correct packages received Corrupted packages received Package error

UpLink 92 7 8%

1 92 7 8%

2 92 7 7%

3 91 7 9%

4 89 7 11%

5 91 10 9%

6 89 7 11%

(14)

The next transmission test was done multiple times and was created in the same manner as number 5 in figure3.1. The error rates of the 100 packages of each segment can be seen in table 3.2 and notably it is much worse than in previous tests.

Table 3.2: Error data of second test transmission.

Segment Correct packages received Corrupted packages received Package error

UpLink 42 18 45%

1 45 19 55%

2 41 21 59%

3 45 22 55%

4 36 31 64%

5 44 29 56%

6 39 22 61%

Keeping all 100 packages of each segment the GPS coordinates were fully recovered. Keeping only five of the packages from each segment shows how the filters function of skipping data sets is working. Figure3.7 displays this well, the received data contains errors above the threshold of the filter so they are skipped and don’t get to have a big impact. A test of three packages of each segment gave the same result but with corrections needed in more areas. The result of this test is shown in figure3.8. To find the breaking point of the filter a worst case scenario was created by manually picking bad packages from the original 100 of each segment.

In figure3.9the resulting faulty path is displayed. In the start the filter manages to correct the data some- what but after a burst of errors the system fails and the filter isn’t allowing any more values to come through.

Figure 3.7: 5 packages of each segment.

(15)

Figure 3.8: 3 packages of each segment.

Figure 3.9: Worst case scenario.

(16)

Chapter 4

Discussion

4.1 Current System

Transmission tests were done in the early stages and they provided interesting knowledge of wireless connectivity of the CC2520EM. A product built with these guidelines would have to have specified hardware which would have different connectivity characteristics and be applied in a specific environment different to what was tested. This test was a way to show how transmission hardware and environment would be tested to be able to pick suitable hardware for a specific task.

The option to skip data sets that are incorrect is great as it doesn’t ruin the visual picture that we use to measure the success of our tests. However, in many applications it would be unacceptable to remove a data set, or not interesting enough to approximate it in the first place. Depending on application this would have to be solved in different manners. For real time use of the data a system would have to be built with a higher standard of transmission to reduce the risk of data corruption. If the information in an application that is transmitted is not used instantly and is allowed a time delay then the data could be stored on the transmitter’s side until a better connection is established.

To logically equalize the techniques of changing power consumption, increasing transmit-power and repeat transmission, was a great tool to display the projects second motive of conserving energy while retaining a specific performance level. Sending 100 of each signal and saving the text files also allowed for testing in MatLab without having to re-transmit every time a new feature was applied. In addition this gave the data related filter and the "most common" technique the same data with the same error probability to work with.

Most wireless electronics have some boot time implemented which means the time for the UpLink to establish the correct starting values would probably not be noticed. The UpLink could also act as a reset button, where if you lost connection completely you could resent and recalibrate with the UpLink function. We saw an example of this issue in figure 3.8 where the path stops about a third of the way through. This is due to the filter trying to read previous, accepted, values to determine if the next value is valid. When a lot of values in a row have been corrupted the last correct position is further away from the next correct value than the filter accepts, 20m as it is now. A way of solving this would be to have the filter reset and re-transmit the UpLink. If communication on the opposite direction isn’t available in any way then the problem could be solved by adding 20 meters acceptance to the filter each time a data set is removed. Until a correct one is found and the filters coefficient is reset. This would create a larger error acceptance but it would allow the path to find its way back on track. Another way of solving this would be to add a function that removes the filter after a specific number of filter-removed data sets and then apply it back once it found a valid data set.

(17)

What is missing compared to a potential final product? If this was to be presented to a electronics company it would be as an idea of how to build a full system, the hardware currently used would not be optimal and the codes would be less volatile and more specific for its task. To design a system for a particular task would require a lot of information.

What data is being sent, how important is error probability?

What environment and what are the transmission conditions?

What power and capacity does the transmitter have if attached to something running on battery?

What processing capabilities and delay acceptance would the receiver have?

These four basic questions would shape the proposed product that the company could sell.

4.2 Additionally planned features

The GPS data sent has values with 8 decimal digits and depending on what the transmitter is attached to it would never be able to change the more significant of those digits by moving. A way of sending less data, and thereby saving power, is to remove the first few digits depending on the application. Changing the second most significant value of a coordinate by 1 gives a 120km difference on the map. Depending on the product it could have a region that it always stays in and the significant digits of the coordinates that aren’t changed within that region could be skipped when transmitting.

A function comparatively close to the data related filter, which discovers and removes errors, would be a parity bit. It would be sent as a number in the end of each segment and by calculating information in the data and comparing it to this number, discovering if the data is corrupted or not. This could range from as simple as if the string is correct or not, to a complex calculation of the strings contents. A more complex, and probably more to transmit, parity bit could resolve which parts of the string is corrupted and still keep data that is correct. A function already implemented in Smart RFstudio does the simple version of this and was of great help while building the system and testing features early on. Creating a parity bit function would still be necessary as the built in one wouldn’t always exist on the hardware you buy. Parity bits are very common in wireless transmission and even in wired transmission.

Lets say a system was being planned and the directions were that the system needed to be moderately fast, have low errors and would be tracking a flying drone over a field. We would ask ourselves the four questions mentioned earlier to come up with a solution. As the drone will be flying around it could lose connection from time to time, a good enough transmission would be required to keep the stability above a threshold.

An option that could be added to the product is a more simple transmission in the opposite direction that evaluates the connection strength. If the connection is bad then the power would increase to compensate and if the signal has free sight it would decrease the power to conserve energy. This evaluation could also be done by reading the results at the receiver and transmitting a connectivity rate but this would cause delay and when the power consumption change is applied the drone might have gotten into a position where it is no longer in need of it. In cases where the transmitter is connected to something slower and where maybe weather was creating the change in signal strength the estimation by one way transmission would be easier to implement.

The implemented and tested features were created with these additional features in mind and they could be implemented without altering the already done work. There are endless other ideas that could be applied to reduce noise and to counter the impact of it. The final test with a lot of errors in the transmission was barely readable and had a lot of flaws. Comparing the decoded and filtered data to the received raw data shows a great increase in accuracy and presentability in the first part before the filters drifted too far. With these additional features mentioned above and adaptive powering it might have been a successful transmission as well.

(18)

Chapter 5

Conclusion

As mentioned before the scope of the project is quite large. The first motive of creating a function transmission system and the second motive of reducing error or power consumption were both tested and successful.

The fact that a lot of errors could be removed or negated was good and if presented to an electronics company it would be the main point of the sale. The system is not fully developed by any means, neither was it supposed to be, and the final product that was created is only a stepping stone to show what can be created. It’s proof that a complete system would work and it showcases it’s functionality, it’s limitations and possibilities. Compared to already existing systems our system is majorly flawed and slow but it is a stand alone. It would be used as a guide to build a better system compared to the ones on the market or the ones that come with products today. It’s comparable to a PC where you could buy a fully built and complete system or you could pick the parts you need and have it built with them. For personal use or minor operations the first option does the work in most cases but for mass production or operations where optimization on a large scale is necessary the second option could surpass the first in cost and performance.

Bringing this work to a company today would probably not be very successful but with more development and more built examples it could be picked up as an option. To continue building on this project more filter ideas would have to be applied and more task specific designs would have to be developed and tested.

Putting this on a drone or a boat close to the coast would be very interesting as a test. There would be many differences in these two cases even though they are very alike. The boat has waves around it but moves quite predictably and the receiver at the docs could have an antenna with direction while keeping track of the boat to increase signal strength. In the case of a drone it would be less likely that you could track its position with a parabola shaped receiver. It would also have the ability to go behind things whereas the boat would not. Filters and hardware would differ a lot depending on the task at hand and it would be very interesting to test different cases and develop solutions.

(19)

Chapter 6

References & links

Supervisor on this project was Mikael Sternad.

Addition help regarding hardware from Ping Wu.

[1] Wireless Communications - Andrea Goldsmith.

Publisher: Cambridge India. Published: December 2010 [2] Texas Instruments Transciever evaluation board.

http://www.ti.com/tool/SMARTRFTRXEBK [3] Texas Instruments CC2520EM trancievers.

http://www.ti.com/tool/CC2520EM_REFDES [4] GPSlogger v102.

https://play.google.com/store/apps/details?id=com.mendhak.gpsloggerhl=en