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

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]

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

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]

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]

The determined value of Rset with the values of Table 3-9 is 2 kΩ.

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,906*53 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]

Only the relevant output logs for this project will be explained in detail. If more information about another output log is needed, take a look to the SUPERSTAR II Firmware Reference Manual [23].

Output log Navigation Status

Figure 3-14 Output log navigation status [23]

The command shown in Figure 3-14 is only used in start up. The purpose of this command is to check if the SUPERSTAR II is initialized. When the SUPERSTAR II is initialized the other commands will give a correct response.

• GPS Fix Quality Indicator:
  • L (Low): navigation solution is obtained from less than 5 satellite measurements;
  • H (High): navigation solution is obtained from at least 5 satellite measurements:
• Navigation modes:
  • 3DD: 3-D fix with differential aiding;
  • 3-D: 3-D fix;
  • 2DD: 2-D fix (constant altitude) with differential aiding;
  • 2-D: 2-D fix (constant altitude);
  • D-R: Dead-Reckoning;
  • INI: Initialized (last good fix or external initialization);
  • NCD: No Computed Data. Fix data is not valid and should be ignored The receiver does not have a valid time and/or a valid position (from last good fix or external initialization).

Output log GGA


Figure 3-15 Output log GGA command [23]

• Horizontal Dilution of precision (HDOP): the best value is between 1 and 5. Bigger than 10 is bad.
• 1: May be different from number in view, the best value is >= 4;
• 2: GPS Quality indicator:
  • 0 = fix not available or invalid, these values needs to be deleted;
  • 1 = GPS fix;
  • 2 = Differential GPS fix;
• 3: Longitude with respect to WGS-84. (3-digit degrees, 2-digit minutes, 4-digit decimal fraction minutes);
• 4: Latitude with respect to WGS-84. (2-digit degrees, 2-digit minutes, 4-digit decimal fraction minutes).

Output log GLL


Figure 3-16 Output log GLL command [23]

• 1: Status:
  • A = Data Valid;
  • V = Data Invalid;
• 2: Longitude with respect to WGS-84 (3-digit degrees, 2-digit minutes, 4-digit decimal fraction minutes);
• 3: Latitude with respect to WGS-84 (2-digit degrees, 2-digit minutes, 4-digit decimal fraction minutes).

Output log ZDA


Figure 3-17 Output log ZDA command [23]

In a perfect situation an accuracy of less then 5 m is possible. The chance that this happens is really small. There are environmental and system errors, such as:

• Ionospheric group delays;
• Tropospheric refraction delays;
• Satellite clock errors;
• Receiver clock errors;
• Multipath signal reception/

To check the dispersion of the received values, the data was logged for 12 hours. If the dispersion is to large, the average value of an x-number of data is calculated. The command 'GGA' is used because it gives the most feedback. 3 data fields are used to take a look at the dispersion:

• Latitude;
• Longitude;
• Altitude.

After making a script in Matlab it was easy to collect all the data, verify the data, calculate the necessary values, and plot the data. The used Matlab script is in the topic Deliverables.
First of all the logged data is plotted. But before plotting, all the data where the quality indicator is smaller than 1 is replaced by the first previous correct value. The result is visible in Figure 3-18.

Figure 3-18 Plot all measured samples

The dispersion is too big to have an accurate position and altitude. In the 'GGA' response there is the value that represents how many satellites are used to define the value. Lets implement this value in the plot and look if there is a difference (Figure 3-19). Such as explained in subsection 3.4.3, the best value for this parameter is bigger or the same as 4.

Figure 3-19 Plot of all the samples taking into account the SVs value

The difference is small, so it was checked if there is a way to make the data more accurate. Lets take a look to the plot if the HDOP is implemented. For this plot all the DHOP values bigger than 4.8 are replaced by the first previous correct value (Figure 3-20).

Figure 3-20 Plot of all the samples taking into account the SVs and DHOP value

The dispersion of the data is smaller but still not accurate enough. Too many values are to far away from the average value. By taking the average of x values, it was tried to make the deviation small. 3 different values of the quantity samples are investigated. In Figure 3-21 5 samples are used, in Figure 3-22 10 samples are used and in Figure 3-23 20 samples are used.

Figure 3-21 Plot of average of 5 samples taking into account the SVs and DHOP value


Figure 3-22 Plot of average of 10 samples taking into account the SVs and DHOP value


Figure 3-23 Plot of average of 20 samples taking into account the SVs and DHOP value

It was concluded that 5 samples is to little. 10 and 20 give the most chance to have an exact value of the position. Most samples are on the average value of all the samples. For this project an average of 10 samples is used. This can be easily changed in the future.
Figure 3-24 is made with a program specially made for implementing and plotting NMEA data.

• green: the last sample;
• black: the average value of the dataset;
• magenta: the standard deviation of the dataset.

Figure 3-24 Plot of all the samples with the program NMEA web interface

First approach
Before the UART driver can be used, it has to be initialized first. The state diagram of this is given in Figure 3-25 and the code for this is given in Figure 3-26/

Figure 3-25 UART state machine driver [19]


Figure 3-26 UAR code driver

The diagram in Figure 3-27 describes the transmitter state machine; the diagram is valid while the driver is in the UART_READY state. The fitting code for this diagram is shown in Figure 3-28. This state machine is automatically reset to the TX_IDLE state each time the driver enters the UART_READY state.

Figure 3-27 UART state machine transmitter[19]

Figure 3-28 Code transmitter UART

The diagram in Figure 3-29 describes the receiver state machine; the diagram is valid while the driver is in the UART_READY state. The fitting code for this diagram is shown in Figure 3-30. This state machine is automatically reset to the TX_IDLE state each time the driver enters the UART_READY state.

Figure 3-29 UART state machine receiver [19]

Figure 3-30 UART code receiver

This works perfect if the GNSS sensor is active and never turned off. The problem begins when the GNSS sensor is started up. Because the UART driver is used, the received data needs to be a specific quantity of data. In the beginning the data fields are empty, so the quantity of the data is different than when the GNSS sends the complete message with all the necessary data. Normally this won't give a problem. When looking to the datasheet of the GNSS sensor, the startup time is at least 45 seconds for a warm start and 166 seconds for a cold start. To make sure the measured data is correct, a safety is build in. There is checked when the STARVIEW II isn't in initialization fase. This is checked with the command Navigation Status. The GNSS always sends a complete message then. In all the tests that were performed it always worked perfect. But to optimize the program, the serial driver can be used. The data is buffered first so there can be one byte read at time. So when the receiver detects a $ it starts reading till a \r\n is detected.
Flowchart first approach

Figure 3-31 Flowchart GNSS sensor

The flowchart of the code from the GNSS sensor is shown in Figure 3-31. With the use of a virtual timer ever x s a interrupt is generated and the program will jump to the code of the GNSS sensor. In the beginning the status of the GNSS is checked. While the status of the GNSS sensor is still in initialization fase the part of the program of the GNSS sensor will wait. When the GNSS sensor is initialized the STM32F3 discovery board will ask the GNSS sensor for the GGA output log. Once the response is received, the necessary checks are performed as explained in subsection 3.4.4. The relevant data is stored. When there are 10 samples, the average value is calculated of the samples and send to the SD-card, where it is written to the CSV file on the SD-card.

Second approach
For using the serial driver, activate it in the halconf.h file. Also go to the mcuconf.h file to activate 'STM32_SERIAL_USE_USART2 '

use the following code to start the serial connection (Figure 3-32).

Figure 3-32 Initialization of serial driver

Here the standard setup for the port is used. The standard baudrate is 38 400. The baudrate can be changed in the halconf.h (Figure 3-33)


Figure 3-33 Code Standard Baudrate serialport in halconf.h file

Once the STM32F3DISCOVERY is programmed, the commands described above are tested to see if it works . The STM32F3DISCOVERY is programmed with the command to ask the time and date. This command will be sent every 5 seconds. Only the TX pin of the STM32F3DISCOVERY is connected to the RX port of the GNSS. An extra pin is placed between this connection. This pin we're going to use to connect it with an logic analyzer. The TX pin of the GNSS sensor will also be connected to the logic analyzer.

Signals UART interface

Figure 3-34 Signals UART communication

The STM32F3DISCOVERY is sending a command and the GNSS sensor is responding. When zoomed in, it can be checked that the values sent are the expected values.\\
Signal TX

Figure 3-35 Output UART STM32F3 discovery board

This signal is the output of the STM32F3DISCOVERY, so the input of the GNSS. The command that is sent satisfy the conditions explained in the part about the commands.

Signal RX

Figure 3-36 Input UART STM32F3 discovery board
This signal is the output of the GNSS sensor. The command that is sent satisfies the conditions explained in the part about the commands.

Figure 3-37 SD-card [24]
An SD-card adapter is used in this project to plug the SD-card in (Figure 3-37). The SD-card that is used in this project has a capacity of 8 GB, so it supports FAT 32. To access the SD-Card SPI is used. SPI uses only 4 wires (chip-select, MOSI, MISO, SCK). First the working of SPI is going to be explained. Once this is understood, the working of the SDC is explained.

SPI stands for Serial Peripheral Interface. Because of the high transfer rate of 20 Mbps or faster, it is mainly used for internal communication, memory, etc. In this project for the internal communication between the STM32F3 and the SDC.

Figure 3-38 SPI connections [25]

In SPI there are 3 signal lines, and 1 additionally signal. In figure 3-38 the signals are shown, these are:

• Serial Clock (SCLK)
• Master-In Slave-Out (MISO)
• Master-Out Slave-In (MOSI)

The additional signal is Slave Select (SS), must be replicated for every slave connected to the bus. With the SS a slave can enabled or disabled. Every SPI bus has a single master and one or more slaves. The STM32 can be configured in either role, but in this project the STM32 is the master. All communication is controlled by the master.The master selects the slave it wishes to communicate with by lowering the appropriate SS line, and then causes a single word (commonly one byte) to be transferred serially to the slave over the signal MOSI and simultaneously accepts a single byte from the slave over the signal MISO . This transfer is realized by generating 8 clock pulses on the signal SCLK.

Figure 3-39 SPI connection with shift register [25]
This behavior can be visualized by a pair of linked shift registers, as illustrated in figure 3-39. SPI got four possible clock modes (Figure 3-40)

Figure 3-40 SPI modes [26]

for the SDC we need to use mode 0 (CHPA=0 and CPOL=0)

Testing
The configuration of the SPI port is shown in table 3-12:
Table 3-12 Pin configuration SPI port

A logic analyzer is used to look if the SPI works.

Figure 3-41 Test signals SPI
In figure 3-41, the enable signal (SS) is low, so the slave is selected. After 8 clock pulses a complete byte is send to the slave (MOSI).

Now that the SPI interface works it's time to take a look to the SD-card. By using a SD-card the user can always access the memory, and can store more data. In figure 3-42 the pin out of the SDC is given.
pin layout

Figure 3-42 Connections SD-card [27]
The micro SDC has 8 pins. In SPI mode, only 6 signals are used. Like discussed in the chapter above, there are the 4 basic signals for SPÏ:

• DO (MISO)
• DI (MOSI)
• SCLK
• CS (SS)

The other two signals are used to provide the SD card with power. The supply voltage for the SDC is 3.3 V. A additional signal is used here the card detect (CD) signal. The card have a file system, in this case its FAT32 because the size of the SD card is bigger then 2 GB. The SD card consist of a flash memory and a control processor which communicates with a host over the SPI bus. Ihe host send a command message to the SD card and receives a response. To access the data stored on the SD card, we need to use file level commands for example open, read, write, etc. Luckily, these commands are provided by the FAT generic file system.

Figure 3-43 Fatfs organization [25]

• ffconf.h Configuration file for FatFs module.
• ff.h Common include file for FatFs and application module.
• ff.c FatFs module.
• diskio.h Common include file for FatFs and disk I/O module.
• integer.h Alternative type definitions for integer variables.
• option Optional external functions.

When the disk is initialized it can be read, written and control. The SDCard communication protocol is transaction based. Each transaction begins with a one-byte command code, optionally followed by parameters, and then a data transfer (read or write).
Insertion and removal event

Figure 3-44 Flowchart of what happens when SDC is inserted or removed
Before the SDC can be used it has to be mounted en initialized. The flowchart of this process is shown in figure 3-44. The tmrfunc is called every 10 ms. The first thing that happens is checked in witch state the SDC is. The check can only be performed while the driver is not in a transfer state because, this could disturb the transfer. A counter is used, to check if the SDC is inserted for 100 ms. If the counter is 0 without that the SDC is inserted, there is checked if there is a SDC inserted. If this isnt the case the program will jump to the RemoveHandler if the SDC is unmounted will it was mounted first. The SDC driver will be disconnected and the Boolean fs_ready is false. If the SDC is mounted for 100 ms, and the state of the CD has changed in this 100 ms. The function inserthandler is called. The first thing that happens in this function is checking if the SDC is already initialized is this the case the program will jump back to tmrfunc. In the other case the program will try to mount the SDC. When this is successful the program will go back to tmrfunc and a Boolean fs_ready will set on true to indicate that the SDC is ready to be used. If there went something wrong the program will jump to the tmrfunc again.
When the SDC is ready to use, there can be written and read from the SDC. The file needs to be open first before it can be manipulated. Never forget to close the file, if it isn't used anymore. Otherwise if there is something written to the SDC the write command may not happen.

The STM32F3DISCOVERY and the BeagleBone Black board will communicate with each other by using a serial connection. A protocol is needed in order to manage this communication. The protocol applies on the STM32F3DISCOVERY and the BeagleBone Black board as well; therefore, the determination of the protocol was a joint work.
On the following picture the general overview of the protocol can be seen.

Figure 3-45 Protocol overview

In the diagram above the possible commands that can be sent are shown. At the right side there are the commands received by the STM32F3 Discovery development board (STM32F) , at the left side there are the commands received by the BeagleBone Black board (BBB).

In what follows the protocol will be more detailed.

Commands and errors/approval

Figure 3-46 shows how the data package used for commands and errors will look like.

Figure 3-46 Data package for commands and errors/approval

The meaning of the abbreviations is the following:

SOH: indicate, the start of the package, the $ (24 hexadecimal) is chosen to indicate this start of the package.
After the $ an identity number is needed to indicate which information will be send in the data.
ID#:

Figure 3-47 ID# commands and errors

remark: The ID# isn't chosen randomly, there is some logic behind it.
The first number of the ID# for:

• modes starts with a 1
• coordinates starts with a 2
• the wind sensor starts with a 3
• the CTD sensor starts with a 4
• the Combination and Stop command are starting with a 6
• errors starts with a 8
• message ok if it starts with a 9
  

ID# compl: this is the first-compliment of the ID# field, this will verify the ID#;
Data Length: this number will indicate how long (how many bytes the data will be). If the message ID is 10 (Regatta mode), 14 (environmental mode), 99 (Message OK) or 67 (Stop command) the Data length will be 0;
EOH: to indicate the end of the data (End Of Header) a star-sign is used, this will also indicate the start of the checksum;
Checksum: a 16 bit sum (8 bytes) of the complete command is taken to verify the entire package. If there is an overflow in the calculation the package is discarded immediately;

Data

In order to make a distinction between the packages for commands/errors and the packages for data, the packages will be different; this can be seen on the next figure.

Figure 3-48 Data package for data

As can be seen on the figure above, the entire package can contain data from different sensors. Every data package will be separated from each other by the ID#. SOH, ZDA, Time/date, EOH, Chechsum and CR)/LF are only ones sent in one entire package. The number of ID# and data packages dependents on the data logging request (of how many or which sensors is the data asked). The meaning of the abbreviations SOH and EOH stays the same.

The meaning of the abbreviations are the following:
SOH: same meaning as for the commands/errors package; this will indicate the start of the package, the $ (24 hexadecimal) is chosen to indicate this start of the package;
ZDA: after the ZDA-sign the time and date of the data capture are send, so this indicated the beginning of the time and date;
Time, date: this is the time and date of when the data is captured;
ID#: like for the command/error package an ID# is needed to indicate which information will be send in the data.

Figure 3-49 ID# data
In Figure 3-49 the different ID# data abbreviations are listed. EOH: same meaning as for the commands/errors package; to indicate the end of the data (End Of Header) a star-sign is used, this will also indicate the start of the checksum;
Checksum: also same meaning as for the commands/errors package; a 16 bit sum (8 bytes) of the entire package is taken to verify the entire package. If there is an overflow in the calculation the package is discarded immediately;
CR/LF: LF stands for Line Feed or new line and CR for carriage return (ASCII characters), this well provide a clearer overview of the different packages when consulting them after each other.

All commands separate
In what follows all the different commands are listed. All the values, expressed in hexadecimal of the abbreviations are listed of every command.
The mode commands (Regatta mode and Environmental mode) and error/approval commands (SDC not connected, GNSS not connected, Wrong command, Wrong data, Message ok, Stop command) don't carry any data, therefor their Data Length is 0. All the other commands contain the same abbreviations as a standard command package (Figure 3-47 Data package for commands and errors/approval).

Regatta mode
On Figure 3-50 the data package for the Regatta mode command is shown.

Figure 3-50 Regatta mode command

SOH: $
ID#: 10
ID# compl: EF
Data Length: 0
EOH: *
Checksum: 14D

This gives the following command for the Regatta mode:
Command: 2410EF0*14D

Environmental mode
On Figure 3-51 the data package for the Environmental mode command is shown.

Figure 3-51 Environmental mode command

SOH: $
ID#: 14
ID# compl: EB
Data Length: 0
EOH: *
Checksum: 14D

Command: 2414EB0*14D

SDC not connected

On Figure 3-52 the data package for the SDC not connected command is shown.

Figure 3-52 SDC not connected command

SOH: $
ID#: 82
ID# compl: 7D
Data Length: 0
EOH: *
Checksum: 14D

Command: 24827D0*14D

GNSS not connected
On Figure 3-53 the data package for the GNSS not connected command is shown

Figure 3-53 GNSS not connected command

SOH: $
ID#: 84
ID# compl: 7B
Data Length: 0
EOH: *
Checksum: 14D

Command: 24847B0*14D

Wrong command
On Figure 3-54 the data package for the Wrong command, command is shown.

Figure 3-54 Wrong command, command

SOH: $
ID#: 86
ID# compl: 79
Data Length: 0
EOH: *
Checksum: 14D

Command: 2486790*14D

Wrong data

On Figure 3-55 the data package for the Wrong data, command is shown.

Figure 3-55 Wrong data command

SOH: $
ID#: 88
ID# compl: 77
Data Length: 0
EOH: *
Checksum: 14D

Command: 2488770*14D

Message ok

On Figure 3-56 the data package for the Message OK command is shown.

Figure 3-56 Message ok command

SOH: $
ID#: 99
ID# compl: 66
Data Length: 0
EOH: *
Checksum: 14D

Command: 2499660*14D

Stop command
On Figure 3-57 the data package for the Stop command is shown.

Figure 3-57 Stop command

SOH: $
ID#: 67
ID# compl: 98
Data Length: 0
EOH: *
Checksum: 14D

Command: 2467980*14D

Remark: the Data length is not used correctly in the following commands. It's not to indicate the Data length, but it's to indicate if there's data needed from one date (indicated by a 1) or between two dates (indicated by a 2). Therefore the name of this field should be changed.

Coordinates

On Figure 3-58 the data package for the Coordinates command is shown.

Figure 3-58 Coordinates command

SOH: $
ID#: 23
ID# compl: DC
Data Length: Data Length: number 1 indicates one date and number 2 indicates data which stands for a date between two dates
Data: hhmmss.ss,DD,MM,YYYY for data from 1 date and for data between 2 dates hhmmss.ss,DD,MM,YYYY,hhmmss.ss,DD,MM,YYYY

EOH: *
Checksum: Depends on the data value

Command: 2423DC….*..

Wind speed

On Figure 3-59 the data package for the Wind speed command is shown.

Figure 3-59 Wind speed command

SOH: $
ID#: 31
ID# compl: CE
Data Length: Data Length: number 1 indicates one date and number 2 indicates data which stands for a date between two dates
Data: hhmmss.ss,DD,MM,YYYY for data from 1 date and for data between 2 dates hhmmss.ss,DD,MM,YYYY,hhmmss.ss,DD,MM,YYYY

EOH: *
Checksum: Depends on the data value

Command: 2431CE….*..

Wind direction
On Figure 3-60 the data package for the Wind direction is shown.

Figure 3-60 Wind direction command

SOH: $
ID#: 36
ID# compl: C9
Data Length: Data Length: number 1 indicates one date and number 2 indicates data which stands for a date between two dates
Data: hhmmss.ss,DD,MM,YYYY for data from 1 date and for data between 2 dates hhmmss.ss,DD,MM,YYYY,hhmmss.ss,DD,MM,YYYY

EOH: *
Checksum: Depends on the data value

Command: 2436C9….*..

Depth water
On Figure 3-61 the data package for the Depth water command is shown.

Figure 3-61 Depth water command

SOH: $
ID#: 41
ID# compl: BE
Data Length: Data Length: number 1 indicates one date and number 2 indicates data which stands for a date between two dates
Data: hhmmss.ss,DD,MM,YYYY for data from 1 date and for data between 2 dates hhmmss.ss,DD,MM,YYYY,hhmmss.ss,DD,MM,YYYY

EOH: *
Checksum: Depends on the data value

Command: 2442BE….*..

Conductivity water
On Figure 3-62 the data package for the Conductivity water command is shown.

Figure 3-62 Conductivity water command

SOH: $
ID#: 45
ID# compl: BA
Data Length: Data Length: number 1 indicates one date and number 2 indicates data which stands for a date between two dates
Data: hhmmss.ss,DD,MM,YYYY for data from 1 date and for data between 2 dates hhmmss.ss,DD,MM,YYYY,hhmmss.ss,DD,MM,YYYY

EOH: *
Checksum: Depends on the data value

Command: 2447BA….*..

Temperature water
On Figure 3-63 the data package for the Temperature water command is shown.

Figure 3-63 Temperature water command

SOH: $
ID#: 49
ID# compl: B6
Data Length: Data Length: number 1 indicates one date and number 2 indicates data which stands for a date between two dates
Data: hhmmss.ss,DD,MM,YYYY for data from 1 date and for data between 2 dates hhmmss.ss,DD,MM,YYYY,hhmmss.ss,DD,MM,YYYY
EOH: *
Checksum: Depends on the data value

Command: 2447B6….*..

Combination
On Figure 3-64 the data package for the Requesting data Combination command is shown, this command is used when several commands are combined into one data package.
Figure 3-64 requesting data Combination command
SOH: $
ID#: 62
ID# compl: 9D
#Data: defines how many ID# and ID# compl will follow
ID# and ID# compl: can appear more then once. Depending on how much different data's that the user wants.
Data Length: Data Length: number 1 indicates one date and number 2 indicates data which stands for a date between two dates
Data: hhmmss.ss,DD,MM,YYYY for data from 1 date and for data between 2 dates hhmmss.ss,DD,MM,YYYY,hhmmss.ss,DD,MM,YYYY
EOH: *
Checksum: Depends on the data value

Protocol Diagrams are drawn in order to visualize the protocol. This shows the different massages/packages that can be sent between the Base Station (BS), the BeagleBone Black board (BBB) and the STM32F3DISCOVERY. The diagram has to be read from top to bottom. By starting from the first arrow, witch represents a message, the second arrow is a result of the previous one. It will therefore show how they communicate with each other.

The first Protocol Diagram starts by a data command that has been sent by a Base Station (BS) to the BeagleBone Black Board (BBB)(Figure 3-65).

Figure 3-65 Protocol Diagram when Command has been sent

The Protocol Diagram from Figure 3-65 explained in different steps:

1. BS sends a Command data to the BBB
2. BBB receives it and sends this command data to the STM32F3 and a Message OK responds to the BS
3. after a defined time (Time-out) the BBB didn't receive a Message OK respond from the STM32F3, there must happened something to the command data. Therefore the BBB sends it again.
4. STM32F3 receives the command data, but there happened something with the package because it's not a know command. The STM32F3 sends therefore a Wrong command message to the BBB.
5. BBB receives this wrong command and sends the command data again.
6. STM32F3 now receives and knows the command. The STM32F3 sends therefore a Message OK to the BBB.
7. BBB receives this Message OK and now know that the STM32F3 received the message well.
8. STM32F3 sends after the Message OK the Data (Data 1) which was asked
9. BBB receives Data 1 and sends it to the BS. The BBB sends a Message OK to the STM32F3 to let him know the message is well received.
10. BS also sends a Message OK to the BBB after a good receive.
11. STM32F3 sends now Data 2
12. BBB receives wrong data and sends as answer Wrong data to the STM32F3
13. STM32F3 receives this Wrong data command and sends therefore Data 2 again.
14. BBB receives Data 2 and sends it to the BS
15. before the BS receives Data 2, it sent a Command stop data and a new Command data to the BBB (the BS wants other information). The BBB receives this Command stop data and sends therefore a Message OK to the BS. The BBB sends this Command stop data and Command data to the STM32F3. The Command data gives the STM32F3 new information about the Data.
16. STm32F3 sends now the asked asked data (Data 1) to the BBB
17. BBB receives this data and sends this data on his turn to the BS. The BB also sends a Message ok to the STM32F3.
18. BS receives Data 1 correctly and sends therefore also a Message ok to the BB.
19. this communication continuous until the BS sends a Command stop data to the BBB

The second Protocol Diagram starts by a mode command (the BS wants to change the mode) that has been sent by a Base Station (BS) to the BeagleBone Black Board (BBB)(Figure 3-66).

Figure 3-66 Protocol Diagram when a Mode has been sent

The Protocol Diagram from Figure 3-66 explained in different steps:

1. BS sends Command mode to the BBB
2. BBB received the Command mode well and sends a Message OK as confirmation to the BS. At the same time the BBB sends this Command mode to the STM32F3
3. BBB didn't receive a Message ok after a defined time (Time-out) and sends the command mode therefore again.
4. STM32F3 receives a wrong command (there went something wrong with the package) as answer he sends Wrong command to the BBB.
5. BBB receives the Wrong command and sends therefore the Command mode again
6. STM32F3 received Command mode correctly and sends a Message OK to the BBB

The third Protocol Diagram shows the error that can appear when the STM32F3 didn't receive a Message ok from the BBB (Figure 3-67). This error arises when the STM32F3 didn't send the data from one of the senors to the BBB.

Figure 3-67 Protocol Diagram when STM32F3 didn't receive a Message ok from the BBB

The Protocol Diagram from Figure 3-67 explained in different steps:

1. after a defined time the STM32F3 didn't receive a Message ok from the BBB. The BBB didn't receive the package, a sensors must be not connected.
2. STM32F3 sends therefore a not connected command to the BBB
3. BBB receives this command and sends this not connected command to the BS. The BBB also sends a Message OK to the STM32F3.
4. BS receives the not connected command and sends therefore a Message ok to the BBB

The last protocol diagram shows the solution than can be integrated in the BBB when it doesn't have a connection with the STm32F3. This is not related with the protocol between the BBB and the STM32F3 and is therefore not mentioned in the Protocol overview.

Figure 3-68 Protocol Diagram when the BBB doesn't have a connection with the STM32F3

The Protocol Diagram from Figure 3-28 explained in different steps:

1. BS sends a Command mode to the BBB
2. BBB sends this Command mode to the STM32F3
3. After 3 Time-outs the BBB still didn't receive a Message ok from the STM32F3. This must be a result of a bad connection between the BBB and the STM32F3.
4. BBB sends therefore after the third Time-out a STM not connected command to the BS
5. BS receives this command well and sends therefore a Message ok to the BBB

Remark: This is just a suggested solution that can be integrated Remarks according to the defined protocol:

1. a protocol diagram should be drawn which figures a timeout between BS and the BBB, this because the probability of arising this timeout is very high.
2. one's complement is not necessary since the checksum will already verify the whole package, it should be therefore discarded.

There was not enough time left to implement this protocol. But the communication between the Beagle BoneBlack and the STM32F3 discovery board is already established.

Figure 3-69 Complete scheme
Because of the problems of broken wires and bad connection, there is decided to make a PCB to make the project setup more reliable. The scheme is shown in figure 3-69. All the different parts will be discussed in this chapter, but the function of the most parts are already discussed in the previous chapters.

Figure 3-70 Scheme of the mutiplexer and demultiplexer
The UART connections are limited, to expand the UART connection a multiplexer and demultiplexer is used. The scheme of this 2 components is shown in figure 3-70. The multiplexer is used for the RX signal, while the demultiplexer is used for the TX signal Both components can be connected to 8 different components. One connection of each port is already connected to the SUPERSTAR II. With B10,B9 and B3 the output or input signal is selected.
Table 3-13 Truth table Demultiplexer

Table 3-14 Truth table Multiplexer

Figure 3-71 Scheme power supply
A battery is used as power supply for this PCB. The battery's have a voltage of 12 V.There are 2 different voltages needed on this board. In the first place 3.3 V is needed for the GNSS sensor. For the multiplexer and demultiplexer 5 V is needed. For the 3.3 V the PTH 12000 is used. This IC was already used in the beginning, as explained in chapter 3.3.1 . Due to a fault in the library of the drawing tool the symbol isn't 100% correct. VOADJUST = VOU and EPAD=VOUT. For the 5 V a standard voltage regulator is used. The reference of this voltage regulator is 7805. The voltage needed for the the SD-card is delivered by the STM32F3 discovery board. The scheme of both voltage converters is shown in figure 3- 71.

Figure 3-72 Connections FT232
This IC (Figure 3-72) converts RS232 to USB and vice-versa. The converter can fulfill 2 tasks.

• when R4 and R5 are placed the GNSS signal is connected to the converter
• when R6 and R7 are placed the signal connected to X11 is connected to the converter

Led 1 indicates if there is a TX signal while led 2 indicates if there is a RX signal.

Figure 3-73 Connection STM32F3 discovery board
In table 3-15 The connection of figure 3-73 will be explained
Table 3-15 Overview of the connection between STM32F3 and other components

Table 3-16 Overview components PCB board

Figure 3-74 Different views PCB
1: Copper bottom
2: Components and jumpers top view
3: Components bottom
4: All components and jumpers

Software development for the STM32 microprocessor with ChibiOS

This chapter, all the tools used in this project will be explained.First there is shown how to use ChibiOS and to integrate ChibiOS in Eclipse. Ofcourse other development tools can be used but ChibiOS recommend Eclipse. The other program explained in this chapter is STARVIEW. The operating system that is used in this guide is Windows.

This a complete version of Eclipse where the most tools to use ChibiOS are include as a lot of demo projects. This is the easiest way to get started with ChibiOS.

• Download Chibistudio (download link at the end of this chapter)
• Unzip it
• This is a 32 bit version. So make sure the java development kit installed on the computer is 32 bit

• Download ChibiOS.
• Unzip ChibiOS, then choose the folder.
• Download yagarto and install it.
• Download yagarto tools and install it.
• Add the path ”<install_dir>\yagarto-20121222\arm-none-eabi\bin” to the environment PATH variable.
• Add the path ”<install_dir>\yagarto-tools\bin” to the environment PATH variable.

If it is preferred to use ChibiOS without Eclipse, Notepad++ can be used to change the source code.

• Download Notepad++.
• Edith the code with Notepad++, here the demo code of ChibiOS for the STM32F303-discovery board is used.
• Open cmd, and do” cd <install_dir>\ChibiOS 2.6.0/demos/ARMCM4-STM32F303-DISCOVERY/ “ to go to the folder of the code.
• Do make
• A new folder is created inside the folder, called build.
• To program the board there are two options:
  • Use the following command in cmd: st-flash write build/ch.bin 0x8000000
  • Use the program “STM32 ST-LINK Utility”.

• Make sure that Java is installed.
• Create a directory and unzip Eclipse.
• It can be useful to create a shortcut on the desktop.
• At startup, when Eclipse asks for a workspace directory, select the ChibiOS root directory (Figure 4-1).
  

Figure 4-1 Select a workspace Eclipse

• Unselect “Project ⇒ Build Automatically” to prevent insanity
• Let Eclipse auto update “Help ⇒ Check_for_Updates”.
• Unordered List ItemInstall the “C/C++ Hardware debugging “Help ⇒ Install New Software…” change “work with” to “Indigo - http://download.eclipse.org/releases/indigo” scroll to “Mobile and Device Development” and select “C/C++ Hardware debugging “ (Figure 4-2)
  

Figure 4-2 add software to Eclipse

• Go to “Window ⇒ Preferences” go to “C/C++ ⇒ Code Analysis” at the left and disable everything, if not there will be a lot of Errors and Warnings.
• Go to “C/C++ ⇒ New CDT Project Wizard ⇒ Makefile Project”, go to the tab “Discovery Options”, select “Automatic Discovery of paths and symbols” and then “GCC per project scanner info profile”.
• Select the “Behaviour” tab and unselect “Use parallel build” then “Use optimal jobs number”
• At the left tree go to “Run/Debug ⇒ Launching ⇒ Default launchers”. Select “GDB Hardware Debugging ⇒ [debug]” and select “Standard GDB Hardware Debugging Launcher” (Figure 4-3)
  

Figure 4-3 Select debugger Eclipse in preferences

• Click on “Apply” and close the dialog. These setting will be always used if a new project is started.

This software cant be downloaded anymore, but in LSA they still have the software. If needed ask the software there.
Once te program is open go to File/Port and click on Serial Port. The next window will open (Figure 4-4), here can the comport and the baudrate be selected.

Figure 4-4 Configure serial port in starview
After a connection is made with the serial port, the GNSS can be put in Binary mode or NMEA mode. Under the menu balk of Xmit Msg is a button called protocol diagram. When clicking on it the screen shown in figure 4-5 pops up.

Figure 4-5 Configure protocol in starview
When the current mode of the GNSS sensor isn't know click on 'Force to binary, 9600 b/s' and the mode of the GNSS will go into Binary. If the mode needs to be in NMEA open it again and check in Current setting 'Binary' and in desired setting 'NMEA' and click on OK

Figure 4-6 Terminal in starview
To log the received data of the GNSS sensor the terminal screen can be opened as displayed in the figure 4-6.

Figure 4-7 Possible command for the SUPERSTAR II in starview
If a command needs to be send to the GNSS sensor click on Xmit Msg (figure 4-7) in the menu balk and select the command that needs to be send.

Figure 4-8 Continuous or one shot of the response in starview
Once the command is selected, the choose is given if the GNSS needs to response once ore continuous (Figure 4-8).

Figure 4-9 NMEA settings for the SUPERSTAR II
If the GNSS needs to send more then 1 response continuously its easier to go to Tool Setting and ten click on Set Defailt Msg list (Figure 4-9). Her a selection of the responses that the GNSS sends can be done. By selecting one Msg ID and putting the Rate on 0 the GNSS will stop sending this command.

ChibiOS: http://sourceforge.net/projects/chibios/
Notepad++: http://notepad-plus-plus.org/download/v6.5.1.html
Yagarto: http://sourceforge.net/projects/yagarto/
Yagarto tools: https://code.google.com/p/csud/downloads/detail?name=yagarto-tools-20121018-setup.exe&can=2&q=
STM32 ST-LINK Utility: http://www.st.com/web/en/catalog/tools/PF258168#
ChibiStudio: http://sourceforge.net/projects/chibios/files/ChibiStudio/

As told in the motivation, it was a big challenge to do a lot of programming work. And a challenge it was, it was mostly struggling in the beginning. In the first place research was done about what the other group had realized. Information was collected about the different components. Pretty soon there was a good overview of what was already realized and what has to be done. Sadly enough, a lot of time was lost in programming the STM32F3 disovery board. In the first place Chibios has to be discovered. With a minimum background of C this was a hard task. Step by step the working of Chibios and the integration in a project begin to get understandable. When I was able to master the working and intregration of chibios, there could be looked to the total project. The research of the working of the GNSS sensor could be done. With the help of the program STARVIEW and the datasheet the working of the GNSS sensor got clear. The difficult part of the program was the SD-card. A lot of different drivers had to be combined here, and there were a lot of conflicts. At the end of the project the connection between the SD-card and the STM32F3 dicovery board was a fact. The most instructive part of the project was working with another person for the protocol. Each person has his own vision of the protocol. Both people put there version of the protocol on paper and start to look what the advantages and disadvantages where of each protocol. at the end both visions where combined to get a good working protocol. Sadly enough there wasn't any time left to integrate the protocol into the STM32F3 discovery board. Only the connection between the 2 devices is established. Like told in the acknowledgement, this project is the work of a lot of people who supported and helped to get the the project to the point where it now is. But the development of the project doesn't stop here. Still a lot of work has to be done.

A lot of work is already established. But this project can still be continued. In the first place the protocol have to be completed. The protocol is already defined in chapter 3.6, but it have to be integrated in the STM32F3 discovery board.The GNSS sensor is controlled now by the STM32F3 discovery board. But there is the possibility that the sensor send every second the necessary data. How this can be done is already explained in chapter 3.45 in the part “second approach”. The test of the GNSS sensor are preformed in the city, and this gives a complete other view of the accuracy of the sensor then on the water. For this the test of the GNSS sensor have to be realized on the water. But this test can only be accomplished when the buoy is completely assembled. The only sensor programmed is the GNSS sensor, so the CTD and the wind sensor still have to be programmed. The working of the SD-card has to be updated so that it communicate correctly with the protocol. Of course the project can be enlarged. I'm thinking about adding solar panels, more sensors, etc.

[1] Wikipedia, Comma-separated values, 2014. Available at http://en.wikipedia.org/wiki/Comma-separated_values [Accessed in January 2014].
[2] http://en.wikipedia.org/wiki/Load_cell
[3] http://www.omega.co.uk/prodinfo/RTD.html
[4] http://en.wikipedia.org/wiki/Electrical_conductivity_meter
[5] http://www.nmea.org/content/nmea_standards/nmea_0183_v_410.asp
[6] http://en.wikipedia.org/wiki/Binary_protocol
[7] http://www.onsetcomp.com/what-is-a-data-logger
[8] http://www.geminidataloggers.com/data-loggers/tinytag-wireless
[9] http://www.oceanor.no/systems/seawatch/buoys-and-sensor/Seawatch-Midi-185
[10] http://www.geograph.org.uk/photo/449545
[11] http://www.jcommops.org/dbcp/platforms/types.html
[12] http://wallpaperbases.com/wallpapers/archives/3891/regatta-wallpapers-race-boat-wind-wave
[13] http://www.oceanor.no/related/Datasheets-pdf/SEAWATCH_Wind_LiDAR_Buoy.pdf
[14] http://www.oceanor.no/related/Datasheets-pdf/SW22_Seawatch_MIDI_185_FINAL.pdf
[15] http://www.eps2013-wiki3.dee.isep.ipp.pt/doku.php?id=report
[16] http://www.digikey.com/product-detail/en/STM32F3DISCOVERY/497-13192-ND/3522185
[17] http://chibios.org/dokuwiki/doku.php?id=chibios:architectures
[18] http://home.deib.polimi.it/bellasi/lib/exe/fetch.php?media=teaching:2012:rtos_chibios_handout.pdf
[19] http://chibios.sourceforge.net/html/index.html
[20] http://www.novatel.com/assets/Documents/Manuals/om-20000077.pdf
[21] pdf: GPS Active Antenna Specification (Model: GAACZ-A)
[22] http://www.ti.com/lit/ds/symlink/pth12000l.pdf
[23] http://www.novatel.com/assets/Documents/Manuals/om-20000086.pdf
[24] http://www.jameco.com/Jameco/Products/ProdDS/2110799.pdf
[25] http://www.cs.indiana.edu/~geobrown/book.pdf
[26] http://elm-chan.org/docs/spi_e.html
[27] http://elm-chan.org/docs/mmc/img/micro_contact.jpeg