Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
| wiki:site_notice [2014/01/17 15:20] – old revision restored epsatisep | wiki:site_notice [2021/03/23 11:23] (current) – external edit 127.0.0.1 | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | ====== Report ====== | + | **EPS@ISEP | The European Project Semester (EPS) at ISEP** |
| + | ---- | ||
| - | **Environmental/ | ||
| - | **\\ | ||
| - | **Author**: | ||
| - | Jeroen Vervenne \\ | ||
| - | |||
| - | ===== Acknowledgement | ||
| - | I would like to take this opportunity to thank all the people that made this Project/ | ||
| - | |||
| - | 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' | ||
| - | |||
| - | 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. | ||
| - | ===== Abstract ===== | ||
| - | These days Scientists know more about the universe than about the sea. Nevertheless, | ||
| - | |||
| - | 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. | ||
| - | |||
| - | ===== Glossary ===== | ||
| - | |||
| - | ^Abbreviation^ Description^ | ||
| - | |**Introduction**|| | ||
| - | |USB |Universal Serial Bus| | ||
| - | |LSA |Autonomous Systems Laboratory| | ||
| - | |**State of the Art**|| | ||
| - | |AC/DC |Alternating Current/ | ||
| - | |GPS | NAVSTAR Global Positioning System is a space-based satellite navigation system that provides location and time information in all weather conditions, anywhere on or near the Earth where there is an unobstructed line of sight to four or more GPS satellites| | ||
| - | |LCD |Liquid-Crystal Display is a flat panel display, electronic visual display, or video display that uses the light modulating properties of liquid crystals. Liquid crystals do not emit light directly| | ||
| - | |PCB |Printed Circuit Board mechanically supports and electrically connects electronic components using conductive tracks, pads and other features etched from copper sheets laminated onto a non-conductive substrate| | ||
| - | |PC |Personal Computer| | ||
| - | |SMS |Short Message Service is a text messaging service component of phone, web or mobile communication systems| | ||
| - | |e-mail | Electronic mail| | ||
| - | |GSM| Global System for Mobile Communications, | ||
| - | |GPRS| General packet radio service, is a packet oriented mobile data service on the 2G and 3G cellular communication system' | ||
| - | |UHF| Ultra-High Frequency designates the ITU radio frequency range of electromagnetic waves between 300 MHz and 3 GHz (3000 MHz), also known as the decimetre band or decimetre wave as the wavelengths range from 1 dm to 10 dm| | ||
| - | |VHF| Very High Frequency, is the ITU-designated range of radio frequency electromagnetic waves from 30 MHz to 300 MHz, with corresponding wavelengths of 1 m to 10 m| | ||
| - | |NMEA| National Marine Electronics Association is a US-based marine electronics trade organisation setting standards of communication between marine electronics| | ||
| - | |CTD| Conductivity, | ||
| - | |EPDM| Ethylene Propylene Diene Monomer| | ||
| - | |UV| Ultraviolet light is electromagnetic radiation with a wavelength shorter than that of visible light, but longer than X-rays, that is, in the range between 400 nm and 10 nm| | ||
| - | |GNSS|Global Navigation Satellite System, is a system of satellites that provide autonomous geo-spatial positioning with global coverage| | ||
| - | |OEM|Original Equipment Manufacturer, | ||
| - | |ASCII| American Standard Code for Information Interchange is a character-encoding scheme originally based on the English alphabet that encodes 128 specified characters - the numbers 0-9, the letters a-z and A-Z, some basic punctuation symbols, some control codes that originated with Teletype machines, and a blank space - into the 7-bit binary integers| | ||
| - | |SD| Secure Digital is a non-volatile memory card format, an evolutionary improvement over MultiMediaCards| | ||
| - | |IC |Integrated Circuit or monolithic integrated circuit, is a set of electronic circuits on one small plate (" | ||
| - | |GPIO| General Purpose Input/ | ||
| - | |SPI| Serial Peripheral Interface Bus, type of communication interface| | ||
| - | |UART| Universal Asynchronous Receiver/ | ||
| - | |**Project Development**|| | ||
| - | |RTOS| Real-Time Operating System, is an operating system (OS) intended to serve real-time application requests| | ||
| - | |IRQ| Interrupt Request, is a hardware signal sent to the processor that temporarily stops a running program and allows a special program, an interrupt handler, to run instead| | ||
| - | |DMA| Direct Memory Access, is a feature of modern computers that allows certain hardware subsystems within the computer to access system memory independently of the central processing unit (CPU)| | ||
| - | ===== 1. Introduction ===== | ||
| - | ==== 1.1 Presentation ==== | ||
| - | **Table 1-1 Prensentation**\\ | ||
| - | {{: | ||
| - | |||
| - | ==== 1.2 Motivation ==== | ||
| - | 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, | ||
| - | |||
| - | ==== 1.3 General Information ==== | ||
| - | 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' | ||
| - | |||
| - | {{: | ||
| - | **Figure 1-1 Example of a buoy as marker [10]** | ||
| - | |||
| - | {{: | ||
| - | **Figure 1-2 Example of a measuring buoy [11]** | ||
| - | |||
| - | ==== 1.4 Project description ==== | ||
| - | 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/ | ||
| - | - The environmental data logging mode; | ||
| - | - 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/ | ||
| - | 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**\\ | ||
| - | |||
| - | ==== 1.5 Objectives ==== | ||
| - | === 1.5.1 General objective == | ||
| - | 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. | ||
| - | - Assistance in autonomous sailing boat regattas who will be constructed at LSA in the future; | ||
| - | - 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, | ||
| - | |||
| - | === 1.5.2 Objective within the data logging part === | ||
| - | 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/ | ||
| - | |||
| - | ==== 1.6 Requirements ==== | ||
| - | 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.\\ | ||
| - | |||
| - | ===== 2. State of the Art ===== | ||
| - | |||
| - | ==== 2.1 Introduction ==== | ||
| - | 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. | ||
| - | ==== 2.2 Purpose of the Buoy ==== | ||
| - | ===2.2.1 Introduction === | ||
| - | 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. | ||
| - | ===2.2.2 Data Logging === | ||
| - | 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, | ||
| - | {{:: | ||
| - | **Figure 2-1 Data logging systems [7]**\\ | ||
| - | |||
| - | ===2.2.3 Collecting Ocean Data === | ||
| - | 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, | ||
| - | |||
| - | Meteorological data logging involves, among others, the collection of wind, humidity, temperature, | ||
| - | |||
| - | ===2.2.4 Regatta Mode === | ||
| - | |||
| - | 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, | ||
| - | |||
| - | 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. | ||
| - | |||
| - | ===2.2.5 Environmental Mode === | ||
| - | |||
| - | 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. | ||
| - | |||
| - | ===2.2.6 Conclusion === | ||
| - | 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/ | ||
| - | ====2.3 Logging systems ===== | ||
| - | ===2.3.1 Introduction === | ||
| - | 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, | ||
| - | ===2.3.2 Data logging systems=== | ||
| - | __**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, | ||
| - | \\ | ||
| - | **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, | ||
| - | \\ | ||
| - | __**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, | ||
| - | * 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. | ||
| - | ===2.3.3 Other buoys=== | ||
| - | 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, | ||
| - | * Meteorological (above the water); | ||
| - | * Oceanographic (under the water). | ||
| - | |||
| - | ===2.3.4 Protocol === | ||
| - | 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. | ||
| - | |||
| - | |||
| - | |||
| - | ===2.3.5 Conclusion === | ||
| - | From the data logging system there was learned that the best option is to use 1 processor. If the buoy needs to work autonomously, | ||
| - | ==== 2.4 Available Equipment ==== | ||
| - | ===2.4.1 Hull === | ||
| - | |||
| - | 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, | ||
| - | * 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. | ||
| - | |||
| - | {{: | ||
| - | |||
| - | ===2.4.2 Steel Structure === | ||
| - | |||
| - | 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**\\ | ||
| - | ===2.4.3 GNSS receiver === | ||
| - | 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, | ||
| - | * 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, | ||
| - | * 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; | ||
| - | * ''< | ||
| - | __**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]. | ||
| - | |||
| - | ===2.4.4 Wind sensor === | ||
| - | |||
| - | 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]**\\ | ||
| - | ^Parameter^Value^^ | ||
| - | |Product name|Davis anemometer|| | ||
| - | |Dimensions|470 mm x 191 mm x 121 mm|| | ||
| - | |Weight|1.332 kg|| | ||
| - | |Connector|Modular connector (RJ-11)|| | ||
| - | |Cable lenght|12m|| | ||
| - | |Cable type|4-conductor, | ||
| - | ^Measurement^^^ | ||
| - | | |Wind speed|Wind direction| | ||
| - | |Sensor type|Solid state magnetic sensor|Wind vane and potentiometer| | ||
| - | |Accuracy|±3 km/h|±7°| | ||
| - | |Resolution|0.1 m/s|1° (0° to 355°)| | ||
| - | |Range|1 to 322 km/h|0° to 360°| | ||
| - | |Sample period|2.25 s|1 s| | ||
| - | |Output|1600 rev/h = 1 mph\\ V = P(2.25/T)\\ V - speed in mph\\ P - # of pulses per sample period\\ T - sample period in seconds|Variable resistance 0 - 20 kΩ\\ 10 kΩ = south, 180°| | ||
| - | ===2.4.5 CTD sensor === | ||
| - | 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]**\\ | ||
| - | ^Parameter^Value^^^ | ||
| - | |Product name|CTD||| | ||
| - | |Size|366 x ∅95 mm||| | ||
| - | |Power supply|8 - 30 V||| | ||
| - | |Power consumption|1.5 W / 12 V||| | ||
| - | |Communication|RS232 or I2C||| | ||
| - | ^Measurement ^^^^ | ||
| - | |Quantity|Conductivity|Temperature|Pressure| | ||
| - | |Sensor|7 electrodes|PT100|Load cell| | ||
| - | |Unit|mS/ | ||
| - | |Range|0 - 70 mS/cm|-5 °C to 35 °C|0 - 100 dbar| | ||
| - | |Resolution|±0.001 mS/ | ||
| - | __**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]**\\ | ||
| - | ^Solution^Conductivity^ | ||
| - | |Absolute pure water|0.055 µS/cm| | ||
| - | |Good city water|50 µS/cm| | ||
| - | |Ocean water|63 mS/cm| | ||
| - | __**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: | ||
| - | * 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, | ||
| - | ===2.4.6 Data storage === | ||
| - | |||
| - | 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, | ||
| - | 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**\\ | ||
| - | ===2.4.7 Control Unit === | ||
| - | |||
| - | 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/ | ||
| - | |||
| - | 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/ | ||
| - | * At least 1 SPI interface for the SD-card; | ||
| - | * At least 1 Universal Asynchronous Receiver/ | ||
| - | * 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. | ||
| - | ===== 3 Project Development ===== | ||
| - | ==== 3.1 Introduction ==== | ||
| - | |||
| - | 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. | ||
| - | |||
| - | ==== 3.2 Components ==== | ||
| - | 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)**\\ | ||
| - | {{:: | ||
| - | |||
| - | ==== 3.3 STM32F3DISCOVERY ==== | ||
| - | {{: | ||
| - | ** 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**\\ | ||
| - | ===3.3.2 ChibiOS === | ||
| - | 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: | ||
| - | * 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, | ||
| - | * 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:\\ | ||
| - | * '' | ||
| - | * '' | ||
| - | * '' | ||
| - | * '' | ||
| - | * 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 '' | ||
| - | * '' | ||
| - | * '' | ||
| - | * '' | ||
| - | * '' | ||
| - | * '' | ||
| - | |||
| - | 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, | ||
| - | \\ | ||
| - | {{: | ||
| - | ** Figure 3-7 Code virtual timer**\\ | ||
| - | |||
| - | __**Communication Standards**__\\ | ||
| - | The SPI connection, UART connection and the serial connection while be explained with the conforming part.\\ | ||
| - | |||
| - | ==== 3.4 GNSS sensor ==== | ||
| - | {{: | ||
| - | ** 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| | ||
| - | |TX_No_1 |11| | ||
| - | |RX_No_1|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 | ||
| - | |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] **\\ | ||
| - | ^Parameter^ Value^ | ||
| - | |impedance RF port|50 Ω| | ||
| - | |DC Voltage |3,3 V| | ||
| - | |Frequency|1575.42 MHz| | ||
| - | |Max DC current Preamp|50 mA| | ||
| - | |||
| - | 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**\\ | ||
| - | ^Text GNSS^ meaning^ | ||
| - | |NovAtel Inc. 1.110-SSII|| | ||
| - | |D0|| | ||
| - | |PSN: SXF06220247 |Product Serial Number| | ||
| - | |UCPB: 0x955213A5 || | ||
| - | |PCPB: 0x0000387C|| | ||
| - | |GO |Go in Operation mode| | ||
| - | |<|| | ||
| - | |NovAtel Inc.|| | ||
| - | |S/W Version: 1.310-L1|Software version| | ||
| - | |CB=0x0000003F SHP|Bit self-test| | ||
| - | |Go to NMEA @ 9600 baud.|Operating in NMEA mode @ baud rate of 9600| | ||
| - | |In NMEA @ 9600 baud.|| | ||
| - | |||
| - | 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' | ||
| - | {{: | ||
| - | ** Figure 3-11 Connection scheme of the PTH 12000W [22]**\\ | ||
| - | Resistor '' | ||
| - | {{: | ||
| - | **Figure 3-12 formula PTH12000W [22]**\\ | ||
| - | \\ | ||
| - | **Table 3-9 Unknown parameters for the '' | ||
| - | ^Pt. No.^PTH12000W^ | ||
| - | |Vmin|1.2 V| | ||
| - | |Rs|1.82 kΩ| | ||
| - | The determined value of '' | ||
| - | ===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 ' | ||
| - | \\ | ||
| - | | ||
| - | 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:\\ | ||
| - | '' | ||
| - | |||
| - | In NMEA mode the Sentence identifiers shown in Table 3-10 are available: | ||
| - | \\ | ||
| - | **Table 3-10 Possible identifiers request log command [23]**\\ | ||
| - | ^ID^ Description^ | ||
| - | |900 |Navigation Status| | ||
| - | |902 |Self-Test Results| | ||
| - | |906 |Bearing, Distance and Delta-Elevation to Waypoint| | ||
| - | |907 |User Position in MGRS Format| | ||
| - | |908 |Receiver Parameter Status| | ||
| - | |912 |Receiver Configuration| | ||
| - | |GGA |Global Positioning System Fix Data| | ||
| - | |GLL |Geographic Position - Latitude/ | ||
| - | |GSA |GPS DOP and Active Satellites| | ||
| - | |GSV |GPS Satellites in View| | ||
| - | |RMC |Recommended Minimum Specific GPS Data| | ||
| - | |VTG |Track Made Good and Ground Speed| | ||
| - | |ZDA |UTC Time and Date| | ||
| - | The second part of the contents of data fields is the '' | ||
| - | To clarify an example:\\ | ||
| - | Supposing that this message is received '' | ||
| - | |||
| - | ==3.4.3 Output logs == | ||
| - | |||
| - | 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]**\\ | ||
| - | ^ID^ Description^Response^ | ||
| - | |900 |Navigation Status|'' | ||
| - | |902 |Self-Test Results|'' | ||
| - | |906 |Bearing, Distance and Delta-Elevation to Waypoint|'' | ||
| - | |907 |User Position in MGRS Format|'' | ||
| - | |908 |Receiver Parameter Status|'' | ||
| - | |912 |Receiver Configuration|'' | ||
| - | |GGA |Global Positioning System Fix Data|'' | ||
| - | |GLL |Geographic Position - Latitude/ | ||
| - | |GSA |GPS DOP and Active Satellites|'' | ||
| - | |GSV |GPS Satellites in View|'' | ||
| - | |RMC |Recommended Minimum Specific GPS Data|'' | ||
| - | |VTG |Track Made Good and Ground Speed|'' | ||
| - | |ZDA |UTC Time and Date|'' | ||
| - | 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]**\\ | ||
| - | ===3.4.4 Averaging === | ||
| - | 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 ' | ||
| - | * 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 ' | ||
| - | {{: | ||
| - | ** 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**\\ | ||
| - | ===3.4.5 Integration ChibiOS === | ||
| - | __**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 '' | ||
| - | __**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 '' | ||
| - | \\ | ||
| - | __**Second approach**__\\ | ||
| - | For using the serial driver, activate it in the '' | ||
| - | \\ | ||
| - | 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 '' | ||
| - | \\ | ||
| - | {{:: | ||
| - | ** Figure 3-33 Code Standard Baudrate serialport in halconf.h file **\\ | ||
| - | \\ | ||
| - | ===3.4.6 Testing === | ||
| - | 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, | ||
| - | \\ | ||
| - | **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. \\ | ||
| - | ==== 3.5 SD-card ==== | ||
| - | {{: | ||
| - | ** 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, | ||
| - | === 3.5.1 SPI === | ||
| - | SPI stands for Serial Peripheral Interface. Because of the high transfer rate of 20 Mbps or faster, it is mainly used for internal communication, | ||
| - | {{: | ||
| - | ** 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**\\ | ||
| - | ^Function^ Pin #^ | ||
| - | |SCK|PB13| | ||
| - | |MISO |PB14| | ||
| - | |MOSI |PB15| | ||
| - | |SS|BP12| | ||
| - | 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). | ||
| - | |||
| - | |||
| - | === 3.5.2 Working SDC === | ||
| - | 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]**\\ | ||
| - | * '' | ||
| - | * '' | ||
| - | * '' | ||
| - | * '' | ||
| - | * '' | ||
| - | * '' | ||
| - | 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 '' | ||
| - | 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. | ||
| - | ==== 3.6 Protocol ==== | ||
| - | === 3.6.1 Introduction === | ||
| - | 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).\\ | ||
| - | |||
| - | === 3.6.2 General overview === | ||
| - | In what follows the protocol will be more detailed.\\ | ||
| - | |||
| - | __**Commands and errors/ | ||
| - | |||
| - | 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/ | ||
| - | |||
| - | |||
| - | The meaning of the abbreviations is the following: | ||
| - | |||
| - | **SOH:** indicate, the start of the package, the '' | ||
| - | After the '' | ||
| - | **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: | ||
| - | |||
| - | |||
| - | __**Data**__\\ | ||
| - | |||
| - | In order to make a distinction between the packages for commands/ | ||
| - | |||
| - | {{: | ||
| - | **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/ | ||
| - | **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/ | ||
| - | {{: | ||
| - | **Figure 3-49 ID# data**\\ | ||
| - | In Figure 3-49 the different ID# data abbreviations are listed. | ||
| - | **EOH:** same meaning as for the commands/ | ||
| - | **Checksum: | ||
| - | **CR/LF:** LF stands for Line Feed or new line and CR for carriage return (ASCII characters), | ||
| - | |||
| - | __**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/ | ||
| - | |||
| - | **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: | ||
| - | |||
| - | This gives the following command for the Regatta mode:\\ | ||
| - | **Command: | ||
| - | |||
| - | **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: | ||
| - | |||
| - | **Command: | ||
| - | |||
| - | **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: | ||
| - | |||
| - | **Command: | ||
| - | |||
| - | **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: | ||
| - | |||
| - | **Command: | ||
| - | |||
| - | **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: | ||
| - | |||
| - | **Command: | ||
| - | |||
| - | **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: | ||
| - | |||
| - | **Command: | ||
| - | |||
| - | **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: | ||
| - | |||
| - | **Command: | ||
| - | |||
| - | **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: | ||
| - | |||
| - | **Command: | ||
| - | \\ | ||
| - | //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' | ||
| - | |||
| - | \\ | ||
| - | |||
| - | **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, | ||
| - | **EOH:** * \\ | ||
| - | **Checksum: | ||
| - | |||
| - | **Command: | ||
| - | |||
| - | **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, | ||
| - | **EOH:** * \\ | ||
| - | **Checksum: ** Depends on the data value \\ | ||
| - | |||
| - | **Command: | ||
| - | |||
| - | **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, | ||
| - | **EOH:** * \\ | ||
| - | **Checksum: | ||
| - | |||
| - | **Command: | ||
| - | |||
| - | **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, | ||
| - | **EOH:** * \\ | ||
| - | **Checksum: | ||
| - | |||
| - | **Command: | ||
| - | |||
| - | **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, | ||
| - | **EOH:** * \\ | ||
| - | **Checksum: | ||
| - | |||
| - | **Command: | ||
| - | |||
| - | **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, | ||
| - | **EOH:** * \\ | ||
| - | **Checksum: | ||
| - | |||
| - | **Command: | ||
| - | |||
| - | **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, | ||
| - | **EOH:** * \\ | ||
| - | **Checksum: | ||
| - | === 3.6.3 Protocol Diagrams=== | ||
| - | Protocol Diagrams are drawn in order to visualize the protocol. This shows the different massages/ | ||
| - | |||
| - | 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:\\ | ||
| - | - BS sends a Command data to the BBB | ||
| - | - BBB receives it and sends this command data to the STM32F3 and a Message OK responds to the BS | ||
| - | - 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. | ||
| - | - 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. | ||
| - | - BBB receives this wrong command and sends the command data again. | ||
| - | - STM32F3 now receives and knows the command. The STM32F3 sends therefore a Message OK to the BBB. | ||
| - | - BBB receives this Message OK and now know that the STM32F3 received the message well. | ||
| - | - STM32F3 sends after the Message OK the Data (Data 1) which was asked | ||
| - | - 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. | ||
| - | - BS also sends a Message OK to the BBB after a good receive. | ||
| - | - STM32F3 sends now Data 2 | ||
| - | - BBB receives wrong data and sends as answer Wrong data to the STM32F3 | ||
| - | - STM32F3 receives this Wrong data command and sends therefore Data 2 again. | ||
| - | - BBB receives Data 2 and sends it to the BS | ||
| - | - 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. | ||
| - | - STm32F3 sends now the asked asked data (Data 1) to the BBB | ||
| - | - BBB receives this data and sends this data on his turn to the BS. The BB also sends a Message ok to the STM32F3. | ||
| - | - BS receives Data 1 correctly and sends therefore also a Message ok to the BB. | ||
| - | - 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:\\ | ||
| - | - BS sends Command mode to the BBB | ||
| - | - 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 | ||
| - | - BBB didn't receive a Message ok after a defined time (Time-out) and sends the command mode therefore again. | ||
| - | - STM32F3 receives a wrong command (there went something wrong with the package) as answer he sends Wrong command to the BBB. | ||
| - | - BBB receives the Wrong command and sends therefore the Command mode again | ||
| - | - 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:\\ | ||
| - | |||
| - | - 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. | ||
| - | - STM32F3 sends therefore a not connected command to the BBB | ||
| - | - BBB receives this command and sends this not connected command to the BS. The BBB also sends a Message OK to the STM32F3. | ||
| - | - 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' | ||
| - | |||
| - | {{: | ||
| - | **Figure 3-68 Protocol Diagram when the BBB doesn' | ||
| - | |||
| - | The Protocol Diagram from Figure 3-28 explained in different steps:\\ | ||
| - | - BS sends a Command mode to the BBB | ||
| - | - BBB sends this Command mode to the STM32F3 | ||
| - | - 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. | ||
| - | - BBB sends therefore after the third Time-out a STM not connected command to the BS | ||
| - | - 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: | ||
| - | |||
| - | - 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. | ||
| - | - one's complement is not necessary since the checksum will already verify the whole package, it should be therefore discarded. | ||
| - | |||
| - | === 3.6.4 Implementation === | ||
| - | |||
| - | 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. | ||
| - | |||
| - | ====3.7 Interface board ==== | ||
| - | ===3.7.1 Complete scheme=== | ||
| - | {{:: | ||
| - | **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. | ||
| - | ===3.7.2 Multiplexer and Demultiplexer === | ||
| - | {{: | ||
| - | **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**\\ | ||
| - | ^Inhibit^B9^B3^B10^Output^ | ||
| - | |1|X\\ don't care|X\\ don't care|X\\ don't care|All open| | ||
| - | |0|0|0|0|NO0| | ||
| - | |0|0|0|1|NO1| | ||
| - | |0|0|1|0|NO2| | ||
| - | |0|0|1|1|NO3\\ RX GNSS sensor| | ||
| - | |0|1|0|0|NO4| | ||
| - | |0|1|0|1|NO5| | ||
| - | |0|1|1|0|NO6| | ||
| - | |0|1|1|1|NO7| | ||
| - | **Table 3-14 Truth table Multiplexer**\\ | ||
| - | ^Inhibit^B9^B3^B10^Input (Pin #)^ | ||
| - | |1|X\\ don't care|X\\ don't care|X\\ don't care|All open| | ||
| - | |0|0|0|0|4| | ||
| - | |0|0|0|1|3| | ||
| - | |0|0|1|0|2| | ||
| - | |0|0|1|1|1\\ TX GNSS sensor| | ||
| - | |0|1|0|0|15| | ||
| - | |0|1|0|1|14| | ||
| - | |0|1|1|0|13| | ||
| - | |0|1|1|1|12| | ||
| - | ===3.7.3 Power supply=== | ||
| - | {{: | ||
| - | **Figure 3-71 Scheme power supply**\\ | ||
| - | A battery is used as power supply for this PCB. The battery' | ||
| - | === 3.7.4 USB to RS232 converter=== | ||
| - | {{: | ||
| - | **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. | ||
| - | ===3.7.5 Connection of the STM32F3=== | ||
| - | {{: | ||
| - | **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**\\ | ||
| - | ^Connector^Pin #^Pin name STM^Function^ | ||
| - | |SV2|1|3V|3V for SD-card| | ||
| - | |SV2|7|PC2|CD SD-card| | ||
| - | |SV2|12|PA3|USART1 RX| | ||
| - | |SV2|13|PA2|USART1 TX| | ||
| - | |SV2|35|PB12|SPI CS(SS| | ||
| - | |SV2|36|PB13|SPI SCK| | ||
| - | |SV2|37|PB14|SPI MISO| | ||
| - | |SV2|39|PB15|SPI MOSI| | ||
| - | |SV1|3|PF10|Adress B mux and demux| | ||
| - | |SV1|9|PC13|Adress A mux and demux| | ||
| - | |SV1|10|PE6|Adress C mux and demux| | ||
| - | |SV1|50|GND|GND| | ||
| - | |||
| - | ===3.7.6 Overview components PCB board=== | ||
| - | **Table 3-16 Overview components PCB board**\\ | ||
| - | ^Part^ Value ^Device Package^ | ||
| - | |C1|100 µ|C1206| | ||
| - | |C2|100 n|C1206| | ||
| - | |C3|100 n|C1206| | ||
| - | |C4|100 n|C1206| | ||
| - | |C5|10 n|150CLZ-0810| | ||
| - | |C6|4.7 µ|150CLZ-0810| | ||
| - | |C7|100 n|C1206| | ||
| - | |IC1|FT232RL|SSOP28| | ||
| - | |IC2|Voltage convertor 5 V|7805 | | ||
| - | |IC3|74HC151N|DIL16| | ||
| - | |IC4|NLAS405S|TSSOP16| | ||
| - | |LED1| |1206| | ||
| - | |LED2| |1206| | ||
| - | |R1|2 k|R0603| | ||
| - | |R2|270 R|R0603| | ||
| - | |R3|270 R|R0603| | ||
| - | |R4|0 R |R1206| | ||
| - | |R5|0 R |R1206| | ||
| - | |R6|0 R |R1206| | ||
| - | |R7|0 R |R1206| | ||
| - | |U1|PTH12000W_EUS_5|PTH12000W_EUS_5| | ||
| - | |X10|MINI-USB-32005-201|MINI-USB-32005-201| | ||
| - | |||
| - | === 3.7.6 Overview of the PCB=== | ||
| - | {{:: | ||
| - | **Figure 3-74 Different views PCB\\ | ||
| - | 1: Copper bottom\\ | ||
| - | 2: Components and jumpers top view\\ | ||
| - | 3: Components bottom\\ | ||
| - | 4: All components and jumpers\\ ** | ||
| - | ===== 4. Development tools ===== | ||
| - | |||
| - | Software development for the STM32 microprocessor with ChibiOS | ||
| - | ==== 4.1 Introduction ==== | ||
| - | 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. | ||
| - | |||
| - | ==== 4.2 ChibiOS ==== | ||
| - | 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 | ||
| - | ==== 4.3 ChibiOS ==== | ||
| - | * Download ChibiOS. | ||
| - | * Unzip ChibiOS, then choose the folder. | ||
| - | * Download yagarto and install it. | ||
| - | * Download yagarto tools and install it. | ||
| - | * Add the path ”< | ||
| - | * Add the path ”< | ||
| - | ==== 4.4 Using ChibiOS without Eclipse ==== | ||
| - | 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 < | ||
| - | * 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/ | ||
| - | * Use the program “STM32 ST-LINK Utility”. | ||
| - | |||
| - | ==== 4.5 Using Chibios with Eclipse ==== | ||
| - | * 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:// | ||
| - | {{: | ||
| - | ** 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/ | ||
| - | {{: | ||
| - | ** 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. | ||
| - | ==== 4.6 StarView ==== | ||
| - | 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 '' | ||
| - | {{:: | ||
| - | ** 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 ' | ||
| - | {{:: | ||
| - | ** 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 | ||
| - | ==== 4.6 Download links ==== | ||
| - | ChibiOS: [[http:// | ||
| - | Notepad++: [[http:// | ||
| - | Yagarto: [[http:// | ||
| - | Yagarto tools: [[https:// | ||
| - | STM32 ST-LINK Utility: h[[ttp:// | ||
| - | ChibiStudio: | ||
| - | |||
| - | |||
| - | ===== 5. Conclusions ===== | ||
| - | ====5.1 Discussion ==== | ||
| - | 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 '' | ||
| - | ====5.2 Future developments ==== | ||
| - | 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 " | ||
| - | ===== Bibliography ===== | ||
| - | [1] Wikipedia, Comma-separated values, 2014. Available at http:// | ||
| - | [2] http:// | ||
| - | [3] http:// | ||
| - | [4] http:// | ||
| - | [5] http:// | ||
| - | [6] http:// | ||
| - | [7] http:// | ||
| - | [8] http:// | ||
| - | [9] http:// | ||
| - | [10] http:// | ||
| - | [11] http:// | ||
| - | [12] http:// | ||
| - | [13] http:// | ||
| - | [14] http:// | ||
| - | [15] http:// | ||
| - | [16] http:// | ||
| - | [17] http:// | ||
| - | [18] http:// | ||
| - | [19] http:// | ||
| - | [20] http:// | ||
| - | [21] pdf: GPS Active Antenna Specification (Model: GAACZ-A)\\ | ||
| - | [22] http:// | ||
| - | [23] http:// | ||
| - | [24] http:// | ||
| - | [25] http:// | ||
| - | [26] http:// | ||
| - | [27] http:// | ||
| - | ===== Appendices ===== | ||
