Wireless Sensor And Actuator Nodes For A Process Control Experiment
Jesper Wälivaara
Civilingenjör, Teknisk fysik och elektroteknik 2018
Luleå tekniska universitet Institutionen för system- och rymdteknik
i
LULEÅ UNIVERSITY OF TECHNOLOGY
Abstract
Signals and Systems
Department of Computer Science, Electrical and Space Engineering
Master of Science in Engineering
Wireless Sensor And Actuator Nodes For A Process Control Experiment
by Jesper W
ÄLIVAARAThis report details the work which has been done to redesign an older process con- trol lab setup, in order for it to become fully modular and wirelessly controllable.
The process control lab setup of interest was the quadruple water tank process. As
a proof of concept, a single prototype tank module of the quadruple tank setup was
to be redesigned, where this new design would use entirely modular and wirelessly
controllable sensors and actuators. The design of these wireless devices was done
from scratch, the end result was that a set of micro-controller based devices which
communicate over Xbee radios were manufactured. Control of this wireless tank
system was achieved through a custom Simulink interface, said interface was also
created during this project. The finalized tank prototype system worked as intended
and it fulfilled all of the relevant system requirements regarding the sensor and ac-
tuator network design. There was originally a mechanical design component in this
project which had to be left after the initial research stages due to time constraints,
which concerned the construction of a new tank system. This prototype system was
a proof of concept, which proved the feasibility of building larger scale wirelessly
controllable process control systems, such as the quadruple water tank process.
iii
Acknowledgements
I would like to thank my supervisor Wolfgang Birk for giving me the opportunity to do this master thesis project, as well as supplying valuable advice along the way. I would also like to thank Dariusz Kominiak for aiding me with ordering of compo- nents and giving me access to the control lab at LTU. I also want to thank both Wolf- gang and Dariusz for their patience and continued professionalism when working with me during this thesis project.
Lastly I would like to extend a big thank you all my friends and family members
that have supported me throughout the entirety of my engineering studies. I would
not have managed to get this far without your continued support!
v
Contents
Abstract i
1 Introduction 1
1.1 Background . . . . 1
1.2 Project Description . . . . 2
1.3 Project Goals . . . . 4
1.4 Thesis Layout . . . . 4
1.5 Project Delimitations . . . . 5
2 Problem Analysis 7
2.1 Mechanical Design . . . . 7
2.1.1 Tank Dimensioning . . . . 7
2.1.2 Outflow Valve Selection . . . . 9
2.1.3 Pump Selection . . . 10
2.2 Software Solution . . . 11
2.2.1 Wireless Communication Protocol Selection . . . 11
2.2.2 Flexibility Of Software Solution . . . 11
2.3 Electronic Hardware Design . . . 12
2.3.1 Sensor Setup . . . 12
2.3.2 Power Delivery Requirements . . . 12
3 Method 15
3.1 Electrical System Design Process . . . 15
3.2 Software Design Process . . . 16
3.2.1 Micro-controller Solution . . . 16
3.2.2 System Base Code Development . . . 16
3.2.3 Simulink Interface . . . 17
3.3 Mechanical Design Process . . . 18
4 System Overview 19
4.1 Node overview . . . 19
4.1.1 Gateway Node . . . 19
4.1.2 Electrical Pump Control Node . . . 20
4.1.3 Valve Control Node . . . 20
4.1.4 Water Level Measurement Node . . . 21
4.1.5 Temperature Measurement Node . . . 21
4.1.6 Power Supply Scheme . . . 21
4.2 Simulink Interface . . . 22
5 Software Design 23
5.1 Software Overview . . . 23
5.1.1 Software Requirements . . . 23
5.1.2 Wireless Protocol Selection . . . 23
vi
5.1.3 Software Solution Components . . . 24
5.2 System Base Code . . . 25
5.2.1 System Base Code Architecture . . . 25
5.2.2 UART Interfaces . . . 25
5.2.3 Xbee Wireless Network . . . 26
Network Configuration . . . 26
Xbee API Operating Mode Driver . . . 27
5.2.4 System API Introduction . . . 28
Transmission Of Commands To End Nodes . . . 28
5.2.5 Node Device Drivers . . . 29
Gateway Node . . . 29
Valve Control Node . . . 30
Electrical Pump Control Node . . . 30
Temperature Sensor Node . . . 31
Water Tank Level Sensor Node . . . 31
5.2.6 System Base Code Limitations . . . 31
5.3 Simulink Interface . . . 33
5.3.1 System Actuation Block . . . 35
5.3.2 Serial Data Reception Block . . . 35
5.3.3 Serial Data Parsing Block . . . 35
5.3.4 Simulink Interface Limitations And Bugs . . . 36
6 Mechanical Design 37
6.1 Outflow Valve Solution . . . 37
6.2 Water Tank Dimensioning . . . 38
6.3 Pump Selection . . . 40
7 Electrical Design 41
7.1 Base Design . . . 41
7.1.1 Wireless Communication Solution . . . 41
7.1.2 Micro-Controller Solution . . . 42
7.1.3 Gateway Node . . . 43
Board Layout And Manufactured Device . . . 43
7.2 Electrical Pump Control Node . . . 44
7.2.1 Pump Control . . . 44
7.2.2 Heat Sink . . . 45
7.2.3 Power Supply . . . 45
7.2.4 Board Layout And Manufactured Device . . . 46
7.3 Valve Control Node . . . 47
7.3.1 Stepper Motor Selection . . . 47
7.3.2 Stepper Motor Control . . . 47
7.3.3 Power Supply . . . 48
7.3.4 Board Layout And Manufactured Device . . . 48
7.4 Temperature Sensor Node . . . 50
7.4.1 Power Supply . . . 50
7.4.2 Board Layout And Manufactured Device . . . 50
7.5 Water Tank Level Sensor Node . . . 51
7.5.1 Pressure Sensor . . . 51
7.5.2 Power Supply . . . 52
7.5.3 Board Layout And Manufactured Device . . . 52
7.6 Power Delivery Solution . . . 53
vii
8 Conclusions and Discussion 55
8.1 Conclusions . . . 55
8.2 Discussion . . . 56
8.2.1 Estimated System Cost . . . 56
8.2.2 System Performance . . . 57
8.2.3 Minimum Achievable System Sample Time . . . 58
8.2.4 Packet Loss . . . 58
8.2.5 Command Propagation Delay . . . 60
8.2.6 Recommendations For Future Work . . . 62
8.2.7 Personal Thoughts About The Project . . . 63
A Electrical Schematics 65 B Matlab Testing Scripts 73
B.1 Latency Tester . . . 73
B.2 Packet Loss Tester . . . 74
B.3 Latency Log Parser . . . 75
B.4 Packet Loss Log Parser . . . 76
Bibliography 77
ix
List of Abbreviations
AC Alternate Current
ADC Analog (to) Digital Converter API Application Programming Interface CAD Computer Aided Design
DC Direct Current FIFO First In First Out
GPIO General Purpose Input/Output HAL Hardware Abstraction Layer LTU Luleå Tekniska Universitet PAN Personal Area Network PC Personal Computer PCB Printed Circuit Board PWM Pulse Width Modulation TH Through Hole
TTL Transistor Transistor Logic
UART Universal Asynchronous Receiver/Transmitter USB Universal Serial Bus
1
Chapter 1
Introduction
1.1 Background
Research into wireless distributed sensor and actuator networks has been gaining popularity in recent years, this is mainly due to a growing interest from various industries to push the wireless technology. Direct quote taken from the IEC white paper on wireless sensor networks [8](p. 15):
“Today, industrial automation is one of the most important areas of WSN applica- tions. According to Freedonia Group, the global market share of sensors for indus- trial use is 11 billion USD, while the cost of installation (mainly cabling costs) and usage is up to more than 100 billion USD. This high cost is the main issue hindering the development of industrial communication technology.”
Evidently there appears to be a rather large financial incentive to explore the field of wireless industrial automation. By using wireless technology you gain increased system flexibility while also heavily reducing the cost of installation. To enable fu- ture research into this field, the researchers at the automatic control department here at Luleå Tekniska Universitet (LTU) have therefore requested that a new wirelessly controlled version of an older lab setup be built for this purpose.
This older lab setup was the quadruple water tank process as shown in Fig. 1.1.
This setup consists of water tanks, pumps and valves which are interconnected with each other in order to form a complex multiple inputs and outputs process control system. The quadruple tank system is a multi-variable laboratory process that can be used in the design of multi-variable automatic control schemes. For more details about the quadruple water tank process refer to[9](p.456 - 465).
The older quadruple water tank setup is currently being used here at LTU to teach students within the the field of automatic control on how to design multi variable process control algorithms. Larger scale versions of this type of automatic control process are commonly found within industries such as paper making and water treatment facilities. The control objective for a system like this one is to adjust the liquid levels in the tanks in order to control the chemical processes within.
This older system was then to be redesigned so that it becomes modular and wire-
lessly controllable. A new prototype system consisting of a single tank module from
this quadruple setup was to be designed and constructed as part of this master thesis
project. The idea was that this newer system would be fully wirelessly controllable,
where each sensor and actuator would exist on separate devices. This prototype
module would be created as a proof of concept before committing to building a
2 Chapter 1. Introduction
FIGURE1.1: Image of old quadruple tank setup. There are four tanks that are interconnected by tubing and valves. During normal oper- ation there would be a reservoir of water just below the two bottom tanks, which is where the pumps would source their water from. This system is connected to a nearby PC to factilitate implementation of control algorithms. The control objective is to balance the liquid lev- els in the tanks, this objective would be accomplished by actuating
the valves and pumps accordingly.
larger scale system for future research. The researchers were interested in exploring how automatic control systems can potentially be configured when you have a fully modular and wireless lab setup, and to see which problems could appear due to the use of wireless interfaces.
1.2 Project Description
The task at hand during this project was to construct one new prototype tank mod-
ule for the new quadruple tank system as a proof of concept. One tank module of
the older quadruple tank system is shown in Fig. 1.2, this is the design which to
base the new prototype from. This module consists of one capacitive water tank
level sensor which can be seen as the metal pipe inside the tank. It measures the ca-
pacitance between a copper wire and the surrounding metal casing, which is a value
1.2. Project Description 3
FIGURE1.2: Image of a single tank module from the older quadruple tank setup in Fig.1.1.
that changes based on how much water is inside the tank. There are two outflow valves at the bottom which are connected to servo motors. These servo motors can be used to adjust the opening degree of the valves, which would increase or decrease the flow of water exiting the tank. Lastly there is an electrical centrifugal pump in the bottom left of the image. This pump is used to supply water into the tank from above. The two servos and the pump are powered by electrical circuits behind the front panel. All electrical signals are routed through a cable to a nearby PC which is responsible for actuating the system.
Based on this older module a new prototype was to be designed and manufactured.
The newer prototype module would have the same actuator and sensor types as the old design, except now each actuator and sensor would be moved onto a sepa- rate wirelessly controlled device (node). Control of this new wireless system would be achieved by sending commands through a "Gateway" device which will be con- nected to a PC. This Gateway device would receive its commands automatically from a system modelling program called Simulink. These commands would be gen- erated by a custom made Simulink interface which would also need to be created during this project. Simulink is an extension to the computational program Matlab, and is a commonly used toolbox within the field of automatic control. It is a block based modelling program which makes it possible to easily implement automatic control algorithms as simple block diagrams.
For this thesis project the goal was always to keep the cost relatively low for the
entire prototype system. This master thesis project had a total budget of 20000 SEK
which was intended to included the cost of all necessary electronics and any external
parts such as pumps, valves and tubing. This budget became the main driving force
behind why the system needed to be custom built from scratch. There are complete
wireless sensor and actuator solutions out on the market, however they are mainly
aimed towards industrial customers so they are quite cost prohibitive. This means
4 Chapter 1. Introduction
that in order to stay within the allotted budget, custom wireless sensor and actuators needed to be designed rather than purchased in this project.
1.3 Project Goals
A new prototype system was to be designed and manufactured. This new prototype system would be fully modular and wireless by design, where each actuator and sensor exists on its own wirelessly controllable device (node). These wireless nodes would need to communicate wirelessly through a Gateway node which would be connected to the PC. On this PC a custom made Simulink interface would be run- ning, said interface would have to be created from scratch to fit the new prototype system. This interface would enable autonomous control of the wireless node based system from within the Matlab software environment. The nodes which would need to be designed were then as follows:
• An electrical pump control node
• A multi rotational valve control node
• A temperature sensor node
• A water tank level sensor node
• A Gateway node
The goal was to create electrical designs for each one of these nodes and then man- ufacture them. These nodes would then need to be programmed in such a way that they can interact with the custom made Simulink interface on the PC. The system would need to be constructed in such a way that it is entirely modular and wire- lessly controllable, where it needs to be capable of operating in a real-time use case.
In addition to the electrical and software design components, there was a mechanical design component as well. Firstly the new prototype system needed to work with multi-rotational valves rather than traditional single turn ones, which would require a different solution than that of the older tank setup. Secondly the new water tank had to be dimensioned in such a way to obtain a physical time constant of T = 20 seconds or less. Lastly a selection of new electrical water pumps also had to be done. These pumps should be centrifugal pumps and not membrane pumps, where the sizing of the pumps should be based on the new tank dimensioning.
The central part of the entire prototype system design process was to keep costs rel- atively low. A preliminary budget had been allotted to be 20000 SEK for the new prototype module, this budget needed to be considered when making design deci- sions. A complete problem analysis which covers the various system requirements is found in Ch. 2.
1.4 Thesis Layout
Some quick information about the layout of this thesis. A problem analysis is done in
chapter 2, here various project requirements are stated and analysed for the new pro-
totype system. The problem solving methodology used in this project is detailed in
chapter 3. The basic working principles of the finalized system are explained briefly
1.5. Project Delimitations 5
in chapter 4. This chapter mostly serves as a quick reference guide over how the system is constructed, and how its software operates. Reading this chapter should give the reader a good idea about how the system functions as a whole.
A more detailed explanation of the software solution is given in Ch. 5. The electrical schematics/boards and motivations behind component selections are detailed in Ch.
7. Lastly the mechanical aspects of the system are covered in chapter 6. The final chapter 8 contains conclusions and discussions about the end result of this project, any recommendations for future work are also detailed here.
1.5 Project Delimitations
The mechanical design aspect of the prototype module will only concern a theoreti- cal study, no actual construction of a new tank system has been done in this project.
This was mainly due to time limitations, and also due to the fact that the mechani- cal design aspect was not the main focus of the thesis project as a whole. The main area of focus was the design and manufacturing of the wireless sensor and actuator nodes, which has been completed in full. These nodes have been tested on an older tank setup to ensure that they function as intended. In the design of the electrical system I have mainly made use of digital integrated circuit (IC) solutions, no ana- logue electronic solution for implementation of filters or similar has been done in this project.
For the software system I have only designed it to be used directly with the Simulink
interface. If it needs to be used with some other program, heavy modifications to
the software may need to be done. This is mainly due to the fact that the command
generation and data conversion is done by the Simulink scripts and is not entirely
done on the Gateway node.
7
Chapter 2
Problem Analysis
The task at hand was to redesign the old tank module to enable fully wireless opera- tion. For each actuator and sensor in the old system a separate wirelessly controlled node was to be constructed for the new system. This newer wireless system has a few requirements on how it must perform in a real-time use case. The mechanical design of the new setup also needed to meet a set of requirements. All of the system requirements and their impacts on the system design are analysed in the following sections.
2.1 Mechanical Design
The three important aspects about the mechanical design of the system is the dimen- sioning of the tank, selection of the pump and the selection of outflow valve. These three topics are covered here.
2.1.1 Tank Dimensioning
For this project the water tank is assumed to be cylindrical in shape with a circular opening at the bottom, see fig. 2.1. The dimensioning of the tank will be done in such a way that a certain system time constant could be achieved. This time constant is related to the rate at which water can flow in and out of the tank. It is a value which indicates how "fast" or "sluggish" the system is. This is an important property to consider when designing automatic control schemes, since the time constant will be the main limiting factor that decides how quickly a system can be actuated. The system time constant is a value which changes based on the dimensioning of the tank. To derive an equation for the single tank process time constant you first start with the mass balance equation,
In − Out = Accumulation, (2.1)
In terms of water flow-rates this turns into,
Q
in− Q
out= dV /dt. (2.2)
Simply put, the net difference in flow rates directly equates to an increase in volume
over time. Assuming a cylindrical shaped tank this is further expressed as,
8 Chapter 2. Problem Analysis
FIGURE2.1: Simple mathematical model for the single water tank.
Q
in− Q
out= A dh/dt. (2.3)
The area A is the cylinder area and dh/dt is the rate of change of the water tank level.
The water height level h will be a function of time. The flow rate going out of the bottom of the tank Q
outwill be given by,
Q
out= a
p2gh. (2.4)
A reference for eq. 2.4 will be given in the pump selection section. Eq. 2.4 assumes that there is a circular opening at the bottom of the tank with area a. The gravita- tional acceleration constant is given by g. The water height level is given by h. In this case it is also assumed that there are no frictional losses at the outlet. Putting eq.
2.4 into equation 2.3 we get,
Q
in− a
p2gh = A dh
dt . (2.5)
Which can be rewritten as, dh dt + a
A
r2g
h h = Q
inA . (2.6)
This equation has a familiar form, namely that of a first order characteristic equa- tion[11] (p. 100). The characteristic equation for a first order system is given by,
dy(t)
dt + ay(t) = bu(t). (2.7)
As can be seen eq. 2.6 clearly has the same form as eq. 2.7, where y(t) = h and
u(t) = Q
in. From the solution to this characteristic equation, the time constant of the
system can be found to be 1/a [11] (page 101). This means that the time constant T
of the water tank system is described by,
2.1. Mechanical Design 9
T = A a
s
h
2g . (2.8)
Here the nominal operating liquid level is given by h. The gravitational acceleration constant is g. The tank cross sectional area is A and the bottom opening area is given by a. This formula assumes an ideal case where there are no frictional losses at the outlet, which would lower the outflow rate and in turn increase the time constant value. For this tank system it was decided that the nominal operating point of the liquid level should be 10 cm, with an intended operational range from 0 to 20 cm.
This means the parameters to fine tune would be the areas A and a, in order to achieve a desired time constant. The value for the area A will be a fixed value which is decided upon in this design process. Whereas the value of a could change based on which outflow valve is being used.
If the time constant of a system is too large then system becomes slow to react to changes, and therefore becomes slow to work with. The researchers had this is- sue with the older quadruple tank setup. In this setup the time constant of each individual tank was about T = 30 seconds, this means the individual tanks all by themselves are already on the slower side. However the real issues surface when combining these slower physical processes into a larger system. For their quadruple tank setup they ended up having a system time constant of about T = 300 sec- onds, depending on the opening degree of the valves. This lead to major headaches whenever they wanted to change the liquid levels in the quadruple tank system, the system could take several minutes to settle in at a new desired level. Which leads to a system that is quite cumbersome to actually work with when tuning automatic control schemes for the quadruple tank process. To avoid these issues for the future improved quadruple tank system, they wanted an individual single tank module to have a time constant of at most T = 20 seconds, preferably lower. This should lead to a significantly faster system when scaled to the quadruple tank variant.
2.1.2 Outflow Valve Selection
With regards to selecting new valves the researchers wanted to utilize multi rota- tional valves instead of traditional single turn ones. Multi rotational valves give a higher degree of accuracy when adjusting the flow rate of liquid going out of the tank. The new valve should ideally be chosen so that its maximal opening degree is slightly larger than the bottom opening area a of the tank, and not much larger than that. if this is not the case and the valve opening area is smaller than the one of the tank, the time constant of the tank will be negatively impacted. Recall that the time constant T increases as the area a decreases as according to Eq. 2.8. If the valve maximal opening area happens to be larger than the one of the tank then no effects on the outflow will be detectable as the valve opens up past this point.
This new multi rotational valve would require the use of something other than a
simple servo motor in order to open and close the valve. A decent candidate would
be a stepper motor, however these require more advanced circuitry to control, which
becomes relevant when designing the electronics. The dimensions of the valve and
any mounting solution will also have to be taken into consideration. If the water cut-
off point within the valve for instance lies 3 cm from either end point of the valve,
then this offset would directly impact the nominal water height level within the tank
10 Chapter 2. Problem Analysis
itself. Therefore the valve selection will also have an impact on the other mechanical design aspects of this system.
2.1.3 Pump Selection
When searching for a new pump it was important that it would be a centrifugal pump, and not an membrane pump. The researchers had found previously that membrane pumps produce too much vibrational noise when operating at higher speeds. Vibrational noise adds uncertainties to the water level readings and is in general an undesirable property for the system. A centrifugal pump operates in a much smoother fashion and therefore produces less vibrational noise. For a process control system such as this one, it is also important that the pump has "good" control properties. In general this refers to the idea that the pumps behaviour has to be fully predictable. When a given voltage is supplied a corresponding flow rate of water should be achieved. It is critical that this behaviour is consistent between different runs of the system as well. Ideally the pump should also have a wide range of operation where the flow rate can be fine tuned for precise system actuation.
The exact sizing of the pump ends up being entirely dependent on the dimensioning of the water tank and the outflow valve selection. As the operating point h and bottom operating area a change, so does the required pump flow rate in order to stabilize a liquid level. The flow rate of water going out of the tank is given by,
Q = a ·
p2gh · C
c· C
v. (2.9)
This equation was found at the link[24], Here a, g and h are as before. The flowrate is given by Q and has the unit m
3/s. C
cis the contraction coefficient for the opening aperture. C
vis the velocity coefficient which for water is about 0.97. C
cis essentially a frictional loss coefficient that depends on the shape of the outlet edges, for a sharp edge it is about 0.6 and for a very well rounded one about 0.97. If frictional losses are ignored we can simplify the equation to get the "worst case" value for the flow rate as,
Q = a ·
p2gh. (2.10)
The goal was to be able to maintain and operate around a nominal level of 10 cm.
To achieve this an adequately high flow rate pump would need to be chosen for the new system. It is probably a better idea to over dimension the pump to meet this "worst case" requirement when maintaining a nominal level of 10 cm. Since at the end of the day the pump needs to be able to actually move the liquid level up to 20 cm in shorter bursts, so having more available pumping power is a necessity.
Recall that the nominal liquid level will change based on the outflow valve selection,
therefore these liquid levels are not absolute values. This would further motivate
over dimensioning of the pumps to be a better choice.
2.2. Software Solution 11
2.2 Software Solution
As mentioned earlier the system was going to be of a modular design, where the separate nodes would communicate wirelessly with one another. In a single tank module there would only be a total node count of 5. That is the Gateway node, the valve control node, the pump control node, the temperature measurement node and lastly the water level measurement node. However since the end goal is to use four (4) of these modules to construct the quadruple tank setup, the wireless design must account for this future expansion. Since in the quadruple setup the total node count will likely be in the range of 15 to 20. This wireless system would also have to be remotely controllable from a PC running a custom made Simulink interface.
Therefore the Simulink interface also has to account for this future system scaling.
2.2.1 Wireless Communication Protocol Selection
The amount of data that would need to be transferred between nodes was going to be quite small. The only data that would need to be transmitted would be sensor readings or shorter commands. This data amount could be estimated to be in the range of 10 to 200 bytes per transmission. Based on the desired physical system time constant of around T = 20 seconds, a desired sample time can be estimated to be t
s=
10T= 2.0 seconds or faster. Selecting the sample time in this manner is based on best practices for control loop design, for further details refer to [4]. Sample time selection is a relevant topic because ultimately this pump system is supposed to operate with an external control loop, which has been implemented via Simulink.
Combining the desired sample time t
s= 2.0 with the data transmission size, an estimated data transfer rate turns out to be in the range of 5 b/s to 100 b/s. This is the bare minimum data transfer rate, faster sample time would require higher data transfer rate. This system is supposed to operate wirelessly in real-time, therefore latency of the data transmission becomes an important property to consider as well.
There were no strict requirements on minimum or maximum signal latency given for this project. The most important software system property to aim for was that it has to be possible to sample and then actuate based on the sampled data, and this must be done within the sample time window of t
s= 2.0 seconds. Based on these requirements for wireless data transfer, some appropriate protocol would need to be chosen.
2.2.2 Flexibility Of Software Solution
The end goal for this system is to be able to add and remove nodes as needed. If lets
say the researcher wanted to add another valve and valve controller at the bottom of
the tank, this should be possible to accommodate for in the software. Likewise if a
sensor is removed because it was not needed, it should be easily removable without
breaking the system functionality. The whole system should not need to be rebuilt
from the ground up just because a node was added or removed. Adding and remov-
ing nodes should require nothing more than simply updating some settings within
the Simulink interface, and supplying power to the new hardware. This required
system flexibility needs to be taken into consideration throughout the software de-
sign process.
12 Chapter 2. Problem Analysis
2.3 Electronic Hardware Design
For the electrical design portion of this build there are a few requirements to con- sider, mainly about power delivery and sensor specification.
2.3.1 Sensor Setup
The two system properties that needed to be measured was the water temperature and the water level in the tank. There are a number of ways of measuring the water level. One of the easiest ways to do it is by first measuring the gauge water pressure at the bottom of the tank, then converting the pressure reading into a water column height. The water level h is derived from the fluid column static pressure equation where the gauge pressure is given by,
P = ρgh. (2.11)
This equation was sourced from [3]. Here the density of the water is known as ρ, and the gravitational acceleration constant is g. The operating point where this pressure would need to be measured would be in the range of about 0 Pa to 2000 Pa. This pressure range has been calculated from knowing that the expected water column height will be within the operational range of 0 to 20 cm. However due to flow mechanical effects near the bottom outlet such as fluid vortexes, pressure measurements will be distorted at lower water column heights. Therefore a more realistic measurable water column height will be in the range of approximately 2 to 20 cm.
Measuring of the water temperature was also to be done in this project. The tem- perature measurements were expected to be in a range from about 5 to 60 degrees centigrade. Preferably the sensor should be in the form of a pre-built waterproof temperature probe. This would make sure that relocation of the sensor would be possible, and that it also would be possible to directly measure the temperature in the water.
The only given requirement for sensor accuracy was that it needs to be better than 8-bits of resolution, anything above 8-bit was deemed acceptable. This requirement applied to both the temperature measurements as well as for the water height level reading.
2.3.2 Power Delivery Requirements
The most power hungry node in the entire electrical system will be the water pump
driver node. Any medium sized pump that could be required for this system can
have an estimated power draw within the range of 20 to 60 Watts. These numbers
have been gathered by browsing the available pump selections on-line for different
applicable flow-rates. However these power value requirements depend heavily on
what dimensions the water tank has, since that directly affects what flow rate will
be expected from the pump. Bigger pumps draw more power, and this has to be
calculated for when designing the electronics of the pump driver node. It would be
2.3. Electronic Hardware Design 13
a good idea if the power supply circuitry can handle a wide range of pump sizes, in case the pump needs to be replaced for a different model at a later stage.
All other components still need to be supplied with power in some practical manner.
It may not be as simple of a problem to solve as simply adding a DC power jack to
each separate node. This would make for a very cumbersome system, because when
the node count increases so would also the amount of AC-DC power supplies that
need to be connected to wall sockets. Therefore some scalable solution needs to be
implemented to make the system easier to work with.
15
Chapter 3
Method
This pump system project consisted of a number of separate tasks. There was a need to design new hardware for every separate node, and then also program it to function properly. This wireless pump system had to have some sort of interface to control it, this was constructed within Simulink. The newer tank setup would also need to be mechanically designed to fulfil the newer system requirements as specified in ch. 2. Which tools have been used and what the design process was for each task is detailed in this chapter.
3.1 Electrical System Design Process
The design process for the electrical system first involved getting a general idea of what components were required to make a functional system. Sourcing of the electrical components was done for everything but the most basic passive compo- nents, such as common resistors and capacitors. All of the electrical components were sourced from either Elfa ( www.elfa.se ), Farnell ( www.se.farnell.com ) or Digikey (www.digikey.se).
These components were then drawn up in the CAD tool Autodesk EAGLE[7] and they were put into schematics. A schematic design was figured out for each board by researching the component data sheets, and making connections between com- ponents as required to make a functional design. This method of using pre built IC’s instead of designing custom devices is mentioned on p. 1192[1].
PCB layouts then had to be drawn up for each schematic in the program EAGLE,
so that a physical implementation of these schematics could be realized. The PCB’s
were later put on panels which were then manufactured by the Swedish company
Cogra Pro AB (www.cogra.se), which at the time of this project was the main PCB
supplier for Lulea University of Technology. Every PCB design in this project uses a
two layer board layout, where components are placed on one side only. Soldering of
components onto the unpopulated PCB’s was mostly done in the microelectronics
lab at LTU. The EAGLE software was running a premium license which was ob-
tained by supplying a student email address, and the program version used in this
project was 8.3.2.
16 Chapter 3. Method
FIGURE3.1: Nucleo-F303K8 Development platform by STMicroelec- tronics. It has the same form factor as the well known Arduino nano
platform.
3.2 Software Design Process
3.2.1 Micro-controller Solution
For this project I decided to work with development platforms instead of mounting a micro-controller directly onto each node PCB. Each node device is instead a so called
"shield" board that attaches ontop of a prebuilt development platform. By doing it this way you simplify the electrical designs considerably, and in addition you also have the option of changing micro-controllers in the future. The development plat- form of choice was the NUCLEO-F303K8 by STMicroelectronics and it is pictured in Fig. 3.1. Product page for the nucleo platform is found at[17]. These development boards have a small form factor which helps with making the system node designs smaller and more compact. The Nucleo platform is based on the ARM Cortex-M4 STM32F303K8 micro-controller[20], and it comes with USB flashing and debugging capabilities. The deciding factor behind choosing this platform over other ones was that I had previous experience working with similar micro-controllers from STMi- croelectronics, and it had the required hardware feature set for this project.
Some of the important features of the STM32F303K8 micro-controller include two Universal Asynchronous Receiver/Transmitter (UART) interfaces, Pulse Width Mod- ulation (PWM) signal generation capability and the usual General-purpose Input/Out- put (GPIO) port functionalities. In this project the STM32F303K8 micro-controllers have all been configured to operate on a 64 MHz system clock, where internal timers for serial communication interfaces and the like have all been based on this clock.
3.2.2 System Base Code Development
Program flashing of the micro-controllers has been done through Atollic Truestudio and the source code was written in the C programming language. I used the free ver- sion of Atollic and it had a version number of 8.0.0, link to the software page at[2].
The STM32F303K8 micro-controllers can be configured through a tool that STMicro-
electronics provides called CubeMX[19], example program view shown in Fig. 3.2.
3.2. Software Design Process 17
FIGURE3.2: Program view of CubeMX showing the pin setup tab.
CubeMX is used to auto generate initialization code for the micro- controllers.
In this tool you can set pin-names, clock frequencies, communication protocols and more. When this is all done you can then auto-generate the C code that is needed to initialize the micro-controllers with those settings. In this project I mainly used CubeMX version 4.22.1.
When programming the micro-controllers you can make use of their hardware ab- straction layer (HAL) driver, refer to their HAL driver user manual for specific infor- mation[21]. These HAL drivers are auto generated by CubeMX in the same process as before. A hardware abstraction layer makes it so you as the programmer don’t need to edit the lower level registries, instead you work on a higher level. This speeds up the development process considerably. So throughout this master thesis project I have decided to make use of the code generation tool and the HAL drivers for my micro-controller software solution.
3.2.3 Simulink Interface
As part of the thesis work some sort of interface had to be built for Simulink (prod- uct page at[16]). Simulink is an extension program to the computational program Matlab (product page at[12]). Matlab and Simulink are used extensively within the automatic control community when implementing automatic control schemes. Since Simulink is a block based modelling software where users interconnect functional blocks with each other to form complex logical structures, it made sense that my Simulink interface should come in the form of one of such functional blocks.
The interface I have built for Simulink is a multiple input and output block, which
relies on a series of background scripts that execute within the Matlab enviroment
to be able to interact with the micro-controller system. The construction of this
Simulink interface mostly consisted of writing these Matlab scripts and function files
that are used to output command sequences to the micro-controller system. In order
to enable real time operation I decided to make use of the real time synchronization
18 Chapter 3. Method
block[15]. This block forces the entire Simulink diagram to operate at a fixed rate which is directly related to the passage of real time. The Simulink interface and asso- ciated scripts have been created in the Matlab/Simulink version R2017b. Academic licenses for Matlab and Simulink were supplied by Luleå Tekniska Universitet.
3.3 Mechanical Design Process
The initial idea at the start of the project was to build a new setup for a single tank module. This would require the sourcing of new water tanks, tubing, valves and a new pump. For the new tank module one of the goals was to construct a system which had a lower time constant than the older one. This leads to a different require- ment for the flow rate of the pump, which means a new pump has to be found, the older one was no longer sufficient. It was later on during the project that it became clear that sourcing of a new pump was proving to be more difficult than first antici- pated. What made it difficult was that the new pump had to be both centrifugal and self priming, these are two properties that combined make for a very niche product.
A decision was made by my supervisor that for building the single tank module prototype, it would be better to simply modify an older existing setup. This setup had a pump of an older model (made in the 1980’s), which was both centrifugal and self priming and would work fine for this prototyping purpose.
As a consequence when re using the older water tank setup, the older water tanks
would also be used. This ended up changing the scope of the master thesis project
somewhat. The initial plan was to dimension a new tank setup completely and
then built it from scratch, however due to time limitations it was deemed sufficient
to modify an older setup for use in prototyping. Therefore the mechanical design
component of this project is mostly a theoretical study that could be used in the later
design stages, after this thesis project has been concluded.
19
Chapter 4
System Overview
The wireless pump system consists of a number of nodes which are all communi- cating wirelessly over Xbee radio modules. Interaction with this system is done via the custom Simulink interface on a computer. All of the nodes are driven by STM32F303K8 micro-controllers that are mounted onto the Nucleo development platforms.
Reprogramming of the micro-controllers is done over a micro USB cable. Important:
the nodes must receive power externally before you plug in the USB cable. Other- wise there is a risk of damaging circuitry on the development boards. This concerns the Nucleo platforms which have been modified to operate of external power and not over USB. These modifications are explained in Ch. 5.
4.1 Node overview
The separate nodes that exist in this system are as follows:
• The Electrical pump control node
• The Multi rotational Valve control node
• The Temperature sensor node
• The Water tank level sensor node
• The Gateway node
They will be covered very briefly here, more details are found in both the electrical design chapter and the software design chapter. A picture displaying all of the nodes side by side is found in Fig. 4.1.
4.1.1 Gateway Node
This is the node which is connected over a USB cable to the PC running the Simulink interface. This node is the coordinator device in the Xbee network, all other nodes are end devices. This node takes system API commands and sends the relevant commands to all other end nodes. The gateway node is therefore the central com- munications device in the system.
The Xbee radio modules of choice for this node and all others is labeled "XB24CAPIS-
001". This is a surface mounted module with an embedded antenna. It is part of the
20 Chapter 4. System Overview
FIGURE4.1: Picture showing all of the node types side by side. From left to right, 1) Temperature measurement node, 2) Gateway node, 3) Water level measurement node, 4) Valve control node and 5) Electrical
pump controller node.
Xbee S2C product line and is manufactured by Digi International. For more details on how the Xbee network has been configured refer to Ch. 5.
4.1.2 Electrical Pump Control Node
This node is responsible for adjusting the pumping speed of the water pump. It has an internal speed setting which ranges from 0 to 200. When this setting is ad- justed the PWM control signals duty cycle that is transmitted to the pump driver integrated-circuit (IC) will be adjusted accordingly. A speed setting of 0 gives a PWM duty cycle of 0 % and a setting of 200 is 100 % duty cycle. The electrical cir- cuitry on this node is capable of driving any 12 V pump up to a power rating of 60 Watts, as long as the connected DC power supply can handle the load. As a safety precaution the pump driver node has an automatic shut-down feature. If no actua- tion commands are received in a 3 second time window, the pump will automatically be stopped completely.
4.1.3 Valve Control Node
A stepper motor based solution is currently being used to turn the multi rotational
valve. The stepper motor is being rotated in full steps, no micro stepping techniques
are being used. This node is capable of driving 2-phase stepper motors that require
up to 1.5 A of current per winding. The stepper motor operational voltage is 5V. The
command input given to this node is the desired amount of steps that the stepper
motor should rotate, and in which direction it should rotate to. The input value is
an integer which can be either positive or negative. There is an internal tracker for
the total offset of the stepper motor. There are configurable maximal positive and
maximal negative values that the stepper motor can ever rotate to. If the internal
tracker hits either limit the stepper motor will be unable to rotate further in that
direction. There is currently no solution in place of externally tracking the position
of the motor shaft.
4.1. Node overview 21
4.1.4 Water Level Measurement Node
The water level in the tanks are being measured by gauge pressure sensors. These sensors measure the pressure at the bottom of the tanks as an analog voltage read- ing. This voltage is sampled by the micro-controller on this node and is sent over Xbee radio to the Simulink interface. In the Simulink interface this reading is then converted to a water level reading.
The micro-controller samples the voltage with a 12-bit resolution and the value will be in the range of 0 V to 3.3 V. The pressure sensor itself will output a voltage in the range of 0.6 V to 3.0 V (refer to the sensor datasheet[13]). Where a measured 0 kPa gives 0.6 V output with a voltage scaling of 0.6 V/kPa up to a maximum of 3.92 kPa.
When converted to units mm H
2O the sensor is capable of measuring a range of 0 mm to 400 mm, where mm refers to the height of the water column.
4.1.5 Temperature Measurement Node
A Temperature measurement is taken by the DS18B20 waterproof temperature probe.
The measured value is converted to degrees Celsius on the temperature measure- ment node. This value is then sent to the Simulink interface over Xbee radio. The resolution on the temperature measurement is configurable in the system base code but it can not currently be changed during system runtime. The resolution can be set to be between 9 to 12-bits. At the time of this writing it has been set to be 12-bits.
4.1.6 Power Supply Scheme
The gateway node draws all of its power from the USB port on the PC, so it has no external power requirements. The temperature measurement node, water level measurement node and the valve control node all require an external 5 V DC supply.
Currently this is solved by taking a common 5 V DC power supply and connecting it to the custom power splitter board. This power splitter board has a separate fuse for each individual output. Regular cables are drawn from the splitter board to the aforementioned nodes. As a safety precaution I have implemented a reverse polarity protection circuit on these nodes, so there is no risk of critically damaging circuitry in case the wire connections are reversed.
Since the pump is the main power draw of the entire system I decided that a separate
DC supply be used for the pump control node. This node takes regular 12 V DC
power supply plug as input. The pump will be supplied power by the pump control
node. The current rating on the 12 V power supply must be adequate to power the
intended pump.
22 Chapter 4. System Overview
4.2 Simulink Interface
The Simulink interface consists of a functional block that takes multiple inputs and gives multiple outputs. This interface is constructed by a series of scripts which are run in the background during normal operation. These scripts generate the appro- priate command sequences needed to actuate the system, and then sends them over UART serial connection to the gateway node. The input values to the functional block are encoded into these command sequences. Any reply messages generated by an end device will be received by Simulink and then be decoded. The outputs of the Simulink block are updated with the new decoded values.
The foundation that makes this Simulink interface work as it should is the real time
synchronization block. The execution of the Simulink diagram is being done in real-
time. The system sample rates are configurable in the initialization script. It is also
there where the physical end nodes are configured to work with Simulink. For more
information refer to Ch. 5.
23
Chapter 5
Software Design
5.1 Software Overview
5.1.1 Software Requirements
Before going into details about how the software system has been constructed the system requirements need to be restated. Firstly this system would be operating in real-time which would make any execution delays within the system a highly undesirable property. This is important because in an automatic control problem the speed of actuation of the entire system should be faster than
101of the systems physical time constant, to be able to achieve adequate controller performance (as mentioned previously in Ch. 2). The ballpark number for the system sample time was a system actuation time of 2000 milliseconds or faster, this value assumes a water tank physical time constant of about T = 20 seconds, which was the target value for the mechanical design process.
Secondly the system had to be flexible in its design. The researchers should be able to add new nodes to the system, simply by connecting power cables to the new hardware and then changing some settings in the Simulink interface. This required system flexibility becomes important because it could mean that multiple copies of the same node type, say the water height level sensor node, could exist in the system at the same time. The system should have no fundamental limitation which would prevent it from using multiples of the same node design, as to be able to support a wide range of system configurations. In conclusion, the system software solution needs to be both flexible in design and contain as few unnecessary delays as possible in order to fulfil the system requirements.
5.1.2 Wireless Protocol Selection
The fully modular pump system needed to have a means of communicating wire-
lessly between nodes. This wireless solution needed to be able to support a data
transfer rate of about 5 b/s to 100 b/s, as previously discussed in Ch. 2. The system
will operate in real-time, therefore latency of data transfer should be kept as low as
possible. Based on these requirements the most viable communication protocol was
deemed to be Xbee, which is a proprietary version of the ZigBee protocol made by
Digi International and is based on the IEEE 802.15.4 standard. Xbee networks are an
ideal wireless solution for when networks need to be large in node count, but the
24 Chapter 5. Software Design
data transfer rate can be kept relatively low within the network. The Xbee proto- col therefore ended up being a suitable choice for this wireless pump system, where there are multiple nodes but the internal data transfer rates are low. In this project I opted to go with the Xbee S2C modules[27] made by Digi International Inc, these devices implement the Xbee protocol in an easy to use surface mounted package.
5.1.3 Software Solution Components
The software solution for the entire pump system ended up consisting of two major components. First major component of the pump system is the system base code it- self. This base code is a collection of device drivers which are executing on the differ- ent micro-controllers in the wireless system. These drivers enable the STM32F303K8 micro-controllers on every node to control the external IC’s, and to communicate wirelessly over the Digi Xbee S2C radios. This system base code has an API so that it can easily be controlled from an external source, which in this case will be the Simulink interface.
Second major component of the pump system is the Simulink interface which oper- ates inside the computational program Matlab. Simulink is a commonly used system modelling program within the automatic control community. In Simulink the user implements various logical control schemes by working with inputs and outputs going in and out of functional blocks in a block diagram. The Simulink interface for the pump system behaves exactly as one of these functional blocks. It has in- puts and outputs which directly correspond to the various inputs and outputs that govern the physical system. This functional block can then be connected with other blocks within the Simulink environment in order to implement automatic control schemes.
These two major components will be covered in this chapter in separate sections.
The inner workings of the system base code will be covered first. Here the details
about how the micro-controller system has been programmed will be given. Follow-
ing this, the details about how the Simulink interface has been constructed will be
given. At the end of each major component section any relevant system limitations
will also be detailed. These limitations will be put into context as to make it clear in
what way they could impact future system expansion.
5.2. System Base Code 25
5.2 System Base Code
5.2.1 System Base Code Architecture
A diagram depicting an overview of the software within the current system is shown in Fig. 5.1. The basic concept behind the system is that it consists of multiple end nodes which all receive commands from a central node, the Gateway node. This Gateway node in turn receives its commands from an external PC which is running an instance of the Simulink interface. This example system consists of one Gateway node and two end nodes that communicate wirelessly by using the Xbee radio mod- ules. All commands sent from the PC to the Gateway are in the form of system API commands. The image only depicts two end nodes being utilized but this is only for simplicity’s sake. The system design has been tested to be fully operational with 5 end nodes and is expected to be able to handle many more (10+).
The data communication interfaces, namely the serial UART and the Xbee network, will be covered first in their own subsections in this chapter. These are the interfaces which allow the STM32F303K8 micro-controllers to communicate with each other and to the Simulink interface. The system API which makes it possible to control the pump system from a PC will also be introduced in its own subsection following this. The functionality of the different nodes will be detailed in its own subsection after the system API introduction, here I will go over how the nodes are actuated and what they do. In the last part of this section I will list which system base code limitations exist, and how they might affect future system expansion.
FIGURE5.1: Overview of system components and interfaces. Arrows represent data transmission between nodes, the protocol used is listed
next to the arrows.
5.2.2 UART Interfaces
The UART serial interfaces in this system all use an interrupt driven solution. Every time a character is received over the serial wires an interrupt is fired of in the code.
This received character is then stored in a circular buffer for later processing. The
26 Chapter 5. Software Design
circular buffer has a fixed size and will wrap back onto itself when full, therefore there is a fixed amount of data that can be received before data loss will occur.
Processing of this circular buffer is done after a set amount of time, as time of writing this it is configured to be after a window of 1 millisecond has passed without any further UART reception. The circular buffer is then split into the separate commands that have been received as denoted by special delimiter characters. These separate commands are processed one by one as quickly as possible. Exactly what each com- mand does and what response it generates is entirely node specific. This command reception and command execution algorithm is applied to every unique UART in- terface. So for the end nodes there is one of these algorithms receiving commands from the Xbee. On the Gateway node there are two UART interfaces, one to the PC and one to the Xbee module, so on this node there are two instances of this algorithm running. In order to properly send and receive commands to/from the Xbee module the custom Xbee driver has been applied in the base code for every node.
All of the UART interfaces throughout the system are running with an 8-bit word length without any parity bits and with one stop bit. The UART interface from gate- way to PC is running at a baud rate of 460800 b/s. The UART interfaces between micro-controllers and Xbee modules is running at baud rates of 230400 b/s. These were the highest baud rates achievable without doing any major modifications to the code base.
5.2.3 Xbee Wireless Network
Network ConfigurationIn this wireless system the Xbee modules have been configured to operate with a master/slave network structure. The master is commonly referred to as the coordi- nator of the network and the slaves are known as the end devices. The Xbee modules are capable of transmitting data in the form of either unicasts or broadcasts. A uni- cast is a directed message that is sent from one device to another device. A broadcast is a message which is transmitted from one device to every other device within the same network.
For this wireless system setup the Xbee module on the Gateway node is the network coordinator, and the Xbee modules on the end nodes are the end devices. All of these modules exist within the same Personal Area Network (PAN), and can conversely only communicate with other modules within this network. Each module has a con- figurable PAN ID, this is a parameter which designates which PAN it belongs to.
The PAN ID setting on all devices in the same network must match. Another impor-
tant parameter is the channel selection, this sets the radio frequency channel which
the module operates on. To enable targeted data transmission(unicast) operation,
each end device has been configured to associate with any coordinator that matches
the end devices PAN ID and channel selection. Likewise the coordinator has been
configured to allow association with end devices that have matching PAN ID’s and
channel selections. This association setup makes the modules bond with each other
so that unicasts can be used, as well as non targeted transmissions (broadcasts). All
modules have been configured to operate in so called "API" mode, and they all com-
municate with the Nucleo platforms over a UART serial interface. The different Xbee
parameters are configured by sending "AT" commands to the targeted device, which
5.2. System Base Code 27
Xbee Parameter Coordinator End Device Description.
ID 1234 1234 PAN ID
CH (C) (C) Channel selection
A1 0 1 End device assoc.
A2 1 0 Coordinator assoc.
AP 1 1 API mode enable
CE 1 0 Coordinator enable
BD 8 8 UART Baud rate
TABLE5.1: Xbee parameter settings, all values are sent as hexadeci- mal numbers. The channel selection in parantheses is a default value and can not be changed on S2C modules. The baud rate is specified as a setting of pre-defined values, in this case 0x08 refers to a baud
rate of 230400 b/s, see usermanual[28] for more details.
can be done through Matlab scripts which I have made. These scripts make use of a system API function to send AT commands either locally (to Gateway module) or remotely (to end devices).
All of the Xbee modules have non-volatile memory which you can save settings to. The nodes I made during this project have been properly configured and their settings have been stored to non-volatile memory. When the nodes power on from a hardware reset they will automatically load and apply all of the saved settings, therefore configuration of the Xbee modules only needs to be done once. A table containing the important parameters and what setting they currently have on the coordinator node and the end nodes is given in tab. 5.1.
Xbee API Operating Mode Driver
The Xbee modules are highly configurable and are in turn quite complex to work with. One of the simpler ways of using Xbee’s is to configure each device to have a pre-programmed destination address. Then when data is sent to the module through a UART serial connection, it will be automatically sent to that target address. This mode of operation is referred to as "transparent operation mode" in Digi’s docu- mentation. However this operating mode poses a few problems when applied to the wireless pump system design. In order to be able to send data to a specific end node, the pre-programmed destination address would have to be changed before each message transmission. This process is quite time consuming and is not a stable solution for real-time operation due to the increased system delay. Thankfully there is another alternative, and that is to use Digi’s "API operating mode".
The basic idea of Digi’s API mode revolves around sending packets also known as
"API Frames" to the Xbee modules. These frames contain instructions for the module
to perform, such as sending a data payload to a specific destination address. For this
project I have configured all Xbee modules to utilize API operation mode. However
with the increased functionality of this mode, this has also lead to increased com-
plexity when interfacing with the modules. During this master thesis project I have
essentially started a side project that was about writing an Xbee driver to be able to
operate in Digi’s API mode, this driver was written in the C language and can be
used on any STM32 micro-controller. This was a necessity since there were no work-
ing drivers for these micro-controllers to be found anywhere when this side project
28 Chapter 5. Software Design
was started. Currently this custom Xbee driver makes it possible to reconfigure local and/or remote Xbee modules and to send and receive data payloads to/from other Xbee modules. I will not however cover it’s structure and functionality it in this report since it does not directly relate to this master thesis project.
5.2.4 System API Introduction
Interaction with the pump system is done entirely by using the system API com- mands. All API commands are sent as character sequences over the UART con- nection from the PC to the Gateway node. The received commands are decoded and executed in a first in first out order (FIFO). The Gateway node is used to transmit and receive packages wirelessly to/from other end nodes. When a package is received on the Gateway node it will always directly forward it through the connected USB UART connection to the PC. The Gateway node can also be used to remotely recon- figure Xbee modules on the end nodes, which is a highly practical way of changing various parameters on remote Xbee modules during system configuration.
Controlling an end node is done by transmitting an appropriate character sequence to the target node. Every unique end node has a specific list of commands that per- forms an action on that node. These commands are things such as sampling of a value from a sensor or increasing the speed of a pump. These end node commands are given in the form of a character sequence in an Xbee message, which was trans- mitted wirelessly from the Gateway node. The end nodes process received com- mands in a FIFO order exactly like the Gateway node. Almost all commands on end nodes will generate some kind of response message which will be sent back to the Gateway node over Xbee radio.
Transmission Of Commands To End Nodes
