Department of Science and Technology Institutionen för teknik och naturvetenskap Linköpings Universitet Linköpings Universitet SE-601 74 Norrköping, Sweden 601 74 Norrköping

ExamensarbeteLITH-ITN-ED-EX--07/006--SE

Data collection for anindividual heat consumptionmeasurement system using a

Zigbee wireless networkJohan Nordlander

2007-02-09

LITH-ITN-ED-EX--07/006--SE

Data collection for anindividual heat consumptionmeasurement system using a

Zigbee wireless networkExamensarbete utfört i Elektronikdesign

vid Linköpings Tekniska Högskola, CampusNorrköping

Johan Nordlander

Handledare Qin-Zhong YeExaminator Shaofang Gong

Norrköping 2007-02-09

RapporttypReport category

Examensarbete B-uppsats C-uppsats D-uppsats

_ ________________

SpråkLanguage

Svenska/Swedish Engelska/English

_ ________________

TitelTitle

FörfattareAuthor

SammanfattningAbstract

ISBN_____________________________________________________ISRN_________________________________________________________________Serietitel och serienummer ISSNTitle of series, numbering ___________________________________

NyckelordKeyword

DatumDate

URL för elektronisk version

Avdelning, InstitutionDivision, Department

Institutionen för teknik och naturvetenskap

Department of Science and Technology

2007-02-09

x

x

LITH-ITN-ED-EX--07/006--SE

Data collection for an individual heat consumption measurement system using a Zigbee wirelessnetwork

Johan Nordlander

The ever increasing energy cost has led to the need for new energy saving inventions. Previous studieshave shown that individual heat/energy consumption measurements have a positive effect on the energyconsumption for a home. A 10-20 % lower consumption has been noticed in many cases, compared tothe energy consumption before the equipment was installed. One of the problems with existing system isthat the installation cost is high, in many cases money spent on installation is much higher than thepossible saving. For this reason a cheap wireless solution is desirable (for example ZigBee). This workhas investigated how a ZigBee solution could be used in a system for individual heat/energyconsumption measurements.

ZigBee, individual heat/energy consumption measurement

Upphovsrätt

Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare –under en längre tid från publiceringsdatum under förutsättning att inga extra-ordinära omständigheter uppstår.

Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner,skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat förickekommersiell forskning och för undervisning. Överföring av upphovsrättenvid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning avdokumentet kräver upphovsmannens medgivande. För att garantera äktheten,säkerheten och tillgängligheten finns det lösningar av teknisk och administrativart.

Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman iden omfattning som god sed kräver vid användning av dokumentet på ovanbeskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådanform eller i sådant sammanhang som är kränkande för upphovsmannens litteräraeller konstnärliga anseende eller egenart.

För ytterligare information om Linköping University Electronic Press seförlagets hemsida http://www.ep.liu.se/

Copyright

The publishers will keep this document online on the Internet - or its possiblereplacement - for a considerable time from the date of publication barringexceptional circumstances.

The online availability of the document implies a permanent permission foranyone to read, to download, to print out single copies for your own use and touse it unchanged for any non-commercial research and educational purpose.Subsequent transfers of copyright cannot revoke this permission. All other usesof the document are conditional on the consent of the copyright owner. Thepublisher has taken technical and administrative measures to assure authenticity,security and accessibility.

According to intellectual property law the author has the right to bementioned when his/her work is accessed as described above and to be protectedagainst infringement.

For additional information about the Linköping University Electronic Pressand its procedures for publication and for assurance of document integrity,please refer to its WWW home page: http://www.ep.liu.se/

© Johan Nordlander

Abstract

Individual heat/energy measurements have been a hot topic in Europe during thelast 50 years, both for fair reasons and for energy saving reasons. The argument forusing individual heat/energy measurements for fair reasons is that no one shouldpay more than he or she consumes no matter if the person lives in a rental apartmentor in a house. Previous studies have shown that individual heat/energy measure-ments will lower the total energy consumed, when each tenant of a multi-apartmentbuilding has to pay for the actual amount of the consumed heat/energy individu-ally. Unfortunately the installation cost of an individual heat/energy measurementsystem is considered to be high, so the economical arguments for installing this typeof system in existing and new buildings have not been fullled. One reason for thisis that until recently all of these systems used wired solutions. However the publica-tion of the two wireless standards ZigBee and Zwave have opened new possibilitiesfor creating entirely standardized wireless systems, reducing both the installationtime and cost.

The goal of this thesis work is to evaluate the possibilities for developing such asystem based on the ZigBee standard. The work began with a study of the existingsystems (hardware systems) available from some companies in Sweden (Brunata,Metrima, Siemens Building Technologies and Techem). This work also covers somecommunication protocols used (M-bus, BACnet, ZigBee) and dierent sensors (tem-perature, humidity, water consumption, and heat) used in an individual heat/energymeasurement system.

Based on this information a central data collection software server for windowshas been developed. This together with a client application and a database servergives an entire software suite for data collection and data analysis of a ZigBee basedheat/energy measurement system.

Abbreviations

ANSI American National Standards InstituteAPI Application Programming InterfaceASHRAE American Society of Heating, Refrigerating and Air-

Conditioning EngineersCA Collision AvoidanceCAL Central Allocation Logic. The master of the M-Bus net-

workCSMA Carrier Sense Multiple AccessCRC Cyclic Redundancy CheckFFD Full Function DeviceIEEE Institute of Electrical and Electronics EngineersHVAC Heating, Ventilation and AirConditionIEC International Electrotechnical CommissionLQI Link Quality Indicator. A measured value of the link

qualityMFC Microsoft Foundation ClassMS Master-SlaveNTC Negative Temperature CoecientODBC Open DataBase ConnectivityPTC Positive Temperature CoecientRFD Reduced Function DeviceRTD Resistance Temperature DetectorSAP Service Access PointSIBT Siemens Building TechnologiesSPC Standard Project CommitteeTDMA Time Division Multiple AccessTP Token-PassingVCP Virtual COM PortWINAPI Windows Application programming interface

1

Contents

1 Introduction 71.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.2 Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.3 Delimitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.4 Goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.5 Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2 Individual heat/energy measurements 102.1 Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.1.1 Comfort based . . . . . . . . . . . . . . . . . . . . . . . . . . 102.1.2 Energy consumption based . . . . . . . . . . . . . . . . . . . . 102.1.3 More complicated systems . . . . . . . . . . . . . . . . . . . . 11

2.2 History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.2.1 History in Sweden . . . . . . . . . . . . . . . . . . . . . . . . . 112.2.2 Individual energy measurement in Europe . . . . . . . . . . . 12

2.3 System overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3 Sensors 133.1 Water . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.1.1 Single-/multi jet ow meter . . . . . . . . . . . . . . . . . . . 143.1.2 Transit time ow meter . . . . . . . . . . . . . . . . . . . . . . 153.1.3 Doppler ow meter . . . . . . . . . . . . . . . . . . . . . . . . 163.1.4 Inductive ow meter . . . . . . . . . . . . . . . . . . . . . . . 17

3.2 Temperature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.2.1 Mercury and other expanding uid sensors . . . . . . . . . . . 183.2.2 Resistance temperature detector (RTD) . . . . . . . . . . . . . 183.2.3 Thermistor . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.2.4 Solid state . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.2.5 Integrated circuit . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.3 Humidity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.3.1 Capacitive sensors . . . . . . . . . . . . . . . . . . . . . . . . 213.3.2 Resistive sensors . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.4 Heat consumption meters . . . . . . . . . . . . . . . . . . . . . . . . 223.4.1 Water temperature dierence ow meter . . . . . . . . . . . . 223.4.2 Heating system, room temperaure dierence meter . . . . . . 233.4.3 Other meters . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2

4 Communication standards 244.1 Network topologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.1.1 Bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244.1.2 Star . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254.1.3 Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254.1.4 Mesh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264.1.5 Pear to pear . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.2 Mbus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284.2.1 General information . . . . . . . . . . . . . . . . . . . . . . . 284.2.2 Protocol information . . . . . . . . . . . . . . . . . . . . . . . 28

4.3 M-Bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294.3.1 History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294.3.2 Physical layer . . . . . . . . . . . . . . . . . . . . . . . . . . . 294.3.3 Protocol information . . . . . . . . . . . . . . . . . . . . . . . 304.3.4 Key Benets of M-bus . . . . . . . . . . . . . . . . . . . . . . 31

4.4 BACnet - Building Automation and Control Networks . . . . . . . . 324.4.1 History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324.4.2 General information . . . . . . . . . . . . . . . . . . . . . . . 324.4.3 Physical layer . . . . . . . . . . . . . . . . . . . . . . . . . . . 344.4.4 Key Benets of BACnet . . . . . . . . . . . . . . . . . . . . . 34

4.5 ZigBee - IEEE 802.15.4 . . . . . . . . . . . . . . . . . . . . . . . . . . 364.5.1 IEEE 802.15.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.5.2 Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.5.3 ZigBee modes . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.5.4 Harware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.5.5 ZigBee layers . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

5 Existing systems 405.1 Brunata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

5.1.1 System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415.2 Metrima . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5.2.1 System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435.3 Techem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5.3.1 System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455.4 Siemens/Siemens Building Technologies . . . . . . . . . . . . . . . . . 47

5.4.1 System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

6 ZigBee feasibility 48

7 System integration 517.1 Design process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

7.1.1 System requirments . . . . . . . . . . . . . . . . . . . . . . . . 517.1.2 System restrictions . . . . . . . . . . . . . . . . . . . . . . . . 517.1.3 Development platform . . . . . . . . . . . . . . . . . . . . . . 51

7.2 System overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 537.3 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

7.3.1 ZigBee/USB protocol . . . . . . . . . . . . . . . . . . . . . . . 54

3

7.4 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 567.4.1 Reader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 567.4.2 Update - Processing . . . . . . . . . . . . . . . . . . . . . . . 587.4.3 Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 587.4.4 Event engine . . . . . . . . . . . . . . . . . . . . . . . . . . . 587.4.5 Other blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 587.4.6 Sensor manager . . . . . . . . . . . . . . . . . . . . . . . . . . 587.4.7 Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

7.5 Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 607.5.1 Source code . . . . . . . . . . . . . . . . . . . . . . . . . . . . 617.5.2 Connecting to the database . . . . . . . . . . . . . . . . . . . 617.5.3 Navigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 627.5.4 Detailed information about the client application . . . . . . . 63

7.6 Database server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 637.6.1 ODBC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

7.7 Demonstration application . . . . . . . . . . . . . . . . . . . . . . . . 637.7.1 Source code . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

8 Results and conclusions 678.1 ZigBee feasibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 678.2 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

9 Further work 689.1 Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

9.1.1 Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 689.1.2 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 689.1.3 Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

A Formulas 69A.1 General curve tting . . . . . . . . . . . . . . . . . . . . . . . . . . . 69A.2 Doppler ow meter . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69A.3 Inductive ow meter . . . . . . . . . . . . . . . . . . . . . . . . . . . 69A.4 Resistance temperature detector (RTD) . . . . . . . . . . . . . . . . . 70

A.4.1 Reference design . . . . . . . . . . . . . . . . . . . . . . . . . 70A.5 Thermistors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71A.6 Solid state . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

B Demo application 72B.1 Source code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

C Source code 77C.1 License . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

4

List of Tables

4.1 BACnet services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334.2 BACnet objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344.3 ZigBee frequency bands . . . . . . . . . . . . . . . . . . . . . . . . . 38

5.1 Brunata temperature meters . . . . . . . . . . . . . . . . . . . . . . . 415.2 Brunata water meters . . . . . . . . . . . . . . . . . . . . . . . . . . . 425.3 Brunata Heat measurement meters . . . . . . . . . . . . . . . . . . . 425.4 Metrima temperature meters . . . . . . . . . . . . . . . . . . . . . . . 435.5 Metrima water meters . . . . . . . . . . . . . . . . . . . . . . . . . . 445.6 Metrima heat measurement meters . . . . . . . . . . . . . . . . . . . 445.7 Techem temperature meters . . . . . . . . . . . . . . . . . . . . . . . 455.8 Techem water meters . . . . . . . . . . . . . . . . . . . . . . . . . . . 465.9 Techem uid meters . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

7.1 3part contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 527.2 ZigBee/USB communication protocol . . . . . . . . . . . . . . . . . . 547.3 ZigBee/USB packet types . . . . . . . . . . . . . . . . . . . . . . . . 55

A.1 RTD material constants . . . . . . . . . . . . . . . . . . . . . . . . . 70

5

List of Figures

3.1 Multi jet ow meter . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.2 Transit time ow meter . . . . . . . . . . . . . . . . . . . . . . . . . . 163.3 Doppler ow meter . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.4 Inductive ow meter . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.5 Capacitive humidity sensor . . . . . . . . . . . . . . . . . . . . . . . . 21

4.1 Bus topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254.2 Star topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254.3 Tree topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264.4 Mesh topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264.5 M-bus master/slave communication . . . . . . . . . . . . . . . . . . . 304.6 M-bus slave/master communication . . . . . . . . . . . . . . . . . . . 304.7 M-bus image X . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314.8 ZigBee layers/ZigBee stack (source: Microchip AN965) . . . . . . . . 38

6.1 Range versus data rate . . . . . . . . . . . . . . . . . . . . . . . . . . 496.2 Battery life time versus data rate . . . . . . . . . . . . . . . . . . . . 506.3 Battery life time versus data rate . . . . . . . . . . . . . . . . . . . . 50

7.1 System implementation. . . . . . . . . . . . . . . . . . . . . . . . . . 537.2 ZigBee/USB communication protocol . . . . . . . . . . . . . . . . . . 547.3 Server implementation . . . . . . . . . . . . . . . . . . . . . . . . . . 567.4 Receive data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 577.5 Decode data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 577.6 Start the server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 597.7 Terminate the server . . . . . . . . . . . . . . . . . . . . . . . . . . . 607.8 Client application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 617.9 Connecting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 627.10 Setting up the new connection . . . . . . . . . . . . . . . . . . . . . . 627.11 Navigation tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

A.1 RTD reference design with temperature compensation . . . . . . . . . 71

6

Chapter 1

Introduction

The ever increasing energy cost has led to the need for new energy saving measures.Some low-tech solutions let the tenant/user better understand how much energy heor she consumes in dierent situations (shower, cleaning etc) but high tech solutionsare also of interest. The development of high-tech solutions is also important. Inthis report some existing systems (from sensor level to entire systems) for individualheat/energy measurement systems are described. A totally wireless (ZigBee) systemis also introduced.

1.1 Background

Previous studies have shown that individual heat/energy consumption measure-ments have a positive eect on the energy consumption for a home. A 10-20 % lowerconsumption has been noticed in many cases, compared to the energy consumptionbefore the equipment were installed. One of the problems with existing systems isthat the installation cost is high; in many cases money spent on installation is muchhigher than the possible energy saving.

For this reason a cheap wireless solution is desirable. At the Department ofScience and Technology (ITN) at Linköping University, ZigBee modules have beenconstructed and manufactured for sensor network. Based on this work, this thesiswork will evaluate the feasibility of this wireless solution and develop the softwarefor data collection from a ZigBee-based individual heat/energy consumption mea-surement system.

1.2 Problem

• Study existing solutions and systems for individual heat/energy consumptionmeasurements.

• Investigate the feasibility of using the ZigBee technique for individual heatconsumption measurements in an multi-apartment building.

• Develop a Microsoft Windows interface program for data collection from aZigBee network. The interface program should also perform some functions

7

such as data storage, display and analysis.

1.3 Delimitation

In this thesis no new hardware has been developed or manufactured. The work hasfocused on software development and system design (generic system design). Thesoftware created has not been designed to meet the end user demands and stability,but the intention has been to have basic functions for further work.

1.4 Goal

The goal of this project is to answer the problems listed in 1.2 and to give anintroduction to individual heat/energy measurement systems.

1.5 Outline

• Chapter 2 - Individual heat/energy measurementsThis section describes the basic aspects of and individual heat/energy measure-ment system, how the system is built and the history of individual heat/energymeasurements in both Sweden and the rest of Europe.

• Chapter 3 - SensorsThe central part of an individual heat/energy consumption measurement sys-tem is the sensors. Dierent kinds of standard sensors will be described in thissection.

• Chapter 4 - Communication standardsToday many dierent communication protocols are used to communicate withdierent modules in the system. This section will describe some of the mostcommonly used protocols.

• Chapter 5 - Existing systemsSome companies already sell equipment for individual heat/energy consump-tion measurement. In this section some of these systems (from the largestcompanies in this branch) will be described.

• Chapter 6 - ZigBee feasibilityIs ZigBee suitable for these applications? That is an important question forthis report. Based on the information about existing systems and the previouswork done with ZigBee at ITN, answers are given in this thesis.

• Chapter 7 - Software implementationThis section describes the software developed for central data collection ofmeasured data and how the data could be analyzed and displayed.

• Chapter 8 - Results

8

• Chapter 9 - Further development

9

Chapter 2

Individual heat/energymeasurements

The basic idea of individual heat/energy measurement is that no one should paymore energy than he or she consumes. This may sound like a good idea but duringthe last 50 years almost everyone living in a rental apartment has had the cost forboth heating and hot water as a xed part of the monthly rent, with no chance ofknowing how much being consumed.

Studies have also shown that by installing this type of systems, energy consump-tion in each apartment will decrease by an average of 10 to 20 %. This is a greatsave, especially now when the energy price increases and the green house eectaects everyone.

2.1 Models

In the systems used today dierent models are used. Each of these models hasbenets but also disadvantages.

2.1.1 Comfort based

The comfort based systems are the simplest systems, only using the temperature asthe parameter deciding the cost for heating for each tenant. Unfortunately just mea-suring the temperature will not give a fair and correct reading for most apartments,because all apartments are dierent.

2.1.2 Energy consumption based

The energy consumption based system measures the exact energy consumed for eachapartment. This would have worked well if all apartments were equal, but becausesome apartments are placed in the middle of the building and some at the edge,dierent amount of energy must be consumed to keep the same standard (sametemperature). Therefore this system cannot be called fair either.

10

2.1.3 More complicated systems

The most complicated systems today use a mix of comfort based and energy con-sumption based models with compensated values for each apartment (compensatingfor the parameters described). Some systems compensate this in the meters (ad-justing the measured value before the value is sent to the system) and some usemultiplying factors adjusting the price.

2.2 History

The idea of using individual heat/energy measurement has a long history. In thebeginning of the 1930's central heating systems began to be installed in multi-familyhouses (one central heat source for the whole block. One central heat source for eachbuilding is much older) all over Europe. In the same time the idea of letting thetenant pay for the energy he or she consumes began to take form. Unfortunatelythe available techniques was not ready to achieve this to a reasonable price, so ittook 20 more years before any full scale tests were made.

2.2.1 History in Sweden

The progress for individual energy measurement in Sweden has not been a totalsuccess. During the 50's and 60's more than 200000 new apartments were equippedwith individual heat measurement systems. The most commonly used meters inthese systems were evaporation meters located on each radiator. Due to the lowaccuracy in this type of meters and the high cost for reading/administration, manyof these systems have not been used since the tax benets were removed in 1964.

When the energy-crisis appeared in the 70's, this subject was put on the agendaagain. A regulation was written in 1975, which made it mandatory for the houseowner of newly constructed multi-family houses to install systems to measure elec-tricity, hot water and gas. But only 4 years later, when the eect of this regula-tion was understood the regulation was redrawn. The main reason was that theinstallation- and maintanance costs were too high compared to the energy-/costprot.

Over the following 20 years many studies were made to study the eects of thistype of systems both by government-funded projects and by private companies.Some of these studies have resulted in working technical systems and there are someSwedish companies that sell good systems (more information about this is givenlater in the report). When Sweden entered the European Union in 1994, Swedensigned the SAVE-directive. This directive combined with the Kyoto-directive (1997)gave both government institutions and private companies an extra push to reduceenergy consumption, and after this the interest for individual energy measurementhas grown.

Until recently a majority of these systems have still been wire-based, with a highinstallation cost. Howover during the last 5-10 years some companies have startedto sell partially wireless systems.

11

2.2.2 Individual energy measurement in Europe

The leading countries for individual energy measurement in Europe are Germany andSwitzerland but many other countries have initiated similar projects, for exampleFrance and Denmark. In Denmark individual energy measurement is mandatory fornew buildings since the 1/7-1995. Although other countries have had good resultsfrom individual heat/energy measurements, it is not possible just to copy theirsystems/laws because the Swedish rules for apartments is dierent (for examplehow the living area is calculated and how the rent is calculated).

2.3 System overview

All systems for individual heat/energy consumption measurement are dierent, someuse cable connected devices and some wireless. Some systems are built with one cen-tral unit that processes everything and some are designed with distributed devices.However on the system level all systems are more or less equal.

The network controller is the device that controls the entire network. Thereis usually just one network controller in each network. In some cases the networkcontroller is a standard PC (see BACnet 4.4) and in some cases it is an embeddedsystem (see ZigBee 4.5). The main task for these modules are to have overall systeminformation and control of the network, for example authorization of devieces andcentral data collection.

Sub controllers are devices normally connected to the network controller, but insome cases these devices are not available, for example BACNet(BACnet devicesconnect directly to one bus). In other cases both the sub controllers and end de-vices can be connected to the network controller (see ZigBee 4.5). The use of subcontrollers increases the maximum network capacity, especially if the sub controllersimplements data routing functions like ZigBee.

The last type of modules in individual heat/energy consumption measurementsystems is the actual sensors or end devices. These can take any form and can haveany function (for example temperature sensors, water meters, electricity meters andlight meters, etc).

Together all these modules form a system for individual heat/energy consump-tion, but a similar system (a system with more end devices) could also be used forclimate control or home automation.

12

Chapter 3

Sensors

The central part of an individual heat/energy measurment system is the sensorsavailable. Depending on how advanced or precis the overall system is, dierenttypes of sensors must be used. Simple systems can be constructed with low costand low preformence sensors, but in many cases high precision measurements areneeded, and then high precision sensors should be used.

13

3.1 Water

A water meter is used to measure hot and in some cases cold water consumption.Most of the water meters on the market today are based on an old technique andare usually called "single jet" ow meters, but other techniques exist.

3.1.1 Single-/multi jet ow meter

Single- and Multi-jet ow meters are actually meters that measure uid velocityand not the real ow. An impeller (a small propeller) is located in a restrictedcavity. When the uid ows through this cavity, the impeller rotates with a speedproportional to the speed of the uid. By knowing the diameter/volume of themeter the ow can be calculated. Of course the owner of the meter does not haveto calculate this. It is done by the meter itself, either by a microprocessor or bya mechanical system with gears. The multi jet ow meter works in the same waybut with multiple impellers located in a restricted cavity. This results in a moreaccurate meter at small ows, but the path through the meter is more restricted.For this reason multi- jet ow meters is not commonly used in larger systems.

Figure 3.1: Multi jet ow meter

Advantage

• A well proven technique

• Already installed in many apartments/buidings

Disadvantage

• A big wear (Compared to other techniques)

• Cannot be used with uids that contain a high consentration of for examplecalcium oxid.

• Cannot measure direction of the ow

14

3.1.2 Transit time ow meter

The simplest way of measuring a ow without making permanent changes to thepipe-system is to use an ultrasonic transit time meter equipment.

The basic idea of this type of sensors are that sound travels faster in a positiveow of uid than in a negative ow. This applies to all ows, but the higher thedensity the greater is the change. By sending a number of pulses of sound fromone transmitter in one direction, then wait for that burst of sound to arrive to areceiver located some distance from the transmitter, and then send a similar soundburst in the opposite direction (see gure 3.2). The time dierence between thesetwo transmission is than proportional to the ow of the uid. If the diameter,the material and the wall thickness of the pipe is known, the absolute ow can becalculated.

In most cases an ultra sonic receiver/transmitter is used to measure this eect.The main reason for this is that the ultra sonic waves can travel through the wallof the pipe, i.e. the receiver and the transmitter can be mounted on the outside ofthe pipe.

Problems

There are mainly two problems with this type of meters. The rst and most seriousproblem is that, if the ow is small the time dierence will be small. With a speed ofsound in fresh water of 1435 m/s and a speed of sound in salt water of 1500 m/s themeasured time dierence will be in the ms- or us-second range. This dierance isnot a problem by itself, but combined with the relation described below, this smalltime will be hard to measure.

The other problem is that at each intersection between two dierent materials thesonic beam is divided into a diracted and a reected portion. The sonic wave alsotravels through the pipe wall and depending on the material and the wall ticknessa diracted sonic wave is created. As a result many dierent sonic waves hit thereceiver and some of them must be ltered out. The maximum accuracy of themeter is limited by how this "sonic wave" selection is achieved.

Advantage

• No permanent changes must be made to the pipe system

• Relatively cheap

• Easy to install and uninstall

• The direction of the ow is easy to measure

Disadvantage

• Requires a quite large ow to be accurate

• Not possible to use in all systems (3.1.2)

15

Figure 3.2: Transit time ow meter

3.1.3 Doppler ow meter

The last standard way of measuring the ow of a uid is to use a sensor based onthe Doppler eect. The Doppler eects or the Doppler shift principle says that thefrequency of the sonic wave will be higher if the "sound source" moves towards thereceiver and lower if the "sound source" moves from the receiver (see gure 3.3).

Because there is no way of placing the sound source or the sound receiver insidethe ow and let it move with the same speed as the uid ow, this phenomenoncannot be seen in a perfect/clean uid. For this phenomenon to happen in a uid,particles or bubbles with a size of at least 100 microns must be added and theconcentration of the impurities must be at least 100 ppm (the exact size of theparticles is frequency dependent). The bubbles/particles work as a reector andmake it possible to measure the ow speed with a xed transmitter/receiver.

Figure 3.3: Doppler ow meter

Advantage

• Can measure large ows

16

Disadvantage

• The dubbles or the particles must be added to the uid (at least if the uid iswater)

• Measuring the Doppler eect is more complicated than the two previous tech-niques

3.1.4 Inductive ow meter

The inductive ow meter operates according to the magnet induction measurementprinciple. According to Faraday's Law of magnetic induction a voltage is inducedin a conductor moving through a magnetic eld. By placing a coil around a pipegenerating a magnetic ux the induced voltage could be measured in the conductor.In the case of a ow of uid, the uid can act as a conductor as long as a minimumconductivity of at least 5 µS/cm is reached. The voltage induced is proportional tothe ow velocity and is therefore a value of the volumetric ow. The induced voltageis picked up by two sensing electrodes placed as in gure 3.4. These electrodes arethan connected to the measuring circuit transforming the measured voltage to theow rate based on the cross sectional area of the pipe.

Figure 3.4: Inductive ow meter

Advantage

• High accuracy

• Independent on temperaure/viscosity

Disadvantage

• Cannot be used on clean liquids

17

3.2 Temperature

The most commonly used sensor in existing buildings is the temperature sensor.In older buildings this type of sensors is often called a thermometer and is justused to measure the outdoor or indoor temperature, i.e. it is not connected to anydata collection system or temperature regulators. In some new buildings and in thebuildings described in this report, this simple and cheap sensor can be used as oneof the input signals to automated climate control system.

3.2.1 Mercury and other expanding uid sensors

Ever since the rst thermometer was invented in 1701 by the Danish astronomerOle Rømer people have been using expanding uids to measure temperature. MrOle Rømer´s thermometer was using red wine but until recently mercury is the mostcommonly used uid. Since mercury is poisonous new thermometers is using ethanolinstead.

Advantage

• Easy for the user to see the temperature

• Secure sensor type, as long as the sensor is calibrated (done at manufacturing)and the cavity is not broken

• Slow (a build in moving average, 10 sec or more)

Disadvantage

• Cannot be used in automated systems because the level is hard (complicated)to measure

• Slow

• Expensive compared to many other temperature sensors

3.2.2 Resistance temperature detector (RTD)

RTDs use the basic physical relation between conductivity of a material (usually ametal) and temperature. Increased temperature results in lower conductivity andthis result in higher resistance (also known as PTC, Positive Temperature Coe-cient). By measuring the resistance vs temperature for the material, the resistancefor any given temperature can be obtained by doing a curve-tting calculation forthe measured data (see appendix A.1).

The most commonly used resistive temperature detectors today is the PT-100and PT-1000 device. The name PT comes from the material in the sensor (Platinum)and the number comes from which resistance the device has at 0C. i.e. the PT-100is made of Platinum and has 100 Ω at 0C. Platinum is used because the resistanceis almost linear over the whole operation range. Other materials used in RTDs areNickel (cheaper than Platinum but not linear), Copper(used when Copper coils is

18

used for other reasons) and Tungsten (can measure temperatures up to 1200C, notlinear). The curve-tting equation is usually simplied more in room temperatureapplications. The characteristic is linearized from 0 to 100C resulting in the αfactor (see A.6). By inserting α into equation 3.1 or 3.2 the temperature can becalculated.

Resistor Temperature Dependence

R = R0 (1 + α ·∆T ) (3.1)

∆T =

(RR0

− 1)

α(3.2)

Advantage

• Simple to connect to a (micro)computer

• High accuracy

• Large operation range (normaly −200C to 1000C)

Disadvantage

• Calibration is needed for maximum accuracy

• Expensive

3.2.3 Thermistor

Thermistors are based on the same physical relations as RTDs (see 3.2.2), but in-stead of having a resistance that increases with increasing temperature, the thermis-tor´s resistance decreases (also known as NTC or Negative Temperature Coecient).This is achieved by using metal oxide semiconductor/ceramic materials, for exam-ple Silicon and Copper. Thermistors is usually cheaper than RTDs (see 3.2.2) butwith less precision (an average thermistor have a precision of about 0.1 C), due tothe cost per unit, thermistor is usually used instead of RTDs in room temperatureapplications. The disadvantage compared to RTDs is that thermistors has a nonlin-ear resistance-temperature characteristic (calculating the temperature requires morecomputer power) and it is not possible to linearized it. By adding a material pa-rameter β the temperature can be calculated (see equation A.11 in appendix). βcan also be called B or K and is usually in the range of 1000 K(Kelvin) to 5000 K[1] [2].

Advantage

• High accuracy (±0.02C)

• Low drift

19

• Short response time

• Relativly cheap

Disadvantage

• Limited temperature range ( −100 to 150C)

• Nonlinear resistance-temperature characteristics

3.2.4 Solid state

A solid state temperature sensor is usually constructed from a normal p-n junctionand is using the correlation between the bangap and the temperature. By measuringthe voltage drop over a forward biased diode vs. temperature the temperaturecharacterisation can be obtained (using a similar curve-tting calculation as withthe RTD, see section 3.2.2). If the temperature is in the range of 50 to 500 K thecharacterisation is linear and therefore well suitable for temperature measurementsin indoor climate (For more information see appendix A.6)

Advantage

• Cheap

• Easy to integrate in integrated circuits

Disadvantage

• Low accuracy

• Large dierences from one example to the other

3.2.5 Integrated circuit

In most low cost applications all the temperature sensor types listed above (see3.2.1 to 3.2.4) are either too expansive or require some additional components to beused. If thhe accuracy demand is low (normal integrated temperature sensor has anaccuracy in the range of ±0.5 to ±2C), most products use integrated sensors. Thesensor part of these devices is constructed from one of the types listed above. Forexample the TC77 from Microchip or the DS1825 from MAXIM is using a solid statesensor (an internal diode)[3]. By integrating the sensor together with some logic onthe same silicon substrate, many of the accuracy limiting factors could be reduced.The TC77 (see [3]) for example has a digital SPI interface to the microprocessor andthe DS1825 is connected through an OneWire interface.

20

3.3 Humidity

Existing systems for individual heat/energy measurements do not measure humidity.One can only speculate about the reason for this, because humidity is an importantparameter if comfort-based models are used. Depending on the humidity level thesame temperature will be felt dierent. This eect will also depend on the tem-perature level, if the temperature is above 40 C a higher humidity will increasethe temperature experienced (similar to a sauna). At temperatures below 40 C ahigher humidity will have the opposite eect.

The humidity is measured in relative humidity (RH) and this unit represents theamount of water absorbed in the air (0-100 %). This unit is temperature dependentand depending on the accuracy required a compensated relative humidity could becalculated. In most applications (room temperature) this is not done and thereforea standard humidity sensor has accuracy of about 5 %.

3.3.1 Capacitive sensors

The simplest humidity sensors are created from a "nger" capacitors (see gure3.5) with a dielectric material that is humidity dependent. This may sound like asimple solution but interfacing this type of sensor is complicated. Measuring thecapacitance could be achieved by calculating the time constant, but the resistanceover the capacitor is unknown and that eects the time constant. For this reasonthis type of sensor is usually just used to measure the existence of moisture underdishwashers, etc.

Figure 3.5: Capacitive humidity sensor

Advantage

• Cheep

Disadvantage

• Complex to interface

3.3.2 Resistive sensors

The resistive humidity sensors are more complex than the capacitive sensors, butthe accuracy is usually higher (1-5 %). The main advantage is that the resistive

21

humidity sensor is created to be linear over the whole range (0-100 %).The resistive sensor is constructed in a similar way as the capacitive sensors

but the material in the conductor changes the conductivity with humidity. Thisis achieved by using conductor materials that store some moisture. This meansthat the sensor could be interfaced in a similar way as the RTD and thermistortemperature sensors.

Advantage

• Linear

• High accuracy

Disadvantage

• Expensive

3.4 Heat consumption meters

Measuring the heat consumed by an apartment or house is the most importantparameter for an individual heat/energy measurement system, but also the mostdicult one to measure. Over the years dierent types have been used, for examplethe evaporation meters used during the 50's and 60's (see section ??) and the radiatortemperature used in some of the systems today.

3.4.1 Water temperature dierence ow meter

The temperature dierence ow meter measures the temperature dierence betweenthe ingoing water to an apartment and the of outgoing water. At the same timethe water ow is measured and from this the energy transferred from the heatingsystem to the apartment is calculated.

Advantage

• Easy to measure

Disadvantage

• The energy transferred from the heating system to the apartment is not theonly parameter giving the total heat consumption

• The energy consumed for the whole apartment is measured. It is not possibleto get more precise information

22

3.4.2 Heating system, room temperaure dierence meter

This type of meter works in a similar way as the temperature dierence ow meterbut instead of measuring the temperature dierence of the heating system, thistechnique measures the temperature dierence between the heating system and thesurrounding air. By knowing the eect and the size of the radiator the heat consumedcan be calculated. This meter usually consists of two separated temperature sensors,one placed on the center point of radiator and one in a suitable place in the sameroom.

Advantage

• Easy to install

• Cheap

• The heat consumption "for each" radiator could be calculated

Disadvantage

• Requires dierent settings for all installations

3.4.3 Other meters

In the cases where electric radiators are used, none of the techniques described aboveare suitable. However the eciency of the electricity to heat conversion is almostideal, so to measure the electricity consumed (both for heating and normal use) isenough.

23

Chapter 4

Communication standards

Over the years a lot of work has been done to create communication protocols,some open to the public/other companies and some closed for the creator. In homeand industrial automation some of these protocols have become more or less branchstandard and are used by most manufacturers. They will be described in this sec-tion, but in the rst section the most commonly used network topologies are alsodescribed.

4.1 Network topologies

Choosing the right network topology is always important, but for a sensor network(low cost, low power (battery powered) applications ) it is crucial. The topologydecides many system parameters, like the minumum number of nodes required andthe maximum coverage (this is also limited by the software protocol).

In this section the most commonly used network topologies for sensor networkswill be described. Some of the advantages and disadvantages of each topology willbe described.

4.1.1 Bus

The bus topology (see gure 4.1, the blue node represents the controller, the rednormal nodes and the green the sensors) is the simplest topology to implement inhardware, but software implementation could be more problematic. If a bus topologyis used, all nodes in the network can hear what all the other nodes is transmittning,but that does not mean that all nodes are listningen to all the trac. In manycases one central node controls all the other nodes in a client-server relationship (ifthe clients want to talk to each other they would have to talk through the server).Another technique for these topology is TDMA1. In this case each node get a timeslot at which the node is allowed to communicate (the node is listning the rest ofthe time).

This topology is mainly used for wired connections (Notice, the star topologyfor wireless network is similar to the bus topology for wired connections).

Examples: I2C, IDE, Ethernet (with hub)

1Time division multiple access

24

Figure 4.1: Bus topology

4.1.2 Star

The traditional topology for wireless sensor networks have been the star. In thiscase one central node controls all communication in the network (client/slave nodescan not talk directly with each other). This means that the network can onlybe as large as the maximum distance between the central node and the slave (seegure 4.2 the blue node represents the controller, the red normal nodes, the grayunreachable nodes and the green the sensors). The same restriction applies to wiredconnections, but in this case the restrictions have more to do with the fact that thestar is used for preformance reasons. The goal of these connections is to maximizethe transfer speed, which means that the central node must be able to work withmultiple parallell tasks at the same time (for example a twisted pair ethernet switch).

The dierent communication techniques are similar as the one used with the bustopology, but with more and more wireless communication, this topology is beingreplaced by the tree and mesh topology in new techniques.

Examples: Bluetooth

Figure 4.2: Star topology

4.1.3 Tree

The tree topology is an extended version of the star topology (see gure 4.3 the bluenode represents the controller, the red normal nodes and the green the sensors) andrequires more system resources then the star. The tree topology makes it possibleto create larger networks (both number of nodes and the area each network covers)because nodes can be connected to other nodes, not just to the central node. Thedisadvantage is that there will be delays in the network since each relay takes time.

Just like with bus and star networks TDMA is a possible technique. But theadministration of timeslots is problematic. For this reason, TDMA is usually not

25

used with the tree topology. Instead CSMA2/CA3 is used. This means that if anode wants to transmit data, it rst checks if a carrier is present. If so it waits(normaly for a "random" time), otherwise the new transmission starts.

Examples: Ethernet (with switches) and USB

Figure 4.3: Tree topology

4.1.4 Mesh

The most advanced topology used in sensor network today is the mesh networks(see gure 4.4). This is an extended version of the star network where each nodecan connect to many other nodes. The advantage of this is a more robust network.If one node breaks down the remaining part of the network will still work as long asone path is found through the network. This can be compared with a tree topology,that will fail if one node breaks down. This feature of the mesh topology meansmesh nets must have routing capabilities.

Examples: ZigBee and Ethernet (with routers)

Figure 4.4: Mesh topology

4.1.5 Pear to pear

The pear to pear network is similar to the mesh network. Each node can commu-nicate directly with other nodes, but a normal pear to pear network does not have

2Carrier Sense, Multiple Access3Collision Avoidance

26

routing capabilities (see Mesh for more infomration 4.1.4).

27

4.2 Mbus

The Mbus(Message Bus) is a light-weight message-oriented coordination protocol fordeveloping component-based distributed applications. The protocol has been devel-oped by Universität Bremen [4] and University College London and was publishedas RFC3259 in 2002. [5]

Notice that this is not the same bus as the high speed MBus developed bySUN which connects memory, CPU and other components in Sparc based highperformance computers [6]. Mbus is not the same as M-Bus either, the M-Bus isseperatly described in section 4.3

4.2.1 General information

The Mbus specication denes a standard where dierent modules doing dierenttasks, can communicate over the same network. The same network can handlecommunication between personal computers and small micro controllers.

4.2.2 Protocol information

The Mbus has been designed as an ASCII protocol. All values including numbersand time are expanded into normal text, for example the binary value 0xF7 will beconverted into "127". This is similar to HTTP. This results in a larger packet sizebut the implemention of the protocol is simpler.

Data structure

Each message sent by a MBus node is constructed with a header and a body.The header holds information about:

• The protocol version a xed string containing "mbus/1.0"

• A sequence number

• A time stamp in ms

• A message eld

• A source address

• A desination address

• An acknowledge list

Addressing

Compared to other communication protocols, the way Mbus address nodes is dif-ferent. The Mbus address is built from a string tag where the manditory address iswritten like id:<identier>.

28

4.3 M-Bus

M-Bus or Meter Bus has been designed to fulll the need for a standard way ofinformation collection and controling. The physical layer of the M-Bus protocol isunique compared to other communication protocol.

4.3.1 History

M-Bus was created by Professor Dr. Horst Ziegler of the University of Paderborn incooperation with TI 4 and Techem (Germany) and was published in 1996. Over theyears M-Bus has grown to be the most commonly used protocols for this purpose.Today it is possible to nd almost any sensor with a M-Bus interface, everythingfrom temperature measurement equipment to advanced regulators. [7]

4.3.2 Physical layer

The whole purpose of the M-Bus protocol is to keep the cost down and still have theopportunity to transmit information over long distances. For this reason, M-Bushas been designed to work on a two-wire cable (a normal two-wire telephone cable issuitable). It also implements remote powering of slave nodes over the same two-wires(with a limited current consumption for each node). This is implemented using amix of voltage and current consumption protocol, where the master or the CAL5

transmits data by varying the dc-level and the slave nodes transmit by changing thecurrent consumption. Because a change in voltage will result in a change in current,this way of communication will only work in half duplex. [4]

Master

A logical "1" is sent from the master to the slave by applying a 36V dc level on thebus and a logical "0" is sent by reducing the dc-level by 12V to 24V (notice this isthe voltage from the master and it will be lower at the slave nodes because of theresistance/losses in the cables). The normal state of the bus when the master is nottransmitting is 36V (a logical "1") (see gure 4.5).

Slave

Data sent from a slave node to the master is coded by modulating the currentconsumption of the slave. A logical "1" is represented by a constant (versus voltage,temperature and time) current of up to 1.5 mA, and a logical "0" is sent by anincreased current drain requirement by the slave of an additional 11-20 mA. The"1" state current can be used to power the interface and in some situations themeter or sensor itself (see gure 4.6).

4Texas Instruments5Central Allocation Logic. The master of the M-Bus network

29

Harware implementation

The demand for the high volume product, the slave modules, have resulted in an in-tegrated circuit from Texas Instrument, the TSS721. This component integrates theentire M-bus physical specication and makes it easy and cheap to construct M-Busslave modules6. Implementing the master is much more complicated beacause thereis no generic solutions (no integrated circuits to buy). Dependeing on how manyslaves each master can handle, dierent considerations have to be made. If onlya few slave modules (up to 25) is needed the master implementation can be con-structed with standard componentes, like op-amp's and some passive components,but if the slave modules count get high, designing the current supply (poweringthe interface/bus) can be hard. The current supply and current measuring circuitmust have a ripple of at most 5 mA (system) or 0.2 % for each device (sensor, etc)according to the specication.

Figure 4.5: M-bus master/slave communication

Figure 4.6: M-bus slave/master communication

4.3.3 Protocol information

The communication protocol dened in the M-Bus specication has many similar-ities with RS232. Each byte starts with one start bit and ends with one stop bitand one parity bit (11 bits total). The protocol denes 4 dierent packet frames.One single byte frame and three multi-byte frames. Each of the multi-byte framesstarts with a header and ends with a tail (see gure 4.7. Notice the number repre-sents a constant value). The multi-byte frames also contains a CRC 7 value for dataintegrity check.

Because of the physical limitations in voltage/current protocol and the simplesoftware implementation all communcation is initiated from the master (CAL). Theslave nodes are only responding when they are talked to.

6for more information contact TI's european information center7Cyclic Redundancy Check

30

Packet frame

The data frames used in a M-Bus network apply to the IEC 870-5 standard8. Asdescribed previous four dierent frames is available (single byte, short frame, controlframe, long frame). The single byte frame is for acknowledge of transmissions only,and can not be used to exchange user data. The other three packet frames is usedfor protocol- and user data communication.

Figure 4.7: M-bus image X

Addressing

The address eld in each package only consists of one byte, therefore only 255addresses is available in one network (addresses 1-250 are available for sensors andaddresses 0, 251-255 are reserved). Address 255 is used for broadcast without replayand 254 is used for broadcast WITH replay. To make it more complicated onemodule can answer to multiple addresses.

4.3.4 Key Benets of M-bus

• Branch standard

• Cheap

• Low complexity

8International Electrotechnical Commission

31

4.4 BACnet - Building Automation and Control Net-

works

4.4.1 History

The work of BACnet began in 1987 in Nashville, Tennessee, as a project initializedby SPC 9. During the rst meeting with SPC guidelines were written and the workon BACnet began. Eight years later (1995) BACnet was published as aASHRAE 10

/ ANSI 11 standard (BACnet-95) and during the following 6 years the standard wasupdated 5 times. Two years later in January 2003 BACnet was approved as an ISOstandard (16484-5). Until this day BACnet has not been approved as a Europeanstandard, but much work is being done to do so. In Sweden the interest groupBIG-SE[1] aims to promote BACnet through training and publications.

4.4.2 General information

The BACnet protocol is based on objects, properties and services. Each objectrepresents a seperate function, for example an analog port. Each property representsdierent settings for the associated object. Some of the objects and properties aremanditory and some are optional. For example each object have to have an "objectidentier", an "object name" and an "object type", but a "Current value" is onlyavailable for ports.

The BACnet protocol is also capable of sending information on a specieed timeintervall, for example every 10 seconds. This feature can also be optimized so eachnode/object only sends information that has changed. Thanks to the min-, maxand range properties many sensors could be installed in the same network, withoutincreasing the need for higher bandwidth.

9Standard Project Committee10American Society of Heating, Refrigerating and Air-Conditioning Engineers11American National Standards Institute

32

BACnet services

The implementation of services gives a device/object the possibility to interact/communicate with another devices or objects. This makes it possible for one deviceto communicate directly with another device without interference from the networkcontroller (compare to M-Bus, see section 4.3).

Through the "Who-Is", "I-Am", "Who-Has", and "I-Have" services enumerata-tion of network resources is possible and through the "Read-Property" and "Write-Property" services object properties for any device/object can be accessed. Func-tions for alarm and le access are possible to access in a similar way.

Table 4.1 shows a list of the most important services in a BACnet:

Table 4.1: BACnet services

Type DescriptionAlarm and EventFile accessI-AmI-HaveRead-PropertyObject accessRemove device man-agementNetwork secuirityVirtual TerminalWho-HasWho-IsWrite-Property

33

BACnet objects

The available BACnet objects handle all functions required in an automation system.From analog to digital and input to output. The most important objects is shownin table 4.2.

Table 4.2: BACnet objects

Type DescriptionAnalog InputAnalog OutputAnalog ValueBinary InputBinary OutputBinary ValueCalendarCommandDeviceEvent-EnrollmentFile Larger set of data (trends, etc)GroupLife safty Fire/safty alarm, etcLoopMulti-State InputMulti-State OutputNotication-ClassProgramSchedule

4.4.3 Physical layer

Today BACnet has been dened for many dierent physical standards. Dependingon the size of the network or the type of sensors used, v24 (RS232D, two-wirecommunication), ethernet, ARCNET, MS 12/TP13 or echelon LonTalk can be used.These physical standards can then be combine. One network can be built with justv24 sensors or it could combine v24 devices with for example ethernet devices.

Work is being done to combine BACnet with ZigBee for wireless communication,but no standard has yet been published.

4.4.4 Key Benets of BACnet

• Royalty-/licence free - anyone may develop implementations without cost

12Master-Slave13Token-Passing

34

• Maintained by an ASHRAE committe representing all sectors of the industry

• Designed specicallt for building control

• Can be implemented in devices of any size

• Not tied to present technologies

• GPL version of the BACnet stack

35

4.5 ZigBee - IEEE 802.15.4

ZigBee is one of two new international standards for low datarate/low power wirelessnetwork communication. The other one is Z-wave, but it will not be described in thisreport. The standard is being developed and promoted by the ZigBee alliance, con-taining more than 200 members including big companies like TI, Freescale, Phillipsand Samsung. Of the communication protocols described in this report ZigBee isthe most complicated, but also the one with most features.

4.5.1 IEEE 802.15.4

ZigBee is based on the IEEE 802.15.4 standard. This standard denes the physicallayer (PHY) and medium access control layer (MAC) used by ZigBee. This meansthat the IEEE standard denes the fundamental functions for communicating ina personal area network (PAN). By using the IEEE standard, a star- (see section4.1.2) or point to point/mesh network (see section 4.1.4) could be created with amaximum transfer speed of up to 250 kbit/s (2.4 GHz). For small networks IEEE802.15.4 could be used by itself instead of the more complex ZigBee standard, butas the network grows the need for ZigBee increases.

4.5.2 Network

Compared to other wireless techniques the number of nodes in each ZigBee networkis large. The ZigBee standard allows up to 65000 nodes in each network, but inreality the maximum number of nodes is less then that. This has to do with the factthat the total bandwidth of the network is limited and that the memory (RAM)available on most ZigBee nodes is too small to handle the full/maximum ZigBeespecications. The RAM size mainly limits the size of the routing/neighborhoodtables resulting in too many route recoveries, increasing the overhead trac.

Addressing

Each node in the ZigBee network is identied by two addresses, a long and short one.The long address is represented by an IEEE 64 bit integer value. This value is uniqueand set by the manufacturer. The other address, a 16 bit integer could be set by themanufacturer, but it is usually set by the network itself or as one step of the installa-tion. Once the network is initialized, either the long or short address could be used.

Security

In many cases data protection is needed, especially if a wireless technique is used.The use of encryption is the standard way of achieving this and encryption is in-cluded in the IEEE standard. The encryption algorithm used is AES-128, this givesZigBee an high security when needed. In cases where encryption is not needed ac-cess control could be used. This means information is only received from installednodes (nodes installed in the access control list), all other data is dropped.

ZigBee can operate in the following security modes:

36

• Unsecured mode

• Access control list

• Secure mode

4.5.3 ZigBee modes

The IEEE standard denes three dierent types of nodes, the coordinator, the fullfunction devices and the reduced function devices, each with dierent features.

Coordinator

Each network need to have a network coordinator. This device handles the overallcontrol and settings of the network and if a star network is used, it relay informationbetween the nodes. The coordinator is the most system demanding device used ina ZigBee network because it implements all the features from the FFD plus thecoordinator specic features. For this reason this device must be mains powered.

Full Function Device (FFD)

The full function device implements the entire IEEE 802.15.4 standard. This deviceis always turned on and in listening mode if not transmitting (the node is alwaysaccessible). If ZigBee is used, this device routes messages and keep informationabout neighborhood nodes (this is not available if only the IEEE standard is used).

Reduced Function Device (RFD)

This device type represents the simplest devices used in a ZigBee/IEEE 802.15.4network. It has no routing capabilities (it is not implementing the whole IEEE802.15.4) and could be turn on/o when no data need to be received or transmitted.Therefore this type is suitable for battery powered nodes. In many cases thesedevices come alive on a predened time interval, do what thay are supposed to doand then enter sleep mode again.

4.5.4 Harware

The IEEE 802.15.4 standard denes three dierent frequency bands (One for use inEurope/Asia, 868 MHz, one for use in USA, 915 MHz and one for worldwide use,2.4 GHz). The lower frequencies have an maximum transfer speed of 20/40 kbit/sand the limit for the high frequency (2.4GHz) is 250 kbit/s. Although both 868 and915 MHz is used, 2.4 GHz is the frequency band used in most applications and thefrequency band used by all devices from ITN.

SensitivityCompared to other techniques like Bluetooth and Wlan, the output power neededfor ZigBee is small. In most cases 0 dBm (1 mW) or less is used, but still giving a

37

Table 4.3: ZigBee frequency bands

FrequencyMHz

Frequencyband

Channels(count)

Modulation Bitratekbit/s

868 MHz 868 - 868.6 0 (1) BPSK 20915 MHz 902 - 928 1-10 (10) BPSK 402450 MHz 2400 - 2483.5 11-26 (16) O-QPSK 250

range of up to 150 m (outdoor). This is achieved by using DSSS (Direct SequenceSpread Spectrum).

4.5.5 ZigBee layers

The denition and implementation of ZigBee has been separated into dierent layers,similar to the OSI modell, (see gure 4.8) to increase the modularity and to handle"multitasking". Each layer handle dierent tasks and responsibilities, but for eachlayer to work communication with the other layers must take place. The layer tolayer communication is handled by the SAPs14 otherwise each layer works seperated.

Figure 4.8: ZigBee layers/ZigBee stack (source: Microchip AN965)

14Service access point

38

PHY - Physical layer

The physical layer of the IEEE 802.15.4/ZigBee standard handles all tasks involv-ing the access to ZigBee hardware. This includes initialization of the hardware(transceiver) and reading from and writing to the internal transceiver buers.

MAC - Medium access control layer

The second layer from the IEEE standard is the MAC layer. This layer handlescommunication between the NWK and PHY layer. It is also responsable for channelscans (both active- and orphan scans).

NWK - Network layer

The NWK layer is the rst layer from the ZigBee standard. The main task for thislayer is to form the network. This involves handling joining and leaving of devices,maintenance of the routing tables and the actual routing itself. If encryption isenabled that is also handled by this layer.

APL - Application layer

The application layer is created from three sub-layers, the APS, the AF and theZDO. Together they form a framework for the end user application. The frame-work introduces application objects, similar to BACnet objects (see 4.4.2), whichcorrespond to functions (a switch, a dimmer, an io-port, etc). The function couldbe dened by either the manufacturer (user dened) or the public proles. At themoment public proles for home control and lighting exist.

APS - Application Support Sub-layer

The application support sub-layer is the rst layer in the APL. The APS sub-layerbinds functions to nodes by building a table containing pairs of the function (appli-cation object) and source/destination address. This table could for example bind aswitch to a lamp.

AF - Application Framework

Each function (application object) stores one item in the application framework ta-ble. The application framework stores information about all local functions availablein that device (maximum 240 objects). This is then used both by the APS sub-layerand the ZDO.

ZDO - ZigBee Device Object

The last sub-layer of the APL is the ZigBee Device Object. This layer handlesenumeration of network application objects.

39

Chapter 5

Existing systems

As described in the history section (see section 2.2) individual heat/energy measure-ment is nothing new. Companies from both Sweden and other countries all over theworld have been developing and producing equipment for this purpose. This sectionwill give a brief introduction to some of these systems (components) produced bysome companies operating in Sweden.

Equipment for the following companies will be described:

• Brunata

• Metrima

• Techem

• Siemens Building Technologies

40

5.1 Brunata

Brunata A/S is one of the oldest companies in Europe producing and selling equip-ment for individual heat/energy measurements. The company was funded in 1935 inDenmark and has survived multiple fusions and splits until 1990 when the companytook its current shape. [8]

5.1.1 System

The system available from Brunata for individual heat/energy measurements isbased on a mix of wired and wireless modules. The system could also be usedif only remote meter reading is needed. In this case all measured data is read usinga hand terminal (wired or wireless) once a year.

Wireless

Although not all meters are wireless a special RS232/RS484 wireless transceiver isavailable giving wireless features to most meters. The wireless network is using aFSK modulated 433.92 MHz radio and a closed, company developed communicationprotocol called IMR-2. The wireless modules have a maximum range of 20 meters(from one end device to the receiver module).

Temperature meters

The standard temperature sensor used by Brunata is a stand alone temperaturelogger that could be connected to a central data collection system through a wirelessconnection. The wireless connection is not required and the temperature sensorcould store information for up to 2 years. Within this time it is possible to manuallyread the stored information and proceses it. The history is also accessible by thetenant on an integrated display.

Table 5.1: Brunata temperature meters

Name Connection TypeElectric com-fort meter

Manual, RF 0.1 C resolution

Water meters

Single-/multi-jet ow meters and inductive ow meters are the meter of choice inBrunatas systems (see section 3.1.1). These meter types are used both for hot-and cold water measurements and communicates with the data collection systemthrough an M-bus network.

41

Table 5.2: Brunata water meters

Name Connection TypeHGW M-bus,

RS232Inductive meter

BLZ Pulse Single-jet ow meterHydrometerMNR

Pulse Multi-jet ow meter

Heat measurement meters

Brunata is using two dierent systems for heat measurements. One of the systemsis based on a transit time ow meter (see section 3.1.2) with two inputs for externaltemperature sensors. The product is called SharkY and is usually used togetherwith two Pt-500 temperature sensor (see section 3.2.2). This meter measures thetemperature dierence between the input- and output water together with the owand then calculates the energy transferred to the apartment. The communicationwith the central data collection system uses M-bus or in some cases a pulse signal(one pulse per KWh), but it could also be used as a standalone meter.

The other system is called HGQ and HGS and is based on an inductive ow meter(see section 3.1.4) and two inputs for external temperature sensors. Except for theow measurement technique this meter works exactly the same as the previous meter(SharkY).

Table 5.3: Brunata Heat measurement meters

Name Connection TypeSharkY M-bus, Pulse

outputTemperature dierence ow meter

HGQ/HGS M-bus,RS232

Inductive ow meter

42

5.2 Metrima

Metrima is the company the most successful Swedish company working in this seg-ment. The company was funded in 1942 as Svensk Värmemätning (SVM) and hasgrown by buying other companies (ABB metering, North Node and Home SolutionsAB). [9]

5.2.1 System

Brighthome Center is the name of the individual heat/energy measurement systemsupplied by Metrima. This system implements all features required for this typeof system Furthermore it also adds surveillance features like re alarm and accesscontrol.

The system is built from network (TCP/IP) connected central- and sub con-trollers. The sub controllers are then connected to the sensor modules throughM-bus, RS232, RS485 or pulse signals. All collected information is then sent over alocal area network or the internet to the central collection unit.

MCom3 is a similar system to the Brighthome Center system, suitable for largerinstallations. This system is built from the similar components as the BrighthomeCenter system, but it works with other techniques including M-bus and GPRS(TCP/IP, RS232/ RS485 is also used). Compared to the Brighthome Center sys-tem, the MCom3 system is capable of storing information from heat, electricity, gas,water and also customer requested parameters. The Brighthome Center system juststores information from the basic sources (heat, water, temperature).

Temperature meters

The temperature sensors used in the Brighthome Center system is a standard semiprecision temperature sensor (0.1 C resolution). The temperature sensor moduleis connected to the sub controller through a wired connection, including both powerand data lines and the measured temperature is recorded on predened intervals.

Table 5.4: Metrima temperature meters

Name Connection TypeMLTS RS232 0.1 C resolution

Water meters

Metrima is using single-jet ow meters (see section 3.1.1) to measure water con-sumption, both cold- and hot water. The water meters are wire connected to thesub controller with a pulse signal which gives one pulse for each 10L consumed.

43

Table 5.5: Metrima water meters

Name Connection TypeABB 141(Cold water)

Pulse output Single-jet ow meter

ABB 142(Hot water)

Pulse output Single-jet ow meter

Heat measurement meters

The heat meter used in Metrima's system is a standard temperature dierence owmeter (See section 3.4.1). The meter is equipped with an M-bus and pulse outputinterface for communication with the rest of the system.

Table 5.6: Metrima heat measurement meters

Name Connection TypeSVM F 27 M-bus, Pulse

outputTemperature dierence ow meter

44

5.3 Techem

Techem is one of the larger companies in Europe supplying equipment for individualheat/energy measurements. The company was funded in Germany in 1952 and hasgrown to a company with more then 2000 employees in 20 countries (all located inEurope). In the year 1999 Techem expanded and opened a new oce in Stockholmand until this day more then 7 million apartments have had systems from Techeminstalled. In general each of these apartments has had 5 sensor modules installed.[10]

5.3.1 System

The systems available from Techem are using a mix of wired- and wireless modules.All functions with control features are using wire connected communication using theM-bus protocol (see section 4.3) and RS232. Data collection devices like temperaturesensors and water meters are also using M-bus/RS232, but wireless versions areavailable and used when remote meter reading is required.

Temperature meters

The temperature sensors used in Techem's systems are of high precision type (mainlypt-100 temperature sensors, see section 3.2.2). The precision is in the range of 0.03C to 0.1 C. The room temperature sensor used in Techem's new systems is calledTM data and is a battery powered, wireless, high precision temperature sensor (seedatasheet [11]).

Table 5.7: Techem temperature meters

Name Connection TypeTM data S FM RTD (see 3.2.2)

Water meters

Techem is using three dierent types of uid meters. Single-/multi-jet ow metersare used in the vario S product (see section 3.1.1), transit time ow meters areused in ultra S (see section 3.1.2) and inductive uid meters are used in the productScylar-heat (see section 3.1.4). The dierent sensors full all dierent needs requiredfor an individual heat measurement system, from the small ows in an apartmentto the big ows on the supply lines.

Heat measurement meters

The heat added from the radiator(s) is measured by doing an integration betweenthe temperature dierence of the radiator and the surrounding temperature (room

45

Table 5.8: Techem water meters

Name Connection Typevario S M-bus, FM Single-jet ow meterultra S M-bus Transit Time Flow MeterScylar-heat M-bus,

RS232, 4-20mA

Inductive ow meter

temperature), and the nominal eect of the radiator 1. The sensor used in Techem'ssystem is called FHKV Data and is using FM signals to communicate with thesystem.

Table 5.9: Techem uid meters

Name Connection TypeFHKV Data FM Two point radiator heat meter

1The nominal eect of the radiator is an eect the radiator can transfer from the hot water to

the air

46

5.4 Siemens/Siemens Building Technologies

Siemens Building Technologies (SIBT) is one of the largest companies in North-ern Europe producing and selling equipment for industrial applicaions (regulators,automation, etc), but they also have products for home applications.

Today SIBT is working with the following segments

1. Building Automation

2. Fire Safety

3. HVAC Products

4. Security Systems

5.4.1 System

SYNERGYR is the main system for individual heat measurement sold by SIBT.This system is built from three dierent techniques depending on how and wherethe system is installed. For old buildings or buildings that can not be rebuilt thereis a wireless system. In new buildings or where M-bus (see section 4.3) equipment isalready installed wired M-bus is the technique chosen. The last system is the mostadvanced system and has all the features from the two other ones, but it can alsobe used to control (automate) temperature etc. [12]

M-bus

The M-bus system is an older type then the wireless one, with all the limitationsthe M-bus protocol have. But because of the good supply of M-bus devices andthe high reliability, it is still a well-working system. The fact that a larg amountof equipment already installed in many homes is using M-bus is one other strongpositive point about this system.

Wireless system

The wireless system is built from wireless sensor modules located all over the apart-ment/building. The radio signal is sent from each sensor to a data collection unitlocated on each oor (these devices are usually placed in the stairways). All thedata collection units are then connected to a central data collection point through awired communication network. This system is just for heat/comfort measurementsand it is not possible to control temperature etc.

Controll and measure system

If controll features is required the third system must be used. This system use mod-ules from the previous systems (M-bus and wireless) together with electric radiatorvalves and other equipment for automation.

47

Chapter 6

ZigBee feasibility

As shown in chapter 5 existing systems from dierent manufacturers use a wide rangeof both dierent sensors and dierent communication techniques. In many casesboth wired- and wireless modules are used in the same system forming a well workingsystem. Although these systems work wel, there is a good reason why ZigBee is moresuitable for individual heat/energy consumption measurements. By using a standardwireless communication network, modules from dierent manufacturers can be usedtogether (if public proles are used) for reducing the cost. For example the cheapestsensor modules can be used and the increased number of sensor modules will lowerthe cost per unit. Therefore, there is a good opportunity to create a system entirelybased on wireless modules. This will keep the installation cost low and at the sametime create a robust system. In many cases ZigBee is more more robust than awired system, because of the routing/repair features of ZigBee.

As shown in gure 6.1, the data rate of Zigbee is low compared to other wellknown wireless techniques like Wireless LAN and Bluetoth. With a maximum trans-fer speed (for the whole network) of 250 kbit/s and a range of up to 150 meters(outdoor without obstacles), ZigBee is mostly used for sensor networking. The re-quired data rate for a sensor network is small. In general the transfer speed neededis in the range of 1 to 250 kbit/s (see section 4 for more information).

Another important parameter is the life time of each battery powered node. Asshown in gure 6.2 the time before a battery has to be replaced in a ZigBee nodeis high compared to all other techniques except for RFID (passive RFID-tags donot need a battery and active tags only communicate while placed "in front" of the"reader" unit). The high operation time (battery-powered) for a ZigBee node isonly available on the RFD;s (Reduced Function Devices) and is achived by lettingeach node /transiever stay in a low power mode (sleep) except for a predeneda time interval when each node wakes up and handles it tasks. The FFD (FullFunction Devices) and coordinator must be mains-operated (with a battery backup)for reliable operation. The long operation time for battery power devices are one ofthe best arguments for using ZigBee instead of the other techniques.

The number of nodes in each network (without bridge coupling between multiplenetworks) is another strong argument for ZigBee. The theoretical number of nodesin each network is over 65000, compared to eight for Bluetooth and around 300 forM-bus. Notices that this is the theoretical limit, the number of nodes in a ZigBee

48

Figure 6.1: Range versus data rate

based sensor network implementation is usually much lower because the network isnot symmetrical (a none symmetrical network will result in routning complications)and the system resource in each node is limited.

Previous work at ITN has shown that ZigBee modules placed on the right posi-tion can communicate with each other no matter if the walls are created from woodor concrete. The work done by Richard Nilsson and Christian Ramsten [13] hasshown that the placement of the sensor is crucial for the functionality of the net-work. Their work has also shown that the range is limited by the obstacles locatedbetween two nodes and that the best position for a node (if only one node is locatedin each room) is next to the door [13].

The work by Johan Lönn and Jonas Olsson has also shown that ZigBee is wellsuitable for battery powered applications and therefore ideal for sensor networks.The ZigBee modules they created, the same used in this thesis, have worked perfectlythrough out the project [14].

Today the only big problem with ZigBee is that it is more expensive than otherexisting techniques. The production cost for a ZigBee node starts around $15 com-pared to $2-5 for the simplest traditional nodes. This will probably decrease as theuse of ZigBee increases, but it is still an unknown parameter.

49

Figure 6.2: Battery life time versus data rate

Figure 6.3: Battery life time versus data rate

50

Chapter 7

System integration

It does not matter how fancy or advanced a data collection system is, if measureddata cannot be analyzed. How the data is analyzed is entirely dependent on theapplication, and in this case historical trends of all measured information are theprimary source for the analyzsis. For this reason a Windows application have beencreated, displaying all the information needed.

7.1 Design process

7.1.1 System requirments

• Receive (and Transmit) data from ZigBee network

• Store historical data

• Do some basic analysis

• Work on Windows

7.1.2 System restrictions

• Use existing hardware at ITN

• Stable enough for further testing

7.1.3 Development platform

A data collection software of the kind described in this report has no realtime re-quirements, the only performance considerations required is that the user will notexperience lag. For this reason a high level language like VB (visual basic) or Pythoncould have been use. Java and .NET is also possible platforms, but my knowledge isbest in c and c++ and therefor I decieded to write everything in c++. One benitof writing it in c++ is that the server requires small system resources. This a bigadvantage because the server is designed to run as a system service.

51

Both the client and server is developed in C++ (Microsoft Visaul Studio) com-patible with version 2002/2003 and 2005 (not express edition). The client is dy-namicaly linked to MFC (Microsoft Foundation Class) and the freeware version ofProf-uis (Professional User Interface[15]). The server is dynamicly linked to MFC[16] (easy to remove). All source code is available on request.

Part of the code for the client is made by others:1

Table 7.1: 3part contributors

Class AutourCColourPopup Chris Maunder/Alexander BischofbergerCMemDC Keith RuleScientic charting control Gunnar Bollexmllib Lee ThomasonProf-uis FOSS Software, Inc

1see source code for more information

52

7.2 System overview

The whole system has been designed to be a true client-server application. Thereis one dedicated application to communicate with the ZigBee network through aUSB connection. This application also implement some monitoring functions forthe ZigBee network (see below for more information). The second software is theend user display and analysis application. In this software, graphs and tables displayhistorical measured data stored in the third part of the system, the database (seegure 7.1).

Right now it is not possible to display live updated data (it is not possible tocommunicate with a sensor directly).

Figure 7.1: System implementation.

7.3 Hardware

All the hardware used in this thesis is previously created at ITN [14]. For this rea-son only humidity and temperature is possible to measure, but the system has beendesigned to work with all important parameters for individual heat/energy mea-surement system including water, electricity and heat measurements. The hardwareincludes a USB/ZigBee module (for communication with the PC) and temperatureand humidity sensors all with a ZigBee interface.

53

7.3.1 ZigBee/USB protocol

The communication between the ZigBee network and the PC uses a simple protocoldesigned to transfer dierent messages over the same connection. The protocolcontain a header (message type and message length), a data payload section and atail containing information about the transmitter (source address or PIDL2 and aLQI3) (see gure 7.2 and table 7.2)

Packet format

Figure 7.2: ZigBee/USB communication protocol

Table 7.2: ZigBee/USB communication protocol

Byte index Information0 Packet type1 Packet length. Message length = Packet

length + 22 .. length - 3 Packet payloadlength - 2 Source address highlength - 1 Source address lowlength Link Quality Indicator

2A PIDL is a 16 bit address each ZigBee node can be indentied from3Link Quality Indicator

54

Packet type

Table 7.3: ZigBee/USB packet typesValue Description0x81 Humidity0x82 Temperature

55

7.4 Server

Figure 7.3 shows the block diagram of the server implementation. All the importantblocks will be described more in the following sections. Notice that the source codefor this application is not included in this report, but it is available on request (seeappendix C).

Figure 7.3: Server implementation

7.4.1 Reader

The reader class has control over the input and output communication with the Zig-Bee network. This class receives data and stores the received data in a ciruclar buer(also known as a ring buer)4. The ciruclar buer is used for maximum performancewith minimum system resources and for the ability to handle multiple packets withdierent length (A normal xed buer must be allocated as the maximum packetlength multiplyed by the number of buered elements and the dynamic buer mustbe allocated/deallocated for each packet).

Receive data

The receiver works as shown i gure 7.4. The receiver loop rst checks if the portis open, if not, it handles all received data so far and then end the receiver loop.If the port is open and valid then the receiver tries to read information from thedriver buers. If no data is available it sleeps for one millisecond. This will reducethe need for system resources (cpu time) for the application when it is not needed.If data is received, all data is written to the circular buer for further processing.After all received packets are decoded the receive loop continues.

4A circular buer is a buer with xed size, but where data will be wrapped

56

Figure 7.4: Receive data

Decode received data

If the circular buer contains less than 2 bytes of data, no packet is received. In thiscase we just return to the receive loop (is due to the communication protocol used.see section 7.3.1 ). Otherwise 2 bytes of data are peeked from the buer to decidethe length of the packet. If the length is larger than the length of the stored datain the buer, it just return to the receive loop to read some more data (the recevieddata is not an entire packet). If the amount of data i enough, the data is decoded(depending on the packet type, dierent decoding will take place) and sent to theupdate buers. Finally before the decode loop tries to decode next packet, decodeddata is removed from the buers.

Figure 7.5: Decode data

57

7.4.2 Update - Processing

The update block handles all decoded packets. Depending on the packet type dier-ent tasks will be executed. A normal packet with measured data (the only availabletype) will execute a database update (the new data will be added to the databaseand the sensor last update parameter will be updated).

7.4.3 Database

The DB block handles all communcation with the database server, both reading andwriting. Because the server is using multithreading technology, and multiple threadsneed access to the database, synchronization is needed (Standard ODBC API is notthread safe). This is also done by this block. The synchronization is implementedwith a processing queue. Each database operation adds a new task to the queueand then each task is executed in sequence.

Database tasks

There are two dierent types of tasks available, blocking and none blocking. Thenone blocking task is a task that does not need conrmation (for example updat-ing a sensor state). The blocking tasks waits for the database operation to nish,then executing some code, before new tasks are executed. The disadvantage of theblocking tasks is a reduced system preformance (other threads may have to wait forthe database operation to nish.

7.4.4 Event engine

The event engine handles and produces network events. For example if a sensor isnot responding in a predened time, an event is generated to notify the maintenancedepartment to replace it or change batteries etc.

7.4.5 Other blocks

The server also contains some less important blocks. These blocks are not criticalfor the function of the application, but they give the possibility to nd problemsand to run in dierent environments without recompiling.

7.4.6 Sensor manager

All installed sensors (installed in the database) has a reference in this block. Thesensor manager stores information about last comunnication with each ZigBee mod-ule. This information is used by the event engine to keep track of timeouts, etc.

Log

The log block stores information about the program execution, warnings, errors etcto a le on the harddrive. This le is usually stored in .\logs\and the le will beappended on each update. Old information must be removed manually.

58

Settings

This class handles program settings including database connection settings. Thesettings are stored in an xml le and this settings le will be loaded when theserver starts and rewritten when the program stops. Notice that modication of thesettings must be made by hand.

7.4.7 Operations

Start the server

The start procedure for the server includes connecting to the database and openingthe COM port at which the ZigBee/USB module is connected. If one or more ofthese steps fail, the server will shutdown again. Figure 7.6 shows a summery of thestart procedure. As shown in this gure the rst step includes loading the setting,then connecting to the database. Then the event engine is started before the updateor processing unit is loaded.

Finally all installed sensors/modules are enumerated and added to the sensormanager.

Figure 7.6: Start the server

59

Terminate the server

Shutting down the server works in the same way as starting the server, but becauseinternal buers are used, the order of termination is important for reducing data losseects. The rst step is to shutdown the hardware (ZigBee/USB module), whichprevent the server from receiving any more data from the network. Then the existingbuers are processed and when this is nished the event engine stops after that theremaining database operation is executed. Finally the database connection is closedand the server is stopped.

Figure 7.7: Terminate the server

7.5 Client

The client application is the software that the maintenance crew or building owneruse to display information about the buildings/apartments. The software displayshistorical information about water consumption, heat consumption, humidity andtemperature for all the installed sensors. Each sensor can be placed at any locationin the buildings and after the program is setup it automatically displays the correctinformation for selected objects.

The GUI 5 in the client uses a standard "explorer" type interface6. By select-ing a building or an apartment in the tree located to the left (see gure 7.8), theinformation for that object is displayed in the right view. The information shownis a summary of all stored information for all "lower objects" (if an apartment isselected all information from that apartment and all information from all rooms in

5Graphical User Interface6An explorer interface means a tree control is controlling what is shown in the all the other

views

60

that apartment is shown, but no information is shown for the building where theapartment is located in).

Figure 7.8: Client application

7.5.1 Source code

Notice that the source code for this application is not included in this report, butit is available on request (see appendix C).

7.5.2 Connecting to the database

Connecting to the database server is done by pressing File Connect, pressingthe short key F2 or by pressing the connect icon (see gure 7.9). When one ofthese inputs is made, a window pops up and asks for the server name/port andusername/password. If the database server is running locally or the database isused in a windows 2000 or windows 2003 domain environment, a trusted connectioncan be used (a trusted connection is using the windows login username and passwordfor autorization). Otherwise a username and password must be provided (Notice,the username and password at this stage is for database login).

The database server used with the gures below is MSSQL Express and the serveris running on ip-number 130.236.134.111 (more information about the databasecould be found in section 7.6).

61

Figure 7.9: Connecting

Figure 7.10: Setting up the new connection

7.5.3 Navigation

Selecting an object in the navigation tree control (see gure 7.11) will update theinformation shown in the display view (the right view). The navigation tree isupdated from the database as the tree expands. Each update will display a windowwhere information about the update is shown. Notice, on fast computers with goodconnections to the database, this window may only ush.

Navigation between dierent information can also be made by pressing the hy-perlinks (similar to hyperlinks on the web) located in the right view. In this casethe navigation tree control will automatically be expanded so the selected object isaccessible and so the hierarchy is shown.

Figure 7.11: Navigation tree

62

7.5.4 Detailed information about the client application

For detailed information about the client application please look at the source codeand the documentation of the source code.

7.6 Database server

Based on the size of an individual heat/energy consumption measurement system,dierent data storage demands must be fullled. But no matter if the system has25 or 250 sensor modules the storage demands are high. For this reason a PC baseddatabase server has been included as one part of the system (if history is not neededthe database server could be removed). By using a database server backup and othermaintenance become easy, standard third-party or database engine tools could beused.

A MSSQL 2005 database Server has been used in the development process. Forsmall installations a MSSQL 2005 Express Edition database could be used (thefreeware edition of MSSQL 2005).

The database design does not rely on any advanced features. All database tablesare directly accessed by the client and server application.

7.6.1 ODBC

The communication between the server/client application and the database is achievedby using an ODBC driver7. This makes both applications independent of databasemanufacturer (connection strings must be changed according to the documentationof each database). Depending on the database chosen, dierent ODBC drivers mayneed to be installed. On a standard windows installation (windows 2000/XP/Vista)ODBC drivers for MSSQL are preinstalled, but drivers for other database engines forexample MySQL (http://www.mysql.com) and Oracle (http://www.oracle.com/)must be installed manually.

7.7 Demonstration application

Implementing a full functional Windows program requires much code. The twosoftwares described above for example consist of more then 900 KiB (Kilo byte, 210

byte) of code. For this reason a simple demo application has been written. Thesoftware just reads the data from the ZigBee network using a VCP driver8 anddisplays the received information on screen.

The software also describes the basic concepts of setting up serial communicationusing standard API9 (usually called WINAPI10 on Windows platform)

The ZigBee/USB protocol is described in section 7.3.1 and will not be describedmore.

7Open DataBase Connectivity8Virtual COM Port9Application programming interface10Windows Application programming interface

63

7.7.1 Source code

Open a COM-port

The rst step to read information from the ZigBee network is to connect to theUSB-ZigBee module. This is done by connecting through a VCP-driver11. Theconnection is opened using the CreateFile command with the port name as one ofthe arguments. Notice if the port number is less then 10 (com1 to com9) the portcan be accessed through the short name "..\\COM6:" otherwise "..\\.\\COM6:"has to be used. The CreateFile command can also be used to open local les (CreateFile("c:\\temp.txt", ...) ) or to open drives ( CreateFile("..\\.\\C", ...)

HANDLE hHandle = INVALID_HANDLE_VALUE;

hHandle = :: CreateFile( szPort ,

GENERIC_READ | GENERIC_WRITE ,

0,

NULL ,

OPEN_EXISTING ,

0,

NULL

);

if ( hHandle == INVALID_HANDLE_VALUE )

printf( "Failed to open port [%s]\r\n", szPort );

return false;

printf( "Com port open [%s]\r\n", szPort );

Set port settigs

The next step is to setup the port. The USB-ZigBee module communicates at 38400bits/s, one stop bit, no parity and hardware ow control. This is initialized usingthe GetCommState and SetCommState, the GetCommState command is called fordefault parameter initialization, and the SetCommState set the new settings.

DCB dcd;

if ( !:: GetCommState( hHandle , &dcd ) )

printf( "Failed to load port settings\r\n" );

:: CloseHandle( hHandle );

return false;

// Setup the new port settings

dcd.BaudRate = CBR_38400;

dcd.ByteSize = 8;

dcd.Parity = 0;

dcd.StopBits = ONESTOPBIT;

dcd.fDtrControl = DTR_CONTROL_HANDSHAKE; //

dcd.fOutxCtsFlow = TRUE; // Hardware flow

dcd.fOutxDsrFlow = TRUE; // control

dcd.fRtsControl = RTS_CONTROL_HANDSHAKE; //

dcd.fInX = 0;

11Virtual COM Port

64

dcd.fOutX = 0;

if ( !:: SetCommState( hHandle , &dcd ) )

printf( "Failed to setup port settings\r\n" );

:: CloseHandle( hHandle );

return false;

printf( "Com port settings set\r\n" );

Timeout

Then the timeout for each operation must be set (Read and Write). Just like theprevious step the default parameters are rst read using the GetCommTimeouts

command, then the paramaters are updated and nally the timeout parameters arewritten using the SetCommTimeouts command. By setting the timeout the programis able to run in a single thread, otherwise a read or write command will lock theprogram and it will not continue until the connection is closed.

COMMTIMEOUTS commtimeouts;

:: memset( &commtimeouts , 0, sizeof( COMMTIMEOUTS ) );

if ( !:: GetCommTimeouts( hHandle , &commtimeouts ) )

printf( "Failed to get port timeouts\r\n" );

:: CloseHandle( hHandle );

return false;

commtimeouts.ReadIntervalTimeout = 3000; // 3000 ms

commtimeouts.ReadTotalTimeoutMultiplier = 1;

commtimeouts.ReadTotalTimeoutConstant = 3000; // 3000 ms

commtimeouts.WriteTotalTimeoutMultiplier = 0;

commtimeouts.WriteTotalTimeoutConstant = 1000; // 1000 ms

if ( !:: SetCommTimeouts( hHandle , &commtimeouts ) )

printf( "Failed to set port timeouts\r\n" );

:: CloseHandle( hHandle );

return false;

Final initialization

The nal step before we are ready to read information from the ZigBee network isto ush the rx and tx buers. This is done because previous received data (receivedbut not handled) is stored in the driver buers. By ushing the buers we also knowthat the rst byte read is the rst transmitted byte in the next packet. The reasonfor this has to do with the hardware ow control. The actual ushing is achievedby calling the FlushFileBuers command.

// Flush the RX and TX buffers

if ( !:: FlushFileBuffers( hHandle ) )

printf( "Failed to flush buffers\r\n" );

65

:: CloseHandle( hHandle );

return false;

Read information

Now when the port is opened and initialized we are ready to read data. The standardfunction to read information from a COM-port/le is ReadFile. This function triesto read data from the opened port/le and waits until the specied length has beenreached or a timeout has occurred. A negative result means the read failed (usuallybecause the port/le is closed), a zero result means that the function call timeoutand a positive result corresponds to the number of bytes read.

nResult = :: ReadFile( hHandle ,

pBuffer ,

max( 0, MAX_RX_PACKET_LENGTH - nLen ),

&nRead ,

NULL );

if ( nResult < 0 ) // An error occured

printf( "An error occured\r\n" );

break;

Close port

When the application ends the port must be closed again. This is done by callingthe CloseHandle function.

:: CloseHandle( hHandle );

66

Chapter 8

Results and conclusions

The market for individual heat/energy measurement systems is recently growingfast. The products available on the market today work well, but it is still problematicto connect devices from dierent manufacturers and the installation cost is high.

8.1 ZigBee feasibility

This work has shown that wireless ZigBee modules can be used as one solution tolower the installation cost and to create a system only based on wireless nodes. Onereason for this is that no additional cables is installed in either newly constructedbuildings or in old one (if battery powered devices are used) . At low volumes ZigBeemodules are more expeansive than traditional devices, but as the volume increasesand ZigBee modules are installed in more homes (for other reasons than heat/energymeasurements), the big advantage of using the ZigBee appears.

8.2 Software

This work has developed a functional Windows application suite for data collectionfrom a ZigBee based system for individual heat/energy measurement (see gure 7.8for screenshot). The program has not been nished for a public release, but it isstable enough for further testing. The system implements all functions needed formeasurements and analysis of information from a sensor to larger networks (mea-surements can be grouped by sensors, rooms, apartments, buildings and companies).The information is displayed in a structured way. It includes all information aboutall sensors in a building, even sensors associated with an apartment or a room, inthe selected building. The system is based on a standard database, therefore newfeatures could be added easily, including a web interface or an application for smartphones.

67

Chapter 9

Further work

9.1 Application

1. Direct access to ZigBee modules, both server - ZigBee module and client -

ZigBee module.

2. Web based interface

9.1.1 Client

1. Add printing support

2. Add export support

9.1.2 Server

1. Plugin support - Making it possible to change the software functionality basedon the demands of the customer.

9.1.3 Database

1. Right now the database is not multi-user write-safe. If two users change somedata "at the same time" it is not possible to know what data is stored. Theusers do not get any warning either.

2. User authorization/user administation also needed. Right now all logged inuser gets administrator access.

68

Appendix A

Formulas

A.1 General curve tting

R(T ) = Rref

(1 + a1∆T + a2∆T 2 + .. + an∆T n

)(A.1)

where ∆T = T − Tref (Tref is usually 0C)

where a1, a2, .., an is material constants

A.2 Doppler ow meter

Doppler shift principal

f ′ =

(v + vo

v − vs

)f (A.2)

f = Source frequency

f ′ = Observed frequency

v = Speed of sound in the material

vs = Speed of sound source

vo = Speed of sound observer/receiver

Fixed transmitter and receiver position

f ′ =(1− vf

v

)f (A.3)

vf = Speed of the fluid flow

A.3 Inductive ow meter

ε =δΦ

δt+

∮(v ×B) · dL (A.4)

69

A.4 Resistance temperature detector (RTD)

Applied formula for Platinum sensors (Callendar - Van Dusen equation)

R(T ) = Rref

(1 + a1∆T + a2∆T 2 + a3 ∗ (∆T − 100) ∆T 3

)(A.5)

Linearized equation

α =R100 −R0

100 ∗R0

[Ω/C] (A.6)

Material Polynomial Coecients αCopper 0.00427Ω/C

Nickel a1 = 5.485 ∗ 10−3

a2 = 6.650 ∗ 10−6

a3 = 2.805 ∗ 10−11

a4 = −2.000 ∗ 10−17

0.00672Ω/C

Platinum a1 = 3.90830 ∗ 10−3

a2 = −5.77500 ∗ 10−7

a3 = −4.18301 ∗ 10−12

0.00385055Ω/C

Table A.1: RTD material constants

Polynonmial coecients supplied by CAPGO [17]

A.4.1 Reference design

There are two standard circuits for measuring temperature with a RTD sensor.The simplest one is built from a voltage divider where the RTD sensor is one of theresistors. This circuit works ne for low precision applications where the temperaturerange is limited to indoor climate, but in many case where RTD;s is used higherprecision is needed. For this reason a temperature compensating current sourceis more suitable. The circuit described below (see gure A.1) is one example onhow this could be implemented. This current source works by using the fact thatthe voltage drop across the zener diode is constant so the voltage over R2 will beconstant. In this case IE and IC will be equal, so by choosing the value of R2 thecurrent through the load can be adjusted, independent of the load resistance. Theresistor R1 is supplying the base current for the transistor and the zener currentfor the zener diode. The last diode is removing the temperature dependent of thecurrent supply by "removing" the transistor VB voltage (see equation A.8).

70

Figure A.1: RTD reference design with temperature compensation

The value of the resistors can be calculated using equation A.7 and A.8.

R1 =VS − VZ − VD

IZ + hfe ∗ IB

(A.7)

R2 =VZ + VD − VBE

IR2

(A.8)

A.5 Thermistors

R = Rrefeβ( 1

T− 1

Tref)

(A.9)

T =Trefβ

β + Tref (ln R − ln Rref )(A.10)

T =Tref

1 +Tref (ln R−ln Rref )

β

(A.11)

T Temperature (inK)R Resistance of the sensor

TRef Reference temperature (usually25 C or; 298.15K)RRef Resistance at TRef

β Calibration constant (material constant)

A.6 Solid state

V = ln

(I(T )

I0

+ 1

)kT

q(A.12)

71

Appendix B

Demo application

B.1 Source code

c_usb_reader_demo.h

// c_usb_reader_demo.h

#ifndef C_USB_READER_DEMO_H

#define C_USB_READER_DEMO_H

bool usb_read_demo( char *szPort );

#endif // C_USB_READER_DEMO_H

c_usb_reader_demo.cpp

// c_usb_reader_demo.c

#include "stdafx.h"

#include "windows.h"

#include "conio.h"

#define MAX_RX_PACKET_LENGTH 11

#define RX_BUFFER_SIZE MAX_RX_PACKET_LENGTH

void _hex_nible( char buffer , char ** pphexbuffer )

BYTE data = (BYTE)buffer & 0x0F;

if ( data >= 0 && data <= 9 )

(** pphexbuffer) = '0' + data;

else if ( data >= 10 && data <= 15 )

(** pphexbuffer) = 'A' + data;

(* pphexbuffer) ++;

void _hex( char buffer , char ** pphexbuffer )

_hex_nible( ( buffer >> 4 ), pphexbuffer );

_hex_nible( buffer , pphexbuffer );

(** pphexbuffer) = ' ';

(* pphexbuffer) ++;

72

void expand_hex_buffer( char *buffer , int nLen , char *phexbuffer )

// Notice hexbuffer must be 3 times larger then buffer

char ** pphexbuffer = &phexbuffer;

for ( int n = 0; n < nLen; n ++ )

_hex( buffer[n], pphexbuffer );

(*(* pphexbuffer) ) = '\0';

bool usb_read_demo( char *szPort )

HANDLE hHandle = INVALID_HANDLE_VALUE;

// Open the port. If the port has a lower index then 10

// "\\ COM2:" will work , otherwise you have to write

// "..\\.\\ COM10 :"

hHandle = :: CreateFile( szPort ,

GENERIC_READ | GENERIC_WRITE ,

0,

NULL ,

OPEN_EXISTING ,

0,

NULL

);

if ( hHandle == INVALID_HANDLE_VALUE )

printf( "Failed to open port [%s]\r\n", szPort );

return false;

printf( "Com port open [%s]\r\n", szPort );

DCB dcd;

if ( !:: GetCommState( hHandle , &dcd ) )

// We couldn´t get the port settings so we can´t change the

// baudrate etc. so we just close the port

printf( "Failed to load port settings\r\n" );

:: CloseHandle( hHandle );

return false;

// Setup the new port settings

dcd.BaudRate = CBR_38400;

dcd.ByteSize = 8;

dcd.Parity = 0;

dcd.StopBits = ONESTOPBIT;

dcd.fDtrControl = DTR_CONTROL_HANDSHAKE; //

dcd.fOutxCtsFlow = TRUE; // Hardware flow

dcd.fOutxDsrFlow = TRUE; // control

dcd.fRtsControl = RTS_CONTROL_HANDSHAKE; //

73

dcd.fInX = 0;

dcd.fOutX = 0;

if ( !:: SetCommState( hHandle , &dcd ) )

printf( "Failed to setup port settings\r\n" );

:: CloseHandle( hHandle );

return false;

printf( "Com port settings set\r\n" );

// Setup port time outs

COMMTIMEOUTS commtimeouts;

memset( &commtimeouts , 0, sizeof( COMMTIMEOUTS ) );

if ( !:: GetCommTimeouts( hHandle , &commtimeouts ) )

printf( "Failed to get port timeouts\r\n" );

:: CloseHandle( hHandle );

return false;

commtimeouts.ReadIntervalTimeout = 3000; // 3000 ms

commtimeouts.ReadTotalTimeoutMultiplier = 1;

commtimeouts.ReadTotalTimeoutConstant = 3000; // 3000 ms

commtimeouts.WriteTotalTimeoutMultiplier = 0;

commtimeouts.WriteTotalTimeoutConstant = 1000; // 1000 ms

if ( !:: SetCommTimeouts( hHandle , &commtimeouts ) )

printf( "Failed to set port timeouts\r\n" );

:: CloseHandle( hHandle );

return false;

printf( "Com port timeouts set" );

// Flush the RX and TX buffers

if ( !:: FlushFileBuffers( hHandle ) )

printf( "Failed to flush buffers\r\n" );

:: CloseHandle( hHandle );

return false;

DWORD nRead = 0;

INT nResult = 0;

char buffer[ RX_BUFFER_SIZE ];

char hexbuffer[ RX_BUFFER_SIZE * 3 ];

char *pBuffer = buffer;

bool bLQISet = false;

BYTE nLQImax = 0;

BYTE nLQImin = 0;

74

INT nPos = 0;

INT nLen = 0;

printf( "Started ...\r\n" );

printf( "====================================================="

"====\r\n" );

while ( true )

nResult = :: ReadFile( hHandle ,

pBuffer ,

max( 0, MAX_RX_PACKET_LENGTH - nLen ),

&nRead ,

NULL

);

if ( nResult < 0 ) // An error occured

printf( "An error occured\r\n" );

break;

if ( :: _kbhit( ) )

if ( :: _gettch () == ' ' )

break;

// Check if we received any data , if not just continue

// running the loop

if ( nRead == 0 )

continue;

pBuffer += nRead;

nLen += nRead;

// Check if we have received an entire message

if ( nLen >= 2 && nLen == buffer [1] )

expand_hex_buffer( buffer , nLen , hexbuffer );

// Reset the buffer pointer and the counter

pBuffer = buffer;

nLen = 0;

printf( "Packet recieved: Type: %d\n",

(UINT8)buffer [0]

);

printf( " Length: %d\n",

(UINT8)buffer [1] + 2

);

printf( " Address: %d\n",

(UINT16 )( buffer [8] << 8 ) | buffer [9]

);

printf( " LQI: %d (%0.2f%%)\n",

(UINT8)buffer [10], (( UINT8)buffer [10]) / 2.56

);

buffer [8] = '\0'; // Terminate the string ,

75

// this is dirty :')

printf( " Data: %s\n",

&buffer [2]

);

printf( " Raw: %s\n",

hexbuffer

);

if ( !bLQISet )

nLQImax = buffer [10];

nLQImin = buffer [10];

bLQISet = true;

else

nLQImax = max( nLQImax , buffer [10] );

nLQImin = min( nLQImin , buffer [10] );

:: CloseHandle( hHandle );

printf( "====================================================="

"====\r\n" );

printf( " LQI max: %d (%0.2f%%)\n",

nLQImax ,

(( UINT8)buffer [10]) / 2.56

);

printf( " LQI min: %d (%0.2f%%)\n",

nLQImin ,

(( UINT8)buffer [10]) / 2.56

);

_gettch( );

return true;

76

Appendix C

Source code

All source code is available on request. If you are interested please send me an emailbut notice the licence agreement:

Contact information

Email: johno591@student.liu.se

C.1 License

Modied BSD license* Copyright (c) 2007, Johan Nordlander

* All rights reserved.

* Redistribution and use in source and binary forms, with or without

* modification, are permitted provided that the following conditions are met:

*

* * Redistributions of source code must retain the above copyright

* notice, this list of conditions and the following disclaimer.

* * Redistributions in binary form must reproduce the above copyright

* notice, this list of conditions and the following disclaimer in the

* documentation and/or other materials provided with the distribution.

* * Neither the name of the author nor the

* names of its contributors may be used to endorse or promote products

* derived from this software without specific prior written permission.

* * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS AS IS AND ANY

* EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED

* WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE

* DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE FOR ANY

* DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES

* (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;

* LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND

* ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT

* (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS

* SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

77

Bibliography

[1] VVS Tekniska Föreningen (Swedish). Big-se. Internet, 2006.http://www.siki.se/page.html?pid=331.

[2] engineering fundamentls efuna. Internet, 2006.http://www.efunda.com/DesignStandards/sensors/thermistors/thermistors_theory.cfm.

[3] Microchip. Datasheet tc77. Datasheet, 2004.http://ww1.microchip.com/downloads/en/DeviceDoc/20092a.pdf.

[4] MBus.org. Internet, 2006. http://www.mbus.org/index.html.

[5] RFC3259. Internet, 2006. http://www.ietf.org/rfc/rfc3259.txt.

[6] Wikipedia. Internet, 2006. http://en.wikipedia.org/wiki/MBus.

[7] Professor Dr. Horst Ziegler. Der m-bus - eine neue europäische norm zur zäh-lerfernauslesung, 1996. http://fb6www.uni-paderborn.de/ag/ag-zi/ag-zi.htm.

[8] Brunata. Internet, 09 2006. http://www.brunata.se/.

[9] Metrima. Internet, 09 2006. http://www.metrima.se/.

[10] Techem. Internet, 11 2006. http://www.techem.se/.

[11] techem. Tm data. Datasheet, 11 2006.http://www.techem.se/Svenska/Kontakt/Broschyrer/TM_data/TM_data_6.sid.pdf.

[12] Siemens Building Technologies. Internet, 11 2006.http://www.siemens.com/index.jsp?sdc_p=ft15ml17s2uo1140292n1140292i1140293pc174z2&sdc_sid=32047368880&.

[13] Christian Ramsten Richard Nilsson. Trådlöst nätverk för övervakning och styrn-ing i fastigheter. Master's thesis, Linköpings Tekniska Högskola, campus Nor-rköping, 2005. ISRN: LITH-ITN-EX05/016SE.

[14] Jonas Olsson Johan Lönn. Zigbee ready modules for sensor networking. Mas-ter's thesis, Linköpings Tekniska Högskola, campus Norrköping, 2005.

[15] Inc FOSS Software. Internet, 11 2006. http://www.prof-uis.com.

[16] Microsoft. Msdn. Internet, 11 2006. http://www.msdn.com.

[17] CAPGO. Internet, 11 2006. http://www.capgo.com.

78