Dissertation Title

advertisement
ZBeeMeR
A ZigBee Automatic Meter Reading System
André Duarte Monteiro Glória
Dissertation submitted to obtain the Master (MSc) degree in
Electrical and Computer Engineering
Jury
President:
Prof. Marcelino Bicho dos Santos
Supervisor:
Prof. Maria Helena da Costa Matos Sarmento
Co-Supervisor:
Prof. Mário Serafim dos Santos Nunes
Member:
Prof. Francisco André Corrêa Alegria
October 2010
ii
Acknowledgements
My first words of appreciation go to my supervisor Prof. Helena Sarmento, without her this
dissertation would never seen day light. I thank her for the patience, support, criticism, suggestions,
patience1 and time. To my co-supervisor Prof. Mário Serafim Nunes I thank him for sharing his
technological insight and market knowledge, and also for his continued support.
Other people directly helped in this dissertation. My many thanks to Bithium, namely António
Muchaxo for the discussions, ideas, support and access to Bithium’s resources, and Sérgio Martins
for the soldering tips and help with PCB corrections and testing. To Luís Silva for the PCB tips and
revision. Also to António Moreira for the explanations about antennas and EDP - Energias de
Portugal for providing the energy meters used in this work.
To all my friends and colleagues I thank their time, support, help and laughs, in better and worst
times, not only throughout this dissertation, but throughout my entire graduation journey.
Finally and more importantly, to my family that always believed in me and whom I deprived from
my attention several times. Your understanding, huge support and comfort is invaluable.
Many thanks to you all, you helped me more than you may realise.
1
Yes, patience appears twice and believe me when I say it is probably not enough.
iii
iv
Abstract
To produce and distribute power in a even more efficient manner, with high reliability and transparency, utilities are currently looking for more control over the electric grid and power demand.
Utilities also want to provide consumers with information that compels them to save energy. Automatic Meter Infrastructure (AMI) aims to solve this problem. AMI refers to a metering infrastructure
that automatically records and reports customer consumption, hourly or even more frequently in a
day.
This dissertation proposes a wireless solution, using ZigBee, to AMI over a building or neighbourhood. Hardware and software were developed to implement it. The infrastructure is supported
by a ZigBee mesh network, where energy meters are the nodes and an unique concentrator enables the communication between the meters and the utility. A ZigBee module was developed to
connect to the energy meter though an RS-232 interface and to implement the concentrator. The
software supports the hardware and the metering infrastructure. Access to the metering information
and interaction with the Wireless Sensor Network (WSN) can be done through a web interface.
A prototype with four nodes was set-up inside a building. ZigBee demonstrated to be a good
solution to implement the required bi-directional communications. Using Energy Meter Sensor
Nodes (EMSeNs) with routing capabilities and an unique concentrator to aggregate metering data,
permits to achieve a low cost system without reducing performance.
Keywords
PCB, Electronic Design, AMI, AMR, Smart Grid, ZigBee
v
vi
Resumo
Para produzir e distribuir energia eléctrica com grande eficácia, fiabilidade e transparência, os
operadores energéticos (utilities) pretendem actualmente ter um maior controlo sobre a rede eléctrica e o consumo de energia. Pretendem ainda fornecer informação aos seus clientes, para que
estes poupem energia. A Automatic Meter Infrastructure (AMI) pretende solucionar este problema.
Esta define uma infra-estrutura com contadores, que de forma automática registam e transmitem
o consumo de energia de hora em hora, ou de forma ainda mais frequente.2
Esta dissertação propõe uma solução sem fios, utilizando ZigBee, para implementar AMI num
edifício ou vizinhança. Foram desenvolvidos equipamentos e programas para a implementar. A
infra-estrutura é suportada numa rede (mesh) ZigBee, na qual os contadores são nós e um único
concentrador permite a comunicação entre estes e o operador de energia. Um módulo ZigBee foi
desenvolvido para comunicar via RS-232 com o contador e para implementar o concentrador. Os
programas desenvolvidos suportam tanto o módulo como toda a infra-estrutura de telecontagem.
O acesso aos consumos e a interacção com a rede de sensores pode ser realizada através de
uma página na internet.
Um protótipo com quatro nós foi instalado num edifício. O ZigBee demonstrou ser uma boa
solução para implementar a comunicação bidirecional necessária. O uso de contadores dotados
de ZigBee com capacidades de reencaminhamento de mensagens, aliado ao uso de um único
concentrador que agrega a informação dos consumos, permite obter um sistema de baixo custo
sem comprometer desempenho.
Palavras Chave
Circuito Impresso, Projecto de Electrónica, AMI, AMR, IEC 62056-21, Rede Eléctrica Inteligente,
ZigBee
2
Esta funcionalidade pode ser designada de telecontagem.
vii
viii
Contents
1 Introduction
1
2 ZigBee Technology
5
2.1 IEEE 802.15.4
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.1.1 The Physical Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.1.2 The Medium Access Layer . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.2 ZigBee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
2.2.1 The Network Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
2.2.2 The Application Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
2.3 ZigBee Pro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
2.4 6LoWPAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
3 ZBeeMeR System
15
3.1 ZBeeMeR Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
3.2 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
3.2.1 The ZigBee SoC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
3.2.2 Power System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
3.2.3 Antennas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
3.2.4 Serial Communication and Extra Memory . . . . . . . . . . . . . . . . . . .
22
3.2.5 Printed Circuit Board . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
3.3 Prototype
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
3.3.1 Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
3.3.2 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
3.4 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
3.4.1 Nodes Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
3.4.2 EMSeNs and Network Extender Nodes . . . . . . . . . . . . . . . . . . . .
29
3.4.3 Concentrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
3.4.4 Web Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
4 Tests and Results
4.1 Module Tests
35
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
4.2 ZBeeMeR Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
ix
5 Conclusions
43
5.1 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
References
44
48
Appendices
Appendix A ZigBee Solutions for Product Development
51
Appendix B Ni-MH and Li-ion batteries
63
B.1 Ni-MH batteries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
63
B.2 Li-ion batteries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
64
Appendix C PCB Project Dossier
67
C.1 PCB Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
68
C.2 Assembly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
71
C.2.1 Bill of Materials (BOM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
71
C.2.2 Component References . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
73
C.2.3 Top Component Placement . . . . . . . . . . . . . . . . . . . . . . . . . . .
74
C.2.4 Schematics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
75
C.3 Stencil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
78
C.3.1 Board Panel Stencil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
78
Appendix D Communications in the ZBeeMeR prototype
x
79
List of Tables
1.1 Comparison of technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
2.1 Frequency ranges, data rates and modulations. . . . . . . . . . . . . . . . . . . . .
6
3.1 ZigBee SoCs - Selection from the initial survey. . . . . . . . . . . . . . . . . . . . .
17
3.2 Comparison of Antenna Solutions. . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
4.1 Deviations from the centre channel frequency. . . . . . . . . . . . . . . . . . . . . .
37
4.2 Power measurements over a 1 meter distance. . . . . . . . . . . . . . . . . . . . .
39
4.3 Power measurements over a 2 meters distance. . . . . . . . . . . . . . . . . . . . .
39
4.4 Power measurements over a 5 meters distance. . . . . . . . . . . . . . . . . . . . .
39
A.1 ZigBee chip solutions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
52
A.2 Detailed information of ZigBee single chip solutions. . . . . . . . . . . . . . . . . .
53
A.3 ZigBee development kits. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
54
A.4 ZigBee modules and their features.
. . . . . . . . . . . . . . . . . . . . . . . . . .
61
C.1 Bill of Materials (BOM) − Supplier: Digikey . . . . . . . . . . . . . . . . . . . . . .
71
C.2 Bill of Materials (BOM) − Supplier: Farnell
. . . . . . . . . . . . . . . . . . . . . .
72
C.3 Component references and values. . . . . . . . . . . . . . . . . . . . . . . . . . . .
73
xi
xii
List of Figures
2.1 ZigBee stack architecture.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.2 Message flow in a Star network topology. . . . . . . . . . . . . . . . . . . . . . . .
7
2.3 Parent-Child associations in a Clustered Stars network topology.
. . . . . . . . . .
7
2.4 A superframe structure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
3.1 AMI based on a ZigBee mesh network. . . . . . . . . . . . . . . . . . . . . . . . .
16
3.2 The ZigBee module architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
3.3 ZigBee module’s power supply diagram. . . . . . . . . . . . . . . . . . . . . . . . .
20
3.4 Battery charging circuit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
3.5 Layer stack-up on a 4-layer PCB. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
3.6 Digital and analog separation on the PCB. . . . . . . . . . . . . . . . . . . . . . . .
23
3.7 Power connection through bypass capacitor.
. . . . . . . . . . . . . . . . . . . . .
24
3.8 The ZigBee module. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
3.9 Prototype Network Devices.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
3.10 ZBeeMeR Software Architecture − Protocols Involved. . . . . . . . . . . . . . . . .
26
3.11 ZBeeMeR Software Architecture − Exchanged Information. . . . . . . . . . . . . .
27
3.12 Software architecture of the ZigBee modules. . . . . . . . . . . . . . . . . . . . . .
27
3.13 EMSeNs and network extender nodes program flowchart. . . . . . . . . . . . . . .
30
3.14 Concentrator program flowchart − ZigBee module. . . . . . . . . . . . . . . . . . .
31
3.15 Concentrator program flowchart − PC. . . . . . . . . . . . . . . . . . . . . . . . . .
32
3.16 Web interface architecture overview. . . . . . . . . . . . . . . . . . . . . . . . . . .
33
3.17 Web Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
4.1 Module emissions over a 3GHz frequency span. . . . . . . . . . . . . . . . . . . .
36
4.2 Module unmodulated emissions. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
4.3 Module O-QPSK modulated emissions. . . . . . . . . . . . . . . . . . . . . . . . .
38
4.4 Prototype network structure with nodes location. . . . . . . . . . . . . . . . . . . .
40
C.1 PCB layers − Electrical connections and components. . . . . . . . . . . . . . . . .
68
C.2 PCB layers − Solder and solder mask pads.
. . . . . . . . . . . . . . . . . . . . .
69
C.3 PCB layers − Drills and component labels. . . . . . . . . . . . . . . . . . . . . . .
70
C.4 Component Placement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
74
C.5 Schematic (1 of 2). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
76
xiii
C.6 Schematic (2 of 2). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
77
C.7 Stencil. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
78
D.1 EMSeN association with the network concentrator. . . . . . . . . . . . . . . . . . .
80
D.2 EMSeN association with a network extender node. . . . . . . . . . . . . . . . . . .
81
D.3 EMSeN responding to a concentrator request.
. . . . . . . . . . . . . . . . . . . .
82
D.4 EMSeN performing a route request and then sending data. . . . . . . . . . . . . . .
83
xiv
Acronyms
AC
ACK
ADC
AES
AF
AMI
AMR
APL
APS
AODV
ARM
ASK
BOM
BPSK
CAP
CCM
CCM*
CFP
CRC-16
CSMA/CA
DC
DES
DLMS
DSSS
EMSeN
FFD
GPRS
GTS
GSM
HAL
ID
IETF
I/O
IP
Alternate Current
Acknowledgement
Analog-to-Digital Converter
Advanced Encryption Standard
Application Framework
Automatic Meter Infrastructure
Automatic Meter Reading
Application Layer
Application Support Sublayer
Ad hoc On-demand Distance Vector
Advanced Reduced Instruction Set Computing Machine
Amplitude Shift Keying
Bill of Materials
Binary Phase-Shift Keying
Contention Access Period
Counter with CBC-MAC
Extension of CCM
Contention Free Period
Cyclic Redundancy Check 16
Carrier Sense Multiple Access with Collision Avoidance
Direct Current
Data Encryption Standard
Device Language Message Specification
Direct Sequence Spread Spectrum
Energy Meter Sensor Node
Full Function Device
General Packet Radio Service
Guaranteed Time Slot
Global System for Mobile Communications
Hardware Abstraction Layer
Identification
Internet Engineering Task Force
Input/Output
Internet Protocol
xv
IPv4
IPv6
kBs
LDO
LGA
Li-ion
LMP
LQI
MAC
MCU
MMCX
MTU
Ni-MH
NWK
O-QPSK
PAN
PCB
PHY
PIN
PiP
PLC
PSSS
RAM
RFD
RF
RISC
ROM
RSSI
SCI
SE
SIM
SiP
SMD
SoC
SPI
TDMA
TI
TTL
UART
WAN
WiMax
WPA
WSN
ZCL
ZDO
ZDP
Internet Protocol version 4
Internet Protocol version 6
Kilobytes
Low Drop-Out
Land Grid Array
Lithium-Ion
Link Management Protocol
Link Quality Indicator
Medium Access Control
Micro-controller Unit
Micro-miniature Coaxial
Maximum Transmission Unit
Nickel-metal Hydride
Network Layer
Offset Quadrature Phase-Shift Keying
Personal Area Network
Printed Circuit Board
Physical Layer
Personal Identification Number
Platform in Package
Power Line Communications
Parallel Sequence Spread Spectrum
Random Access Memory
Reduced Function Device
Radio Frequency
Reduced Instruction Set Computing
Read-only Memory
Received Signal Strength Indicator
Synchronous Communications Interface
Smart Energy Profile
Subscriber Identity Module
System in a Package
Surface Mounted Device
System on a Chip
Serial Peripheral Interface
Time Division Multiple Access
Texas Instruments
Transistor-transistor Logic
Universal Asynchronous Receiver/Transmitter
Wide Area Network
Worldwide Interoperability for Microwave Access
Wi-Fi Protected Access
Wireless Sensor Network
Zigbee Cluster Library
Zigbee Device Object
ZigBee Device Profile
xvi
Chapter 1
Introduction
Today’s electric grids are outdated. The traditional manual energy meter reading wastes, time
and manpower. Its unreliability and low frequency of occurrence produces data that is both, useless
for energy production/distribution real-time decisions and for accurate consumption measurements
and billing. A better control over the energy production, distribution and consumption is required.
In this scenario, environmental sustainability is pushing us to a more efficient use of earth’s natural
resources, leading us to expand the use of green/renewable energies, and turning electric cars [1,2]
into a future reality. In addition, micro-generation is also gaining momentum as a means to catch
up to the ever increasing power demand [3].
The electric grids components, energy production plants, distribution lines and loads need to
become “smart”. Smart grid is a new concept that refers to technologies devoted to modernising
the electric grids, creating an intelligent system that responds to peaks of energy usage, controls
power demand, better incorporates local production of clean energy and accurately measures consumption. Automatic Meter Reading (AMR) and Automatic Meter Infrastructure (AMI) are smart
metering technologies that contribute to the smart grid.
AMR technology enables energy meters to autonomously report customer consumption, hourly
or even more frequently in a day, while AMI provides an infrastructure to aggregate, record and send
that information to a service provider. AMI goes even further, it creates a two-way network between
the smart energy meters and the service provider, allowing individuals and companies to improve
their energy usage. In-home energy displays, thermostats, light switches and load controllers are
already a reality [4]. Utilities also benefit from this two-way networking since it improves reliability,
and allows for dynamic billing and appliances control.
The communication technologies, either wired or wireless, are a key element in smart metering. They will allow remote access to the metering data, remote configuration of energy meters and
even remote firmware updates. For such technologies to succeed, they must promote interoperability1 , create robust and reliable networks and have a low installation and maintenance cost [5].
Wired connections, using Power Line Communications (PLC) in AMR systems already exist [6–8].
However, their reliability is highly affected by the noise generated from appliances [9] and several
1
Open Standards being the only way to guarantee interoperability.
1
disturbances that can occur in the electric grid [10].
Wireless technologies are becoming more common since they avoid the hassle and cost of
installing and maintaining a cable infrastructure to support a network. Regarding AMI/AMR, GPRS,
Wi-Fi, Bluetooth and ZigBee are the most promising wireless technologies. General Packet Radio
Service (GPRS) [11, 12] has the advantage of using an already existing infrastructure, but it is an
expensive solution. Hardware costs as well as power consumption (transmission requires bursts
of more than 2 A) are higher than in other wireless technologies. In addition, utilities need to pay
for the communications service, subscribing it from a telecoms provider. These disadvantages are
important since utilities look for cost effective solutions [13].
As Wi-Fi routers already exist in the majority of homes and offices, utilities can use Wi-Fi enabled meters to communicate metering data. This could potentially save installation costs but it
relies heavily on the costumer. The costumer must configure the wireless connection, making the
utility partially loose control over the system. One possible solution, involving Wi-Fi is relying on
the upcoming Worldwide Interoperability for Microwave Access (WiMax) technology [13, 14]. This
combination can be a good solution for AMI/AMR, but the future of WiMax is still uncertain [15].
Solutions using Bluetooth [16, 17] take advantage of the low power nature of this technology.
However, Bluetooth is intended to short distance cable replacement being unable to form large
networks. A Bluetooth network can bridge together piconets of 8 nodes to form larger networks
(called a scatternet), but neither the mechanism nor the resulting topology are defined by the
Bluetooth standard [18]. This allows manufacturers to implement different algorithms (examples
in [19, 20]), not promoting interoperability, which will hinder the proliferation of the technology to
in-home appliances.
Table 1.1: Comparison of technologies
ZigBee
Bluetooth
Wi-Fi
GPRS
PLC
Standard
IEEE 802.15.4
IEEE 802.15.1
IEEE 802.11
Promoter
ZigBee Alliance
Bluetooth SIG
Wi-Fi Alliance
3GPP
Several
Organizations
Network
Topology
Nodes
(max)
Mesh, Tree,
Star
Star
Star
Tree
Tree
65000
8
32
N/A
hundreds
Spectrum
868/915 Mhz
2.4 Ghz
2.4 Ghz
2.4 Ghz
5.8 Ghz
Security
AES-128 bit
PIN Paring
LMP
WPA
800 Mhz
1900 Mhz
SIM authentication
64 bits encryption
250 Kbps
723 Kbps
11-105 Mbps
56-114 Kbps
4-128 Kbps
10-70m (1km)
Very Low
Alkaline
(Months - Years)
10m
Low
Rechargeable
(Days - Weeks)
10-100m
High
Rechargeable
(Hours)
Mobile Network
High
Rechargeable
(Hours)
300m
Wired
Data Rate
(max)
Range
Power
Battery Life
2
3-148 Khz
DES
N/A
The last alternative technology, ZigBee, is the adopted in this thesis. Its technological features [21, 22] (see table 1.1) surpass that of the other referred technologies, making it an attractive
solution to support the smart grid.
ZigBee is a low-power, low-cost wireless technology being recently used as a de facto standard
for Wireless Sensor Network (WSN). Large reliable deployments are now in place implementing
ad-hoc WSN, such as, room locks in Mandalay Bay Hotels [23], equipment tracking at Tri-City
Medical Center [24] and metering [25]. ZigBee Alliance, which promotes ZigBee, is developing
profiles and enforcing certifications to achieve interoperability, making ZigBee very attractive for
home automation, telecom services and smart metering. In 2008, ZigBee Alliance specified the
Smart Energy Profile (SE) profile that provides device descriptions and standard practises for demand response, load control, pricing and metering applications, in order to allow interoperability
among ZigBee products produced by various manufacturers.
More recently, ZigBee Alliance stated [26] it would incorporate global IT standards from the
Internet Engineering Task Force (IETF) into the SE, to provide applications with native IP support.
They also announced a collaboration with Wi-Fi Alliance [27], to use 6LoWPAN in the SE. 6LoWPAN is a compression mechanism to enable the use of IPv6 in IEEE 802.15.4 based networks.
Other AMI/AMR implementations, using ZigBee, have been reported. In [28, 29], an AMR
system is presented. These works use a dedicated ZigBee routers infrastructure to create the
mesh wireless network, and ZigBee end devices to interface with the meters. In [29], GPRS is
used to make the metering data available, while in [28] they state any wired or wireless protocol
could be used.
In [30] a dedicated router infrastructure is also proposed for message handling. They assume
all communications between the meters, the appliances and the costumers will always require information to go to the service provider and back. Therefore, they employ a load balancing scheme,
by simultaneously using more than one channel to send data, to avoid communications congestion
and reduce message delays.
A metering module is developed, in [31], that interfaces with a data acquisition module and not
with existing meters. They consider a star network for the measuring infrastructure and the data
collected is then stored on the concentrator. No methods to send that data to the service provider
are presented.
At a larger scale there is the pilot project in Goteborg [21] whose purpose, is to create an AMI
system, over the entire city, using ZigBee. Unfortunately, the information available is not enough
for a comparison with this thesis work.
The system implemented in this thesis, interfaces with existing digital energy meters enabling
them to communicate through ZigBee. Using Device Language Message Specification (DLMS), it
can not only retrieve voltage/current/power measurements from the energy meter but it can also
configure it, which is a clear future advantage over systems that use data acquisition modules
directly on the power lines or count the meters’ pulses. Communications are supported by a full
mesh ZigBee network (every meter node is a ZigBee router), so no router infrastructure, dedicated
to routing messages, is required. Although using ZigBee end devices produces the lowest power
3
consumption solution (ZigBee end devices can sleep while ZigBee routers cannot), it increases
costs due the increase of devices needed. No load balancing scheme is employ, like in [30], our
system’s nodes are flexible enough to implement a costumer-meter communication that does not
required constant utility queries, therefore lowering network traffic. Finally, the network concentrator
interacts with the service provider through ethernet, but any Wide Area Network (WAN) protocol
can be used.
Objectives
The main objective of this work is to develop an AMI/AMR system, using a ZigBee mesh WSN
that easily integrates with the existing infrastructure. The developed solution must provide a lowcost upgrade to the systems already in place. To achieve the main objective, specific objectives are
defined:
- Analyse commercially available products on the market.
- Develop the hardware and software of a ZigBee module.
- Implement, in the ZigBee module, an interface to enable communication with commercially
available energy meters.
- Choose and implement an antenna for the ZigBee module.
- Choose and implement a permanent power supply for the ZigBee module.
- Choose a type of rechargeable batteries to be used as a backup power supply and implement
its charging circuit.
- Develop a platform to permit the system’s demonstration.
Dissertation Outline
The structure of this dissertation is as follows. Chapter 2 introduces the ZigBee technology,
detailing its physical characteristics, features and operation, and presenting a brief overview about
its evolution to 6LoWPAN. Chapter 3 details the work done to implement the ZBeeMeR system, introducing the proposed architecture and then detailing hardware and software decisions. In Chapter 4 the tests to validate the developed ZigBee module and the complete ZBeeMeR system are
presented, as well as some results. Finally, Chapter 5 concludes this dissertation by, evaluating the
initial objectives, criticising the obtained system and describing future work.
4
Chapter 2
ZigBee Technology
ZigBee aims to be a open and global standard to be used in low-cost, low-power, low data
rate and highly reliable monitoring and control wireless solutions. This specification [32] is supported by the ZigBee Alliance, that provides public application profiles and interoperability testing
specifications.
Like any other protocol, ZigBee has a stack of layers presented on figure 2.1. As depicted on
the figure, ZigBee is built on top of the IEEE 802.15.4 standard [33].
Application (APL) Layer
ZigBee Device Object (ZDO)
Application Framework (AF)
Application 1
(endpoint 1)
Application 240
(endpoint 240)
Device Application
Network
Discovery Matching Management
Application Support Sublayer (APS)
Binding
Management
APS
Security
Security
Service
Provider
Packet
Fragmentation
Packet
Filtering
ZDO’s
Management
Plane
Network (NWK) Layer
Security
Management
Network
Topology
Packet
Routing
ZigBee
Alliance
Network
Addressing
Medium Access Control (MAC) Layer
Network
Maintenance
Channel
Assessment
Reliable
Data Transport
IEEE 802.15.4
Physical (PHY) Layer
868/915 MHz Radio
2.4 GHz Radio
Figure 2.1: ZigBee stack architecture.
The IEEE 802.15.4 standard only defines two layers, the Physical Layer (PHY) and the Medium
Access Control (MAC). ZigBee defines the two other layers. The Network Layer (NWK) provides,
5
hierarchical/stochastic addressing, route discovery, forwarding, authentication and encryption. The
Application Layer (APL) provides message fragmentation and filtering, binding management and
another level of encryption. In the APL, the Zigbee Device Object (ZDO) also provides network
services like device and service discovery, and application matching.
Next sections summarise the ZigBee specification, focusing on the relevant subjects for this
thesis work.
2.1
2.1.1
IEEE 802.15.4
The Physical Layer
The PHY layer defines three frequency ranges, the 868MHz band, unlicensed in most European
countries1 , the 915MHz band, unlicensed in North America and some Asian countries and the
2.4GHz band, unlicensed worldwide. The standard allocates 27 channels distributed through the
bands: channel 0 in the 868MHz band, channels 1 to 10 in the 915MHz band and channels 11 to
26 in the 2.4GHz band. For the three frequency bands, four PHYs layers are defined by combining
the band with one of three types of modulation, as shown in table 2.1.
Table 2.1: Frequency ranges, data rates and modulations.
Phy
1
2
(optional)
3
(optional)
4
Frequency
Bit Rate
(MHz)
(Kb/s)
868
915
868
915
868
915
2450
20
40
250
250
100
250
250
Modulation
Symbols
BPSK
BPSK
ASK
ASK
O-QPSK
O-QPSK
O-QPSK
Binary
Binary
20-bit PSSS
5-bit PSSS
16-ary Orthogonal
16-ary Orthogonal
16-ary Orthogonal
PHY 2 uses Parallel Sequence Spread Spectrum (PSSS) and the other 3 adopt Direct Sequence Spread Spectrum (DSSS). PHYs 2 and 3 are marked as optional, which demands that any
device using these schemes must be able to dynamically change to the mandatory PHY 1, on request [33]. The PHY specification includes the definition of some basic features, organised in data
and management services, that a radio must possess in order to conform to the standard. However,
these features (as most of this layer definitions) are implemented by the chip’s manufacturer.
2.1.2
The Medium Access Layer
Device Types
The IEEE 802.15.4 standard defines 2 types of devices. The Reduced Function Device (RFD)
that requires less memory, processing and power resources, than the Full Function Device (FFD),
1
Unlicensed means it can be used without paying fees.
6
which offers more features. FFDs are the only devices able to directly communicate with any other
device. They are also, the only devices capable of starting a network (task done by the special FFD
called coordinator), of forwarding packets and of giving permission to others devices to associate
with the network. A RFD only communicates and associates with one FFD at a time. RFDs are
usually sensor or actuator nodes, therefore implementing a reduced protocol set.
Due to their features, each device has a different role, FFDs create and maintain a network that
the RFDs use to report data.
Network Topologies
FFD
FFD
RFD
Coordinator
RFD
RFD
FFD
Figure 2.2: Message flow in a Star network topology.
FFDs and RFDs can interact in a star or in a peer-to-peer topology. The star network (figure 2.2)
is defined by a central node − the coordinator − and several satellite devices that join him to start
transmitting in the network. There are no direct associations between the satellite nodes, being all
the communications with the coordinator.
The peer-to-peer topology permits FFD devices to communicate directly with any other in range.
It does not define a network by itself, but permits various network structures with or without topological restrictions. For example, in figure 2.3 a clustered stars network is presented. In this network
any two FFD in range, can communicate directly even with devices they are not associated with.
RFDs remain restricted to communicate with the FFD their associated with. As in every IEEE
802.15.4 network, one FFD is required to be the coordinator, responsible for starting the network.
RFD
RFD
FFD
FFD
RFD
FFD
Coordinator
FFD
RFD
RFD
RFD
FFD
RFD
RFD
RFD
RFD
Figure 2.3: Parent-Child associations in a Clustered Stars network topology.
7
Communication Modes
The communication between network nodes is done according to either the beacon mode or the
non-beacon mode, using the Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA)
method for medium access. The main distinction between both modes is the existence of a mechanism that allows for a synchronised/organised communication between the network nodes. In the
non-beacon mode, any time a node needs to send data over the air, it checks for channel activity2 .
While activity is detected, it backs off for a random amount of time. As soon as no channel activity
exists, it starts transmitting. The transaction ends when the last byte has been sent. However, if an
Acknowledgement (ACK) was requested, the transaction only ends when the sender, successfully
receives it from the receiver. The receiver, after receiving the last byte of information, has less than
192µs to reply with an ACK message, without using CSMA/CA. So, the non-beacon mode has
no rules for communication other than the CSMA/CA scheme, and offers no mechanism for device
synchronisation.
Figure 2.4: A superframe structure.
The beacon mode uses beacons and a superframe to provide device synchronisation. Beacons
are still used in the non-beacon mode but only for network identification. A beacon is a frame
periodically sent by the coordinator, without CSMA/CA, and retransmitted by the routers. It is used
as a time marker to synchronise network devices. It also transports information that identifies the
network and its superframe structure (see figure 2.4).
A superframe is not a packet, but a structured time period delimited by beacons. It is a
mechanism to achieve device synchronisation that also provides a structured environment for
data exchange. Figure 2.4 presents the complete superframe structure. The Contention Access
Period (CAP) and the Contention Free Period (CFP), in the active time interval, are subdivided in
equally sized time slots (dashed lines in figure 2.4).
Only one type of network activity is permitted in each time interval of the superframe. During
the CAP, the communication is similar to the non-beacon mode, but the device must synchronise
to the beacon before trying to transmit. The communication uses slotted CSMA/CA, where the
back-off time is a random time slot, aligned with the start of the beacon transmission, and not an
absolute random time like in unslotted CSMA/CA.
During CFP there is no channel competition, Time Division Multiple Access (TDMA) is used.
The CFP is intended for devices whose applications require a specific amount of bandwidth or low
latency. A Guaranteed Time Slot (GTS) can be obtained by request to the coordinator and used for
the communication. It is comprised of one or more time slots. The CFP is divided in up to seven
2
This operation is commonly called a clear channel assessment.
8
GTSs and is an optional time interval.
Finally, the inactive period permits that any device, even routers, go to a sleep mode in order to
preserve power. The inactive time interval is also optional.
2.2
2.2.1
ZigBee
The Network Layer
ZigBee Network Layer (NWK) extends the IEEE 802.15.4 MAC layer (recall figure 2.1) by defining an addressing scheme and a routing mechanism. It also provides authentication and encryption. ZigBee types of nodes taxonomy, network topologies and modes of operation present some
differences to IEEE 802.15.4.
Differences to IEEE 802.15.4
ZigBee defines type of nodes based on their role rather than on hardware capabilities (FFD
and RFD). A ZigBee network has a coordinator, routers and/or end devices. The coordinator,
one per network, is a special case of a router. It is the sole responsible for starting a network
and for choosing/setting some key network parameters. After starting the network, the coordinator
behaves like a router, but its network address is always zero (0x0000). A router is a device capable
of extending the network coverage. It routes messages between other devices and enables new
devices to associate with it. The association allows the new device to join the network. Finally,
an end device is any device that is neither a router nor a coordinator. It only associates with one
device at a time, cannot directly exchange messages, and can sleep in order to save power. A
coordinator or router must be supported by a FFD while an end device can be either a FFD or a
RFD.
Tree and mesh network topologies, which use the peer-to-peer IEEE 802.15.4 feature, are
the two topologies defined by ZigBee . The tree topology is a particular case of the IEEE 802.15.4
clustered stars topology (figure 2.3), where hierarchical addressing and routing are used. The mesh
topology is the IEEE 802.15.4 clustered stars topology with mechanisms and rules to dynamically
achieve message routing. Routing is the ZigBee feature that eliminates the “in range” limitation of
communications on IEEE 802.15.4 networks.
Beacon or non-beacon modes of operation are, in ZigBee , network topology dependent. The
beacon mode is only supported on the tree topology, not being permitted in a mesh network topology.
Addressing and Routing
Addressing in ZigBee networks is done using the Cskip algorithm [32]. This algorithm needs to
know, a priori, the maximum number of routers, the number of children3 and the tree depth. With
3
Children are the sum of routers with end devices.
9
this information, ranges of 16 bit static addresses are computed and pre-programmed in all routers
and in the coordinator.4 Therefore, each device (apart from end devices) as a limited number of
addresses to attribute to joining devices. From each address the hierarchical location of a device
inside the network can be undoubtedly inferred.
Routing can follow one of two possible schemes, tree routing or a simplified version of Ad hoc
On-demand Distance Vector (AODV). Tree routing uses the implicit hierarchical information from
each device network address to route messages. Since in a hierarchical network, a message can
either go up or down, tree routing follows one condition. If the destination address is within the
device’s address range the message goes down, otherwise, it is sent up. Tree routing can be used
in any ZigBee network topology because their addressing algorithm is the same.
AODV creates routes when a node wants to send data to a receiver. The sender broadcasts
a route discovery request, if the destination address is not yet in its routing table. This request is
re-broadcasted again by every device that receives it, until the destination is reached. Once the
destination node is reached, the receiver sends a route request reply. This reply travels to the
requesting device and each device that forwards it along, stores an entry in its routing table.
Each routing table entry contains only the destination address and the address of the next hop
required to reach it.5 The sender can finally dispatch the message to its intended destination, over
the created route. A new route discovery request will only be initiated, on this same route, if any of
its devices fails. Any temporary routing information stored by nodes that did not forward the route
request reply, expire after a few seconds.
The ZigBee specification foresees the usage of a metric, (but only defines its scale) according
to which each device could report a number between one and seven representing the level of
confidence in receiving a message. This value would be summed up by the route request reply,
providing a measure for routes comparison.
Security
ZigBee NWK provides means for authentication and encryption built on top of the basic security
framework, AES encryption and CCM security modes, defined in IEEE 802.15.4. ZigBee protects
messages integrity by encryption according to AES-128 using the CCM* security mode. Though
CCM*, ZigBee combines encryption and authentication with a single key, while also supporting
messages that require only encryption.
Three different security keys can be used. A master key, to provide security between two
devices6 , a link key, to protect the transport of data between two devices, and a shared network
key, for network wide security against outside attacks, at either data or infrastructure levels.
Keys can be pre-programmed in the devices or exchanged when a device joins the network.
They can also be periodically updated, to improve security. A device implementing the trust center,
4
Although each device has a 64 bit unique identifier, that can be used for identification/communication, when in a
network, communications use a 16 bit address.
5
This way, each device only stores a portion of the route information, allowing for smaller routing tables and consequently smaller RAM requirements.
6
Protects link key exchange.
10
is responsible for the network keys handling and maintenance, and also for admitting new devices
into the network.
2.2.2
The Application Layer
The Application Layer (APL), the last ZigBee layer (figure 2.1), is dedicated to support the
costumer/manufacturer application inside a ZigBee device. It is divided in three sections, the Application Framework (AF), that allows for a single device to run many applications, the Zigbee Device
Object (ZDO), that provides several network services and the Application Support Sublayer (APS),
that provides message handling services.
Each device is defined by a profile, either public or private, that defines its application environment, its features and the clusters it uses for communication. Clusters are unique identifiers that
represent a collection of commands (or attributes), that are inputs and outputs of the application.7
Public profiles guarantee interoperability between different vendors for the same application environment.8 The public Zigbee Cluster Library (ZCL) [34], an add-on to ZigBee profiles, is a collection
of clusters that retain their meaning across profiles. For example, the OnOff cluster that defines
how something can be turned off, on or toggled, can be used in a light switch, a garage door, valves
and any other device that can have these two states (on or off). This promotes interoperability by
re-use of clusters when a new application profile as to be defined.
An application is implemented as an application object and connects to the rest of the stack
through an endpoint, which makes it addressable within a device. The AF is the infrastructure that
handles message delivery between endpoints and between an endpoint and the ZigBee network.
It also stores the profile descriptors of all application objects, to respond to service discovery or
descriptor matching network queries. The AF supports up to 256 endpoints from which, 240 are
available for applications. Two special endpoints are defined, endpoint 255 is a broadcast address
and endpoint 0 is the ZDO.
The ZDO (featured in figure 2.1) is a special application object, resident in all ZigBee devices.
It is responsible for network management features such as, device management, security keys
and security policies. These features are defined in the ZigBee Device Profile (ZDP). The other
application objects (or endpoints) make calls to the ZDO when they want to access or use network
services. These services are, device discovery by network (short) or IEEE (extended) address,
service discovery according to device type or a matching criteria and queries for device descriptors
directly or matching. An endpoint can also, through requests to ZDO, control the device it is in,
obtain information from it and define its security settings. Security becomes transparent to an
endpoint once it negotiates settings with the ZDO. Information can be obtain about the device’s
network status, about the contents of its routing table and/or binding table, about the result of a
energy detection scan, about when a new device joins the network or a new service becomes
available, etc. To enable these features the ZDO directly accesses the NWK layer and the APS
sublayer as denoted, by the ZDO’s management plane, in figure 2.1.
7
8
In practice attributes can be understood as tags carried by messages, identifying the message type.
The Home Automation profile and the Smart Energy Profile are two examples of ZigBee defined public profiles.
11
The last member of the APL is the Application Support Sublayer (APS), that provides message
handling services. It filters received messages so that only unique messages addressed to the
device or a group to which the device belongs to, are delivered to the AF and consequently to its
correct endpoint. The ability to define a group (giving it an unique address) and adding/removing
devices from that group is also provided by the APS. In addition to message filtering it can encrypt
and authenticate messages9 , handle message fragmentation and manage binding. Fragmentation
consists in segmentation and reassembly of messages that exceed the maximum transmittable
packet size (127 bytes). Binding is the creation of an unidirectional logical link, between a source
endpoint/cluster pair and a destination endpoint that can exist in one or more devices. Each time
the bound endpoint sends a message with the bound cluster tag, the APS resolves the destination
device address. This address resolution can be made through network matching queries or by the
physical pressing of a button in each device involved. Applications, for example, light switches use
this feature to lower their complexity.
2.3
ZigBee Pro
The ZigBee specification has two versions, the ZigBee 2007 and the ZigBee 2007 Pro. All the
functionality explained in section 2.2 is valid for both. ZigBee Pro is an enhancement to ZigBee,
introduced for better support of large (hundreds of devices) networks. ZigBee Pro stack size is
bigger. Therefore, it shall be used only in applications that require and fully take advantage of its
features.
ZigBee Pro enhancements are at the NWK layer. The application layer in both versions is fully
compatible. The two versions can even coexist in a limited manner. If the network is initialised with
the Pro version, then ZigBee 2007 devices are allowed to join but only in the role of an end device.
The same restrictions apply to devices with the Pro version that have joined a network started as
ZigBee 2007.
ZigBee Pro changes tree addressing to stochastic addressing with conflict resolution. This
dynamic addressing scheme improves network scalability, since all available network addresses
become available to any device that joins. In the most extreme case a router can have 21 6 = 65 536
associated devices.
ZigBee Pro also improves the AODV routing protocol, with the many to-one source route aggregation option. This option reduces the network traffic, the routing table space and the time required
for route establishment, when multiple nodes report to a single network device. It also allows for
that device to reply back to each sender without requiring additional entries in its routing table.
Other enhancements introduced by ZigBee Pro include:
- a neighbour broadcast feature, devices keep the addresses belonging to near by nodes, in a
special group;
- the ability to dynamically change the frequency channel;
- a network Identification (ID) conflict resolution scheme;
9
ZigBee states that each layer is responsible for the security of the frame it generates.
12
- an asymmetric link handling mechanism to improve links quality when establishing routing
paths;
- the ability for the Trust Center to run in a device other than the coordinator;
- a high security option that mandates the use of network and link keys by all devices.
2.4
6LoWPAN
ZigBee Alliance announced it would incorporate Internet Protocol (IP) standards into ZigBee [26].
Early this year, they announced version 2.0 of the Smart Energy Profile (SE) [35], where 6LoWPAN
adaptation layer is used. As the future of AMI will, most certainly, be tied to this profile, the following
paragraphs briefly introduce 6LoWPAN.
6LoWPAN is a protocol specification to enable IEEE 802.15.4 networks to carry Internet Protocol version 6 (IPv6) packets [36]. With 6LoWPAN each node (of a WSN) will be seamlessly10
available from any other IP network, independently of its underlying technology.
6LoWPAN adapts the IPv6 40 bytes headers and 1280 bytes MTU to the packet size of IEEE
802.15.4 networks, in order to maintain a reduced code size and minimise power consumption.
6LoWPAN headers can be as small as 2 bytes. Header compression avoids sending information
inferable from other layers, reducing the number of bits to share status information when devices
belong to the same network, and using “stacked header”. Stacked headers provide the ability for
each message to have only the data necessary to its delivery. For example, if the payload fits in
the maximum packet size of the IEEE 802.15.4 network then, there is no need for fragmentation.
The fragmentation header field can be omitted.
10
Simpler bridges/routers already available can be used instead of a more complex gateway.
13
14
Chapter 3
ZBeeMeR System
ZBeeMeR is an AMR system that provides a cost effective way to upgrade an existing metering
system. It regularly transmits energy consumption to the utility and can also enable consumers to
monitor their consumption far more accurately, on a daily basis.
ZBeeMeR addresses building or neighbourhood environments, creating a ZigBee WSN in
which the energy meters are the ZigBee sensor nodes. Each Energy Meter Sensor Node (EMSeN)
is able to report measurements with a pre-defined periodicity and to accept direct commands from
the utility. The unique ZigBee coordinator acts as a data concentrator, aggregating data from the
EMSeNs and efficiently sending it to the utility management centre. The use of a concentrator decreases the system cost, by avoiding a direct connection from each EMSeN to the utility. Two-way
communication between the utility and a EMSeN is still possible, through the concentrator.
Some EMSeNs can be out-of-rangue of the concentrator. To solve this problem no ZigBee
end devices are allowed, all EMSeNs are ZigBee routers having forwarding capabilities to enable
message routing. When EMSeNs cannot fully cover the environment, network extender nodes
(EMSeNs without metering capabilities), are used to obtain the necessary coverage.
3.1
ZBeeMeR Architecture
Figure 3.1 presents the proposed AMR architecture and its components. Ethernet, GSM/GPRS,
Wi-Fi are shown as possible protocols to establish the communication between the WSN and the
utility. However, any other WAN protocol with adequate data rate and for the required distance can
be used.
EMSeNs are commercially available energy meters with a ZigBee module attached, that provides wireless capabilities to the meter. They are able to autonomously and independently report measurement values, according to a pre-defined parametrisation, and to respond to external
requests. External requests can either be measurement requests, parameters configurations or
software updates. EMSeNs do not require great computational power. However, memory can be
an important issue, depending on the specifications of the time interval to maintain measured values. Under normal operation, they are powered by the electric grid. In spite of that, EMSeNs will
15
Utility
Management
Centre
Energy meter
sensor node
WAN
(Ethernet, GSM/GPRS)
Concentrator
Building/Neighbourhood
ZigBee LAN
GSM/GPRS
Wi-Fi
Ethernet
Energy meter
sensor node
End Energy
Consumer
Energy meter
sensor node
ZigBee
Network
extender
node
Figure 3.1: AMI based on a ZigBee mesh network.
have a backup power source to permit them to identify the origin of a power blackout, if one occurs.
EMSeNs can also implement control permissions to enable the consumer to directly read its energy
meter, using ZigBee.
Network extender nodes can also be remotely configured and are able to report internal status.
They do not support metering features, being only ZigBee router nodes. They can be smaller in
size and require less resources than an EMSeN.
The concentrator, also without metering capabilities, requires significantly higher resources. It
bundles together collected data, either from EMSeNs or network extender nodes, to sent it to the
utility. It also processes messages sent by the utility to the nodes, such as, software updates,
test commands and configuration commands. Additionally, due to its gateway behaviour, it can
implement access control permissions, exposing different information to different types of users.
The utility management center permanently stores metering information. It analyses this information to enable users to access it, to enable dynamic billing and to better adjust its production/distribution network to the real-time demands. It can also remotely configure and update an energy
meter.
To conclude, the end energy consumer represents any in-home devices that can display metering/billing information or control appliances. Such device can get information directly from a utility
WAN accessible interface, or through ZigBee from an EMSeN. This component is an add-on to the
ZBeeMeR system, not an integral component of it, since it is not directly involved in the automatic
energy meter reading infrastructure.
3.2
Hardware
The module was intended to be generic enough for use in any other applications. So, it was
developed to be as small as possible even though the available meters could accommodate bigger
dimensions.
The energy meters available for the prototype are digital energy meters that provide a twoway communication over a RS-232 interface. These meters have enough casing free space to
accommodate anything smaller than 5x5 cm. Internally they provide a DC voltage of 5V that can
16
Antennas
2.4GHz ZigBee Transceiver
+
Micro-Controller
Power
Sources
RS-232
Transceiver
Extra
Memory
Figure 3.2: The ZigBee module architecture.
eventually be used. Therefore, the designed ZigBee module includes an RS-232 interface and
the possibility to operate from 5V. Figure 3.2 illustrates the module architecture, which includes
a ZigBee transceiver, a micro-controller, a RS-232 transceiver, additional memory and a power
supply system.
A SoC solution, having both the MCU and the ZigBee transceiver, is used to reduce size and
cost. For worldwide availability, the module is to operate on the 2.4GHz band. The power supply
system considers the eventually available 5V, from the energy meter, and a battery. The battery
acts as a backup to be used by energy meter sensor nodes when a blackout exists1 . For the
network extended nodes, the battery is the main power supply.
The following subsections describe each of the module’s blocks.
3.2.1
The ZigBee SoC
A market survey was conducted, in order to decide about the best ZigBee System on a Chip
(SoC) to be used in the project. The survey addressed products from many companies involved
with ZigBee technology. The diversity of information collected allowed not only for a better SoC
decision but also gives an overview about the existing ZigBee development. Information gathered
about SoCs, transceivers, development kits and modules is presented in appendix A.
Table 3.1: ZigBee SoCs - Selection from the initial survey.
Manufacturer
Solution
Ember
EM250
Jennic
JN5139
Texas
CC2430
Freescale
MC13224V
1
Micro-Controller
16bit RISC
(XAP2b ASIC)
32bit RISC
8bit 8051
32bit ARM7
TDMI-S
EPROM
(kBs)
128
(flash)
192
(ROM)
32/64/128
(flash)
128 + 80
(see text)
RAM
(kBs)
Tx Pwr
(dbm)
5
3
96
3
8
0
96
4
Package
48-pin QFN
7x7mm
56-pin QFN
8x8mm
48-pin QLP
7x7mm
99-pin LGA
9.5x9.5mm
Enables the node to report that a blackout occurred, helping the identification of its cause.
17
Price
(EUR)
5
4
4
4
The initial survey lead to a more detailed analysis of Ember, Jennic, Texas Instruments and
Freescale solutions that are better in terms of features and development support. This detailed
technical information is in table A.2 also in appendix A. Table 3.12 summarises the characteristics
of the four SoCs.
The four selected SoCs have dedicated hardware for MAC management, handling preamble
insertion, CRC-16 computation and checking over the MAC payload, and all CSMA/CA tasks.
That hardware also computes the Received Signal Strength Indicator (RSSI) and the Link Quality
Indicator (LQI). The integrated circuits also include an 128bit-AES encryption engine responsible
for data encryption/decryption. The Micro-controller Unit (MCU) characteristics were not a decisive
factor for the final choice, since the application is not very computationally demanding. Furthermore, the four SoCs employ different architectures and run at different clock speeds, making it
hard to assess the best overall performance. Available memory differs significantly, due to different
architectures.
Freescale solution [37] integrates the SoC itself, the balun and RF matching components, bypass capacitors and 128 kBs of SPI flash memory into a Land Grid Array (LGA) [38]. The SoC
features 80 kBs of ROM and 96 kBs of RAM. The ROM comes preloaded with the bootstrap code,
the UART and SPI drivers and a basic implementation of IEEE 802.15.4 MAC.3 The application
code must be and the ZigBee stack can optionally be stored in the SPI flash memory. However the
program code and data are always accessed from ROM or RAM. Upon boot, the flash memory is
mirrored into RAM, effectively limiting the application size to less than 96 kBs. That also makes the
available RAM for the ZigBee routing tables and application variables dependent on the application
size.
The Jennic SoC [39] has a similar memory architecture, the 192 kBs of ROM are intended to
host bootstrap code, drivers, the ZigBee stack, and the application code and data. The 96 kBs of
RAM are shared between program variables and code, since all code is accessed from RAM. If
more memory is required for software storage, an external SPI flash memory must be bought.4
Ember [40] and Texas Instruments (TI) [41] present a different approach with a typical MCU
with internal flash memory and RAM. The RAM is used for variables/tables only, while the internal
flash hosts both the application and the ZigBee stack up to the 128 kBs available.
To make a ZigBee network, a ZigBee stack is necessary. All manufacturers provide their own
stack in the form of binary libraries. TI, Jennic and Freescale implement the ZigBee specification.
These stacks are freely available for download, but Freescale limits the availability to a 90 day
trial version. Ember implements the ZigBee Pro specification, but its availability depends on the
purchase of a development kit.
To design the ZigBee module is also important to have access to a development kit that offers
ZigBee nodes and programming/debugging platforms. Jennic provides the cheapest development
kits. Their development software is a GNU-based tool-chain freely available for download. Ember
2
Prices are for quantities above 1000 units. The price for TI CC2430 refers to the 128 kBs version.
But can be extended to also host the ZigBee stack and code to handle the Serial Peripheral Interface (SPI) flash
memory.
4
Which increases this solution’s cost.
3
18
has the most expensive kits based on the xIDE compiler. Freescale and TI kits have a medium cost
and rely on the IAR Systems’ software.
All four solutions (table 3.1) are good, but each has advantages and disadvantages. Ember has
the advantages of being the only with a ZigBee Pro stack implementation and having the highest
number of modules in its development kits. However, that makes it the costlier solution, having
no freely available stack and the lowest amount of RAM in its SoC. Freescale solution eases
development by bundling, in a single package, the SoC and several other required components,
achieving the highest transmission power. In spite of that, Freescale has a limited free availability
for its stack and a high cost for a development kit with enough modules for field testing. Also, its
MCU memory architecture makes it hard to assess the amount of RAM available for stack tables
and application data. Jennic has the cheapest development kits and the highest amount of internal
storage memory, powered by a 32bit RISC MCU. Its disadvantages are the less optimised code that
may be obtained from its GNU-based tool chain and suffering from the same memory architecture
as Freescale. Finally, Texas Instruments is the only with flexibility in terms of flash sizes, it has the
biggest amount of RAM and uses a compiler optimised for its SoC. On the other hand, has the
weakest MCU and its development kits have a medium cost (when compared to the others already
presented).
To conclude, the characteristics of the SoC itself, the features and cost of the development kits
and the ZigBee stack availability, were the main decision factors about which SoC to use. Although
considering Jennic solution to be the most powerful and therefore the best solution, TI, the second
best solution, was chosen due to existing prior knowledge about it.
3.2.2
Power System
The module is intended to, under normal circumstances, be powered by the 5V available in
the energy meter. However, this solution requires inner access to the energy meter which may not
be viable to the utility, since any change requires the energy meter to undergo certification. The
alternative is to power the module from the electric grid by using an AC/DC converter. Additionally,
as already referred, batteries are required.
Power from Voltage Regulator
Some components in the module require a supply voltage of 3V. Therefore, a DC/DC voltage
regulator is required. Initially a switching regulator was considered since their generally more efficient than linear regulators [42]. However, by analysing components consumption I estimated,
that even when the radio is transmitting and the other chips are fully working as well (worst case
scenario), the module will consume less than 65mA. For such a low consumption, a linear regulator
is more efficient than a switching regulator [43], even if has a light load mode5 [44]. In addition,
switching converters are much more complex than linear regulators and consequently more expen5
Also known has power save mode. In this mode, the switching is temporarily stopped between voltage thresholds,
to reduce losses due to unnecessary switching.
19
sive, their cost difference goes up to more than double, so a linear regulator was chosen for this
work.
Linear regulators are basically a series pass transistor that works as a variable resistor. It
dissipates the excess power in order to generate a constant output voltage, independent of load
current. Because linear regulators require a voltage drop between their input and output terminals,
the maximum output voltage they can produce is equal to their input voltage minus its voltage dropout. To generate around 3V from the available 5V, a Low Drop-Out (LDO) regulator was required.
The TLV1117 linear regulator from Texas Instruments was the cheapest regulator that fulfilled the
requirements. It converts 5V into about 2.8V by means of two resistors. The 2.8V voltage was
chosen because it stands well inside the input voltage range of all the chips and is a good value for
battery charging.
Power from Rechargeable Battery
Chemical batteries are the classical solution to power circuits when the electrical grid is not
available. More recently super-capacitors and energy harvesting is being considered as a possible alternative. Solar energy [45], combined solar and wind energy [46] and RF harvesting [47]
are examples. Other forms are also exploited but no system is yet able to power a WSN node
continuously [48]. So, rechargeable chemical batteries were used.
There are many types of electrochemical cells, but Li-ion and Ni-MH stand out in terms of
energy density and size [49]. Li-ion batteries are less available to the general public than Ni-MH
and require a more complex charging circuit (see appendix B). Therefore, Ni-MH batteries were
chosen.
V+
Voltage
regulator
ZigBee Module
power feed
points
Rechargeable
batteries
V-
Figure 3.3: ZigBee module’s power supply diagram.
Two AA Ni-MH rechargeable batteries in series are required to produce a voltage inside the
chips range. To guarantee uninterrupted operation, both the battery pack and the linear regulator
are connected in parallel feeding the module simultaneously (see figure 3.3). This simple arrangement saves the cost and space of a solution involving power sensing and switching, while ensuring
that the module will only stop working if both power sources are not present.
The charging circuit used is very simple and may shorten batteries lifetime (see appendix B).
We considered that a more expensive and complex charging circuit is not justified due to its seldom
use. The low outage occurrence and low power drained by the module means the batteries will be
fully charged over the majority of their lifetime.
As Ni-MH batteries shall be charged with a fixed current method, the simple charging circuit
devised only required one resistor (see figure 3.4). Due to the resistor, charging is done with
20
2.8V
2.0V to 2.8V
R
Voltage
regulator
C2
2 AA
Batteries
C1
Figure 3.4: Battery charging circuit.
a very low current and stops naturally when the batteries voltage reaches the 2.8V imposed by
the linear regulator. This 2.8V threshold voltage was chosen after careful study of charge diagrams of different Ni-MH battery manufacturers. As the batteries are assumed to be at full capacity
for the majority of time, this charging occurs in an intermittent manner6 , that according to some
manufacturers [50, p. 13], improves charge efficiency, extends battery life and reduces electricity
consumption when compared to a low rate continuous charge method.
3.2.3
Antennas
The module needs an antenna for 2.4GHz. Three possible alternatives for the antenna exist.
The antenna can be printed on the Printed Circuit Board (PCB), can be inside a chip (chip antenna)
or be a whip antenna. In [51], Texas Instruments presents a good overview about that alternatives.
Table 3.2 summarises the advantages and disadvantages of the three types of antennas. Based on
Table 3.2: Comparison of Antenna Solutions.
Antenna
types
PCB
antenna
Chip
antenna
Whip
antenna
Advantages
Disadvantages
• Low cost
• Good performance
• Small at high frequencies
• Standard designs widely available
• Compact size
• Short time to market
• Good performance
• Short time to market
• Hard to design
• Big at low frequencies
• Non-steerable
• Medium performance
• Medium cost
• High cost
• Difficult to fit in some applications
table 3.2 it is possible to conclude that chip antennas are an average option. They are smaller but
more expensive and have lower performance than PCB antennas. Therefore, we decided to use a
PCB antenna and also a whip antenna. Both alternatives cannot be used simultaneously though,
switching between them requires the unsolder and re-solder of a capacitor. Implementing these two
alternatives will provide the possibility to analyse and compare them for a future implementation.
PCB and whip alternatives were considered has they can share the same balun7 . By contrast, the
6
This intermittent charging mechanism is similar to the maintenance Ni-MH battery charging stage, referred on appendix B.
7
The balun converts the single ended 50 ohm feed point of the antenna to the differential antenna interface of the
ZigBee SoC.
21
chip antenna requires a different balun [52].
Texas Instruments suggests the use of Folded Dipoles [53], Inverted F antennas [54] or Meandered Inverted F antennas [55] to implement PCB antennas for the 2.4GHz band. They provide
information describing the antenna, explaining how to design it and providing results from performance tests. We choose the Inverted F antenna, since it achieves the best trade off between
size and performance. The balun was implemented with a microstrip balun and only 4 discrete
components following the design proposed by Texas Instruments.
As the ZigBee module will be located inside the electric meter casing, and the whip antenna
will be in the outside for better signal reception, the whip antenna is supported by a small U.FL
connector8 in the PCB. At first a Micro-miniature Coaxial (MMCX) vertical mounted connector was
chosen due to its little size and robustness, but at purchase time it was unavailable, so it was
replaced by the U.FL connector. The U.FL connector is smaller, but less robust than the MMCX.
However, as the antenna will be attached to the meter casing little stress is applied to the connector.
3.2.4
Serial Communication and Extra Memory
The ZigBee SoC provides two UART controllers that output signals at the TTL levels. Maxim
Max3319 is the integrated circuit chosen to convert between TTL and RS-232 voltage levels, due to
its ability to operate under low voltage levels − 2, 25V to 3, 00V − and to automatically be shutdown
and reactivated. It shutdowns after 30 seconds without communication activity and reactivates itself
upon receiving a valid RS-232 level signal, avoiding the use of Input/Output (I/O) ports of the ZigBee
SoC to control the TTL/RS-232 conversion.
Additional memory is included in the ZigBee module, to make possible to store energy measurements over a considerable amount of time. We choose a SPI enabled flash memory. There are
no special requirements nor speed constraints, so cost and upgrade possibility9 were the decision
factors. Therefore, the Numonyx M25P40, a low voltage 512 kBs flash memory was selected.
3.2.5
Printed Circuit Board
The circuit was designed using OrCad 10.3 software. Footprints from OrCad’s libraries or
designed according to data-sheets were used. On both cases, pads were incremented by 10%
in average to provide a bigger tolerance to misplacements that may occur when components are
assembled. All used components are of Surface Mounted Device (SMD) type, to ensure a small
sized module.
The circuit was implemented in a 4-layer PCB (figure 3.5) with 1 millimetre thickness, due to
TI’s specification for its microstrip balun [54]. The two outer layers are used for signal routing and
the two inner layers for ground and power planes. Components are mounted on the upper layer
and the ground plane is the layer immediately below.
8
U.FL is a miniature coaxial RF connector for high-frequency signals up to 6GHz manufactured by Hirose Electric
Group in Japan. It is part of the ultra small surface mount coaxial connectors.
9
In terms of having other, pin-compatible, flash memory sizes.
22
Copper - Top Routing Layer
Prepreg: Uncured Fiberglass-Epoxy Resin
Copper - Ground Layer
Core: Cured Fiberglass-Epoxy Resin
Copper - Power Layer
Prepreg: Uncured Fiberglass-Epoxy Resin
Copper - Bottom Routing Layer
Figure 3.5: Layer stack-up on a 4-layer PCB.
Loop inductance can be a problem on PCBs that handle high frequency signals [56]. Power
and ground planes reduce loop inductance by allowing a return path to exist near the signal path.
A plane has also less inductance than a narrow trace, which further reduces path inductance.
Furthermore, stacking the ground plane in a inner plane, provides isolation between the signals
routed on the outer layers. While the power plane makes the Direct Current (DC) voltage available
near any component pin by means of a short trace. So, planes also make it possible to reduce the
PCB size, through trace length reduction.
To further preserve signal integrity and ensure a stable power supply, the layout was designed
taking into account the following issues:
- The fast switching of digital circuits is usually a source of noise that causes unwanted interference, specially on analog signals. Therefore, to minimise interference within the PCB, the
Radio Frequency (RF) section is placed on the opposite corner to the digital components and
power supply (figure 3.6).
Figure 3.6: Digital and analog separation on the PCB.
- The empty spaces (not populated with traces) on the routing layers are also flooded with
copper connected to ground for additional signal isolation.
- All traces across the PCB are keep as small as possible to reduce their inductance.
- Traces that cannot go in a straight line are chamfered ( 45◦ ) to reduce their capacitance.
- Bypass capacitors are used to improve power distribution. They short circuit high frequency
noise and serve as charge reservoirs. Bypass capacitors are mounted as close as possible
23
to power pins and connect to ground by a short trace (figure 3.7). As a general recommendation [57, p. 151] the bypass capacitor is mounted between the chip’s power pin and the
power plane via.
(a) Straight connection
(b) Bent connection
Figure 3.7: Power connection through bypass capacitor.
The project dossier that includes schematics, Bill of Materials (BOM) and Gerber files is presented in appendix C. The obtained ZigBee module, after manufacturing, manual placement of
components and reflow soldering is shown in figure 3.8.
Figure 3.8: The ZigBee module.
3.3
3.3.1
Prototype
Devices
Following the architecture of the ZBeeMeR system, described in figure 3.1, a prototype was
implemented. The ZigBee module developed is used for the EMSeNs, network extender nodes
and concentrator. To form an EMSeN the ZigBee module connects to an energy meter through its
RS-232 interface (figure 3.9a). A network extender node is accomplished with just the ZigBee module powered by rechargeable batteries (figure 3.9b) The network concentrator is a PC connected
through a RS-232 interface, to the ZigBee module (figure 3.9c) and to the WAN through an ethernet interface. The utility management center (figure 3.1) is implemented on another PC running
an Apache web server. This server is accessible over the internet, allowing for the concentrator
24
(a) EMSeN
(b) Network Extender Node
(c) Network Concentrator
Figure 3.9: Prototype Network Devices.
to communicate with it. The end energy consumer device is any PC with an internet browser that
connects to the Apache web server.
3.3.2
Features
The ZBeeMeR system prototype has four distinct components with the following features:
- the EMSeN that reports metering information, responds to requests, routes messages between ZBeeMeR nodes and allows new devices to join the network;
- the network extender node, which only routes messages and allows new devices to join the
network;
- the concentrator that requests, aggregates and provides information from all network nodes;
- the apache web server that displays metering data and allows to send requests to the network
or an individual node.
25
These features require different software implementations. An EMSeN implements the ZigBee
router profile, to allow network associations and message relaying. This node also implements the
IEC 62056-2110 [58] for communication with the energy meter. The network extender node only
implements the ZigBee router functionality. Although being different components, EMSeNs and
network extender nodes run the same software. This software will perform differently according to
the presence, or absence of an energy meter. EMSeNs are able to request metering data from the
energy meter and send it to the concentrator while, network extender nodes are not and fall back
to a ZigBee router only behaviour.
The concentrator implements the ZigBee coordinator profile and the protocol to communicate,
over the WAN, with the Apache web server. It bundles together metering data from EMSeNs and
stores it on a database11 temporarily, until sending it to the apache web server via an IPv4 ethernet
interface. The concentrator also implements a debugging interface that provides access to the local
database and to the ZBeeMeR network nodes.
The remote PC running the apache web server, runs an application that maintains a metering
data database with the periodic information sent by the concentrator. This remote PC also provides
a web interface to display the metering information and to allow messages to be sent to the ZigBee
network. These messages are sent over the internet to the concentrator that in turn delivers it to
the ZigBee network.
Figures 3.10 and 3.11 present the implemented interaction between ZBeeMeR components,
according to the interfaces and protocols used, and the type of information exchanged, respectively.
Concentrator
PC
Apache
web server
Custom Protocol
(by Ethernet)
Custom Protocol
(by RS-232)
(gateway and
database)
ZigBee
module
(coordinator)
ZigBee 2007
(by Air)
DLMS: IEC62056-21
(by RS-232)
Energy meter
ZigBee
module
(router)
ZBeeMeR node
Figure 3.10: ZBeeMeR Software Architecture − Protocols Involved.
10
11
This standard belongs to the Device Language Message Specification (DLMS).
This database is locally stored on the concentrator.
26
Changes to Nodes Configuration
Concentrator
Sends Requests
or Configurations
ZigBee
module
PC
Apache
web server
Sends
Measurement
or Status
Relays Messages
(gateway and
database)
(coordinator)
Requests Measurements
Relays
Messages
Sends Measurement
or Status
Replys to Requests
Energy meter
Requests Values
ZigBee
module
(router)
ZBeeMeR node
Figure 3.11: ZBeeMeR Software Architecture − Exchanged Information.
3.4
Software
The prototype implementation of the ZBeeMeR devices required different programming languages. The ZigBee module was programmed in C language using the IAR Embedded Workbench
v7.30b. The concentrator program running in a PC, was implemented with C# . The web interface
and the remote database manager are implemented using JavaScript, PHP and Perl.
The following subsections describe the implementations of ZBeeMeR devices in the prototype.
3.4.1
Nodes Software
Software running in the ZigBee module consists of three entities, the ZigBee stack, the Hardware Abstraction Layer (HAL) and the application (see figure 3.12). The ZigBee stack handles
network maintenance and configuration. The HAL supports the hardware. The particular features
of each node are implemented by the application entity.
Each entity is responsible for a particular set of functions that consist of one or more tasks
associated to one or more events. Tasks run concurrently, controlled by an event driven nonpreemptive scheduler. Each time a task ends, the scheduler executes the next task associated to
the highest priority waiting event.
ZigBee
Stack
Application
HAL
ZigBee Module
(Hardware)
Figure 3.12: Software architecture of the ZigBee modules.
27
Tasks from these three entities work together to ensure the intended operation of each ZBeeMeR
component.
ZigBee stack entity
The stack permits to create a ZigBee network that operates according to the specification [32].
It defines and implements the logical device device type that individualises the coordinator, the
routers and the end devices. Z-Stack version 1.4.3, from TI, supports the CC2430 SoC and permits the implementation of ZigBee 2007 non-Pro version. Z-Stack permits to configure several
parameters, such as, the internal tables sizes (routing, binding, etc), the time-outs duration, the
frequency channel to use, the network topology, the Personal Area Network (PAN) ID and the type
of security employed. These parameters are configurable at compile-time12 .
The majority of Z-Stack parameters maintain their default values. The parameters that were
changed configure the network:
- as a beaconless mesh network with only ZigBee routers due to the message routing requirement;
- with routing done according to AODV13 , falling to tree routing if AODV fails [59, p.10];
- with an hierarchical addressing scheme that allows each device to have up to six children
and allows to form a network with a maximum depth of six hierarchical levels;14
- to use the least noisy channel from the sixteen channels available in the 2.4GHz band;
- to use a specific PAN ID;
- with message encryption and authentication disabled.
Hardware Abstraction Layer (HAL) entity
HAL is an abstraction layer between the hardware, and the ZigBee stack and application entities. It allows for better software portability and readability, since it hides hardware differences
from these entities. The implementation of the HAL that supports the developed ZigBee module
was based on the HAL TI provides to support its development boards. TI HAL implements the
proper handling of CC2430 transceiver and its MCU I/O ports. The developed HAL adds enhanced
features to six I/O and the correct UART serial parameters.
Four CC2430 I/Os are accessible to support debugging and extend its capabilities if necessary,
in the future. Through HAL these I/Os can be set, read, configured as inputs or outputs and
have interrupts enabled or disabled. Two other I/Os, connected to the internal Analog-to-Digital
Converter (ADC), permit to measure batteries and power supply voltages.
The UART control was implemented to support the 300 baud and the 9600 baud rates (used
by the energy meters) and the 7E115 RS-232 data format defined by the IEC 62056-21 standard.
12
Z-Stack parameters cannot be changed when the network is operating.
More correctly it implements a simplified version of AODV.
14
These values are chosen so that the maximum number of devices does not exceed the 216 available addresses.
15
Seven data bits, one stop bit and even parity checking.
13
28
As the UART in the CC2430 only supports RS-232 formats with eight and nine data bits, two
algorithms were defined in HAL to convert serial data. These algorithms operate on the basis that
a 7E1 format has the same number of bits has an 8N116 , therefore the UART is configured to use
the 8N1 data format and HAL converts data to the required 7E1.
3.4.2
EMSeNs and Network Extender Nodes
As already referred (subsection 3.3.2), EMSeNs and network extender nodes run the same
software inside CC2430 MCU. Their specific behaviour is defined by the ability to communicate with
an energy meter. The program flowchart of these two ZBeeMeR nodes is illustrated on figure 3.13.
Each node starts by initialising variables and registering for network and/or HAL notifications.
Then, the node searches for the pre-programmed PAN ID in all available channels. If the joining
process is unsuccessful, it retries several times before permanently aborting the joining process,
stopping its execution. However, when the joining process is successful, the node joins the ZigBee
network and attempts to communicate with the energy meter, requesting its serial number. If the
communication fails, the node immediately informs the concentrator about the failure, although it
retries a number of times. After the maximum number of retries is reached, it defaults to a network
extender node, informing the concentrator of such decision. If the meter serial number is obtained
the node defaults to an EMSeN, informing the concentrator of its association with the energy meter.
Then, the code running in a node enters a loop, waiting for events to be processed.
The program flowchart (figure 3.13) only shows the two main application events. Other events
include:
- ZigBee stack messages that inform17 the application about changes in the network status,
about new devices that joined the network or about any particular request or response pertaining device and/or service discovery.
- HAL notifications to inform the application when the power supply is turned off, when the
batteries are running low, when one of the accessible I/Os has been triggered or when a
timer expires. Timer notifications control the reading periodicity of energy measurements,
time-outs and retrying delays.
- Signals to break large execution threads, allowing another tasks to run. This is advised due
to the non-preemptive nature of the scheduler.
- ZBeeMeR data or configuration request messages sent by the concentrator. Data requests
are used to ask for metering information in real time. Configuration requests permit to:
◦ set the periodicity of autonomous measurements reading;
◦ set meter login information;
◦ obtain unique identifiers from ZigBee module and form energy meter;
For each message exchange (request or response) between a node and the concentrator, the is
an ACK. If the ACK is not received, the sender device resends the message for a defined number
16
17
Eight data bits and one stop bit without parity checking.
The application is only informed of the events it registered for, in the initialization phase.
29
of times. In case of failure, the message is stored for a latter resending or lost if there is not enough
space to store it.
Init
No
Yes
End
Search/Join
network
Max
retries?
No
Joined?
Yes
Start
measurements
timer
Get meter
serial number
Inform concentrator Yes
about EMSeN
behaviour
Got
meter
serial?
No
Inform
concentrator
about failure
Delay
Yes
Max
retries?
Yes
Event
triggered?
No
No
Is reading?
Concentrator
request?
No
Yes
Abort RS-232
communications
Yes
Request
measurement
from meter
Yes
Inform
concentrator
Yes
For meter?
Send
data to
concentrator
Process
request
No
Default to
network
extender node
Figure 3.13: EMSeNs and network extender nodes program flowchart.
30
3.4.3
Concentrator
As referred (subsection 3.3.1), the concentrator is a PC connected to a ZigBee module. There
is a program running in the ZigBee module MCU and another in the PC. The flowchart of the
program in the ZigBee module is presented on figure 3.14.
Init
Create WSN
No
Event
triggered?
Yes
Yes
RS-232
request?
Convert
request
No
Send request
to network
Yes
Send to PC
Node
message?
No
Figure 3.14: Concentrator program flowchart − ZigBee module.
This program starts by initialising some variables, creates the ZigBee network and runs in a loop
waiting for an event. Events are of two types, the reception of a RS-232 request (that originated
from the utility), or a node (EMSeN or network extender) message. If a RS-232 request is received,
it is validated and converted to be sent to its destination. The request can be sent to all network
nodes (broadcast) or to a specific node (unicast). If the event is a message from a node, the
information it contains is transmitted to the PC. Possible requests and message types were already
described for the other ZBeeMeR nodes in section 3.4.2.
The program running in the PC implements a gateway functionality and handles a database,
where it stores the metering data received from network nodes and also information about them.
Additionally, it maintains logs for all its communications.
The flowchart of the PC is illustrated on figure 3.15. The PC program runs three concurrent
threads to handle data received from the RS-232 interface, from remote connection via WAN or
from the local keyboard input. The keyboard is only used for prototyping purposes, providing a
31
Init
No
No
Socket
connect?
Yes
Validate
command
Remote Connections
Thread
Is node
informing
message?
Send request
to network
No
Socket
input?
Yes
Yes
Database
request?
Yes
Wake waiting
thread
No
Send request
to network
No
Socket
closed?
Log
warning
Response
received?
Yes
Response to
request?
No
No
Respond
to request
No
RS-232
input?
Yes
Yes
Create
remote connections
thread
No
No
Keyboard
input?
Metering
data?
Yes
Store data
Announce
warning
in console
Yes
Terminate
thread
Figure 3.15: Concentrator program flowchart − PC.
32
Yes
Add new
node entry
Announce
in console
local console interface to send broadcast or unicast requests to the ZigBee network and access
the database of the concentrator.
The thread handling remote connections implements a server that listens on a socket. For
each remote connection it receives, it creates a new thread to handle the client.18 This new thread
waits for requests from the utility and processes them, until the utility terminates the connection.
If the requested data is available in the concentrator database, it is immediately sent. However,
if the request demands real-time data from an energy meter or is a configuration request, it is
issued to its destination node(s) and both the utility and the remote connections thread, wait for
the response. A special request exists to send the entire database contents to the utility, deleting it
from the concentrator.
The RS-232 thread handles data received from the ZigBee module. The action taken by the
thread depends on the type of message received:
- if the message is the initial message sent by a node informing it is an EMSeN or a network
extender node, then a new database entry is created to store future information from that
node;
- if the message is received from a node without a database entry, a warning is issued on the
console and written to the log file;
- if the message is a response to a previous request, the waiting remote connections thread is
waken up to handle it;
- if the message is metering data autonomously sent by the meter node, it is stored in the
database.
3.4.4
Web Interface
The information presented by the web interface is periodically read from a database present in
the PC that runs the Apache web server. This database is handled by a Perl script that sits between
the interface and the ZigBee network concentrator, as shown in figure 3.16.
Write
Concentrator
Data exchange
database
(by ethernet)
Database
handler
(perl script)
Read
Utility
database
Web
interface
Direct requests
Apache Web Server
ZigBee Network Concentrator
Figure 3.16: Web interface architecture overview.
As can be seen on figure 3.17, the web interface presents information by columns. Each column represents an EMSeN, identified by the meter serial number. Each cell in a column presents
18
In the prototype, the only connection received is from one utility server, the apache web server.
33
Figure 3.17: Web Interface.
the issued command, the response data and a time-stamp. The time-stamp is presented between square brackets, indicating date and time values, next the command code is displayed and
parenthesis enclose the response data. Only four lines are displayed with the last commands and
responses.
In the example of figure 3.17, columns display metering data from two EMSeNs. The interface
provides two drop-down menus and two buttons. The drop-down menus allow to choose the command to be sent and its destination. The destination can be broadcast, to send the same command
to to all EMSeNs or the address of a specific EMSeN. The rescan button permits to identify the
available EMSeNs in the ZBeeMeR system by sending an identify broadcast request to all of them.
This request requires an EMSeN to send its unique identifier together with the energy meter serial
number.
34
Chapter 4
Tests and Results
Several tests were performed to test the ZBeeMeR system functionality, the electrical correctness of the ZigBee module, and the power emissions compliance with the IEEE 802.15.4 standard
and ranges achieved.
4.1
Module Tests
After soldering the received manufactured PCB panel, by applying solder paste, using a stencil sheet, and manually placing components, some electrical tests were performed. These tests
ensured the absence of short circuits in-between layers and chips pins, and confirmed the power
levels throughout the board.
Radio emissions were verified using a Rohde & Schwarz FS300 spectrum analyser to:
1. test for the existence of emissions out of band the 2.4GHz band;
2. test for compliance with the maximum channel center frequency deviation allowed;
3. test for compliance with the maximum channel bandwidth allowed.
Due to missing equipment for measuring power emissions from the antenna implemented on the
PCB, only the external whip antenna was used for the tests. However, since they use the same
balun results can be extrapolated.
Figure 4.1 shows power emissions for four channels over a 3GHz frequency span. Based on
that, we can conclude that all frequencies are in the 2.4GHz and no spurious emissions exist.
35
(a) Channel 1 (2405MHz)
(b) Channel 5 (2425MHz)
(c) Channel 11 (2455MHz)
(d) Channel 16 (2480MHz)
Figure 4.1: Module emissions over a 3GHz frequency span.
(a) Channel 1 (2405MHz)
(b) Channel 5 (2425MHz)
(c) Channel 11 (2455MHz)
(d) Channel 16 (2480MHz)
Figure 4.2: Module unmodulated emissions.
36
Figure 4.2 shows, in detail, the center frequency of the four channels. Table 4.1 presents the
frequency deviation for all sixteen channels. All channels have a deviation of 404Hz. As according
to the IEEE 802.15.4 standard, the maximum allowed tolerance is 100Hz, further RF tuning is
required.
Table 4.1: Deviations from the centre channel frequency.
Channel
Number
Teorical
(GHz)
Measured
(GHz)
Deviation
(Hz)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
2.4050
2.4100
2.4150
2.4200
2.4250
2.4300
2.4350
2.4400
2.4450
2.4500
2.4550
2.4600
2.4650
2.4700
2.4750
2.4800
2.404596
2.409596
2.414596
2.419596
2.424596
2.429596
2.434596
2.439596
2.444596
2.449596
2.454596
2.459596
2.464596
2.469596
2.474596
2.479596
404
404
404
404
404
404
404
404
404
404
404
404
404
404
404
404
37
Figure 4.3 shows the bandwidth used for the same four channels. All channels comply with
IEEE 802.15.4, surpassing the -30dBm absolute limit for frequencies that verify the |f − fc | >
3.5MHz condition. f is the frequency in question and fc the centre channel frequency.
(a) Channel 1 (2405MHz)
(b) Channel 5 (2425MHz)
(c) Channel 11 (2455MHz)
(d) Channel 16 (2480MHz)
Figure 4.3: Module O-QPSK modulated emissions.
To test for transmission ranges, several power measurements were realised. These tests include measurements from:
1. the TI development module;
2. the developed ZigBee module using the whip antenna;
3. the developed ZigBee module using the antenna implemented on the PCB.
Each RSSI value presented, is the average of the reception of 500 packets1 over a fixed distance
of 1 meter (table 4.2), 2 meters (table 4.3) and 5 meters (table 4.4). From the obtained values,
we conclude the performance of the developed module is similar to that of the TI module. Both
achieving communications below a 5 meters range, without noticeable packet loss. However, at
a 5 meters range with messages of 90 bytes of payload, packet loss increases. The antenna
implemented on the PCB achieves the worst range. Packet loss increases on ranges over 1 meter
and is more sensitive to the payload size, than the other antenna.
We conclude that only the whip antenna and a signal amplifier should be considered for future
implementations.
1
Packet that are loss decrease this number.
38
Table 4.2: Power measurements over a 1 meter distance.
Antenna
Type
Whip (TI)
Whip
PCB
Average
Lost
Error
RSSI (dBm) Packets (% )
30bytes of payload
-43,4
0
0,0
-40,7
0
0,0
-43,9
0
0,0
-31,7
0
0,0
-31,4
1
0,2
-32,1
0
0,0
-42,1
0
0,0
-42,1
0
0,0
-42,1
1
0,2
Average
Lost
Error
RSSI (dBm) Packets (% )
90bytes of payload
-43,8
0
0,0
-42,8
0
0,0
-43,1
0
0,0
-31,6
0
0,0
-31,8
0
0,0
-31,7
0
0,0
-42,1
0
0,0
-42,1
0
0,0
-42,1
0
0,0
Table 4.3: Power measurements over a 2 meters distance.
Antenna
Type
Whip (TI)
Whip
PCB
Average
Lost
RSSI (dBm) Packets
30bytes of payload
-53,9
0
-54,9
1
-57,2
0
-45,4
0
-45,9
0
-45,4
0
-65,6
46
-65,2
85
-64,4
79
Error
(% )
0,0
0,2
0,0
0,0
0,0
0,0
9,2
17,0
15,8
Average
Lost
RSSI (dBm) Packets
90bytes of payload
-57,4
1
-57,7
1
-58,2
1
-45,6
0
-45,8
0
-45,2
0
-66,2
95
-65,8
136
-65,8
130
Error
(% )
0,2
0,2
0,2
0,0
0,0
0,0
19,0
27,2
26,0
Table 4.4: Power measurements over a 5 meters distance.
Antenna
Type
Whip (TI)
Whip
Average
Lost
Error
RSSI (dBm) Packets (% )
30bytes of payload
-57,2
1
0,2
-63,8
4
0,8
-56,8
1
0,2
-63,1
5
1,0
-61,2
3
0,6
-62,5
9
1,8
39
Average
Lost
Error
RSSI (dBm) Packets (% )
90bytes of payload
64,5
4
0,8
61,5
6
1,2
65,8
6
1,2
61,6
15
3,0
66,1
25
5,0
59,8
36
7,2
4.2
ZBeeMeR Tests
To validate the network functionality, the message routing, the possibility to increase coverage
with network extender nodes, and the adequacy of ZigBee for AMI, the ZBeeMeR system was
set-up. It consisted of a network with four nodes distributed on a building floor, as presented on
figure 4.42 . The network includes two EMSeNs, a network extender node and the concentrator.
The network extender node, situated in the corridor, assures that the data from EMSeN 1 arrives
at the concentrator.
Figure 4.4: Prototype network structure with nodes location.
The first three tests permit to validate the network configuration, and the last three the functionality. Appendix D presents the packets exchanged between the four nodes. For testing purposes,
the web interface is used to send requests and to display metering values. The metering values
returned from requests sent to the EMSeN were confirmed by the energy meter LCD display.
Test 1. Activation of the concentrator and EMSeN 1: no network association occurred because they
are out of range.
Test 2. Introduction of a network extender node: metering data from EMSeN 1 arrived at the concentrator.
Test 3. Activation of EMSeN 2: metering data arrived at the concentrator.
Test 4. Metering data requested to all nodes (using a broadcast message): EMSeN 1 and EMSeN 2
replied with the requested data.
Test 5. Metering data requested only to EMSeN 2 (using a unicast message): EMSeN 2 replied.
2
This plant represents the third floor, right section, of the Inesc-ID building.
40
Test 6. Metering data, not requested, received from both EMSeNs: EMSeNs had started autonomously
sending metering data at the pre-programmed periodicity.
Test 4 and 5 show that measurements can be requested to a single EMSeN or to the whole
network. It also validated the routing of messages. Test 6 demonstrates the autonomous behaviour
of EMSeNs.
We can conclude that the ethernet functionality works and can give access to concentrators
locally stored data. Also permitting remote measurement requests to energy meters.
41
42
Chapter 5
Conclusions
The main objective of this work was to propose and develop an AMI/AMR system, using a
WSN based on a ZigBee mesh, easily integrable into an existing utility infrastructure and using
commercially available energy meters. A small low power ZigBee module, that fits inside an energy
meter casing and connects to it via a RS-232 interface, was successfully built. The developed
system permits bi-directional communication between the meters and the utility. Metering data can
be accessed from a web page.
In the course of this work the specific objectives were reached and some conclusions were
taken:
- Commercially available ZigBee products were analysed, allowing to choose a cost effective
chip to integrate the developed ZigBee module.
- Commercial energy meters were analysed, permitting to conclude that several implement the
IEC 62056-21 standard through a RS-232 interface.
- Two antennas, a PCB antenna and a whip antenna, were implemented on the module. Power
emission measurements permit to conclude that the whip antenna achieves higher transmission ranges. However, its indoor range was around 5 meters and highly affected by big
metallic structures, such as, book shelves or elevator shafts. As a consequence, a signal
amplifier should be considered for future implementations.
- The voltage of 5V, available inside some energy meters, was initially considered to power the
ZigBee module. However, this alternative requires inner access to the energy meter, affecting
its certification. A solution to use the electric grid (220V AC) to generate the DC power supply
must be analysed.
- Rechargeable batteries were analysed, leading to conclude that Nickel-metal Hydride (NiMH) batteries are the appropriate solution. We adopted a very simple charging circuit due
to the low power nature of the module and because batteries are only necessary when the
electric grid fails.
We concluded that ZigBee is suitable to implement the bi-directional communications of an
AMI/AMR system. Furthermore, installation costs can be reduced by using Energy Meter Sensor
Nodes (EMSeNs) with routing capabilities, and a unique concentrator to aggregate metering data.
The developed prototype validated the proposed architecture and the ZBeeMeR system functionality. Simplifications done for prototyping purposes do not incur in loss of generality, regarding a
43
real system implementation, for the following reasons: EMSeNs and network extender nodes only
need small improvements (further RF tuning is required); the concentrator requires more rework,
since in the final architecture it is an embedded system and, in the prototype, we use a PC connected to a ZigBee module. Due to the resources gap between a PC and an embedded system,
the majority of the developed code has to be adapted and rewritten. For integration into an existing utility infrastructure, the communication protocols have to be analysed and implemented in the
concentrator.
5.1
Future Work
Future work can focus on enhancing and extending the developed prototype to become more
accordant with the proposed ZBeeMeR system or integrate new solutions and ideas. A good start
would be finding answers to the following questions: is it possible to eliminate network extender
nodes analysis by using a RF signal amplifier; how to use the electric grid (220V AC) to generate
the DC power supply; how to use green alternatives to rechargeable batteries.
Additionally, system performance and coverage tests with large networks, to understand the
influence of the location of energy meters in a building, need to be performed.
We are currently improving the ZBeeMeR system, to permit to use it in a real world implementation. A simple AC/DC converter was successfully tested and is able to power a ZigBee module with
a RF signal amplifier, while fitting inside a meter casing. Also, a concentrator, integrating ZigBee
and a WAN interface, was designed.
44
Bibliography
[1] Dickerman, L. and Harrison, J., “A New Car, a New Grid,” Power and Energy Magazine, IEEE,
vol. 8, no. 2, pp. 55–61, Mar./Apr. 2010.
[2] Clement-Nyns, K. and Haesen, E. and Driesen, J., “The Impact of Charging Plug-In Hybrid
Electric Vehicles on a Residential Distribution Grid,” in Power Systems, IEEE Transactions,
vol. 25, no. 1, Atlanta, GA, Feb. 2010, pp. 371–380.
[3] Li, F. and Lima, J., “Network charges for micro-generation,” in Power and Energy Society
General Meeting - Conversion and Delivery of Electrical Energy in the 21st Century, 2008
IEEE, Pittsburgh, PA, Jul. 20–24, 2008, pp. 1–5.
[4] Zpryme Research & Consulting, LLC, “Smart Appliances,” Smart Grid Insights, Mar. 2010.
[5] David G. Hart and Ron D. Pate, “AMI and Realising the Distribution Smart Grid,” Metering
International, no. 2, 2010.
[6] M. Choi, S. Ju, and Y. Lim, “Design of integrated meter reading system based on power-line
communication,” in Power Line Communications and Its Applications, 2008. ISPLC 2008. IEEE
International Symposium, Apr. 2008, pp. 280–284.
[7] D.-E. Lee, D.-S. In, J.-J. Lee, Y.-J. Park, K.-H. Kim, J.-T. Kim, and S.-G. Shon, “A field trial of
medium voltage power line communication system for amr and das,” in Transmission Distribution Conference Exposition: Asia and Pacific, 2009, Oct. 2009, pp. 1 –4.
[8] Q. Liu, B. Zhao, Y. Wang, and J. Hu, “Experience of amr systems based on bpl in china,”
in Power Line Communications and Its Applications, 2009. ISPLC 2009. IEEE International
Symposium, Mar. 2009, pp. 280 –284.
[9] S. Khan, R. Islam, O. Khalifa, J. Omar, A. Hassan, and I. Adam, “Communication system for
controlling smart appliances using power line communication,” in Information and Communication Technologies, 2006. ICTTA ’06. 2nd, vol. 2, 2006, pp. 2595–2600.
[10] C. Smallwood, “Power quality issues relating to power line carrier automated meter reading
technology,” in Rural Electric Power Conference, 2001, 2001, pp. B1/1 –B1/8.
[11] Yujun Bao and Xiaoyan Jiang, “Design of Electric Energy Meter for Long-distance Data Information Transfers which based upon GPRS Technology,” in Intelligent Systems and Applications, 2009. ISA 2009.International Workshop, Wuhan, China, May 23–24, 2009, pp. 1–4.
[12] Gao Fuxiang and Xue Wenxin and Liu Langtao, “Design of Electric Energy Meter for Longdistance Data Information Transfers which based upon GPRS Technology,” in Industrial and
Information Systems (IIS), 2010 2nd International Conference, vol. 2, Dalian, China, Jul. 10–
11, 2010, pp. 270–273.
45
[13] Anderson, M., “WiMax for smart grids,” Spectrum, IEEE, vol. 47, no. 7, p. 14, Jul. 2010.
[14] Li Li and Xiaoguang Hu and Weicun Zhang, “Design of an ARM-based power meter having
WIFI wireless communication module,” in Industrial Electronics and Applications, 2009. ICIEA
2009. 4th IEEE Conference, Xi’an, China, May 25–27, 2009, pp. 403–407.
[15] “A socio-economic analysis of wimax,” in Application of Information and Communication Technologies, 2009. AICT 2009. International Conference, Oct. 2009, pp. 1 –6.
[16] Koay, B.S. and Cheah, S.S. and Sng, Y.H. and Chong, P.H.J. and Shum, P. and Tong, Y.C.
and Wang, X.Y. and Zuo, Y.X. and Kuek, H.W., “Design and implementation of Bluetooth
energy meter,” in Information, Communications and Signal Processing, 2003. 4th International
Conference, vol. 3, Dec. 15–18, 2003, pp. 1474–1477.
[17] Peng Xuange and Xiao Ying, “An Embedded Electric Meter Based on Bluetooth Data Acquisition System,” in Education Technology and Computer Science (ETCS), 2010 Second
International, Wuhan, China, Mar. 6–7, 2009, pp. 667–670.
[18] Al-Kassem, I. and Sharafeddine, S. and Dawy, Z., “BlueHRT: Hybrid Ring Tree Scatternet
Formation in Bluetooth Networks,” in Computers and Communications, 2009. ISCC 2009.
IEEE Symposium, Sousse, Tunisia, Jul. 5–8, 2009, pp. 165–169.
[19] Alkhrabash, A.-A.S. and Elshebani, M., “Routing schemes for bluetooth scatternet applicable
to mobile ad-hoc networks,” in Telecommunication in Modern Satellite, Cable, and Broadcasting Services, 2009. TELSIKS ’09. 9th International Conference, Niš, Serbia, Oct. 7–9, 2009,
pp. 560–563.
[20] Jingjing Wang, “A new formation algorithm of Bluetooth Ad hoc networks,” in Control and
Decision Conference, 2009. CCDC ’09. Chinese, Guilin, China, Jun. 17–19, 2009, pp. 1291–
1295.
[21] T. Arnewid, “Ami in the city of goteborg,” Metering International, no. 4, pp. 76–79, 2007.
[22] N.Escravana, R.Lascas, M.Nunes, C.Anjos, H.Sarmento, A.Casaca, T.Silva, J.Lageira, and
J.Moreira, “Proposta de arquitectura,” Projecto Arquitectura de Comunicações do INOVGRID,
INOV, Tech. Rep. 0.8, Nov. 2008.
[23] ZigBee Alliance. (2010, Mar.) Timelox ab with zigbee; increasing hotel security worldwide.
ZigBee Success Stories. [Online]. Available:
http://www.zigbee.org/imwp/download.asp?
ContentID=15272
[24] ZigBee Alliance. (2009) Awarepoint with zigbee improve patient care and the bottom
line. ZigBee Success Stories. [Online]. Available: http://www.zigbee.org/imwp/download.asp?
ContentID=15796
[25] ZigBee Alliance. (2010, Mar.) Landis+gyr and zigbee advanced metering for the intelligent
electric grid. ZigBee Success Stories. [Online]. Available:
http://www.zigbee.org/imwp/
download.asp?ContentID=15796
[26] ZigBee Alliance. (2009, Apr.) ZigBee Alliance Plans Further Integration of Internet Protocol
Standards. Pdf. [Online]. Available: http://zigbee.org/imwp/idms/popups/pop_download.asp?
contentID=15754
46
[27] ZigBee Alliance. (2010, Mar.) ZigBee and Wi-Fi Alliances to Collaborate on Smart Grid
Wireless Networking. Pdf. [Online]. Available:
http://zigbee.org/imwp/idms/popups/pop_
download.asp?contentID=17400
[28] L. Hui, “A meter reading system based on wsn,” in Optics Photonics and Energy Engineering
(OPEE), 2010 International Conference, vol. 1, May 2010, pp. 311 –314.
[29] S. De-chao and Z. Shao-hua, “Resarch and design of meter reading system,” in Circuits,
Systems, Signal and Telecommunications (CISST). 2009 3rd International Conference, 2009.
[30] H. Y. Tung, K. F. Tsang, and K. L. Lam, “Zigbee sensor network for advanced metering infrastructure,” in Consumer Electronics (ICCE), 2010 Digest of Technical Papers International
Conference, Jan. 2010, pp. 95 –96.
[31] S.-W. Luan, J.-H. Teng, S.-Y. Chan, and L.-C. Hwang, “Development of a smart power meter
for ami based on zigbee communication,” in Power Electronics and Drive Systems, 2009.
PEDS 2009. International Conference, Nov. 2009, pp. 661 –665.
[32] ZigBee Alliance, “ZigBee Specification,” ZigBee Document 053474r17, Jan. 2008.
[33] “Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for LowRate Wireless Personal Area Networks (WPANs),” IEEE Std 802.15.4™-2006, Sep. 2006.
[34] ZigBee Alliance, “ZigBee Cluster Library Specification,” ZigBee Document 075123r01, Oct.
2007.
[35] “ZigBee Smart Energy Profile™ 2.0 Technical Requirements Document,” ZigBee Document
095449 Draft, Dec. 2009.
[36] G. Mulligan, “The 6lowpan architecture,” in EmNets ’07: Proceedings of the 4th workshop on
Embedded networked sensors.
New York, NY, USA: ACM, 2007, pp. 78–82.
[37] “MC13224V Technical Data, Rev. 1.2,” Doc. MC1322x, Freescale Semiconductor, p. 50, Feb.
2009.
[38] “Manufacturing with the Land Grid Array Package,” Application Note AN2920, Freescale Semiconductor, p. 16, 2008.
[39] “JN5139 Data Sheet, Rev. 1.6,” Jennic, p. 85, Sep. 2008.
[40] “EM250 Data Sheet, Rev. 2.1,” Doc. 120-0082-000I, Ember, p. 117, Jul. 2006.
[41] “CC2430 Data Sheet, Rev. 2.1,” Doc. SWRS036F, Texas Instruments, p. 211, May 2007.
[42] D. H. J. Zhang, “Linear regulator and switching mode power supply basics,” in Embedded
Systems Conference (ESC), Apr. 2006.
[43] “Linear Regulators in Portable Applications,” Application Note 751, Maxim/Dallas, p. 11, 2001.
[44] T. Nass and A. Andersen, “Powering Low-Power RF Products,” Texas Instruments, Design
Note DN019, 2009.
[45] Simjee, F.I. and Chou, P.H., “Everlast: Long-life, Supercapacitor-operated Wireless Sensor
Node,” in Low Power Electronics and Design, 2006. ISLPED’06, Tegernsee, Oct. 4–6, 2006,
pp. 197–202.
[46] C. Park and P. Chou, “AmbiMax: Autonomous Energy Harvesting Platform for Multi-Supply
Wireless Sensor Nodes,” in Sensor and Ad Hoc Communications and Networks, 2006.
SECON ’06., vol. 1, Reston, VA, Sep. 28, 2006, pp. 168–177.
47
[47] Sogorb, T. and Llario, J.V. and Pelegri, J. and Lajara, R. and Alberola, J., “Studying the Feasibility of Energy Harvesting from Broadcast RF Station for WSN,” in Instrumentation and
Measurement Technology Conference Proceedings, 2008. IMTC 2008. IEEE, Victoria, BC,
May 12–15, 2008, pp. 1360–1363.
[48] Seah, W.K.G. and Zhi Ang Eu and Hwee-Pink Tan, “Wireless Sensor Networks Powered by
Ambient Energy Harvesting (WSN-HEAP) - Survey and Challenges,” in Wireless VITAE 2009,
Aalborg, May 17–20, 2009, pp. 1–5.
[49] I. Buchmann, Batteries in a Portable World, 2nd ed.
Cadex Electronics Inc, 2001.
[50] Panasonic, “Nickel Metal Hydride Batteries,” Aug. 2005.
[51] R. Wallace, “Antenna Selection Guide,” Texas Instruments, Application Note AN058, 2009.
[52] N. R. Subramanian and N. Kirkeby, “Anaren 0404 (BD2425N50200A00) balun optimized for
Texas Instruments CC2430 Transceiver,” Anaren, Balun Application Note ANN-2002, Aug. 31,
2007.
[53] G. E. Jonsrud, “Folded dipole antenna for CC2400, CC2420, CC2430, CC2431, and CC2480,”
Texas Instruments, Application Note AN040, 2008.
[54] A. Andersen, “2.4 GHz Inverted F Antenna,” Texas Instruments, Design Note DN0007, 2008.
[55] A. Andersen, “Small Size 2.4 GHz PCB antenna,” Texas Instruments, Application Note AN043,
2008.
[56] K. Mitzner, Complete PCB Design Using OrCad Capture and Layout, Elsevier, Ed.
Newnes,
2007.
[57] K. Mitzner, Complete PCB Design Using OrCad Capture and Layout.
Newton, MA, USA:
Newnes, 2007.
[58] IEC TC 13, “EN 62056-21, Electricity metering - Data exchange for meter reading, tariff and
load control - Part21: Direct local data exchange,” International Electrotechnical Commission,
CENELEC, Brussels, Standard CEI/IEC 62056-21:2002, 2002.
[59] Texas Instruments, “Z-Stack Developer’s Guide,” Document F8W-2006-0022, 2007.
48
Appendices
49
Appendix A
ZigBee Solutions for Product
Development
This appendix is the result of a survey done in order to choose the chip upon which the ZigBee
module would be built and to understand the current market state of the ZigBee technology. The
ZigBee Alliance website provided information about the companies involved with ZigBee technology.
The survey focused hardware solutions here organised in four tables. Table A.1 presents available integrated circuits. Detailed information about the chips is presented in table A.2. Table A.3
describes the development kits indicating the hardware platform they use, their features and their
cost. Finally, table A.4 aggregates information about standalone modules. Modules are surface
mountable PCBs with integrated circuits and the basic circuitry required to make them functional.
We conclude that there are four major ZigBee chips manufacturers, Ember, Jennic, Texas
Instruments (TI) and Freescale. Development kits exhibit great diversity in terms of features and
software, and normally provide a stack that implements the IEEE 802.15.4, ZigBee, or some proprietary protocol. They are usually intended to develop a particular integrated circuit. Standalone
modules ease development of new ZigBee solutions by providing RF certification while allowing
flexibility to choose antenna connectors and transmit power levels.
51
52
CC2431
MC13202
MC13224V
MC13213
MRF24J40
Texas Instruments
Freescale
Freescale
Freescale
MicroChip
CC2430
Texas Instruments
MG2455-F48
RadioPulse
CC2520
MG2450
RadioPulse
Texas Instruments
MG2400-F48
RadioPulse
CC2420
ML7246
OkiSemi
CC2480
ML7065
OkiSemi
Texas Instruments
AT86RF212
Atmel
Texas Instruments
AT86RF231
Atmel
JN5139
AT86RF230
Atmel
Jennic
EM260
Ember
JN5121
EM250
Jennic
Transceiver
UZ2400
UBEC
Ember
Transceiver
SiP
PiP
Transceiver
SoC
SoC
Transceiver
Transceiver
Co-processor
SoC
SoC
SoC
SoC
SoC
Transceiver
Transceiver
Transceiver
Transceiver
Transceiver
Co-processor
SoC
Type
Designation
Manufacturer
2.4GHz RF transceiver. SPI interface.
MC13202 transceiver and MC9S08GT MCU. 60kBs flash, 4kBs of RAM
and 80kBs ROM for bootcode, device drivers and stack. JTAG interface.
2.4GHz RF transceiver with 32bit TDMI ARM7. 128kBs flash, 96kBs of RAM
2.4GHz RF transceiver. SPI interface.
Same as previous with hardware location engine.
RAM.
2.4GHz RF transceiver with a 8-bit MCU. 32/64/128kBs flash and 8kBs of
face.
Second generation 2.4GHz RF transceiver. Improved selectivity. SPI inter-
2.4Ghz RF transceiver. SPI interface.
2.4GHz RF transceiver with a MCU for stack. SPI or UART interface.
of ROM. 48byte one-time programmable memory.
2.4GHz RF transceiver with a 32-bit RISC MCU. 96kBs of RAM and 192kBs
of ROM.
2.4GHz RF transceiver with a 32-bit RISC MCU. 96kBs of RAM and 64kBs
Same as previous but different package
boot rom. Voice codecs. SPI interface.
2.4 RF transceiver with 8-bit MCU. 96kBs flash and 8kBs of RAM. 1kBs
2.4GHz RF transceiver with 8-bit MCU. 64kBs flash and 4kBs of RAM.
2.4GHz RF. USB 2.0 interface.
2.4 GHz RF. SCI interface.
800/900MHz RF. SPI interface.
Equal to previous but with AES dedicated hardware.
2.4 GHz RF without AES hardware. Has SPI interface.
Application must be on another MCU.
2.4GHz RF transceiver with a MCU for running the EmberZNet ZigBee stack.
2.4GHz RF transceiver with a 16-bit MCU. 128kBs flash and 5kBs of RAM.
2.4GHz RF with SPI interface.
Description
Table A.1: ZigBee chip solutions.
40-pin QFN 6x6mm
71-pin LGA 9x9mm
99-pin LGA 9.5x9.5mm
32-pin QFN 5x5mm
48-pin QFN 7x7mm
48-pin QLP 7x7mm
28-pin QFN 5x5mm
48-pin QLP 7x7mm
48-pin QFN 7x7mm
56-pin QFN 8x8mm
56-pin QFN 8x8mm
48-pin QFN 7x7mm
72-pin VFBGA 5x5mm
48-pin QFN 7x7mm
48-pin WQFN
48-pin VQFN
32-pin QFN
32-pin QFN
32-pin QFN
40-pin QFN 6x6mm
48-pin QFN 7x7mm
40-pin QFN 6x6mm
Package
$3
$7
$5
$5
$11
$10
$6
$6
$14
$15
$20
-
-
-
$6
$5
$7
$6
$6
$10
$10
-
Price
53
(2.4GHz)
SiP
(2.4GHz and 8bit)
Transceiver
(2.4GHz)
MC13213
Freescale
MC13202
MC13212
Freescale
SiP
(2.4GHz and 8bit)
Freescale
PiP
(2.4GHz and 32bit)
(2.4GHz)
CC2420
Freescale
Transceiver
Texas
MC13224V
SoC
(2.4GHz and 8bit)
Texas
CC2430
SoC
Transceiver
Texas
CC2520
(2.4GHz and 8bit)
(2.4GHz)
CC2480A1
Texas
Co-processor
Texas
CC2431
SoC
(2.4GHz and 32bit)
Jennic
JN5139
SoC
(2.4GHz and 32bit)
Jennic
(2.4GHz)
JN5121
Transceiver
(2.4GHz and 16bit)
EM260
Ember
Co-processor
Ember
EM2420
SoC
(2.4GHz and 16bit)
Ember
Type
EM250
Reference
Manufacturer/
-
60
32
(see text)
128 + 80
-
32/64/128
128
-
128
(ROM)
192
64
-
-
128
(kBs)
EPROM
-
4
2
96
-
8
8
-
8
96
96
-
-
5
(kBs)
RAM
No
No
No
Yes
Yes
Yes
Yes
Yes
Partial
Yes
Yes
Yes
Yes
Yes
hardware
MAC
No
No
No
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
hardware
AES
40
40
40
22
18,8
27
27
18,5
27
34
50
19,7
35,5
28
(mA)
Rx Current
35
35
35
29
17,4
27
27
25,8
27
34
45
17,4
35,5
24
(mA)
Tx Current
Table A.2: Detailed information of ZigBee single chip solutions.
3
3
3
4
0
0
0
4
0
3
0
0
2,5
3
(dbm)
Tx Power
5X5mm
32-pin QFN
9X9mm
71-pin LGA
9X9mm
71-pin LGA
9.5x9.5mm
99-pin LGA
7X7mm
48-pin QLP
7X7mm
48-pin QLP
7X7mm
48-pin QFN
5x5mm
28-pin QFN
7X7mm
48-pin QFN
8x8mm
56-pin QFN
8x8mm
56-pin QFN
7x7mm
48-pin QLP
6x6mm
40-pin QFN
7x7mm
48-pin QFN
Package
$5
$7
$5
$12
$6
$10
$11
$6
$14
$15
$20
$8
$10
$10
Price
54
EM250-DEV
EM250-EK-R
Ember
Ember
-
-
-
EM250-JMP-R
Ember
UZ2400
-
78K0 UZ Stick
NEC Electronics
UZ2400
UZ2400
UZ2400
UZ2400
Transceiver
Skyley
78k0R UZ Stick
TK-78K0/KF2+UZ
TK-78K0R/KG3+UZ
NEC Electronics
NEC Electronics
TK-850/SG2+UZ
NEC Electronics
NEC Electronics
Reference
Manufacturer
-
-
-
-
78K0/KE2
78K0/KF2
78K0R/KE3
78K0R/KG3
V850ES/SG2
Micro-Controller
-
EM250/EM260
EM250/EM260
-
-
-
-
-
-
SoC
$500
$10.000
$2.500
$1.300
-
-
-
-
-
Price
Continues on next page
USB Cables Antennas InSight Desktop Software User Guide
Radio Module with Carrier Board AA batteries Power supply
fessional Edition xIDE Compiler Training:One day one person
EM250/EM260 Chips Software: 1license InSight Desktop Pro-
Cable 1x 16 Port Switch w/ 8 x POE ports Sample Chips: 10x
ble 8x Power Supplies and Battery Pack 8x Extended Debug
InSight Adapter 1x MC Card to SMA Cable 8x InSight Port Ca-
Board 8x EM250/EM260 Breakout Board 8x EM250/EM260
Hardware: 8x EM250/EM260 Radio Control Modules (RCM)
veloper Edition xIDE Compiler
EM250/EM260 Chips Software: 1license InSight Desktop De-
Cable 1x 8 Port Switch w/ 4 x POE ports Sample Chips:10x
ble 3x Power Supplies and Battery Pack 3x Extended Debug
InSight Adapter 1x MC Card to SMA Cable 3x InSight Port Ca-
Board 3x EM250/EM260 Breakout Board 3x EM250/EM260
Hardware: 3x EM250/EM260 Radio Control Modules (RCM)
need of programing Uses NECEL/SKYLEY ZigBee stack
SDK and applications that can configure networks without the
8bit CPU, 128KB Flash, 7KB RAM
bugger, and IEEE MAC stack
8bit CPU, 128KB Flash, 7KB RAM Compiler (32KB max), de-
16bit CPU, 256KB Flash, 12KB RAM
debugger and IEEE MAC stack
16bit CPU, 512KB Flash, 30KB RAM, Compiler (64KB max),
library
Debugger, TCP/IP HTTP, SMTP, POP3 and IEEE MAC stack
32bit CPU, 384KB Flash, 32KB Ram Compiler (128KB max),
Description
Table A.3: ZigBee development kits.
55
Reference
MNZB-DKL-24
MNZB-DKC-24
MNZB-DKL-A24
MNZB-DKC-A24
OKI-ZDK
MG245X-ZDK
Manufacturer
MeshNetics
MeshNetics
MeshNetics
MeshNetics
Okisemi
RadioPulse
-
ML7065
AT86RF230
AT86RF230
AT86RF230
AT86RF230
Transceiver
-
ML67Q4061
ATMega1281v
ATMega1281v
ATMega1281v
ATMega1281v
Micro-Controller
MG2455/ MG2450
-
-
-
-
-
SoC
XPORT device installer,
$4.000
$500
$900
$400
$900
$400
Price
Continues on next page
Device-Programmer, CP2101 Driver, CP2101 USB ID SET,
Software: Profile-Simulator, Profile-Builder, Packet-Analyzer,
lyzer adapter 2x Ethernet Cable 2x XPORT (Serial to Ethernet)
and 3 4dBi) 2x 9-pin RS-232 Serial Cable 1x Packet Ana-
bles 2x 5V DC Adapters 6x Dipole Antennas (3 with 2dBi
25x ZigBee Single Chip (MG2455 or MG2450) 6x Usb ca-
6x PC Interface Board (MG245X-EVB 6x Chip Interface Board
bench for ARM Segger’s embOS RTOS
Daintree’s Network Analyzer software IARs Embedded Work-
ZigBee stack for Oki’s ARM7 based 4050/4060 series MCUs
- IEEE802.15.4 USB radio dongles Evaluation versions of:
1x - Oki ZigBee Network Evaluation/Demo (zNED) board 2x
SerialNet Extensions (make your own)
acess to new software, Gerber Files, bootloader source code.
Same has previous one, but offers more support (1year). Early
support
mands) and WSN Monitor) & documentation CD 45 days of
2 x external interface cables 1 x software(SerialNet(AT com-
modules mounted on MeshBean Amp boards 2 x USB cables
2 x MeshBean Amp development boards 2 x ZigBit Amp OEM
SerialNet Extensions (make your own)
acess to new software, Gerber Files, bootloader source code.
Same has previous one, but offers more support (1year). Early
mentation CD 45 days of support
ware(SerialNet(AT commands) and WSN Monitor) & docu-
boards 3 x USB cables 2 x external interface cables 1 x soft-
tenna types 3 x ZigBit OEM modules mounted on MeshBean
3 x MeshBean development boards featuring different an-
Description
Table A.3: ZigBee development kits − continued.
56
Reference
MG245X-EVK
JN5139-EK000
JN5121-EK010
JN5121-EK020
ZigBee-2.4-DK
802.15.4-2.4-DK
Manufacturer
RadioPulse
Jennic
Jennic
Jennic
Slicon Labs
Silicon Labs
-
-
-
-
-
-
Transceiver
-
-
-
-
-
-
Micro-Controller
C8051F121
C8051F121
JN5139
JN5139
JN5139
MG2455/MG2451
SoC
bundle software with demonstrations
$365
$950
$220
$500
$450
-
Price
Continues on next page
versions of Keil compiler, assembler and linker. Drivers and
comm stack Silicon Labs IDE (free to download). Evaluation
USB cables 2x 9V batteries Software: MAC firmware Heli-
nas 1x Power supply (9V, 1.5A) 1x USB debug adapter 2x
2x 2.4GHz 802.15.4/ZigBee development boards with anten-
bundle software with demonstrations
versions of Keil compiler, assembler and linker. Drivers and
comm stack Silicon Labs IDE (free to download). Evaluation
USB cables 6x 9V batteries Software: MAC firmware Heli-
nas 1x Power supply (9V, 1.5A) 1x USB debug adapter 2x
6x 2.4GHz 802.15.4/ZigBee development boards with anten-
MAC Free SDK
2x USB cables. Software: JenNet stack (C API) AT-Jenie IEEE
3x Sensor Board Module with ceramic antenna RS23 Batteries
libraries
The same but with ZigBee stack instead of the JenNet network
Networks Sensor Network Analyser (trial)
controller and peripheral libraries Code::Block(IDE) Daintree
flash programmer) Software: JenNet network libraries, micro-
ules GNU-based toolchain (ansi C, C++ compiler, debugger,
Controller Board 4x Sensors Board USB 2x High Power mod-
device installer,
Programmer, CP2101 Driver, CP2101 USB ID SET, XPORT
pin RS-232 Serial Cable 2x Ethernet Cable Software: Device-
bles 2x 5V DC Adapters 6x Dipole Antennas (2dBi)) 2x 9-
25x ZigBee Single Chip (MG2455 or MG2450) 2x Usb ca-
2x PC Interface Board (MG245X-EVB 2x Chip Interface Board
Description
Table A.3: ZigBee development kits − continued.
57
CC2520DK
XB24-BPDK-W
Digi
Texas
EZDK 1220PA
Helicomm
XB24-DMDK
DAUB-DK1 2400
Silicon Labs
Digi
Reference
Manufacturer
CC2520
MC9S08GT60
MC9S08GT60
-
-
Transceiver
MSP430F2618
MC13192
MC13192
C8051F121
-
Micro-Controller
-
-
-
-
-
SoC
$650
-
$350
$2.700
$152
Price
Continues on next page
limited edition of IAR Embedded Workbench (IAR Kickstart)
bug interface 3 x USB cables Documents A free, code size
Antennas 2 x CCMSP-EM430F2618 1x MSP-FET430UIF de-
3 x SmartRF®05EB 3 x CC2520EM evaluation modules 3 x
Various Adapters
GHz RPSMA Antennas 2x Power Adapter 2x 9V Battery Clip
opment boards 2x RS-232 serial cables 2x USB cables 2x 2.4
wire antenna s 2x RS-232 development boards 2x USB devel-
PRO DigiMesh 2.4 w/ U.fl connector 2x XBee DigiMesh 2.4 w/
1x XBee-PRO DigiMesh 2.4 w/ RPSMA connector 1x XBee-
Cables 1x Power Adapter 3x 9V Battery Clips 3x Adapters
U.fl to RPSMA Adapter Cable 3x RS-232 Serial Cables 2x USB
2x USB Development Boards 3x 2.4 GHz RPSMA Antenna 1x
RPSMA Connector (Router) 3x RS-232 Development Boards
w/ U.fl Connector (Router) 2x XBee-PRO ZB/ZNet 2.5 w/
ZB/ZNet 2.5 w/ Chip Antenna (Router) 1x XBee ZB/ZNet 2.5
1x XBee ZB/ZNet 2.5 w/ Wire Antenna (Coordinator) 1x XBee
quired cables and power supplies
API specifications, networking examples and tutorials All re-
plified) WIN-View Networking Management SoftWare Module
6x PC Interface Board with integral IP-Link 1220PA (power am-
faces.
a ZigBee network and expose the AF/ZDO Application Inter-
terface. The ZigBee drivers allow the dongle to operate within
802.15.4 drivers provide direct access to the 802.15.4 MAC in-
The dongle is available with a choice of two driver options: The
yser software drivers.
2x OEM-DAUB1 2400 ZigBee USB Dongles. Protocol anal-
Description
Table A.3: ZigBee development kits − continued.
58
1320x DK
1321xDSK
Freescale
CC2431ZDK
Texas
Freescale
CC2430ZDK
Texas
EZ430-RF2480
CC2420MSP430ZDK
Texas
Texas
Reference
Manufacturer
-
MC13202
CC2480
-
-
CC2420
Transceiver
-
-
MSP430F2274
-
-
MSP430FG4618
Micro-Controller
MC13213
-
-
CC2431
CC2430
-
SoC
$250
$100
$100
$2.000
$1.500
$320
Price
Continues on next page
evaluation of Bee-Stack Batteries, Cables and Power Adapters
tenna CodeWarrior Special Edition IDE BeeKit with 90-day
acceleration sensor and temperature sensor Printed F an-
2x 1321x-SRB (Sensor Reference Board) MMA7260Q 3-axis
Guide This is an hardware only Daughter Card
Transceiver Printed F antenna SMA connection CD and User’s
1320x-RFC RF daughter card MC13202 2.4 GHz RF
LEDs Interruptible push button for application control
general-purpose digital I/O pins connected to green and red
ment pins Highly integrated, ultra-low-power MSP430 MCU 2x
(eZ430-BB) 4x AAA batteries 5x available GPIO develop-
gle interface (MSP-eZ430U) 2x powered by battery boards
3x ZigBee Nodes (eZ430-RF2480 Target Boards) 1x USB don-
from Daintree
(30+60 days evaluation license.) Sensor Network Analyzer
and cables IAR EW8051 C-compiler with C-SPY debugger
10x Battery Boards for use with the CC2431EMs Antennas
Demonstration Boards 10x CC2431EM Evaluation Modules
Boards 2x CC2430EM Evaluation Modules 5x CC2430DB
TI’s ZigBee stack, Z-Stack 2x SmartRF04EB Evaluation
cense.) Sensor Network Analyzer from Daintree
C-compiler with C-SPY debugger (30+60 days evaluation li-
Demonstration Boards Antennas and batteries IAR EW8051
Boards 2x CC2430EM Evaluation Modules 5x CC2430DB
TI’s ZigBee stack, Z-Stack 2x SmartRF04EB Evaluation
stacks
Free software and trial ones, network analyzers, packet snifer,
MSP430 Experimenter Board 1x Programmer
TI’s ZigBee stack, Z-Stack for MSP430 1x CC2420EMK 2x
Description
Table A.3: ZigBee development kits − continued.
59
1322xDSK-DBG
1322xNSK-DBG
1322xNSK-IAR
Freescale
Freescale
Freescale
1321xEVK
Freescale
1322x-USB Kit
1321xNSK-BDM
Freescale
Freescale
1321xNSK
Freescale
1321xEVK-SFTW
1321xDSK-BDM
Freescale
Freescale
Reference
Manufacturer
-
-
-
-
-
-
-
-
-
Transceiver
-
-
-
-
-
-
-
-
-
Micro-Controller
MC13224V
MC13224V
MC13224V
MC13224V
MC13213
MC13213
MC13213
MC13213
MC13213
SoC
Same but with IAR 256KB edition
$2.600
$580
$380
$80
$3.300
$1.750
$550
$500
$350
Price
Continues on next page
Bee-Stack Daintree Analyzer SoftWare J-Link JTAG Debugger
1322x-USB IAR 32KB Edition Beekit with 90-day evaluation of
work Coordinator Board) 1x 1322x-LPB (Low Power Board) 1x
1x 1321x-SRB (Sensor Reference Board) 1x 1321x-NCB (Net-
work Coordinator Board) J-Link JTAG Debugger
1x 1321x-SRB (Sensor Reference Board) 1x 1321x-NCB (Net-
to function packet sniffer
BeeStack Batteries, Cables and Power Adapters Programmed
1322x-USB IAR 32KB Edition BeeKit with 90-day evaluation of
Warrior Standard Edition IDE
The same but has: BeeKit Full Node Locked Version Code-
Adapters
Stack Daintree Standard Edition Batteries, Cables and Power
Special Edition IDE BeeKit with 90-day evaluation of Bee-
work Coordinator Board) USB Multilink BDM CodeWarrior
4x 1321x-SRB (Sensor Reference Board) 3x 1321x-NCB (Net-
bug
The same with USB system that permits programming and de-
Cables and Power Adapters
tion IDE BeeKit with 90-day evaluation of Bee-Stack Batteries,
playing messages Printed F antenna CodeWarrior Special Edi-
work Coordinator Board) Programmable 2-line LCD for dis-
2x 1321x-SRB (Sensor Reference Board) 1x 1321x-NCB (Net-
bug
The same with USB system that permits programming and de-
Description
Table A.3: ZigBee development kits − continued.
60
Reference
1322xEVK
1322xEVK-SFTW
DM163027
DM183023
AC164134
ETRX2DVKA
ETRX2DVKA-PLUS
Manufacturer
Freescale
Freescale
MicroChip
MicroChip
MicroChip
Telegesis
Telegesis
-
-
-
-
MRF24J40
-
-
Transceiver
-
-
-
-
PIC18LF4620
-
-
Micro-Controller
EM250 (Ember)
EM250 (Ember)
-
-
-
MC13224V
MC13224V
SoC
tenna 100mm cable - connects HR module to antenna
PA module AA Battery Holder with lead 1/2 Wave external an-
tor for external antenna MCB Carrier Board fitted with ETRX2-
win connector to plug onto ETRXDV and Hirose UF.L connec-
ETRX2USB - USB stick ETRX2HRHW-PA - Module with Har-
Cable
fitted with ETRX2 module 2 x AA Battery Holder with lead USB
win connector to plug onto ETRXDV 2 x MCB Carrier Board
ETRXDV - Development Board ETRX2HW - Module with Har-
PIC)
bilities to the Explorer 16 development board (this board is for
MRF24J40MA PICtail Plus 2.4GHz RF Card, gives RF capa-
ZENA Network Analyzer.
(on CD ROM) PICDEM Z User’s Guide (on CD ROM)
transceiver daughter card ZigBee protocol stack source code
2x PICDEM Z demonstration boards each with an RF
Version
Same but with IAR 256KB edition and BeeKitFull Node Locked
Bee-Stack Daintree Analyzer SoftWare J-Link JTAG Debugger
1322x-USB IAR 32KB Edition Beekit with 90-day evaluation of
work Coordinator Board) 2x 1322x-LPB (Low Power Board) 1x
4x 1321x-SRB (Sensor Reference Board) 3x 1321x-NCB (Net-
Description
Table A.3: ZigBee development kits − continued.
$450
$350
$19,00
$130,00
-
$4.000
$2.000
Price
61
XB24-Z7CIT-004
XB24-Z7WIT-004
XB24-Z7UIT-004
XB24-Z7SIT-004
Digi
Digi
Digi
Digi
IP-Link1221-2264
IP-Link1221-2164
Helicomm
Helicomm
IP-Link1221-2134
IP-Link1221-2034
OKI-ZNED
Okisemi
Helicomm
MNZB-A24-UFL
MeshNetics
IP-Link1220-2133
MNZB-24-A2
MeshNetics
Helicomm
MNZB-24-B0
MeshNetics
JN5139-xxx-M02/04
U-Power1000
UBEC
Jennic
U-Power500
UBEC
JN5139-xxx-M00/01/03
U-Force
UBEC
Jennic
Reference
Manufacturer
-
-
-
MC13192
CC2420
-
-
ML7065
AT86RF230
UZ2400
Transceiver
-
-
-
MC9S08GT60
C8051F133
C8051F121
-
-
ML67Q4061
ATMega1281v
-
-
-
Micro-Controller
-
-
-
-
-
-
-
-
JN5139
-
-
-
-
-
-
-
SoC
The same but with a RPSMA connector
The same but with an w/ U.FL connector
The same but with an integrated wire antenna
$24
$21
$21
$21
-
$45
$58
$30
$30
$80
$36
$26
$23
-
-
-
Price
Continues on next page
Xbee low power platform with +1dbm of Tx Power with chip antenna
connector
Equal to previous but Tx Power of +18dbm. Has external antenna
IP-Link1221- 2164 has external antenna connector.
Equal to previous but Tx Power of +10dbm.
Equal to previous but Tx Power of +0dbm
Net networking firmware.
Tx Power of +10dbm. RS232/RS485 Interface ZigBee-Compliant IP-
SMA connector. M04 has uFI connector
Equal to previous but has amplifier. Tx Power of +19dbm. M02 has
U.FL connector (M03). Tx Power: +2.5dbm. Size: 18x30mm
Board with an integrated antenna (M00), SMA connector (M01) or
tors. 128kBs flash and 16kBs RAM. The MCU is a ARM7 TDMI
and temperature sensors, three leds, RS-232, LCD, Radio connec-
Flexible Power Supply, switches, tri-axis MEMs accelerometer, photo
128kBs Flash, 8kBs RAM in a package 38.0x13.5x2.0mm
Amplified board with U.FL Antenna Connector. Tx Power of +20bdm
8kBs RAM in a package 13.5x24.0mm
Board with Dual Chip Antenna. Tx Power of +3dbm 128kBs Flash,
128kBs Flash, 8kBs RAM in a package 13.5x18.8mm
Board with Balanced RF Output but no antenna. Tx Power of +3dbm
connector.
Equal to previous but amplifies to +22 dbm and has SMA antenna
Equal to previous but has amplifier that boosts signal to +10dbm
of +0dbm
Board with PCB antenna. Gives SPI access to transceiver. Tx Power
Description
Table A.4: ZigBee modules and their features.
62
MRF24J40
-
MRF24J40MA
TinyOne
ETRX2
ETRX2-PA
MicroChip
RF-One
Telegesis
Telegesis
-
-
-
-
XB24-Z7CIT-004J
XBP24-Z7UIT-004J
-
MC13192
Digi
Digi
Transceiver
Digi
XBP24-Z7SIT-004J
XBP24-Z7WIT-004J
Digi
Reference
Manufacturer
-
-
-
MicroChip PICs
-
-
-
MC9S08GT60
Micro-Controller
EM250
EM250
CC2430
-
-
-
-
-
SoC
Equal to previous but Tx Power of +18dbm
RS232 or over the air
based on the mesh stack EmberZNet2.2 Firmware upgrades over
or single 50ohm pad Tx Power of +3dbm AT-stle software interface
Board size: 37.75x20.45mm 3 antenna options: integrated, U.FL,
Z-One stack Download over the air. SMD 26x15x3mm
Board with PCB antenna and balun. Development oriented
The same but with an U.FL connector
The same but with a chip antenna
The same but with an integrated wire connector
Xbee-PRO high power platform with +18dbm with RPSMA connector
Description
Table A.4: ZigBee modules and their features − continued.
$29
$23
$30
-
$34
$34
$34
$36
Price
Appendix B
Ni-MH and Li-ion batteries
The ZigBee module developed in this work is powered by the electric grid and rechargeable
batteries. The batteries ensure uninterrupted operation in case of a power failure. We considered
rechargeable batteries because the module can recharge them, prolonging their lifetime beyond
that achievable with disposable batteries. This choice also reduces battery costs while being more
environment friendly.
This appendix describes the study made to better understand two types of batteries − NiMH or Lithium-Ion (Li-ion) − and how to charge them. It first describes this batteries strengths,
weaknesses and best charging methods and then concludes over the best solution for this work.
Ni-MH and Li-ion were the only two battery types considered due to their high portability when
compared to other battery types [49].
B.1
Ni-MH batteries
Ni-MH batteries, have a good energy density, are cheap and widely available, are capable of
providing great peak currents and have a moderate self-discharge rate with little memory effect.
Their lifetime is prolonged if used in applications where they get shallow discharge cycles, in fact,
deep discharge cycles tend to degrade their performance. Load currents should be in the order of
20% to 50% of the battery’s rated capacity. And temperatures cannot go above 50◦ . They shall also
get periodic (once every three months) full discharges to prevent crystalline formation and mitigate
the little memory effect they suffer.
The ideal method of charging a Ni-MH battery, requires a MCU to monitor the battery’s state
and control the current applied to charge it. This method fully charges a fully discharged battery and
assumes each battery (a single 1.2V cell) is individually charged and monitored. The method consists of five stages, sequentially applied to the battery, where the charging current is a percentage
of the battery’s rated capacity C:
1. Pre-Charge: to prevent damaging from fast charging, a battery that is depleted is charged at
about 0.1C mA until its voltage reaches 1V 1 .
1
Batteries should not be permitted to go under 1V , it negatively affects their performance and lifetime.
63
2. Condition Tests: the internal resistance of the battery shall be measured in order to avoid
charging worn-out or even damaged batteries.
3. Fast Charge: battery is charged with a current greater than 0.5C mA but less than 1C mA.
A few minutes (aprox. 15 minutes) after this charging stage start, the battery voltage and
temperature must be sampled every few seconds. The battery is considered to be charged
if:
- the battery voltage falls about 5 to 10 mV2 ;
- the battery voltage stays at the same value for more than 20 minutes;
- the battery temperature has a rising rate (dT /dt) of about 1◦ to 2◦ Celsius per minute;
The following conditions shall never occur:
- Battery voltage higher than 1.75V .
- Battery temperature higher than 50◦ Celsius.
- Charging time higher than 90 minutes, if charging began at highest rate (1C mA).
4. Top-Off Charge: charge at 25% of the rapid charge current is applied for about half the time
spent in the fast charge stage, to ensure full charge3 .
5. Maintenance Charge: until the battery is used, a charge at 0.1C mA should be applied
for periods of 16hours, each time the voltage of the battery goes below 1.3V . This stage
counters the battery’s self-discharge rate.
B.2
Li-ion batteries
Li-ion batteries have a higher energy density than Ni-MH batteries, have no memory effect,
have low self-discharge, are environment friendly and do not require periodic cycling4 to extend its
lifetime. Li-ion batteries do not require any maintenance, but capacity is lost with ageing. A battery
typically lasts two to three years, although capacity loss is noticeable after one year.
Li-ion batteries are intolerant to incorrect charging, discharging and temperature abuses. Because of this their only sold in the form of a battery pack, in which an electronic protection circuit is
present to prevent over-discharging, increase of internal pressure and excessive internal temperature. This makes them more expensive and not so available as Ni-MH batteries.
A Li-ion battery is charged at a fixed voltage5 , with the current applied limited to the battery’s
maximum capacity C. This charging voltage threshold is a characteristic of the Li-ion battery pack.
It takes about three hours to completely charge a Li-ion battery pack, in the mentioned conditions.
Higher current rates do not accelerate the process by much, in fact, they tend to produce not
fully charged batteries. The charging process ends when the battery pack’s voltage reaches the
threshold voltage. During charge the battery pack shall not heat, if that happens the battery pack
is damaged.
After the battery pack has been considered charged, its open-voltage voltage shall be monitored for a few minutes. If it does not hold itself at the threshold value, the charging shall be
2
This method is commonly referred to, by −δ V .
If the temperature or voltage maximum values are reached before this stage’s timer ends, the charging shall be
stopped.
4
One cycle refers to a full discharge followed by a full charge.
5
This threshold voltage has a tolerance of only ±0.05V , so the charger circuit must be very precise.
3
64
restarted. When the battery pack is fully charged (at its threshold voltage level) no intermittent,
trickle or any kind of timed charging shall be applied, since Li-ion cells are unable to absorb overcharge.
In conclusion, although Li-ion batteries charging is conceptually more simple, it becomes complex to implement, due to the high intolerance Li-ion batteries have to charging imperfections. In
contrast, Ni-MH batteries are much more tolerant. Therefore, Ni-MH batteries were chosen since
they are more robust to charging, are more cheaper and are more commercially available.
As detailed in B.1 the ideal Ni-MH battery charger needs circuitry for voltage and resistance
monitoring, as well as dynamic current control. Such circuitry requires a considerable amount of
PCB area and increases the total module’s cost. So, a simpler charging circuit is required.
The devised charging circuit (see section 3.2.2) implements a method similar to the one described in the maintenance stage (B.1). As the power grid will be available for the majority of time,
batteries will be always fully charged. During the temporary duration of a power outage, very low
current is drained by the module (see section 3.2.2) and so a maintenance charge is enough to
counter the lost charge and fully charge the batteries. However, in the prolonged absence of power
from the electric grid, batteries will lose a considerable amount of charge and the maintenance
charge will charge them in a not ideal way. In this case, batteries lifetime is expected to shorten a
little.
65
66
Appendix C
PCB Project Dossier
This appendix contains information for PCB manufacturing and assembly. The module implemented on a four layers PCB with 1 millimetre thickness. Outer layers are used for signal routing
and inner layers for ground and power planes. Components are mounted on the upper layer with
the ground plane immediately below them.
The dossier includes manufacturing information in extended Gerber (RS-274X) files for artwork
and an excellon1 file with tool listing embedded, for drills tooling. Assembly information for components placement and acquisition is also included, as well as, the layout for a panel stencil containing
six modules. The electrical circuit is also present.
67
C.1
PCB Layout
The electrical connections (power and signal), for the 4-layers used, are illustrated in figure C.1.
Figure C.2 shows the solder and solder mask patterns required. Figure C.3 concludes with drill
information (sizes and location) and PCB labelling.
(a) Layer TOP (positive).
(b) Layer BOTTOM (positive).
(c) Layer GND (negative).
(d) Layer PWR (negative).
Figure C.1: PCB layers − Electrical connections and components.
68
(a) Top Solder Mask (positive).
(b) Bottom Solder Mask (positive).
(c) Top Solder Paste (positive).
Figure C.2: PCB layers − Solder and solder mask pads.
69
(a) Mechanical Drawing (values in mils).
(b) Drill Drawing.
(c) Top Silkscreen.
Figure C.3: PCB layers − Drills and component labels.
70
C.2
Assembly
The BOM is provided for two distinct suppliers (tables C.1 and C.2), it includes prices and
minimum quantities for both prototyping and production assembly. The components manufacturer
and design references, as well as their values, are available in table C.3. This section ends with
the PCB components placement information in figure C.4.
C.2.1
Bill of Materials (BOM)
Table C.1: Bill of Materials (BOM) − Supplier: Digikey
Supplier
Item
Quantity
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
3
8
2
1
1
1
2
2
1
1
1
1
2
1
1
1
1
1
1
1
1
1
2
1
1
4
1
1
1
1
1
1
DigiKey
Cost (C) Quantity
Per Unit
Minimum
(prototype)
445-1363
587-1229
399-3027
490-4923
490-1284
587-1231
490-1280
399-1038
587-1453
490-3103
S1BB-FDICT
H9161-ND
WM6502
WM6504
WM6503
PCD1933CT
445-1471
PCD1926CT
311-124CRCT
311-158CRCT
RHM5.1ARCT
RHM100KJCT
311-56.0KLRCT
311-43.0KLRCT
296-17598
M25P40-VMN3TP/XCT
MAX3319ECAE+
296-21950
644-1044
535-9166
0.196
0.056
0.020
0.048
0.019
0.037
0.019
0.017
0.224
0.053
0.420
1.140
0.240
0.320
0.280
0.060
0.120
0.060
0.063
0.063
0.028
0.063
0.057
0.057
0.540
2.030
4.650
7.690
0.450
0.400
71
10
10
10
10
10
10
10
10
10
10
1
1
1
1
1
1
1
1
10
10
10
10
10
10
1
1
1
1
1
1
Cost (C) Quantity
Per Unit
Minimum
(production)
0.031
0.009
0.005
0.007
0.002
0.006
0.003
0.003
0.035
0.009
0.050
0.390
0.024
0.035
0.024
0.004
0.004
0.003
0.003
0.002
0.002
0.190
0.960
0.670
4.400
0.250
0.210
2,000
10,000
10,000
10,000
10,000
10,000
10,000
10,000
10,000
10,000
3,000
2,500
10,000
10,000
10,000
5,000
5,000
10,000
10,000
10,000
10,000
2,500
2,500
1,000
1,000
1,000
3,000
Table C.2: Bill of Materials (BOM) − Supplier: Farnell
Supplier
Item
Quantity
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
3
8
2
1
1
1
2
2
1
1
1
1
2
1
1
1
1
1
1
1
1
1
2
1
1
4
1
1
1
1
1
1
Farnell
6582140
8715696
1402740
1403468
8031356
8819599
1650807
1650926
1403144
3908021
1550562
1444322
1551629
1305094
1669628
9239448
1458795
1411497
9882871
1573880
1611824
Cost (C) Quantity
Per Unit
Minimum
(prototype)
0.026
0.008
0.029
0.037
0.078
0.160
1.060
0.093
0.153
0.138
0.143
0.060
0.076
3.010
18.620
0.610
72
1
1
1
10
1
1
1
1
1
5
5
50
50
1
1
1
Cost (C) Quantity
Per Unit
Minimum
(production)
0.008
0.003
0.011
0.004
0.004
0.011
0.094
0.011
0.740
0.037
0.079
0.065
0.094
0.047
0.015
0.012
0.230
0.640
10.690
0.400
5,000
2,500
10,000
10,000
8,000
500
500
10,000
100
2,000
3,000
2,000
1,000
1,000
15,000
15,000
2,500
100
100
100
C.2.2
Component References
Table C.3: Component references and values.
Item
Quantity
1
3
Reference
Value
10u_6V3_0805
C2012X5R0J106M
TDK Corporation
0u22_0402
JMK105BJ224KV-F
Taiyo Yuden
2
1
1
1
2
2
1
1
1
1
C1,C2,C3
C4,C5,C6,C7,
C8,C10,C11,C14
C9,C19
C12
C13
C15
C16,C17
C18,C20
C26
C27
D1
JP2
2
8
3
4
5
6
7
8
9
10
11
12
ManufacRef
13
2
J1
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
1
1
1
1
1
1
1
1
1
2
1
1
4
1
1
1
1
1
1
J4
J11
J12
L1
L2
L3
R1
R2
R3
R4,R5
R6
R7
TP1,TP2,TP3,TP4
U1
U2
U3
U4
Y1
Y2
100n_0402
33p_5%_NP0_0402
27p_5%_NP0_0402
1u_0402
15p_5%_NP0_0402
10n_X7R_0402
2u2_0402
5p6_0402
1N4002
CON_EXT
V_EXT_2pin,
V-_INT_1pin,
V+_INT_1pin
CON_PRG_DBG_5pin
IFA_PCB_ANT
CON_RS232_3pin
6n8_0402
22n_0402
1n8_0402
124R_0805
158R_0805
5R_1/8W_0805
100K_0402
56K_1%_0402
43K_1%_0402
1.7mm
TLV1117-ADJ
M25P40-SO8
MAX3319-SSOP16
CC2430-QLP48
32MHz
32.768KHz
73
Manufacturer
C0402C104K8PACTU
GCM1555C1H330JZ13D
GRM1555C1H270JZ01D
JMK105BJ105KV-F
GRM1555C1H150JZ01D
C0402C103K4RACTU
JMK105BJ225MV-F
GJM1555C1H5R6CB01D
S1BB-13-F
U.FL-R-SMT(01)
Kemet
Murata
Murata
Taiyo Yuden
Murata
Kemet
Taiyo Yuden
Murata
Diodes Inc
Hirose Electric Co Ltd
22-28-4023
Molex Connector Corp
22-28-4043
Made in PCB
22-28-4033
ELJ-RF6N8JFB
MLK1005S22NJ
ELJ-RF1N8DFB
RC0805FR-07124RL
RC0805FR-07158RL
MCR10EZPJ5R1
MCR01MZPJ104
RC0402FR-0756KL
RC0402FR-0743KL
Made in PCB
TLV1117CDCYR
M25P40-VMN3TP/X
MAX3319ECAE+
CC2430ZF128RTCR
NX5032GA-32MHz
ABS25-32.768KHZ-T
Molex Connector Corp
Molex Connector Corp
Parasonic - EGG
TDK Corporation
Panasonic - EGG
Yageo
Yageo
Rohm Semiconductor
Rohm Semiconductor
Yageo
Yageo
Texas Instruments
Numonyx/ST Micro
Maxim Integrated
Texas Instruments
NDK
Abracon Corporation
C.2.3
Top Component Placement
Figure C.4: Component Placement.
74
C.2.4
Schematics
The electrical circuit divided in two figures, figure C.5 presents the SoC and its required components. Figure C.6 illustrates the power supply, the RS-232 /TTL level translator and the SPI
memory.
75
76
Figure C.5: Schematic (1 of 2).
77
Figure C.6: Schematic (2 of 2).
C.3
C.3.1
Stencil
Board Panel Stencil
This stencil allows for the placement of solder over a six module panel, manufactured for separation with V-Cut.
Figure C.7: Stencil.
78
Appendix D
Communications in the ZBeeMeR
prototype
This appendix presents the ZigBee network frames exchanged by the ZBeeMeR components
in the implemented test network. The exchanged frames validate the association between an
EMSeN and the concentrator (figure D.1), and between an EMSeN and a network extender node
(figure D.2). Also confirmed is the ability of an EMSeN to respond to data requests (figure D.3),
and the procedure an EMSeN follows in sending its first message to the concentrator, when it is
not directly associated with it (figure D.4).
79
80
Figure D.1: EMSeN association with the network concentrator.
81
Figure D.2: EMSeN association with a network extender node.
82
Figure D.3: EMSeN responding to a concentrator request.
83
Figure D.4: EMSeN performing a route request and then sending data.
Download