Thesis 1

See discussions, stats, and author profiles for this publication at: https://www.researchgate.
net/publication/315794059
Development of an optimal synchronization system for remotely located

sensor units of Overhead Line Monitoring Systems (OLMS) using Global
Positoning System (GPS) Satellite Receive...
Thesis · March 2017

DOI: 10.13140/RG.2.2.22044.90249
CITATIONS READS
0 2,814
1 author:
Ahmedul Haque
Karlsruhe Institute of Technology
5 PUBLICATIONS 1 CITATION
SEE PROFILE
All content following this page was uploaded by Ahmedul Haque on 06 April 2017.
The user has requested enhancement of the downloaded file.

Development of an optimal
synchronization system for remotely
located sensor units of overhead line
monitoring systems
Master Thesis of
Ahmedul Haque
At the Department of Electronics

Institute for Information and Processing Technologies (ITIV)
Reviewer: Prof. Dr. rer. nat. Wilhelm Stork

Advisor: M.Eng. Gabrela Molinar
Duration: 19. September 2016 – 18. March 2017
KIT – University of the State of Baden-Wuerttemberg and National Research Center of the Helmholtz Association www.kit.edu
Abstract
Due to the recent advances in technology, low-cost, low-power, multifunctional sensor nodes
equipped with data processing, sensing and communicating abilities have been developed.
These sensor units are used to observe and monitor a variety of phenomena (such as
temperature and height measurement) in real physical world. Some applications need a
network of sensor units, where each node is connected to each other and their measurements
must be considered as a whole. In those cases, a time synchronization between all sensor
units is needed to guarantee a correct analysis of the data.
This thesis reviews the most representative clock synchronization algorithms for Wire-
less Sensor Networks (WSN) and evaluates their suitability to Overhead Line Monitor-
ing Systems (OLMS). The thesis describes also the development and implementation of
an innovative time synchronization algorithm for providing optimum time synchroniza-
tion performance to a set of remotely located sensor units installed on overhead power
lines. This algorithm ensures a reliable way to effectively handle and understand the data
tramsmitted from sensor units to a central station, where the data is processed. This
algorithm was programmed and run on a STM microcontroller with a Cortex M4 proces-
sor at 168 MHz. The performance of this algorithm is tested with two microcontrollrs of
STM32 family namely, STM32F407VGMCU Discovery Kit and STM32F4329ZI DISCO
Evaluation Board. This new algorithm and the proposed system architecture are designed
in an optimum way to enhance fault tolerance, scalability, enegy efficiency and accuracy
of the whole sensor network. Moreover, some suggestions are made to further improve the
performance of the developed system.
iii
I declare that I have developed and written the enclosed thesis completely by myself, and
have not used sources or means without declaration in the text.
Karlsruhe, March 2017
.........................................
(Ahmedul Haque)
Acknowledgments
First and foremost, I would like to thank my thesis supervisor, Ms.Gabriela Molinar. Her
support, advice, experiences and guidance were instrumental in the completion of this
work. Regular discussion with her was effectively helpful and insightful. I am deeply
grateful to her for her wise suggestion on several challenges while performing the time
synchronization task among sensor units. I am also indebted to her for her sincere effort
to teach me the art of doing research works as an individual. Her guideline will surely help
me to a significant extent in my future life.
I would also like to extend my gratitude to Prof. Dr. rer. nat Wilhelm Stork for is
continuous support during the development of this thesis and giving me the opportunity
to do the thesis within the Institute for Information Processing Technologies (ITIV).
I also want to thank all people that worked in the ITIV institute. With their patience and
openness, they created an enjoyable working environment. I would like to appreciate their
inspiration and cooperation during the entire work.
vii
Contents
Abstract iii
Acknowledgments vii
1. Introduction 1
1.1. An overview of Wireless Sensor Networks (WSN) . . . . . . . . . . . . . . . 2
1.2. Time synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3. Overhead power line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.4. Overhead Line Monitoring Systems (OLMS) . . . . . . . . . . . . . . . . . . 4
1.4.1. Components of a monitoring system . . . . . . . . . . . . . . . . . . 4
1.5. Use of sensors in OLMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.6. Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.7. Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.8. Requirements on time synchronization protocols for Wireless Sensor Networks 7
2. Theoretical background 9
2.1. Related work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.1. Definition of clock and general clock model [RN10] . . . . . . . . . . 9
2.1.2. Sources of errors in time synchronization . . . . . . . . . . . . . . . 11
2.2. Classification of time synchronization protocols . . . . . . . . . . . . . . . . 12
2.2.1. Synchronization issues . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.1.1. Master-slave versus peer-to-peer synchronization . . . . . . 12
2.2.1.2. Internal synchronization versus external synchronization . 13
2.2.1.3. Probabilistic versus deterministic synchronization . . . . . 13
2.2.1.4. Sender-to-receiver versus receiver-to-receiver versus receiver-
only synchronization . . . . . . . . . . . . . . . . . . . . . . 13
2.2.1.5. Clock correction vs untethered clocks . . . . . . . . . . . . 14
2.2.1.6. Pairwise Synchronization versus network-wide synchroniza-
tion [RLK+ 09] . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.2. Application-dependent features . . . . . . . . . . . . . . . . . . . . . 15
2.2.2.1. Single-hop versus multi-hop networks . . . . . . . . . . . . 15
2.2.2.2. Stationary networks versus mobile networks . . . . . . . . 15
2.2.2.3. MAC-layer-based approach versus standard approach . . . 15
2.3. Discusssion of time synchronization protocols . . . . . . . . . . . . . . . . . 16
2.3.1. Flooding Time Synchronization Protocol (FTSP) . . . . . . . . . . . 16
2.3.2. Reference Broadcast Synchronization(RBS) . . . . . . . . . . . . . . 16
2.3.3. Romer’s Synchronization Protocol . . . . . . . . . . . . . . . . . . . 17
2.3.4. Continuous clock synchronization is wireless real-time applications
(Mock et al.’s Protocol) . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.3.5. Timing-Sync Protocol for Sensor Networks (TPSN) . . . . . . . . . 19
2.3.6. Delay Measurement Time Synchronization (DMTS) Protocol . . . . 19
2.3.7. Probabilistic Clock Synchronization service in wireless sensor networks 21
ix
x Contents
2.3.8. Tiny-Sinc and Miny-Sinc . . . . . . . . . . . . . . . . . . . . . . . . 22

2.3.9. Time Diffusion Synchronization Protocol(TDP) . . . . . . . . . . . . 22
2.3.10. Asynchronous Diffusion Protocol(ADP) . . . . . . . . . . . . . . . . 23
2.3.11. Fast Asynchronous Diffusion Protocol(FAD) . . . . . . . . . . . . . . 23
2.3.12. TSYNC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.3.13. Optimized Time Synchronization protocols (OTSP) . . . . . . . . . 24
2.3.14. Consensus Clock Synchronization(CCS) . . . . . . . . . . . . . . . . 25
2.3.15. Syncob: Collaborative Time Synchronization . . . . . . . . . . . . . 26
2.4. Comparison among time synchronization protocols . . . . . . . . . . . . . . 27
2.4.1. Quantitative Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.4.2. Qualitative Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.5. Global Positioning System (GPS) . . . . . . . . . . . . . . . . . . . . . . . . 30
2.6. GPS receiver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.7. U-blox Neo-6M GPS Module . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.7.1. Features [Ele] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.7.2. Electrical specifications . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.7.3. Pin descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.7.4. Connection to micro-controller board . . . . . . . . . . . . . . . . . . 33
2.7.5. PPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.7.5.1. How to use PPS for time synchronization . . . . . . . . . . 34
2.7.5.2. A few notes on using PPS as a time reference: . . . . . . . 34
2.7.5.3. How to use PPS with STM32F4 Microcontroller: . . . . . . 35
2.7.6. GPS receiver output . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.7.7. NMEA Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.8. Communication Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.8.1. Parallel Communication . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.8.2. Serial Communication . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.8.2.1. Asynchronous serial . . . . . . . . . . . . . . . . . . . . . . 37
2.8.2.2. Synchronous serial . . . . . . . . . . . . . . . . . . . . . . . 37
2.8.3. Universal synchronous asynchronous receiver transmitter (USART) . 38
2.9. Real-Time Clock(RTC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.9.1. RTC clock configuration . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.9.2. RTC Calendar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.9.3. How to adjust the RTC calendar clock . . . . . . . . . . . . . . . . . 42
2.9.4. RTC alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
2.9.5. RTC alarm sub-second configuration . . . . . . . . . . . . . . . . . . 43
3. System description 45
3.1. Reasons behind choosing GPS receiver as time source . . . . . . . . . . . . 46
3.2. An innovative time synchronization algorithm . . . . . . . . . . . . . . . . . 47
3.2.1. Reasons behind choosing this algorithm . . . . . . . . . . . . . . . . 47
3.2.2. Implementation of the time synchronization algorithm . . . . . . . . 49
3.2.2.1. NMEA Messages Overview . . . . . . . . . . . . . . . . . . 51
4. Results 53
4.1. Test Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.2. Test Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.2.1. Time needed to reset counter/timer . . . . . . . . . . . . . . . . . . 54
4.2.2. Processing time needed to update GPS and set RTC seperately . . . 55
4.2.3. Total processing time needed to update GPS and set RTC . . . . . . 56
4.2.4. Clock Offset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
x
Contents xi
4.2.5. Synchronization Precision . . . . . . . . . . . . . . . . . . . . . . . . 56

4.2.5.1. Absolute Precision . . . . . . . . . . . . . . . . . . . . . . . 56
4.2.5.2. Relative Precision . . . . . . . . . . . . . . . . . . . . . . . 56
4.2.6. Clock Skew . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.2.7. Power Consumption . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.2.8. Time interval between each GPS update . . . . . . . . . . . . . . . . 60
4.3. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5. Conclusion and Outlook 63

5.1. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.2. Outlook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Bibliography 65
Appendix 67
A. List of Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
B. Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
C. Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
xi
List of Figures
1.1. Overhead power line in Gloucestershire, England. . . . . . . . . . . . . . . . 3

1.2. Monitoring system scheme. . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. An example of overhead transmission line. . . . . . . . . . . . . . . . . . . . 5
1.4. Structure of sensor network. . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.5. Structure of a sensor unit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Behavior of slow, fast and perfect clock. . . . . . . . . . . . . . . . . . . . . 10

2.2. Delays involved during delivery of a message over a wireless link . . . . . . 11
2.3. Time critical path in RBS protocol. . . . . . . . . . . . . . . . . . . . . . . 17
2.4. Time transfer path in a mica mote wireless media. . . . . . . . . . . . . . . 20
2.5. GPS constellation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.6. GPS receiver. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.7. NEO-6M GPS receiver. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.8. Connection between a microcontroller and a NEO-6M GPS receiver. . . . . 33
2.9. NMEA protocol. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.10. An example of parallel communication. . . . . . . . . . . . . . . . . . . . . . 36
2.11. An example of serial communication. . . . . . . . . . . . . . . . . . . . . . . 37
2.12. An example of asynchronous serial communication. . . . . . . . . . . . . . . 37
2.13. An example of synchronous serial communication. . . . . . . . . . . . . . . 38
2.14. USART communication procedure. . . . . . . . . . . . . . . . . . . . . . . . 39
2.15. RTC clock source. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.16. RTC calender. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.17. RTC calender display. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.18. RTC prescaler adjust . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.19. RTC Alarm A fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
2.20. RTC Alarm sub-secondfields . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.1. Structure of a sensor unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

3.2. The proposed sensor network architecture in this thesis . . . . . . . . . . . 46
3.3. The flow chart of proposed time synchronization algorithm . . . . . . . . . 49
3.4. The proposed time synchronization algorithm . . . . . . . . . . . . . . . . . 50
3.5. Seperation of second from subsecond . . . . . . . . . . . . . . . . . . . . . . 51
4.1. Configuration of the system when testing performnance . . . . . . . . . . . 53

4.2. Comarison of RTC frequency of two microcontrollers . . . . . . . . . . . . . 57
4.3. Snapshot of RTC alarm signal for . . . . . . . . . . . . . . . . . . . . . . . . 58
4.4. Snapshot of RTC alarm signal for . . . . . . . . . . . . . . . . . . . . . . . . 58
xiii
List of Tables
1.1. Different Applications of WSN . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.1. Classification based on synchronization issues . . . . . . . . . . . . . . . . . 14

2.2. Classification based on application-dependent features . . . . . . . . . . . . 16
2.3. Quantitative performance comparison . . . . . . . . . . . . . . . . . . . . . 29
2.4. Qualitative performance comparison . . . . . . . . . . . . . . . . . . . . . . 30
2.5. Electrical specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.6. Pin description of NEO-6M GPS module . . . . . . . . . . . . . . . . . . . . 33
2.7. RTC prescaler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.8. RTC alarm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.1. Used NMEA standard messages . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.1. Processing time needed to reset timer/counter . . . . . . . . . . . . . . . . . 54

4.2. Processing time needed to update GPS and set RTC seperately . . . . . . . 55
4.3. Processing time needed to update GPS & set RTC . . . . . . . . . . . . . . 56
4.4. Absolute precision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.5. RTC frequency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.6. Power Consumption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.7. Time interval between each GPS update . . . . . . . . . . . . . . . . . . . . 60
xv
1. Introduction
It is hardly possible to imagine a modern society without electrical power. Most of the
devices of the daily life works with electric power. Electricity has become one of the
fundamental needs for the modern society.
After being generated, electric power needs to be transmitted to the place of consumption.
Sometimes, this distance could be quite long. Electric network is used to transport elec-
tricity from generators to consumers. The transmission system between power generation
and consumption has to be reliable. This medium must be risk free and employed in an
efficient way for monetary reasons. In order to ensure that, these lines need to be moni-
tored by transmission system operators (TSO). The capacity of the existing network could
be enhanced by using sensors and optimal regulation. Doing that, the need to construct
new lines will be reduced [MB11].
The high voltage transmission lines or overhead power lines, depending on system load,
can carry high current. This high current and weather conditions can cause a rise in
temperature, finally leading to the elongation in length of these lines. There could be two
problems created by this:
1. The amount of maximum power transmitted could be limited.
2. These elongated lines become bent and could touch any object below since the dis-
tance between these lines and ground is reduced. At high temperature there will
be risk electric sparks and short circuits with objects that are below these lines (for
example, highways, trees, buildings,cars etc.) thus causing lots of damages in terms
of human lives as well.
Hence, it is of vital importance to regularly monitor the lines. Sensors are used for this
purpose. They will measure the temperature and height of the lines from the ground and
then send the measured data to the TSO where further processing and analysis will take
place.
Sensors are used to monitor the conductor behavior and to control the power that can
be transmitted in real-time. Time synchronization between all sensor units is needed to
guarantee a correct analysis of the data. Those sensors must be time synchronized, i.e.
each measurement must have a time stamp common to all sensor units, to allow an efficient
data understanding and control of the system.
1
2 1. Introduction
1.1. An overview of Wireless Sensor Networks (WSN)

Due to the advancement in technology, low-cost, low power and multifunctional wireless
sensing devices have been developed. These wireless devices are capable of sensing, data
processing and communication. A wireless sensor network (WSN) consists of a large num-
ber of sensor nodes which are spatially distributed to track a certain physical phenomena.
Each sensor is fitted with sensing components, a transceiver for wireless communication,
computing circuitry for data processing and networking, and an energy source or battery
[SBK05].
Sensor networks are a special type of ad-hoc network. In an ad-hoc network, wireless
devices (usually called nodes) work together spontaneously to form a network without the
necessity of any infrastructure. The positions of sensor nodes might not be predetermined.
That means sensor nodes should have self organizing capability [SBK05].
Some of the application domains of WSN are military, civilian, industrial, environmental,
medical, agriculture, space exploration, logistics etc. as shown in Table 1.1.
Domain Applications
Health Recognition of pre defined symptoms by tele-monitoring physio-
logical data
Logistics Tracking of Cargo
Civilian Highway traffic monitoring
Military Enemy attack prevention, chemical and nuclear attack monitoring
Environment Flood and Earthquake detection
Home and K-12 educa- Smart kindergarten, intelligent home
tion
Agriculture Soil moisture and water resource monitoring
Space Exploration Exploration of cosmic radiation and inter-planets
Ocean Deep undersea exploration
Industry Toxic gas emission detection
Table 1.1.: Different Applications of WSN [SBK05].
1.2. Time synchronization

Since sensors in WSN work independently, the local clock of each node might not be
synchronized with respect to the other. So it might be difficult to integrate and interpret
information collected by different nodes. That is why we need time synchronization which
creates a common understanding of time among the local clocks in the sensor nodes. Since
the hardware clocks are not perfect, the local clocks of the nodes might drift away from
each other in time, i.e. observed time or duration of time interval could be different for
each node in the network.
Time synchronization is important for many applications such as data fusion of measure-
ments collected from different nodes and then sending the collected data to a sink node in
order to make a decision. In order to have a correct decision, there has to be a common
notion of time among all the sensor nodes. Moreover, common services in WSN, such
as security, communication, coordination, power management also depend on global time
scale.
1.3. Overhead power line

Electrical power needs to be transmitted from point of generation to the point of consump-
tion. It can be done via cables or overhead lines. However, the repair and maintenance
2
1.3. Overhead power line 3
costs associated with cables are high. Morever, long relocation time makes it unsuitable
in many real time applications. Overhead line overcomes the problems associated with
cables and hence (Figure 1.1) is preferred in transmission of energy along large distances.
It is comprised of one or more conductors, suspended by poles or towers [MPJ08].
Figure 1.1.: Overhead power line in Gloucestershire, England [ove].
The advantages of overhead power line compared to cables for power transmission are as
follows [MPJ08]:
• It is easier to maintain overhead lines.

• They have significantly lower relocation time.
• They are cheaper due to low insulation cost and low conductor material cost.
• They have better heat dissipation.
3
4 1. Introduction
However, overhead power line shows some distadvantages as follows [MPJ08]:
• They are vulnerable to lightning strikes which can cause interruption.
• They use bare conductors which can break and cause damage.
• In tourism regions, they will be seen as an impairment of nature.
• The maintenance cost is high.
• The voltage drop in overhead lines is high.
1.4. Overhead Line Monitoring Systems (OLMS)

The backbone of electrical power transmission is the overhead line. In majority of cases,
it is the most economic and practical solution for energy transmission. The energy con-
sumption is growing fast in Europe and the volatility of energy transmission has also been
increased during the last decade due to the opening of electrical energy market. This
opening has caused the minimization of the maintenance of existing lines. Today, network
operators are running out of equipment and blackouts and disturbances in small and large
areas are also increasing. That is why it has become essential to improve the reliability of
the network. One way to do this is the monitoring of overhead lines [MPJ08].
1.4.1. Components of a monitoring system
The basic components of a monitoring system are [MPJ08] (see Figure 1.2 ):
1. A measuring unit with power supply and data communication.
2. A receiving unit with data processing, storage and graphical user interface for the
operator.
Figure 1.2.: Monitoring system scheme [MPJ08].
4
1.5. Use of sensors in OLMS 5
1.5. Use of sensors in OLMS
The transmission of energy is monitored in transmission lines via deploying sensors in all
the components of OLMS. There are many poles supporting a long overhead transmission
line (Figure 1.3). Usually sensors are placed on locations close to the poles on each span.
Data generated by sensors have to be delivered to the substation [MPJ08].
Figure 1.3.: An example of overhead transmission line [HLL+ 10].
1.6. Environment
The structure of the sensor network developed for monitoring remotely located sensors of
OLMS is according to Figure 1.4. There are sensor units located in the overhead power
lines, which are wirelessly connected a central station. Each of the sensor units consists of
an arbitrary number of sensors and a processing unit as shown in Figure 1.5.
The sensor units on OLMS could have different kind of sensors, as for example [MPJ08]:
• Height measurement sensor or sag sensor.
• Temperature measurement sensor.
• Image sensor.
• Rope tension measurement sensor.
• Phase angle measurement sensor.
This thesis focuses on the design and implementation of the time synchronization algo-
rithm which will timestamp incoming data from sensors. This algorithm runs in a mi-
crocontroller (which is used as processing unit in this thesis) and is bound to assure an
effective synchronization of time inside the system.
5
6 1. Introduction
Figure 1.4.: Structure of the sensor network for the OLMS considered in this thesis. CS stands for
central station, SU for sensor unit. An arbitrary number of sensor units are wirelessly
connected to a central station.
Figure 1.5.: Structure of a typical wireless sensor unit. It has an arbitrary N number of sensors
(denoted as S1,S2 up to SN) connected to a processing unit (denoted as PU) which
ensures the wireless transmission of timestamped information to the central station.
1.7. Tasks
The measured data from each sensor will be processed by the corresponding processing
unit and then will be sent to a central station for making further analysis. The central
station will get measured data from all the sensor units available in the system. In order
to properly manage and efficiently understand the time when each measured data is taken,
the central station should receive data with proper time information (that means when
the measured data is taken). A common notion of time is thus needed among sensors in a
sensor unit.
6
1.8. Requirements on time synchronization protocols for Wireless Sensor Networks 7
The central station is responsible for managing the information generated by the sensors
in each sesnor unit. That means, all measurement data have to be properly time-stamped
on the sensor unit. This also implies that the processing unit itself needs to be time
synchronized. One possible way to do it is to connect a global source of time such as a
GPS receiver to the processing unit.
This thesis is focused in synchronization of time among sensors in individual sensor units.
1.8. Requirements on time synchronization protocols for Wire-

less Sensor Networks
There are a broad set of requirements that should be met while evaluating the performance
of a time synchronization algorithm [Yan12]. However there is a trade-off between these
requirements in an efficient synchronization solution (For example, energy efficiency against
precision).
• Accuracy:
Accuracy indicates the maximum offsets or average errors between the local clock
values of any two nodes. The need for accuracy varies for different protocols depend-
ing on applications and purpose of synchronizations. It shows how well the time is
maintained in WSN with respect to the standard time.
• Energy Efficiency:
It is the most important factor for WSN as every network node has a limited energy
resource. Some define energy efficiency based on awake and sleep time of nodes.
Others define it as the amount of energy consumed for one round of synchronization.
• Robustness:
If WSN is employed in harsh and hostile environments, network nodes might die or
go out of network. It affects the level of synchronization errors at least for some time
until the failed node is replaced. During this time, nodes waste both energy and
time.
• Lifetime:
The synchronized time may be instantaneous or throughout the entire duration of
the network.
• Scalability:
A large number of sensor nodes are deployed in wireless sensor networks. Time
synchronization protocols should work well with arbitrary number of nodes.
• Complexity:
Highly complex synchronization protocols are not applicable to many applications
due to energy constraint and hardware limitations.
• Cost and size:

Wireless sensor nodes are usually cheap and inexpensive devices. Therefore attaching
a large expensive device might not be a good option for synchronizing nodes. So a
synchronization protocol should be developed with limited cost and size issues in
mind.
• Scope:
A time synchronization protocol may provide a common time scale for all sensor
nodes in the network or for only some closely spaced nodes.
7
8 1. Introduction
• Immediacy/Delay:
Many applications, such as forest fire detection, may require instant response without
any significant delay. This is called immediacy requirement and might prevent the
designer of the protocol from depending on excessive processing after such an event
of interest occurs which in turn requires that all nodes to be pre-synchronized at all
times.
8
2. Theoretical background
Before beginning the development of a time synchronization algorithm, it is necessary to

determine how will be fulfilled each requirement that the system has and once that is
known, the implementation can start.
2.1. Related work

2.1.1. Definition of clock and general clock model [RN10]
Computer clock circuits are comprised of a hardware oscillator assisted clock which imple-
ments an approximation C(t) of real time t. C(t) is the clock value. The angular frequency
of the oscillator decides the clock rate. The counter increments its value to represent the
local clock value C(t) of a sensor node.
∂C
The rate of a clock is denoted as ∂t .
For a perfect clock, equation 2.1 is fulfilled which means that clock value is equal to real
time.
∂C
=1 (2.1)
∂t
In reality, due to a series of fluctuations, such as vibration, temperature, humidity etc. the
angular frequency of a clock changes over time and clocks drift.
For some node i, the local clock value Ci (t) can be related to real time t by equation 2.2.
Ci (t) = (ai × t) + bi (2.2)
Here, ai is the clock drift and bi is the clock offset of node i. Drift denotes the rate or
frequency of the clock and offset denotes the difference between the clock value and real
time t.
Equation 2.2 can be used to compare the local clock values of two nodes (see equation
2.3).
C1 (t) = (a12 × C2 (t)) + b12 (2.3)
9
10 2. Theoretical background
Where, a12 is the relative drift and b12 is the relative offset between the clocks of nodes 1
and 2.
If two clocks are perfectly synchronized, then the relative drift is equal to 1 and the relative
offset is equal to zero as shown in equations 2.4, 2.5.
a12 = 1 (2.4)
b12 = 0 (2.5)
Different kinds of errors are defined in equations 2.6, 2.7, 2.8 ,
Of f set, δ = C1 (t) − C2 (t) (2.6)
∂C1 (t) ∂C2 (t)

Skew, η = − (2.7)
∂t ∂t
∂ 2 C1 (t) ∂ 2 C2 (t)
Drif t, λ = − (2.8)
∂t2 ∂t2
Offset is the difference in local clock values between two clocks. Skew is the difference in
rate of change of local values between two clocks. In other words, skew is the difference
in frequency of two clocks. Drift is defined to be the difference in rate of change of skew
between two clocks [RLK+ 09].
The clock skew can fluctuate over time due to different atmospheric conditions, such as
temperature and humidity. But assuming that the clock skew stays bounded, equation 2.9
is reached.
clockskew ≤ (1 + ρ) (2.9)
Here ρ denotes maximum skew rate and a typical value of it is 0.000001.

The behaviour of slow, fast and perfect clock is shown in Figure 2.1.
Figure 2.1.: Behavior of slow, fast and perfect clock [SBK05]
10
2.1. Related work 11
2.1.2. Sources of errors in time synchronization

In order to synchronize the sensor nodes, reliable estimation of message delays between
the nodes is necessary. For that, the communication channel has to be possessed by sensor
nodes for a certain period of time. But the main problem in time synchronization is the
non deterministic character of the delays.
For example, if two nodes namely, node 1 and node 2 want to get synchronized, then
node 1 will send a packet with its time stamp to node 2. Since there is non-deterministic
message delay involved, node 2 cannot directly determine the difference between the two
clocks, making time synchronization between these two nodes more difficult.
Generally, the following six components (as shown in Figure 2.2) are the main sources of
time synchronization errors [BM10]:
Figure 2.2.: Delays involved during delivery of a message over a wireless link [BM10]
1. Send Time:
This is the time needed to build the message at the application layer and then transfer
it to the network interface. This time varies with operating systems.
2. Access Time:
Probably the most significant componenet that leads to packet delay. This is the
waiting time needed to access the channel after reaching the MAC (Medium Access
Control) layer. It is highly dependent of the sensor network employed MAC protocol.
3. Transmission Time:
During this time the packet is transmitted bit by bit at physical layer. Estimation
of the packet time depends on the radio speed and packet size.
4. Propagation Time:
During this time the message travels from network interface of the sender to the
network interface of the receiver through air.
5. Reception Time:
Similar to transmission time, reception time is the time taken in receiving a message
bit by bit at the physical layer.
6. Receive Time:
Highly dependent on the operating system in use. This is the time spent in receiving
the message, transforming the bits into a packet and then tranferring the packet to
the application layer where the receiver decodes it.
11
2.2. Classification of time synchronization protocols

Wireless sensor networks have wide range of applications. These applications are closely
linked to the type of networks used. Some commonly referred time synchronization pro-
tocols are:
1. Flooding Time Synchronization Protocol (FTSP)
2. Reference Broadcast Synchronization(RBS)
3. Lightweight Tree-based Synchronization (LTS)
4. Romer’s Synchronization Protocol
5. (Mock et al.’s Protocol
6. Timing-Sync Protocol for Sensor Networks (TPSN)
7. Delay Measurement Time Synchronization (DMTS) Protocol
8. Probabilistic Clock Synchronization service
9. Tiny-Sinc and Miny-Sinc
10. Time Diffusion Synchronization Protocol(TDP)
11. Asynchronous Diffusion Protocol(ADP)
In some aspects, these protocols are similar to each other, Based on some other aspects,
these protocols will be different. Time synchronization protocols can be classified based
on the two following features [SBK05]:
• Synchronization issues
• Application-dependent features
2.2.1. Synchronization issues

In order to fuse data from different sensors, it is necessary to have a common notion of
time among sensor nodes.This can be done in any of the two ways [SBK05]:
1. By synchronization of local clocks of each sensor nodes.

2. By translating the timestamps arriving at sensor nodes into local clock times.
Different options are described below [SBK05].
2.2.1.1. Master-slave versus peer-to-peer synchronization
• Master-slave:
One node will be selected as master, the other nodes will be slaves. The local
clock reading of the master will be regarded as reference time by the slaves. Slaves
will try to get synchronized with the master node. The master node needs CPU
resources proportional to the number of slaves. Usually, master nodes have powerful
processors.
• Peer-peer:
Any node can communicate directly with all the other nodes in the network. So the
risk of master node failure is eliminated in this method. This protocol offers more
flexibility but can also be more difficult to handle.
12
2.2. Classification of time synchronization protocols 13
2.2.1.2. Internal synchronization versus external synchronization
• Internal synchronization:
A global time base, called real time is unavailable and that is why the main target
of this method is to minimize the maximunm difference between local clock readings
of the sensor nodes.
• External synchronization:
A standard source of time, such as UTC(Universal Time Controller) is available.
UTC can be used as reference time by the sensor nodes. This method has high
energy requirement due to the use of an external time source.
Internal synchronization is applicale to both master-slave and peer-peer fashion
whereas, external synchronization is suited for master-slave fashion only. External
synchronization needs master node which maintains communication with a stan-
dard time service (such as GPS) in order to synchronize the slaves and itself to the
reference time.
2.2.1.3. Probabilistic versus deterministic synchronization
• Probabilistic synchronization:
A probabilistic guarantee on the maximum clock offset with a failure probability that
can be bonded or determined is ensured in this method. Protocols following deter-
ministic approach exchange more messages and need extra processing. So propabilis-
tic approach is preferred over deterministic one some times. However, propabilistic
method is not suitable for wireless environment.
• Deterministic synchronization:
An upper bound on the clock offset is guaranteed with certainty. Most algorithms
follow deterministic approach.
2.2.1.4. Sender-to-receiver versus receiver-to-receiver versus receiver-only syn-

chronization
• Sender-to-receiver synchronization (SRS):

This approach takes place in 3 steps:
1. The sender node periodically sends a message with its local time as a timestamp
to the receiver
2. The receiving node then synchronizes with the sender using the timestamp it
has received from the sender.
3. The delay between the sending and the receiving node is computed by consid-
ering the round-trip time.
• Receiver-to-receiver synchronization (RRS):
This method works based on the priciple that if any two receiving nodes receive the
same message in a single hop transmission, then they receive it at approximately
the same time.Receiving nodes exchange their time of receiving the same message
with each other and then the offset is computed based on the difference in reception
times.
• Receiver-only synchronization (ROS):
By only listening to the message exchanges of a pair of nodes, group of nodes will
be simultaneously synchronized.
13
2.2.1.5. Clock correction vs untethered clocks
• Clock correction:
In order to keep the entire network synchronized, the local clock values of the par-
ticipating nodes are corrected either instantly or continously. The correction is done
with respect to a global time-scale or an atomic clock.
• Untethered clocks:
In order to have a common notion of time among the sensor nodes, a considerable
amount of energy is dissipated. It can be avoided if the local clock value of each
node is exchanged with others. The local values are maintained and compared in
a tabular format. When sensor nodes exchange the timestamps, those timestamps
are transferred to the local clock values of the receiving node. The round-trip delay
between two nodes is taken into consideration.
2.2.1.6. Pairwise Synchronization versus network-wide synchronization [RLK+ 09]
• Pairwise Synchronization:
Synchronization is done in between two nodes. However synchronization among a
set of nodes is also possible.
• Network-wide synchronization:
A large number of nodes are synchronized using this method.
Table 2.1 shows the classification of different time synchronization protocols based on
synchronization issues [SBK05].
Synchronization issues
Protocol Master- Internal vs. Probabilistic Sender-to- Clock
slave versus external vs. deter- receiver vs correction
peer-to- ministic receiver-to-
peer receiver
RBS Peer-peer Both Deterministic Receiver- No
to-receiver
Romer Peer-peer Internal Deterministic Sender-to- No
receiver
Mock et al. Master/slave Internal Deterministic Receiver- Yes
to-receiver
TPSN Master/slave Both Deterministic Sender-to- Yes
receiver
DMTS Master/slave Both Deterministic Sender-to- Yes
receiver
Probabilistic Peer-peer Both Probabilistic Receiver- No
to-receiver
Tini-sync Peer-peer Internal Deterministic Sender-to- Yes
receiver
Time- Peer-peer Internal Deterministic Receiver- Yes
diffusion to-receiver
Asynchronous Peer-peer Internal Deterministic Sender-to- Yes
diffusion receiver
Table 2.1.: Classification based on synchronization issues [SBK05]
14
2.2. Classification of time synchronization protocols 15
2.2.2. Application-dependent features

The application-dependent features of the synchronization algorithms can be of the fol-
lowing types [SBK05]:
2.2.2.1. Single-hop versus multi-hop networks

• Single-hop communication:
A direct communication and exchange of messages between a sensor node and any
other node in the network is possible. However if the network size is large, it becomes
impossible for each sensor node to communicate directly with every other node in
the network.
• Multi-hop communication:
The communication between a sensor node in one domain and a sensor node in other
domain is done via an intermediate sensor node which can relate to both domain.
Through a chain of pairwise-adjacent sensor node, communication is also possible as
a sequence of hops.
2.2.2.2. Stationary networks versus mobile networks

• Single-hop communication:
Sensor nodes are in a fixed position. An example could be the sensor network used
to monitor vehicles.
• Multi-hop communication:
Sensors can move and have the ability to contact with other sensors within the
geographical scope of those sensors. Although mobiity of the sensor nodes offer
flexibility, but it can induce more difficulty while achieving synchronization.
2.2.2.3. MAC-layer-based approach versus standard approach

Media Access Control(MAC) is a part of the Data Link Layer in Open System Intercon-
nection (OSI) model. This layer performs the following functions:
• Delivers reliability to the higher layers with respect to the connection established by
the physical layer.
• Avoids transmission collision so that message transmission between one sending node
and the other intended receiving node(s) does not hamper the transmission by other
nodes.
MAC protocol properly utilizes the MAC layer in order to get better energy efficiency.
The IEEE 802.11 MAC protocol is widely used.
Table 2.2 shows classification of different time synchronization protocols based on appli-
cation dependent features [SBK05].
15
Application-dependent features
Protocol Single-hop MAC layer Geared to
versus vs standard mobility
multi-hop
RBS Both Standard No
Romer Single-hop Standard Yes
Mock et al. Both MAC layer No
TPSN Both MAC layer Yes
DMTS Both Standard No
Probabilistic Both Standard No
Tini-sync Both MAC layer No
Time- Both Standard Yes
diffusion
Asynchronous Both Standard Yes
diffusion
Table 2.2.: Classification based on application-dependent features [SBK05]
2.3. Discusssion of time synchronization protocols

2.3.1. Flooding Time Synchronization Protocol (FTSP)
In order to achieve local synchronization among local participating nodes, FTSP algorithm
is used. Local clock synchronization error in each node is corrected using message exchange
mechanism. Synchronization of time of single sender to multiple receivers is done using
a single radio message. High accuracy between sensor nodes is maintained along with
synchronized communication. FTSP synchronizes multi-hop nodes since WSN (Wireless
Sensor Network) operates in areas larger than the radius of the node. There are two types
of nodes: Root Node and Dynamic Node forming a Ad-hoc network. Overall time for
all nodes (except the root node) is maintained using dynamic node. The total time is
transferred from root node to all nodes that keep the initial phase of the tree [MKSL04].
FTSP has the following advantages [MKSL04]:
• More robust against failure of links between nodes and dynamic topology changes.
• Each node can communicate despite the lack of reliability.
However, this protocol represents some disadvantages as follows [MKSL04]:

• Due to linear regression, an initiation period is required.
• Each node can communicate despite the lack of reliability.
2.3.2. Reference Broadcast Synchronization(RBS)

RBS system is receiver centric. This protocol exchanges synchronization packets on the
physical layer. RBS is based on broadcasting principle of media. If two receiving nodes are
within the listening distance of the sender, then the transmitted packet will arrive to the
two receiving nodes almost the same time. Then time of reception of the packets will be
compared between two nodes and local clock correction will be done [SBK05] accordingly
(see figure 2.3).
RBS exhibits the following advantages [SBK05]:
• The largest sources of error (access time and send time) are eliminated from critical
path by decoupling the sender from the receiver.
16
2.3. Discusssion of time synchronization protocols 17
Figure 2.3.: Time-critical path for traditional protocols (left) and RBS protocol (right) [SBK05].
• Waste of energy on updating clocks is prevented by post-facto synchronization.

• Clock skew and offset are estimated independent of each other.
• Since local clocks are never modified, clock correction does not affect any of the
estimations.
• Works best with single hop networks.
• Extension to multi-hop support is provided using nodes that belong to multiple
neighborhoods.
• RBS protocol works with both wired and wireless networks.
• RBS handles lost packets.
• Multiple broadcasting enables tight synchronization.
• Absolute and relative timescales can be maintained.
On the other hand, the disadvantages of RBS protocol are as follows [SBK05]:
• RBS is suitable for point to point communication since a broadcasting medium is
required..
• In order to synchronize nodes exchange of messages is needed, which makes RBS
protocol costly.
• The reference node cannot be synchronized in RBS.
• Because of large number of message exchanges, convergence time (time needed to
synchronize the whole network) is high.
• The number of message exchange is very large. For a single hop network, if there
are n receiving nodes, then RBS needs n2 message exchanges.
2.3.3. Romer’s Synchronization Protocol

This protocol is designed for ad-hoc communication networks. This protocol is based on
two assumptions [SBK05]:
1. There is an upper bound on the maximum skew of computer clock.

2. If a message is exchanged between two nodes, the connection will remain active until
on additional message is exchanged.
17
The advantages of this protocol are as follows[SBK05]:

• This protocol is suitable for resource restricted environments due to low resource and
message overhead requirement.
• For long distance communication applications, where distance is much greater than
the transmission range of nodes, this protocol is suitable.
• By avoiding computer clock correction, this protocol saves energy since local clocks
are allowed to run at their own natural rates.
• Time estimation is bounded with an interval.
On the other hand, the following are the disadvantages of this protocol[SBK05]:
• With the increase of the number of hops along the path of message containing the
timestamp, the synchronization error increases.
• In sparse networks, where the number of hops is usually high, this protocol is not
applicable.
• Synchronization achieved in this protocol is localized and short lived.
• Round trip estimation is required, which can increase synchronization error.
2.3.4. Continuous clock synchronization is wireless real-time applications

(Mock et al.’s Protocol)
This protocol is based on continuous clock synchronization. It uses continuous correction
and employs advanced rate adjustment algorithm. It also utilizes broadcasting property
of medium. This protocol uses two messages for synchronization between a master and a
group of slaves as follows [SBK05]:
1. Indication message.
2. Confirmation message.
Following are the advantages of Mock et al.’s Protocol [SBK05]:
• This protocol is an improvement over IEEE 802.11 standard. This protocol is based
on continuous clock synchronization where as IEEE 802.11 standard works with
instantaneous clock synchronization.
• Since only one message per synchronization round is required, the message complex-
ity of this protocol is quite low.
• Reasonably good accuracy result is obtained when the message transmission between
master and slaves is tight.
• A high degree of tolerance is obtained with respect to loss of messages, a common
situation in wireless networks.
The disadvantages of this algorithm are as follows[SBK05]:
• Due to rate based correction method, computational load on each node is high.
• Clock correction costs significant amount of energy Moreover clock correction is
continuous.
• This protocol is not suitable for multi-hop communications because of the longer and
unpredictable delays.
18
2.3.5. Timing-Sync Protocol for Sensor Networks (TPSN)

TPSN is used for achieving network-wide time synchronization. It works in two phases[SBK05]:
1. Level discovery phase:

A root node is selected and being assigned the lowest level. Then the levels of the
rest of the nodes in the network are determined.
2. Synchronization phase:
In this phase, synchronization among the nodes is performed.
TPSN algorithm has the following advantages [SBK05]:

• TPSN is scalable (works for an arbitrary number of nodes).
• The synchronization precision does not degrade with the increase of the network size.
• Network wide synchronization is achieved in contrast to Mock et al’s protocol which
works effectively only with a small number of nodes.
• TPSN is computationally less expensive compared to NTP.
• Does not depend on transmission range.
The disadvantages of TPSN algorithm are [SBK05]:
• TPSN does not support multi-hop communication.
• This protocol is not efficient to handle dynamic topology protocol changes.
• This protocol is not energy efficient. If the root node dies in the network, the whole
synchronization method must be repeated.
• For applications with high mobility nodes, this protocol is not suitable. It requires
a hierarchical infrastructure.
• Since physical clock correction needs to be performed on local clocks of sensors while
achieving synchronization, TPSN is not efficient in terms of energy conservation.
2.3.6. Delay Measurement Time Synchronization (DMTS) Protocol

DMTS protocol is proposed by Ping. It is a mater-slave, sender-receiver and clock correc-
tion based synchronization approach. DMTS synchronizes sender and multiple receivers
at the same instant thus requiring less number of exchanged messages. Wireless sensor
networks tend to be dynamic behavior in nature. That means network topology may
change any time. DMTS is either adaptive or not sensitive to network topology changes
[RLK+ 09].
• Working Principle:
Among a set of communication nodes, a leader is selected as the time master. Then
the leader broadcasts its time or local clock value to the receivers. There is some
delay involved in between the transmission from leader and the reception in the re-
ceivers. The receivers measure this time delay by comparing their local clock values
to the leader’s time. Then the receivers set their time as received master time plus
the measured time delay. That’s how, all the sensors receiving the time synchroniza-
tion message can now be synchronized with the leader. The time synchronization
accuracy is mainly bounded by the accuracy involved in the measurement of time
delay [RLK+ 09]. Some important features of DMTS protocol are described below:
1. A local clock is maintained.
19
2. Local clocks are synchronized over the whole network to create a network time.
3. Global time source synchronization is possible by connecting the synchroniza-
tion leader to a global time source such as GPS receiver.
The five delays involved along a time transfer path [RLK+ 09] are presented in the
figure 2.4.
Figure 2.4.: Time transfer path in a mica mote wireles media[Pin03].
1. The processing time and MAC delay of the sender can be eliminated by taking
a timestamp when a clear channel is detected.
2. Transmit time is divided into two parts: time to send preamble and start sym-
bols and then time to send the data.
3. The processing time of the receiver is measured using local timestamps of the
receiver: If a time packet is time stamped at its arrival time and then time
stamped again before adjusting the local clock of the receiver then, processing
delay of receiver is the difference between the two timestamps.
Figure 2.4 shows the time line of transferring a message from one node to
the other. In Mica platform, the sender synchronizes with the receiver at the
end of start symbol. If the receiver takes a local timestamp at this instant
(denoted by t1 ) and then take another timestamp when processing the time
message (denoted by t2 ) then, total time delay (denoted by td ) can be measured
[RLK+ 09] according to equation 2.10.
td = te + t2 − t1 (2.10)
whereas, te is the estimated time to send the preamble and start symbols.
In DMTS protocol, the leader sends a time synchronization message with its
timestamp t, which is added after MAC delay and detection of a clear chan-
nel. The receiver calculates the path delay and sets its local clock time to tr :
The receiver is then synchronized with the leader. The lower bound is the
synchronization precision and the upper bound is the local clock accuracy.
• Multi-hop DMTS algorithm:
Two scenarios are possible [RLK+ 09].
20
1. If a node is aware of its children nodes, then it will broadcast a time signal
after adjusting its own time. By using single hop communication with a known
leader, the node then synchronizes with its children.
2. If a node has no knowledge about the children, then multi-hop DMTS algorithm
is used .Using leader selection algorithm a time master is selected. In order to
identify the distance from master to another node. A master is of source level
0. If a node is synchronized with master, it will be level 1 time source. The root
node periodically broadcasts is time and so do the synchronized nodes. When
receiving a time signal, a node will check the level of the tie source. If it is from
a source of lower level than itself, then it accepts the time. Otherwise it silently
rejects the signal. DMTS guarantees shortest path to time master, since a node
always selects the node that is closest to the time leader as its parent.
DMTS has some advantages as follows [RLK+ 09]:
• DMTS is energy efficient because only one time signal transfer is required to syn-
chronize all nodes in a single hop.
• To monitor a wireless sensor network at run-time, a user application interface is
provided.
• DMTS is lightweight since there is no complex operation involved. So computational
complexity is low.
• From point of view of receivers, the leader’s time signal is a common-view timestamp.
That is why it is convenient for receivers to get synchronized with each other better
than they can synchronize with the sender.
• DMTS supports multi-hop synchronization.
• This algorithm guarantees that root time will be propagated to all network nodes
with a limited number of broadcasts.
However, DMTS has the following disadvantages [RLK+ 09]:
• The synchronization accuracy is low compared to RBS.
• This method is applicable only to a relatively low resolution, low frequency external
clock.
• There is a trade-off between synchronization accuracy and computational complexity
and/or energy efficiency.
2.3.7. Probabilistic Clock Synchronization service in wireless sensor net-

works
Deterministic algorithms can limit the maximum error in clock offsetr estimation. But
a large number of message needs to be exchanged in order to ensure a guarantee on
synchronization accuracy thus making this approach unsuitable for severely limited system
resources. In that case, a reasonable synchronization accuracy can be achieved following
probabilistic approach[SBK05].
This algorithm has the following advantages [SBK05]:
• The probabilistic guarantee ensures the reduction of both the number of messages
exchanged between the nodes and the computational load on each node.
• A trade-off between synchronization accuracy and resource cost is possible.
• This protocol can support multi-hop networks which span several domain.
21
The disadvantages of this algorithm are as follows [SBK05]:

• It might not be appropriate to have a probabilistic guarantee on accuracy in safety
critical applications.
• This method is sensitive to message losses.
2.3.8. Tiny-Sinc and Miny-Sinc

These are two lightweight time synchronization algorithms. These algorithms assume
that the frequency of the clock in a sensor network is fixed. They also assume that
this constant frequency is linearly correlated. In order to collect data, two way message
exchange approach is used [SBK05].
These algorithms at first aim to synchronize a pair of sensor nodes. Then they target to
synchronize all the sensor nodes in the network.
Miny-Sinc is an extension of Tiny-Sinc [SBK05].
The advantages of these algorithms are as follows [SBK05]:
• These protocols provide a tight synchronization scheme because of the minimal re-
quirement of the storage space and computational resources.
• Bandwidth requirements are low.
• These protocols are much more suitable for sensor networks that are highly con-
strained in bandwidth and computational power.
• These protocols are tolerant of message loss.
On the contrary, these algorithms display the following disadvantages [SBK05]:
• The scalability and the robustness of the networks are yet to be discussed.
• The convergence time is quite high.
• Since the sensor network is organized in a hierarchical structure, these protocols are
not suitable for mobile sensor networks.
2.3.9. Time Diffusion Synchronization Protocol(TDP)

TDP permits all the sensor nodes to have a common local time. But this local time is
small bounded deviated version of network-wide equilibrium time [SBK05].
TDP has the two following cases [Yan12]:
1. Without precise time servers.
2. With precise time servers.
TDP exhibits the following advantages [SBK05]:
• TDP is tolerant to message loss.
• TDP is geared toward mobility.
• Non-dependence of the diffusion on a static level by level transmission provides fault
tolerance and flexibility.
• TDP can be applied to both static and mobile sensor nodes.
• A network wide synchronization is achieved across all nodes and involves all the
nodes in the synchronization process.
22
• TDP can provide synchronization even without external time servers.

The disadvantages of TDP are as follows [SBK05]:
• Since no external precise time server is used, the convergence time tends to be high.
• Clocks can run backward if the clock value is suddenly adjusted to a lower value.
• In each active phase there are multiple cycles and each cycle has multiple rounds.
Moreover, in each round, multiple master nodes initiate a diffusion message broad-
cast. Thus the computational complexity is quite high.
2.3.10. Asynchronous Diffusion Protocol(ADP)

This is a rate based diffusion protocol. In order to have synchronization, the local clock
value of each node is exchanged with all the other nodes in the network. After that, the
nodes agrees to a consensus value and then each node adjusts its local value according to
the consensus value [SBK05].
ADP exhibits the following advantages [SBK05]:
• A system-wide equilibrium time across all nodes involved in a synchronization process
is achieved.
• ADP does not depend upon external time server or a synchronization leader.
• ADP provides robustness.
ADP exhibits the following disadvantages as well [SBK05]:
• ADP makes no provisions for manipulating clock skews in order to achieve synchro-
nization.
• The complexity of ADP is quite high compared to RBS. Many synchronization rounds
are needed to reach reasonable convergence and each node must communicate with
every other node in its neighborhood to achieve convergence.
• ADP makes an assumption that any two nodes can accurately swap their clock
readings when running their synchronization protocol. In practice, achieving that is
not easy.
• Clocks can run backward. If nodes adjust their clock values down, the clock values
obtained earlier will be repeated. This problem is deteriorated by the fact that nodes
can adjust their clock values independent of each other.
2.3.11. Fast Asynchronous Diffusion Protocol(FAD)

This protocol is an extended version of ADP. This algorithm is able to synchronize nodes
even if disconnection in network topology occurs [MB11].
FAD has the following advantages [MB11]:
• The average operation in this algorithm is not atomic, so average operations need
not to be sequenced although a node is involved in two or more operation groups
• FAD needs less number of rounds than ADP until convergence achievement is done.
That’s why FAD converges faster than ADP.
FAD displays the following disadvantages as well [MB11]:
• Since FAD spends more time than ADP in getting average value, FAD seems to be
less energy efficient.
• In terms of space complexity and time complexity, FAD shows less performance.
23
2.3.12. TSYNC
It provides network-wide synchronization. It has two versions [SBK05]:
1. Centralized version:
This is called Hierarchical Referencing Time Synchronization (HRTS).
2. Decentralized version:
This is called Individual Time Request (ITR) protocol,.
TSYNC shows the following advantages [SBK05]:
• Accurate.
• Lightweight.
• Flexible.
• Comprehensive
• This protocol manipulates the use of multi-channel radios to improve precision, re-
duce communication overhead and lower consumption of energy.
• This protocol can be easily extended to sensor networks that are devoid of multiple
channels.
TSYNC has the following disadvantages [SBK05]:
• Implementation of TSYNC at any layer above MAC layer could introduce more
imprecision.
• Implementation of TSYNC at any layer above MAC layer could introduce security
vulnerability.
Some time synchronization protocols are recently propsed. They are discussed as follows.
2.3.13. Optimized Time Synchronization protocols (OTSP)

OTSP is a new time synchronization protocol for wireless sensor networks. It is based on
transmitter-receiver synchronization approach. This protocol works in 3 phases [BT15]:
1. Neighbour Discovery Phase
This phase provides tables of neighbors to the base station (BS).
2. Center node localization phase
The center node is localized using the neighbors’ tables and a hierarchical tree is also
created.
3. Synchronization phase
A synchronization tree of lowest depth has been created. The center node syn-
chronizes the direct neighbors and from them a subset of coordinator nodes will be
selected. Then coordinators propagate the synchronization message and will again
choose another set of coordinators so that the process goes on. This process will go
on until synchronization of leaf nodes is done.
Working Principle
A given node in the network could be [BT15]:
1. Base Station (BS):

This is the main element in a network. BS initiates neighbor discover phase, which
is run by all nodes in the network. It is possible for nodes to identify their neighbors
and then put them in tables, which is finally sent to the BS. It also localizes the
center node.
24
2. Center node:
Based on the tables received from sensor nodes, a center node is localized by BS. A
center node has the highest degree and lowest depth (lowest number of hops from
BS). Center node is the root for the synchronization tree that will be constructed.
If a BS finds lots of nodes with highest degree and lowest depth, then it will choose
one of them as center node.
3. Coordinator nodes:
These nodes are designated by center node initially. Center node will designate
1-hop neighbors with highest degree as coordinator nodes, which will forward the
synchronization message. These coordinator nodes will then designate another set of
coordinator nodes that will propagate the synchronization message. This process will
end when leaf nodes get the synchronization message. In the beginning, center node
having level 0 will send messages to coordinator nodes having level 1. Then these
coordinator nodes will send messages to another set of coordinator nodes having level
2. In the end, coordinator nodes having level (n-1) synchronizes the leaf nodes.
4. Leaf nodes:
These nodes are located at the last level of synchronization tree. Only synchroniza-
tion of their clocks worry them.
The advantages of OTSP are as follows [BT15]:

• This method minimizes synchronization error.
• OTSP reduces energy consumption.
• OTSP reduces overhead.
• OTSP is superior compared to TPSN and RTSP in terms of energy efficiency, syn-
chronization tree depth and synchronization error.
• OTSP outperforms TSST only in terms of synchronization error.
2.3.14. Consensus Clock Synchronization(CCS)

CCS algorithms attempts to achieve internal consensus within a network. The internal
consensus is based on reaching an agreement upon what the time is and how fast it does
travel. In each round of synchronization, the compensation parameters for each node
are updated and over a certain period of time, the network clocks finally converge to a
consensus or agreed value[MOT12].
The consensus clock is a virtual clock . When network nodes run the CCS algorithm, this
virtual clock is generated which has its own offset and skew rate relative to the absolute
time of a physical clock.
In each synchronization round, two major tasks take place [MOT12]:
1. Skew compensation
• Results from current and previous synchronization round are compared by each
node to improve its skew compensation parameter.
2. Offset compensation
• Local clock readings between nodes are exchanged. This exchange of clockvalue
allows the nodes to get synchronized to a common time.
CCS algorithm exhibits the following advantages [MOT12]:
25
• Computationally light, scalable, robust to link and node failure.

• CCS requires as few as one transmission per node, per synchronization round. So
this protocol is energy efficient.
• Distant nodes will converge over time to a common consensus.
• No requirement for master or reference clock.
• CCS is robust in case of mobility and failure of nodes.
• CCS provides internal synchronization which reduces the costs and hardware require-
ments that are involved with a battery.
• CCS works well with increasing network size.
• Synchronization is maintained for longer periods of time.
However, there are some disadvantages as follows [MOT12]:
• In order to correct clock drift over time, continuous skew adjustment is needed
• CCS works well with spatially closely located nodes.
2.3.15. Syncob: Collaborative Time Synchronization

Syncob can synchronize an arbitrary number of nodes. It does not need any infrastructure,
protocol overhead or master node. This protocol is mostly suitable for ad-hoc communi-
cation networks [KBDR07].
The advantages of Syncob are as follows [KBDR07]:
• Works well with mobile settings.
• Synchronizes an arbitrary number of nodes.
• Since Syncob needs only local knowledge, it avoids energy consuming protocol over-
head through packet exchange for coordination.
• With high synchronization accuracy, Syncob is well suited for fusion and coordination
of WSN.
• Does not need any master node.
• Shows low complexity for hardware and software.
Syncob has the followin disadvantage [KBDR07]:
• Syncob is implemented on physical layer only.
26
2.4. Comparison among time synchronization protocols 27
2.4. Comparison among time synchronization protocols

The comparison and evaluation of various time synchronization protocols are done here.
Before evaluating the protocols, the criteria, which will be used for comparing the pro-
tocols, should be discussed in details. This work will divide evaluation criteria into two
groups namely, quantitative and qualitative evaluation.
Quantitative evaluation includes the following aspects:
1. Synchronization precision
2. Piggybacking
3. Computational complexity.
4. Convergence time.
5. Network Size.
6. Compatibility with sleep mode.
Qualitative evaluation includes the following aspects:
1. Scalability
2. Accuracy
3. Energy efficiency
4. Overall complexity
5. Fault tolerance
Now each of these aspects is discussed in details below.
2.4.1. Quantitative Evaluation

• Synchronization precision:
The physical clock of each sensor node consists of hardware oscillator circuits. How-
ever the frequency of oscillation is different for each sensor node. That is why the
clock values, used for time synchronization in WSN, are not physical clock readings.
Instead, networks nodes use a logical notion of clocks. Modification of logical clocks
can be done by hardware (e.g. by the physical clocks) and hardware (e.g. during
time synchronization). Synchronization precision can be defined in the following two
ways.
– Absolute precision: The maximum error (e.g. offset and skew) of the logical
clock of a node with respect to an external standard time source (e.g. UTC).
– Relative precision: The maximum deviation among the logical clock values of
the sensor nodes in a wireless sensor network.
In this work, the notion of relative precision is used. High synchronization precision
is a desirable feature in every synchronization protocol. However, high precision
comes at the expense of high computational cost, more storage requirement and
more number of exchanged messages among sensor nodes.
• Piggybacking:
This is the process of accumulating the acknowledgement messages that carry syn-
chronization data among nodes. In lieu of sending individual acknowledgement mes-
sages, these messages are piggybacked, in order to reduce the message traffic in the
27
network. Since wireless networks often suffer from severe bandwidth limitations, pig-
gybacking mitigates the communication demand on the network. Moreover, it also
cuts down the storage requirements on network nodes. Romer’s protocol and TPSN
use piggybacking.
• Computational complexity:
Since wireless networks often suffer from limited hardware capacity and severe energy
constraints, the complexity level of a synchronization protocol is very important to
know. A highly complex protocol might be unsuitable for many applications. In this
work, the computational complexity of a protocol (run-time and memory require-
ments) is differentiated from message complexity (number of exchanged messages
during synchronization).
• Convergence time:
This is the time required for synchronizing a network. If a protocol needs a large
number of exchanged messages per synchronization, then it will result in long con-
vergence time. In order to make a protocol cost efficient, the message complexity
has to be reduced. Since convergence time dependent on message complexity and
bandwidth usage, low convergence time is a highly desirable feature in wireless net-
work.
• Network size:
The empirical evaluation of the synchronization protocols on the actual sensor net-
works has been done by some authors. This information is unavailable for most of
the protocols studied yet. TPSN can handle neighborhoods with of up to 300 nodes.
• Compatibility with sleep mode:
In order to meet the energy requirements, the ability to go to low power (sleep) mode
is crucial. The nodes have to be synchronized and have to remain active only when
the application needs. RBS shows this feature by using post facto synchronization.
Table 2.3 compares various time synchronization protocols in terms of the quantitative
performance. The data for precision is taken from [RN10],[Yan12].
Different protocols are suitable for different conditions.
2.4.2. Qualitative Evaluation

A broader and more general perspective is provided by qualitative study of time synchro-
nization protocols.
• Scalability:
The scope of a network is the geographic span of the synchronized nodes. It can be
broadened by increasing the number of nodes in a wireless sensor network. Nowa-
days, the sensors are becoming cheaper thus making the wireless sensor networks
as large as possible. There can be over 10,000 sensor nodes in a network. That’s
why synchronized protocols must be highly adjustable with respect to the increasing
network size. Some protocols place scalability on the op of the list of priorities.
• Accuracy:
It is a measure of how well the maintained time in the network is true with respect
to the standard time. In other words, it is a measure of synchronization precision.
A protocol with high accuracy is highly desirable since it also ensures high precision.
For absolute precision, it means that the synchronized time in the network is deviat-
ing very much less from the external standard (UTC or GPS). For relative precision,
it means that, for a set of synchronized nodes, the maximum deviation of the clock
of any node is very small.
28
2.4. Comparison among time synchronization protocols 29
Protocols Precision Piggy- Convergence Complexity Network Sleep

backing Time Size Mode
RBS 29.1 µs N/A N/A High 2-20 Yes
nodes
Romer 3 ms Yes N/A Low Unknown Yes
TPSN 16.9 µs No Unknown Low 150-300 Yes
nodes
FTSP 1.5 µs Unknown Unknown High - -
DMTS 32 µs Yes High(multi- Low Unknown No
hop)
TDP 100 µs No High(multi- High 200 Yes
hop) nodes
Probabilistic Unknown Unknown N/A High Unknown Yes
Tiny-Sync 10.78 µs No High(multi- Low N/A Yes
Mini-Sync hop)
Asynchronous Unknown No High(multi- High 200-400 Yes
Diffusion hop) nodes
Mock et al 150 µs No Low High Unknown No
Table 2.3.: Quantitative performance comparison of various time synchronization protocols

[RN10],[Yan12].
• Energy efficiency:
Energy efficiency is the most important feature in most sensor networks. The require-
ment of energy efficiency varies with applications. For instance, a sensor network
with strict energy consumption will force the nodes to go to sleep mode as frequently
as possible, thus limiting the energy available for time synchronization. The prime
reason behind the energy constraint in the networks is the small size of the batteries
in sensor nodes, which greatly limits the amount of energy that can be stored and
used. There is an important tradeoff between use of the available energy to commu-
nicate or compute. In case of sensor networks having radio frequency transmitters
and receivers, the energy needed to communicate is far greater than that needed to
compute. The CPU also shuts down often to save energy.
• Overall complexity:
It is a combination of communication overhead, overhead due to fault tolerance and
algorithmic complexity. Highly accurate protocols very often suffer from high overall
complexity.
• Fault tolerance:
It shows the behavior of the protocol in case of node failure. Wireless media is error
prone. In many protocols, there are one or more special nodes with respect to which
other nodes get synchronized. If any of these nodes fails during synchronization
process, it can lead to the increase in the level of synchronization error until the
failed node is replaced. In the mean-time, nodes can waste both data and energy.
Any node is not regarded as robust unless the selection of a new special node does
not affect the synchronization process.
Table 2.4 compares various time synchronization protocols in terms of the qualitative
performance.
According to Table 2.4, different protocols are more suitable for different qualitative cri-
teria.
29
Protocols Energy Accuracy Scalability Overall Fault Toler-

Efficiency Complexity ance
RBS High High Good High No
Romer High Average Poor Low No
Mock et al Low High N/A Low Yes
TPSN Average High Poor Low Yes
FTSP High High Average - No
DMTS Very High High Good Low Yes
Probabilistic Unknown Unknown Good Low No
Tiny-Sync High High N/A Low Yes
Mini-Sync
TDP Average High Good High Yes
Asynchronous Low Unknown N/A High Yes
Diffusion
Table 2.4.: Qualitative performance comparison of various time synchronization protocols

[RN10],[Yan12].
2.5. Global Positioning System (GPS)

The Global Positioning System (GPS), is a space-based radionavigation system, that is
owned by the United States Government (USG) and is controlled by the United States
Air Force (USAF). GPS is a part of global navigation satellite system (GNSS) which can
deliver to a GPS receiver information regarding time and geolocation anywhere on earth
and in all weather conditions. However, the GPS receiver must have an unobstructed
line of sight to four or more GPS satellites (see Figure 2.5). The GPS system capable of
providing critical positioning capabilities to military, civil, and commercial users all around
the world. US government maintains the GPS system and has made it freely accessible to
anyone with a GPS receiver.[GPS]
Maximum of 32 satellites are allowed to circle around the earth. Each of these satellites
providess their time and own position on regular intervals to the earth. A GPS receiver
receives these informations sent by satellites and uses geometric calculation to estimate
the location of the receiver with respect to those satellites. Moreover, a GPS receiver
can also be used as an accurate time base. Since GPS receivers are comparatively cheap
and broadly available, time synchronization of any suitable device using GPS receiver has
become a very popular trend nowadays.[Bie15]
Working principle of (GPS)
GPS works in five steps as follows [tri]:
1. The basis of GPS is trilateration from satellites. Trilateration is the process of
estimating the relative position of the objects based on the geometry of triangles.The
mathematical method used to calculate position using multiple reference points. In
order for a GPS receiver to compute accurate position and time, it needs to be in
good view of at least 4 satellites in the sky. This is called a GPS lock or fix. We
all know how to use triangulation to calculate the distance to an object using two
reference points (x, y). However, with GPS, we need to determine 4 values, i.e.
latitude, longitude, elevation, and time.
2. Using the time taken by radio signals to travel, GPS receiver calculates the travel
distance which is necessary for trilateration.
3. Very accurate timing is needed to measure travel time of radio signals.
30
2.6. GPS receiver 31
Figure 2.5.: A visual example of 24 satellite constellation in motion with the rotating earth. Max-
imum 9 satellites are in line of sight with the GPS receiver in this case [GPS]
4. Knowledge about exact location of the satellites is necessary too.

5. The delays, experience by the signal while travelling though the atmosphere, must
be taken into consideration and corrected accordingly.
2.6. GPS receiver

A GPS receiver mainly has the following components [UAR]:
• Antenna interface.
• Digital Signal Processor (DSP).
• Microprocessor.
• Memory.
• Data interface
A block diagram of a typical GPS receiver is shown in figure 2.6.
The data interface of a GPS receiver could be USB, UART or CAN. Transport protocol
of UART is simple, resulting in less software overhead and high performance. The data
throughput on UART interface is almost similar to that of a USB interface.[UAR]
2.7. U-blox Neo-6M GPS Module

In this thesis u-blox Neo-6M GPS Module (see Figure 2.7) has been used which is cost
effective and provides optimum performance.The NEO-6 module series is a family of stand-
alone GPS receivers featuring the high performance u-blox 6 positioning engine. These
flexible and cost effective receivers offer numerous connectivity options in a miniature 16 x
12.2 x 2.4 mm package. Their compact architecture and power and memory options make
NEO-6 modules ideal for battery operated mobile devices with very strict cost and space
constraints [Neoa].
31
Figure 2.6.: Block diagram of a GPS receiver [UAR]
Figure 2.7.: NEO-6M GPS receiver module [ubl]
The 50-channel u-blox 6 positioning engine boasts a Time-To-First-Fix (TTFF) of under 1

second. The dedicated acquisition engine, with 2 million correlators, is capable of massive
parallel time/frequency space searches, enabling it to find satellites instantly. Innovative
design and technology suppresses jamming sources and mitigates multipath effects, giv-
32
2.7. U-blox Neo-6M GPS Module 33
ing NEO-6 GPS receivers excellent navigation performance even in the most challenging
environments.[Neoa]
2.7.1. Features [Ele]

• Standalone GPS receiver.
• There is a built in Ceramic antenna with strong satellite searching capabilities.
• Can set parameters via the serial port and save in EEPROM.
• Compatible with 3.3V level, making it easier to connect to any microcontroller.
2.7.2. Electrical specifications

Some operating conditions of NEO-6 GPS receiver module is shown in Table 2.5.
Parameter Min Typ Max Units

Power supply voltage 2.7 3.0 3.6 V
Antenna Gain - - 50 dB
Maximum supply cur- - - 67 mA
rent
Table 2.5.: Electrical specifications [Neoa]
2.7.3. Pin descriptions

NEO-6M GPS receiver module has five pins (see Figure 2.7). The functions of each of
these pins are according to Table 2.6.
Pin Number Pin Name Description

1 PPS Time Pulse output
2 RXD Rx. Connect to Micro-controller’s Tx pin
3 TXD Tx. Connect to Micro-controller’s Rx pin.
4 GND Connect to ground.
5 VCC Connect to 3.0V-3.3V.
Table 2.6.: Pin description of NEO-6M GPS module [Ele]
2.7.4. Connection to micro-controller board

The connection between the NEO-6M GPS receiver and a microcontroller is shown in
Figure 2.8.
Figure 2.8.: Connection between a microcontroller and a NEO-6M GPS receiver [Ele]
33
2.7.5. PPS
PPS is the abbreviation of 1 Pulse Per Second. This signal is synchronized at the rising
edge. The pulse is of duration 500ms [Neoa]. PPS pin is internally connected to an LED
in GPS receiver. By default there are two states in PPS signal [Ele]:
• Always on, which means that the module has started to work, but have not estab-
lished positioning yet.
• Flashing (100ms off, 900ms bright), which means that the module has established
successful positioning.
2.7.5.1. How to use PPS for time synchronization

PPS is an output pin. It generates a signal of duration 500ms which is less than a sec. The
rising edge of PPS is very close to the starting of a second in GPS. Utilizing this property,
PPS can be used as a time reference for many devices.PPS changes value on the 1 sec.
boundary for UTC (Universal Coordinated) time. When the PPS pin toggles once in a
second, then it becomes possible to synchronize the clock of a microcontroller to the GPS
clock. The polarity and length of the PPS signal is usually programmable in the GPS
[Jba].
2.7.5.2. A few notes on using PPS as a time reference:

When PPS is used as a time reference by an external device (such as a microcontroller),
there are few points which should be taken into consideration [Jba].
1. There are two measures of the PPS signal namely, signal accuracy and precision.
• Accuracy is the measure of how close the PPS signal edge is with respect to
the second of the actual UTC boundary. We want this value to be as low as
possible. Sometimes this value is within the range of few microseconds. This
error is usually fixed for a given firmware version.
• Precision is the measure of how much the PPS signal edge changes from one
second to the other. This value can range from 10’s of nanoseconds to the order
of few microseconds.
2. The PPS signal edge and rise time are very important if resetting of a counter is
needed. Large capacitance and long signal length can make the rise time slow. Slow
rise tim will add an offset the accuracy value. In order to cancel that, we will need
calibration. In case of noisy signal, the reset circuit might see more than one PPS
signal edge or a variable delay on the offset time where the resetting of counter takes
place.
3. Lots of GPS receiver have precision in the scale of 10’s of nanoseconds.Crystal oscil-
lators usually have errors in the range 20-100 ppm. In that case, those oscillators can
be calibrated using PPS. But the precision of GPS can not be guaranteed to be fixed.
This value can vary due to many factors which are not easy to measure. So, this
error due to precision can change from one PPS to the next. Using a median filter
or moving average of several PPS counts, the actual count value can be determined.
4. Viewing the sky clearly is one of the fundamental requirements for a GPS system
to work properly. If the GPS receiver is placed indoor or shielded then the problem
might worsen. Running the antenna of the GPS outside is a possible solution.
5. The GPS serial data isused to set the system date and time. The data com out of
the GPS some time usually from 100-500 ms after the PPS signal edge [Jba].
34
2.7. U-blox Neo-6M GPS Module 35
2.7.5.3. How to use PPS with STM32F4 Microcontroller:

The whole process takes place according to the folllowing sequence:
1. PPS signal is sent by GPS module.
2. Microcontroller takes it as an interrupt called external interrupt.
3. At each rising edge of the PPS, there is an interrupt.
4. The interrupt handler will send the GPS data to the computer.
2.7.6. GPS receiver output

• GPS receiver continuously provides timing and position information as output.
• This information is transmitted to and from the GPS receiver via a RS232 serial
interface.
• There are several message formats available to display GPS data over serial inter-
face.They are standard and non-standard(proprietary)message formats.
• NEO-6M GPS receiver uses NMEA protocol to display GPS data. This is the most
common message format as well.
• The NMEA protocol consists of a number of sentences as character strings, trans-
mitted according to the baud rate of the device(For NEO-6M it is 9600 bps).
• Each character string contains accurate time and position information.
• The PPS output combined with NMEA timing and positioning information, provides
a highly accurate timing reference for microcontrollers.
2.7.7. NMEA Protocol

NMEA messages sent by the GPS receiver are based on NMEA 0183 Version 2.3. The
NMEA messages appear in the form of a sentences. Each sentence contains different bits
of data in comma delimited format (i.e, data seperated by commas) [Neob]. A typical
NMEA message format is shown in figure 2.9.
Figure 2.9.: An example of NMEA protocol format
35
2.8. Communication Protocols

In order to exchange data between two embedded devices, they should share a common
communication protocol. Lots of communication protocols are available and they can be
classified into two categories: serial and parallel.
2.8.1. Parallel Communication

In every clock pulse multiple bits will be transmitted at the same time. Theses multiple
data bits will be transmitted or recieved through parallel channels [Tam].
Figure 2.10.: An example of parallel communication[JIM]
Figure 2.10 shows an example of parallel communication where 8 bits are transmitted with
every clock pulse.
Parallel communication has the following advantages over serial communication [Tam]:
• It has high data rate because of the ability to transmit/receive multiple bits at each
clock cycle.
• Straightforward
• Easy to implemenent
2.8.2. Serial Communication

Serial communication is the process of sending or receivin one bit at a time. Serial interfaces
stream their data, one single bit at a time. These interfaces can operate on as little as one
wire but never more than four [Tam].
Figure 2.11 shows an example of serial communication where each bit is transmitted with
every clock pulse.
36
2.8. Communication Protocols 37
Figure 2.11.: An example of serial communication [JIM]
Although parallel communication has some advantages over serial communication, it suf-
feres sevely from cross-talk and clock skew which ultimately affects the data rate. More-
over, parallel interfaces need lots of input/output(I/O) lines. But microcontrollers have
limited number of pins avalable. Hence, serial communication is preferred in exchanging
information with microcontrollers [Tam].
There are two modes of serial communication:
1. Asynchronous serial.
2. Synchronous serial.
2.8.2.1. Asynchronous serial
In this case, data bits are not synchronized with a clock signal. This transmission method
is perfect for minimizing the required wires and pins. There is no control over when data
is sent. In order to reliably transmit and receive data, asnchronous serial interfaces add
an extra start bit and an extra stop bit to each byte that helps the receiver remaining
synchronized with the incoming data from the sender (Refer to figure 2.12) [Tam].
Figure 2.12.: An example of asynchronous serial communication [Mik]
2.8.2.2. Synchronous serial
In case of synchronous serial communication, data bits are synchronized with clock pulses.
Here no additional start and stop bits are needed for synchrozing data between sender
and receiver. The clock signal, shared by all the devices on the serial bus, takes care
of that problem (see figure 2.13). This makes for a more straightforward, often faster
serial transfer, but it also requires at least one extra wire between communicating devices.
Examples of synchronous interfaces are SPI, and I2C [Tam].
37
Figure 2.13.: An example of synchronous serial communication [Mik]
2.8.3. Universal synchronous asynchronous receiver transmitter (USART)

A universal synchronous asynchronous receiver/transmitter (USART) is a block of cir-
cuitry that is responsible for implementing serial communication. Basically, the USART
is allowed as an intermediary between parallel and serial interfaces. On one end of the
USART is a bus of eight-or-so data lines (plus some control pins), on the other is the two
serial wires - RX and TX.
In USART communication, two USARTs are allowed to communicate directly with each
other. The sending USART first converts the parallel data from a controlling device like
a CPU or MCU into serial form, transmits the serial data to the receiving USART, which
then converts the serial data back into parallel data for the receiving device. Only two
wires are needed to transmit data between two USARTs. Data flows from the Tx pin of
the transmitting USART to the Rx pin of the receiving USART as shown in figure 2.14.
UART sends data asynchronously, which means there is no clock signal to synchronize the
output of bits from the transmitting UART to the sampling of bits by the receiving UART.
Instead of using clock signal, the sending UART adds extra start and stop bits to the data
packet being transmitted. These bits define the beginning and end of the data packet so
the receiving UART knows when to start reading the bits and when to stop doing that.
When the receiving UART detects a start bit, it starts to read the incoming bits at a
specific frequency known as the baud rate. Baud rate is a measure of the speed of data
transfer, expressed in bits per second (bps). Both UARTs must operate at about the same
baud rate. The baud rate difference between the transmitting and receiving UARTs should
be very small..
Both UARTs must also must be configured to transmit and receive the same data packet
structure.
2.9. Real-Time Clock(RTC)

The real-time clock (RTC), embedded in STM32F4 microcontroller, acts as an independent
Binary Coded Decimal (BCD) timer/counter.There are dedicated registers whuch hold the
value of the second, minute, hour (in 12/24 hour), week day, date, month, year, in BCD
38
2.9. Real-Time Clock(RTC) 39
Figure 2.14.: USART communication procedure
format. Correction for 28, 29 (leap year), 30, and 31 day of the month are performed
automatically.The RTC can provide a programmable alarm and programmable periodic
interrupts with wakeup from Stop and Standby modes. The sub-seconds alarm is also
available in binary format [STMd].
RTC is clocked by a 32.768 kHz external crystal, resonator or oscillator, the internal
low-power RC oscillator or the high-speed external clock divided by 128. The internal
low-speed RC has a typical frequency of 32 kHz. The RTC can be calibrated using an
external 512 Hz output to compensate for any natural quartz deviation [STMd].
Two alarm registers are used to generate an alarm at a specific time and calendar fields
can be independently masked for alarm comparison. To generate a periodic interrupt,
a 16-bit programmable binary auto-reload downcounter with programmable resolution is
available and allows automatic wakeup and periodic alarms from every 120 Î 14 s to every
36 hours [STMd].
A 20-bit prescaler is used for the time base clock. It is by default configured to generate
a time base of 1 second from a clock at 32.768 kHz [STMd].
39
2.9.1. RTC clock configuration

The RTC clock source can be one of the following [STMd] (see Figure 2.15 ):
• The HSE 1 MHz (HSE divided by a programmable prescaler)
• The LSE clock
• LSI clock
Figure 2.15.: STM32F4xx RTC clock sources [STMc]
In order to select RTC clock source, program the RTCSEL[1:0] bits in the RCC Backup
domain control register and the RTCPRE[4:0] bits in RCC clock configuration register
[STMd].
When LSE is selected as the RTC clock, the RTC will work normally even if the backup
or the system supply suddenly disappears. If the LSI is selected as the clock source, the
normal working state of RTC is not guaranteed if the system supply disappears [STMd].
The LSE clock is in the Backup domain,but the HSE and LSI clocks are not. So [STMd]:
• If LSE is selected as the RTC clock source:
– The RTC will continue to work even if the VDD supply is switched off, provided
the VBAT supply is maintained.
• If LSI is selected as the Auto-wakeup unit (AWU) clock:
– The AWU state is not guaranteed if the VDD supply is disconnected.
• If the HSE clock is selected as the RTC clock:
– The RTC state is not guaranteed if the VDD supply is disconnected or if the
internal voltage regulator is powered off (removing power from the 1.2 V do-
main).
40
2.9.2. RTC Calendar

A calendar contains track of the time (hours, minutes and seconds) and date (day, week,
month, year). Using RTC calendar, the clock RTC was synchronized with the clock of
GPS receiver. The STM32 RTC calendar includes the following features [STMc] :
• Calendar with (see figure 2.16):
– sub-seconds (not programmable).
– seconds
– minutes
– hours in 12-hour or 24-hour format
– day of the week (day)
– day of the month (date)
– month
– year
• Calendar is maintained in binary-coded decimal (BCD) format
• Automatic arrangement of 28, 29(leap year), 30, and 31 day in a month.
• Daylight saving time adjustment is also offered.
Figure 2.16.: RTC calender fields. RCTD R, RT CT R are RTC Date and Time registers.The sub-
second field is the value of the synchronous prescaler’s counter
A software calendar could be a software counter (usually 32 bits long) that represents/counts
the number of seconds. Software routines convert the counter value(the number of seconds)
to hours, minutes, day of the month, day of the week, month and year. This data can be
converted to both BCD format and Binary format and could be displayed on a standard
LCD [STMc], Also, the 12-hour format with an AM/PM indicator is also programmable
(see Figure 2.17).
Conversion routines consume considerable amount of memory and CPU-time making them
not useful in certain real-time applications. When using the STM32 RTC calendar, there
is no need for software conversion routines because their functions are done by hardware
[STMc].
The STM32 RTC calendar is provided in BCD format. This avoids an additional step
of binary to BCD software conversion routines, thus saving significant memory space and
CPU-load in real time applictions [STMc].
41
Figure 2.17.: Example of calendar display on an LCD [STMc]
2.9.3. How to adjust the RTC calendar clock

The RTC clock source can not be directly connected to the RTC calender. The RTC
clock requency has to be down-converted to 1Hz to make the RTC calender work. The
RTC features several prescalers that can be used to deliver a 1 Hz clock to calendar unit,
irrespective of the clock source. An example in shown in figure 2.18.
There are two types of presclaers available:
1. Synchronous prescaler.
2. Asynchronous prescaler.
Figure 2.18.: Prescalers from RTC clock source to calendar unit [STMc]
The formula to calculate ck − spre (which is equals to 1 Hz) is [STMc]:
RT CCLK
ck − spre = (2.11)
(P REDIVA + 1)(P REDIVS + 1)
whereas,
• RTCCLK can be any clock source: HSE, LSE or LSI

• P REDIVA is asychronous prescaler divisor and can be 1,2,3,..., or 127
• P REDIVS is sychronous prescaler divisor and can be 0,1,2,..., or 8191
Table 2.7 shows several ways to deliver 1 Hz frequency to the RTC calender.
RTCCLK Clock P REDIVA [6:0] P REDIVS [12:0] ck-spre

source
HSE = 1MHz 124 (div125) 7999 (div8000) 1 Hz
LSE = 32.768 kHz 127 (div128) 255 (div256) 1 Hz
LSI = 32 kHz 127 (div128) 249 (div250) 1 Hz
LSI = 37 kHz 124 (div125) 295 (div296) 1 Hz
Table 2.7.: RTC calendar clock equal to 1 Hz with different clock sources [STMc]
42
2.9.4. RTC alarms

RTC alarm configuration
STM32 RTC has two similar alarms, alarm A and alarm B. An alarm can be generated at
a given time or/and date based on the programming by the user.
The STM32 RTC delivers a rich combination of alarms settings, and offers many features.
So it becomes comparatively easier to configure and display these alarms settings [STMc].
Each alarm unit (alarm A or alarm B) contains the following features [STMc]:
• Fully programmable alarm: sub-second, seconds, minutes, hours and date fields (see
Figure 2.19) can be independently selected or masked to provide a rich combination
of alarms.
• Ability to exit the device from low power modes when the alarm occurs.
• The alarm event can be routed to a specific output pin with configurable polarity.
• Dedicated alarm flags and interrupt.
Figure 2.19.: Alarm A fields [STMc]
An alarm comprises a register with the same length as the RTC time counter. When the
RTC time counter reaches the value programmed in the alarm register, a flag is allowed
to set to indicate the occurance of an alarm event.
The STM32 RTC alarm can be configured by hardware to generate various types of alarms.
The desired alarm event can be configured by using the MSKx bits (x = 1,2,3,4) of the
corresponding alarm register.
Some possible alarm settings are shown in Table 2.8. For all possible alarm settings please
refer to table 2.19
2.9.5. RTC alarm sub-second configuration

The STM32 RTC unit provides programmable alarms, sub-second A and B, which are
similar. They generate alarms with a high resolution (for the second division) as shown in
Figure 2.20.
The value programmed in the Alarm sub-second register is compared to the content of the
sub-second field in the calendar unit [STMc].
The Alarm sub-second can be configured using the mask ss bits in the alarm sub-second
register. shows the configuration possibilities for the mask register and provides an example
with the following settings [STMc]:
43
MSK3 MSK2 MSK1 MSK0 Alarm behaviour

1 0 0 1 Weekday and seconds do not matter in alarm compar-
ison
1 0 1 0 Weekday and minutes do not matter in alarm compar-
ison
1 0 1 1 Weekday,minutes and seconds do not matter in alarm
comparison
1 1 1 1 Alarm occurs every second
Table 2.8.: Some possible RTC alarm settings [STMc]
Figure 2.20.: Alarm sub-second field [STMc]
• LSE is selected as the RTC clock source (for example LSE = 32768 Hz).
• The Asynchronous prescaler is set to 127.
• The Synchronous prescaler is set to 255 (the Calendar clock is equal to 1Hz).
• The alarm A sub-second is set to 255 (255 is put in the SS[14:0] field).
44
3. System description
The main task of this thesis is divided intwo two parts: the first part is to choose an
algorithm from the protocols that are mentioned in 2.2 or to develop an optimum time
synchronization algorithm that will fulfill the specific requirements needed in order to
monitor overhead powerlines. The second one is to test the desired algorithm and evaluate
its suitability to OLMS system. The system architecture of a sensor unit is shown in
figure 3.1. The architecture of OLMS is shown in figure 3.2 The software used to develop
this algorithm is IAR Embedded Workbench. This algorithm was run on two different
microcontrollers namely, Discovery kit with STM32F407VG MCU and STM32F429ZI-
EVAL, an evaluation board. Both of them are the two most powerful microcontrollers of
the family STM in terms of processing power. Two microcontrollers are needed to evalaute
and compare performance of two sensor units.
Figure 3.1.: Structure of a sensor unit. The yellow structure on the right side is the GPS receiver
In this chapter how the time synchronization algorithm that was programmed and imple-
mented in the two STM32F4 microcontrollers will be presented and discussed in details.
Besides how the NMEA protocol, used by GPS for serial communication with a microcon-
troller, works and how the detailed structure of the program will also be illustrated.
45
46 3. System description
Figure 3.2.: The proposed sensor network architecture in this thesis
3.1. Reasons behind choosing GPS receiver as time source

In the chapter 2.3, the state of art of the time synchronization algorithm has been discussed.
Neither of them is suitable to be applied to a sensor network for OLMS. The reason for
this is explained in this section.
In the proposed architecture of the sensor network, there will be an arbitrary number
of sensor units deployed, each having its own processing unit. There could be a large
seperation between these microcontrollers. In traditional time synchronization algoritm,
usually a microcontroller is made the master node and the other microcontrollers are made
the slaves of the master. But doing this will not be a wise idea in this case case because
of the following reasons:
1. If a microcontroller is made the master node, then it will act as the master clock.
The other microcontrollers will act as the slave clock and they will try to synchronize
their time based on the clock of the master. But in that case, it is not easy to be
46
3.2. An innovative time synchronization algorithm 47
sure about the type of connection to be used between the master and its slaves. It
is mainly because there could be minimum 300 m between sensor units along a line
that can be around 20 km between each processing units. So, one possibility could
be wired connection such as optical fibers. But fibers are expensive. Moreover, they
could be damaged quite easily due to pressure, bad weathers etc. We want to make
our optimum in terms of both performance and cost. So, wired connection is not a
solution. Then the only possibility remains is to use a wireless connection. But there
could be significant delay involved in between transmission of time information from
master clock and reception of that information by the slave clocks. So the amount of
deviation in time among sensor unit clocks could be very high. That is why, making
a microcontroller as the master node will not produce optimum performance for our
proposed sensor network.
2. Secondly, we want flexibility in our system. Since an arbitraty number of sensor units
will be deployed, each of them is supposed to act on its own. Therefore, the optimum
option in that case is to use a GPS receiver which is able to receive time information
from a global source of time (such as UTC or GMT). A good GPS receiver is able
to receive time information from the satellites that are constanly rotating around
the atmosphere. So even in harsh and hostile conditions, a GPS receiver is able to
receive data and send it to an external device (in our case the external device is
a microcontroller). Each microcontroller will have its own GPS receiver. So each
sensor unit will be synchronized with a global time source at all times and does not
have to depend on other sensor units for time synchronization which can offer great
flexibility in terms of system complexity. Moreover, a GPS receiver also takes care
of the amount of delay involved in receiving clock information from the satellites.
Hence, making a GPS receiver as the master clock and the attached microcontroller as its
slave clock for each sensor unit offers more advantages over making a single microcontroller
as the master clock and all other microcontrollers as its slave.
3.2. An innovative time synchronization algorithm

In this section, an innovative time synchronization algorithm that is developed spefically
for synchronizing time among remotely located sensor units in the above mentioned sensor
architecture will be discussed. Moreover, the reason for using this newly developed algo-
rithm and discarding the alraedy discussed other time synchronzation protocols will also
be explained as well.
3.2.1. Reasons behind choosing this algorithm

There are number of reasons for developing this new algorithm.
Since a GPS is used as master clock of the system, an especial time synchronization
algorithm must be chosen, which has the following charactersitics:
1. The communication occurs in only one direction (from GPS to SU)
2. The algorithm does not work with synchronization packets but use the PPS signal
and clock data sent by the serial.
Neither of the time synchronization protocols described before can fulfill these require-
ments. Therefore, an application-specific-algorithm was developed.
The RTC clock is set based on the GPS time update available. It is known that each second
the PPS signal arrives with the updated information about time which is nothing but the
update in second. Now if the RTC clock is set every second, that does not make the system
47
efficient in terms of energy consumption. It is desirable to lower energy consumption as

much as posible without influencing the performance of the sensor network. It can be
easily done if instead of setting RTC clock with each incoming PPS signal, the RTC clock
is set after a certain interval of PPS pulses. For example, the RTC clock is set in every 10
sec. That means in every 10th PPS signal , the GPS time is updated and set the clock of
RTC. And when the tests were conducted, the algorithm was developed based on waiting
period of 10 PPS pulses. However, the exact waiting period depends upon the drift of the
RTC clock. Hence it is possible to wait until a drift of 1 second in between the RTC clock
and GPS clock takes place.
48
3.2.2. Implementation of the time synchronization algorithm
The proposed algorithm works in the following sequence as shown in Figure 3.3.
Figure 3.3.: The flow chart of proposed time synchronization algorithm. Here tw stands for time
to wait.
1. PPS signal:
In each second, an external signal from the GPS receiver through the Pulse per
second (PPS) pin will be received by a GPIO pin in the microcontroller. This PPS
signal will contain updated information about time. In each rising edge of the PPS
signal there will be an external interrupt in the microcontroller.
2. Counter/Timer reset:
With the reception of each PPS signal, a timer will be reset. The frequency of this
49
timer is to be 1 KHz so that this timer produces a counting tick in each 1ms. We
are doing this so that we have our own definition of subseconds.
3. GPS update and RTC clock set:

The program will update the GPS time and then set the clock of the microcontroller,
called the RTC clock, according to the received GPS time with the reception of PPS
signal. But this updating of GPS time and RTC clock will not take place with each
received PPS signal. There will be certain time interval involved in between two
conecutive updating of GPS time and RTC clock. That means we will not update
GPS time and set RTC clock every second, but after a certain interval of time tw.
For better understanding of the reader, an example diagram of this new algorithm is
shown in Figure 3.4. In the image is shown an example where the time interval between
two consecutive GPS time update and RTC clock set (tw) is six PPS rising edges.
Figure 3.4.: The proposed time synchronization algorithm
It is needed to seperate the calculation of seconds from that of subseconds. The GPS
receiver that we are using provides time information only upto the scale of seconds. But
it is desirable to have more finer resolution in time, in the scale of subseconds which could
be ms, µs or ns. In order to differentiate among different events occuring at the same,
calculation in the scale of subsecond is needed. That is why, a timer was reset at the
starting of a second( the arrival of PPS signal every second). PPS singal is used as a time
reference since the start of a new second is very close to the corresponding rising edge of
the PPS signal. A timer of 1 KHz frequency is used which produces a tick (a count) in
each 1ms. So, in 1 second there will be 1000 ticks starting from 0 ms upto 999 ms. With
the start of the next second, the subsecond value starts from 0 ms again and reaches upto
999 ms. So the start of the a new second is ensured by the incoming PPS signal each
second whereas the start of the range of subsecond values is ensured by resetting a timer
at the same instant a PPS signal arrives (see Figure 3.5).
The pseudocode of the proposed time synchronization algorithm is 10:
50
Figure 3.5.: Seperation of second from subsecond
Algorithm 1 An innovative time synchronization algorithm

Require: PPS signal, RTC clock, A timer (TIM5) of 1KHz frequency
f = 1KHz
PPS signal received at any instant(v=1)
Reset TIM5
Wait for 10 PPS time duration
Ensure: v = 10
if v = 10 then
Update GPS hour, minute, second.
RT Csecond ← GP Ssecond
RT Cminute ← GP Sminute
RT Chour ← GP Shour
end if
3.2.2.1. NMEA Messages Overview

In the theis, GPS was programmed to return the following 4 NMEA statements [Neob] as
shown in Table 3.1.
NMEA Standard Messages Description

GGA Global Positioning System Fix Data
GSA GPS DOP and Active Satellites
GSV GPS Satellites in view
RMC Recommended minimum specific
GPS/Transit data
Table 3.1.: Used NMEA standard messages
1. GGA returns the current time.

2. GSA returns the range of the satellites in view.
3. GSV returns the id of the satellites in view.
4. RMC returns the current date.
51
4. Results
In this chapter the tests, conducted with the two microcontrollers, are properly explained
along with results of these tests. The order of these tests are organized in the same way the
requirements on time synchronization protocols of wireless sensor networks are introduced
The tests were conducted to check the suitability of the proposed time synchronization
algorithm in the OLMS.
4.1. Test Environment

The test environment is shown in figure 4.1. It is to be noticed here that two microcon-
trollers were sharing the same GPS receiver. Moreover, even if each microcontroller had its
own GPS receiver, the results of the conducted tests would have been similar.This is based
on the assumption that if two different GPS modules were used, probably each of them
would have its own errors. The IAR Embedded Workbench software, installed in a per-
sonal computer, was used to program the proposed algorithm in these two microcontrollers
and check the performance evaluating parameters. Using more microcontrollers will also
provide results in the similar range as that have been obtained with two microcontrollers.
Figure 4.1.: The test setup for performance evaluation
53
54 4. Results
4.2. Test Results
In this section, the results obtained through the tests will be discussed and analyzed .
4.2.1. Time needed to reset counter/timer
An extra timer(TIM 1) of 168 MHz frequency was used to calculate the amount of time
needed to reset the timer(TIM 5) of 1 KHz frequency asscoiated with the arrival of each
PPS signal. A timer of 168 MHz frquency was used for counting because that corresponds
to the frequency of the system core clock. At first, TIM 1 counter register value was checked
just before and just after the TIM 5 was reset. The difference in the counter register values
at these two instants was divided by the frquency of TIM 1 (which is 168MHz) to obtain
the time needed to reset TIM 5.
This processing time for two microcontrollers are shown in Table 4.1. The resetting time
was same for both microcontrollers. The pseudocode of the processing time needed to
reset a timer is 16:
Algorithm 2 Calculate processing time needed to reset a timer/counter of 1KHz frequency

(TIM5)
Require: Another timer of 168MHz frequency(TIM1)
f = 168M Hz
Check the value of TIM1 counter register for first time
F irstvalue ← x
Reset TIM5
Check the value of TIM1 counter register for again
Secondvalue ← y
Find out the difference (d1 ) in counter regsiter values
if x < y then
d1 ← y − x
else if x > y then
d1 ← (65535 − x) + y
else
d1 = 0
end if
Calculate processing time (t1 )
t1 ← d1 /f
∆N
Pocessing time = (4.1)
f
Here ∆N is the difference in counter register values at two instants and f is the frequency
of the timer used for counting.
Microcontrollers Time needed to reset counter

STM32F407VG 130.95ns
STM32F29ZI 130.95ns
Table 4.1.: Comparison of processing time needed to reset timer/counter in two microcontrollers
54
4.2. Test Results 55
4.2.2. Processing time needed to update GPS and set RTC seperately
Again TIM 1 was used for measuring time. The value of the counter register was checked
just before and just after updating the GPS data. The same technique is also used when
RTC clock was set based on the obtained updated GPS data. Table 4.2 shows the calcu-
lated values.
Microcontrollers Time needed to update Time needed to set

GPS RTC
STM32F407VG 56.53 µs 30.54 µs
STM32F29ZI 70.77 µs 36.89 µs
Table 4.2.: Comparison of processing time needed to update GPS and set RTC seperately in two
microcontrollers
The pseudocode of the processing time needed to update GPS and set RTC is 25:
Algorithm 3 Calculate processing time needed to update GPS and set RTC
Require: A timer of 168MHz frequency(TIM1)
f = 168M Hz
PPS signal received at any instant(v=1)
The tests were conducted using 10s of waiting time
Some other value could also have been used
Wait for 10 PPS time duration
Ensure: v = 10
if v = 10 then
Check the value of TIM1 counter register for first time
F irstvalue ← x
Update GPS hour, minute, second.
RT Csecond ← GP Ssecond
RT Cminute ← GP Sminute
RT Chour ← GP Shour
Check the value of TIM1 counter register for again
Secondvalue ← y
Find out the difference (d1 ) in counter register values
if x < y then
d1 ← y − x
else if x > y then
d1 ← (65535 − x) + y
else
d1 = 0
end if
end if
Calculate processing time (t1 )
t1 ← d1 /f
The deviation in processing time to update GPS was more than the deviation in processing
time to set RTC clock for STM32F407VG and STM32F429ZI microcontrollers. The time
needed to set RTC clock in two different microcontrollers was different since the crystal
oscillators running the RTC clocks in those microcontrollers were oscillating at different
frequencies.
55
56 4. Results
4.2.3. Total processing time needed to update GPS and set RTC
Table 4.3 shows the total processing time needed to update GPS and set RTC clock in
STM32F407VG and STM32F429ZI microcontrollers.
Microcontrollers Time needed to update GPS & set RTC
STM32F407VG 87.07 µs
STM32F29ZI 107.66 µs
Table 4.3.: Comparison of processing time needed to update GPS and set RTC in two
microcontrollers
4.2.4. Clock Offset

Clock offset is defined as the difference in time between two local clocks (see equation
4.2). In this case, it will be the processing time difference between two microcontrollers
to update GPS and set RTC calendar. It is a relative measure of how much deviation is
involved in clock values of two sensor units at any instant.(See equation 4.2)
Clock Offset = 107.66µs − 87.07µs = 20.9µs (4.2)
4.2.5. Synchronization Precision

It can be of two types:
• Absolute precision
• Relative precision
4.2.5.1. Absolute Precision

In this case, absolute precision is the maximum error(deviation in time) between each
microcontroller and the GPS receiver.
There are three sources of error involved.
• Processing time to update GPS and set RTC.
• Time needed to reset the timer/counter.
• Accuracy for time-pule signal (30ns).
Accuracy for time-pulse signal is the time taken by the GPS receiver clock to read the
clock of the satellite. Absolute precision is the sum of all these 3 errors (Refer to Table
4.4).
Microcontrollers Absolute Precision

STM32F407VG 87.23095 µs
STM32F29ZI 107.82095 µs
Table 4.4.: Comparison of absolute precision in two microcontrollers
4.2.5.2. Relative Precision

Relative precision is the maximum deviation among local values. In this case, it would be
the difference in absolute precision in between two microcontrollers( see equation 4.3). It
is to be noted that clock offset and relative precision share the same value.
Relative Precision = 107.82095µs − 87.23095µs = 20.9µs (4.3)
56
4.2.6. Clock Skew

Clock skew is defined as the difference in frequency between two RTC clocks. In order to
measure the frequency of a RTC clock, an alarm of 250ms duration was generated. Since
the pulsewidth of that alarm should be 250ms, hence the period of that alarm signal should
be 500ms and the frequency will be the inverse of that period i.e. 2 Hz.
But, since the RTC clocks are controlled by crystal oscillators inside. These oscillators
are not perfect. So, they oscillate at a frequency different than they are supposed to be.
Therefore there is deviation in frequency involved as shown in Table 4.5.(see figure 4.2,
4.3, 4.4)
Figure 4.2.: Comarison of RTC frequency of two microcontrollers
Microcontrollers RTC alarm frequency Deviation

STM32F407VG 2.097 Hz + 0.097 Hz
STM32F29ZI 1.930 Hz -0.07 Hz
Table 4.5.: Comparison of frequency of RTC clocks in two microcontrollers
57
58 4. Results
Figure 4.3.: Snapshot of RTC alarm signal for STM32F407VG MCU
Figure 4.4.: Snapshot of RTC alarm signal for STM32F429ZI MCU
58
Using equation 4.4, the value of clock skew was found to be 0.167 Hz which is a reasonable
value for time synchronization in OLMS system.
Clock Skew = 0.097Hz − (−0.07Hz) = 0.167Hz (4.4)
Using equation 2.9 it is possible to verify the already obtained clock skew value.
0.167 ≤ 1.000001 (4.5)
So the obtained clock skew value is within the maximum limit.
4.2.7. Power Consumption
In Table 4.6 the power consumed by each microcontroller and GPS setup is calculated by
multiplying the mean of current cosumption by the voltage of the corresponding micro-
controller. Then when the tests were conducted with two microcontrollers parallely along
with the single GPS receiver, the power consumed by the whole setup is also calculated.
Micro- Micro- GPS Current(Micro- Current Power Con-

controllers controller Volt- controller+GPS) Mean sumption
voltage age
STM32F407VG 5V 3V (0.13-0.16)A 0.145A 0.725W
STM32F29ZI 5V 3V (0.13-0.16)A 0.145A 0.725W
Combined 5V 3V (0.21-0.26)A 0.235A 1.175W
Table 4.6.: Comparison of power consumption in two microcontrollers seperately and combinedly
It is to be noted that,in the combined setup, both microcontrollers were sharing the same
GPS receiver. So in that occassion, current was consumed by only one GPS receiver. So,
based on this fact, we can calculate the current consumed by the GPS receiver,
Ctotal = C1 + C2 − Cgps (4.6)
whereas, Ctotal is the total current consumption when two microntrollers were used par-
allely =0.235A, C1 is the current consumption by STM32F407VG MCU along with the
connected GPS receiver =0.145A, C2 is the current consumption by STM32F29ZI MCU
along with the connected GPS receiver=0.145A, Cgps is the current consumed by the GPS
receiver only.
Using equation 4.6, the value of Cgps was found to be 0.055A. Hence, the power consumed
by GPS receiver was,
P ower = Vgps × Cgps = 3V × 0.055A = 0.165W (4.7)
Now it is possible to calculate power consumed by each microcontroller.
Power consumed by STM32F407VG = (0.725-0.165)W =0.56W.

Power consumed by STM32F29ZI = (0.725-0.165)W =0.56W
59
60 4. Results
4.2.8. Time interval between each GPS update

It depends on the amount of time needed until a drift of one second to take place in
between the RTC clock of the corresponding microcontroller and the clock of the GPS
receiver. Drift depends on two terms.
• Since the RTC clock frequencies of each microcontroller fluctuate from the ideal value
and it happens every time that alarm occurs, so this fluctuation is acculumated as
an error along time and plays a part in the drift between RTC clock and clock GPS
receiver.
• The processing time needed to update GPS and set RTC calender.
ErrorRTC = TRTC + Tdiff × t (4.8)
where,
ErrorRTC is the drift = 1 second;
TRTC is the processing time needed to update GPS and set RTC;
Tdiff is the deviation in the pulse width of RTC alarm signal from its ideal value;
t is the time interval between each GPS update.
Using equation4.8 the value of t was found for the two microcontrollers.
Microcontrollers Tdiff t Time interval between each

GPS update
STM32F407VG +9.1ms 109.88s 109s
STM32F29ZI -11.6ms 86.1976s 86s
Table 4.7.: Comparison of Time interval between each GPS update in two microcontrollers
Here we see that, waiting periods for two microcontrollers were not the same. Time in-
terval value is much higher for STM32F407VG MCU. In this sense, it is logical to assume
that STM32F407VG MCU is more energy conservative than STM32F429ZI MCU. This
is mainly because the frequency crytal oscillator driving the clock of the STM32F429ZI
MCU is fluctuating at a much higher rate than the crystal oscillator of STM32F407VG
MCU. This problem could be solved by recalibrating the crystal oscillators of each micro-
controllers.That means the STM32F429ZI MCU needs recalibration at a scale larger than
that in STM32F407VG MCU.
60
4.3. Analysis 61
4.3. Analysis
Now some aspects of the proposed time synchronization algorithm in the given sensor
network architecture will be analyzed in details as follows.
• Robustness
If we consider the whole system, there are an arbitraty number of sensor units each
having its own microcontroller and GPS receiver. So, even if one or more than one
GPS receiver and microcontroller fail, the time synchronization among other sensor
units will not be affected.
• Scalability
The whole sensor network can support an arbitrary number of sensor units as well.
Hence, it could be said that this new algorithm is highly scalable.
• System complexity
The proposed algorithm is very simple to implement. Moreover, providing individual
GPS receiver to each SU offers huge flexibility in terms of system complexity.
• Scope
The proposed algorithm provides common time scale for all sensor units in the net-
work since each SU works independently.
• Message complexity
It is simple. Since for each round of synchronization, only one directional message
transfer is needed (from GPS receiver to the microcontroller), that’s why the number
of exchanged messages is one.
• Network size
It depends on how many microcontrollers the protocol can support. Since an arbi-
trary number of SU is supported by this time synchronization protocol, henceit can
be said that the size of the network supported by this protocol is not limited by the
time synchronization algorithm developed in the master thesis.
• Convergence time
It is the time required for synchronizing the network. Convergence time depends on
the message complexity and bandwidth usage. Since one message transfer from GPS
receiver to microcontroller is needed for one round of synchronization, it can be said
that the network is synchronized every second.
• Piggybacking
The proposed algorithm does not offer piggybacking.
61
5. Conclusion and Outlook
5.1. Conclusion
In this thesis a time synchronization algorithm was developed to synchronize time among
the sensor units that are used to monitor the overhead power lines. The performance of
this algorithm was evaluated in order to check whether it fulfills the time synchronization
requirements of a WSN.
Since it is desirable that the developed algorithm will be suitable to work with any num-
ber of sensor units, hence the algorithm program was tested with two different microcon-
trollers. More microcontrollers could have been used for testing purpose, but the obtained
results would have been in more or less the same range as with two microcontrollers.
STM32F407VG and STM32F429ZI, both of them are high performance 32 bit ARM Cor-
tex M4 devices with FCU core.
The algorithm is energy efficient since the RTC clock of microcontrolllers is not set every
second. The time interval between each consecutive GPS update and RTC set was found
to be 86 seconds and 109 seconds for each microcontrollers. These values are satisfactory
for the deveolped system.
The clock offset and the relative precision among two microcontroller clocks were found
to be the same. A timer was reset every time an external PPS signal is received. In other
words, with the beginning of each second, a timer was reset to ensure that the start of a
new second corresponds to the starting of a new subsecond. Since the frequency of the
resetting timer was set to 1 KHz, hence the subseconds were restricted to millisecond scale
(starting from 0 ms up to 999 ms).
The deviation in processing time to update the GPS was more than the deviation in
processing time to set RTC clock for STM32F407VG and STM32F429ZI microcontrollers.
A precise timer was used to calculate the processing times for both microcontrollers. The
frequency of the timer was set equal to the frequency of the system, which is 168MHz. It
was done so that the obtained processing times become highly accurate.
Based on the waiting period between each GPS update criteria, it can be concluded that
STM32F407VG MCU is more energy efficient than STM32F429ZI MCU.
63
64 5. Conclusion and Outlook
5.2. Outlook
The performance of the overall system could be improved by using a GPS receiver which
provide much more accurate time information. In other words, a GPS receiver which is
used for timing purpose only. This type of receiver however, could be more expensive than
the one that has been used in this thesis. But the used NEO 6M GPS receiver has some
drawbacks. The PPS signal was not activated as soon as the GPS receiver was turned on.
Sometimes the waiting time was about 30 minutes which can affect the system performance
too much. Moreover, since the connection setup and tests were conducted inside a building,
there were instances when the GPS module was not receiving the updated data at the
expected data rate. Hence using the whole setup outside buildings or connecting a more
powerful antenna to the GPS receiver could solve these problems.
A microcontroller was used as a processing unit inside each sensor unit to process the
incoming data from sensors. It is comparatively easier to program microcontrollers. Al-
though microcontrollers provide satisfactory performance, there are more powerful pro-
cessing devices such as FPGA(Field Propagation Gate Array)available. Using such device
could improve the overall performance of the system.
Last but not the least, since each of these microcontrollers will be placed along overhead
power lines that carry high voltage, these voltage lines will have high temperature as
well. Hence, the attached microcontrollers will be affected by the high temperature unless
they are sorrounded by insulating materials. The sensor unit could be also installed on
the tower and not directly on the overhead line. Even though the ambient temperature
can affect the internal clock. Since, the clocks inside a microcontroller are driven by a
crystal oscillator, its stability is one of the most important charactersitics. Stability is
defined as the tendency of a crystal oscillator to stay at the same frequency over time.
Unstable oscillators will adversely affect the clock rate of a microcontroller. In order to
keep accurate clock rate of a microcontroller, recalibration could be done. As a refrence for
the calibration, the GPS data could be used since it is not be affected by the temperature
changes.
64
Bibliography
[Bie15] L. Bies. (2015) Time synchronization with a garmin gps. [Online]. Available:
https://www.lammertbies.nl/comm/info/GPS-time.html
[BM10] J. Bae and B. Moon, Time Synchronization in Wireless Sensor Networks. IN-
TECH Open Access Publisher, 2010.
[BT15] R. Beghdad and F. Tinsalhi, “Otsp: an optimised time synchronisation pro-
tocol for wireless sensor networks,” International Journal of Sensor Networks,
vol. 19, no. 3-4, pp. 217–233, 2015.
[Ele] G. Electronic, “User manual, u-blox neo-6m gps module,” GI Electronic.
[Online]. Available: http://www.gie.com.my/download/um/wireless/gps/um
gps.pdf
[GPS] Global positioning system. [Online]. Available: https://en.wikipedia.org/wiki/
Global Positioning System
[HLL+ 10] K. Hung, W. Lee, V. Li, K. Lui, P. Pong, K. Wong, G. Yang, and J. Zhong, “On
wireless sensors communication for overhead transmission line monitoring in
power delivery systems,” in Smart Grid Communications (SmartGridComm),
2010 First IEEE International Conference on. IEEE, 2010, pp. 309–314.
[Jba] Jbattles. Gps pps use as a time reference. [Online]. Available: http:
//mtnstormdaq.com/blog/2012/10/gps-pps-use-as-a-time-reference/
[JIM] JIMBO. Serial communication. [Online]. Available: https://learn.sparkfun.
com/tutorials/serial-communication
[KBDR07] A. Krohn, M. Beigl, C. Decker, and T. Riedel, “Syncob: Collaborative time
synchronization in wireless sensor networks,” in Networked Sensing Systems,
2007. INSS’07. Fourth International Conference on. IEEE, 2007, pp. 283–290.
[MB11] B. Moon and J. Bae, “A global time synchronization scheme for wireless sensor
networks,” in Grid and Distributed Computing. Springer, 2011, pp. 383–391.
[Mik] MikeGrusin. Serial peripheral interface (spi). [Online]. Available: https:
//learn.sparkfun.com/tutorials/serial-peripheral-interface-spi
[MKSL04] M. Maróti, B. Kusy, G. Simon, and Á. Lédeczi, “The flooding time synchroniza-
tion protocol,” in Proceedings of the 2nd international conference on Embedded
networked sensor systems. ACM, 2004, pp. 39–49.
[MOT12] M. K. Maggs, S. G. O’Keefe, and D. V. Thiel, “Consensus clock synchronization
for wireless sensor networks,” IEEE Sensors Journal, vol. 12, no. 6, pp. 2269–
2277, 2012.
[MPJ08] M. Muhr, S. Pack, and S. Jaufer, “Usage and benefit of an overhead line mon-
itoring system,” in High Voltage Engineering and Application, 2008. ICHVE
2008. International Conference on. IEEE, 2008, pp. 557–561.
65
66 Bibliography
[Neoa] NEO-6,u-blox 6 GPS Modules, Data Sheet.

[Neob] u-blox 6 Receiver Description.
[ove] Overhead power line. [Online]. Available: https://en.wikipedia.org/wiki/
Overhead power line
[Pin03] S. Ping, “Delay measurement time synchronization for wireless sensor net-
works,” Intel Research Berkeley Lab, vol. 6, pp. 1–10, 2003.
[RLK+ 09] I.-K. Rhee, J. Lee, J. Kim, E. Serpedin, and Y.-C. Wu, “Clock synchronization
in wireless sensor networks: An overview,” Sensors, vol. 9, no. 1, pp. 56–85,
2009.
[RN10] P. Ranganathan and K. Nygard, “Time synchronization in wireless sensor net-
works: a survey,” International journal of ubicomp, vol. 1, no. 2, pp. 92–102,
2010.
[SBK05] B. Sundararaman, U. Buy, and A. D. Kshemkalyani, “Clock synchronization
for wireless sensor networks: a survey,” Ad hoc networks, vol. 3, no. 3, pp.
281–323, 2005.
[STMa] UM1472 User Manual. Discovery kit with STM32F407VG MCU, STM micro-
controllers, DocID022256 Rev 5.
[STMb] UM1640 User Manual. Discovery kit with STM32F429ZI MCU, STM micro-
controllers, DocID025175 Rev 2.
[STMc] AN3371Application note.Using the hardware real-time clock(RTC) in STM32
F0, F2, F3, F4 and L1 series of MCUs, STMMicroelectronics, DocID018624
Rev 01.
[STMd] Datasheet.STM32F405xx,STM32F407xx, STMMicroelectronics, DocID022152
Rev 01.
[Tam] Y. Tambi. Serial communication-introduction. [Online]. Available: http:
//maxembedded.com/2013/09/serial-communication-introduction/
[tri] How gps works? [Online]. Available: http://www.trimble.com/gps tutorial/
howgps.aspx
[UAR] AN10353Application notel. Application of UART in GPS navigation system.
[ubl] U-blox neo-6m gps positioning module to serial ttl
rs232 - black. [Online]. Available: http://www.dx.com/p/
u-blox-neo-6m-gps-positioning-module-to-serial-ttl-rs232-black-312527#
.WLxrN L0-Qk
[Yan12] Y. Yang, “Time synchronization in wireless sensor networks: A survey,” 2012.
66
Appendix
A. List of Abbreviations
• MCU : Micro-Controller Unit
• SU : Sensor Unit
• GPS : Global Positioning System
• OLMS : Overhaed Line Monitoring System
• WSN : Wireless Sensor Network
• USART : Universal Synchronous Asynchronous Receiver Transmitter
• UART : Universal Asynchronous Receiver Transmitter
• UTC : Coordinated Universal Time
• GMT : Greenwich Mean Time
• PPS : Pulse Per Second.
• FPGA : Field Propagation Gate Array
• NMEA : National Marine Electronics Association
• RTC : Real-Time Clock
• HSE: High Speed External
• LSE: Low Speed External
• LSI : Low Speed Internal
• CPU: Central Processing Unit
67
68 Appendix
B. Software
The software is attached in a CD-ROM.
68
C. Hardware 69
C. Hardware
STM32F429ZI-EVAL: see the user manual [STMb].
STM32F407VG-Discovery Kit: see the user manual [STMa].
69
View publication stats

Thesis 1

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Thesis 1

Uploaded by

Copyright:

Available Formats

See discussions, stats, and author profiles for this publication at: https://www.researchgate.

Development of an optimal synchronization system for remotely located

Thesis · March 2017

The user has requested enhancement of the downloaded file.

At the Department of Electronics

Reviewer: Prof. Dr. rer. nat. Wilhelm Stork

Duration: 19. September 2016 – 18. March 2017

2.3.8. Tiny-Sinc and Miny-Sinc . . . . . . . . . . . . . . . . . . . . . . . . 22

4.2.5. Synchronization Precision . . . . . . . . . . . . . . . . . . . . . . . . 56

5. Conclusion and Outlook 63

1.1. Overhead power line in Gloucestershire, England. . . . . . . . . . . . . . . . 3

2.1. Behavior of slow, fast and perfect clock. . . . . . . . . . . . . . . . . . . . . 10

3.1. Structure of a sensor unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4.1. Configuration of the system when testing performnance . . . . . . . . . . . 53

1.1. Different Applications of WSN . . . . . . . . . . . . . . . . . . . . . . . . . 2

2.1. Classification based on synchronization issues . . . . . . . . . . . . . . . . . 14

3.1. Used NMEA standard messages . . . . . . . . . . . . . . . . . . . . . . . . . 51

4.1. Processing time needed to reset timer/counter . . . . . . . . . . . . . . . . . 54

1. The amount of maximum power transmitted could be limited.

1.1. An overview of Wireless Sensor Networks (WSN)

Table 1.1.: Different Applications of WSN [SBK05].

1.2. Time synchronization

1.3. Overhead power line

Figure 1.1.: Overhead power line in Gloucestershire, England [ove].

• It is easier to maintain overhead lines.

However, overhead power line shows some distadvantages as follows [MPJ08]:

• They are vulnerable to lightning strikes which can cause interruption.

• In tourism regions, they will be seen as an impairment of nature.

• The maintenance cost is high.

• The voltage drop in overhead lines is high.

1.4. Overhead Line Monitoring Systems (OLMS)

1.4.1. Components of a monitoring system

1. A measuring unit with power supply and data communication.

Figure 1.2.: Monitoring system scheme [MPJ08].

1.5. Use of sensors in OLMS

Figure 1.3.: An example of overhead transmission line [HLL+ 10].

• Height measurement sensor or sag sensor.

• Temperature measurement sensor.

• Rope tension measurement sensor.

• Phase angle measurement sensor.

1.8. Requirements on time synchronization protocols for Wire-

• Cost and size:

Before beginning the development of a time synchronization algorithm, it is necessary to

2.1. Related work

Ci (t) = (ai × t) + bi (2.2)

C1 (t) = (a12 × C2 (t)) + b12 (2.3)

Different kinds of errors are defined in equations 2.6, 2.7, 2.8 ,

Of f set, δ = C1 (t) − C2 (t) (2.6)

∂C1 (t) ∂C2 (t)

Here ρ denotes maximum skew rate and a typical value of it is 0.000001.

Figure 2.1.: Behavior of slow, fast and perfect clock [SBK05]

2.1.2. Sources of errors in time synchronization

2.2. Classification of time synchronization protocols

2.2.1. Synchronization issues

1. By synchronization of local clocks of each sensor nodes.

Different options are described below [SBK05].

2.2.1.1. Master-slave versus peer-to-peer synchronization

2.2.1.2. Internal synchronization versus external synchronization

2.2.1.3. Probabilistic versus deterministic synchronization

2.2.1.4. Sender-to-receiver versus receiver-to-receiver versus receiver-only syn-

• Sender-to-receiver synchronization (SRS):

2.2.1.5. Clock correction vs untethered clocks

2.2.1.6. Pairwise Synchronization versus network-wide synchronization [RLK+ 09]