June 12, 2022 by Andrei Florian
An affordable, portable water quality monitoring system integrated with cloud-computing services.
| 1 | Bandsaw | ||
|
|
|||
| 1 | Sander | ||
|
|
|||
| 1 | Hot Wire Strip Heater | ||
|
|
|||
| 1 | Soracom | ||
|
|
|||
| 1 | Microsoft | ||
|
|
|||
| 1 | Microsoft Azure | ||
|
|
|||
A GitHub repository for this project can be found here.
Figure 1: UnifiedWater device being held above canal
Yearly, over 8 billion tonnes of plastic enter the world’s oceans among other waste; from companies dejecting their waste products to individuals blind to bins, we all contribute to this number.
A staggering 80% of water pollution is directly or indirectly caused by humans, making water pollution one of the greatest challenges our society has faced to sate.
Water quality monitoring is essential for the identification of risks for human health and environmental issues and with growing awareness about this problem, designing accurate and robust devices that monitor and track water quality is essential.
UnifiedWater is a system that allows for the easy monitoring of water quality from anywhere in the world. The device is equipped with multiple sensors that collectively monitor the overall quality of the water. This data is streamed live to Azure IoT Central where it is then displayed on a dashboard.
UnifiedWater is an affordable, mass producible, and open source application which allows governments, private associations, and even individuals to take water quality readings and share them with the community, enabling data analysis and observations which can allow authorities to identify places that are being polluted (rivers, lakes, seas, oceans) and take appropriate action to ensure that the water is clean.
UnifiedWater operates in two modes: the device to be stationed at one point along a body of water and stream a consistent flow of data or be used to take single samples at various points along one or multiple bodies of water, hence making it easier and more cost-effective to identify the source of pollutants. The latter function is novel to our proposed system.
Figure 2: UnifiedWater device with a mounted solar panel
Water quality monitoring is a relatively new concept. Data collection is done in unstable environments, technologies are often proprietary, and the cost of operation is very high, bringing water quality monitoring out of the reach of even developed countries.
Existing solutions more often than not collect water samples to send to labs for inspection as opposed to collecting the data in the field. This takes longer and incapacitates live tracking of pollution. Modules that do collect data in the field are often large and bulky and lack flexibility, making it a pain to mount them and apply maintenance, on top of this, they often don’t collect sufficient and meaningful data.
But most importantly, they lack IoT connectivity. Devices that do send data to a central location often use proprietary technologies such as XBee and other radio communication methods which do not directly connect online. Adding pain to injury, these implementations are extremely expensive for what they offer.
Figure 3: UnifiedWater being carried around by a surveyor
This is where UnifiedWater comes in. Using industry standard sensors and IoT connectivity, UnifiedWater redefines water quality monitoring through a set of distinct features setting it apart from other devices on the market.
Interacting with the device is essential for longevity and ensuring its functionality. UnifiedWater can be configured remotely using twin properties in IoT Central allowing the authorities, universities, or private institutions to change the number of samples taken, interval of data collection and many other parameters. This reduces the amount of maintenance required by people on the field dramatically.
By only clicking a button online, the device can transition between enterprise mode (where it works with other devices) and personal mode (where it can be submerged at different points by a surveyor).
Figure 4: A look at the UnifiedWater dashboard
The flexibility of the implementation together with the low production cost, scalability, security, sustainability, and high accuracy set UnifiedWater apart from existing competitors. The only way we can make our waters cleaner and save marine species from extinction is by identifying the root causes of pollution by monitoring water quality. Be it in rivers, lakes, or oceans, UnifiedWater is in the front-line combatting water pollution.
This section of the publication will go into technical detail regarding the application. The overview section above gave a non-technical overview of the application.
UnifiedWater collects data from multiple sensors to encapsulate the overall quality of the body of water. Measuring water quality is difficult because there are a lot of parameters to look for (from temperature to presence of chemicals). It is not plausible to collect data on every parameter as that would require tens of sensors and significantly impact the device’s battery life and increase costs.
The balance between battery life and data collected has been carefully analysed. I reached the conclusion that the main data points needed are the water temperature, pH (acidity), and turbidity (as well as atmospheric temperature and humidity to be able to contrast them with the water temperature). The table below details the data collected by each sensor and the unit it is measured in.
Sensor | Data Collected | Units |
|---|---|---|
pH Sensor | pH (acidity) of water | pH scale (1 – 14) |
Water Turbidity Sensor | Amount of suspended, insoluble particles (in mg) in water per litre | NTU (Nephelometric Turbidity Units) |
Water Temperature Sensor | The temperature of the water (2cm below surface) | Degrees Celsius |
GY 21 Temp and Humidity Sensor | Temperature and humidity of atmosphere | Degrees Celsius and percentage respectively (where water is 100%) |
All the data collected is relevant and significant in measuring the overall quality of the water. As previously mentioned, a balance between volume of data and battery life must be reached. It would not make sense to only measure temperature and humidity (as this data does not mean much on its own) but nor would it make sense to include many more sensors as that would impeach the battery life of the device and exponentially increase costs.
The optimal values vary greatly by circumstance. This is especially valid for the pH of the water. For example, the average pH of a river is 7.4 while an ocean is around 8.1. If a river that in month x had a pH of 7.5 and in month y had 5.6, then it is plausible to say that it was polluted with an acidic substance such as phosphorus fertiliser. This measurement is very significant to deduce the overall quality of the water.
It is easier to judge the water turbidity value. Turbidity is measured by shining a beam of light through a water sample at 90 degrees and measuring the intensity of the scattered light. The light is blocked by insoluble particles suspended in the water, hence the more particles suspended, the greater the turbidity. Turbidity is measured in NTU (Nephelometric Turbidity Units), this measures the quantity of insolubles in water (in milligrams) per 1 litre of water.
Drinking water has a turbidity of anywhere between 0 and 4 ntu. The more polluted the water is with dirt, debris, manure, and/or human waste, the higher the turbidity. Water turbidity is essential for getting the overall water quality.
Finally, the water temperature reading is useless without the atmospheric temperature reading to contrast to (and vice versa). Very seldom are both temperatures the same (the smaller the body of water, the more similar they are). Usually, large bodies of water (seas, oceans) are warmer than the atmosphere during the winter and colder during the summer (because of water’s heat absorption).
But a recent Harvard University study has directly linked differences between water and atmospheric temperature to oxygen levels in the body of water. Oxygen becomes lighter when heated and becomes heavier when cooled. Using this logic, if the water is warmer than the atmosphere directly above it by a considerable amount (2 degrees up), the oxygen will leave the body of water by slowly rising. Note that if the atmospheric temperature is greater, the opposite effect will not take place.
Bodies of water are home to a vast quantity of life, if they were to be deprived of oxygen, their volume would decrease due to the area not being able to maintain the same volume of life. This means that species may be reduced in size and even endangered and migrations could take place.
All sensors offer precise readings and are suitable for long term exposure. It is recommended that all sensors be replaced every 12 to 16 months of staying in the field to ensure their precision.
All sensors come calibrated out of the box bar the water pH sensor. It is essential that this sensor is calibrated every 3 to 4 months to ensure its precision. The steps below reflect the recommendations provided by DF Robot.
The device collects the data from the sensors at an interval of time defined by the user in IoT Central (see lower down for details). The device will query data from the pH sensor and turbidity sensor a defined number of times at intervals of 1 second to eliminate any outlier data and average the values (this exponentially increases the precision of the readings).
The data is then stored locally until it is sent to IoT Central thereafter being deleted.
This section will detail the two operating modes of the device. As previously mentioned, the device can operate in two modes making it extremely flexible under multiple use cases. These modes are described below.
Figure 5: Architecture diagram of the device in Personal Mode
This is what sets the project out from its competitors. In personal mode (Figure 5), the device can be carried around by a surveyor as opposed to being fixed in a location. The surveyor can submerge the sensors in water, press a button and collect the data from the specific point. The data is then sent to the backend together with the geolocation of the reading and potted on a map.
This mode is very useful because it allows multiple points along a stream, sea or ocean to be measured with a single device. The device can be attached to a boat for example and set to take samples at periods of time, hence tracking the water quality as the boat sails and sending it to the cloud via GSM.
The device can also be manually handled by a surveyor tasked with collecting water quality readings at different points on a stream for a monthly report. The surveyor would travel the stream monthly, submerging the device at different points.
The use cases are endless. Multiple teams could be sent with such devices after an oil leak to see where the effects are worse and prioritise action. The device can be taken on a hiking trip to see if water in streams is drinkable.
This allows for inexpensive, robust monitoring whenever it is needed.
Figure 6: The architecture diagram of the device in Enterprise Mode
Enterprise mode (Figure 6) allows for the device to be fixed in a specific location and collect data and send it to the cloud at defined intervals of time. Tens or hundreds of devices can be fixed at different points along a stream, sea, or dock to measure the water quality in those respective places.
The data from all devices can be visualised as a whole or individually on the dashboard. This mode has endless use cases. A series of devices can be implemented temporarily along a polluted stream to identify the exact point where the pollution originates and allow authorities to take informed action. Devices can be placed along a dock where boats are parked to discover potential leakages before they damage the fauna and flora in the area.
This allows for industry grade efficiency and big data collection allowing authorities and corporations to precisely keep track of pollution in real time in any body of water.
The best part is that the device’s mode can be changed from the backend with the press of a button. Therefore, if a device has been in personal mode and authorities need it to be fixed in a location because the reading there was anomalous and they wish to investigate, all they have to do is press a button and the device will switch from collecting data when instructed to collecting at adjustable intervals of time.
The device uses GNSS to get its location. Because it operates on GSM, the module also allows it to query the precise location from the cell tower. Note that the device is aware of its location both in personal and enterprise mode but only reports it to IoT Central in personal mode (because its location is fixed in enterprise mode).
The device is also aware of the time by synching its onboard RTC to satellite time every time it reboots. This ensures that the device is always aware of the current time for signing certificates for IoT Central and parsing data.
Note that if the geolocation from the cell tower is not precise, a GPS module can be attached to the device (adding only €5 to the BOM). This will offer pinpoint accuracy at all times.
Figure 7: The device in Personal Mode taking a sample
The device is equipped with a Neopixel ring (which is 16 LEDs arranged in a circle). This ring is used for feedback in personal mode so the surveyor can keep track of what the device is currently doing. The table below details the significance of different LED colors.
LED Position/Color | Significance |
|---|---|
Loading white | Device is booting up and preparing everything |
Loading blue | Device is collecting sensor data |
Fast load blue then wait | Acknowledgement that the button is pressed, and device should be placed in water |
Loading green | Device is sending data to IoT Central |
Loading purple | Device is receiving twin changes from IoT Central |
Flashing/Loading Red | Device error. If flashing or staying red, reboot device and try troubleshooting by connecting to computer and turning the serial monitor on. |
GSM connectivity is used in the case of the project because of its wide availability across most of the world. This allows the project to work in most areas without a problem. Hologram was chosen as the sim provider because of the monitoring it allows in the backend. You can see exact usage of data as well as precise and affordable billing. The service also scales very well.
I decided to use Azure IoT Central for a wide range of reasons. IoT Central is industry standard when it comes to IoT management in the cloud and is created by Microsoft. This service is extremely reliable and can handle vast quantities of data streamed by thousands of devices, the services also scale very well and are very cost effective.
The standard pack comes with 2 free devices (with $0.40 per device per month thereafter) and 5,000 messages (with $0.015 per thousand messages per month thereafter). Hence, monitoring a long river with 100 devices would cost only €40 a month to operate in IoT Central.
The other reason IoT Central is so great is device twins. These are parameters that are synced in the cloud and on the device. They are different from telemetry data – which is sensor data reported by the device to the cloud because both the device and backend sync the values between them.
In enterprise mode, there are different timers set for collecting and sending telemetry to the backend. The device sends all messages to the backend in JSON messages and encrypts them using bit64 encryption.
In personal mode, the device will send the sensor readings and geolocation as telemetry directly after the data was collected. The table below shows the data sent as telemetry and in which mode it is sent.
Data Sent | Mode Sent In |
|---|---|
Atmospheric Temperature | Both |
Atmospheric Humidity | Both |
Device Geolocation | Only In Personal |
Water pH | Both |
Water Temperature | Both |
Water Turbidity | Both |
All communication is based on libraries provided by Microsoft for Arduino devices to connect to IoT Central. All libraries are open source.
Content goes hereDevice properties are different from telemetry data. These are pieces of information about the software or firmware of the device that are being sent to the backend. Twin properties are a special type of properties which are changeable by the user in the dashboard. These properties are then synced with local variables on the device enabling remote control over different device parameters. The table below lists all device twins and their roles on the device.
Twin property | Role |
|---|---|
Device Mode | Allows the user to switch between enterprise and personal mode remotely by clicking a button |
Telemetry Send Interval | The interval at which data collected by the device is sent to the backend |
Data Collection Interval | The interval at which the device collects data (not applicable in low power mode) |
Property Send Interval | The interval at which the device sends twin properties and location accuracy readings to the backend (not applicable in low power mode) |
Sample Value | The number of times the pH sensor and turbidity sensor are queried at an interval of 1 second when the device is collecting data (see above for explanation) |
This improves the device’s autonomy because these critical parameters can be set in the backend without the need of persons interfering with devices on the field. This is particularly helpful if vast quantities of devices are being used because instead of having to go out and manually flash different code on these devices in the field, the values can be set via a computer in seconds.
Figure 8: Architecture diagram of the property syncing process
The Figure 8 diagram shows the way these properties are changed. The device will check if there is a change in a twin property (unless in low power mode). When a change is received, the device will check to ensure that the change is valid (for example the correct data type is sent, and the value is not too large to hold as a local variable). If the change is valid, it will send back an acknowledgement confirming the change (the change will then show up as applied in the dashboard). If there was an error, an error message will be sent back, and the change will be marked as not confirmed.
The device also sends constant properties when it boots up. It will send information about the device such as its IMEI, model version and firmware version. This allows the users to view credentials of every device in the backend with the click of a button.
When booting up, the device will sync all its local variables with properties in IoT Central and confirm the setting. This ensures that the device retains the same settings even after restarting or receiving a software update.
There are two dashboards in the backend to which the users have access to. Note that different roles can be assigned to users allowing them to view only certain sections, control their ability to change twins and prevent them from viewing device details.
This dashboard is specific to each device in the application. If tens or hundreds of devices are being used, each one has an individual dashboard where specific properties can be changed (note that they can also be changed in bulk), device specific data can be read for troubleshooting and device details can be viewed.
The home page consists of a map where the location where device readings were made can be seen when the device is in personal mode (a single point is seen in enterprise mode for the device’s constant location).
Figure 9: The device specific dashboard showing all data collected on graphs
Scrolling down will reveal data posted by the device on graphs (Figure 9). This allows data from a single device to be visualised over time. The device info page displays the information about the device such as its IMEI and serial number.
Figure 10: The device specific dashboard highlighting the property change page
Finally, the settings page allows the user to change twin properties and set the exact location of the device when fixed in enterprise mode (Figure 10). Note that save must be pressed to update these properties.
The dashboard displays data from all connected devices accumulated in a series of graphs and cards. The largest element is a map that shows the location of all connected devices (in enterprise mode) or the location of readings of all devices (in personal mode).
All the other values displayed are averages from all devices connected (the number of connected devices is visible on the dashboard). This can be changed to display values for each individually. A graph illustrates the relationship between atmospheric temperature and water temperature over time.
Figure 11: The Project Dashboard highlighting graphs encapsulating the data collected by all connected devices
Scrolling down will reveal the water pH, temperature and turbidity readings displayed both on cards and online graphs (Figure 11). This data again is the average from all devices but can be changed.
The battery life of the project in its base configuration is about a week before a recharge is needed (1800mAh battery, bigger battery would proportionally increase battery life). This may not be ideal in enterprise mode and therefore many changes have been made (check the section below) to increase battery life. By running the device in low power mode and adding a solar panel implementation, the device can last on the field for weeks to a few months.
Note that battery life is currently only being sent to the backend in the base configuration because the addition of a solar panel to charge the battery does not allow the microcontroller to get the battery reading. I am currently working on this together with other future features in the going further section.
This section of the write-up talks about the device’s market, competitors, and production of the product.
The target market of UnifiedWater is very broad. The device can be used by everyone from government institutions to monitor the water quality in locations around the country to private individuals who want to occasionally measure the quality of water.
The product is focused on companies and institutions through the provision of two modes adding flexibility to the product. It is also reliable, self-sufficient, and inexpensive making it a great choice for both developed and developing nations.
This section will go over the cost of operation per device per month. This is calculated under the circumstances show in the tables below. Note that the amount of data used per message is averaged. Cost for personal mode varies by number of samples taken.
1 Device | Personal Mode |
|---|---|
Reboot and Setup | 100 kilobytes |
One Data Send | 10 kilobytes |
Cost per kilobyte send | €0.0004 |
Cost per message sent (cost per sample taken) | €0.004 |
Cost for rebooting and setting up | €0.04 |
1 Device | Enterprise Mode |
|---|---|
Telemetry Send Interval | 3 hours @ 10kb |
Property Send Interval | 1 hour @ 10kb |
Total data usage a day | 80kb (telemetry) + 240kb (property) = 320kb |
Cost per kb send | €0.0004 |
Total cost per day | €0.128 |
Total cost per month | €3.84 + 0.4 (device in IoT Central) = €4.24 |
Total cost per month (2 reboots) | €3.92 + 0.4 (device in IoT Central) = €4.32 |
The prototype built can be easily reproduced. All code is 100% open source meaning that anyone can use it free of charge. This dramatically accelerates production for the project. All components used for the project are available off the shelf meaning that they can be bought in bulk at a low price. Finally, all technologies used are scalable and can operate with anywhere from one to 1,000 devices. Below is a list of actions needed to be taken to bring this prototype to market.
The only step that must be taken to turn this prototype into a distributable product is the construction of a waterproof enclosure. The enclosure I built is handmade and only suitable for the prototype. I do not dispose of the tools needed to precisely produce such enclosures that would be available in large quantities.
This section will detail improvements added to the project as well as future aspirations and plans for developing the project more.
While developing the project, I came across a solar panel module I bought a while ago that I completely forgot about. So, I decided to implement it in this project. I figured out how to do the wiring and added it. It costs only an extra €20 to add this feature to a device. This allows the device to recharge the LiPo battery attached using a solar panel which can extend its battery life to months using low power mode (Figure 13).
Setting up has been covered throughout the article. Although the solar panel addition works perfectly with both device modes, it has been targeted at enterprise mode.
Figure 12: The architecture diagram for the device in Low Power Mode
This can be found in the low power folder in GitHub. This code branch is designed to exponentially increase the battery life of the device by putting the microcontroller in deep sleep between data reads.
The device will only use two properties: telemetry send interval; which will control the amount of time the device sleeps for between reads, and the sample value; which will determine the number of samples to collect from the pH and turbidity sensors. Note that the low power option is only available in enterprise mode.
The device will check for property changes when it wakes up, setting the variables accordingly and will then collect sensor data and send it to IoT Central. It will then check for property changes once more before going back to sleep for the defined period of time.
It is preferable that low power mode be used in enterprise mode to lengthen the device’s battery life. Setup for this mode is covered throughout the article.
This section covers new ideas and features for the project in the future. They are listed below.
If you have any other ideas or features you would like to see in the project, please comment down below.
This section of the write-up lists the steps needed to construct the project.
The required components can be seen in the bill of materials.
Figure 13: All the components required to construct the project
You will need the following machinery needed to hand build the enclosure for the project: a bandsaw, a hot wire strip heater and a sander. Note that CAD files are attached of the enclosure if you prefer 3D printing it.
Figure 14: An image of the schematics for the project
The Figure 14 diagram shows the circuit connections of the project. Please follow it to connect all the modules together. Note that if you are not using the solar powered version, the LiPo battery is to be connected to the MKR GSM LiPo battery socket.
If the solar shield is being used, please connect the solar panel and LiPo battery to corresponding ports on the shield and ensure it is turned on when operating the device. Connect the pins as instructed in the table below.
Shield Pin | MKR GSM Pin |
|---|---|
5v | VIN |
GND | GND |
Now that everything is connected. We need to set up IoT Central. There are a few prerequisites before we can get started.
Figure 15: Credentials needed to connect the device to the backend
Content goes hereAnd that’s it, you are ready to move on!
And that’s it, you are ready to move on!
I want to say a big thank you to Ian Hollier and Benjamin Cabé on GitHub for providing the libraries that I used to build this project. Their code is open source and available here. Anyways, before we move on, please install the following Arduino libraries:
We need to increase the payload size limit in PubSubClient to allow for the larger size of MQTT messages from the Azure IoT Hub. Open the file at %HomePath%\Documents\Arduino\libraries\PubSubClient\src\PubSubClient.h in your favourite code editor. Change line 128 as below:
#define MQTT_MAX_PACKET_SIZE 128
Ok, so now that all of that is ready, you can save the sketch and flash the code onto the device. Make sure you have your SIM inserted and antenna connected. You can turn the serial monitor on to see debug.
It took me a long while to get things started. There was a lot of editing of libraries and Googling involved as documentation around connectivity was really limited to that one example above. But in the end everything worked. Below are some basic troubleshooting tips.
In the end, if everything works, you should see data appearing in the RAW data section of the dashboard as shown in Figure 16.
Figure 16: A look at the data streamed by the device to the backend
And if you are really stuck, you can always contact me, I will try to help you as best as I can.
The dashboard is the place where all data collected by all devices is summarised.
Figure 17: A look at all the cards on the project dashboard
I started off with a large piece of plastic that I marked for cutting.
I then cut it into pieces using a band saw and sanded the edges making them soft.
I then bent the large piece into an open box using a hot wire strip heater.
At home I started gluing the pieces together and then insulating them. I am no expert at this, so I let my dad take the lead (I designed the 3D drawing in the meanwhile). We then drilled holes in the enclosure (everything is in the STL file available from Circuit Cellar’s article code and files download webpage).
We then stuck the components to the enclosure using a variety of adhesive (primarily double-sided tape as I did want to reuse the components). Figure 18 shows the inside of the device before the lid was sealed.
And finally, we sealed it off and tested it to ensure that water could not get in. If you are building this and intend on distributing it, it is better to 3D print it, I unfortunately don’t have a 3D printer, so I had to manually make mine.
Figure 18: The inside of the device before the lid was sealed
The last thing you need to do is calibrate the pH sensor (described above) and bring it out into the field!
UnifiedWater is a device which uses multiple sensors to detect the quality of water in a given area, and uploads this data to a database. The data can be monitored and analysed through an interactive dashboard to allow for easy visualisation.
I was inspired to create this project after seeing the disturbing water quality of a canal in my local area. I wanted to observe how bad it was and created UnifiedWater so that others could do the same in their area. I hope that in the future UnifiedWater can be implemented by organizations to measure the quality of large bodies of water, or that it is used by individuals such as myself to inspect their local water quality.
Secondary School Student and Part-Time Pursuer of Ideas.
