Electronic system intended for the management of sensors in agriculture. Sistema Electrónico destinado a la gestión de sensores para la agricultura

Equation Chapter 1 Section 1 Electronic system intended for the management of sensors in agriculture. Sistema Electrónico destinado a la gestión de sensores para la agricultura. Author: Lucía Gálvez del Postigo Gallego Tutor: Juan García Ortega End of Career Project Electronics, Robotics and Mechatronics Engineering Department of Electronic Engineering Electronic Technology Area Higher Technical School of Engineering University of Seville Seville, 2020 III Trabajo Fin de Grado Ingeniería Robótica, Electrónica y Mecatrónica Sistema Electrónico destinado a la gestión de sensores para la agricultura Autor: Lucía Gálvez del Postigo Gallego Tutor: Juan García Ortega Profesor titular Departamento de Ingeniería Electrónica Área de Tecnología Electrónica Escuela Técnica Superior de Ingeniería Universidad de Sevilla Sevilla, 2020 V Proyecto Fin de Grado: Sistema Electrónico destinado a la gestión de sensores para la agricultura Autor: Lucía Gálvez del Postigo Gallego Tutor: Juan García Ortega El tribunal nombrado para juzgar el Proyecto arriba indicado, compuesto por los siguientes miembros: Presidente: Vocales: Secretario: Acuerdan otorgarle la calificación de: Sevilla, 2020 El Secretario del Tribunal VII To all those who believed in me even when I did not. A todos aquellos que creyeron en mí aun cuando yo no lo hacía. IX Acknowledgements To all teachers who truly have a vocation and are passionate about what they teach, looking for the real interest of the students. To Juan, especially, for having welcomed me into this project, for his involvement and commitment both when he was my teacher and now as a tutor. To my father, for teaching me that constancy is the key that opens all doors and reminding me anytime that "I can". To my mother, for teaching me that every "no" is just a step that brings you closer to the next "yes". To my sister, for always being there for me with the greatest smile to encourage me. To my colleagues, because without them, the path would not have been the same. To Carmen, in particular, for filling these years with unforgettable memories. To all those who came into my life, sooner or later, to stay forever. Special mention of my friends Doru, for all the help, motivation and support; and Javi for providing me with a part of the material A todos los profesores que verdaderamente tienen vocación y son apasionados de aquello que enseñan, buscando el interés real de los alumnos. A Juan, especialmente, por haberme acogido en este proyecto, por su implicación y empeño tanto cuando fue mi profesor, como actualmente como tutor. A mi padre, por enseñarme que la constancia es la llave que abre todas las puertas y recordarme que “yo puedo”. A mi madre, por inculcarme desde siempre que cada “no” es sólo un paso que te acerca más al próximo “sí”. A mi hermana, por estar siempre ahí para mí con la mayor de las sonrisas y buscando comprenderme en cada momento. A mis compañeros, porque sin ellos, el camino no hubiera sido el mismo. A Carmen, en particular, por llenar de recuerdos inolvidables estos años. A todos aquellos que llegaron a mi vida, más pronto o más tarde, para quedarse para siempre. Mencionar especialmente a mis amigos Doru, por toda la ayuda, motivación y apoyo; y Javi por proporcionarme parte del material. INDEX OF ILLUSTRATIONS Illustration 1. Weather Station, using a data logger 3 Illustration 2. DTH11 Module Sensor – Sensor [17] 9 Illustration 3. . DS18B20 aspect. [18] 10 Illustration 4. Parasite and normal mode of DS18B20 sensor. [1] 11 Illustration 5. HD-38 sensor [20] 12 Illustration 6. Arduino IDE message area. 16 Illustration 7. Arduino IDE Buttons 16 Illustration 8. Baud rate agreement 16 Illustration 9. Micro SD card Adapter [19] and micro SD Card 18 Illustration 10. SIM808 aspect and connections [4] and 12 Volts Charger [21] 20 Illustration 11. Try AT commands serial output 21 Illustration 12. Arduino-Sensors connection 25 Illustration 13. Arduino Mega - MicroSD Adapter wiring 27 Illustration 14. Welding J19,J12,J13 and result. 28 Illustration 15. SIM808 wiring with Arduino Nano 28 Illustration 16. Arduino Serial Port Communication: DS18B20 redord 35 Illustration 17. Arduino Serial Port Communication: Sensors record 35 Illustration 18. Arduino program with the libraries that will be used and its result in Arduino Nano’s memory 37 Illustration 19. Arduino Mega's memory utilization when all the libraries are loaded 37 Illustration 20. Before and after writing on the EEPROM memory 38 Illustration 21. Arduino Serial Port Communication: Clock setting 39 Illustration 22. Arduino Serial Port Communication: Frequency Check 40 Illustration 23. The process of writing a file in the SD cad. 41 Illustration 24. The process of writing a file in the SD cad. 41 Illustration 25. Arduino Serial Port Communication: Sending an SMS and SMS received in the phone 42 Illustration 26. Arduino Serial Port Communication for receiving a message and the SMS sent in the phone 43 Illustration 27. System prepared for demo 45 Illustration 28. Veinasa Soil Moisture Sensor [13] 59 Illustration 29. Soil Temperature Sensor [16] 60 Illustration 30. Air pressure, temperature and humidity Sensor [14] 61 Illustration 31. Wind Speed Sensor [15] 63 Illustration 32. A real datalogger with keypad [22] 65 Illustration 33. Example of a PCB implementation in Eagle. 66 Illustration 34. Sampling data line in an asynchronous serial communication [23] 67 XVII Notation OTP Memory One Time Programmable Memory PCB Printed Circuit Board Arduino IDE Arduino Integrated Development Environment UART Universal Asynchronous Receiver-Transmitter PWM Pulse Width Modulation SRAM Static Random Access Memory EEPROM Electrically Erasable Programmable Read-Only Memory SPI Serial Peripheral Interface MISO Master In Slave Out MOSI Master Out Slave In SCLK Serial Clock CS Chip Select GPS Global Positioning System GPRS General Packet Radio Service SMT Surface Mount Technology LSB Least Significant Bit CRC Cyclic Redundancy Check-Control OSI Open System Interaction ADU Application Data Unit PDU Protocol Data Unit 1 INTRODUCTION owadays, everything is changing so fast, people tend to use technology to help themselves and improve their way of working. A challenging area on which to apply this progress is agriculture, data loggers have been invented for this scope. A data logger is an electronic device which registers data on time. By using its own or externally connected sensors, information about the state of some parameters is gathered. This gadget is generally based on microcontrollers and frequently equipped with a microprocessor along with internal memory to store the information. Some of them, communicate with a personal computer using specific software, while others have a local interface (keyboard, LCD screen) so they can be used as an independent dispositive. The goal of using data loggers is to be able to supervise some nature parameters such as wind speed, humidity and temperature; thus, making decisions regarding the care of the corps. One of the benefits of using them is having data 24 hours per day on the state of the field. Besides, once activated, dataloggers are left without surveillance providing an autonomous way of checking the state. This device varies among those with general porpuses for a wide range of applications, and the specific ones, to measure a designed environment or application. It is common for the first to be programmable; nonetheless, lots of them continue being static machines with a limited number of parameters. This study aims to design a data logger from the ground up with improvements pursuing a user-friendly solution where some limitations are fixed. The present project is organized following a path for creating a new device; starting in the first chapter by designing a black boxes diagram explained in detail and completed throughout the following chapters. Once the diagram is understood, choices made for implementing each part are justified based on the requirements and possibilities. When the design is completed, the tests carried out are explained, after, a final experiment is performed, and the compliance of requirements is checked. The final chapter describes future improvements either in the system created or in a new system with more professional attributes. N “Life can only be understood backwards; but it must be lived forwards.” - Søren Kierkegaard- 3 3 Sistema Electrónico destinado a la gestión de sensores para la agricultura 1.1 Requirements The initial requirements were stated as: - For the device to have better connectivity, offering the possibility of connecting several sensors without having as many limitations as currently available devices. - Result in a user-friendly device. Nevertheless, in order to create a data logger, different aspects must be taken into account. When the problem was analysed in-depth, some questions arose, and by giving them answers, several requirements were fixed: - Where is supposed to be placed this device? In the champ, this aspect must be considered to create the structure case but also it is essential for the sensors that will be selected for the prototype because they must stand these conditions. - How to communicate with the datalogger? Since it is going to be placed in the champ, in theory, no WiFi connection is available. Therefore, another method for the connection must be found. - The aim is to leave the device without surveillance; hence the datalogger must work autonomously. - The information collected by the sensor must be reliable, avoiding interferences. - Sensors will be placed near the device, so there is no need to have a large cable, this affects the communication and interferences that may arise. - The amount of information collected must be defined in order to manage data storage, memory, etc. Illustration 1. Weather Station, using a data logger 1.2 Objectives This project aims to develop a datalogger to retrieve data from the environment of the corps and take actions accordingly for their best care. The development of the aim is structured in this path: • Synthesize a real datalogger. • Decide how to implement each of the parts identified in the first analysis. • Investigate each component and get familiar with the programming and connections. • Integrate the whole system. • Present the final solution throughout a real experiment. • Analyse the results and seek for improvements 2 SYSTEM o have a better idea of what must be recreated; it is crucial to start with the analysis of a real datalogger. Thus, in the first step, a data logger was carefully studied. The analysis, based in a breakdown, resulted in some gathered modules which could be replicated afterwards. Those modules can be depicted in a simple schema like the one shown in Figure 1. From now on, references to this diagram will be made, for it the explanation to be easier to follow. It is observed that the datalogger can be considered as a system which will manage some information coming from the sensors. The information will be processed in a certain way, and then it will be sent through a communication channel. The user will be able to obtain or to ask the information by interacting with the User Interface. It is important to note that the Communication Interface supports a twoway flow of information. This description helps to understand, in general terms, how the system works. In the present section, specific details of the above-referenced modules will be given. 2.1 Sensors In the first place, the way of collecting the information, and which information to monitor, must be decided. Figure 1 shows that the first Module is the Sensor one; for which some aspects have to be considered. Even if the parameters to monitor may change over time, for this project, some properties to observe were selected. Therefore, to understand what is happening with the crops under surveillance, soil temperature and moisture, humidity, ambient temperature, were supervised. It is important to note that Sensors consist of Hardware and Software, as appreciated in Figure 2; therefore, both aspects need to be studied. T Communication channel Sensors Processing Unit User Interface User System Figure 1. System description. System 6 2.2 Processing Unit The core of our system is found in the Processing Unit. This unit’s functions vary from processing the information, collecting it, storing it and/or transmitting it. Additionally, other applications could be joined. Nevertheless, the functions listed on the preceding were selected to be those that our system will include. Another significant aspect of the Processing Unit is that the activities should be synchronized. For this reason, this unit must be provided with a clock signal or timing control. Bearing in mind that saving information implies providing this Module with an amount of memory; it is vital to define the frequency of data collection or the volume of data to be stored, in order to know how much memory would be necessary. Furthermore, errors must be prevented from happening. In the event of an error, the data should be stored in such a way that recovering it is possible. Besides, some method must be thought in order to understand which sensors are connected. The decisions made about the Sensor’s Module will also have its influence here. The reason is that this piece should be able to receive the data from the sensors, which will use a certain protocol, and then the Processing Unit will transmit it again to another Module. Beyond, even if the information flows only in one way, the Processing Unit must be able to receive information in both senses taking into account user’s requests. Figure 3 shows a summary of the characteristics described, in addition to the relationship of this Module to the preceding and subsequent elements. 2.3 Communication Channel As seen in Figure 3, the nature of such a device is bidirectional as far as communication is concerned; enabling both the Processing Unit and the final User to communicate. This characteristic implies that the Communication Channel will be the bridge; the requests for the information will first pass through this Module, but also the information will arrive at the client by the same mean. It is compulsory to create a “code” so that both ends can understand each other. Moreover, the conditions on which the communication will take place needs to be evaluated so that interferences, the fact that distance is not known in advance or the countryside conditions do not affect the performance. Processing Unit •Processing information •Store information •Time processing Sensors User interface • Understand Protocols • Sensors Identification •Transmitting information Communication Channel Sensors Hardware Software Figure 3. Pocessing Unit description Figure 2. Sensors description. 7 7 Sistema Electrónico destinado a la gestión de sensores para la agricultura 2.4 User interface The User Interface will present the information to the user whenever he or she asks for it. Requests for information from the user will also be made through this Module. In conclusion, both parties will dump the information on this platform. 2.5 User The user stands for the person who will interact with the device. Consequently, he or she will be able to choose some of the parameters that will be decided as susceptible to change. For instance, in what refers to data frequency different approaches could be taken: To have the device working the whole day and then, certain times a day, transmitting the information; or communicating with the client only when a request is made, among others. Provided that versatility is one of the requirements, the best choice would be to include both options. In general, some requirements need to be defined in order to identify which will be the degree of freedom of the user in defining configuration parameters. Once each Module has been described, little pieces of information can be added to the previous diagram, resulting in. Figure 5 The following section will review the modules trying to find a suitable implementation for each one. Communication channel Sensors Processing Unit User Interface User System •Processing information •Store information • Transmitting information •Understand protocols •Time processing •Sensor identification Hardware Software Countryside conditions Information requests, data frequency Figure 5. System Characteristics Implemented Solution 14 3.2.2.1 Arduino Arduino is an open-source hardware and software company, project, and user community. This enterprise designs and manufactures single-board microcontrollers as well as microcontroller kits for building digital devices. The platform that this company holds is based on easy-to-use hardware and software. Arduino boards can read inputs and turn them into outputs. The board operates according to a set of instructions sent to the microcontroller on the board. To set these instructions, Arduino programming language (based on Wiring), and the Arduino Software (IDE) (based on Processing), are used. Among all the features that can be found on the manufacturer’s website [3], the most interesting for this project are: - Open source and extensible software, due to the fact that The Arduino software is published as an opensource tool, available for extension by experienced programmers. The language can be expanded through C++ libraries, and people wanting to understand the technical details can switch from Arduino to the AVR C programming language on which it is based. - Open source and extensible hardware, because the plans of the Arduino boards are published under a Creative Commons license; therefore, expert circuit designers can create their version of the Module, extending it and improving it. Considering, on the one hand, this information about this type of microcontroller; and, on the other hand, the fact of having worked with them previously throughout the university degree; Arduino was chosen for implementing the processing unit. 3.2.2.1.1 Arduino boards Different Arduino boards are available; an assessment should be made to have an idea of which one will be suitable for the present work. There are different kinds of Arduino boards. In order to find the one that best suits our system, some of the alternatives are analysed below: - Arduino Uno: It consists of 14-digital I/O pins, where 6-pins can be used as Pulse Width Modulation outputs (PWM), 6-analog inputs, a reset button, a power jack, a USB connection and more. When purchasing Arduino One, everything for the microcontroller to work is integrated into the board, so it is only needed to plug it into the computer and upload the code. In more advanced applications, which may require extra supply, AC-to-DC adapter or battery are used. - Arduino Mega: The Arduino Mega 2560 is a microcontroller board based on the ATmega2560. It has 54 digital input/output pins (of which 15 can be used as PWM outputs), 16 analogue inputs. Besides, 4 UARTs (hardware serial ports), a 16 MHz crystal oscillator, a USB connection, a power jack, an In Chip Serial Programmer (ICSP) header, and a reset button. It contains everything needed to support the microcontroller. It also can connect to the computer by a USB cable and using it directly or add an ACto-DC adapter or battery. - Arduino Nano: The Arduino Nano is a small and complete board based on the ATmega328 (Arduino Nano 3.x). It has 22 digital input/output pins out of which six can be used as PWM outputs, eight as analogue inputs. It works with a Mini-B USB cable instead of a standard one and lacks a DC power jack. 15 15 Sistema Electrónico destinado a la gestión de sensores para la agricultura UNO MEGA NANO Architecture AVR AVIR AVR Operating Voltage 5V 5V 5 V Input Voltage (recommended) 7-12V 7-12V 7-12 V Input Voltage (limit) 6-20V 6-20V 6-20V DC Current per I/O Pin 20 mA 20 mA 40 mA (I/O Pins) DC Current for 3.3V Pin 50 mA 50 mA - Power consumtion 20mA 50mA-200mA 19 mA Flash Memory 32 KB (ATmega328P) of which 0.5 KB used by bootloader 256 KB of which 8 KB used by bootloader 32 KB of which 2 KB used by bootloader SRAM 2KB (ATmega328P) 8 KB 2 KB EEPROM 1 KB (ATmega328P) 4 KB 1 KB Clock Speed 16 MHz 16 MHz 16 MHz Length 68.6 mm 101.52 mm 18 x 45 mm Width 53.4 mm 53.3 mm Weight 25 g 37 g 7 g Table 4 Arduino Uno, Mega, Nano comparison 3.2.2.1.2 How to programme In order to use the Arduino boards, it is necessary to program code and then upload it. To be able to do this, there is a tool that the Arduino platform itself provides to the user, the Arduino Integrated Development Environment (IDE). This program is a cross-platform application, written in functions from C and C++. It supplies a software library from the Wiring project, which includes many standard input and output procedures. Programs written using Arduino Software IDE are called sketches, which are saved with the file extension .ino. Looking now at the aspect of this tool, the message area, shown in Illustration 6, is found at the bottom of the window and gives feedback while saving and exporting codes, but it displays errors as well. The console, with a black background, displays text output by the Arduino Software IDE, including complete error messages and other information. The bottom righthand corner of the window displays the configured board and serial port. Implemented Solution 16 Illustration 8. Baud rate agreement The serial port is used for communication between the Arduino board and a computer. All Arduino boards have at least one serial port (also known as a UART or USART). On Uno, Nano, Mini, and Mega, pins 0 and 1 are used for communication with the computer. Connecting anything to these pins can interfere with serial communication, including causing failed uploads to the board. The Arduino environment’s built-in serial monitor can be used to communicate with an Arduino board. It can be opened by clicking on the button in the right-hand corner at the top of the window (See Illustration 7). In order to use the serial communication, the same baud rate as the one used in the call to begin() in the code must be selected. Moreover, it is worth mentioning the use of libraries for programming in Arduino. Libraries provide sketches with extra functionality, for example, working with external hardware or manipulating data. For using a library in a sketch, it must be selected from the menu on the upper part: Sketch > Import Library menu. The libraries are inserted one behind the other by #include statements at the top of the sketch. The library is compiled with the sketch. Because libraries are uploaded to the board with the sketch, they increase the amount of space it takes up; therefore, special attention must be paid not to overload the board with unnecessary information. Illustration 6. Arduino IDE message area. Illustration 7. Arduino IDE Buttons 17 17 Sistema Electrónico destinado a la gestión de sensores para la agricultura 3.2.2.2 Board Usage As seen in Table 4, characteristics overall are similar; it seems an excellent choice to choose Arduino Mega because of the abundance of memory and pins. However, on the other hand, the Arduino Nano offers similar features and tiny size. The risk of choosing Arduino Nano is the possible lack of memory for performing all the features wanted in the project, seeing that the quantity of memory available in this model is significantly reduced. For the moment, we are considering both options and details of the final choice will be given later. The decisions regarding the implementation of the following modules are taken based on the choice of Arduino. A considerable benefit of Arduino, from which this project takes advantage, is the wide variety of easy-to-connect extra hardware that is found on the market. The following Figure gives an idea of how the system looks like as decisions are taken. Although the Arduino platform satisfies the general aspects considered for the Processing Unit, one significant point is missing. This Module must consider the possibility of saving data acquired by the sensors, allowing the user to retrieve them in the future. Therefore, taking advantage of the hardware extensiveness offered by Arduino, an extra module to perform this task should be considered. 3.2.2.3 Data storage Arduino boards have three different kinds of memory with different functions each: Static Random Access Memory (SRAM); a volatile memory, where the sketch creates and manipulates the variables when executed, it is a limited resource and must be monitored to avoid depletion, EEPROM; a non-volatile memory to keep data after a reset, Flash, which is the program memory, where the sketch is saved once it has been compiled, it also stores the bootloader. Although all of them are necessary and allow the Arduino to perform its functions, external memory is required to perform the sensor data storage function. By proceeding this way, the benefit accomplished is that in the event of an Arduino failure data is separately stored so it could be recovered. Figure 9. System details with Arduino functionalities Communication channel Processing Unit User Interface User System Countryside conditions Information requests, data DS18B20 HD-38 DTH11 One wire Protocol ✓Processing information ✓Transmitting information ✓Understand protocols ✓ Time processing ✓Sensor identification ?Data storage Implemented Solution 18 A popular and easily obtainable option is the usage of an external SD memory. In order to insert an SD memory on the system, an SD adapter compatible with Arduino must be included. There is a wide range of these on the market; a micro SD was already available; therefore, a micro SD adapter was the model chosen. The model selected is shown in Illustration 9, and also the electrical characteristics of the module are found in Table 5. Min Typical Max Power Voltage VCC (V) 4.5 5 5.5 Current (mA) 0.2 80 200 Interface Electrical Potential (V) 3.3 or 5 Support Card Type Micro SD Card/Micro SDHC Card Size (mm) 41 x 24 x 12 Wight (g) 5 Table 5. Micro SD adapter Characteristics 3.2.2.3.1 Software As was the case of the sensors, for using this device, software libraries are needed, the name of them are “SD.h”, “SPI.h”. The first one allows for reading and writing to SD cards, the formats supported of the SD are FAT16 and FAT32, this last one will be used. The second library is needed because the communication between the microcontroller and the SD card uses Serial Peripheral Interface (SPI), which takes specific pins of the Arduino in order to perform this communication. The SPI protocol is a synchronous serial data protocol used by microcontrollers for communicating with own or more peripheral devices in a quick way over short distances. In this protocol, a master is always found, usually, a microcontroller which controls the peripheral devices. This communication uses three lines, common for the devices that will use SPI. Those three lines are Master In Slave Out (MISO), which allows the slave for sending data to the master; Master Out Slave In (MOSI), Master’s line for sending data to the peripherals, Serial Clock (SCLK) which allows data transmission synchronization, it is generated by the master; and one specific line for every device, Save Select (SS) by the pins connected to this line, the master is able to decide which device will enable or disable. When the Slave Select is at a low value, the device connected is communicating with the slave, whereas when its value is high, the peripheral device is ignoring the master. Figure 10 is updated with the last choices made, also adding the protocols needed to communicate between the parts. Illustration 9. Micro SD card Adapter [19] and micro SD Card 19 19 Sistema Electrónico destinado a la gestión de sensores para la agricultura 3.2.3 Communication channel Different possibilities are available for providing an Arduino Board with communication skills. Some of the requirements limit the options, for instance, the fact that there is no WiFi connection where the datalogger will be placed, discards the choice of a WiFi module. Therefore, a more reasonable alternative was to consider a 3G module for communication. Having a 3G transmission provides several benefits; for example, the distance between the user and the device is not a problem. In the market, several compatible 3G Arduino shields are found, the SIM808 evb-v3.2 model was used. 3.2.3.1 SIM808 evb-v3.2 SIM808 module is a complete Quad-Band GSM/GPRS module which provides Global Positioning System (GPS) technology for satellite navigation. This compact design integrates General Packet Radio Service (GPRS) and GPS in a Surface-Mount Technology (SMT) package. It will let users develop GPS enabled applications. Featuring an industry-standard interface and GPS function, it allows variable assets to be tracked seamlessly at any location and anytime with signal coverage [4]. Furthermore, sending and receiving SMS messages or making and receiving phone calls is also possible with this Module; those are indeed the most relevant characteristics for our project. Some features are: Communication channel Arduino User Interface User System Countryside conditions Information requests, data frequency DS18B20 HD-38 DTH11 One wire Protocol MicroSD card Adapter SPI Figure 10. System details adding micro SD adapter Implemented Solution 20 Quad-band 850/900/1800/1900MHz GPRS multi-slot class 12/10 GPRS mobile station class B Compliant to GSM phase 2/2+ Class 4 (2 W @ 850/900MHz / Class 1 (1 W @ 1800/1900MHz) Bluetooth compliant with 3.0+EDR FM 76~109MHz worldwide bands with 50KHz tuning step Dimensions 24.0*24.0*2.6mm Control via AT commands (3GPP TS 27.007, 27.005 and SIMCOM enhanced AT Commands) Supply voltage range 3.4 ~ 4.4V Operation temperature: -40℃ ~85℃ Table 6 SIM808 Characteristics Using this shield involves having an external power supply adapter. In this case, a 12Volts charger was acquired like the one seen in Illustration 10. Illustration 10. SIM808 aspect and connections [4] and 12 Volts Charger [21] 21 21 Sistema Electrónico destinado a la gestión de sensores para la agricultura 3.2.3.1.1 AT commands For the communication with the SIM808 board, AT commands are used. The Hayes command set (also AT command set) is a specific command language originally developed for the Hayes Smartmodem 300 baud modem in 1981. The command set consists of a series of short text strings which can be combined to produce commands for operations such as dialling, hanging up, and changing the parameters of the connection. The vast majority of dial-up modems use the Hayes command set in numerous variations [5]. The AT commands are required to use the SMS communication of this shield In the provided datasheet of SIM808 module, the syntax for programming is laid out [6]. The procedure starts with specific commands used for configuring parameters to deploy communication; then, SMS communication takes place by using other instructions. A simple code was made to analyse the responses of the shield. The performance of that program helped in order to have a better understanding of how the Module works. In this first code, it is possible to send AT commands by serial port, writing them directly by the computer keyboard. This test not only allowed us to observe the responses but also to know which are the parameters to send for a given setting command. Writing the command followed by a question mark ‘?’ gives the current value of the command, whereas writing the command followed by ‘=?’ results in the values that the parameter accepts—this process is observed in Illustration 11 . Illustration 11. Try AT commands serial output Implemented Solution 22 3.2.3.1.2 Using SIM808 for sending and receiving SMS The specific commands for setting up the Module to receive and send SMS are found on the following table. AT+CMGF [6] Select SMS Message format AT+CNMI=<mode>[,<mt>[,<bm>[,<ds>[,<bfr>]]] ] Terminal Adapter (TA) selects the procedure for how the receiving of new messages from the network is indicated to the Terminal Equipment (TE) when TE is active. The parameters used in our case: AT+CNMI=2,2,0,0,0 <mode> = 2 Buffer unsolicited result codes in the TA when TA-TE link is reserved (e.g. in on-line data mode) and flush them to the TE after reservation. Otherwise, forward them directly to the TE <mt> = 2 the rules for storing received SMs depend on its data coding scheme preferred memory storage (+CPMS) setting and this value SMS-DELIVERs (except class 2) are routed directly to the TE using unsolicited result code: +CMT: [<alpha>],<length><CR><LF><pdu> (PDU mode enabled) Class 2 messages result in indication as defined in <mt>=1 Table 7. AT commands for setting up the parameters to receive/send SMS texts After setting all these parameters, the Module is prepared for receiving the SMS messages coming from the user. This is the path to follow for sending an SMS: AT+CMGS [6] Send SMS Message Write Command 1) If text mode (+CMGF=1): +CMGS=<da>[,<toda>]<CR> text is entered<ctrl-Z/ESC> ESC quits without sending 2) If PDU mode (+CMGF=0): +CMGS=<length><CR>PDU is given<ctrl-Z/ESC> Parameters <da> GSM 03.40 TP-Destination-Address Address-Value field in string format(string should be included in quotation marks); BCD numbers (or GSM default alphabet characters) are converted to characters of the currently selected TE character set (specified by +CSCS in TS 07.07); type of address given by <toda> <toda> GSM 04.11 TP-Destination-Address Type-ofAddress octet in integer format (when first character of <da> is + (IRA 43) default is 145, otherwise default is 129) <length> integer type value (not exceed 160 bytes) indicating in the text mode (+CMGF=1) the length of the message body <data> (or <cdata>) in characters; or in PDU mode (+CMGF=0), the length of the actual TP data unit in octets (i.e. the RP layer SMSC address octets are not counted in the length) Table 8. AT command for sending an SMS 23 23 Sistema Electrónico destinado a la gestión de sensores para la agricultura A response is given from the module whenever a message is sent, the description is found on the following table. Response TA sends a message from a TE to the network (SMS-SUBMIT). Message reference value <mr> is returned to the TE on successful message delivery. Optionally (when +CSMS <service> value is 1 and network supports) <scts> is returned. Values can be used to identify message upon unsolicited delivery status report result code. 1) If text mode(+CMGF=1) and sending successful: +CMGS: <mr> OK 2) If PDU mode(+CMGF=0) and sending successful: +CMGS: <mr> OK 3) If an error is related to ME functionality: +CMS ERROR: <err> Table 9. SMS Response description. After selecting the device which stands for the Communication Channel, the whole system diagram can be updated, resulting as the one in Figure 11. 3.2.4 User Interface Provided that the communication will employ SMS, the User Interface will be the application installed in the mobile phone to read and send SMS. The phone number to which refer the communication is the one found in the SIM card installed on the SIM808-ev2.3 Module. SIM808 evb-v3.2 Arduino User Interface User System Information requests, data frequency DS18B20 HD-38 DTH11 One wire Protocol MicroSD card Adapter SPI Figure 11. System Scheme Adding SIM808 Implemented Solution 30 The assumption here is that even if the sensors used are right now defined, in the future, some others may be added. The intention is to avoid a considerable change in the implementation to extend the device’s functionalities. Proceeding in this way, allows the user to perform the connections of the sensor in a more versatile way. Besides, the first of the functionalities: “Ask the user which sensors are connected.” would be covered. The maximum number of sensors has been limited to five (Requirement 1) for this system. In a real performance, this is the first parameter that the user will be asked to define. Secondly, the user must define a frequency corresponding to the frequency of SMS reception. These SMS will include the measure of each sensor. The limitation will be 30 seconds because between each SMS there is an unavoidable delay. This information will also be displayed on the User’s manual. If the set frequency does not meet this requirement, another one is asked. However, in a real-life test of the system, a much lower frequency should be considered. It would not make sense to observe the parameters with such insistence since changes will generally occur gradually over time. The second feature: “Asking the user to define a frequency for the regular notification” is accomplished. On the other hand, the device will count with an internal frequency to monitor data (Requirement 2). This frequency is defined as 30 seconds in order to have information for each moment throughout a day. This requirement is not subject to be changed by the user. The data will be stored in the external memory of the device, and it is possible to consult this information anytime. To sum up, it is found that the user will have to define two features when first setting up of the system: the number of sensors connected as well as its identification according to Table 11, and the SMS frequency. Once determined, the system is prepared to start measuring. At this point, the device works autonomously. There are also some extra functionalities: by using specific keywords, like the ones seen in Table 12, the user is able to perform different functions. These extra functionalities allow completing the remaining features of the system. Keyword Function Address Change the identifications of the sensors connected Consult Ask for the values of sensors connected in a specific passed moment of time Frequency Change actual period of user’s sms update Keyword of the sensor In our case: - Temperature is established for DS18B20 - Moisture would be established for HD38 - Humidity would be established for the humidity value of sensor DTH11. - Ambient Temperature would be established for DTH11. Each sensor will have a particular keyword in order to retrieve its measures at the moment. Other keywords could be configured according to future sensors connected to this device. Table 12. Keywords for the different functions of the system. Moreover, when a parameter goes out of a specific range, the user will receive an alert. This functionality corresponds to the last of the features presented in 3.1. If the device is accidentally or intendedly turned off, when it is turned on again, it asks for the number of sensors connected. It would then send a confirmation of the data it had stored from when it was in operation. An SMS 31 31 Sistema Electrónico destinado a la gestión de sensores para la agricultura will be sent to inform the user of the addresses it contains and the frequency of messages. The user is asked to confirm whether or not he/she wants to change them and then continues the execution regularly, as explained above. 3.4.2 Programming path So far, the behaviour of the system is summarised in broad terms. Right now, all the information is summarized in a flowchart. The scheme describes the path that the future program will have to follow more transparently. Implemented Solution 32 EEPROM Memory EEPROM Memory Inicio Ask how many sensors are there and store the value Is the frequency of user’s SMS available? Take measures Is the identification of sensors available? Yes Yes Yes No No No No Ask for Identification of each sensor Ask for Identification of each sensor Ask for frequency Ask for frequency Recover data from EEPROM and send it to the user Recover data from EEPROM and send it to the user Store information Store information Recover data from EEPROM and send the User Recover data from EEPROM and send the User EEPROM Memory EEPROM Memory Store information Store information * Change values? Yes No No EEPROM DATA EEPROM DATA EEPROM DATA EEPROM DATA Change value? Yes No No 33 33 Sistema Electrónico destinado a la gestión de sensores para la agricultura Store data in SD Store data in SD Proceed to sending SMS Proceed to sending SMS Send Alert! Send Alert! Is there any measure out of the range? T_NOW ≥ T_SMS? SMS arrival? T_NOW ≥ T_SD? Wait for ACK Wait for ACK ACK? ACK? Identify keyword Identify keyword Perform the activity Perform the activity Yes Yes * Loop Yes Yes Yes Yes Yes Yes No No No No No No No No T_NOW = Current time T_SD =Predicted time to make a new SD memory storing T_SMS = time when the user will receive the next SMS T_NOW = Current time T_SD =Predicted tiene to make a new SD memory storing T_SMS = time when the user will receive the next SMS Tests 34 4 TESTS ll the sensors described in the preceding section were not available. For this reason, some modifications on the first outline of the system had to be made. To avoid losing versatility on the whole system, the remaining sensors were simulated; more details about the process are given in the present section. The equipment available was: - DS18B20 - Arduino Nano/Arduino MEGA. - Micro SD card Adapter - SIM808 evb-v3.2 Subsequently, a series of tests where carried out with this material. The importance of these tests resides in the fact that they help to get acquainted with each Module separately. Once it is understood how each one works, it is possible to proceed to the shaping of the final system. Each section below describes the tests carried out for each Module. In addition, tests are referred to the requirements that they enable to satisfy, those raised in Section 3.1. 4.1 Sensors Provided that only one of the sensors were available, the way of creating a more realistic system was to simulate the remaining sensors by reading random values for each one. Therefore, it is proceeded with the programming of the real sensor, based on the information given in the previous section. Besides, some trials were made in order to implement the function that was going to provide the values. A … •Define fequency of measure •Ask for information at a certain past time •Ask for the information at the present moment SIM808 evb-v3.2 Arduino User Interface User System DS18B20 One wire Protocol MicroSD card Adapter SPI Figure 14. Final system 35 35 Sistema Electrónico destinado a la gestión de sensores para la agricultura 4.1.1 DS18B20 Sensor’s test Using the previously described libraries, but also studying its way of working and making some tests, the sensor was quickly launched. A method was created in order to obtain the measure each time it was called. The result of the tests is found in Illustration 16. ✔ Test check: Completing this test allows for obtaining the soil temperature measurement. Therefore, at this point, the requirement of observing this parameter is fulfilled. The result of the test is not only significant for this reason but also because it is possible to work with the value obtained: transmitting it or saving it. 4.1.2 Sensor’s simulation The fact of monitoring several parameters renders the system much more effective and realistic. Since this idea was to be retained, the rest of the sensors were simulated with random values. In order to obtain those random values, a function was created using Arduino’s own “random()” method. This function returns pseudo-random values up to the number given between brackets. Illustration 17 demonstrates how this function is combined with the previous temperature value and how all sensors are gathered together. Illustration 16. Arduino Serial Port Communication: DS18B20 redord Illustration 17. Arduino Serial Port Communication: Sensors record Tests 36 ✔ Test check: At this point, a more generic implementation of the system is allowed because in the future, when having all the sensors available, it will be easier to integrate them, at the programming level. On the other hand, obtaining these values and being able to operate with them, allows the selected parameters in 3.2.1 section, “soil and ambient parameters”, to be successfully monitored. Concretely, it is possible to refer here to the requirement number 5:Provide versatility in the sensor’s implementation/connection. 4.2 Arduino Up to now, due to the fact that the rest of the parties were not yet considered definitive, the alternatives of Arduino Mega or Nano, to implement the Processing Unit, have both been considered. However, at this moment, it is convenient to choose one of them in order to continue with the project. The characteristics of both boards have already been discussed in section 3.2.2.1.1, and the differences between them can be found in Table 4. 4.2.1 Arduino Nano vs Mega The price of both can be considered a determinant factor to decide since Arduino Nano costs 20 euros [7] whereas Arduino Mega costs 35 euros [8]. We have mentioned above aspects of size, resulting Arduino nano advantageous over mega, if integrating everything into a small system is aimed. However, above all this, it is found the factor related to memory. Once the other elements have been defined, it is verified that a large number of external libraries is required. The size of the sketch increases whenever a library is added. The comparison between the memories follows in Table 13: MEGA NANO Flash Memory 256 KB of which 8 KB used by bootloader 32 KB of which 2 KB used by bootloader SRAM 8 KB 2 KB EEPROM 4 KB 1 KB Table 13. Arduino Mega VS Nano, memory comparison. As a recall: The Flash memory (program space), is where the Arduino sketch is stored. The SRAM is where the sketch creates and manipulates variables when it runs. EEPROM is a memory space that programmers can use to store long-term information. The three of them will be used in the implementation of the system, but the first two are essential to decide which board to use. Just by loading the ten libraries needed to use all the elements and leaving the program empty; it can be noticed how Arduino Nano is quite far from being able to be used without the risk of running out of memory. In Illustration 18, it is appreciated how this program requires almost 40% of the total SRAM memory and leaves only around 80% for the programming of functions and general code. When compared to the 9% and 2% occupation of Flash memory and SRAM respectively of Arduino Mega, which can be seen in Illustration 19, there is no doubt that Arduino Mega must be chosen in order to continue with the implementation. 37 37 Sistema Electrónico destinado a la gestión de sensores para la agricultura Illustration 18. Arduino program with the libraries that will be used and its result in Arduino Nano’s memory 4.2.2 Arduino Tests Now the tests needed to implement the parts that Arduino controls of the Processing Unit are explained. There are different functionalities of the Arduino, not related to the units connected to it, which need to be programmed for proper operation. These functionalities, such as time control or error forecasting, need to be addressed separately. How to implement those functionalities and the trials made is presented below. 4.2.3 Writing/Reading from EEPROM Provided that if the system is turned off, it has to work again; some information must be stored to permit relaunch without asking for it again. The EEPROM is a memory whose values are kept when the board is turned off, as previously mentioned. Therefore, when it was decided to use this solution, a necessary test to be carried out was to read and store data in this memory. Thanks to a library so-called “EEPROM.h”, performing the activities of reading and writing was straightforward employing its functions: read(), write(), update(). For this trial, since each address is a byte available, some values were written at specified addresses, then the Arduino board was disconnected and connected again. A program for reading the whole EEPROM was then uploaded to check whether the value was still the one previously assigned. Illustration 19. Arduino Mega's memory utilization when all the libraries are loaded Tests 38 It is observed in Illustration 20 that the default value of the memory is 255. At each address, only a byte is supported. In the final implementation, this memory will store information about the frequency and the identification of the sensors. ✔ Test check: Anticipate a possible turning off error. 4.2.4 Clock It is crucial to managing time in our system; Arduino boards can create clock signals and interact with timers or dates. Provided that a physical clock module is not available, again we resort to the time libraries available in Arduino. The Time library adds timekeeping functionality to Arduino with or without external timekeeping hardware. When included in a sketch, some macros, functions, and new variables are available to create timers. It is relevant to mention the time_t variable, having 32 bits, allows to store time format data in a precise way: The number of seconds transcurred from a date until the first of January of 1970 [9]. The variables containing time can be added or subtracted, a great advantage, for instance, to compare different dates. Once this is understood, it is essential to set the time in order to match it with the current time. The setTime() function allows doing the coordination accepting as parameters the current time and date. In conclusion, the first step regarding the clock point will be to set the time. Additionaly, knowing how to create moments of time will also have relevance. The structure tmElements_t implements this functionality, some details must be taken into account about its values, Illustration 20. Before and after writing on the EEPROM memory 39 39 Sistema Electrónico destinado a la gestión de sensores para la agricultura tmElements_t tm ; tm.Second= // Seconds 0 to 59 tm.Minute= // Minnutes 0 to 59 tm.Hour= // Hours 0 to 23 tm.Wday= // Day of the week 0 to 6 (It is not used in mktime) tm.Day= // Day 1 to 31 tm.Month= // Month 1 to 12 tm.Year= // Year 0 to 99 (Diference since 1970) once a structure tmElements_t is created, to generate the time it is necessary to do: time_t Time = makeTime(tm); Illustration 21. Displays the result of setting up a clock by using the setTime function, giving as parameters each number. ✔ Test check: In this case, it has been proved that it is possible to manage time with Arduino libraries and its functionalities. This test allows to include time in the implementations and helps to overcome time checks that are needed to fulfil the requirements. 4.2.4.1 Frequency checks Whenever a clock is defined, there is a function called “now()” which returns the actual time; it can be stored into a time_t variable. By utilizing this function, the actual time can be compared to an objective one in such a way that it is possible to check if the quantity of time defined has already elapsed. Illustration 22 shows the first try comparing a moment to another ten seconds after. Note that during a whole second, time objective is equal to the actual time, that is why “Time reached!” is printed several times. Illustration 21. Arduino Serial Port Communication: Clock setting Demo 46 Figure 15. Arduino Serial Port Communication: DemoPart 1 The next step is to ask for the sensors’ identification. An SMS is sent asking for the sensor in turn’s number. When the answer is given, this information is stored in the EEPROM. Figure 16 displays this process for the Ask for Sensor One’s identification User’s response Figure 16. Arduino Serial Port Communication: Demo - Part 2 47 47 Sistema Electrónico destinado a la gestión de sensores para la agricultura SMS asking for the frequency Response of the user SMS asking for another frequency seeing that the value was not correct Response of the user Next time when a measure is sent/stored is calculated Figure 18. Arduino Serial Port Communication: Demo – Part 4 four sensors in this example. The numbers correspond with the ones previously seen in Table 11. Whenever all the sensors are identified, a copy of the address assigned is sent to the user. This SMS is used as a double-check that everything is correct. The process can be seen in Figure 17. The last part of the setting up regards defining the frequency for the SMS texts that will be sent automatically to the user. The frequency is asked as a quantity of time in a hh:mm:ss format. The system takes into account the requirement that 30 seconds is the maximum frequency. In fact, in this example, a lower frequency is given to demonstrate this functionality. In Figure 18, the details about this section is shown. Sensor’s identification Figure 17. Arduino Serial Port Communication: Demo - Part 3 Demo 48 The user interface stands for the SMS app on the mobile phone. The aspect of the process described until now will result as follows in Figure 19. 5.1.2 Program flow In the regular workflow of the program, messages with the measurements will be sent, according to the frequency. Also, when a measure is stored in SD, a message is displayed on the screen. In Figure 20 the process is displayed; in this case, the User’s frequency is one minute. It has been waited for the process to occur twice. The new time when sending or storing data is again performed is calculated only after completing the activity, to avoid not taking into account possible delays on the network. Figure 19. SMS exanged in Getting Started Demo Part 49 49 Sistema Electrónico destinado a la gestión de sensores para la agricultura Storing measures in SD SMS texts with sensors’ measurement Updating time Updating storing time Figure 20. Arduino Serial Port Communication: Demo - Part 5 Demo 50 The following illustration shows the aspect of the SMS that update the status of the sensors periodically on the phone. Concretely the illustrations correspond to the previous Arduino transcription in Figure 20. . 5.1.3 Extra-Functionalities In 3.4.1 section, some functionalities were presented in Table 12, right now each of them is tried. - Address: Provided that the sensors may vary during the use of the device, it is possible to change the identification by using this keyword. Also, which sensors are currently connected is asked using “Address”. An affirmative answer must be given in case of wanting to change it. This process is shown in Figure 23 and Figure 22. Figure 21. SMS texts with the measures of the sensors 51 51 Sistema Electrónico destinado a la gestión de sensores para la agricultura Figure 23. Arduino Serial Port Communication: Address functionality - Consult: This functionality allows the user to know which were the values of the sensors at a particular Figure 22. SMS aspect of Address functionality Checking code Sending actual addresses’ value User’s response Demo 52 past moment. After sending the keyword, the time at which the consult wants to be made is asked. When the system receives this information, the data is searched all over the file, which is stored in SD. If the exact time is not present on the record for any reason, the solution adopted returns the closest value, either over or under it. Whenever the data is found, the quantity of values is checked, because the number of sensors connected could change over time. Both Figure 24 and Figure 25 show the workflow of this functionality. Figure 24. SMS exchanged in Consult functionality and Data record on micro SD 53 53 Sistema Electrónico destinado a la gestión de sensores para la agricultura Code checking Ask for the time of the consult User's response Searching for micro SD information Sending information to the user Figure 25. . Arduino Serial Port Communication: Demo - Consult Functionality Demo 54 - Frequency: The possibility of changing the SMS reception frequency during the execution of the programme is under consideration as well. For that purpose, it is necessary first to ask what the current frequency is, sending “Frequency” as a keyword. If an affirmative answer is given, a new frequency is asked. In the example shown below, the frequency started at one minute, is changed to one hour so that the SMS will not interfere with the course of the demo. In the end, the frequency is again asked in order to check that the value has been updated. Checking code Sending actual frequency value Sending actual frequency value User’s response Asking for the new frequency value Asking for the new frequency value User’s response Operation result Internal data storing Checking code Sending actual frequency value Sending actual frequency value User’s response Figure 26. Arduino Serial Port Communication: Demo - Frequency Functionality 55 55 Sistema Electrónico destinado a la gestión de sensores para la agricultura The process described in las paragraph has this aspect on the phone interface: - Ask for a sensor’s value: Each sensor will have a keyword to ask for its current value. This functionality is useful in case of having a low SMS reception frequency. Therefore, the user can have an independent update if wanted. The system answers with a text containing the current measure of the sensor. The results are shown in the following Figure: Figure 29. Arduino Serial Port Communication: Demo - Asking for a particular sensor's information. Figure 28. SMS example of frequency functionality Further investigation and future Improvements 62 Atmospheric pressure Measuring range 10 ~ 1100hPa Relative accuracy ± 0.3hPa Resolution 0.1hPa Temperature Measuring range -50 ~ 100 ℃ Resolution 0.1 ℃ Accuracy ± 0.3 ℃ Humidity Measuring range 0 ~ 100% RH Resolution 0.1% RH Accuracy ± 2% RH Power Supply DC 5V DC 12V DC 24V Signal Output RS232 RS485 Operating Environment Temperature -50℃～80℃ Humidity≤100%RH Protection grade: IP45 Table 17. Air temperature, Pressure and Humidity sensor characteristics - Wind Speed Sensor: The last but not least is wind direction and speed sensor. This one is a kind of physical device that detects and senses the wind direction information. It works by the rotation of the arrow of the wind direction, and transmits it to the coaxial code plate; at the same time, it outputs the relevant values of the wind direction. Veinasa’s wind speed sensor uses a three-cup wind speed sensor structure, whose structure is made with carbon fibre material. Several uses of this sensor among agricultural areas are found. 63 63 Sistema Electrónico destinado a la gestión de sensores para la agricultura Measurement range 0~45m/s; 0~70m/s start-up wind speed ±(0.3+0.03V)m/s (V-wind speed) Resolution 0.1m/s Power supply DC5V, DC 12V, DC24V, Other Signal output 4-20mA, 0~5V, RS485, RS232 Load resistance Voltage type: RL≥1KΩ Current mode: RL≤ 600Ω Working temperature -40℃~50℃ Relative humidity 0~100%RH Power consumption 50 mW Table 18. Wind Speed Sensor Characteristics 6.2.1.1.1.1 Sensor’s protocol In order to integrate all these sensors into a system, the common characteristic among them should be used. As regards to communication and power supply, all of them count with RS485 protocol as well as 5V signal. In order to apply this specific communication protocol, a far-reaching study of the protocol is required, it can be found in section 7.1.2. This choice also affects the processing unit since it must understand the information provided by the sensors. 6.2.1.2 Processing Unit Following on from what was described immediately above, it can be assumed that a new processing unit must understand and communicate with the sensors using the same protocol, RS485. This time, instead of using a general-purpose microcontroller, a great solution would be to implement a specific solution. Integration of all the components must be made, but also an allocation of memory and dimensioning battery. These will be the milestones to achieve when designing the new and specific PU. In this way, former extra-modules such as SD adapter could be avoided, prioritizing the integration of components. Illustration 31. Wind Speed Sensor [15] Further investigation and future Improvements 64 6.2.1.3 Communication 6.2.1.3.1.1 Communication channel Including a more efficient communication system without cost for the user will be an essential consideration to make. In this direction, information is gathered from various possibilities, for example, communicating with a database hosted on the internet, for which a wifi connection would be required; Bluetooth transmission, among others. In particular, a promising option was found when getting information about LoRa [10]. IOT’s wireless technology has been influenced by the emergence of low-power, high-range networks like LoRa. This is a wireless technology like WiFi or Bluetooth, which uses a type of radiofrequency modulation called Chirp Spread Spectrum (CSS). This modulation technology has been used in military and space communications for decades. There are several advantages found in LoRa for communication such as security, bidirectional communication, high tolerance to interferences, high sensitivity to receive data (-168dB), low power consumption, long-range 10-20 km, point to point connection, among others. In turn, LoRaWAN is a network protocol that uses LoRa technology for low power and wide area networks. The extensive coverage range would allow the design of a system that, through the use of this technology, could communicate successfully. 6.2.1.3.1.2 User interface In the case of the user interface, it should change accordingly to the choice made above. Thus, if the database option was taken, a web page could be created to show the data, or simply allow the user to access the platform where the data is located. Another option could be to create an application for the phone. The real goal is to make the user experience simpler and more accessible than the one implemented in the prototype. 6.2.2 Hardware wiring and implementation By investigating these new options, new ways of implementing the system have also been considered. The fact of having new components involves a reconsideration of some aspects. The following are new possibilities raised during the study for future improvements. 6.2.2.1 Sensors identification. As regards the connection of the sensors to the system, these are supposed to be connected and disconnected indistinctly. Identification is needed so that Processing Unit can have that versatility of connecting sensors indistinctly, which continues to be a requirement in this research. Right now, two options are explained, their advantages and disadvantages. 6.2.2.1.1 Keyboard and screen Providing the system with a keyboard and screen allows the user to provide the required information for the sensor’s identification. In this case, the procedure would be similar to the one proposed in the prototype of this work. Comparing this system with the current one, it would be much more versatile and perhaps more straightforward, without having to take care of the number of messages to make it minimal. However, it implies that the user must be physically present where the device is when this configuration is made. Besides, a module that allows wireless communication must also be included to transmit the data; therefore, the product would be more expensive. 65 65 Sistema Electrónico destinado a la gestión de sensores para la agricultura 6.2.2.1.2 Switch An efficient and highly versatile way of performing sensor identification would be to carry out this identification using electronics. A potential implementation is detailed in Figure 31. It is shown how the sensor connected would first be identified through a switch, that will contain an identification, understandable by the Processing Unit. Then, employing shift registers, the information identifying each sensor connected would reach the Processing Unit. The shift register will have parallel and serial input and serial output; an example of this is the 74LS165, depicted in Figure 31. When operating, the sensors will send their information in the same order as the unit receives the identification numbers, in this way, the PU would always know to which of them corresponds the information received. This implementation will require a lower level of electronic design. For example, it is assumed that this part would be attached via a HUB to the Processing Unit. This option has excellent advantages, e.g. in case of failure or restart, the identification can be made automatically; furthermore, no user intervention in the process is required. Figure 31. Switch implementation of the system Illustration 32. A real datalogger with keypad [22] Further investigation and future Improvements 66 6.2.2.2 Electronic design The fact of trying to implement a custom solution, entails that the coupling of all the parts would be done by means of a Printed Circuit Board (PCB), The design process of a PCB generally goes through 4 phases, search and design, schematic capture and simulation, board layout, verifying. At the end of this process, the board will be ready for printing. The possibilities in terms of programs that exist in the market for the design of PCBs have also been investigated; some of them are: KiCad, Multism, EasyEDA, Altium, EAGLE, DipTrace. They vary in the interface, price, etc. Concretely, during the development of the research, the use of PCB implementation programs was recalled through EAGLE in its free version. Illustration 33. Example of a PCB implementation in Eagle. 67 67 Sistema Electrónico destinado a la gestión de sensores para la agricultura 7 ANNEX 7.1 Introduction to Serial Communication In this section, information about Serial communication is provided. This communication is used when exchanging information between Arduino and the computer, but also between the SIM808 module and Arduino. There are Serial communication protocols, in particular, details about the RS485 and Modbus are included since the last section's sensors use this protocol. In this section, some words are underlined, a box follows with a concrete explanation. This way, a better comprehension of the descriptions can be reached. 7.1.1 Synchronous versus Asynchronous Serial communication The main characteristic of Serial Communication is that the data is managed in series. When the transmitter and the receiver cannot have the same clock signal, since it is not possible to send the clock signal over the communication line, asynchronous communication is performed. In that case, both transmitter and receiver have the same signal frequency, (Some possible values have been standardized: 110, 300, 600, 1200, 2400, 4800, 9600, 19 200, 57 600, 115 200 Hz) but different clock signal. Provided that the speed of the communication is highly related with frequency, because with each clock pulse a bit of information is transmitted, speed is measured on Bits Per Seconds or Baudies; the transmission period is measured in Bit Time (Tb). Once asynchronous communication has been established, it is essential to define the beginning of the transmission sequence. For that purpose, a start bit is introduced on the sequence. The start bit is none other than a synchronization bit, it has the polarity opposed to the idle line status, and its duration equals one Tb. On the other hand, the moment when transmission finishes is recognized because the length of the sequence is known in advance, usually 8 bits packets. An additional bit is transmitted to make sure that the communication line returns to the idle status after the packet reception, the stop bit. It has the idle value of the line. The first bit transmitted is the Least Significant Bit (LSB), the idle value of the Serial Line is HIGH, regarding what has been explained, the start bit has a LOW value as it is appreciated in Illustration 34. 7.1.1.1 Error Detection When using asynchronous communication, error detection is crucial. Hardware and software solutions have been implemented in order to solve errors. On the first hand, a hardware solution is, for instance, parity control, where an extra bit is transmitted to grant the integrity of the data frame. It could be either the LSB or a ninth additional bit associated to the byte. The number of ones in the data frame is an odd or even number according to the parity chosen, completed with the parity bit. On the other right hand, software solutions could be packets with a preset structure as well as a reserved field for checksum control such as Cyclic Redundancy Check Control (CRC). Illustration 34. Sampling data line in an asynchronous serial communication [23] Annex 68 7.1.2 RS-485 A standard of bus communications of the Open Systems Interconnection (OSI) model is the RS485; it is placed on the Physical Layer. Physical Layer of OSI model is the first and lowest one. It defines the topology of the network and the global connections of the computer to the network. Information about the physical mean used and the way of transmitting the data is gathered in this layer. The physical layer must contain details about: - The characteristics of materials (components) but also the electrical ones (Volts values, etc.) which must be used on the transmission of the data by these physical channels. - Functional aspects of the interface, such as the establishment, maintenance, and hard link freeing. Hard link: is a directory entry that associates a name with a file on a file system. All directorybased file systems must have at least one hard link giving the original name for each file. File system: Operative system's component in charge of administrating and facilitate peripherical memories’ usage. - How the bits flow is transmitted in the physical mean. - Electrical signal managing in the physical mean. - In charge of granting the connection. RS485 uses a twisted pair cable whose maximum length is 1200 meters transmitting in this case 300 bits per second, while the maximum speed is 10 Mbits/s for a length of 12 meters. Characterized for the differential interface; the signal travels through two cables so-called A and B, one is the inverted version of the other, which allows an excellent interference rejection. A graphic explanation is given in Figure 32 about differencial signal and interference rejection. It is seen how the difference between both signals remains the same, whether there is interference or not. Besides, RS485 uses multipoint connection with a total top number of 32 stations. In a multipoint network, each communication channel can be used to contact different nodes therefore, only one line of communication exists which use is shared by all the terminals. Figure 32. RS485 Interference rejection because of differencial signal. Among the electrical characteristics, it is found that the network uses 5 volts, a pull-up resistor may be added, but it is not compulsory if the distances are short, the bus value ranges from -7V till 12V. Also, for the receptors to identify the two possible logic states of line A and B correctly, the difference between both must be at least 0.2 V. 7.1.2.1 Data transfer Once the method is defined, it is also worth to mention the way data is managed in this standard. The information in each packet is codified in ASCII. All data transfer is initiated by the master because this protocol is based in a master-slave configuration. Thus, it is the master who sends an interrogation or individual command packets to the slaves. Each slave has a unique address. More details about the data package are given in the following section. Device 1 Device 2 V A > 0 VB > 0 V A VB V A - VB V A - VB 69 69 Sistema Electrónico destinado a la gestión de sensores para la agricultura 7.1.3 MODBUS Modbus is a protocol with a request-response workflow using a master-slave configuration. Two versions of this protocols are standardized: RTU, TCP, ASCII Modbus where the data model and calls to methods are identical, just the encapsulation is different; and Eron, Pemex, Plus, UDP, Modbus, which have non-interoperable variations. On the OSI model, this standard is placed on the application layer. While RS485 is the physical mean, the Modbus explains how the information is distributed. The Application layer offers the applications the possibility to access the other layers’ services, and it defines the protocols that are used by those applications to exchange data. The number of protocols is as many as applications can be found. Usually, the user does not interact directly with this layer. 7.1.3.1 Specifications Modbus frame consists of an Application Data Unit (ADU), which encapsulates a Protocol Data Unit (PDU). The Protocol Data Unit defines basic concepts of the access and data handling; it is conformed by the data and the function code. Moreover, it is considered the core of the specifications of the Modbus protocol, and its full size must not be bigger than 253 bytes. - The function code has flexible behaviour that the slaves can implement based on the application desired. It defines the kind of request that is made to the slave, codified by a number going from 1 until 127, among which public functions, user functions and reserved functions are defined. - The Data: All the data is stored in one of the four data or direction benches, detailed in Table 19, they define the type and access rights of the data contained in these blocks. Additionally, the bench selected provides the ability to restrict or allow access to different types of data. Object type Access Discrete input Just reading Coil Reading/Writing Input register Just reading Holding register Reading/Writing Table 19. Object benches Types on Modbus Each block contains a memory space, maximum 65536 items. The address range of these elements starts at 0 and ends at 65535; however, each data element is numbered from 1 to 65536. Each data frame has a preset configuration. Any frame coming from the master can be distinguished from one coming from the slave because of its configuration. - Master Data Frame: Table 20 displays how a data frame coming from the Master is made up. Below, an explanation of each field is gathered. Byte 01 Byte 02 Byte 03-04 Byte 05-06 Byte 07-08 Slave ID Function Address Length CRC Table 20. Master Data frame in RS485-ModBus Communication Slave ID: Indicates the device to which the frame is addressed. Function: Action to be performed. Annex 70 Address: Where to start looking for the information requested through the function. Length: From the address onwards, how many bytes should be taken. CRC: Modbus Checksum. - Slave Data Frame: Table 21 shows the data frame of the Slave. The main difference between the Master’s data frame and Slave’s is that the slave frame has a more significant number of bytes, according to the quantity of information requested. Byte 01 Byte 02 Byte 03 Byte 04…n Byte n+1-n+2 Slave ID Function # of Bytes Response CRC Table 21. Slave Data frame in RS485-ModBus Communication The Application Data Unit (ADU) includes the PDU, and a different ADU exists depending on the network protocol, the three standard formats are TCP, RTU, ASCII. 71 71 Sistema Electrónico destinado a la gestión de sensores para la agricultura REFERENCE [1] Learn OpenEnergyMonitor, “Learn OpenEnergyMonitor,” [Online]. Available: https://learn.openenergymonitor.org/electricity-monitoring/temperature/DS18B20-temperature-sensing. [Accessed 04 2020]. [2] L. d. V. Hernández, “Porgramar Facil,” [Online]. Available: https://programarfacil.com/blog/arduinoblog/ds18b20-sensor-temperatura-arduino/. [Accessed 2020]. [3] “Arduino,” Arduino, 2020. [Online]. Available: https://www.arduino.cc/en/Guide/Introduction. [Accessed April 2020]. [4] “ACOPTEX,” ACOPTEX, 11 January 2018. [Online]. Available: http://acoptex.com/project/264/basicsproject-053d-sim808-gsm-gprs-gps-bluetooth-evolution-board-evb-v32-atacoptexcom/#sthash.XoACMLoR.dpbs. [Accessed April 2020]. [5] “Wikipedia,” [Online]. Available: https://en.wikipedia.org/wiki/Hayes_command_set. [6] S. S. W. S. Ltd., “Shangai SIMCom Wireless Solution Ltd.,” Shangai SIMCom Wireless Solution Ltd., 24 December 2010. [Online]. Available: http://www.espruino.com/datasheets/SIM900_AT.pdf. [Accessed 2020]. [7] Arduino, “Arduino,” Arduino, [Online]. Available: https://store.arduino.cc/arduino-nano. [Accessed 05 2020]. [8] Arduino, “Arduino,” Arduino, [Online]. Available: https://store.arduino.cc/arduino-mega-2560-rev3. [Accessed 05 2020]. [9] Prometec, “Prometec,” [Online]. Available: https://www.prometec.net/time-arduino/. [10 ] CatSensors, “CatSensors,” CatSensors, [Online]. Available: https://www.catsensors.com/es/lorawan/tecnologia-lora-y-lorawan. [Accessed 2020]. [11 ] R. S. S. a. A. G. Barto, Reinfordement Learning: an introduction, 2018. [12 ] “Components101,” 7 May 2018. [Online]. Available: https://components101.com/sensors/ds18b20temperature-sensor. [Accessed 2020]. [13 ] “AprendiendoArduino,” 28 June 2016. [Online]. Available: https://aprendiendoarduino.wordpress.com/tag/dht/. [Accessed 2020]. [14 ] “Makerfabs,” [Online]. Available: https://www.makerfabs.com/soil-moisture-sensor.html. [Accessed 2020]. [15 ] Sunny, your only power source, “Sunny,” [Online]. Available: https://www.sunnyeuro.com/es/productos/sys1308-2412-w2e-europe-2-1x5-5x11-s-rc-1-8m-6ft. [Accessed 2020]. [16 ] B. Smith, “Campbell Scientific,” 9 January 2019. [Online]. Available: https://www.campbellsci.com/blog/keypad-commands-edlog-data-loggers. [Accessed 2020].