Degree Thesis
Computer Science and Engineering, 180 credits
Application for automated pressure measurement
Bachelor Thesis in Computer Science and Engineering, 15 credits
Halmstad 2021-05-29
Andreas Östlin, Niklas Andersson
Andreas ¨Ostlin Niklas Andersson
1
Preface
The following report is a university thesis at C-level and a final report for the course Examensarbete, 15 credits. The course is compulsory at the School of Computer Science and Engineering, 180 credits, at the Depart- ment of Information Science, Computer and Electrical Engineering (IDE) at Halmstad University. The degree project was carried out in the spring of 2021 in collaboration with Conmore.
We want to extend our thanks to our advisors, both at the University of Halmstad Marco Marinho. And at the company Fredrik Hansson. With- out them, neither the report nor the project would have been as successful as it was. We would also like to thank Conmore for the opportunity to work on this project.
Sammanfattning
Vid installation av rör som är tänkt att hålla högt tryck så finns ett krav att tester utförs och dokumenteras för att utrustningen håller en viss standard. I dagsläget utförs detta arbete manuellt med en manometer och kräver en byggarbetare som håller översikt, ibland över ett tidspann av flera timmar. En kund kom med en idé till ingenjörsbyrån Conmore om att automatisera denna process och på så sätt effektivisera arbetet och samtidigt eliminera handhavande fel i processen. En kravspecifikation skapades i samarbete med företaget, kunden och studenterna som arbeta på projektet för att se till att alla parter skulle bli nöjda med färdig produkt. Den färdiga produkten resulterade i en prototyp som uppfyller alla minimikrav ur specifikation samt många fler funktioner som kunde läggas till utöver. Vissa funktioner bedömdes även mer lämpliga för ett ytterligare projekt då kunskapsområdet blev för bredd för tidsspannet. Prototypen kan i dagsläget mäta tryck i realtid både via den fysiska displayen och på applikationens API. Den kan även spara mät sessioner i en databas för att hämtas när dem behövs.
Abstract
When installing pipes meant to hold high pressure, there is a requirement that this process is tested and documented. Today this is done manually with a manometer and requires a construction worker to monitor this, sometimes over several hours. A customer approached The engineering bureau Conmore with an idea to streamline this procedure by automation, and in the process, remove human error and free up work time during construction. A specification list was created with the company, the students and the customer to ensure the project would result in a prototype all parties were happy with. The finished product resulted in several additional features from the initial specification whilst certain features were deemed better suited for a second project, as they were spread among too many different areas of knowledge. The prototype can measure in real-time, both from the physical monitor and at the applications API. It can also save earlier measurement sessions to be accessed whenever they might be needed.
Contents
Sammanfattning iii
Abstract v
Introduction 1
Description . . . . 1
Purpose and goals . . . . 1
Limitations . . . . 2
Theory and background 3 Choosing a technology . . . . 3
Wi-Fi or Bluetooth . . . . 3
Arduino . . . . 4
Measuring analogue input to data . . . . 4
Analogue to digital on Arduino . . . . 5
Representing the output . . . . 5
Previous solutions . . . . 6
Sensor calibration . . . . 6
Falling pressure in hydraulic separators . . . . 6
Wireless transfer . . . . 6
MQTT . . . . 7
ThingsBoard . . . . 7
Arduino uno . . . . 7
LCD display . . . . 8
Wi-Fi microchip . . . . 8
Pressure Transducer . . . . 9
Programming languages . . . . 9
Waterproof container IP66 . . . 10
Method 11 Task specification . . . 11
Budget . . . 11
Communication and planing . . . 11
Choosing the right approach . . . 12
Software and Arduino setup . . . 12
Hardware Assembly . . . 13
Converting sensor output to readable values . . . 14
Calibration . . . 14
Programming the prototype . . . 15
Application programming interface (API) . . . 16
Rule chain . . . 16
Testing . . . 17
Results 19 Research . . . 19
Construction . . . 19
Software . . . 19
Prototype code . . . 20
Application code . . . 20
Test results . . . 20
Application . . . 21
Summary . . . 22
Discussion 23 General . . . 23
Further development . . . 23
Lessons learnt . . . 24
Conclusion . . . 25
References 27
Appendix 30
Introduction
Conmore, a consulting company in Mölndal, that provides engineering services to clients, was approached by a client with the desire to automate required tests that occur during the installation of pipes designed to hold high pressure. Together with these two parties, the students have worked to develop a working prototype for automation of pressure measurement to help alleviate this problem.
Description
During the installation of pipes, that are meant to hold intense pressure, tests are performed by pressurizing the pipes. The tests are conducted to ensure that no future leakage occurs.
The tests also consist of reading a manometer to make sure that the pressure is stable. If an installation passes the test, a formal report of measurement results must be filled and submitted.
In the project, it has been investigated whether it is possible to replace the reading process by storing data and presenting the results on a completed form directly via a web service.
Purpose and goals
Develop a system that would facilitate work and minimize any handling errors when measuring pressurized pipes. Deliver a Prototype product for automatic measurement. Compare Bluetooth and Wi-Fi for the prototype from a stability and price standpoint.
• Minimum requirements
1. Prototype can measure pressure towards the test rig
• Ideal requirements
1. Prototype connected to application through Wi-Fi 2. Transmit measured data by Wi-Fi
3. Present measured data in application
• Desired requirement
1. Add temperature sensor to compare air to liquid 2. Application support dynamic forms
3. IP66 Casing
There was no specifically requested sample rate or accuracy other than not having less accuracy than reading a manometer manually. Therefore, a chosen sampling rate of 2 seconds was decided to keep a steady flow of values for the API without flooding the system with values. An accuracy of 2 decimals was chosen to increase the accuracy significantly when compared to the previous manual readings.
Limitations
Evaluation of optimal programming language was not performed; previously known languages would expend less of the time budget and therefore were used instead. Furthermore, the product will not be built with large scale production in mind as the project scope covers only the development of a prototype. Therefore, the parts bought might not be ideal in order to remain within the budget provided by the company.
Theory and background
Choosing a technology
When building prototypes for applications and testing small functional devices, the leading two technologies are Raspberry Pi or Arduino. Both technologies can work similarly, with physical attachments mounted on their boards interacting directly with software. The main difference between them is that a Raspberry PI contains a microprocessor that can run a complete OS which means the Raspberry is closer to a fully fledged computer, and, therefore, needs to be booted, but can handle much more complex code. The Arduino, on the other hand, has much more built-in compatibility with analogue receivers, like a pressure sensor, this means that no external libraries will have to be implemented in order to read the input value. In contrast, a Raspberry would need to include several libraries and require some setup to get the same results. No powerful computing was needed, but a direct connection as analogue input was used. Furthermore, an Arduino, can get a faster startup as we do not need to boot up the OS.
Therefore, the Arduino was a better fit for our project [1].
Wi-Fi or Bluetooth
The customer requested an investigation of whether Bluetooth or Wi-Fi would be more suitable for the project both from a price and a stability standpoint. Due to the limited time and financial budget available, it was decided that only research for relevant reports on the subject would be done. The results from a report, ESP8266 based implementation of wireless sensor network with Linux based web-server [2] and Arduino based home automation using Internet of things (IoT) [3] The specifications for the technologies can be listed as following.
Wireless comparison table Technology Maximum power
consumption
Maximum range Cost Data speed
Bluetooth 100 mW 10 m medium 1 - 3 Mbps
Esp8266 100 mW 150 m low 1 - 11 Mbps
Bluetooth uses the 802.15.1 IEEE standard and Esp8266 the 802.11. Looking at the specifications and several other arguments in the reports, like the longer range and higher data rates, the cheap Esp8266 is almost always preferred for microcontroller data transfer.
Arduino
Arduino is a company that manufactures hardware and related software. The products are
"open source", which means that anyone can access the source code of their components and use it or edit it. The company’s most common product is its micro-controllers; this can be compared to a small and primitive computer. Micro-controllers from Arduino use their own programming language to communicate with the board, and it is also compatible with C and C ++, this makes it easy to learn and adapt for beginners in programming. Arduino cards are cheap, and with its global user base, there are thousands of sample codes to take advantage of. This makes it possible to quickly build functional programs, which further contributes to the technology being popular with beginners and hobby users. With that said, there is nothing to prevent the cards from being connected and used in more complex circuits and robots with other electrical components that can perform tasks the Arduino card provides [4].
Measuring analogue input to data
An analogue-to-digital converter is a type of system that converts an analogue signal, like pressure from a gas or liquid, into a digital signal. An ADC, as it is often called may also provide an isolated measurement, in short an ADC is an electronic device that converts an input analogue current or voltage to a number representing magnitude of the current or voltage. Most often a digital output will be in the two’s complement binary number which is proportional to the input. Most ADCs are implemented as integrated circuits. These are typically metal–oxide–semiconductors or a (MOS) mixed-signal integrated circuit chips that can integrate both analogue and digital circuits [5].
In an ADC, there will always be an error. Even at the assumed zero value of the sensor, it will fluctuate in a error margin of a couple of micro Volts. This is because the signal cable will act as an ”antenna”, in low cost analogue input modules there can be an expected error of about 2 % this is given from 0,1 % (pressure transmitter) + 0,1 % (transmission path) + 1 % (analogue input module) + 1 % (analogue input module temperature error) = 2,2 % [6]. The final use of converted data will determine the required sampling and conversion rate of the data acquisition and conversion system [5].
Figure 1: Analogue to digital conversion
Analogue to digital on Arduino
The Arduino board can read the value from the specific analogue pin. The boards contain a multichannel, 10-bit analogue to digital converter. Meaning it will map voltages between a start value of 0 and the operating voltage ranging from 3.3 to 5 Volts to an integer value between 0 and 1023. For example, an Arduino UNO yields a resolution of 0.0049 volts (4.9 mV) per unit.
5 Volt
1024units = 0.0049 Volt per unit (1)
The range of the input can be changed using the built in analogReference() class, the resolution can be changed using the analogReadResolution() class. On ATmega based boards (UNO, Nano, Mini, Mega), it takes approximately 100 microseconds to read an analogue input, so the highest polling rate is nearly 10kHz [7].
Representing the output
In microprocessors and micro-controllers negative numbers and subtractions are represented in 2’s complement form. And many ADCs are designed for use in very time-constrained real-time systems. By having a 2’s complement format in an ADC (or other sensor) means that negative numbers are represented in a way the processor can use directly, without having to spend cycles doing the conversion from other formats.
A pressure sensor can store the pressure values in raw counts of 3 registers: PressureOut1, PressureOut2, and PressureOut3. The most significant bit of the PressureOut1 register indicates the polarity [8]. In figure 2 An example of a pressure calculation when the sign bit is 0 and the output is 1.023 Bar is shown.
Figure 2: example of a positive value where sign bit 0
Pressure Counts = 4191629 decimal value (2)
Pressure millibar = Pressure Counts
Scaling factor = 4191629 Counts
4096 Counts/mbar = 1.03Bar (3)
Previous solutions
Sensor calibration
Measurements in a laboratory environment implementing solutions relevant to this project were found in the IEEE database, Automated experimental procedure using sensors and Arduino - by K. Arasu of Bannari Amman Institute of Technology [9]. The paper deals with different ways to get scientifically accurate analogue to digital measurements, the tests conducted uses an Arduino microprocessor. It also discusses the positive features of working with open-source software and hardware as it will provide competitive and up to date versions. Other topics include how to calibrate the censoring technology and why. This paper is a good reference point for the project as it gives empirical readings for topics that will be central to the report and will be used to help calibrate the equipment in the project.
Falling pressure in hydraulic separators
In a bachelor’s thesis from mittuniversitetet Tryckfall över värmeväxlare - Alexander Eriksson, about making empirical and theoretical comparisons to measure data using an Arduino Uno microprocessor inspiration for development could be found [10]. As the project was dealing with similar technology and hardware, like the microprocessor and the sensor. It was deemed a good starting point for prototype development, it was also helpful to read a similar type of report to help with the structure of this report.
Wireless transfer
To transmit the data through Wi-Fi, some form of information transfer protocol must be used. Several protocols and technologies can accomplish this. However, the MQTT protocol or (Message Queuing Telemetry Transport) was used for this project. The protocol was chosen for the project because MQTT clients are small and require minimal resources, making it ideal for small microcontrollers. The protocols message headers are also small, which optimizes network bandwidth [11].
MQTT
Figure 3: MQTT Flowchart
The protocol is an Organization for the Advancement of Structured Information Standards or (OASIS) standard messaging protocol. It was developed for the Internet of Things or (IoT).
The design is meant to be a very lightweight publish/subscribe messaging transport. The idea was to create communication from remote devices using minimal bandwidth. The protocol is used today in many industries, such as car manufacturing, oil and gas, telecommunications, etc [11].
ThingsBoard
ThingsBoard is an open source Internet of things (IOT) platform widely used by both amateurs and industries. It provides an API to collect time-series of telemetry data and has a wide variety of ways to display said data. Different payment plans range from free to hobby users and startup companies, a premium server for companies, and more significant subscriptions for enterprises [12]. ThingsBoard was the host of the MQTT broker in the project, so all telemetry data collected from the prototype will be received there.
Arduino uno
The Arduino Uno was the first version to be released amongst their microprocessor catalogue.
This is a microcontroller board that is based on the ATmega328P [13]. There are 14 digital output/input pins and seven analogue inputs, a 16 MHz ceramic resonator (CSTCE16M0V53- R0), a USB connection, ICSP header, a reset button, and a power jack. There is much built-in safety for the controller; the only thing at any real risk is the chip (ATmega328P) [14]. This can be easily replaced at a low cost.
LCD display
LCD Display module with two rows and sixteen signs on each row. White on Blue with Back- light and SPI interface. It has a soldered connection module to reduce pins needed for wiring.
Figure 4: An Arduino uno micro-processor Figure 5: LCD display
Wi-Fi microchip
ESP8266 is a low-cost Wi-Fi microchip that has a complete TCP/IP stack and microcontroller capability. It is produced by Espressif Systems in China. The small module allows connection from microcontrollers to a Wi-Fi network making possible simple TCP/IP connections [15].
• Processor: L106 32-bit RISC microprocessor core based on the Tensilica Xtensa Diamond Standard 106 Micro running at 80 MHz
• Memory:
– 32 KiB instruction RAM – 32 KiB instruction cache RAM – 32 KiB instruction cache RAM – 80 KiB user-data RAM
– 16 KiB ETS system-data RAM
Figure 6: Wi-Fi microchip
Pressure Transducer
Daniu 143 is a pressure transducer that can measure pressure of up to 300 PSI. It has a linear output of 0.5-4.5 VDC, which is proportional to 0-300 PSI (0-20 bar). The transducer has an error margin of ± 2 % which leads to an error margin of ± 0.4 Bar.
Figure 7: Pressure Transducer
Figure 8: Transducer output assuming linearity
Programming languages
The Arduino is compatible with a simplified version of C++ which is widely considered to be its own language [16]. You can also write fully fledged C or C++ to the board [17]. Our Web client utilizes JavaScript which is a language that operates client side, this means commands written in the language will be executed on the computer who uses the service instead of having a server handle the computation. The project also employed Python, which is considered an advanced programming language that is interpreted, object-oriented and built on flexible semantics. This according to computerscience.org, a computer science website that helps with education and information on the subject [17]. These two languages handles the scripts of the platform, and are used together with Structured Query Language or (SQL) commands in the node programming of the website further explained in the method section. For the appearance and interactions of
dashboards and widgets HTML is used which is a language used to create web pages. It ensures proper formatting of images and texts in order for Internet browsers to can display them in the ways they were intended to look [17]. And lastly CSS or cascading style sheets, a language used to design and change the style of HTML documents is used to predefined how elements on the website should appear when used [18].
Waterproof container IP66
The IP class system is used to define how resistant a box is to help select the necessary equipment for a project. The first digit defines how resistant the container is to solid objects, like dust and the second to liquids like water. For this project, a container with the IP66 value was chosen. This means it is resistant to high-pressure liquids, as the pipes measure contains highly pressured water this felt appropriate [19]. The box also came equipped with pre-drilled threads with the correct measurements to mount an Arduino-Uno chip.
Figure 9: IP66 box
Method
Task specification
Before any research started, several meetings were conducted. First with the company in charge of the project and then with the customer that ordered the prototype. This was to make sure all parties involved were happy with the planned approach and create a prototype specification together with all parties. After these meetings a rough sketch of the project layout was completed.
Figure 10: Rough process flowchart
Budget
The budget for the project is provided by Conmore and was estimated around one thousand Swedish kronor.
Communication and planing
For the development of the project, it was decided that a system called user stories would be used. This is a part of Kanban development [20]. The system was created to avoid so-called bottlenecks in production. It works like a digital note board, where developers break down the daily work into smaller pieces. When a project is looked at in its entirety as the customer specified it, it is called an epic. When it is later shortened down to more minor elements, it is called a ”less” and after further compartmentalization, it will be a user story [20].
Epic → less → userstory
Communication with advisors, the company and the customer mainly were conducted through email. Meetings were also done remotely through Microsoft teams or Zoom due to the ongoing pandemic.
Choosing the right approach
At the start of the project, much research went into what hardware would be best suited for the project. This was done by looking at similar projects and seeing what issues might be encountered, both software and hardware related, this is further discussed in the theory section. Furthermore, a deep analysis of the documentation was conducted to make sure equipment and technology are compatible with the specifications. There was also a process to choose a good match for the software platform to present and transfer, ThingsBoard was chosen as it had a generous free version to start testing their functions. And easy scalability moving on to their premium version for larger production.
After one of the reoccurring meetings with the company and customer, the idea for the form was further developed. The original idea was for the previously existing form to be filled with the measured values from the prototype. The evolved idea was to implement some way for the application to identify what type of material the pipes are made of during a measurement sessions. And then add this information to the form, as well as the measured values. It was decided that the limited time for the project was not sufficient to implement all the desired features. Instead, it was decided that the form would have to be put aside, and the newly spawned ideas for the form be better suited for a different project, as it would require an extensive amount of testing to identify different expansions of materials or to work with some form of machine learning. These ideas are what we refer to as the dynamic form further on in the report.
Software and Arduino setup
Initially, online guides to learn how to connect the Arduino to software were used.
After this, the Wi-Fi chip was set up as a hub to a phone and to the board.
This required some rewiring as the chip required two 3.3 Volt sources. A simple app to control the built-in LED of the Arduino was created. This was done using the datasheet for both the chip and the processor. Once this was working the led pin could simply be replaced with the
pressure sensors pin. Figure 11: Arduino connected to Wi-Fi
Hardware Assembly
In order to make use of the container some reconstruction was due. A small breadboard was added to the container. The LCD panel was installed directly on the transparent lid as the user does not have any need to see the components underneath, and this saves valuable space for more equipment. The pre drilled holes in the box were used to mount the Arduino board to the bottom. Once all the components where added to the IP66 container, the listed hardware was connected using the data-sheets for the respective components according to the schematic (figure 12).
Figure 12: Prototype schematic
Figure 13: Prototype construction Figure 14: Finished product
Converting sensor output to readable values
The value read at the input pins of the Arduino is called analogue voltage, this voltage will be converted by the built in ADC that reads the changing voltage and converts it to a number between 0 and 1023 (equation 1). To read the actual voltage value on the pin one must therefore divide 5.0 by 1024 and multiply that by the sensor value. After a value for the voltage has been set it can then be converted into to Bar or Psi to display it on logs or the LCD of the prototype with the following formulas:
0 − 300P SI
0.5 − 4.5V =75 P SI
voltage (4)
of f set = 0.5 → 75 ∗ 0.5 = 37.5 (5)
P SI = (V oltage ∗ 75 − 37.5) (6)
Bar = P SI ∗ 0.0689475729 (7)
int sensorVal = analogRead(A1);
float res = 5.0/1024.0;
float offset = 37.5;
float voltage = sensorVal*res;
float pressure_psi = ((float)voltage*75) - offset;
float pressure_bar = pressure_psi * 0.0689475729;
Calibration
The sensor had to be calibrated before actual measurement could begin, this was done following the guidelines shown the previous solution chapter [9]. Calculations were made for expected analogue value (AV) from 0 to 300 PSI assuming ideal linearity.
AV(300 PSI) = 4.5 Volt
5 Volt ∗ 1024 = 921.6 (8)
AV(0 PSI) = 0.5 Volt
5 Volt ∗ 1024 = 102.4 (9)
Converting PSI to Bar gives the following equation for calculating AV for a given pressure
AV(Bar) = Bar ∗ 39.4356 + 102.4 (10)
The prototype was connected to the test rig and measurements were conducted by comparing the analogRead() in the Arduino IDE to the expected values from the calculations once the
pressure was stable. The results were inside the margin of error for the project and the sensor specifications as shown in the graph where we plot out logged values from analogRead() while adding pressure starting from 0 and applying a pressure up to 20 bar.
Figure 15: Experimental values for AV vs pressure in Bar
Programming the prototype
The prototype was built using the documentation from both ThingsBoard and Arduino. The libraries used in the Arduino code are the following:
• <WiFiEsp.h> - The Wi-Fi chips functions used for wireless transmission.
• <ThingsBoard.h> - Used for MQTT communication with the API
• <LiquidCrystal _I2C.h> - Used to display values on the LCD
• <SoftwareSerial.h> - For serial communication on pins 0 and 1
On the following page is a short code example on setting up a connection to the platform using the unique credential generated by the API, and sending a value to the rule chain.
#include <WiFiEsp.h>
#include "SoftwareSerial.h"
#include <ThingsBoard.h>
#include <LiquidCrystal_I2C.h>
#define WIFI_AP "Name of your router"
#define WIFI_PASSWORD "Routers password"
#define TOKEN "Unique token from set device on ThingsBoard"
soft.begin(9600);
// initialize ESP module WiFi.init(&soft);
// Send measured values to the ThingsBoard platform tb.sendTelemetryFloat("Bar", bar);
Application programming interface (API)
To send data from the prototype using MQTT a broker must be created, the broker for the project was set up on the IOT platform Thingsboard. Here the measured telemetry values are recorded on a rest API and displayed in graphs updated in real-time. To achieve this a ThingsBoard demo server was created. On the server the device is registered under a device tab, the Arduino UNO for this project. Once a device is registered on the platform it is given a unique credential number, this is later used in the Arduino code to make sure the put requests for the API is delivered to the correct credential. After a device is connected and continuously sending data to the server, different type of widgets can be programmed in order to make use of the data. For example graphs can be programmed to either receive data in real time or to show it historically, buttons can be made to either call the device or perform some action server side. All of these behaviours must be regulated from the rule chain, which is the heart of the platform.
Rule chain
The rule chain of ThingsBoard determines the behaviour of the broker. It is programmed using node programming. The nodes behave differently depending on how they are connected and how the code inside them is written. They use JavaScript or Python to change behaviour and SQL commands for connections. For this project, the input node will deliver all received data to a Python string enrichment. This is to add the on and off switch from the server-side.
This implementation was built because creating a remote procedure call or RPC command from ThingsBoard directly to the device caused the microprocessor’s memory to be insufficient. This caused a malfunction, and the device could not handle all features. For example, the screen would turn off, or the sensor would stop receiving. Therefore, the RPC had to be removed for the minimum specifications to work. As we still wanted to implement the feature, a workaround
was implemented to work on the server-side instead. If the button prompts the server to let information pass by the filter node written in JavaScript, the message from the input node will be translated to a relevant data set and saved to the database; otherwise, the API will ignore the data. This solution gives the illusion of turning off the prototype. It also makes it easier for a user to track a specific reading and makes the average value make more sense as one will not have to record filling the system with water and beginning of pressurising but can instead start measuring once pressure has been built up in the system.
Figure 16: Rule chain nodes
Testing
During development, the prototype was tested against a test rig provided by the customer.
The rig consists of a water distributor with plastic pipes mounted on a portable stand (figure 17). It has two connections, one for incoming water and another for the pressure transducer.
To pressurize the rig we use a manual water pump (figure 18), which has a capacity of 0-30 bar and a manometer for measuring outgoing water pressure. This was also provided by the customer.
Figure 17: Test rig Figure 18: Rothenberger test pump
The tests are conducted by filling the rig with water and applying a desired pressure. Whilst the rig is pressurized measurements from the prototype are compared to the actual value seen on the pump’s manometer. The test sessions are filmed from three perspectives and compressed into a single file for easy comparison. The three perspectives are of the display on the prototype, the application and the manometer (figure 19).
Figure 19: Sample of compressed file
Results
The results of the project span over a couple of different areas, so they have been divided into sections for clarity of the specific parts, looking individually on research, construction of the prototype, software both for the prototype and the application, and test results.
Research
Arduino was decided as the best suited microcontroller for the project because the operations of the prototype where considered to be relatively simple, it also had good built in support to work with analogue input. The dynamically adapting form was decided to be better suited for a separate project as the idea for the form evolved from the original idea to just store the values read, to self-adjust based on what material the pipes where made from, it would require knowledge in a completely different field and would not fall within the time budget for the project. For wireless transfer of data, research concluded Wi-Fi was the more ideal technology for the project as the cheap esp8266 WiFi module provided a powerful cheap alternative.
Construction
A water proof container was reconstructed to fit all the hardware for the project, all the connections for the device were thread taped to prevent any water leakage during measurement.
Any connections that had to be connected outside the prototype were attached with tightening cords to prevent disconnection from the board. The finished product is a small and portable device which is powered by batteries or USB cable. The prototype is water-resistant, with an LCD mounted in the lid to hide unnecessary complexity for users.
Figure 20: Finished prototype
Software
The software for the project is split into two parts, one for the prototype, which is written using C in the Arduino IDE. And the other on the ThingsBoard platform using several front end tools such as JavaScript, Python, HTML and CSS.
Prototype code
The code was developed over time in many different versions, using the ThingsBoard setup guide as a template to expand upon. The final iteration is written in a minimal way using C programming to make it easy to follow and edit to accommodate future alterations of the code.
The program defines the unique credentials from ThingsBoard, establishes a connection and loops, sending ADC converted float values to the platform using the MQTT protocol.
Application code
The IOT Platform ThingsBoard is configured where the prototype device is registered to get a unique credential. This device delivers data to an API with timestamps to store for later use, and to be pulled by the real-time graphs and meters to display how a current measurement is proceeding. These graphs, buttons and any other widgets used on the platform are programmed with a combination of JavaScript together with HTML and CSS for their appearance. The rule chain is setup to deliver data to the database once sessions have been prompted by a user to begin measuring, this enables database storing, and real-time viewing. Until the button is pressed, received data is discarded.
Test results
The results of the testing ended up with about three hours of measured values stored in the database from different reading sessions an example of which can be seen in figure 22. As well as one hour worth of footage collecting readings comparing the pressure sensor’s reading to the manometers and making sure the prototypes output on the platform and the display are correct, and within the project specifications. This comparison was filmed using a similar perspective to figure 21 and a sample of footage values over 35 minutes can be seen in the table below. Due to a minor leakage in the test rig the pressure is diminishing over time, however the two outputs can still be compared.
Sample measurements 5 minute intervals Time-
stamp
Manometer manually read
Display &
Application read
10:15 Bar: 10 Bar: 10.24
10:20 Bar: 10 Bar: 10.06
10:25 Bar: 9.5 Bar: 9.73 10:30 Bar: 9.5 Bar: 9.49 10:35 Bar: 9.2 Bar: 9.34
10:40 Bar: 9 Bar: 9.12
10:45 Bar: 9 Bar: 8.99
Figure 21: Test footage
Figure 22: Example reading activity from application database
Application
After the button is pressed on the dashboard to start measuring, the measurement is saved in the ThingsBoard database measuring once every 2 seconds and storing the values with a timestamp so a user can retrieve any measurement that was done by the device by just selecting the time frame. Furthermore the dashboard displays the graph of the current measurement in real time as well as the average from the current readings. There is also a live meter displaying the same value as the LCD is currently showing. A second graph is also in place showing the latest hour, this to represent a finished measuring. A picture of the dashboard is shown in the figure 23.
Figure 23: Dashboard
Summary
The project largely followed the time-plan created during the beginning of the thesis, see appendix(2). All previously listed hardware was mounted inside the IP66 container to create the prototype in the figure. It consists of a water-resistant box, two entries, one for the battery connector and another for the pressure sensor. The monitor is mounted in the box’s lid, so the user only sees information from the software. Furthermore, it conceals the hardware. The prototype has been successfully connected to the application through Wi-Fi, and it saves values in the platforms database. The website for the application stores values for up to thirty days, displays values in real time in a graph whilst showing the mean value of the session. It also has a historical graph to display a complete session after completion that can adjust to any length of reading, it also has a live meter to show the exact same value as a manometer would previously do. A step-by-step user guide has been created to use the device (see appendix) to help the customer and any future users of the prototype.
Discussion
General
Once enough meetings and discussions had been conducted between the school advisor, the company and the customer to solidify a complete idea of what the project would entail, what problems were supposed to be solved and get a project specification created. We began researching the topic and concluded there was no product on the market, building into the idea of the finished product. So the decision was made to create a prototype that would deliver on the requirements, such as having the data transmitted through Wi-Fi and present it in user-friendly way on the application. It was decided the prototype should be mounted inside a waterproof encapsulation and be as approachable and straightforward as could be managed.
The finished product ended up being a portable, water-resistant container with two connections, one for the battery and another for the sensor to be connected with the pipes being measured.
The prototype will instantly begin looking for a connection once it is supplied with power.
The user will be informed that the prototype is searching by the display. Once connected, the display will say it is online and display the current measured value on the monitor. The measured values are available on the applications API the second the device is connected to the internet. The pressure sensor accuracy falls within the project specifications, with the error margin being in the range of 2% or, more specifically, 0.4 bar for this project. This was achieved by doing the linear calculations for an ideal sensor, much like the report mentioned in the previous solution chapter [9]. As the thesis on dropping pressure in heat dividers [10]
was used as inspiration for this report, its results and discussions were taken into account for our design. This includes calculating the average value of the entire reading to minimize errors during measurement sessions, and as it was pointed out in their report, an improvement on the design could have been to add a display to view current readings from the prototype, which successfully implemented in this project. Our design also deviates from the SD card implementation of the previous project, as this project elected to send the values directly to a database.
Further development
There were many compromises in the project for various reasons. Most came down to budget constraints or time constraints. A lot of the time went into developing the prototype and the API application and connecting the two. Some features desired for the project like the dynamic form was left out. This is something that can be added to the project if the customer wants to continue development. The platform ThingsBoard was chosen because it supported alarm type features, such as sending an email once an alarm (which could be a set timer for measurement is complete), to an earlier specified email, and the idea was to have the form attached here filled in with values. Also, adapting the form to different materials and types of pipes requires some
form of extensive testing and listing of materials to find the correct delta between different ones. Or machine learning, a subject we decided the time budget for our project did not allow us to look into further but should be considered in the future. We also wanted to create RPC communication between the API and the prototype to control the prototype directly from ThingsBoard. However, the Arduino we chose to develop the project on (Arduino Uno) did not have enough memory to handle these features. This could perhaps be worked into a budget for future development of the prototype, to add a more powerful microprocessor. Because of the reasons mentioned above some features were left out of development but we would like to include them in the report as they might be relevant for a continuation of the project.
• RPC call to set approved average value from start to warn if pressure is low / or high
• Include some form of encryption of the prototype to increase security of the network
• Purchase a better suited IP66 container so it wont need to be adjusted, as the current is only water resistant when it should be completely waterproof.
• Pay for ThingsBoard premium services to add on many useful features, as well as make development of the application easier.
• Use a device built by more powerful hardware all together, this to remove the need for MQTT all together and send data directly to a server.
• A backup for when the prototype disconnects from Wi-Fi, this could be done in a similar fashion to the project in the previous solutions chapter [10], by using an SD-card. As the current prototype only functions when connected to the internet.
We also discussed making the device more intuitive for users to remove the need for a router or purchase a wireless router specifically for the prototype. This way, the Arduino code could be set to always connect to the specific router designated for it, so the user does not need to be present with their phone as a hub for the prototype, making it less dependable on a person being present. However, the most ideal would probably be to remove the need for a router altogether and buy a microprocessor with support for a sim card directly to remove any third party requirement, having the prototype connect directly to 4G once powered. This will come down to a discussion about cost.
Lessons learnt
We want to dedicate a section to the lessons we learnt as they were plenty and might be of use to people reading the project or planning to continue development. From a primarily high-end programming background like Java and JavaScript, some essential things to keep in mind, such as error messages that prevent compilation might not be present in C which can
instead trouble. Because of this, it is essential to conduct tests to make sure implemented code behaves as it is expected to, from our perspective even more so than in Java. Another pain point for the project was the implementation of the RPC button, where the Arduino was running out of memory. Here the IDE did inform us memory was running low, but other than this, no warnings were given out, and the code compiles and seemingly runs fine. However, the controller will allocate memory for the particular thing that is currently running. This caused us all kinds of problems, like the screen blinking and the sensor giving nonsensical values when trying to poll the server for the RPC values, so making sure your implementations altogether does not exceed the entirety of the processor’s memory is important. When working with a software project, some form of version control is crucial in order to keep track of the different versions of the program. This is mostly common knowledge in software development, and here we would like to add that it is well worth making a single version per function implementation and testing all features between each addition. This became apparent when a new version with multiple new features was implemented, where features stopped working, and there was no way of determining which one of the many features in the new version caused the errors.
Conclusion
The product is working with a very accurate result compared to the minimum features of the specification list and was made within the budget of one thousand kronor. Not all the desired features were implemented. The dynamic form part of the desired features was determined to be too far apart from the embedded systems programming most of the project leaned on. It would involve either machine learning, that the time budget did not allow for, or to conduct extensive tests to pre-record the correct values and means for different materials which ran into the same issues of time. So, instead, more time was redirected to the application part.
A lot more features were implemented on the API, such as tracking the average value of both current and previous measure sessions, turning on and off the tracking for the website from the server-side, and navigating through the database history of previous measurements. The code has been formatted in a simple way to make it easy to navigate and change features based on the customer’s specifications, and further implementations or alternative development of features have been discussed in the thesis to help someone completing the remaining parts of the project. There have been many measuring sessions with the test rig and rebuilds. As well as research for a lot of new languages, programming methods that needed to be learnt, and as the field, we studied for the project was extensive, we also ran into many bumps along the road. For example, jumping from writing C programming directly into JavaScript can be very difficult for formatting the code and following the programs’ flow, which leads to many headaches. It may not have any direct environmental effect, but we hope that if used correctly it will eliminate any error when running tests which might in turn result in less rebuilding and damaged property, this would lead to less of an impact on the environment.
References
[1] The Robotics Back-End. When to Use Arduino vs Raspberry Pi. url: https : / / roboticsbackend . com / when - to - use - arduino - vs - raspberry - pi/. (accessed:
20.03.2021).
[2] T. Thaker. “ESP8266 based implementation of wireless sensor network with Linux based web-server”. In: 2016 Symposium on Colossal Data Analysis and Networking (CDAN).
2016, pp. 1–5. doi: 10.1109/CDAN.2016.7570919.
[3] Nihar Mohanty Lalit Mohan Satapathy Samir Kumar Bastia. Arduino based home automation using Internet of things (IoT). url: https://acadpubl.eu/jsi/2018- 118-16-17/articles/17/57.pdf. (accessed: 15.03.2021).
[4] Arduino. About Us. url: https : / / www . arduino . cc / en / Main / AboutUs. (accessed:
15.03.2021).
[5] Texas Instruments. Principles of Data Acquisition and Conversion. url: https://www.
ti.com/lit/an/sbaa051a/sbaa051a.pdf. (accessed: 18.02.2021).
[6] Wika Alexander Wiegand Maurice Bildstein Stefan Heusel. Digital transmission in pressure sensors. url: www.wika.fi/upload/TA_0215_CANNewsl_en_co_64692.pdf.
(accessed: 10.03.2021).
[7] Arduino. analogRead(). url: https://www.arduino.cc/reference/en/language/
functions/analog-io/analogread/. (accessed: 16.02.2021).
[8] STMicroelectronics. How to interpret pressure and temperature readings in the LPS33HW pressure sensor. url: www.st.com/resource/en/technical_note/dm00434156-how- to- interpret- pressure- and- temperature- readings- in- the- lps33hw- pressure- sensor-stmicroelectronics.pdf. (accessed: 12.04.2021).
[9] K. Arasu. “Automated experimental procedure using sensors and Arduino”. In: 2017 International Conference on Inventive Computing and Informatics (ICICI). 2017, pp. 383–387. doi: 10.1109/ICICI.2017.8365378.
[10] Alexander Eriksson. Tryckfall över värmeväxlare. url: https://www.diva-portal.org/
smash/get/diva2:1239920/FULLTEXT01.pdf. (accessed: 03.03.2021).
[11] U. Hunkeler, H. L. Truong, and A. Stanford-Clark. “MQTT-S — A publish/subscribe protocol for Wireless Sensor Networks”. In: 2008 3rd International Conference on Communication Systems Software and Middleware and Workshops (COMSWARE ’08). 2008, pp. 791–798. doi: 10.1109/COMSWA.2008.4554519.
[12] Thingsboard Inc. About us. url: https : / / thingsboard . io / company/. (accessed:
16.03.2021).
[13] Atmel. ATmega328P Automotive - Complete Datasheet. url: https://ww1.microchip.
com / downloads / en / DeviceDoc / Atmel - 7810 - Automotive - Microcontrollers - ATmega328P_Datasheet.pdf. (accessed: 15.02.2021).
[14] Arduino. Arduino Uno Rev3. url: https://store.arduino.cc/arduino-uno-rev3.
(accessed: 20.02.2021).
[15] Espressif. ESP8266. url: https://www.espressif.com/en/products/socs/esp8266.
(accessed: 22.02.2021).
[16] flaviocopes. Introduction to the Arduino Programming Language. url: https : / / flaviocopes.com/arduino-programming-language/. (accessed: 16.02.2021).
[17] ComputerScience.org. Computer Programming Languages. url: https : / / www . computerscience . org / resources / computer - programming - languages/. (accessed:
15.02.2021).
[18] W3schools. CSS Introduction. url: https : / / www . w3schools . com / css/. (accessed:
12.03.2021).
[19] Glamox. IP klasser. url: https://glamox.com/se/ip-klasser. (accessed: 22.02.2021).
[20] Projektledning.se. Kanban. url: https : / / projektledning . se / kanban/. (accessed:
15.03.2021).
Appendix
A - Snabbstart Guide ...
B - Tidsplan ...
Tryckmätare – Snabbstart Guide (Applikation)
v. 2021-1
Andreas Östlin Niklas Andersson
29 april 2021
Sammanfattning
En enkel manual för att assistera mätning med prototypen, samt navigering av applikation.
Innehåll
1 Steg 1 mobil hotspot 3
2 Steg 2 Delning av WiFi 3
3 Steg 3 Anslut prototyp 4
4 Steg 4 Strömförsörjning 4
5 Steg 5 Starta mätning 4
6 Applikation navigation 5
1 Steg 1 mobil hotspot
dela nätverk från telefonen.
Ändra mobilhotspot:
Sätt användarnamn till: ************ (namn vid överlämning av projekt kan ändras).
sätt lösenord till: ************.
1. Börja med att navigera till Inställningar och peka på Mer under Trådlöst och nätverk.
2. Välj Internetdelning och hotspot följt av Inställningar för portabel Wi-Fi-hotspot.
3. Peka nu på Konfigurera Wi-Fi-hotspot. I rutan som dyker upp får du välja dels vad ditt utdelade nätverk ska heta (Nätverksnamn SSID) samt vilket lösenord nätverket ska ha.
4. För att slutligen starta själva utdelningen av Internet klickar du knappen bredvid Mobil Wi-Fi-hotspot. Din telefon skickar nu ut ett eget Wi-Fi-nätverk som andra enheter i närheten kan ansluta till och surfa via.
2 Steg 2 Delning av WiFi
Starta WiFi delning på telefon via mobil hotspot
3 Steg 3 Anslut prototyp
Anslut munstycket på prototypen till anläggningen som ska testas.
4 Steg 4 Strömförsörjning
Anslut batteri eller usb-sladd till prototyp
5 Steg 5 Starta mätning
Starta mätning / övervaka mätningen via applikation på adress https://demo.thingsboard.io/home.
Logga in med:
Användarnamn: ************
Lösenord: ************
6 Applikation navigation
1 Mätare:
Stapelmätare, visar det sista aktuella värdet uppmätt utav prototypen.
2 Start / stopp knapp:
Genom att klicka på texten startar eller stoppas mätning så att inkommande värden samlas till databas samt visas i grafer.
3 Graf 1
Realtids-graf, ritar upp samt visar nuvarande mätning i realtid och ritar upp grafen för tryc- ket.
4 Graf 2
Historiegraf visar graf och medelvärde för mätning som användare specificerar genom att klicka på klockan för att välja start och slut datum / tid.
Tidsplan
Figure 1: Tidsplan f¨or projekt
PO Box 823, SE-301 18 Halmstad Phone: +35 46 16 71 00
E-mail: registrator@hh.se Niklas, 29 år från Falkenberg, har tidigare arbetat som elektriker i 6 år.
Studerar nu till dataingenjör i Halmstad.
Andreas, född 1993 från
Hälsingland,tidigare arbetat som kock i ca 7 år studerar nu till
Högskoleingenjör i datateknik. Efter examen är jag anställd som
systemutvecklare på Quicksearch i Halmstad.
