Report

Environmental/Regatta Buoy: Data Logging

Author:
Jeroen Vervenne

I would like to take this opportunity to thank all the people that made this Project/Internship Erasmus at ISEP possible. In the first place I would like to thank Mr De Strycker Lieven to bring me in contact with Mrs. Malheiro Benedita. Also the other people of KAHO Sint-Lieven namely Mrs Roelands Ilse and Mr Naessens Vincent to fill in and arrange all the necessary things.

Special thanks should be offered to Mrs. Benedita Malheiro, Mr. Paulo Ferreira , Mr. Manuel Silva and Mr. Pedro Barbosa Guedes for holding the weekly meetings, give me a lot of advice, bring me in contact with other people and specially for all the knowledge they teach me. Without this people and there wisdom it would be hard to realized what I now have. But not only their technical information was particular useful, they also give me a lot of information about the Portuguese traditions, places, etc. I'm really grateful for that. In particular I would like to thank Mrs. Benedita Malheiro who guided me from the start of my Erasmus. Without your efforts and drive i wouldn't had a great project and a great experience.

I'm also immensely thankful for the people who helped me from LSA. Especially Mr. Pedro Rocha and Mr Diogo Machado to give me the necessary components and tools that helped me realize this project. But also to share there knowledge with me. As last, i want to thank the people of the international office from ISEP who helped me with the necessary documents to start at ISEP.

These days Scientists know more about the universe than about the sea. Nevertheless, the earth consists of 73 % water. Therefore, using buoys is a good step in the right direction to understand the water on this earth. The buoy designed in this project has two major goals: collecting all kinds of data information and data supporting for an autonomous sailing boat.

This project is a continuation of the work that a group of four students started last year. This time the project is divided into two main parts namely, data logging, and the other is telemetry and configuration. In this report, the part of data logging will be handled. The two parts are connected to each other through a self-defined protocol. The protocol defines the transfer of data and instructions. The last group has already carried out the research work, designed the buoy and ordered the necessary components. Through the good work of the previous group, there could be immediately started to investigate the selected components in order to understand them. After choosing a suitable operating system for the control unit, various sensors could be programmed as well as the storage area. At the end the interface between the two parts is established.

In the end, the aim is to have an autonomous buoy that collects data, saving this data and exchange it with the end users. The buoy combines two major and significant applications, i.e. data collection and assistance in regattas, all which makes it the first of this type. Nevertheless, the buoy unfortunately does have two limitations. First of all, it can only hold up a total weight of around 40 kg. Secondly, it cannot be used on the sea or ocean.

Table 1-1 Prensentation

First of all I chose the Instituto Superior de Engenharia do Porto because our university has a very good connection with it and they also assured us for a very good guidance. There were also a lot of autonomous thesis assignments which were also very maritime focused, this cohesion is very rare what gives a very interesting opportunity.
At last I chose for the autonomous buoy as thesis assignment because it was focused on realization. My part was mainly programming, since I'm studying Electronics this was a big challenge for me. I really like challenges, therefore this was the perfect choice.

A buoy is a partially submerged floating device used in water that can have many purposes. It can be anchored (stationary) or allowed to drift with the sea currents. It can be found at the open sea, a river, a lake, a bay or other places where there's a lot of water. The buoy can be used for many purposes which divides them into different types: collecting data for weather agencies, warning passers about dangers or giving passers useful measurements/information at that location or just as a marker for a dangerous spot, area or line that shouldn't be passed. Depending on the purpose, a buoy can have different chaps and sizes. The smallest mostly don't contain any electronic equipment and are used to mark the location of shallow water or an underwater mountain for instance as exemplified in Figure 1-1. The bigger buoys have more equipment on board to give passers or a control station at a certain range specific measurements on that location as exemplified in Figure 1-2. They are mostly equipped with a multitude of electronics such as sensors, solar panels and batteries.

Figure 1-1 Example of a buoy as marker [10]

Figure 1-2 Example of a measuring buoy [11]

Last year a group of four students already designed and constructed the autonomous buoy (Figure 1-3). This buoy is relative small compared with some of the bigger ones, but rather complex as it is intended to have a number of electronic devices. The most of the necessary equipment to realize this autonomous buoy are present. The objective that remains is assembling and programming. This objective was divided into two main blocks: the data logging part and the telemetry and configuration part. The goal within the telemetry and configuration part is to design and develop a system to configure and download data from an environmental/regatta buoy. This buoy has two operation modes:

1. The environmental data logging mode;
2. The regatta mode.

The system, in environmental mode, should be able to receive request commands and transmit status or data via the wireless and Universal Serial Bus (USB) interfaces. The requests can be reconfiguration (include/exclude sensors, change operation mode, etc.) or data retrieval related. In regatta mode, the buoy must, additionally, act as a beacon and broadcast via the wireless interface the Position, Velocity and Time (PVT), wind and water related data for autonomous boats located in the vicinity.
This paper handles about the data logging. This is collecting the data from all the sensors, analyse the data and store it. When needed the data can be retrieved.

Figure 1-3 Existing hull

The general objective of the buoy is to measure, store and send data from its location at sea (near the shore) or in a river. The buoy is intended to have two main applications in the future.

1. Assistance in autonomous sailing boat regattas who will be constructed at LSA in the future;
2. Collecting environmental data.

In the assistance function the buoy is suppose to perform two tasks:

• inform the sailing boats about its location so that they travel in the right direction;
• provide judges with the necessary weather data to assess each boat’s performance.

For the collecting function the buoy is suppose to make measurements of selected weather conditions at a chosen site and period. Nevertheless, the buoy is for the moment limited to work at sea, near the shore, or in a river because of the absence of a long distance communication unit.

The objective within the data logging part is to develop an on-board buoy system that interfaces with multiple sensors, collects and stores on-board the monitored data (wind, water, heading or PVT related data). The system should be programmatically reconfigurable (include/exclude sensors to/from the list of monitored sensors).

For the data logging part the STM32F3-Discovery board will be used as the on-board buoy system that will communicate with the multiple sensors, collects and stores on-board monitored data (wind, water, heading or PVT related data). This development board was chosen because there is an electronic compass implemented on the board which allows an easier determination of the wind direction and the location. An other factor was the high experience level of LSA with this development board.

Before the project can be started, there needs to be done some research work. First the two modes and the fitting data will be discussed as the purpose of the mode. Once this is discussed, a few competitors will being presented, with the advantages and disadvantages of each one. At the end the existing components will be handled. Because the previous group did the research for the components, all the components are ordered. No comparison between components will be done, but the components will be discussed in detail.

The buoy developed in this project has two operation modes. But what is the benefit of having two modes? In this chapter there is brainstormed about the use of the modes and what data needs to be collected.

A data logger (or datalogger) is defined as an electronic instrument that records measurements of all types at set intervals over a period of time. Data loggers can record a wide variety of energy and environmental measurements including temperature, relative humidity, AC/DC current and voltage, differential pressure, time-of-use (lights and motors), light intensity, water level, soil moisture, rainfall, wind speed and direction, pulse signals, and more. Typically, data loggers are compact, battery-powered devices equipped with an internal microprocessor, data storage that are connected to one or more sensors [7]. Figure 2-1 a general overview of several kinds of data logging systems is displayed.

Figure 2-1 Data logging systems [7]

At sea there are only two physical elements - water and air - that together contribute for the local weather. The collected data can, e.g., be useful to analyse the global warming effect on the sea level and on the temperature of the water.

The main water features are the water temperature, conductivity and current (velocity and direction). When the buoy is used in a river or placed at a dam it could be useful to know the level of the water. For this a reference value is needed, namely the mean sea level. If a NAVSTAR Global Positioning System (GPS) sensor is used, the level of the water can also be determined. The water temperature is also relevant: “Water temperature is one of the key environmental variables in the coral reef environment. At the fine scale, water temperature directly affects biological and chemical reactions.” [8]. The water temperature will be logged in this project.

Meteorological data logging involves, among others, the collection of wind, humidity, temperature, wind velocity and direction, barometric pressure readings. These data can be used, e.g., to predict weather, to navigate, to fish, etc. The wind velocity and direction will be logged in this project. In the future, there is the possibility to add more sensors.

The dictionary defines a regatta as a series of boat races. The term typically describes racing events of rowed or sailed water craft, although some powerboat race series are also called regattas. So, the main purpose of the regatta mode is to provide boats in the vicinity of the buoy with the necessary data to stay on the right track. Figure 2-2 illustrates a sailing regatta.

Figure 2-2 Sailing regatta race [12]

LSA research is focussed on autonomous platforms and, among the several projects under development, includes the autonomous sailing boat with the goal to participate at the World Robotic Sailing Championship. The buoy is intended to work as a beacon during the races, broadcasting relevant data to the autonomous sailing boats in the vicinity. The final goal is to define the race course on the water with a few of these buoys. In order to improve boat navigation accuracy, the buoys broadcast their position together with the wind and the water current parameters (velocity and direction).

The main function in regatta mode is to supply autonomous boats with a continuous flow of relavant data to improve the navigation accuracy during regatta races.

The environmental mode implies a continuous collection and logging of water and meteorological data as well as the on demand transmission of the stored data.

In regatta mode, the most important data concerns the water current, the wind and the buoy position. These data are also required for the environmental mode. The differences between the two operation modes are: (i) in regatta mode, the data is broadcast, the required data rate is at least of one sample/sensor/min and the operation period is at most 2 h (a race course can take up to 2 h); and (ii) in environmental mode, the data is stored, the data rate is typically low (up to several minutes) and the operation period large (up to one week). As a result, the two modes can be simultaneously active.

First a general look to data logging systems will be handled. The main purpose of this is to choose what the best control unit is. Once the best control unit is know, a look to other buoys will be done. Accordingly, it will be looked for what sensors they are using, what data they collect, what the main function is, etc.

Autonomous Testing System for LCD
Description
The Autonomous Testing System for liquid crystal display (LCD) measures the temperature and the rise and fall time of a LCD screen. Figure 2-3 presents the overall system diagram.

Figure 2-3 Diagram Autonomous Testing System for LCD

Between all the different components is an interface. But all the interfaces are combined on one Printed Circuit Board (PCB). Also there are two controllers, that are the personal computer (PC) and the field-programmable gate array (FPGA). The advantage of using a PC is that a lot of processing power is available. The biggest disadvantage is that the user needs to connect a lot of different components before the measurement can start and there are two controllers. The data is stored in a comma-separated values (CSV) file [1]. This is a good point, for the reason that everyone can easily read the data. A CSV (also sometimes called character-separated values, because the separator character does not have to be a comma) file stores tabular data (numbers and text) in plain-text form. Plain text means that the file is a sequence of characters, with no data that has to be interpreted instead, as binary numbers. A CSV file consists of any number of records, separated by line breaks of some kind; each record consists of fields, separated by some other character or string, most commonly a literal comma or tab. Usually, all records have an identical sequence of fields.

Conclusion
A processor is needed that can be connected with several different interfaces. Also, the processor needs to have a good processing power rate. A lot of processes needs to be handled at the same time and all the data needs to be processed. The advantage of using 1 processor is first, it's compact and second it avoids connection problems. A good way to store the measured data is in a CSV file. By making a PCB it can be avoided that cables break or connections are wrong.

HOBO U22 Water Temp Pro
Description
This is the data logger used by Tim Noyes, Research Specialist at Bermuda Institute of Ocean Sciences. It's a water temperature sensor, that collects and stores the temperature of the water. The interval of sampling data is configurable. If the data needs to be collected, the sensor is connected to a computer and the data is downloaded. The sensor is placed on a position and is collected after a certain amount of time.

Conclusion
The main advantage is that the interval of when data is collected is configurable, but this has to be done when the sensor is connected to the computer. Also the data is stored on the device. On the other hand, if the data needs to be collected, the user has to go to the sensor and collect it through a USB connection. The sensor doesn't have a tracking system, so the position of the sensor must always be the same or the sensor is lost. It would be useful if data could be collected without going to the sensor. This also applies for the reconfiguration of the interval.

Tinytag Wireless
Description
The Tinytag wireless data logging system consists of a receiver which is connected to a PC and a number of radio loggers (or wireless data loggers). Each radio logger is a self-contained, battery powered unit that can receive, log, store and transmit data to other radio loggers, as well as the central receiver. Each radio logger (or wireless data logger) has a line of sight range of up to 200 m. Data will always find its way back to the PC because it can be relayed from one logger to another logger in range, until it finds its way back to the receiver. If a logger is unable to find a path back to the receiver, its data is stored locally until a path becomes available [8]. Some features:

• Local cache can store two weeks of readings;
• Short message service (SMS) messaging supported;
• Remote alarm signaling via e-mail.

Conclusion
The fact that the sensor sends data through a wireless connection is a big advantage. If there is something wrong an e-mail is sent, so that there can be done something immediately. On the other hand, the data is continually sent to the base station. It can only store data for two weeks. This is a big disadvantage.

A lot of different buoys are on the market these days. But none that supports data exchange with a boat. In the field of support to boats this buoy is the first. In Table 2-1 two different buoys are compared.

Table 2-1 Buoy comparison [13] [14]


The two buoys have batteries inside that can be charged through a solar panel. This is really useful if the buoy is a long time on the water. Concerning the processor, both have an operating system. This helps to do a lot of processes simultaneously. The midi has a low power processor, and this could explain why the solar panel has less power than the other one. They both use wireless communication, a short and a long range communication is provided on the buoy. This is more for the other part, so it wont be discussed here. What concerns the sensors, two big parts are noticed:

• Meteorological (above the water);
• Oceanographic (under the water).

If a boat needs to be guided to a certain position, it would be useful to know how the captain of the boat knows the position. When looked for this, a few devices where found. All these devices use a protocol called National Marine Electronics Association (NMEA). This protocol will be explained more in detail in subsection 2.4.3. It would be useful to use a device that uses the same protocol as the boat.

From the data logging system there was learned that the best option is to use 1 processor. If the buoy needs to work autonomously, a wireless connection needs to be used, that can collect and reconfigure the buoy. When the buoy is in environmental mode the data isn't sent continual and the data needs to be stored somewhere. So a larg memory space needs to be provided. To avoid wrong or broken connections all the different components can be connected within a PCB. When looking at other buoys, the majority buoys uses a operating system. This has as advantage that multiple processes at the same time can be handled. For the sensors, there are two parts: the sensors in the water and those out of the water. For now only two sensors are used: a wind sensor, and a Conductivity, Temperature and Depth (CTD) sensor. To determine the position of the buoy, a device that outputs a NMEA command needs to be found. There needs to be a system that checks if there are errors, and if so that this state is communicated to the user.

This hull (Figure 2-4) was the starting point of the previous group. It was already available, so everything has to be build around this hull. The hull is made of fiberglass that way the hull is not heavy. It is empty inside, and to access the hull six bolts need to be unscrewed. The idea is to put the electronic components inside the hull. Electric components and water are a bad combination, so the hull has to be water proof. The following things help to make it waterproof:

• The nuts have been replaced and covered with a layer of glass reinforced plastic;
• Rubber washers for the bolts to seal the threaded connection;
• Ethyleen – Propyleen – Dieen Monomeer (EPDM) rubber tape (3 mm x 25 mm x 10 000 mm) attached to the hull;
• “Duct Tape” at the lid-main hull connection, in the future this will be replaced by a rubber skirt;
• Waterproof box inside the hull to put the electrical components in.

Figure 2-4 existing hull

The steel structure (Figure 2-5) is made to attach the sensors to it. Another reason to make a steel structure is to make the buoy taller. On the top of the steel structure is a blinking lamp is attached, to make it visible from a larger distance. There are a few requirements for the steel structure:

• The material needs to be resistant to the effect of salt water and UV radiation;
• Enough space to attach all the sensors;
• The buoy must be resistance against wind and waves;
• Strong enough.

Figure 2-5 Steel structure

The Global Navigation Satellite System (GNSS) sensor is a stand alone GPS card and stands for global navigation satellite system. The GNSS sensor used in this project is a SUPERSTAR II. The SUPERSTAR II is a complete GPS OEM sensor that provides 3D navigation on a single compact board with full differential capability. The SUPERSTAR II is a 12-channel GPS receiver that tracks all in-view satellites. It is fully autonomous such that once power is applied, the SUPERSTAR II automatically searches, acquires and tracks GPS satellites. When a sufficient number of satellites are tracked with valid measurements, the SUPERSTAR II produces a 3-D position and velocity output. The GNSS sensor supports two communication modes:

• NMEA;
• Binary.

NMEA
GNSS receivers uses NMEA 0183. NMEA stands for National Marine Electronics Association Standard for Interfacing and is controlled and defined by the National Marine Electronics Association. There are two previous versions of this NMEA protocol. There is also a new version, NMEA 2000. The NMEA 0183 Interface Standard defines electrical signal requirements, data transmission protocol and time, and specific sentence formats for a 4800 baud serial data bus. Each bus may have only one talker but many listeners. This standard is intended to support one-way serial data transmission from a single talker to one or more listeners. This data is in printable ASCII form and may include information such as position, speed, altitude, frequency allocation, etc. There is also a high-speed (HS) addendum to NMEA 0183 V 4.10, called NMEA 0183-HS Version 1.01 that operates at a 38.4 kbaud [5]. The package is always formed the same way.

• Starting character is a $;
• Five characters, the first two identify the sender (GP for GPS) and the others the type of message;
• Data, separated by a comma. If the data is unavailable the corresponding field remains blank;
• If there is a checksum the next character is a ' * ';
• Ttwo digit checksum. The calculation is explained in 3.4.2 Input commands;
• <CR><LF> ends the message.

Binary
A binary protocol is a protocol which is intended or expected to be read by a machine, rather than a human being. Binary protocols have the advantage that it's faster and smaller [6].

The chosen wind sensor in this project is a Mechanical one (Figure 2-6). It consists of a sort of propeller and a vane. The wind speed is measured through the amplitude of the generated AC voltage by the propeller. The voltage of the AC signal is in proportion with the speed of the wind. A precision potentiometer is used to check the wind direction. If the wind turns, so will the vane change position. This change, changes the value of the potentiometer. But this wont be sufficient to determine the wind direction. The buoy can turn, and because the wind sensor is mounted to the steel structure the zero position changes. For an accurate wind direction, a combination of a compass and the wind sensor is used.

Figure 2-6 wind sensor [15]

Table 2-3 provides the specification of the wind velocity sensor selected.

Table 2-3 Davis anemometer specification [15]

This sensor was developed in LSA. The CTD sensor measures 3 variables:

• Conductivity;
• Temperature;
• Depth.

Table 2-4 displays the specifications of the CTD sensor adopted.

Table 2-4 CTD sensor specifications [15]

Sensor Conductivity
An alternating current is applied to the outer pair of the electrodes. The potential between the inner pair is measured. Conductivity could, in principle, be determined using the distance between the electrodes and their surface area using the Ohm's law but generally, for accuracy, a calibration is employed using electrolytes of well-known conductivity [4]. Table 2-5 shows the conductivity of common solutions.

Table 2-5 Conductivity of some solutions [4]

Temperature Sensor

A PT100 is used to measure the temperature. This is a Resistance Temperature Detector (RTD). The PT100 has a resistance of 100 Ω at 0 °C. The material has a predictable change in resistance as the temperature changes; it is this predictable change that is used to determine temperature. They have a higher accuracy and repeatability than thermocouples. There are two sorts:

• Wire wound elements: consist of a length of fine Platinum wire coiled around a ceramic or glass core. The ceramic or glass core can make them fragile and susceptible to vibration so they are normally protected inside a probe sheath for practical use [3];
• Thin film elements: manufactured using materials and processes similar to those employed in the manufacture of integrated circuits. A platinum film is deposited onto a ceramic substrate which is then encapsulated. This method allows for the production of small, fast response, accurate sensors [3].

Pressure

Load sensors are used to measure this value. A load cell is a transducer that is used to convert a force into an electrical signal. This conversion is indirect and happens in two stages. Through a mechanical arrangement, the force being sensed deforms a strain gauge. The strain gauge measures the deformation (strain) as an electrical signal, because the strain changes the effective electrical resistance of the wire. A load cell usually consists of four strain gauges in a Wheatstone bridge configuration. Load cells of one strain gauge (quarter bridge) or two strain gauges (half bridge) are also available. The electrical signal output is typically in the order of a few mV and requires amplification by an instrumentation amplifier before it can be used. The output of the transducer can be scaled to calculate the force applied to the transducer [2].

The STM32F3 discovery board is relatively memory constrained – 256 kB flash and 40 kB Static Random-Access Memory (SRAM) – which limits the ability to store large quantities of data. So another way to store the data has to be found. In this project a small power efficient and robust data storage unit is preferred. Only two systems satisfy this requirement, namely the Secure Digital card (SD-card) (Figure 2-7) and the flash drive. The SD card is the easiest to program and is also the smallest. Memory-cards like SD-Cards or Multi Media Card (MMC) offer a huge amount of memory and are relatively cheap. They have a micro controller inside. The flash memory controls (erasing, reading, writing, error controls and wear levelling) are completed inside of the memory card. If data needs to be read or write to the SD-Card, a file system has to be used. The micro-SD card adapter supports Serial Peripheral Interface (SPI) and SD Bus mode.

Figure 2-7 micro SD-card

Nowadays most electrical components include an micro controller. It's a small and powerful computer on a single Integrated Circuit (IC) containing:

• processor core;
• memory;
• programmable input/output peripherals.

Table 2-6 provides the comparison between candidate microcontrollers and development boards.

Table 2-6 Comparison of µC boards.


The choicee to use the STM32F3 discovery board as development board, was a decision of the previous group. The main reason to choose this development board were:

• Several interfaces and General Purpose Input/Output (GPIO);
  • At least 1 SPI interface for the SD-card;
  • At least 1 Universal Asynchronous Receiver/Transmitter (UART) connection for the GNSS sensor;
  • 1 USB connection (to connect to the other part);
• Includes an e-compass on it, useful to define the wind direction;
• LSA has the board and has usage experience.

By using an operating system the programming work is made easier. Most drivers are already predefined and it can handle simultaneous processes.

Figure 3-1 displays the block diagram of the project. The project has four main elements:

• The STM32F3DISCOVERY;
• The sensors;
• SD-Card;
• Communication between the BeagleBone Black (BBB) and the STM32F3DISCOVERY.

Figure 3-1 Block diagram of the project
In what follows all the components will be discussed in detail. First an overview of the components that were available from the previous year will be given.

Table 3-1 contains the list of materials that were already bought last year, this to give a complete summary of the already bought components.

Table 3-1 List of materials (last year)

In Table 3-2 the features of the electronic components are listed.

Table 3-2 Electronic components

Table 3-3 contains the entire list of materials that were bought for the project. This to give the total cost of the project.
The materials that were bought this year are indicated by: (new)

Table 3-3 List of materials (complete)

Figure 3-2 STM32F3 discovery board [16]
The used development board is the STM32F3 discovery board (Figure 3-2). ===3.3.1 Overview of the code structure=== In Figure 3-3, an overview of the code structure is given. The STM32F3 discovery board sends every predefined interval a message to the sensors (1) to collect the data. This data is read in the STM32F3 discovery board as RAW data (2). Once the data is read, the STM32F3 discovery board manipulates this data, and only the relevant data is kept (3). The next step is to store the data in a CSV file. In number 4 a connection is made with the SD-card and the CSV file on the SD-card (5) to store the data. When the STM32F3 discovery board receives a message from the Beagle Bone Black (6) the message has to be analysed and the correct action has to take place. When the message is to collect data, the data is read from the CSV file on the SD-card (7). Before the data is sent to the Beagle BoneBlack, the data has to be manipulated so that it satisfies the protocol demands (8).

Figure 3-3 Blockdiagram code structure

ChibiOS is a complete, portable, fast, compact, open source Real-time operating system (RTOS). The advantage of ChibiOS is that it provides:

• Startup and the board initialization;
• Integration of other open source projects;
• Support for common device drivers.

Table 3-4 shows the architectures supported by ChibiOS. The STM32F3 isn't shown in the table , but it supports this board.

Table 3-4 Supported architectures [17]


ChibiOS architecture
Figure 3-4 provides the general architecture of ChibiOS that includes the following components: * Application: high level application code abstracted from hardware details; * HAL: high level, cross platform, drivers API layer. For example the driver for UART is defined here.; * Kernel: portable RTOS kernel layer. For example the driver for a thread is defined here; * Platform: low level, platform-specific, drivers layer; * Port: kernel port layer for a specific Architecture; * Board: board-specific description and initialization code; * Hardware: he HW platform.
Figure 3-4 Architecture ChibiOS [18]

Figure 3-5 illustrates the organisation of an application development folder under Eclipse. The application folder contains the following mandatory files:

• main.c: main application;
• chconf.h: kernel configuration file;
• halconf.h: include/exclude the various device drivers;
• mcuconf.h:
  • Setting up the various peripherals parameters;
  • IRQ priority;
  • DMA priority;
  • Any other HW-related setting;
• Build file;

Figure 3-5 ChibiOS application folder

Threads
Threads are functions having a processor context, state information and a dedicated stack area. The working area is declared using the macro static WORKING AREA(waThread1, 128); and the threads are created with the command Thread* chThdCreateStatic(void *wsp, size t size, tprio t prio, tfunc t pf, void *arg) where: * wsp is a pointer to a working area dedicated to the thread stack; * size represents the size of the working area; * prio specifies the priority level for the new thread; * pf is the thread function; * arg represents an argument passed to the thread function (it can be NULL). Figure 3-6 holds the state diagram of a thread.

Figure 3-6 State Diagram of a thread [19]

Virtual Timer
ChibiOS supports the specification of virtual timers (VT). Furthermore, it allows the registration of a VT callback function (will be invoked by interrupt) which will be called when the timer is up. Figure 3-7 illustrates how to code a virtual timer in ChibiOS.


Figure 3-7 Code virtual timer

Communication Standards
The SPI connection, UART connection and the serial connection while be explained with the conforming part.

Figure 3-8 SUPERSTAR II card [20]
===3.3.1 setup === The SUPERSTAR II card (Figure 3-8) that is used here is a 3.3 V model. The first time, only the minimum number of required connections where used (Table 3-5 and Figure 3-9).

Table 3-5 Connections GNSS sensor
^Signal name^ Pin #^ |VCC |2| |GND |10, 13, 16, 18| |TXNo1 |11| |RXNo1|12| |PREAMP |1|
Figure 3-9 Header SUPERSTAR II card [20]

For the connection with another device, the GNSS sensor uses RS232 communication.
The GNSS needs an antenna to receive data from the satellites. The last group had already found a antenna, but it wasn't ordered yet. Luckily there was an antenna available in school. The antenna that is connected to the card is an active antenna (GAACZ-A). In a active antenna an Low Noise Amplifier is built in to provide sufficient gain to overcome coax cable losses. They require power from the SUPERSTAR II card. The specifications of this antenna are are shown in Table 3-6.

Table 3-6 Specifications antenna [21]
^Parameter^ Value^ |Impedance |50 Ω| |frequency |1575.42 MHz ± 3 MHz| |max DC current|15 mA| |DC Voltage |2.7 V - 5 V| The specification of the SUPERSTAR II card are depicted in Table 3-7. Table 3-7 Specifications SUPERSTAR II card [20]

The SUPERSTAR II card allows the use of an active antenna, which can be configured by connecting pin 1 to VCC. The selected antenna is suitable for the SUPERSTAR II card since both components have the same impedance. This is important to prevent reflection and power loss.
Modern computers don't have a RS232 connection any more. By using a USB to RS232 converter, the GNSS can be connect to the PC. The FT232 suits the best for this job. In Figure 3-10 the connections of this IC are shown.

Figure 3-10 Connection scheme FT232

There are two useful programs that can be used to read and write to the GNNS sensor:

• Putty: data logger;
• StarView: developed for the SUPERSTAR II.

The first time Starview was used. This is a very useful program, but its only made for the SUPERSTAR II. After connection is made with the GNSS sensor and the voltage is put on, the following text appears (Table 3-8)

Table 3-8 Start text SUPERSTAR II card

There can been chosen between two communication modes:

• NMEA mode;
• Binary mode.

The option used in this project is the NMEA mode. The main reason for this is that it is easy to read without any conversion and in 1 message, all the necessary data is collected. Because the GNSS doesn't find any satellites inside, there needs to be looked for a way to use the GNSS sensor outside without needing a power supply. In LSA they have a lot of batteries. These batteries have a voltage of 12 V. This voltage has to be transformed first to 3.3 V, before it can be used with the GNSS sensor. By using a PTH12000 the voltage can be transformed to 3.3 V. In Figure 3-11 the connections are presented.

Figure 3-11 Connection scheme of the PTH 12000W [22]
Resistor Rset determines the output voltage. The following formula (Figure 3-12) determines the value of Rset in function of the output voltage.

Figure 3-12 formula PTH12000W [22]

Table 3-9 Unknown parameters for the Rset formula [22]
^Pt. No.^PTH12000W^ |Vmin|1.2 V| |Rs|1.82 kΩ| The determined value of Rset with the values of Table 3-9 is 2 kΩ. ===3.4.2 Input commands === The most important task of the GNSS is to send recommended data when asked for it. The selection of the communication protocol, configuration mode, etc. will be programmed in advance so that this normally never has to change. This will be done with the program Starview. That's why only the command for requesting data will be explained. The GNSS is configured with the program Starview, that will send data only when asked. The command that is used for requesting data is 'Request Log command'.

Request Log command
This message requests only one transmission of the NMEA log that is specified (Figure 3-13).

Figure 3-13 Request log command [23]

example:
Request the time and date:
$PMCAG,004,ZDA*33

In NMEA mode the Sentence identifiers shown in Table 3-10 are available:

Table 3-10 Possible identifiers request log command [23]

The second part of the contents of data fields is the hh field. This is the NMEA checksum. The checksum field consists of a and two hex digits representing an 8 bit exclusive OR of all characters of the message, but not including, the $ and . To clarify an example:
Supposing that this message is received $PMCAG,004,90653 witch mean requesting the data Bearing, distance and delta-elevation to waypoint. The checksum of this example is 53, which results from calculating the XOR of every character except the $ and : 53=50⊕4D⊕43⊕41⊕47⊕2C⊕30⊕30⊕34⊕2C⊕39⊕30⊕36.

On all of the above given commands there is a response. In Table 3-11 all the responses to the commands are given.

Table 3-11 Responses on the request log command [23]