GPS and Sonar Data Collection for Sea Profile Reconstruction

Examensarbete 30 hp

Juni 2014

GPS and Sonar Data Collection

for Sea Profile Reconstruction

Gathering of position and depth data using

currently available marine equipment

Oskar Bernberg

Teknisk- naturvetenskaplig fakultet UTH-enheten

Besöksadress:

Ångströmlaboratoriet Lägerhyddsvägen 1 Hus 4, Plan 0

Postadress:

Box 536 751 21 Uppsala

Telefon:

018 – 471 30 03

Telefax:

018 – 471 30 00

Hemsida:

http://www.teknat.uu.se/student

Abstract

GPS and Sonar Data Collection for Sea Profile

Reconstruction

Oskar Bernberg

The depth information on today’s nautical charts are often inaccurate. This is due to the fact that the data used often is taken from measurements done in the late 1800’s using contemporary methods. With the increasingly widespread use of chartplotters (a marine GPS unit which contains a nautical chart), especially in recreational boats, this has become a big problem.

This project aims to receive and process data from such navigation equipment. The data is processed and transmitted wirelessly to a remote server were the data is used to update current nautical charts. This allows multiple users to collaboratively improve their current navigation possibilities.

A test unit is built using a small linux computer, the Raspberry Pi. The test unit is also equipped with a marine GPS receiver, Garmin x18-5Hz, communication through the serial NMEA interface often used in these applications. As a proof of concept is the unit also equipped with an air pressure sensor, connected through I2C. The current air pressure is calculated to its corresponding altitude, resulting in a simple method for on-land measurements. A way to automatically calibrate offsets in GPS

receiver/echo sounder position is developed and tested using the test unit.

The test unit is capable of combining GPS coordinates and altitude data and sending it to a remote server. Small changes have to be made for the unit to be compatible with multiple GPS recessives and echo sounder. Further development is also needed for multiple users to simultaneously be able to use the system. It is proven that the concept of GPS and sonar data collection is possible for sea profile reconstruction.

Ämnesgranskare: Uwe Zimmermann Handledare: Mikael Palosaari

Djupinformationen i dagens sjökort har ofta dåligt noggrannhet. Detta beror på att djupen ofta är mätta under sent 1800-tal, med dåtidens teknik. Den senaste tidens ökade användning av GPS i samband med navigation till sjöss har visat att dessa föråldrade sjökorts dåliga noggrannhet är ett stort problem.

Detta projekt siktar på att ta emot och behandla data från sådan navigation- sutrustning. När informationen bearbetats skickas den sedan till en server där den insamlade datan kan användas för att rita nya sjökort. Ett sådant system tillåter flertalet användare att samtidigt samla information för att förbättra sina navigationsmöjligheter.

En testenhet har byggts, baserad på en liten linuxdator, en Raspberry Pi.

Testenheten är även utrustad med en marin GPS-mottagare, Garmin x18-5Hz.

Kommunikationen till denna sker via det seriella NMEA protokollet, vilket är standard för många liknande enheter. För att visa att systemet fungerar utrustas enheten även med en lufttrycksmätare. Lufttrycket räknas sedan om till höjd över havet. Detta resulterar i ett enkelt sätt att göra mätningar på land. En metod för att automatiskt detektera avstånd mellan GPS-mottagare och ekolod har utvecklats och testats på enheten.

Testenheten är kapabel att kombinera GPS-koordinater med höjddata och sedan sända denna information till en server. Små förändringar behöver göras i en- heten för att göra den kompatibel med fler GPS-mottagare och ekolod. Viss vidareutveckling behöver göras för att tillåta att flera användare samtidigt sam- lar in data. Det har visats att konceptet med insamling av GPS- och ekolod-data är möjlig.

Contents

1 Introduction 5

2 Theory 5

2.1 GPS . . . 5

2.1.1 Structure . . . 5

2.1.2 Basic Concept . . . 5

2.1.3 Performance . . . 7

2.2 Global Positioning Coordinates . . . 7

2.2.1 Coordinate Example . . . 7

2.3 Distance . . . 8

2.4 Echo sounding . . . 9

2.4.1 Drawbacks and Limitations of Echo Sounding . . . 9

2.4.2 UNESCO Algorithm . . . 9

2.4.3 Transducer Echo Cone . . . 13

2.5 NMEA 0183 interface . . . 14

2.5.1 NMEA Sentence Example . . . 15

2.6 Different Ways to Accomplish Same Measurements . . . 15

2.6.1 Limitations and Drawbacks . . . 16

2.6.2 Different Setups . . . 16

2.7 Data compression . . . 16

2.7.1 Bit, Bytes, Characters & Hexadecimal Representation . . 17

2.8 Test Setup . . . 17

2.8.1 Pressure to Altitude Conversion . . . 17

2.8.2 Low-pass Filtering . . . 18

3 Method 21 3.1 Measurements on Land . . . 21

3.2 Calibration . . . 21

3.2.1 Calibration Algorithm . . . 21

3.3 Data Format and Compression . . . 23

3.3.1 Data Format . . . 23

3.3.2 Compression Efficiency . . . 24

4 Results 25 4.1 Test Setup . . . 25

4.1.1 Serial Interface . . . 27

4.1.2 I²C Interface . . . 28

4.1.3 Daemon . . . 28

4.1.4 IP resolving . . . 30

4.2 Web Server . . . 30

4.3 Low-pass Filtering . . . 32

4.3.1 Kalman Filter . . . 32

4.3.2 1st Order Low-pass Filter . . . 33

4.4 Air Pressure Compensation . . . 33

4.5 Calibration Algorithm . . . 34

4.5.1 Using the Raspberry Pi . . . 36

5.1 Sources of Measurement Errors . . . 38

5.1.1 GPS Positioning . . . 38

5.1.2 Echo Sounding . . . 39

5.1.3 Water Properties . . . 41

5.1.4 Calibration . . . 41

5.1.5 Travelling Speed . . . 41

5.1.6 Low-pass Filtering . . . 42

5.2 Further Development . . . 42

5.2.1 Using Echo Sounder . . . 42

5.2.2 Replace the Raspberry Pi . . . 43

5.2.3 User Identification . . . 43

5.2.4 User Isolation . . . 43

5.2.5 Feedback to the User . . . 43

1 Introduction

The depth information on today’s nautical charts are often inaccurate. This is due to the fact that the data used often is taken from measurements done in the late 1800’s using contemporary methods. With the increasingly widespread use of chartplotters (a marine GPS unit which contains a nautical chart), especially in recreational boats, this has become a big problem. People rely blindly on their chart plotter and disagree safety distance. New data of the sea depth are done regularly by the Swedish Maritime Administration with trained staff to a high cost.

Today, modern boats of reasonably size are often equipped with sonar. These often have standardized interfaces, e.g. NMEA, for connection to the network.

By connecting a device with NMEA-interface, GPS, GPRS connectivity, mem- ory and processing to the sonar, the depth information can be stored in memory and at a suitable time be transferred to a ”Back Office computer” of the agency or organization responsible for the charts.

This project will be about developing a method and a device to measure the depth data. Another project will take place where the data is analysed.

2 Theory

2.1 GPS

GPS is short for Global Positioning System, which is a navigation system that accurately can determine the position of a receiver on or near the Earth’s sur- face. The Global Positioning System consists of a constellation of satellites, maintained by the United States government.

2.1.1 Structure

The constellation of GPS satellites fly in medium earth orbit, at approximately 20,200 km. This means that they will orbit the earth twice a day. To ensure that a user can acquire a position anywhere on the planet, at least 4 satellites has to be visible from that point. Therefore a total of 24 satellites has to be operational to completely cover the Earth’s surface. However in 2011 the Air Force expanded the constellation with 3 more satellites. As a result, the GPS system now operates with 27 satellites with improved coverage. The United States is committed to maintain those satellites and make sure that the system is fully functional, with at least 24 satellites, more than 95% of the time [1].

2.1.2 Basic Concept

To be able to calculate a position in one dimension, on a straight line, one has to know the distance to two or more points on the line. A point in two dimen- sions, on a plane, is defined by the distance to at least three points. The same goes for three dimensions, four dimensions and so forth. The number of known distances and fixed points has to be at least one more than the dimensions of the room in which one wants to know its position.

in figure 1, for convenience only the two dimensional case is shown.

Figure 1: Two positions on a plane defined by only two satellites.

Figure 2: Three satellites defining a single point on a plane.

In this case, at least four GPS satellites are used as fixed points to calculate the receiver’s position in a three dimensional space. As mentioned before, three points can give a position on a plane. This can be used for boats, where there height above mean sea level often are well known. As seen in figure 1, two satellites are not enough to obtain a definite position on a plane. In three di- mensions each circle is represented as sphere, with a radius of equal distance to the satellite. Those spheres intersect in a single point, the receivers location.

Each satellite continuously sends messages to the receiver. Every message con-

position at that time. Even though the messages travel from the satellite to the receiver at the speed of light, the time dilation and therefore the distance, can be calculated. This results in a satellite that is capable of global positioning and also doubles as a precision clock [3].

2.1.3 Performance

The performance and accuracy of the GPS system may vary depending on the receivers surroundings. However there is a theoretical maximum accuracy that can be obtained, limited by how often new time data is sent from each satellite.

In an open area, such as at sea, a receiver can get a position with 4 meters root mean square accuracy [2]. Some GPS receivers claim to be far more accurate than this theoretical limit. This is possible due to built in algorithms in the receivers. The algorithms may be based on persistence of the boats speed and direction. Some receivers even use additional sensors like accelerometers, gyro- scopes and compasses to capture the boats movements. A GPS receiver that are able to further improve the position given by the satellites often outputs an estimated error together with its current position.

In this report, the coordinates received from the GPS will always be considered accurate, even though they are not. No filtering will be applied and persistence of movement will not be concluded either. As mentioned earlier, different GPS receivers will be able to calculate and output different data. If there is accuracy data present, it will be sent to the database, otherwise some accuracy will be estimated based on number of active satellites.

2.2 Global Positioning Coordinates

The coordinates for position on the earth’s surface in expressed in latitude and longitude. Latitude specifies the north-south position and longitude the east- west position, with north and east as the positive direction in both cases. For the north-south position, the equator is placed at zero degrees and the north and south poles at +90 and -90 degrees respectively. The same goes for the east-west position, ranging from +180 to -180 degrees, with it’s zero as the Prime Meridian. There are three common ways to denote those coordinates.

Either they are written as decimal degrees (DDD), degrees with decimal minutes (DMM) or as degrees with minutes and seconds (DMS). A full circle is divided in 360 degrees, each degree is 60 minutes and each minute 60 seconds.

2.2.1 Coordinate Example

Latitude Longitude Decimal degrees 59.838516^◦ 17.647412^◦

GPS 59^◦50.311⁰ N 17^◦38.845⁰ E Degrees, minutes and seconds 59^◦50⁰18⁰⁰N 17^◦38⁰50⁰⁰ E

Table 1: Same coordinates written as decimal degrees, as degrees with decimal minutes and as degrees with minutes and seconds.

The distance between two points on the outside of a sphere is calculated by using the haversine formula.

haversine d R



= sin² θ2− θ1

2



+ cos(θ1)cos(θ2)sin² λ2− λ1

2

 (1) Where d is the distance between the points and R is the Earth’s radius. Solving for d requires the use of the inverse haversine, which is defined as

haversine⁻¹(h) = 2sin⁻¹(√

h) (2)

resulting in

d= 2Rsin⁻¹ s

sin² θ2− θ1

2



+ cos(θ1)cos(θ2)sin² λ2− λ1

2

! (3)

Using the earth’s radius, R = 6, 371km [5], d equals the distance between the two coordinates denoted with θ and λ for latitude and longitude respectively.

In this report, only small distances will be considered. The distance between two points will only be used to approximate the distance travelled within small areas. If the assumption of a flat earth is made, the distance is approximated by pythagoras theorem. The distances x and y are calculated by

x= 2Rπ

360(θ2− θ1) y= 2Rπ

360(λ2− λ₁)cos(θ1) (4)

resulting in

d= Rp

x²+ y²= 2Rπ 360

r

(θ2− θ1)²+(λ2− λ1)²

2 (cos(2θ) + 1) (5) Where θ is either equal to θ1or θ2. By using the Taylor series of cos(x),

cos(x) =

∞

X

n=0

(−1)ⁿ

(2n)! x²ⁿ= 1 − x² 2! +x⁴

4! −x⁶

6! + . . . (6) the use of trigonometric functions can be completely eliminated. This speeds up the calculation but introduces a small error. This is preferable, since the calculation will be done many times but without the need for high precision.

Combining equation 5 with the Taylor series four first terms, results in

d= R s

(θ2− θ1)²+ (λ2− λ1)²



1 − θ²+θ⁴ 3 −2θ⁶

45



(7)

where θ and λ has been converted to from degrees to radians.

2.4 Echo sounding

Echo sounding is a type of active sonar used, in most cases, to measure the water depth. The depth is measured by transmitting pulses into the water, cre- ating a wave moving towards the bottom. After hitting the bottom, the wave is reflected and travels back to the transmitter. By measuring the time between the transmission and when the echo is received, the depth can be calculated using the speed of sound in water (approx. 1500 m/s [5]).

Marine equipment for echo sounding operates at different frequencies depending on the depth. When measuring shallower areas, up to 100 meters, a high fre- quency transducer may be used to increase accuracy. Typically pulses around 200 kHz are used. Lower frequency waves will be able to penetrate the water further distances and are therefore used when measuring water deeper than 100 meters. These echo sounders often operates at 24-33 kHz.

2.4.1 Drawbacks and Limitations of Echo Sounding

Even though echo sounding is simple, in theory, it does not come without it’s drawbacks. As mentioned in section 2.4, the depth is measured using the speed of sound in water. One problem that arises is that the speed of wave propaga- tion, through any material, depends on its density. There are many things that has an effect on the density of the seawater; pressure, temperature and salinity are the most noticeable. For the speed of sound in any liquid, the following holds:

cf luid= sK

ρ (8)

where K is the bulk modulus of the fluid, and ρ the density. In addition to equation 8, an expression for ρ and K based on pressure, temperature and salinity is needed. These parameters have a rather complex relation to each other. The pressure of the water depends on the density, which in turn depends on the temperature and salinity. Even the bulk modulus, K, changes depending on the same parameters. This is a well studied problem and an international standard algorithm has been developed. It is known as the UNESCO algorithm and was first mentioned 1983 by Fofonoff and Millard [6].

2.4.2 UNESCO Algorithm

The UNESCO algorithm consists of a multiplication of several polynomials with a total of 42 coefficients. In 1995 some of the coefficients was recalculated for adaptation to the International Temperature Scale (ITS-90) [7]. The latest form of the UNESCO equation is:

c_water(S, T, P ) = Cw(T, P ) + A(T, P )S + B(T, P )S^3/2+ D(T, P )S² (9)

Cw(T, P ) =(C00+ C01T+ C02T²+ C03T³+ C04T⁴+ C05T⁵)+

(C10+ C11T+ C12T²+ C13T³+ C14T⁴)P + (C20+ C21T+ C22T²+ C23T³+ C24T⁴)P²+ (C30+ C31T+ C32T²)P³

(10)

A(T, P ) =(A00+ A01T+ A02T²+ A03T³+ A04T⁴)+

(A10+ A11T+ A12T²+ A13T³+ A14T⁴)P + (A20+ A21T+ A22T²+ A23T³)P²+

(A30+ A31T+ A32T²)P³

(11)

B(T, P ) = B00+ B01T+ (B10+ B11T)P (12)

D(T, P ) = D00+ D10P (13)

,T is temperature in degrees Celcius, S is salinity in parts per thousand and P is pressure in bar. The UNESCO algorithm outputs the speed of sound in water, depending on the three parameters mentioned in section 2.4.1. This equation is valid for temperatures of 0 to 40 ^◦C, a salinity of 0 to 40 parts per thousand and a pressure of 0 to 1000 bar [7].

Coefficient Numerical value Coefficient Numerical value

C00 1402.388 A02 7.166 × 10⁻⁵

C01 5.03830 A03 2.008 × 10⁻⁶

C02 −5.81090 × 10⁻² A04 −3.21 × 10⁻⁸ C03 3.3432 × 10⁻⁴ A10 9.4742 × 10⁻⁵ C04 −1.47797 × 10⁻⁶ A11 −1.2583 × 10⁻⁵ C₀₅ 3.1419 × 10⁻⁹ A₁₂ −6.4928 × 10⁻⁸

C₁₀ 0.153563 A₁₃ 1.0515 × 10⁻⁸

C₁₁ 6.8999 × 10⁻⁴ A₁₄ −2.0142 × 10⁻¹⁰ C₁₂ −8.1829 × 10⁻⁶ A₂₀ −3.9064 × 10⁻⁷ C₁₃ 1.3632 × 10⁻⁷ A₂₁ 9.1061 × 10⁻⁹ C₁₄ −6.1260 × 10⁻¹⁰ A₂₂ −1.6009 × 10⁻¹⁰ C20 3.1260 × 10⁻⁵ A23 7.994 × 10⁻¹² C21 −1.7111 × 10⁻⁶ A30 1.100 × 10⁻¹⁰ C22 2.5986 × 10⁻⁸ A31 6.651 × 10⁻¹² C23 −2.5353 × 10⁻¹⁰ A32 −3.391 × 10⁻¹³ C24 1.0415 × 10⁻¹² B00 −1.922 × 10⁻² C30 −9.7729 × 10⁻⁹ B01 −4.42 × 10⁻⁵ C31 3.8513 × 10⁻¹⁰ B10 7.3637 × 10⁻⁵ C32 −2.3654 × 10⁻¹² B11 1.7950 × 10⁻⁷

A00 1.389 D00 1.727 × 10⁻³

A₀₁ −1.262 × 10⁻² D₁₀ −7.9836 × 10⁻⁶

Table 2: Coefficients for the UNESCO algorithm, calculated by Wong and Zhu 1995 [7].

Equation 9 and 10 through 13 with the coefficients from table 2 gives the speed of sound in water for the specified parameters. The pressure at a certain depth is calculated by:

P= dρg (14)

where d is the depth, ρ is the density of the water and g is the earth’s acceleration of gravity. Since this report mainly focuses on shallow water, with depths up to three meters, an assumption that the water is homogeneous will be made, resulting in constant salinity and temperature. The three meters limit results in a maximum pressure of:

P = 3 ∗ 998.2 ∗ 9.81 = 0.29bar. (15)

0 5 10 15 20 25 30 35 40 1400

1410 1420 1430 1440 1450

Salinity [ppt]

Speed of Sound [m/s]

Figure 3: Changes in sound speed depending on salinity. Temperature and pressure both equal to zero.

0 5 10 15 20 25 30 35 40

1400 1420 1440 1460 1480 1500 1520 1540

Temperature [deg C]

Speed of Sound [m/s]

Figure 4: Changes in sound speed depending on temperature. Salinity and pressure both equal to zero.

0 0.1 0.2 0.3 0.4 0.5

1402.38 1402.4 1402.42 1402.44 1402.46 1402.48

Pressure [bar]

Speed of Sound [m/s]

Figure 5: Changes in sound speed depending on pressure. Salinity and temperature both equal to zero.

Figure 3 through 5 shows that the highest speed of sound in water is achieved at high salinity, high temperature and high pressure. Considering two extreme cases; salinity, temperature, pressure at zero and salinity = 40ppm, temperature

= 40^◦Cand pressure = 0.5bar; the speed is calculated to 1568m/s and 1402m/s respectively. This results in an measurement error of up to 35.5cm for a depth of three meters, still assuming a worst case scenario. The change in temperature has the most significant impact on the speed. Therefore many echo sounders also uses a temperature reading to compensate for this. Furthermore is the salinity of the water consistent over time and often well known. Since the temperature and salinity is known, and the pressure has almost no impact on the result, a greater precision is easily achieved.

2.4.3 Transducer Echo Cone

To achieve the highest possible resolution, when combined with the coordinates from the GPS, a depth sounder with a narrow beam angle is preferred. When the depth sounder sends out a pulse, and listens to it’s echo, the depth is calcu- lated as the distance to the closest object that is able to reflect the soundwave.

This causes the depth sounder to only measure the most shallow depth within the cone.

Figure 6: Actual depth not measured correctly due to wide beam angle.

From figure 6 the relation between the radius r, the depth d and the beam angle α can be derived:

tanα 2



d= r (16)

The most common beam angle of a typical transducer is 60^◦, which causes a 1.7m radius at a depth of three meters. The uncertainty in where the echo comes from adds to the uncertainty in position given by the GPS.

National Marine Electronics Association (NMEA) has developed a combined electrical and data specification for communication between marine electronics.

This standard allows data to be sent from marine equipment to computers and other marine equipment.

The NMEA standard is based on a serial communication with multiple de- vices referred to as talkers and listeners. One bus can only handle one talker, but several listeners, this eliminates interference from multiple talkers using the same bus. The most common NMEA standard is the NMEA 0183 which com- municates with ASCII characters at a speed of 4800 bits per second, though some devices supports higher baud rates for improved accuracy.

The messages that are sent from the talker to one or more listeners is called a sentence. Each sentence begins with a ‘$’ followed by a data type, multiple data fields separated with ‘,’ and ends with a carriage return/line feed-character. The NMEA standard defines how different sentences should be interpreted depend- ing on it’s data type. Since sentences are sent in one direction, from talkers to listeners, there is no way to tell the talker that a sentence wasn’t correctly transferred. This problem is solved by ending each sentence with a checksum and making the listener simply discard all corrupted sentences. The checksum begins with a ‘*’ followed by a two digit hexadecimal representation of an ex- clusive OR of all characters in the sentence, except for ‘$’, ‘*’ and the checksum itself.

The NMEA standard is based on the RS-422 standard for serial communication, which uses differential signaling. Data is transmitted as a voltage difference be- tween two wires, without a reference to any other potential (e.g. ground). This results in a much better resistance to electromagnetic noise since both wires receive the same interference.

Figure 7: The use of differential signaling eliminates the noise.

The advantage of differential signaling is shown in figur 7. The electromagnetic noise affects both wires and is canceled when the inverse of one signal is added to the other. In single-ended signaling, the signal would be transmitted by a voltage referenced to ground. This can cause transmission errors when using long wires or if the the two units communicating is referenced to different voltages.

2.5.1 NMEA Sentence Example

This is an example of a sentence with data type GGA which provides a fixed 3-dimensional position together with accuracy data.

$GPGGA, 1337 11 ,595 0. 31 1 ,N, 0 1 7 3 8 . 8 4 5 ,E, 1 , 0 8 , 0 . 9 , 4 1 . 2 ,M, 2 6 . 2 ,M, , ∗ 7A The sentence starts with a ‘$’, followed by GP for GPS unit. GGA is the data

type specifying the rest of the sentence. In this case the data fields, read from left to right, are as follows [4]:

133711 Fix taken at 1 3 : 3 7 : 1 1 UTC

5950.311 ,N Latitude 59 50.311 N

01738.845 ,E Longitude 17 38.845 E

1 Fix q u a l i t y : 1 = GPS f i x

08 Number o f s a t e l l i t e s being tracked

0 . 9 Horizontal d i l u t i o n o f p o s i t i o n 4 1 . 2 ,M Altitude , Meters , above sea l e v e l 2 6 . 3 ,M Height o f geoid (mean sea l e v e l )

empty Time in seconds s i n c e l a s t DGPS update

empty DGPS s t a t i o n ID number

∗7A The checksum data .

2.6 Different Ways to Accomplish Same Measurements

There are two types of sensors needed to be able to measure depth and position.

A depth sounder and a GPS receiver. In this report, a setup consisting of both an onboard depth sound and GPS receiver will be considered. A module will

network connections will also be required, for uploading data to a remote server.

For users who doesn’t use an onboard GPS receiver, an alternative would be the use of a smartphone. A typical smartphone can host both the location ser- vice and the connection to the internet. The two main types of smartphone operating systems are Android and iOS. The self-calibrating algorithm, that will be developed, can be implemented in an application for both the operating systems.

2.6.1 Limitations and Drawbacks

There are some limitations to what types of communications these operating systems can handle. The Android operating system, developed by Google Inc., is able to send and receive serial data through a wired connection as well as using WiFi or Bluetooth, this does not apply to iOS. iOS can’t handle either a wired or a Bluetooth serial connection without a license approved by Apple Inc.

[8]. However, both systems can be set as a portable WiFi hotspot, which allows for web-based communication. Essentially the NMEA interface module acts as a web server, where the smartphone can download measured data, combine them with it’s location and then upload them to a remote server.

2.6.2 Different Setups

Three different modules can be developed for the user to choose from. The most basic setup will require a NMEA to serial converter together with an Android based smartphone. This setup will use the depth sounder combined with either the smartphones GPS, or an onboard receiver.

In an more advance version, the NMEA to serial converter will be combined with a WiFi module and a small webserver. An application receives either depth or depth and location data from the web server. If only the depth is measured, location data from the smartphone will be added. This setup will be compatible with both Android and iOS. This module could also be equipped with a memory card reader for logging data and then sending it directly to the remote server when any WiFi connection is established.

An even more advanced module would completely eliminate the use of a smart- phone. It will have all the functionality of the WiFi-model, but will also be equipped with a SIM-card reader and a GPRS/3G module, for internet com- munication. This type of module will not be considered in this report.

This report will mainly focus on the mid-range module, equipped with both a depth sounder and a GPS receiver.

2.7 Data compression

In order to send all the gathered information to a remote server, some data compression is needed. The NMEA 0183 standard is capable of transmitting 4800 bits per second per sensor. This adds to 9600 bit per second for both

measurements. Each character in a sentence (see section 2.5.1) is described using an 8-bit integer according to the ISO 8859-1 ASCII table, this includes the numbers representing the coordinate values, depth data etc. This is an inefficient way of storing and sending data. Replacing the string "123" with the actual value of 123 will decrease the data from 3 bytes to 1.

2.7.1 Bit, Bytes, Characters & Hexadecimal Representation

Each character in a string of text is stored as a binary value of 8 digits, bits.

Those 8 digits form a byte, also referred to as a character. This includes all char- acters, even those which aren’t visible as text, for instance the null-character (number 0). Therefore will all characters in this report be represented in hex- adecimal form, using only two readable characters for each byte. An example of the value 88 is shown below.

Binary Decimal Character Hexadecimal

01011000 88 X 0x58

2.8 Test Setup

A test setup will be constructed, consisting of a Raspberry Pi as a main com- puter together with a pressure sensor and a GPS receiver. This setup will be able to measure altitude, calculated from current air pressure, and location re- ceived by the GPS. Furthermore will the unit be able to handle data from echo sounder even though such equipment isn’t part of the test setup.

2.8.1 Pressure to Altitude Conversion

To be able to convert a measured pressure to a corresponding altitude, some assumptions about the Earth’s atmosphere has to be made. The assumption of hydrostatic equilibrium is made and gives the relation between a change in pressure per change in height.

dP

dh ≡ −ρg (17)

where P is the atmospheric pressure, h is the altitude, ρ is the air density and g the gravitational acceleration. By combining this equation with the ideal gas law,

P = ρRT (18)

where R is the gas constant for air [J/kgK] and T [K] is the temperature, a differential equation is formed.

dP

dh = − g

RTP (19)

Since the measurements will be taken near the earth’s surface and within a small range, the temperature is assumed to be constant. A solution to the differential equation is given by integration.

h= −RT Z 1

dP = −RT

ln (P ) (20)

tude above sea level, the height corresponding to the pressure at sea level is subtracted. This gives

h= −RT

g ln P/P0 (21)

where h is the altitude above mean sea level and P0 is the pressure as mean sea level (101325 Pa) [5]. This forms a good estimation for the relation between altitude and pressure close the the earth’s surface where the temperature is con- stant.

In this report the constants will be defined as follows:

g 9.81 m/s² gravitational acceleration P0 101325 Pa air pressure at sea level R 287.053 _kgK^J air gas constant T 288.15 K temperature (15^◦C)

Table 3: Constants used for pressure to height calculation.

This results in a pressure-to-altitude relation equal to

h= −8431.6332 ∗ ln P

101325. (22)

To further improve the precision, a change in temperature according to altitude would be applied, along with accurate temperature measurements. Neither of these inputs will be considered in this report. The goal is to measure an altitudes close to the Earth’s surface, where the temperature is assumed to be constant. Furthermore will the atmospheric pressure fluctuate over time, causing an altitude dependant temperature to become very inaccurate.

2.8.2 Low-pass Filtering

Due to chances of measurement noise, low-pass filtering will be applied to the two sensors, if needed. Two different filters will be examined in order to deter- mine which of the two to use in the final test setup.

1st Order Low-pass Filter: A simple digital representation of a first order low-pass filter can be realized by using an electrical low-pass filter.

v

v

R

C

Figure 8: Electrical representation of a 1st order low-pass filter.

The following equations is derived by examining the circuit diagram in figure 8:

vin(t) − vout(t) = Ri(t) Qc(t) = Cvout(t)

i(t) =dQc

dt .

(23)

By substitution, the three equations is merged to

vin(t) − vout(t) = RCdv_out

dt (24)

which can be discretized by substituting the time derivative of vout with the change in y divided by the sampling time, ∆T . This gives

x[n] − y[n] = RCy[n] − y[n − 1]

∆T (25)

which is rearranged to

y[n] = x[n] ∆T RC+ ∆T



+ y[n − 1] RC RC+ ∆T



. (26)

The coefficients of x[n] and y[n − 1] is substituted to α since RC is unknown.

This results in

y[n] = αx[n] + (1 − α)y[n − 1] (27) where y is the filtered signal, x the input signal and 0 ≤ α ≤ 1. α is calculated either by choosing a suitable cut-off frequency or by examining raw and filtered data, choosing the value of α that gives the best result.

Adaptive Filter (Kalman): The Kalman filter is an algorithm that uses in- formation about previous, noisy, measurements, to estimate a state space model of the system. For this filter, the only input that is available is the measurement of the current altitude. By using a state space model where both altitude and vertical velocity is used, the true altitude is estimated with less fluctuations than the raw measurements.

The current state is described by

a_k =a

˙a



(28)

ˆak = F ˆak−1+ Buk−1, (29)

F =1 ∆T

0 1



(30) and

B =∆T 1



(31) where ∆T is the sampling time. This describes a system that uses the vertical velocity as an input for estimating the current altitude. The Kalman filter then works in two steps, prediction and update of the state.

First the next state is predicted, according to equation 29, along with its co- variance matrix P

Pk= F Pk−1F^T + Q (32)

where Q is the covariance of the process noise, that is the error in our model of the movement. When the next state is predicted, a noisy measurement of the current altitude is taken.

zk= Hak+ noise (33)

where H = [1 0]. The estimated altitude is subtracted from the measurement.

Similar to the predicted state covariance P , the residual covariance, S, is calcu- lated by

S_k = HPkH_k^T+ R. (34)

R is the covariance of the measurement noise, which in this case should be greater than Q. Using the predicted covariances P and S, the Kalman gain K is calculated.

K= PkHk^TS_k⁻¹ (35)

The Kalman gain tells how much we should trust the new measurement. The estimated state is then updated by adding the residual to the predicted state, with the Kalman gain as a coefficient. Also the estimate covariance, P , is updated.

ˆak= ˆak+ Kzk (36)

Pk = (I − KH)Pk (37)

If the input, u, is set to 0, the filter will assume to keep the altitude constant.

This still gives a usable filter, but by using the vertical velocity, the filters re- sponse is quicker. For each new state estimation, the change in altitude is used as the vertical velocity input. This causes the estimated vertical velocity to drift toward either positive or negative infinity. The input signal i therefore reduced to a point where the filter is stable, that is when the actual measured altitude is able to prohibit the noisy velocity input.

This procedure is then repeated for each new measurement, giving a new esti- mate and a low-pass filtered result.

3 Method

3.1 Measurements on Land

During the development, an easy way to collect data is needed. Therefore an altitude sensor is used, instead of an echo sounder. The altitude sensor measures air pressure, which is calculated to an altitude. Since water and air share many properties, this is a good analogy, causing similar problems that will arise when measuring depth.

One of the problems with water depth measurements is that the average water level will change over time, resulting in change in depth. The same goes for air pressure, where the pressure at sea level changes from one day to another.

This will be solved by using the current air pressure of the three closest weather stations.

3.2 Calibration

If there is an offset in position of the GPS receiver and the echo sounder on a boat, there will also be an error in the data point measured by that boat. This problem can be solved by making each user specify the distances between the echo sounder and the GPS receiver for that particular boat. Since this has to be done manually, many users will not actually measure their equipment and instead either set the offset to 0m, make a bad estimation or misunderstand how to measure and set it to the correct length, but negative. Whichever happens will most users measure incorrectly and therefore the sea profile reconstruction will be incorrect or inaccurate.

By using a well known area, referred to as a calibration area, these parame- ters can be estimated. Each boat measures continuously, but when entering a calibration area, the measurements are compared with the well known depth in that area. Testing different GPS receiver offsets, finding the one giving the best fit to the known depths, the unit has automatically set these variables, otherwise given by the user.

3.2.1 Calibration Algorithm

The unit will continuously measure its position using a GPS receiver. Within the software running on the unit, the different calibration areas will be defined as squares by two corner points. If a measurement is taken within these areas, the measurement is considered a calibration measurement and is later used to calibrate the locations of the equipment onboard. The offsets of position is de- fined as the distance between where the echo sounder is located, to the position of the GPS receiver, with forward and starboard (right) as the positive direc- tions. Since the distances between GPS receiver and echo sounder is fixed on the boat, the offset in measurements relative to a map depends on the course of the boat.

0 1 2 3 4 5 6 7 8 0

2 4 6 8 10 12

[m]

[m]

echo sounder path GPS path

Figure 9: GPS and echo sounder path with an offset of 1m starboard, travelling counter clockwise along the blue line.

In figure 9, a boat is assumed to travel in a circle. The distance between the echo sounder and the GPS receiver is set to 1m, resulting in a new path for the GPS receiver. If the course of the boat wasn’t considered, the GPS would be assumed to travel the same path as the echo sounder, but with a linear transla- tion in any direction. By using the course, the receivers path is that of a circle with a bigger radius, which is the correct travelling path of the GPS.

Since each calibration area is small, the travelled length can be estimated with a constant distance for each degree. A distance in the north-south direction is proportional to the degrees of latitude, however, when travelling east-west the distance per degree is constant at a constant latitude. For travelling north-south one degree latitude is equal to a distance of

d= 2Rπ

360 (38)

meters. Where R is the mean radius of the earth, 6, 371km. For travelling east-west, one degree is equal to a distance of

d= 2Rπ

360cosθ (39)

meters. Where θ is the degree latitude. Within the calibration areas these esti- mations are used to calculate the offset, in degrees, by using the offset in meters.

The coordinates, depth and course for each point within the calibration area is stored. When the calibration parameters are calculated, the measured coor- dinates is corrupted, according to equations 38 and 39. A maximum offset is predefined, the algorithm then start by changing the measured coordinates to

of data points with the same depth data as before but with updated coordinates.

When travelling along the new path, each difference in depth from one data point to another is calculated. The same goes for the depth of the new points in the calibration area. This results in series of data points representing the measured derivative of the seafloor and the, according to the calibration area, assumed derivative, for that specific path. For each set of offset parameters the least square error is calculated.

= N n

^{2 n} X

i=1

( ˙mi− ˙ci)² (40)

where  is the error, N is the number of measured points in the calibration area and n is the number of adjusted points still in that area. ˙miand ˙ciis the deriva- tives of the measured and calibration data respectively. The fraction multiplied with the sum increases the error with the amount of data points not still in the calibration area squared. This results in an greater error if only a few of the original coordinates is used, that is, if the coordinates is distorted too much.

By repeating the coordinate distortion process and error calculation for many different offset parameters, the best fit is considered the set of parameters that results in the smallest error. The whole calibration process is a very time con- suming calculation, but since the positions of the equipment never changes, it doesn’t matter how much time the calculations require, as long as they eventu- ally finish.

3.3 Data Format and Compression

A complete set of data for a certain point has to contain information about where and when the measurement was taken along with the measure depth, estimated error of measurement and three correction variables. To achieve a smaller storage space for the data, and limit the wireless data transmission over GPS/3G, each of these parameters are recalculated and represented as a new set of characters.

To be able to both send and receive correct data, with as little transmission as possible, the unit that encodes data must follow certain rules of formatting when constructing each message, a standard is formed for both the encoder and decoder.

3.3.1 Data Format

As mentioned in section 2.7 each character is represented by an 8-bit value.

By multiplying following characters together, they can be stored as values of 8, 16, 24. . . -bits. Since each measurement is limited within a certain range, the required number of bits can be determined by

ln (value)

ln (2) ≤ bits (41)

where the number of bits always has to be an integer.

Date 12,319,999 12-31-9999 24 3

Time 235,959 23:59:59 18 3

Latitude 180,000,000 ±90.000000^◦ 28 4

Longitude 360,000,000 ±180.000000^◦ 29 4

Depth 254 25.4m 7 1

Error est. 254 25.4m 7 1

Corr. latitude 254 ±0.000127^◦ 7 1

Corr. longitude 254 ±0.000127^◦ 7 1

Corr depth 254 ±12.7m 7 1

Table 4: The depth and location data that are stored and sent from the chart plotter together with it’s number of required bits.

The data will be merged together in the same specific order as in table 4. Each data field has a maximum value, which translates to a maximum number of bits required. By adding the required bytes for each data field, a fixed data length for one measurement is defined as 19 bytes/characters. Similar to the NMEA sentence (see section 2.5.1) one byte, indicating the start of a new message, is used. In this case is also the ‘$’ used for this purpose. This increases the to- tal number of stored bytes to 20 bytes per measurement but also decreases the number of usable characters since the ‘$’ must not be part of any data field.

Another type of message is also defined, referred to as a header message. This contains all information about which setup the boat uses and the boats unique ID. This message type starts with an at-symbol (@). Altogether, both message types allow for 254 different characters to be used.

3.3.2 Compression Efficiency

To test the efficiency of the compression method, a complete set of data, ac- cording to table 4, was used.

Date 02042014 (February 4, 2014) Time 133711 (13:37:11)

Latitude 149838516 (59.838516^◦) Longitude 197647412 (17.647412^◦)

Depth 024 (2.4m)

Error est. 012 (1.2m) Corr. latitude 014 (−0.000113^◦) Corr. longitude 019 (−0.000108^◦)

Corr. depth 102 (−2.5m)

Table 5: The test data used for testing the compression efficiency. 90^◦and 180^◦ added to latitude and longitude respectively.

The coordinates usually ranges from ±90 and ±180, by increasing the values negative numbers are eliminated. The data from table 5, uncompressed, but merged according to the standard described in section would form the follow- ing, 47 character long, message:

$0204201413371159838516017647412024012014019102

To compress the data, each data field is recalculated to base 254. The two characters that are not allowed is ‘$’ (36) and ‘@’ (64). This means that if any of the bytes used for data storage is greater or equal to the decimal value 36, it is increased by one. The same goes for the value 63; all values greater or equal to 63 will be increased by two. This procedure eliminates the use of ‘$’ and ‘@’

while still not exceeding the limits of the 8-bit characters.

Considering the example for time, given in table 5, the decimal value of 133, 711 is first converted to base 244, which results in [2, 18, 107]. Since 107 is greater than 64, two is added, resulting in [2, 18, 109]. These three integers is then stored as characters with least significant bit stored first. The string of char- acters that this algorithm outputs is stored as: [0x6D 0x12 0x02]. The same procedure goes for all data fields and the start-character is then added, resulting in the following data:

0x24 0x6E 0xA7 0x1F 0x6D 0x12 0x02 0x6C 0x81 0x25 0x09 0x6C 0x8B 0x0F 0x0C 0x18 0x0C 0x90 0x95 0xE8

The total number of stored bytes is decreased from 47 to 20, without any infor- mation loss. This compression both saves storage space and reduces the amount of transmitted data.

4 Results

4.1 Test Setup

The test setup uses a Rasberry Pi (RPi) as it’s main computer. The RPi is equipped with a MPL3115 pressure sensor, a Garmin x18-5Hz GPS receiver and a D-Link DWA-121 WiFi module. The WiFi module will connect directly to a smartphone, by using the phone as a mobile WiFi hotspot. The user will then connect to the Raspberry Pi’s web server using the locally assigned ip address.

This enables the user to remote control the RPi and makes it possible to use the phone as a screen for the device, displaying it’s current status, location and graphing the measured altitude.

This setup allows for exact measurements of air pressure and GPS location together with a timestamp received from the GPS. Both sensors uses different interfaces for communication with the RPi. The GPS receiver communicates with NMEA 0183 and the pressure sensor with I²C. Since both sensors should be sampled independent of each other, a separate process handles each interface.

Figure 11: Block diagram showing hardware and software running on the Raspberry Pi.

A plastic container is used to store the hardware described in figure 11. This gives a compact module that is easy to carry when measuring altitude.

Figure 12: Labeled hardware of the test setup, battery removed.

The test setup is shown in figure 12, where all the mentioned hardware is shown, except for the battery which connects to the two USB wires to the right in the photo.

4.1.1 Serial Interface

The serial interface communicates with the GPS receiver using an USB to RS- 232 adapter. The NMEA 0183 interface is based upon the RS-422 standard for serial communication, as mentioned in section 2.5. Since RS-422 and RS-232 are very similar, the USB to serial adapter can be used to communicate with the GPS receiver even though is does not use the differential signaling. The test setup uses very short wires and are therefore not a subject to external interfer- ence.

The purpose of this process is to connect to the GPS receiver and listen for the transmitted sentences. A table with predefined sentences, according to the NMEA 0183 standard, is used as a reference when processing the received data.

The information that we are interested in is latitude, longitude, time, date, estimated positioning error, course and whether the receiver currently tracks satellites or not. Almost all this information can be obtained from the “Recom- mended Minimum Specific GPS/TRANSIT Data” sentence ($GPRMC), except for the estimated positioning error, which can be obtained from the “Global Po- sitioning System Fix Data” sentence ($GPGGA). For increased compatibility, multiple sentences containing the same information is supported as well as a fallback to a default value if a certain information cannot be obtained.

The GPS receiver can be set to output different sentences even though many of them contain the same information. If that is the case, first a measurement is taken, then transmitted using all the defined sentences. A block of all sentences generated by one measurement from the Garmin x18-5Hz GPS receiver may contain the following information.

$GPGSA,A, 1 , , , , , , , , , , , , , , ,

$GPRMC, 1 2 1 3 3 6 . 0 ,V, 5 9 5 1 . 5 6 4 1 3 ,N, 0 1 7 3 7 . 8 5 7 9 2 ,E, , , 1 7 0 3 1 4 , 0 0 0 5 . 3 ,E

$GPVTG, ,T, ,M, ,N, ,K

$PGRME, ,M, ,M, ,M

$PGRMF, , , 1 7 0 3 1 4 , 1 2 1 3 3 6 . 0 , 1 6 , 5 9 5 1 . 5 6 4 1 3 ,N, 0 1 7 3 7 . 8 5 7 9 2 ,E,A, 0 , , , , The useful information is extracted from the $GPGGA and $GPRMC sentences using the GPS receiver’s datasheet as a reference [9]. The serial interface recog- nizes each block of sentences by comparing the sentence type and the time given by that sentence. This causes the first sentence that gives a new timestamp to be considered the first sentence of that block, which in turn corresponds to a new measurement. The required information is extracted from the sentences, processed to a certain format and then stored in local variables corresponding to each piece of information.

Along with the GPS receivers information, the serial interface process also mea- sures the sampling time and the Raspberry Pi’s local time. All these measure- ments are then merged into a single string, with the data separated by colons and commas. The format is equal to “timestamp:sample time:gps information”, an example is also shown below.

1395060706.51468:

0.401832103729248:

170314 ,121336.0 ,59.8594021666667 ,17.6309653333333 , −1 ,0

The processed gps information is written as “date,time,latitude,longitude,estimated error,fix”, where the coordinates for latitude and longitude are recalculated to decimal degrees according to section 2.2. An estimated error equal to -1 is shown in the example, this is the default value and is only used when there is no GPS reception or the estimated positioning error isn’t available.

4.1.2 I²C Interface

The I²C interface serves the same purpose as the serial interface, except that it communicates using the Raspberry Pi’s I²C interface. A factory calibrated pressure sensor, the MPL3115, is used to measure the current air pressure.

The sensor is also capable of measuring temperature and altitude, but these measurements will not be used in this setup. Each pressure measurement is recalculated to an altitude, according to section 2.8.1, and then stored in the shared RAM memory in the same way as for the serial interface. The stored data from the I²C interface can be equal to the following, colon-separated, string:

1395063182.65117:0.229111909866333:285.095748242646

Where the first value is a timestamp, the second the sample time and the third is the current altitude in meters.

4.1.3 Daemon

Since both the serial and I²C interfaces are subjects to unsuspected errors in communication causing reading errors, timeouts or process crashes, the daemon process acts as a supervisor for the two interfaces, restarting either of them if

Figure 13: Flow chart showing the daemon process.

The daemon process is set to run at startup and then handles all other processes by itself. First task is to allocate 512 bytes of RAM memory, when the memory is allocated the two interfaces are initialized. Each interface performs the sim- ple task of requiring data and storing it in the ram memory. The interfaces are given 128 bytes of RAM each, with the I²C interface writing to the first address and the serial interface writing to address 129 and so forth.

The daemon starts with a delay, allowing both interfaces to start properly.

After that, the shared RAM memory is read from address 0 to 512, the read string is split and data is extracted. By reading each interface sample time, a global sample time is formed as 110% of the highest of the two interfaces. In this setup, the GPS receiver seems to give the longest sampling time at 0.4 seconds, resulting in a global sampling time of approximately 0.44 seconds. For each new sample, the sample times for each interface are again given to the daemon process and considered when executing the next delay.

Each time data is read from the RAM, the timestamp is compared to that of the previous measurement. If the timestamps are equal, it means that the process handling the corresponding interface has crashed due to an unexpected

that particular interface is restarted.

If both sensors reports new timestamps, the measured date, time, altitude, po- sition and error estimation is stored in a log file. For practical reasons, a check of the GPS fix and error estimation is made before logging the measurement.

Only if the GPS receiver is able to acquire it’s position and the estimated error is under 10 meters, data is written to the log file. This minimizes measurements errors caused by the GPS receiver being moved inside.

For a better understanding of the different steps of the daemon process, check Figure 13.

4.1.4 IP resolving

To be able to easily access the web page provided by the Raspberry Pi, a lo- cal connection between the RPi and the users smartphone is made. The local IP-address of the Raspberry Pi is not easily found by the user, and may be changed if the access point provides the RPi with a new IP-address. This prob- lem is solved by letting the RPi find it’s local address and send it to a remote server, through the shared internet connection of the smartphone. The RPi’s local IP, stored on the remote server is then requested by the smartphone and the user is automatically redirected to the web page stored on the Raspberry Pi.

Figure 14: Flow chart showing the IP resolving process.

As seen in figure 14, stores the remote server each RPi’s local IP-address in a text file named after the IP-address it was received from. When an address is requested from the same IP, the text file is accessed and the smartphone receives the local IP-address of the Raspberry Pi connected to the same hotspot. This makes it possible for multiple test units to be used by different users at the same time, without them interfering with each other. Since the users remote IP only is used for redirection, no further protection and user isolation is required. If a new user has the same address as that of another an old user, and the new user hasn’t connected its unit properly, he will be redirected to the local address of the old user, causing no harm to either of the users. The problem is solved by refreshing the page.

4.2 Web Server

For increased compatibility, a web server runs on the Raspberry Pi, providing the user with information. This removes the need for separate applications on different platforms and enables any web-enabled device to be used with the test

web server is therefore designed as a look-alike to the native iOS interface.

Figure 15: A screenshot of the web page.

The web page is designed using css, html, javascript, xml and php. The css- document handles the visual design, together with some some parts of the javascript. The xml-document defines the whole web page and all of its sub- pages. Each page has the ability to use additional javascript and call php.

This makes the whole web interface easy to develop further, implementing new features.

4.3.1 Kalman Filter

The filter that gives the best result, while low-pass filtering the pressure sensor, is the adaptive Kalman filter.

0 20 40 60 80 100

270 275 280 285 290

Altitude [m]

Time [s]

raw filtered

Figure 16: Raw and filtered altitude data.

In figure 16 the raw and filtered data is plotted. By looking at a linear portion of the data, from 15s to 40s, the standard deviation of both signals can be determined.

15 20 25 30 35

270 275 280 285 290

Altitude [m]

Time [s]

Figure 17: Same data as in figure 16, with their corresponding standard deviation.

The raw data is very noisy, with a standard deviation of 2.16m, see figure 17. At small differences in altitude, this causes the measurements to be almost unus- able. The standard deviation of the Kalman filtered signal is reduced to 0.28m.

In figure 17 it is shown that the mean value of the filtered signal is slightly lower than the mean value of the raw data. This is not true, however does the filter introduce a small time delay, as seen in figure 16. The lower mean value is caused by previous changes in altitude, that still affects the filtered signal but

4.3.2 1st Order Low-pass Filter

Using the same method as in the previous section, the performance of the 1st order low-pass filter is examined.

0 20 40 60 80 100

270 275 280 285 290

Altitude [m]

Time [s]

raw filtered

Figure 18: Raw and filtered altitude data.

By visually comparing figure 16 and 19 it is shown that the Kalman filter results in a smoother output. Both filters react to the low frequent change in altitude in the same way by using an α equal to 0.9. For a even smoother output, α can be increased, however this results in a slower filter.

15 20 25 30 35

270 275 280 285 290

Altitude [m]

Time [s]

Figure 19: Same data as in figure 19, with their corresponding standard deviation.

The standard deviation for the low-pass filter is calculated using the same set of data as for the Kalman filter and results in 0.40m compared to the Kalman filters 0.28m.

4.4 Air Pressure Compensation

The air pressure for three different weather stations, located in Uppsala, Stock- holm and Eskilstuna, are used to resolve the air pressure as sea level of the cur- rent position. Current pressure data is fetched from the Swedish Meteorological and Hydrological Institute (SMHI). The three weather stations is assumed to

valid for all points within that triangle.

Figure 20: Effects of air pressure compensation. The image to the right is corrected, the one to the left is not.

If the air pressure isn’t considered, multiple sets of measurements ranging over multiple days will result in great altitude errors. This is also true for measuring water depth. The water surface will rise and drop from one day to another.

In figure 20, six different measurements is used to generate the altitude data.

The most noticeable is the altitude range. For the corrected data, the altitude ranges from approximately 5m to 50m but if the data isn’t corrected, it ranges from −100m to 250m.

4.5 Calibration Algorithm

To test the calibration algorithm a calibration area has to be defined. This is done by measuring the altitude five times in the same location. The data points are interpolated using the built-in MATLAB function TriScatteredInterp, which returns a function describing the altitude given two coordinates.

Figure 21: Calibration area, interpolated by MATLAB’s function TriScatteredInterp. Red areas representing a high altitude and blue a lower.

A sixth set of measurements is used to test the algorithm. Since the test setup only is capable of measuring location and pressure without an offset, the mea- sured coordinates is distorted 5m starboard, as described in 4.5. The distorted coordinates is used as input, and considered the measured coordinates. The algorithm is set to a maximum offset of 10m and a resolution of 0.2m. For each combination of offset parameters the error is calculated.

Forward [m]

Starboard [m]

−10 −8 −6 −4 −2 0 2 4 6 8 10

−10

−8

−6

−4

−2 0 2 4 6 8 10

Figure 22: Heat map of most probable receiver location offset.

With the echo sounder located at the center of figure 22, the most probable location of the GPS receiver is that of the red dot in the same figure. The heat