IoT Tide Gauge System
IoT Tide Gauge System
The project is compromised with two main
units, the transmitter and the receiver. The transmitter is integrated with the
sensor and the ATMEGA328 microcontroller, which does all the mathematical
computation and data management. The methodology and tools built to extract,
process, export, receive and display are laid out as follows.
Figure
1: Figure showing the transmitter process flow
This process is all implemented within the
program stored in the boot loader. The program is executed once and is burnt
into the boot loader. This process then remain in the system until the boot
loader is burnt again at any form. When the system starts, it will set up all
necessary parameters and will also ensure to set up its communication ports.
The GPIO 10 and 11 are reserved for communication purposes in this study.
Once
the communication ports are ready, the system begins analog reading with port
A0, A1 and A2. However, for this case, only A0 and A1 are occupied with active
data, while A2 is left as an extra active sensor port. Once the data is
extracted and calibrated, the data is prepared for transmission. To ensure data
can be differentiated from each other at the receiving end, data is stored and
packaged with a comma after each package before it is written to HC-12 module.
The data is sent one after the other and has to be received at the same order.
Figure
2: Figure expressing receiving, extracting and sending to
PLX-DAQ excel
Once the system is configured, the process starts as off as
the transmitter. It initializes all declared ports, the baud rate and the
communication ports. The receiving end need to recalibrate or generate new
values, it only displays the received values. The system will keep checking the
serial port with a small delay of 10 mS for available data. With the right
sequence of delay, the system will have a smooth interval of data extracted
from the receiver.
Once the data is received, it is checked if the data is true
by eliminating all zeros (0) that appears in the data. This also allows all
values in the same row to be eliminated along with the zero. All data are then
exported to PLX -DAQ excel. This is an excel extension that allows interface
with Arduino and other external processors. In here the data is printed in
real-time to its respective columns while live graphs and charts are plotted
with the respect to received data.
Figure 3: figure showing the whole
system process flow
Experimental Setup
The schematic was implemented on a single sided PCB and was
deployed in the sea for testing. A pole was first erected then the system was
implanted to it. These was done to test the system and extract some real-time
data.
Figure 4: (a) figure showing the erected poles with implanted set up.
(b) figure expressing the first reading at 5:13 pm. (c) figure showing the last
reading taken at 5:55 pm
The figure shown witnessed the setup flow where the pole was
erected with the deployed IoT Tide Gauge Real-time device. The following figure
(a), (b) and (c) expresses the process flow of the experimental setup where it
was deployed for 42 mins to extract water level change (high tide to low tide).
The hydrostatic sensor was raised 0.8 m
for its safety where the displaced part was considered within the code during
calibration.
Figure 5: figure showing the receiver unit mounted at the receiving
station
The figure expressed above shows the receiver module mounted
outside the receiving station. The receiving module receives data and sends it
through USB cable (type B) to the users’ computer.
Components & Parameters
Internet of Things (wireless communication)
Internet of things simply defines the interconnection of devises via wireless communications at any form. The wireless communication in this system adopted the HC-12 module long transmission which has a maximum range of 1.8 km. The module was adopted due to its high advantage in contrast with other wireless communication modules. It has variable channels and multiple communication range.
Figure 6: interfacing HC-12
with Arduino Uno
All communication
parameters of the tide gauge device are constrained with the communication
parameters of the HC-12 wireless RF UART V2.4 Module. The HC-12 communication
module adopts a half-duplex serial communication method which means that the
tide gauge has the capability of both sending and receiving data. A half-duplex
system can only send or receive signal at a segment of time.
Since the tide gauge
is constrained with the parameters of the HC-12 communication module, the
operation of the tide gauge device is limited by the HC-12 module operative
parameters. To begin with, some of the parameters are listed as follows.
Table 1: HC-12 module
operating parameters
|
Index |
Parameters |
|
Operating
Voltage |
3.2
– 5.5 V |
|
Maximum
operating Current |
200
mA |
|
Operating
Frequency |
433.4 – 473.0 MHz |
The HC-12 module has
an in built 3.2 V regulator that helps to protect the module from excess
voltage. It has an idle current consumption of 200 mA, which makes the system
consume up to 0.64 W when not in operation.
The tide gauge
operates from 433.4 to 473.0 MHz which can then be referred to a specific
frequency in terms of channels. The system is integrated with 100 channels
which allows the tide gauge to switch within these channels when finding
difficulties in communication. Switching between frequencies allows the system
to channel its communication to a reduced traffic frequency range depending on
the country’s communication frequency.
To achieve the
best communication range, the tide gauge is set to communicate at 9600 dB, at
this baud rate, the system operates with the most effective range and speed.
However, the system can communicate with four different power level that
categorizes the transmission range and power. The IoT tide gauge device was set
up and was put into a transmission range test.
To perform
external communication from one HC-12 to another, the following interface were
made.
Table 2: Table of HC-12
interface
|
Arduino to HC-12 Interface |
|
|
HC-12
PINS |
Arduino
PINS |
|
VCC |
5V |
|
Ground |
Ground |
|
RXD |
GPIO
11 (RXD) |
|
TXD |
GPIO
10 (TXD) |
|
SET |
Optional
(Ground) |
The table above
shows the connections of the HC-12 module with the Arduino board. The Arduino
board acts as a central processor where it collects data from sensors, process
it and send to the HC-12 module for transmission. The last row shows the set
pin optionally connected to ground, which shows that it will not have any
impact on the system while it is in operation mode. However, while the system
is interacted with the Arduino software, it is highly recommended that the SET
pin is left unconnected as it activates the settings of the HC-12 module,
allowing the user to change any necessary parameter of the module.
The Arduino GPIO 11 is
set to receiving mode and the GPIO 10 was set to transmitting mode. Once this
was declared in the code, transmission is securely established within the HC-12
module and the Arduino module.
Note:
All measurements were taken from google maps using geographic coordinates and
may not be exact depending on the satellite percentage error at your country.
Table 3: IoT Tide Gauge Power
level and transmission range using HC-12 module
|
Mode |
FU1 |
FU2 |
FU3 |
FU4 |
|
Transmission
Delay |
16 - 32mS |
366 - 600mS |
60 - 80mS |
1.1 - 1.3S |
|
Operating
Baud Rate |
115200
dB |
9600
dB |
9600
dB |
1200
dB |
|
Range |
0 - 160m |
0 - 500m |
0 - 995m |
0 - 1810m |
The table above
expresses the IoT tide gauge transmission ranges and some measured parameters
obtained. The mode shows the transmission modes the HC-12 was deployed with. As
shown in table 2, the adopted HC-12 was tested with all communication power
levels from FU1 to FU4 where the transmission ranges and delay was observed. As
shown by the table above, with FU4 mode of transmission the tide gauge is
capable of transmitting data up to 1810 m with a delay of 1.1 - 1.3S.
Putting FU3 into contrast with FU4, FU3 was capable of performing transmission
up to 995 m with very less delay (60 - 80mS).
There is a big difference between the transmission delays and has caused the
transmitted data to miss its respective columns for FU4 mode. This issue arose in the receiving side where
parallax communication is performed.
The lower power
levels have instant response of 16 - 32mS at FU1 mode and 366 - 600mS at FU2 transmission mode. Due to the
difference in transmission power mode and delays, the system was chosen to set
at default on FU3 mode with a 60 - 80mS transmission delay and a range of 0 - 995m.
Antenna
To establish long
range communication, a good antenna is needed. The HC-12 transceiver module arrives
with its own antenna but would recommend an upgrade for long range
transmission.
Figure 7: Antenna Connections
The Antenna 1 is always recommended to be connected for
secure connectivity. Antenna 2 is the default port which should be shouldered
with the default antenna. These can be witnessed in Figure 5. The default antenna is shipped with the HC-12
module and is only capable a communication ranging up to 750m with a 3-4walls
penetration power using FU3 mode. According to the datasheet, the board can do
communication up to 1000 m with a spring antenna at FU3 mode.
With the observation made from the above variations, an
improvement was needed on the antenna. A change was made from the default
spring antenna to an SMA antenna.
Note:
All measurements were taken from google maps measurements using geographic
coordinates and may not be exact depending on the satellite percentage error at
your country.
Table 4: Table of antenna range comparison
|
Mode |
Range |
|
|
Antennas |
Default (Antenna 1) |
SMA Antenna 2 |
|
FU1 |
0-160
m |
0-160
m |
|
FU2 |
0-500
m |
0-500
m |
|
FU3 |
0-750
m |
0-995
m |
|
FU4 |
0-907
m |
0-1810
m |
As shown in table 4 above, the default antenna was able to transmit data through the air over 907 m, while the SMA antenna was capable of transmitting data over 1810 m through open space at FU4 mode.
Hydrostatic sensor
A hydrostatic sensor
is a common water level sensor that operates at a specific range. The
hydrostatic sensor operates with direct current (DC). It operates at a range of
9 – 24 V but has a lot of variations and tuning needed to achieve the
best result. Some hydrostatic sensor appeared with a three-wiring system, four
wiring system and some with two wiring system. The three and four-wiring system
available data signal already provided for analog reading. However, the
hydrostatic sensor integrated with this IoT Tide Gauge has a natural two wiring
system structure.
Figure 8: adopted Hydrostatic
sensor with its available terminals
Figure 2 shows a
visual of the hydrostatic sensor used to measure water level and pressure. The
sensor has a linear range between 0-5 m. Shown in figure 2 are the available
terminals which were used to integrate with Arduino Uno.
To allow signal
interfacing of the two-wiring system hydrostatic sensor with the Arduino Uno
analog read, a current sensor was devised. Since the sensor converts the
supplied voltage into a current source, ranging from 4-20 mA, a resistor was
integrated in parallel to reduce the voltage to a lower ratio range of 0-4 V
while the sensor is operating at 12V.
Current Divider (0.004-0.02A to 0-6.6V)
Expressed in the above figure is the schematic
of how the two-wired hydrostatic sensor was integrated with Arduino Uno. A
constant 12 V supply was supplied directly to the postive end of the sensor
while the negative end of the sensor was connected to a 
resistor. The resistor value was obtained
using the basic Ohm’s law equation: V = IR
However, with R = 50 ohms,
the system will operate exactly at 5-meter range, with a tight interval. Since
the system has to be tested with a lower range, it needs a good spaced interval
of output to ease calibration.
Table 5: Voltage Conversion with default operating depth at 5 m.
|
Level |
Voltage
(V) |
Current
(mA) |
Voltage
(R1) (V) |
Unassigned
Value |
Depth
(m) |
|
Minimum |
12 |
4 |
1.32 |
0 |
0 |
|
Maximum |
12 |
20 |
5 |
1023 |
5 |
Therefore, a voltage high than 5 V was
set without operating at that voltage. This led to:
By letting R1 = 330 ohms,
the analog output of the sensor ranges from 0 - 6.6 V. As matter of fact, the
sensor will only generate 6.6 V when it is deployed to its maximum potential
(5m). To avoid voltage exceeding 5 V, the sensor will only be deployed with
depth less than 3.788 m.
Note: Do
not operate at the extended level.
Table 6: Voltage Conversion with suppressed operating depth from 5 m
down to 3.788 m
|
Level |
Voltage
(V) |
Current
(mA) |
Voltage
(R1) (V) |
Unassigned
Value |
Depth
(m) |
|
Minimum |
12 |
4 |
1.32 |
0 |
0 |
|
Maximum |
12 |
15.152 |
5 |
775.0248 |
3.788 |
|
Extended |
12 |
20 |
6.6 |
1023 |
5 |
The table above
summarizes how the voltage is transformed into an acceptable value where
Arduino can read. The Arduino Uno analog read can only support up to 5 V.
However, the hydrostatic sensor operates at 12 V with a two-wiring system. This
allows the system to generate the same voltage at the output with varying
current.
Since the hydrostatic sensor is a current source, it converts 12
V into a variable current source varying from 4 – 20 mA. Using the parallel R1
implemented in Figure 5, the measured voltage was reduced to a maximum of 6.6 V
with a ratio of 1:1.818.
As expressed in table 5, the system operating range was set at 0
– 3.788 m. Table 5 also expressed the operating levels of the system
categorized into 3 main levels. The system is safe to operate between minimum
to maximum operating level. Where the extended level was set to suppress the
operating depth from 5 m to 3.75 m.
The values tabulated
in Table 5 shows the operating depth suppressed for higher accuracy. To deploy
the device in the ocean, the device needs to be set back to its default
operating depth (5 m). to do so, R1 simply needs to be replaced by the 250 ohms as shown in the sample calculation.
After all, a 10 kiloohms potentiometer was implemented before feeding the signal to A0. The signal operated with the 10 kiloohms potentiometer initially set to zero, then it was slowly incremented until the value generated by Arduino Uno has the best incremental interval. The 10 kiloohms potentiometer was there to tune the incremental interval of the output to its best. The best incremental interval was observed when the potentiometer was at maximum turn (10 kiloohms).
System Schematic & layout
Figure 10:Transmitter Schematic Generated from Eagle PCB design
software
Expressed in Figure 9 above are the schematic layout of the transmission unit. The schematic laid out the interface of Arduino Uno and the HC-12 module plus the integration of the ESP32. The ports ESP32 ports were made available within the schematic where its working logic was reviewed but will not be covered in this paper. It was left out for future work extensions. The HC-12 module has the same integration as made in the receiver module. The most flexible part was the code where it all connected ports are decided and declared. All the ports shown in the schematic was made extendable to maintain the flexibility of the board.
Figure 11: Receiver Schematic Generated from Eagle PCB design software
Shown in Figure 10 above are the schematic layout of the receiver module. The scheme is capable of receiving and performing half duplex serial communication vis HC-12 wireless communication module.
Power Supply
The
figure above expresses the layout of the connections made for the 5V voltage regulator. The 5V voltage regulator
was compromised with two capacitors (C1 & C2) and a 7805-voltage regulator
IC. To achieve a pure DC signal, C1 was
set to at 10 microfarad with C2 at 100 microfarad.
Results
The excel grant user interface has multiple
user and was design to suit the need of flexible data and easy analysis. It has
multiple plots that shows live variations of data with actual raw data. The
charts were plotted live with respect to its time stamp and date as it was
recorded.
Figure
13: Plot of measured depth with respect to time
The graph shown in Figure 13 expressed the measured depth taken from 5:13 to5:59 pm. The depth
decreased from 0.68m to 0.60m. The
trendline plotted in red shows the linear gradient of the plot which was used
to show the wave fluctuations.
Figure
14: Plot of system accuracy
The figure above plots the error showing
the system accuracy. The minimum error from the above plot obtained 0.000211m while the maximum error reaches up to 0.007658m. The equation given below
was used to compute the error between the actual and the measured values.
Error = Actual - Measured
The figure above shows a
direct relationship between pressure and depth. The pressure was obtained from
equation (4) shown below. The hydrostatic sensor gave variations according to
the amount of pressure applied. Since the pressure and height are directly
related, any of the two parameters can be obtained from the other only if it
has been fully calibrated.
Battery level
Figure 16: figure showing the
battery level in GUI
The figure above expressed the battery
level displayed in excel GUI. It witnessed the actual measured battery level
(shown in the multimeter) comparing it to the GUI voltmeter. The GUI meter
shows 91% of the battery level, where the actual battery level in full capacity
is 12V. To compare, 91% of 12V was computed and it came up to 10.92V where the
actual battery level is 10.97V.
The IoT Real-time Tide Gauge Device was
designed particularly for a high-performance low-cost tide gauge with high accuracy.
It is true that IoT has many advantages over system and user monitoring
interface but it may also pose some disadvantages on different ways depending
on how the designed is laid out or structured. IoT systems has been developing
over the years and has improved in most of the areas that were left
unconsidered before. The ranges of communications have also grown unexpectedly
and has put a lot of effort to modern devices. On the other hand, tide gauge
systems have also been so developed and reengineered, that gave rise to existing
models with multiple working logics. As for this paper, multiple existing
models were reviewed and some of the challenges plotted were targeted.
Traditionally, hydrographic surveyors use
to manually extract data from the deployed system. As a matter of fact,
surveying should be done within 1 month to approximately 6 months to attain
quality results. In the duration of 6-months of surveying period, manual data
extraction may be challenging. IoT technology was adopted to replace manual
data extraction. IoT has different techniques where it manipulates Bluetooth,
RF communication and the world-wide internet.
This paper presented a designed IoT Real-time
Tide Gauge Device using HC-12 module. The HC-12 module is a module developed in
particular to long range communication up to 1800m. The module was adopted due
to its low initial cost and does not require any continual payment of data
transfer. As it operates using radio frequency wave, it does one to one module
communication which avoids the use of
the mobile data. The system is compromised with a transmitter and a
receiver. The transmitter collects data, calibrate it and sends it in packages.
The system has multiple channel and modes of communication which is used to
define the range and which receiver it needs to send data to. The receiver can
also switch channel to decide which transmitter to receive from. This is
controlled by the user.
To test the behavior of the system, a was
set up erected in the ocean to collect live data, while manual measured were
also taken accordingly. The manual measurements were taken from a fixed tape
line attached to the erected pole while the system generates reading from the
installed sensor. The sensor was set 0.8m above the zero line where it was
reduced with the generated value to consider its displaced position. The data
extracted was calibrated within the transmission unit before it is transmitted.
The receiving side has a data cleaning strategy which is implemented within the
program uploaded at the receiver unit. The data cleaning strategy eliminates
all zeros (0) ensuring that the graph maintains a smooth curve.
The system adopted a hydrostatic sensor to
collect necessary data needed. The hydrostatic sensor was chosen over other
pressure sensors due to its linearity range shown in the datasheet. The sensor
is linear within 5m in the datasheet but was not deployed to its maximum in
this paper due to the complexity of the set up. However, with the system being
deployed up to 0.68m in the ocean, it shows a solid linear curve which eases
data calibration. Once the sensor is linear, ‘map’ function was adopted from
the program to map the generated reading to the measured reading. This gives
the calibrated system measured depth. The calibrated system measured depth was
then compared with the manual measure value to plot the error graph. The system
accuracy came up to 99.98%.
The system accuracy is defined by the
difference between the calibrated system value and the actual manual
measurements. Experimental samples were taken per minute. There were multiple
data arrived within a minute and was reduced by taking their average. The error
curve plots the maximum error and the minimum error of the system at 47
samples. The plot made in Figure 15 shows the direct relationship between
pressure and height. This allows us to derive pressure from height or the other
way around. Equation 4 was adopted to derive pressure from given height, while
height was derived directly from variations generated by the sensor when
applied with pressure.
Battery Level is most vital out of all the
components integrated in the system. As the system needs power to operate, it
also needs a good monitoring system to show how much battery capacity is left.
As if a voltage divider was devised, it would consume some power simultaneously
as measurement is taken. To efficiently measure the 12V battery with minimum power loss, a single 2.4V battery was measured from the 5 series
batteries installed within the system. The measurements collected from the 2.4V lithium battery then multiplied by 5
considering the whole 12V battery pack.
Considering reliability and durability of
the system, a PCB was designed to ensure secure connection. Eagle software was
used to design and export the Gerber and Drill file needed for PCB milling.
Both the transmission unit and the receiver unit PCB boards were designed with
a minimum cupper thickness of 1.06mm to avoid line burnout.
Moreover, graphical user interface (GUI)
was one of the internet of things tools used to interact and communicate with
sensors which was used in this project. However, there are guidelines for GUI
design that determine how much information should be displayed, how to
categorize it, and where and how it should appear on the screen. Information
presented by a good GUI should be consistent and contextual. To save screen
space, it should eliminate unnecessary information and communicate properly.
Although these requirements are not ideal, they are sufficient to prevent
slight difference. Future GUIs will likely make use of
specifications unless significant performance improvements arise.
Comments
Post a Comment