Mededeling
Mededeling
”Deze eindverhandeling was een examen; de tijdens de verdediging vastgestelde fouten
werden niet gecorrigeerd.
Gebruik als referentie in publicaties is toegelaten na gunstig advies van de
KHBO-promotor, vermeld op het titelblad.”
Announcement
“This thesis was an exam; all errors discovered during the presentation were not corrected.
Using it as a reference in publications is allowed only after approvement from the KHBOsupervisor, mentioned on the title page”
0
Preface
In the fourth and final year of the “Master of Science in Industrial Sciences: electronics”,
studies in Belgium, at the KHBO (Katholieke Hogeschool Brugge-Oostende) campus Ostend,
the students have to make a thesis, as a practical realization of their education. The KHBO
gave us the opportunity to perform this task abroad. We made this thesis in Technobothnia, a
laboratory in Vaasa, Finland. It is part of a bigger project, that we helped establishing through
this project.
Realizing a project of this size, is of course not something that is done alone. That is why we
want to reserve some space here, to thank all the people that helped us and supported us
during these months, and made it possible for us to finish this project.
First of all, we want to thank our supervisor, Dr. Smail Menani, who gave us the opportunity
to assist in this project, and who was always available when we had questions, or when we
needed good advise.
Furthermore, we want to thank Ing. Johan Dams and B.Sc. Liu Yang, who supported us, and
provided us with more technical advice on both software and hardware. We learned a lot from
them.
We want to say thanks to all the lecturers of the KHBO, for their contribution to our
education, and in particular, we want to thank Ing. Dorine Gevaert, who helped us with all the
procedures and practical problems concerning studying abroad. We also want to thank all our
fellow students, for the wonderful moments we shared during our studies.
Finally, we want to say thanks to our parents, who gave us the opportunity to start this
education, and who have always supported us, and motivated us to go on, no matter what.
1
Samenvatting
Onze thesis maakt deel uit van een globaal project over een beveiligd sensornetwerk. De
voornaamste toepassingen zijn beveiligingsdoeleinden en ‘remote nursing’. Het
sensornetwerk bestaat uit verschillende sensoren, die draadloos verbonden zijn met een
centrale node. De node verzamelt data van de sensoren, en kan die gegevens verwerken en
doorsturen. Data kan worden doorgestuurd naar een centrale server en daar worden opgeslaan.
De node is eveneens in staat om een boodschap te versturen over internet (vb. email) of over
het GSM-netwerk (vb. SMS). Als er iets gebeurt, wordt de gebruiker onmiddellijk op de
hoogte gebracht.
Dit project is in een beginfase, en onze thesis is gericht op het maken van een testopstelling.
We hebben enkele sensoren die verbonden zijn met een RF-module, die de signalen draadloos
kan versturen (transmitter) naar een ontvanger (receiver). Die data wordt dan via seriële
communicatie doorgestuurd naar de eerste “node”. Deze node is via TCP/IP verbonden met
het internet. Er is een tweede node, die fungeert als webserver, en de verstuurde data
visualiseert in een webbrowser. De gebruiker kan de website bezoeken en de huidige toestand
van de sensoren bekijken.
Ons project handelt dus vooral over draadloze communicatie, TCP/IP communicatie, seriële
verbinding en het gebruik en programmatie van meerdere microcontrollers.
Een tweede deel van onze thesis handelt over een “Random Number Generator”. In de
toekomst is het de bedoeling dat de verstuurde data geëncrypteerd zal worden. Voor die
encryptie is er een random nummer vereist. In ons project hebben we een schakeling gemaakt
die een “echt” random nummer genereert. Dit gebeurt op basis van een radioactieve bron, en
maakt gebruik van het spanningsverschil die de alfa-deeltjes genereren.
2
Summary
Our thesis is part of a gobal project, creating a wireless sensor network. The mean
applications are security measures and ‘remote nursing’. The sensornetwork consists of
several sensors which are connected wirelessly to a central node. The node collects the data
from the sensors, and is able to process the information. This node is connected with a central
server, where information can be stored. It has the capability to send a message over TCP/IP
(eg. email) or send a message over the GSM network (eg; SMS). If something happens, the
user can immediately be warned.
Our thesis is focused on making a testapplication. There are several sensors, which are
connected to a RF module. The RF module (transmitter) can send the signals wirelessly to
another RF module (receiver). The second RF module is serially connected with a “node”.
This node can send the information to the internet. There’s a second node that’s also
connected to the internet and can function as a webserver. This second node collects the
information and displays it in webbrowser. The user can visit the website and check the status
of the sensors.
Our project especially deals with wireless communication, TCP/IP communication, serial
communication and the use and programming of microcontrollers.
The second part of our thesis is about a “Random Number Generator”. In the future, the
transmitted data will be encrypted. Therefore a random number is needed. In our project, we
made a circuit that creates a “real” random number. The design is based on a radioactive
source and use the difference in voltage the alpha particles generate.
3
Table of contents
PREFACE................................................................................................................... 1
SAMENVATTING...................................................................................................... 2
SUMMARY ................................................................................................................ 3
TABLE OF CONTENTS ............................................................................................. 4
LIST OF FIGURES..................................................................................................... 6
LIST OF ABBREVIATIONS....................................................................................... 8
I.
INTRODUCTION............................................................................................... 9
1.
Vaasa Polytechnic and Technobothnia ...................................................................................... 10
2.
The global project .............................................................................................................................. 13
2.1
Sensor networks..................................................................................................... 14
2.2
Covering project.................................................................................................... 16
2.3
Different aspects of the project ............................................................................ 18
2.3.1 The sensors.......................................................................................................... 18
2.3.2 The sensor nodes................................................................................................. 19
2.3.3 The central server............................................................................................... 19
2.3.4 Security................................................................................................................ 20
2.4
Practical use ........................................................................................................... 21
3.
Participation and requirements.................................................................................................... 22
II.
THE TESTING APPLICATION ....................................................................... 24
1.
The entire design ................................................................................................................................ 25
2.
The sensors ............................................................................................................................................ 27
2.1
Goal......................................................................................................................... 27
2.2
Hardware ............................................................................................................... 28
2.2.1 Two types of sensors........................................................................................... 28
2.2.2 The sensor center................................................................................................ 29
2.2.3 The sensor board ................................................................................................ 32
2.2.4 The AT90S2313 microcontroller....................................................................... 34
2.3
The software........................................................................................................... 41
2.4
Testing .................................................................................................................... 42
4
The future............................................................................................................... 43
2.5
3.
The unidirectional point-to-point wireless connection ........................................................ 44
3.1
Goal......................................................................................................................... 44
3.2
The hardware......................................................................................................... 46
3.2.1 The RF-board ..................................................................................................... 46
3.2.2 The Radiometrix SP2-433-160 .......................................................................... 49
3.3
The software........................................................................................................... 56
3.4
Testing .................................................................................................................... 61
3.5
The future............................................................................................................... 62
4.
The sensor nodes ................................................................................................................................. 63
4.1
Goal......................................................................................................................... 63
4.2
The hardware......................................................................................................... 65
4.2.1 The DS80C400 microcontroller ........................................................................ 65
4.2.2 The TINI board .................................................................................................. 70
4.3
Software.................................................................................................................. 72
4.3.1 Node 1 .................................................................................................................. 72
4.3.2 Node 2 .................................................................................................................. 75
4.4
Testing .................................................................................................................... 78
4.5
The future............................................................................................................... 79
5.
Conclusion ............................................................................................................................................. 81
III. RANDOM NUMBER GENERATOR ................................................................ 83
1.
Goal .......................................................................................................................................................... 84
2.
Theoretical background................................................................................................................... 85
Symmetric and asymmetric encryption .............................................................. 85
Elliptic Curve Cryptography ............................................................................... 87
Principles of radioactivity..................................................................................... 91
Random number generator .................................................................................. 95
2.1
2.2
2.3
2.4
3.
Hardware ............................................................................................................................................... 98
4.
Testing and conclusion ................................................................................................................... 101
IV. FINAL CONCLUSION ................................................................................... 102
V.
APPENDIX ..................................................................................................... 104
BIBLIOGRAPHY ................................................................................................... 108
5
List of figures
Fig. 1. 1 - Vaasa Polytechnic ................................................................................................... 10
Fig. 1. 2 - Technobothnia ......................................................................................................... 12
Fig. 1. 3 - The global project ................................................................................................... 17
Fig. 2. 1 - The entire design - testing application .................................................................... 25
Fig. 2. 2 - The sensors - door/window position detector and motion detector ........................ 28
Fig. 2. 3 - The sensors - central control center........................................................................ 28
Fig. 2. 4 - The sensors - existing security system and accessing its data ................................ 29
Fig. 2. 5 - The sensors - sensor board schematic..................................................................... 33
Fig. 2. 6 - The sensors - sensor board...................................................................................... 34
Fig. 2. 7 - The sensors - microcontroller AT90S2313 pin package ......................................... 36
Fig. 2. 8 - The sensors - microcontroller AT90S2313 architecture ......................................... 37
Fig. 2. 9 - The sensors - microcontroller AT90S2313 memory map........................................ 38
Fig. 2. 10 - The sensors - programming an AT90S2313: the cable ......................................... 39
Fig. 2. 11 - The sensors - programming an AT90S2313: the programming interface............. 40
Fig. 2. 12 - The sensors - sensor board program..................................................................... 41
Fig. 2. 13 - The wireless connection - RF-board ..................................................................... 46
Fig. 2. 14 - The wireless connection - schematic of the RF-board .......................................... 47
Fig. 2. 15 - The wireless connection - transmitter and receiver .............................................. 48
Fig. 2. 16 - The wireless connection - configuration of the RF-module .................................. 49
Fig. 2. 17 - The wireless connection - radiometrix SP2-433-160 pin package........................ 51
Fig. 2. 18 - The wireless connection - main program .............................................................. 57
Fig. 2. 19 - The wireless connection - transmit algorithm....................................................... 59
Fig. 2. 20 - The sensor nodes - microcontroller DS80C400 .................................................... 66
Fig. 2. 21 - The sensor nodes - microcontroller DS80C400 pin package................................ 67
Fig. 2. 22 - The sensor nodes - microcontroller DS80C400 internal structure....................... 67
Fig. 2. 23 - The sensor nodes - TINI board.............................................................................. 70
Fig. 2. 24 - The sensor nodes - program node 1 ...................................................................... 73
Fig. 2. 25 - The sensor nodes - program node 2 ...................................................................... 76
Fig. 3. 1 - RNG - Elliptic Curve Cryptography........................................................................ 88
6
Fig. 3. 2 - RNG - Geiger counter and radioactive source ....................................................... 92
Fig. 3. 3 - RNG - schematic...................................................................................................... 98
Fig. 3. 4 - RNG - PCB: power supply .................................................................................... 100
Fig. 3. 5 - RNG - PCB: radioactive source and filter ............................................................ 100
7
List of abbreviations
ADC
ALU
API
ASCII
CAN
CISC
CPU
DHCP
ECC
EEPROM
ENDEC PHY
GPRS
GSM
IEEE
IETF
JVM
LAN
MAC
MeV
MII
MIPS
MTK
OPAMP
OS
PC
PCB
RAM
RF
RISC
RNG
ROM
SP
SPI
SRAM
TCP/IP
TINI
UART
WSN
Analogue to Digital Converter
Arithmetic Logic Unit
Application Programmer Interface
American Standard Code for Information Interchange
Controller Area Network
Complex Instruction Set Computer
Central Processing Unit
Dynamic Host Configuration Protocol
Elliptic Curve Cryptography
Electrically Erasable Programmable Read-Only Memory
ENcoder-DECoder PHYsical
General Packet Radio Service
Global System for Mobile communication
Institute of Electrical and Electronics Engineers
Internet Engineering Task Force
Java Virtual Machine
Local Area Network
Media Access Controller
Mega-elektronVolt
Media Independent Interface
Million Instructions Per Second
Microcontroller Tool Kit
Operational Amplifier
Operating System
Program Counter
Printed Circuit Board
Random Access Memory
Radio Frequency
Reduced Instruction Set Computer
Random Number Generator
Read-Only Memory
Stack Pointer
Serial Programming Interface
Static Random Access Memory
Transfer Control Protocol/Internet Protocol
Tiny Internet Interface
Universal Asynchronous Receiver Transmitter
Wireless Sensor Network
8
Part 1
INTRODUCTION
9
Chapter 1
Vaasa Polytechnic and Technobothnia
KHBO Ostend gave us the opportunity to realize our thesis abroad. To do this we went to
Vaasa, Finland. We took lessons at Vaasa Polytechnic during our four-month-stay there. In
the mean while we worked on our thesis project in a laboratory called Technobothnia.
Vaasa Polytechnic is a multi-disciplinary, multilingual and international institution providing
higher education and research services within Technology and Communication, Business
Economics and Tourism as well as Health Care and Social Services. Vaasa Polytechnic has
approximately 3500 students enrolled and a staff of over 240 members.
Fig. 1. 1 - Vaasa Polytechnic
10
Vaasa Polytechnic has approximately 1500 engineering students within the fields of:
•
Mechanical Engineering
•
Civil Engineering
•
Electrical Engineering
•
Information Technology
•
Environmental Technology
The education in the faculty is characterized by principles of sustainable development and
training for the challenges of rapidly changing global markets.
The main building for engineering education of Vaasa Polytechnic was built in 1967, and is
located on the Palosaari seaside campus in Vaasa.
The facilities that were renewed in year 1996-1997 meet both the national and international
quality standards set for providing high-level engineering education.
The Department of Information Technology offers its students a wide variety of courses to
choose from. In addition to three Finnish classes, a group of international students begin their
studies in English every year and another group of Finnish adults make it their goal to study
toward a polytechnic degree during weekends. Vaasa Polytechnic is also an attractive
alternative for students arriving from other countries. Approximately 200 foreign degree and
exchange students pursue studies at Vaasa Polytechnic every year.
The primary goal of the degree programme of Information Technology is to provide students
with knowledge and skills for demanding careers in the industry. The special areas of
competence are for example C, C++, Java and TCP/IP applications, mobile phone systems,
Internet programming and embedded systems.
The laboratories of the Faculty of Technology and Communication are situated in the in the
former factory premises of Vaasa Cotton Ltd, which were renovated and finished in 1996.
This technology research centre is called Technobothnia. The centre, which is utilized by the
faculty, provides the students with a quality and up-to-date study and training environment.
11
Fig. 1. 2 - Technobothnia
The state-of-the-art technology that is needed in engineering education, research and product
development has been concentrated inside about a hectare in area. There is equipment
available in the areas of electrical, mechanical, and construction engineering and
environmental and information technology.
Research and development projects are coordinated and the contracting partners' expertise is
distributed and marketed to the businesses and industries in the region. Consulting services,
services in the development of technical products, product concepts, and production methods
are provided, as well as distribution of expertise in establishing marketing contacts and other
technoeconomic solutions.
The owners of Technobothnia are Vaasa Polytechnic, University of Vaasa, Swedish
Polytechnic and Merinova Ltd.
12
Chapter 2
The global project
This thesis is part of a bigger project. The bigger project is called: ‘Embedded Supervision
System based on a Wireless Sensor Network with Full Redundancy, providing Data
Encryption by an Elliptic Curve Cryptographic System’.
The goal of this project is to create a real useable WSN (wireless sensor network). It focuses
on absolute security, and the ability to send data in numerous ways. Eventually this system
will be commercialized.
Before this global project can be fully explained, the concept of a ‘sensor network’ needs to
be clear. Therefore, a general overview about sensor networks will be given next.
13
2.1
Sensor networks
What is a sensor network?
Obviously, a sensor network consists of a large number of sensors. They can be measuring all
sorts of stuff. Some examples are: temperature, movement, humidity, speed, … The
possibilities are seemingly endless. But how to gather all this data? That is what a sensor
network takes care of.
To do this, sensor nodes were created. Each sensor node gathers the data from some of the
sensors. In a sensor network, usually multiple nodes are used. Every sensor is connected to a
node. This can be done wireless or wired. So all those sensor nodes together cover all the
sensors.
In a ‘classic’ sensor network, the nodes send their data to one central point. This point is often
called the primary node. Sometimes it is called the collector, or the central server. This
‘collector’ also takes care of the connection to the outside world. Mostly this is done by
sending the data to a computer.
There are two possible ways for the nodes to send their data to the primary node. The first
possibility is to send it directly of course. But most of the time, this is not possible. A large
part of the nodes are simply not connected directly to this primary node. In that case, the
sensor node sends its data to another node. And so, the data ‘hops’ from node to node, until it
finally reaches the primary node. Every node can contain two types of data: data coming from
its own sensors, and data that was sent through the sensor network by another node.
Obviously, some kind of routing protocol is required.
More sophisticated sensor networks, are able to adapt themselves to the circumstances. If a
node falls out for some reason, for example an empty battery, the data from this node is lost.
But the data from the other nodes, sending their information to this malfunctioning node
would be lost too. In this case, a large part of the sensor network would become useless.
These more sophisticated sensor networks however, will detect the malfunctioning node, and
14
assign it tasks to another node that is nearby. The sensor network will automatically search
another route to send its data to the primary node. Should the malfunctioning node be
repaired, the shortest route to the primary node will be reinstalled.
Mostly, these more sophisticated sensor networks are wireless. And the number of sensors
and sensor nodes is not fixed. When a node is added, the sensor network will detect this
automatically, and integrate the node. In this way, a dynamical system is created. Sensor and
sensor nodes can be added very easily, without any technical knowledge.
15
2.2
Covering project
The full name of the covering project is “Embedded Supervision System based on a Wireless
Sensor Network with Full Redundancy, providing Data Encryption by an Elliptic Curve
Cryptographic System”.
The project will cover the design and implementation of an advanced embedded supervision
system, which makes use of a wireless sensor network to transport sensor data.
This wireless sensor network will rely on a variety of wireless technologies, such as WLAN,
Bluetooth, GSM/GPRS etc.
TCP/IP for instance will be embedded on the various microcontrollers.
The design allows utilising every conceivable way to transmit data from the supervision
media (the sensors) to the supervisor. These sensors may include for example onboard GPS
system to allocate the position of a moving object, remote capture of still image or live video,
sending GPS co-ordinates and image, video or audio over Internet, but also much simpler
security sensors, such as motion detectors, smoke detectors, door/window position detectors,
etc.
Each sensor node has to be able to function independently from the others, but also have the
ability to communicate with other sensor nodes and a central server.
“Rogue” sensor nodes are inserted which can keep working in the unlikely event the central
server should be compromised and be used to deactivate the sensor nodes.
The central server will be used to monitor the network and make configuration changes. This
server will also provide logging of events, although the sensor nodes will be able to log the
events occurring on their own sensors too.
Also, accessing the server remotely requires a password that is generated by the server, and
that changes in time. It is sent to the mobile phone of the owner every time a new one is
generated. Of course this happens encrypted, and the mobile phone of the user, in this case,
has to be equipped with extra software (Java).
However, the server is not a central or essential part of the supervision system and can be left
out if desired, depending on the needs and demands of the customer.
16
Additionally, all communication between the different parts of the sensor network will be
encrypted using a public key encryption scheme, based on an elliptic curve cryptographic
system. Specifically, an algorithm from the Optimal Extension Fields (OEFs), a special case
of GF(p^m) with p=(2^n)+/-c with c being an arbitrary positive rational number (log2c = n/2)
and with p being one prime less than the maximum word-size used by the embedded micro
controllers. Also, with this type of GF(p^m), m is chosen in such a way that P(x) = x^m –w is
an irreducible binomial.
The picture below illustrates this project.
Fig. 1. 3 - The global project
17
2.3
Different aspects of the project
2.3.1
The sensors
The goal of the sensors is of course to monitor certain events in certain locations. The kind of
event that is monitored depends on the kind of sensor that is used. The location is simply
dependant on where the sensor was dropped.
The possibilities are almost infinite. Thousands of sensors exist.
The most simple sensors possible here are the simple digital sensors. They only have two
possible outputs. They are either triggered, or they are not. Some examples: a motion detector,
a smoke detector, a door/window position detector, …
More complex digital sensors are possible too. Their output is significantly more complex
than just a digital high or digital low, as was the case with the simple digital sensors. Also,
their output indicates more than just triggered or not triggered. It gives more information
about the situation near the sensor (for example the output of a digital thermometer does not
only indicate the temperature has gone too high, it also indicates how high the temperature
actually was). These more complex digital sensors may include digital thermometers, digital
cameras, …
And of course analogue sensors are a possibility too. When they are used in a sensor network,
ADC (analogue to digital conversion) is needed, because the wireless connection, the sensor
nodes and the central server are only able to process digital data. Some examples: an analogue
speed indicator, an analogue thermometer, …
All these sensors can be integrated in the sensor network, but because this project focuses on
security, it is most likely to contain only security-related sensors. So an analogue speed
indicator for example, is not likely to be found in this sensor network. Motion detectors on the
other hand, will almost always be a part of the repertoire.
18
Because this project is meant to be absolutely wireless, the connection between sensors and
sensor nodes should be wireless too. Therefore, every sensor needs to be equipped with at
least wireless transmitter, in some cases even a wireless transceiver (transmitter and receiver).
When this product is commercialized, it will have its own, specially designed sensors.
2.3.2
The sensor nodes
The sensor nodes will gather the information from the sensors. All data traffic between the
nodes and the sensors will happen wireless. Also, all communication between the sensor
nodes should happen wireless.
A node should be able to detect the number of sensors and sensor nodes within reach. It will
automatically adapt to the situation. If a sensor is added for example, the node will
automatically integrate it into the sensor network. To do this, some kind of protocol must
exist of course. A sensor should only be communicating with one sensor node. If a sensor
node is added, the other nodes should detect it, and respond to it. The new node could for
example get some sensors under its control, that previously belonged to another node, but are
now closer to the new node. Also, from that moment on, the network can route data through
that node too.
This makes the system extremely dynamical.
Every node will be able to log the events of its own sensor, using a flash memory. If the
central server is out of use, for some reason, the individual nodes can still log the events, and
then send the data to the central server, once it is back online.
Also, every node should be able to become a ‘rogue node’, but this will be discussed later on,
along with the other security issues.
2.3.3
The central server
The central server will provide a user interface. The user will be able to monitor the sensor
network using it. To make this possible, all sensor nodes need to send their data to this central
19
server of course. The server will be able to warn the user of a certain event in numerous ways.
It can for example send a sms to the user, or call him on his cell phone. It could also send an
image using email.
Another task of this central server will be the logging of events that occurred throughout the
sensor network. All events that occurred will be stored in a memory.
Finally, through this central server, the user will be able to control the network to some
extend. Not completely, because of the ‘rogue nodes’, but this will be covered later on.
2.3.4
Security
This project wants to provide absolute security. Therefore, some extra security measures will
be installed.
As was mentioned before, the system will be able to use a wide variety of communication
means. For example GPRS, GSM, the internet, … If someone is able to block one of them, or
one of them simply fails, the system can still use the others.
Another security measure is of course encryption. All data traffic will happen encrypted. This
encryption will happen using a public key encryption scheme, based on an elliptic curve
cryptographic system. More information on this can be found later on in this thesis.
The sensor network will use ‘rogue nodes’. They are a unique concept, designed to provide
even more security. The rogue sensor nodes are inserted because they can keep working in the
unlikely event the central server should be compromised and be used to deactivate the sensor
nodes. They are normal nodes, chosen at random (they can be different nodes after some
time). When a node is chosen ‘rogue’, it can no longer be shut down by the central server.
The central server will actually be unable to perceive the node. The rogue node will always
send its data via other nodes. When the central server is used to shut down the sensor nodes,
the rogue node will be shut down too, according to the central server at least. But actually, it
will never seize to function. The technology concerning these ‘rogue nodes’ is still under
development.
20
2.4
Practical use
The most obvious application for this system is of course a security system. It can be used to
ensure security in a building or an area. Using this system, the covered area can easily be
monitored. Also, the system can warn the user by itself, in case of a security breach. It is
almost impossible for an intruder to bypass the system. It can use so many different
technologies to communicate, its data is encrypted using one of the most modern encryption
methods and it has a new security measure that is yet unheard of: the ‘rogue nodes’. The
combination of these elements takes care of almost any intruder.
A second application for this system can be found in so-called remote nursing. The idea is to
provide a real-time continuous monitoring of a patients physical condition. Of course the
types of sensors used in this case are not the same as the types of sensors used in the security
system. Possibilities are measurements of the heartbeat, blood oxygen saturation, ECG, …
Of course security is a major issue here, and for more then one reason. There are two major
issues here which require absolute security. The first one is about security of information.
Medical files are supposed to be private, so a good encryption method is required. The second
one is about security of the system. The system has to hold under ‘stress’. If for some reason
the Ethernet connection is failing, it cannot cause the whole sensor network to fail. That
would be unacceptable. But this system uses different technologies to communicate. If for
example the Ethernet is failing, it can always use GPRS.
The medical personnel wants to use the system in case of large accidents and fires, where the
number of patients is very high, and for monitoring elderly, long term patients.
Obviously there are a lot more possible applications. Like monitoring a conservatory for
example, with sensors that check temperature, humidity, amount of oxygen,… But the main
purposes of the project are described above. It was designed with these purposes in mind.
21
Chapter 3
Participation and requirements
The project that was described before, is of course huge. Before this project is fully realized,
numerous steps will be taken in between. Every phase will have its own purpose and
requirements. In every new phase, new elements will be integrated, until finally, the project is
ready. And then, the commercialization process begins.
This thesis covers one phase in the entire project. More specific, it covers the first one. This
first phase in the project consisted of two parts: a testing application, as a first step towards
the wireless sensor network, and a true random number generator. The purpose and
requirements of both parts will be explained.
The first part was a testing application. This is actually a first version of the wireless sensor
network. Of course it is not that complex as the final version will be. It is only the first design.
This means that it doesn’t have all the possibilities the final version will have. Only the basic
functions are integrated.
These were the requirements for the testing application:
•
Reading the output of a small amount of simple digital sensors. ‘Simple digital
sensors’ means that the output can only have two different states. Triggered or not
triggered. Nothing more.
22
•
Transporting the sensor data using a wireless unidirectional point-to-point connection.
To create this connection, RF-modules using the free radio band have to be used.
•
Communication over the internet between two nodes, using TCP/IP. One node simply
needs to send the sensor data to the other node.
•
Providing a way to check if the last node received the sensor data correctly. If
possible, with a user interface that doesn’t require any technical knowledge about the
project.
The second part was a true random number generator. Why does this project need a random
number generator? The reason can be found in the encryption part. The public key encryption
method needs true random numbers. Because the encryption algorithm is under construction,
even almost finished, it will probably be integrated in the next phase of the project. But,
before it can be integrated, a random number generator is needed of course. It is possible to
use ‘random seeds’, but they are only ‘pseudo random’. To ensure absolute security, a true
random number generator is needed.
This part of the project only had one requirement:
•
Create a random number generator that delivers true random numbers. The design has
to be based on the random alfa-particle emission of a small radio-active source.
Both parts will be discussed individually now. Afterwards, a conclusion will be made. In this
conclusion, the success of this thesis will be discussed. Do the practical designs meet all the
requirements?
23
Part 2
THE TESTING APPLICATION
24
Chapter 1
The entire design
According to the requirements defined for this part of the project, a practical design was
proposed. The design can be seen on the picture below.
Fig. 2. 1 - The entire design - testing application
25
This theoretical design meets all the requirements. It will be explained part by part. The
different functional parts are:
•
The sensors
•
The wireless unidirectional point-to-point connection
•
The sensor nodes
The part called ‘the sensors’ is about gathering data from multiple simple digital sensors, and
combing that data into a single serial datastream.
‘The wireless unidirectional point-to-point connection’ covers the wireless part of the design.
The purpose here is to send the serial datastream from the previous part (the sensors) to the
next part (the sensor nodes).
The last part: ‘the sensor nodes’, covers the transport of the data over the internet, using
TCP/IP. Also, publishing the data on a website is included in this part.
The practical details about these three parts will be discussed in the following pages. To do
this, the same method will be used each time:
•
First, the goals of each functional block will be examined.
•
Then, the hardware that was used will be examined. Also, the reasons why this
particular hardware was chosen will be discussed.
•
Next, the software algorithms and flow charts that were used to program the
microcontrollers will be explained.
•
Then, a small illustration about the testing of the functional blocks will be given.
•
Finally, the changes that these functional blocks will go through in the future will be
discussed.
When this is done for all three of the functional blocks, a conclusion will be made. Does the
practical design meet the original requirements? If not, what went wrong? Doing so should
give a clear image of this part of the thesis.
26
Chapter 2
The sensors
2.1
Goal
The goal of the sensors is of course to give an indication that a certain event occured in a
certain location. A motion detector for example could indicate that someone moved through a
certain room. Of course there are hundreds of possible sensors available. It is impossible to
summarize them all.
In the test application, only a couple of them are used. The ones that are used are simple
digital sensors. This means that that their output is simple. When the sensor is triggered, the
digital output level changes from 1 to 0, or vice versa.
The sensors used in the test application are: a motion detector and a door/window position
indicator. The motion detector is triggered when something moves in front of it. The
door/window position detector is triggered when the door or window it is attached to is
opened.
The test application also uses four buttons. They are simulating real digital sensors.
27
2.2
Hardware
2.2.1
Two types of sensors
This test application uses two kinds of sensors. The first kind is the buttons. They just
simulate real digital sensors. Buttons were chosen, because it is really easy to run tests with
them.
The second kind are the real sensors: a motion detector and a door/window position detector.
These sensors were chosen, because they are simple digital sensors. There are only two
possible situations, the sensor is triggered, or not. This is exactly what their output reflects.
Digital zero and one each indicate one of these possible states.
Fig. 2. 2 - The sensors - door/window position detector and motion detector
These two sensors are already integrated into an existing security system. They communicate
with a central control center. This doesn’t matter, because it is possible to access the data
from the sensors directly and unchanged. The test application does not interfere with the
existing security system, both systems are compatible
.
Fig. 2. 3 - The sensors - central control center
28
2.2.2
The sensor center
To fully understand how the test application works, one must first understand the existing
security system. This is necessary, because the data from the sensors, which are integrated
into this system, needs to be accessed.
Fig. 2. 4 - The sensors - existing security system and accessing its data
The existing security system (the parts of it that are used in the test application) consists of
two sensors and a central control unit. This central control unit is actually the user interface.
The user of the security system is able to control the system using this device.
The two sensors, the motion detector and the door/window position detector are connected to
the central control unit using radio frequencies, so they are wireless. They continuously send
updates on their status to the central control unit.
29
The central control unit can process this data. It can decide to sound the alarm, to ring your
phone (or mobile phone) and to connect to other security devices using the X10 protocol. This
X10 is a standard for PLC or power line communication. It is basically using the power lines
to send and receive data, thus to communicate with other devices. A bit more into detail about
X10.
X10 Standards
X10 is the dominant protocol for controlling (turning on/off and dimming)
electrical devices, such as lights and appliances, through your home's electrical lines.
X10 is now an open standard. All standards-compatible products display an X10compatible logo on their packaging or on the product itself. When you see this logo,
you know that the product works with other X10 products regardless of the
manufacturer.
To work in a home, X10 doesn't require specific network architecture other than
your existing electrical system. X10 sends its control signals from the controller over
your power lines to every outlet in the house. The controller can have remote control
or PC interfaces.
X10 networking has been around for about 20 years. Pico Electronics of
Scotland developed X10 as a home automation system and the first products were
shipped in 1978. Since then, the original patent has expired and prices for X10compatible devices have dropped sharply.
X10 technology is pretty interesting and relatively simple. It transmits signals
over electrical power lines by inserting 120-KHz signal bursts, each 1 msec long, at
the zero crossing of the voltage on a 60Hz 120V circuit. Each bit transmitted consists
of two bursts; so a binary one is represented by a burst followed by a no-burst while a
zero is a no-burst followed by a burst.
30
Obviously for this encoding to work, the bursts have to be framed. X10 uses a
preamble or start code to indicate a packet start. This start code is the sequence
"burst, burst, burst, no burst" - a combination that is unique because the first two
bursts are neither a zero nor a one. Requiring the double burst to be followed by a
binary one (burst, no burst) reduces the likelihood of a noisy system creating a
spurious false start code.
Following the start code is the data. Being designed for home automation, the
next four bits are the "house code" (which defines 16 groups of devices denoted "A"
through "P") followed by a five-bit device code (16 devices - the least-significant bit of
the code is zero) or function code (16 codes - the least-significant bit is one). How
devices interpret these codes is implementation dependent ("dim" would be
meaningful to a light controller but useless to a device switching a relay on or off).
So what's the data rate? Well, because the bursts are transmitted at the zero
crossings of the voltage cycle, one cycle is required for each bit, or a total of 13 cycles
to transmit one X10 packet of 13 bits (four bits for the preamble and nine bits for the
payload). In addition, each command is sent twice for reliability (power-line
transmission is a notoriously noisy environment) and we have to insert a three-cycle
delay after each pair of commands. For some strange reason, the function codes
"bright" and "dim" (01011 and 01001, respectively) don't require the three-cycle
delay.
Thus for 9 data bits we need 29 cycles, which works out to a data rate of 18.62
bit/sec except for the two exception codes that only need 26 bits so we can hit the
maximum of 20.77 bit/sec.
What can we do with this system? Well, there's a ton of controllers and devices
available. For example, we can interface a computer using the IBM Home Director
Kit, and install X10 light switches, so we can automatically dim the computer room
lights in the evening. Adding a X10 PIR motion detector makes it possible to
31
automatically switch on the lights when someone enters the room. There are also all
sorts of other X10 devices available for controlling high-power devices, amplifying
signals, bridging X10 signals across power-phase legs and analyzing X10 signaling.
But what about the security center? It is indeed an American security system. So
it uses a 60Hz 120V circuit. This makes it possible to use X10 to communicate with
other devices. The security center can for example communicate with an alarm
module somewhere in the house.
Remark :
We had to make or own 60Hz 120V circuit, because the normal
electrical net in Europe uses 50Hz 230V
All those things are possible, but they are not actually part of the test application. They are a
part of the already existing security system. The question is, how to access the data from the
sensors, so it can be processed further using the test application.
As the figure above shows, the data was accessed using a serial port (RS-232). This port was
wired directly to the data bus of the central control unit. Although a serial port was used, this
way of accessing the data does not use a serial configuration. The nine wires of the serial
cable are used to transport parallel data. One pin was used for the ground. The other eight pins
of the serial connector were each wired to one sensor output. Doing so, it is possible to
monitor eight simple digital sensors simultaneously, although only two were used. What was
actually done here, was making a hardware copy of the data, enabling the test application to
use the data, but also enabling the central control unit to use the data for further processing.
2.2.3
The sensor board
The design now has data from the sensor center present. The design also has data from the
buttons present. Now this data needs to be combined, and transformed into serial data.
32
The reason for this can be found within the RF-boards, the hardware that takes care of the
wireless communication in this test application. These RF-boards get their data from a serial
port. Therefore, we need to transform the data from the sensors into serial data. Why exactly
these RF-boards were designed with serial ports will be explained later on.
Fig. 2. 5 - The sensors - sensor board schematic
This figure shows how the problem was solved. The Atmel AT90S2313 microcontroller
collects the data from the sensors on its ports. Then it processes the data, in order to make it
suitable for serial communication. Finally the data is send to the RF-board through a serial
cable.
In order to be able to perform all the tasks that were mentioned earlier, more then just a
microcontroller is needed of course. A board is needed.
33
Fig. 2. 6 - The sensors - sensor board
To perform these tasks, a PCB with an Atmel microcontroller, two serial ports (we added one)
and four buttons was used. The picture above shows the PCB that was used. The huge white
component is some sort of socket, that allows to connect more devices (sensors) to this board.
2.2.4
The AT90S2313 microcontroller
General
The AT90S2313 is a low-power CMOS 8-bit microcontroller based on the AVR RISC
architecture. By executing powerful instructions in a single clock cycle, the AT90S2313
achieves to process 1 MIPS per MHz.
The AVR core combines a rich instruction set with 32 general purpose working registers.
All the 32 registers are directly connected to the Arithmetic Logic Unit (ALU), allowing
two independent registers to be accessed in one single instruction executed in one clock
cycle. This architecture is more code efficient and results in a better performance. The
processing speed is up to ten times faster than conventional CISC microcontrollers.
34
The AT90S2313 provides the following features:
•
2 kB Flash program memory which can be programmed at least 1000 times
•
128 bytes of SRAM data memory
•
128 bytes of EEPROM memory (non-volatile data memory) which can be written
to at least 100 000 times
•
one 8 bit timer/counter
•
one 16 bit timer/counter (includes compare, capture and PWM modes)
•
programmable Watchdog Timer with internal Oscillator
•
SPI serial interface, used for programming the chip
•
programmable serial UART
•
internal and external interrupts
•
15 general purpose I/O lines
•
32 general purpose working registers
•
selectable power-saving modes
The Idle mode stops the CPU while allowing the SRAM, Timer/Counters, SPI port and
interrupt system to continue functioning. The Power-down mode saves the register contents
but freezes the Oscillator, disabling all other chip functions until the next external interrupt or
Hardware Reset.
The device is manufactured using Atmel’s high-density non-volatile memory technology.
The On-chip In-System Programmable Flash allows the Program memory to be
reprogrammed in-system through an SPI serial interface or by a conventional non-volatile
memory programmer. The Atmel AT90S2313 is a powerful microcontroller that provides a
highly flexible and cost-effective solution to many embedded control applications.
The AT90S2313 AVR is supported with a full suite of program and system development
tools including: C compilers, macro assemblers, program debugger/simulators, In-Circuit
Emulators and evaluation kits.
35
Below you can see the scheme of the AT90S2313 microcontrollers pin description.
Fig. 2. 7 - The sensors - microcontroller AT90S2313 pin package
Functional description
The fast-access Register File concept contains 32 x 8-bit general purpose working registers
with a single clock cycle access time. This means that during one single clock cycle, one ALU
operation is executed. Two operands are output from the Register File, the operation is
executed, and the result is stored back in the Register File. This happens all in only one clock
cycle.
Six of the 32 registers can be used as three 16-bit indirect address register pointers for Data
Space addressing. This enables efficient address calculations.
The ALU supports arithmetic and logic functions between registers or between a constant
and a register. Single register operations are also executed in the ALU.
36
The figure below shows the AT90S2313 AVR RISC microcontroller architecture.
Fig. 2. 8 - The sensors - microcontroller AT90S2313 architecture
In addition to the register operation, the conventional memory addressing modes can be used
on the Register File as well. This is enabled by the fact that the Register File is assigned the
32 lowermost Data Space addresses, allowing them to be accessed as though they were
ordinary memory locations.
The I/O memory space contains 64 addresses for CPU peripheral functions such as control
registers, Timer/Counters, A/D converters and other I/O functions. The I/O memory can be
accessed directly or as the Data Space locations following those of the Register File.
The AVR has a Harvard architecture. This means it has separate memories and buses for
program and data. The program memory is accessed with a 2-stage pipeline. While one
instruction is being executed, the next instruction is pre-fetched from the program memory.
This concept enables instructions to be executed in every clock cycle. The program memory
is In-System Programmable Flash memory.
37
With the relative jump and call instructions, the whole 1K address space is directly accessed.
Most AVR instructions have a single 16-bit word format. Every program memory address
contains a 16- or 32-bit instruction.
During interrupts and subroutine calls, the return address Program Counter (PC) is stored on
the Stack. The Stack is effectively allocated in the general data SRAM, and consequently the
stack size is only limited by the total SRAM size and the usage of the SRAM. All user
programs must initialize the SP in the reset routine (before subroutines or interrupts are
executed). The 8-bit Stack Pointer (SP) is read/write accessible in the I/O space.
The 128 bytes data SRAM + Register File and I/O Registers can be easily accessed through
the five different addressing modes supported in the AVR architecture. The memory spaces in
the AVR architecture are all linear and regular memory maps.
Fig. 2. 9 - The sensors - microcontroller AT90S2313 memory map
A flexible interrupt module has its control registers in the I/O space with an additional Global
Interrupt Enable bit in the Status Register. All the different interrupts have a separate Interrupt
Vector in the Interrupt Vector table at the beginning of the program memory. The different
interrupts have priority in accordance with their Interrupt Vector position. The lower the
Interrupt Vector address, the higher the priority.
38
Loading
In order to make the sensor board work, a program needs to be loaded into the Atmel
AT90S2313 microcontroller. Programming this microcontroller is done using a special cable.
Fig. 2. 10 - The sensors - programming an AT90S2313: the cable
One end of the cable is connected to a computer using the parallel port. The other end is
connected to the microcontroller. The microcontroller has a special port for this. This can be
seen on the picture below.
39
Fig. 2. 11 - The sensors - programming an AT90S2313: the programming interface
To create the program, and transfer it into a HEX-file the WinAVR program was used.
WinAVR is a suite of executable, open source software development tools for the Atmel
AVR series of RISC (reduced instruction set computer) microprocessors, hosted on the GNU
GCC compiler for C and C++.
To actually load the program, created in WinAVR, into the microcontroller, PonyProg2000
was used. This is a device programmer, capable of programming lots of microcontrollers, one
of them being the Atmel AT90S2313.
40
2.3
The software
Now a bit more into detail about the program itself. The figure below shows a basic diagram
of how the program works. This is of course not the real code. The real software was written
in C-code, and can be found on the CD-rom.
Fig. 2. 12 - The sensors - sensor board program
The program listens on the ports of the Atmel AT90S2313 microcontroller. These ports are
connected to the sensors. When an event occurs on these ports, being a sensor that is
triggered, the microcontroller will send a datastring through the serial port, that corresponds
to which sensor has been triggered.
This means that it will only send in the event that a sensor has been triggered. So, when a
sensor is triggered, a datastring containing information about what sensor was triggered will
be available on the serial port of the RF-board.
Whenever data is send through the serial port, a baud rate of 9600 is used. This baud rate is
used almost throughout the whole project. It is a bit slow, but it is more then enough for a
testing application. Also, the RF boards, which will be explained later on, proved not being
capable of using a higher baud rate. This is not a problem, because when the system will be
commercialized, it will no longer use RF-modules anyway (it will probably use wireless
LAN).
41
2.4
Testing
Making the whole test application and then hope it will work is of course a very
unprofessional way of working. Also the chance on success is very small.
That is why it is necessary to divide the project in to smaller functional parts, and then test
those first one by one, before assembling them all and testing the entire design.
The sensors and the Atmel microcontroller together make one of those ‘functional’ blocks
that were tested separately, before testing the whole application.
To test this functional block, it has been connected to a computer using a serial cable. The
tool to do the actual testing was Windows Hyperterminal. By trying to communicate with the
functional block using this tool, it was possible to verify its functioning. The buttons were
triggered. Then, by checking if the data the Hyperterminal received, corresponded to which
sensor (being the button pressed in the first place) was triggered, it was possible to test this
part of the design.
42
2.5
The future
This is of course only the design for the test application. In the future this project is meant to
produce a commercial and really useable product. So what will be different, for this sensor
part?
Obviously, there will only be real sensors. The buttons used here are only for testing. In the
future they will be replaced by real sensors.
Also there will be more sensors used. And not only the simple digital ones. More complex
digital sensors will also be used later on. A digital camera for example. Even a small amount
of analogue sensors will be included.
The number of possible sensors that are available is infinite. This part of the project can
expanded as much as wanted.
43
Chapter 3
The unidirectional point-to-point wireless
connection
3.1
Goal
This is supposed to be a wireless sensor network. So, a wireless part is needed in this project.
As is mentioned in the sensor chapter, this wireless part consists of two RF-boards.
What exactly is the goal of this wireless part? Well, from the previous part is known that a
datastring, containing information about which sensor was triggered, is present on the serial
port of one of the RF-boards. Also known is that this datastring needs to be accessed by the
sensor node. So the goal of this wireless part is simply to read the information on the serial
port, transport it wirelessly and then make it available again on a serial port, enabling the
sensor node to access it.
The connection is called unidirectional, because the data only travels in one direction, from
the sensors to the sensor node.
The connection is called point-to-point, because it only uses one transmitter, and one receiver.
The sensors are connected to the transmitter, and the sensor node to the receiver.
44
And finally, the connection is called wireless, because it uses the air interface and radio
frequencies to transport its data.
Basically, this wireless part is just about transporting data from one point to another.
45
3.2
The hardware
3.2.1
The RF-board
This wireless connection needs one transmitter and one receiver. PCB boards that could
perform the requested tasks needed to be designed. These boards are called RF-boards.
The hardware for both the transmitter and the receiver is identical, only the software defines
the function.
Fig. 2. 13 - The wireless connection - RF-board
46
Fig. 2. 14 - The wireless connection - schematic of the RF-board
The figure above shows the schematic for the PCB design. The main components of the
design are: a serial port, an Atmel AT90S2313 microcontroller and a RF-module
(Radiometrix SP2-433-160). The microcontroller is the same type that was used in the sensor
board. In the previous chapter, this microcontroller has already been explained.
This RF-module is a component that contains equipment and protocols for packet-based
sending and receiving of data. To make sure that this wireless communication would not
interfere with the wireless communication of the existing security system, another frequency
47
needed to be chosen. This frequency is 433 MHz. It is located in the free radio band. This
means that anyone can freely use these frequencies, without any cost.
Fig. 2. 15 - The wireless connection - transmitter and receiver
The procedure is as follows: the transmitter-board receives data on its serial port. The data is
then send through the UART to the microcontroller and is then processed by the
microcontroller, in order to make it suitable for wireless communication. After the
handshaking, the data is send by the RF-module.
The receiver-board receives the information on its RF-module. The data is then processed by
the microcontroller, in order to make it suitable for serial communication. Then, finally the
data is send through the UART to the serial port.
So, after this procedure, data about which sensor was triggered is available on the serial port
of the sensor node.
Sending data with the SP2-433-160 RF-module, means feeding it parallel data. The RFmodule has four parallel data ports. It will send four bits (= one nibble) at once.
If the RF-module works on a parallel basis, why was a serial port used in the design of the
RF-board? The reason for this oddity can be found within the sensor node. The sensor node in
this test application uses the TINI board. This board only has serial ports. No parallel ones.
48
Of course there is always the possibility of soldering some wires and ‘creating’ a parallel port.
But in this case the more elegant solution was chosen.
The reason why the TINI board was chosen to function as a sensor node, and not some other
board that does have a parallel port, will be explained later on.
3.2.2
The Radiometrix SP2-433-160
General
The SP2-433-160 is a transceiver module, which enables a radio network/link to be simply
implemented between a number of digital devices. The SP2 is a self-contained plug-on radio
port which requires only a simple antenna, 5V supply and a byte-wide I/O port on a host
microcontroller. The module provides all the RF circuits and processor intensive low level
packet formatting and packet recovery functions required to inter-connect a number of
microcontrollers in a radio network. A data packet of 1 to 60 bytes downloaded by a Host
microcontroller into the SP2's packet buffer is transmitted by the SP2’s transceiver and will
"appear" in the receive buffer of all the SP2's within radio range. A data packet received by
the SP2’s transceiver is decoded, stored in a packet buffer and the Host microcontroller is
signalled that a valid packet is waiting to be uploaded.
transmit / receive
download
HOST
download
SP2
SP2
upload
HOST
upload
Fig. 2. 16 - The wireless connection - configuration of the RF-module
49
Functional description
On receipt of a packet downloaded by the Host, the SP2 will append to a preamble, start byte
and error check code. When not in transmit mode, the SP2 continuously searches the radio
noise for valid preamble. On detection of a preamble, the SP2 synchronises to the incoming
data stream, decodes the data and validates the check sum. The Host is then signalled that a
valid packet is waiting to be uploaded. The format of the packet is entirely of the users
determination except the first byte (the Control Byte) which must specify the packet type
(control or data) and the packet size. A valid received packet is presented back to the host in
exactly the same form as it was given. More commentary can be found further in the
explanation of the host and transceiver interface.
To preserve versatility, the SP2 does not generate routing information (i.e. source/ destination
addresses) nor does it handshake packets. These network specific functions should be
performed by the host.
The SP2 has four normal operating states:
• IDLE / SLEEP
The IDLE state is the quiescent state of the SP2. In IDLE the SP2 enables the receiver and
continuously searches the radio noise for message preamble. If the power saving modes have
been enabled the SP2 will pulse the receiver on, check for preamble and go back to SLEEP if
nothing is found. The 'ON' time is 2.5ms, OFF time is programmable in the SP2’s EEPROM
and can vary between 22ms and 181ms. The TX Request line from the Host is constantly
monitored and will be acted upon if found active (low). A TX Request will immediately wake
the SP2 up from SLEEP mode.
• HOST TRANSFER
If the host sets the TX Request line low a data transfer from the Host to the SP2 will be
initiated. Similarly the SP2 will pull RX Request low when it requires to transfer data to the
Host. The transfer protocol is fully asynchronous. It is desirable that all transfers are
completed quickly since the radio transceiver is disabled until the Host <> SP2 transfer is
completed. Typically a fast host can transfer a 60 byte packet to/from the SP2 in under 1ms.
50
• TRANSMIT
On receipt of a data packet from the host, the SP2 will append to the packet - preamble, frame
sync byte and an error check sum. A full 60 byte packet is transmitted in 6ms of TX air time.
Collision avoidance functions can be enabled to prevent loss of packets. Data packets may be
sent with either normal or extended preamble. Extended preamble is used if the remote SP2 is
in power save mode. Extended preamble length can be changed in the EEPROM memory.
• RECEIVE
On detection of preamble from the radio receiver, the SP2 will phase lock, decode and error
check the incoming synchronous data stream. The data is then placed in a buffer and the RX
Request line is pulled low to signal to the host that a valid packet awaits to be uploaded to the
Host. An in-coming data packet is presented back to the host in the same form as it was given.
Host interface
On the figure below you can see the package of the radiometrix SP2-433-160. Next the
explanation of the interface between the host and the radio-module will be given.
Fig. 2. 17 - The wireless connection - radiometrix SP2-433-160 pin package
Data is transferred between the SP2 and the HOST 4 bits (nibbles) at a time using a fully
asynchronous protocol. The nibbles are always sent in pairs to form a byte, the Least
Significant Nibble (bits 0 to 3) is transferred first, followed by the Most Significant Nibble
51
(bits 4 to 7). Two pairs of handshake lines, REQUEST and ACCEPT, control the flow of data
in each direction:
•
TX Request and TX Accept to control the flow from the HOST to the SP2 (download)
•
RX Request and RX Accept to control the flow from the SP2 to the HOST (upload)
So, there are 4 handshaking pins:
Pin name
Pin function
I/O
Pin description
TXR
TX Request
input
Data transfer request from HOST to SP2
TXA
TX Accept
output
Data accept handshake back to HOST
RXR
RX Request
output
Data transfer request from SP2 to HOST
RXA
RX Accept
input
Data accept handshake back to SP2
The handshaking pins are active low.
A packet transferred between host and SP2 consists of between 1 and 61 bytes, the first byte
of the packet is always the control byte. There are two classes of transfers between the Host
and the SP2.
There are the Data Packets. This is the transmission of data from the microcontroller to the
transmitter and opposite from the receiver to the microcontroller.
Also there is the Memory Access. This is the traffic of information to or from the SP2's
memory.
The 4 data lines:
Pin name
Pin function
I/O
Pin description
D0
Data 0
Bi-dir
4 bit bi-directional data bus. Tri-state
D1
Data 1
Bi-dir
between packet transfers, Driven on
D2
Data 2
Bi-dir
receipt for Accept signal until packet
D3
Data 3
Bi-dir
transfer is complete.
The Reset signal, may either be driven by the host (recommended) or pulled up to Vcc via a
suitable resistor (10kΩ). A reset aborts any transfers in progress and restarts the Packet
Controller.
52
The logic levels of these lines are 5V CMOS.
Transceiver interface
The interface between different radio modules.
The SP2 interfaces to the transceiver using 4 lines. All lines are 5V CMOS level:
Pin name
Pin function
I/O
Pin description
TX
Transmit enable
output
Active low enable for the transmitter
TXD
Transmit data
output
Serial data to be sent
RX
Receive enable
output
Active low enable for the receiver
RXD
Receive data
input
Received serial data
The enable lines, TX and RX, are normally high, active low lines are used to control the
transceiver. The SP2 is a half-duplex controller thus in normal operation the transceiver is
either transmitting or receiving or off.
Transmit Data, TXD, is the serial data to the transmitter, it is held low when the transmitter is
not enabled. When the TX is enabled a synchronous 160kbit/s (6.25μs/bit) serial code is
present to modulate the transmitter.
Receive Data, RXD, is a high-impedance input which is fed with a 'squared-up' (5V logic
level) signal from the receivers' data slicer. The SP2 contains a very selective, noise immune
signal detector and therefore does not require that the RXD signal be muted in the absence of
signal.
The SP2 contains both a packet encoder and a packet decoder. When sending data from the
transmitter to the receiver, a packet is made by the packet encoder.
The packet is made-up of 4 parts:
53
• PREAMBLE
This is a simple 80kHz square wave. The preamble has two functions. First of all, to allow the
data slicer in a remote receiver to establish the correct slicing point. Secondly, to positively
identify and phase lock onto the incoming signal. The preamble may extended to wake-up a
remote SP2 in power saving mode.
• FRAME SYNC
A 7 bit Barker sequence is used to identify the start of the data. Alternatively if the transmitter
is sending extended preamble (to wake a power saving remote SP2) a complimented 7 bit
Barker sequence is sent every 256 preamble cycles as a 'Please Hold The Line' code. An 8th
balancing bit is added after the Barker sequence.
• DATA
Each byte in the SP2's buffer is expanded into a 12 bit symbol prior to sending. The symbol
coding has the following properties:
-
Perfect 50% balance, always 6 one's and 6 zero's.
-
There are never more than 4 consecutive one's or zero's. This minimises the low
frequency components in the code and allows fast settling times to be used for the
receivers' data slicer.
-
Minimum Hamming distance = 2. Each code is different from any other code by a
minimum of 2 bits, thus all odd number of bit errors will always be detected.
-
In general only 256 of 4096 (6.25%) possible codes are valid, this means 93.75 %
probability of trapping a byte error.
-
Preamble and the Frame sync codes are not part of the symbol alphabet, a 'clash'
signal will cause immediate termination of the current decode followed by an attempt
to lock to the new signal.
• CHECK SUM
Since the receiver checks each symbol for integrity, a simple 8 bit check sum is used to test
for overall packet integrity. This is also coded into a 12 bit symbol prior to transmission.
54
At the receiver side. The packet has to be found and then decoded. The signal decoding is in 4
stages:
• SEARCH
Initially the SP2's decoder searches the radio noise on the RXD line for the 80kHz preamble
signal. The search is performed by a 16 times over-sampling detector which computes the
spectral level of 80kHz in 192 samples of the RXD signal. If the level exceeds a pre-set
threshold the decoder will attempt to decode a packet.
• LOCK-IN
The same set of 192 samples are used to compute the phase of the incoming preamble and
synchronise the internal recovery clock to an accuracy of +/- 2μs. The recovery clock samples
the mid point of each incoming data bit and shifts the samples trough an 8 bit serial
comparator. The comparator searches the data on a bit by bit basis for the frame sync byte.
While the search is in progress, the decode will abort if the preamble fails to maintain a
certain level of integrity. If the comparator finds the 'please hold the line' code used during
extended wake-up preamble a phase re-lock is triggered to ensure accurate phase tracking
until the actual packet arrives. When the frame sync is detected the decoder attains full
synchronisation and will move to the Decode state.
• DECODE
Data is now taken in 12 bits at a time (one symbol), decoded into the original byte and placed
in the receive buffer. The symbol decoder verifies each received symbol as valid (only 256
out of a possible 4096 are valid) and will immediately abort the decode on a symbol failure.
The first byte contains the byte count and is used to determine the end of message.
• CHECK SUM
The last byte is the received check sum, this is verified against a locally generated sum of all
the received bytes in the packet. If it matches the packet is valid and RXR line will be pulled
low to inform the Host that a packet awaits uploading.
55
3.3
The software
As was already mentioned before, both of the RF-boards are identical. So the difference
between transmitter and receiver is entirely made using software.
The software needs to be loaded into the Atmel AT90S2313 microcontroller. This board was
design in such a way that it is possible to load the program using a serial cable. So, unlike the
sensor board, no extra ports were added on this board.
To create the programs, and transfer them in to HEX-files, WinAVR was used.
PonyProg2000 was used to actually load the HEX-files into the microcontroller. So, the
programs used for the programming were actually the same as those for the sensor board, only
the hardware for loading them was different.
The figure below shows the basic functioning of the program. The actual program was written
in a combination of C and assembler. It can be found on the CD-rom.
56
Fig. 2. 18 - The wireless connection - main program
The picture above shows how the program works. It is divided into two separate parts:
transmitter and receiver. They are drawn in the same picture, because they are each others
opposite. Each step in the transmitter part has its partner in the receiver part.
The basic functioning of the program is as follows: the transmitter board listens on its serial
port until a signal is present. Because the sensor board will only send data in the case that a
sensor is triggered, the transmitter will only proceed to the next step when a sensor is
triggered.
57
If such an event occurs, the Atmel microcontroller will transform the data (containing
information about which sensor is triggered) to parallel data and store it in a ‘buffermemory’.
The term ‘buffermemory’ is used, because the data is only stored there for a very short period.
Next, the RF-module will send the length of the data. This information is calculated by the
microcontroller. Sending the length of the data is a necessary step in the protocol of the RFmodule. The receiving RF-module needs this information. It will not send it to the receiving
microcontroller however. It only needs it for internal functioning.
The last step in the transmitter process is sending the actual data.
The receiver board then. This board is listening on the radio frequency (433 MHz) using its
RF-module. Because the transmitter board will only send data in the event that a sensor is
triggered, the receiver board should only receive data when a sensor is triggered. It only
proceeds to the next step when such an event occurs.
When such an event occurs, the first thing the receiver board receives is the length of the data
that will be sent next. This data is accepted and interpreted by the RF-module itself. It is not
sent to the microcontroller of the receiver board.
Then the receiver board will receive the actual data (of which it already knows the length).
The microcontroller will store this data into a ‘buffermemory’.
And then, finally, the microcontroller will transform this data back to serial data and send it
through the UART to the serial port. This data can then be accessed by the sensor node.
As was mentioned before, the serial ports use a baud rate of 9600. During the tests it became
clear that the RF-boards are not capable of supporting higher baud rates. This is not a problem
however. It is more then enough for a testing application. Also, when this product is
commercialized, it will not use RF-modules for the wireless communication. Probably
wireless LAN will be used.
58
Fig. 2. 19 - The wireless connection - transmit algorithm
Of course this was a very superficial explanation of the program. The next explanation
highlights a specific part of this program, and goes a bit more into detail. It is almost
impossible to explain every part of the program into detail. But this is an interesting one, that
is typical for wireless communication, and also shows that the program is actually more
complex then the first model makes you believe.
The figure above shows the interaction between the Atmel microcontroller and the RFmodule in the sending procedure of the transmitter board. The principle however is the same
for the receiving procedure.
This part of the program is actually a method, and it is used every time data needs to be send.
It starts with a simple handshaking. The microcontroller sends a ‘request to send’ to the RFmodule. Then it waits for response before taking any new actions (unless of course no
response comes in a given amount of time).
59
The RF-module now knows the microprocessor has some data it wants to send. When it is
ready to send this data the RF-module will give its ‘request accepted’ to the microcontroller.
This means that the RF-module has finished all previous sending tasks, and is now ready to
perform another one.
Then the microcontroller will send the first nibble of data, being the four least significant bits
to the RF-module. Four bits, because the RF-module only has four parallel data ports.
Then the procedure is repeated, but now the four most significant bits are sent. This is because
this program always works with at least one byte, or eight bits, of data. The picture below
show the part of the program that was explained more into detail.
void HSK_TX(byte data)
{
while_TXA_0();
// wait until the RF-module is ready
RFD_OUT();
// set data-pins as outputs
TXR_0();
// request to send
while_TXA_1();
// wait until ‘request accepted’
PORTB = (PORTB&0xF0) | (0x0F & data);
// send least significant nibble
TXR_1();
// reset ‘request to send’ pin
while_TXA_0();
// wait until the RF-module is ready
TXR_0();
// request to send
while_TXA_1();
// wait until ‘request accepted’
PORTB = (PORTB&0xF0) | (0x0F & (data>>4));
// send most significant nibble
TXR_1();
// reset ‘request to send’ pin
while_TXA_0();
// wait until RF-module is ready
}
Fig. – The RF-boards –transmit algorithm detail – the actual code
As was already mentioned, the entire program results in serial data containing information
about which sensor was triggered being present on the serial port of the sensor node.
60
3.4
Testing
To test this functional block, Windows Hyperterminal was used. Each RF-board was
connected to a computer. To do this a serial cable was used.
Then communication between the two hyperterminals was attempted. The computer with the
transmitter board attached to it was used to send information to the computer with the receiver
board attached to it. By checking if any data was received, and if so, if the right data was
received, it was possible to verify the functioning of this functional block.
Once the previous test was satisfactory, the transmitter board was attached to the sensor
board. Now, if a sensor was triggered, data about which sensor was triggered needed to be
received by the hyperterminal. If so, the functioning of both functional blocks, and their
compatibility was confirmed.
61
3.5
The future
In this test application, a unidirectional point-to-point wireless connection is used. Of course,
in the future this will evolve. More complex and commercial kinds of connections will be
used in this part of the project.
For instance, more transmitter boards will be communicating with the same receiver board.
Of course, some kind of a protocol to handle this, and avoid collisions, should be made. The
ideal here is to make it possible to use some kind of ‘plug&play’. When a sensor with a
transmitter board comes in reach of the receiver board, it is automatically integrated into the
system.
Another option that is worth considering, is using a bidirectional connection. Enabling the
microcontroller to give commands to some sensors, in other words. This would for example
make it possible to adjust the position of a camera, when it gets information from a motion
detector.
Also, it was never the intention to keep using the RF-modules. They are just for the test
application. Probably the wireless connection will switch to wireless LAN.
Finally, in order to provide even more security, the data will be sent encrypted.
62
Chapter 4
The sensor nodes
4.1
Goal
In this testing application only two nodes are used. But they each have a different function.
This will not be the case in the final design however. The testing design on the other hand
needs the two functionalities.
From now on, the nodes will be called node 1 and node 2.
Node 1 is used as a real node. This node is used to collect the data from the sensors, which
was transferred using the wireless connection. When it has received data, it will connect to the
internet (using TCP/IP) and send that information to an IP address. This node will actually
send its data to node 2, because the IP address it sends to, is the IP address assigned to node 2.
Node 2 is not actually a node. It is called a node here, because it uses the same hardware as
the real nodes. But, unlike the real nodes, it functions as an embedded webserver. The sensor
nodes of type ‘node 1’ will send their data to the IP address of this webserver. This ‘node’
will create a webpage and publish which sensors were triggered on the internet.
63
As was mentioned above, the type ‘node 2’ nodes will not be used in the final design. When
the entire project is finished, it will have a central server that will, among other things,
perform the tasks of node two. In fact, this central server is already being designed.
But, because no such central server was existing when the test application was made, a
solution had to be found. This solution was the creation of an embedded webserver, using the
hardware of a normal sensor node.
64
4.2
The hardware
To create a sensor node, hardware is needed of course. Choosing the hardware for these nodes
was done in two phases.
At first, creating the hardware seemed the best solution. The final design would need newly
designed hardware anyway. A design for the new hardware was made. The design was using
the Maxim Dallas Semiconductor DS80C400 microcontroller.
The design had two serial ports and the RF-receiver board was already integrated. Also, some
space was reserved to add a GPRS-module and a wireless LAN card. So, the same design
could be used while the project progressed. The schematic for this design was made.
The actual PCB however, was never made. An easier solution had presented itself: the TINI
board. This TINI board also uses the Maxim Dallas Semiconductor DS80C400
microcontroller. Furthermore, it has two serial ports and an Ethernet connection. In other
words, it was ideal. Using this board would greatly enhance the chance on success. The newly
designed board had too many factors that could go wrong. There could be mistakes in the
hardware, there could be mistakes in the software, … The hardware of the TINI board worked
without a doubt. It had been tested before. Also, using this board could save a great deal of
time. So, a working test model of the project could be ready much faster.
The new design is not lost however. Probably it will already be in use in the next version of
this project. The people designing it will be sure the software works. They will only have to
worry about the hardware.
4.2.1
The DS80C400 microcontroller
General
The DS80C400 network microcontroller from Maxim/Dallas Semiconductor is part of the
8051 family. The microcontroller offers the highest integration available in a 8051 device.
65
The microcontroller includes a 10/100 Ethernet MAC, three serial ports, a CAN 2.0B
controller, 1-Wire Master, and 64 I/O pins.
Fig. 2. 20 - The sensor nodes - microcontroller DS80C400
To enable access to the network, a full applicationaccessible TCP IPv4/6 network stack and
OS are provided in the ROM. The network stack supports up to 32 simultaneous TCP
connections and can transfer up to 5Mbps through the Ethernet MAC. Its maximum
systemclock frequency of 75MHz results in a minimum instruction cycle time of 54ns. Access
to large program or data memory areas is simplified with a 24-bit addressing scheme that
supports up to 16MB of memory.
To accelerate data transfers between the microcontroller and memory, the DS80C400
provides four data pointers, each of which can be configured to automatically increment
or decrement upon execution of certain data pointer-related instructions. The DS80C400’s
hardware math accelerator further increases the speed of 32-bit and 16-bit multiply and divide
operations as well as high-speed shift, normalization, and accumulate functions.
The DS80C400 has resources that far exceed those normally provided on a standard 8-bit
microcontroller. Many functions, which might exist as peripheral circuits to a microcontroller,
have been integrated into the DS80C400.
In the figures below, you see the package of the DS80C400 microcontroller and his internal
structure.
66
Fig. 2. 21 - The sensor nodes - microcontroller DS80C400 pin package
Fig. 2. 22 - The sensor nodes - microcontroller DS80C400 internal structure
67
Functional description
With extensive networking and I/O capabilities, the DS80C400 is equipped to serve as a
central controller in a multitiered network. The 10/100 Ethernet media access controller
(MAC) enables the DS80C400 to access and communicate over the Internet.
Instant connectivity and networking support are provided through an embedded 64kB ROM.
This ROM contains firmware to perform a network boot over an Ethernet. The ROM
firmware realizes a full, application-accessible TCP/IP stack, supporting both IPv4 and IPv6.
The 10/100 Ethernet MAC featured on the DS80C400 complies with both the IEEE 802.3
MII and ENDEC PHY interface standards. The Ethernet controller provides receive, transmit,
and flow control mechanisms through a media-independent interface (MII), which includes a
serial management bus for configuring external PHY devices. The MII can be configured to
operate in half-duplex or full-duplex mode at either 10Mbps or 100Mbps, or can support
10Mbps ENDEC mode operation.
The DS80C400 features a full-function CAN 2.0B controller. This controller provides 15 total
message centers, 14 of which can be configured as either transmit or receive buffers and one
that can serve as a receive double buffer. A special auto-baud mode allows the CAN
controller to quickly determine required bus timing when inserted into a new network. A
SIESTA sleep mode has been made available for times when the CAN controller can be
placed into a power-saving mode.
The DS80C400 also has a advanced power-management. The low-voltage microcontroller
core runs from a 1.8V supply while the I/O remains 5V tolerant, operating from a 3.3V
supply. A power-management mode allows software to switch from the standard machine
cycle rate of 4 clocks per cycle to 1024 clocks per cycle. The microcontroller can be
configured to automatically switch back from power-management mode to the faster mode in
response to external interrupts or serial port activity. The DS80C400 provides the ability to
place the CPU into an idle state or an ultra-low-power stop-mode state.
68
The DS80C400 includes four internal memory areas:
•
256 Bytes of RAM
•
8kB of SRAM for Ethernet MAC transmit/receive buffer memory
•
1kB of SRAM configurable as various combinations of data memory and stack
memory
•
256 Bytes of RAM reserved for the CAN message centers
•
64kB embedded ROM firmware
The microcontroller provides a serial port (UART) that is identical to the 80C52. Two
additional hardware serial ports are provided that are duplicates of the first one. This second
port optionally uses pins P1.2 (RXD1) and P1.3 (TXD1). The third port optionally uses pins
P6.6 (RXD2) and P6.7 (TXD2).
All three serial ports can operate simultaneously and be configured for different baud rates or
different modes. When using a timer for the purpose of baud rate generation, serial port 1
must use timer 1, serial port 2 must use timer 3, while serial port 0 can use either timer 1 or
timer 2.
The microcontroller provides four general-purpose timer/counters. Timers 0, 1, and 3 have
three common modes of operation. Each of the three can be used as a 13-bit timer/counter,
16-bit timer/counter, or 8-bit timer/counter with auto-reload. Timer 0 can also operate as two
8-bit timer/counters. When operated as a counter, timers 0, 1, and 3 count pulses on the
corresponding T0, T1, and T3 external pins.
Timer 2 is a true 16-bit timer/counter with several additional operating modes. With a 16-bit
reload register, timer 2 supports other features such as 16-bit autoreload, capture, up/down
count, and output clock generation.
All four timer/counters default to the standard oscillator frequency divided by 12 input clock
but can be configured to run from the system clock divided by 4. Timers 1 and 2 can also be
configured to operate with an input clock equal to the system clock divided by 13.
Loading
The loading of the DS80C400 microcontroller uses a hardware serial port. There is a serial
loader function implemented by the firmware that can be invoked by leaving the serial loader
69
pin (P1.7) at logic 1 during the boot sequence. When this condition is found, the ROM
monitors the RXD0 pin for reception of the <CR> character at a supported baud rate. The
serial loader function uses hardware serial port 0 in mode 1 (asynchronous, one start bit, eight
data bits, no parity, and one stop bit in full duplex). The serial loader can automatically detect
certain baud rates and configure itself to that speed. Timer 2 (used for serial port 0 baud rate
generation) is based on the external clock frequency and desired baud rate. The functionality
was designed to work for clock rates from 3.680MHz to 75.000MHz and baud rates from
2400 to 115,200.
Once a supported baud rate has been detected, the DS80C400 transmits an ASCII text banner
containing copyright information and prompt for command entry. At this point, the user can
issue any of the supported serial loader commands.
4.2.2
The TINI board
The figure below shows a picture of the TINI board. TINI means: Tiny InterNet Interface. As
is visible in the picture below, the TINI board consists of two separate boards. The separate
boards are called DSTINIm400 (the smaller board) and DSTINIs400 (the bigger board).
Fig. 2. 23 - The sensor nodes - TINI board
70
The DSTINIm400 board includes a real-time clock, 1MB flash, 1MB static RAM, and
support for an external Ethernet PHY for connecting to a wide variety of networks. The
circuit board is designed as a module to be plugged into a 144-pin SODIMM connector. So
actually, this board is providing the DS80C400 microcontroller with a clock frequency and
memory. The microcontroller has everything it needs to operate properly.
The DSTINIs400 includes a 144-pin SODIMM connector, this is where the connection to the
DSTINIm400 board can be made. It has two serial ports and a 10/100 Ethernet PHY
connection for connecting the TINIm400 to the physical world. Furthermore this board
provides 1-Wire and CAN2.0B, but those are not used in this testing application.
When these two boards are put together, and form the TINI board, they are ideal for the
projects goals. All the hardware needed to create a sensor node is present. And fully tested.
Although this board is used to create a sensor node in this project, this is of course not what it
was designed for. The intention of the creators, when Maxim Dallas Semiconductors ordered
the creation of this board, was to make a PCB that was capable of fully testing and evaluating
all the features of the DS80C400 microcontroller. Later on, once the microcontroller was fully
tested, this board was sold as a product by Dallas Semiconductor.
71
4.3
Software
4.3.1
Node 1
As was mentioned before, two types of nodes exist in the testing application. They use the
same hardware, so the distinction is entirely made in software. Here the sensor node type
‘node 1’ will be explained. Later on the same will be done for the type ‘node 2’ sensor nodes.
First of all, how to program a DS80C400 microcontroller? The TINI board provides a
programming interface using a serial port. So, in order to program the microcontroller, the
board simply needs to be connected to a computer using a serial cable.
Node 1 was programmed in C-code. Therefore a program was needed that could compile Ccode for the DS80C400 microcontroller. The program used for this was SDCC. This program
is freeware, and can be downloaded easily.
To load it into the microcontroller, after compiling, another program was needed. It needed to
be able to program using the TINIm400 programming configuration. In this case
Microcontroller Tool Kit (MTK) was chosen. This program is also freeware. It is provided by
Maxim Dallas Semiconductor. This program is also capable of real time monitoring. This will
be explained in the part about testing.
The program for node 1 consists of several parts. Only the important programs are explained
here. More programs were used. Some of them contain (very long) assembler code. They are
meant to initialize the microcontroller. These programs are free. They can be downloaded
without problems. No one actually programs these things. When you want to program a
DS80C400 microcontroller, you just use these ‘initialization programs’ provided by Maxim
Dallas, or in this case, provided by the SDCC compiler. At most, some changes will be made
to them. More likely, if some of the initial settings need to be changed, it will be done in the
C-program. This is also what was done in the program for node 1. The only exceptions are the
baud rate of the serial ports and the clock frequency. They were modified in the original
72
initialization files. The baud rate was changed to 9600 (originally 115200). The reason can be
found within the RF-modules. They are not capable of handling a baud rate of 115200.
Also, lots of libraries were used. They are also downloadable for free.
Two main parts can be distinguished in the program of node 1. They are called socket.c and
main.c. The part called socket.c is actually just a group of methods, that are used by main.c.
What exactly does this main.c program do? The picture below shows a very rough flow chart
of the program.
Fig. 2. 24 - The sensor nodes - program node 1
73
The first two steps in the program are preparing the microcontroller to perform its tasks later
on. They are a kind of initialization. This for example reserves RAM (random access
memory), initializes ROM (read-only memory) and takes care of the network parameters. It
modifies some of the initializations that were done in the SDCC initialization files of the
DS80C400. These two parts are executed only once. After that, the initialization is complete,
and there is no need to execute them again.
Then, the DHCP client is started. DHCP means: Dynamic Host Configuration Protocol. This
DHCP is a program that runs on a remote server. This means: a server that is not part of this
testing application. The server is reachable through the internet. The program will connect to
the internet, and request an IP address. The DHCP server will assign an IP address to the
device.
The next step is called ‘socket’. This part is about setting up a TCP/IP socket, for
communication with node 2. TCP/IP is a suite of protocols for networking computers (and
embedded systems) and transmission of data between them. IP (Internet Protocols) breaks
data into packets and routes them in best-effort delivery. TCP (Transmission Control
Protocol) provides reliability of the delivery. But what is a TCP/IP socket? In TCP/IP-based
networks, a socket defines a logical address for a program. Sockets allow communication
between client and server programs. This socket is about the communication between node 1
and node 2, over the internet. Node 1 needs to send the data, containing information about
which sensor was triggered, to node 2. So, a socket is created. To create the socket, node 1
needs the destination’s IP address and port. This is of course impossible, unless node 2 is
already powered up. Once node 2 is powered up and received its IP address, the socket is
created.
The last part of the flow chart shows: ‘Tx data’. This means: transmit data. Node 1 is now
fully initialized, received its IP address and has a TCP/IP socket connection with node 2. So it
is ready to transmit data. Node 1 listens on its serial port. As was already mentioned, it will
only receive data when a sensor was triggered. When this event occurs, node 1 will read the
data from its serial port, and then transmit it through the socket connection to node 2, using
the TCP/IP protocol.
74
4.3.2
Node 2
Node 2 is different from node 1. Of course the program and function are different, but even
the language in which they were programmed is different. Node 2 is programmed in Javacode. The reason for this is very simple. The DS80C400 microcontroller has very good Javacompilers available. Furthermore, it was designed to use Java. And, of course, creating a
webserver is much easier in Java then it is in C-code.
The hardware concerning the programming of the TINI board was already explained in the
part about node 1. But what about the software?
To program node 2, a Java compiler was needed. The compiler used was JavaKit. To use
JavaKit, you must have the Java Runtime Environment 3 and the Java Communications API4
installed. The JavaKit tool is equipped with the TINI Software Development Kit. JavaKit was
also used to load the program into the DS80C400 microcontroller.
The program itself uses TINI OS. This is an operating system for the DS80C400
microcontroller on the TINI board. It is provided by Maxim Dallas Semiconductor as
freeware. TINI OS is a small command shell intended to provide a UNIX-like interface to
TINI’s runtime environment. It is a Java application that is interpreted by TINI’s JVM. TINI
OS is less than a full operating system but more than a simple shell. It provides a way to view
and manipulate the file system, run other Java applications, and control system functions such
as the watchdog timer and network configuration.
The actual program for node 2 consists of three main parts: TCPListener.java,
WebWorker.java and TINIWebServer.java. TINIWebServer.java is actually the main
program. The other two are just classes used by this main program.
75
Fig. 2. 25 - The sensor nodes - program node 2
The figure above shows a rough flow chart of the program for node 2. It illustrates the main
steps in the program.
When node 2 is powered up, the first program that runs is TINI OS. In this testing application,
the TINI operating system is used to initialize and run the other programs. As mentioned
before, this program is available as freeware.
The next step in the process, is to connect to the DHCP server. This is basically the same as in
node 1. The DS80C400 microcontroller will send a request to the DHCP server. Then the
DHCP server will provide an IP address. This procedure has to be followed by every device
connecting to the internet (unless a fixed IP address is used of course).
Then a webserver is created. Actually, two different tasks are performed here. The first is
creating a “TCP port server”. This means that the device will be listening on that port (port
8031 was used). Of course this is the port to which the data from node 1 will be sent. This
needs to be done before node 1 is powered on, because node 1 needs to know the port and the
IP address of node 2 to create the TCP/IP socket. The second task performed here, is the
creation of a website. This is the website, on which the data about the sensors will be
published.
76
The next step in the process is establishing the connection between the two nodes. This is
mainly done in node 1. Node 1 creates a TCP/IP socket connection between the two nodes,
using the IP address and the port of node 2. Once this socket is established, the nodes are
ready to communicate.
Node 2 will now listen on the port. The data transferred by node 1 will arrive here. Node 2
will only proceed to the next step when it receives data on this port. Node 1 can only send
data in the event that a sensor is triggered. This means that node 2 can only proceed to the
next step when such an event occurs.
When a sensor is triggered, node 2 will receive the data, and publish it on the website. The
user of this testing application is now able to check which sensor was triggered on this
website. Reaching this website can be done, just by entering the IP address of node 2. To
ensure that the data on this website is accurate, it will be refreshed automatically every
second. This provides a user-interface which requires no knowledge of the actual system.
77
4.4
Testing
Testing the nodes while under development is not easy of course. If a mistake in the program
occurs, it is very difficult to find it, especially when you are dealing with a quite big system
like this one.
The first part tested here was node 2. The MTK program can be used to monitor the program.
A lot of the initial tests were done by simply printing out comment when certain actions were
performed in the program. Also, the creation of the website could be easily tested, just using
another computer connected to the internet, and surfing to it. An additional bit of code was
created, to transmit the data about the sensors through the serial port too. This made it
possible to compare the information on the website with the data on the serial port.
Node 1 was tested in a similar way. The MTK program was also used to monitor the program.
Here too a lot of the initial tests were done by simply printing out comment when certain
actions were performed in the program.
Eventually, the functioning of both the nodes together needed to be tested of course. To do
this, node 1 was connected to a Windows Hyperterminal. The hyperterminal was used to
simulate the information about the sensors. A random character was entered here. The data
was sent to node 2 using a TCP/IP connection. Now the HEX-code of the character could be
checked, by reading the data on the serial port of node 2. The ASCII-table was used to verify
this HEX-code. Finally, the HEX-code corresponds to certain sensors being triggered
(simulated of course). So, the website could be checked to verify this.
Then, at last, the nodes were connected to the rest of the testing application.
78
4.5
The future
What will this functional block look like in the future?
The type ‘node 2’ sensor nodes will no longer exist of course. As was mentioned before, they
will be replaced by a central server. This central server will, among other things, perform the
tasks of node 2.
So, all the sensor nodes will be type ‘node 1’ sensor nodes. But, of course these nodes will
evolve too. What will be different in the future?
Obviously the hardware will change. When this project finally becomes a commercial project,
it will no longer use the TINI boards. In the near future, the design with the integrated RFmodule and the reserved space for a GPRS-module and a wireless LAN card will probably be
used. However, this will not likely be the final model. The commercial model needs to be
smaller.
What will change in the software?
One of the priorities is the logging of events. When the communication with the central server
fails, the sensor node needs to be able to log the events, so it can retransmit later on.
Another priority is using IPv6 (instead of IPv4, which is now used). IPv6 is short for ‘Internet
Protocol Version 6’. IPv6 is the ‘next generation’ protocol designed by the IETF (internet
engineering task force) to replace the current version Internet Protocol, IP Version 4 ("IPv4").
Most of today's internet uses IPv4, which is now nearly twenty years old. IPv4 has been
remarkably resilient in spite of its age, but it is beginning to have problems. Most importantly,
there is a growing shortage of IPv4 addresses, which are needed by all new machines added to
the Internet. IPv6 fixes a number of problems in IPv4, such as the limited number of available
IPv4 addresses. It also adds many improvements to IPv4 in areas such as routing and network
autoconfiguration. IPv6 is expected to gradually replace IPv4, with the two coexisting for a
number of years during a transition period. Obviously, a new security system cannot use an
old internet protocol.
79
Encryption is another improvement that will be added. The transferring of the sensor data will
happen encrypted in the future. The methods of encryption will be explained more into detail
later on in this thesis.
Also, ‘rogue nodes’ will be included. These are nodes that are randomly chosen (and they can
be different nodes in time), and they can keep working in the unlikely event the central server
should be compromised and be used to deactivate the sensor nodes. This is some kind of an
additional security.
Other possibilities might include node-to-node communication, node-to-sensor board
communication, … But these are merely possibilities. The changes that are already planned
are mentioned above.
80
Chapter 5
Conclusion
The practical design that was described here, is of course a proposal. But is it a solution?
Does it meet all requirements?
These were the requirements for the testing application:
•
Reading the output of a small amount of simple digital sensors. ‘Simple digital
sensors’ means that the output can only have two different states. Triggered or not
triggered. Nothing more.
•
Transporting the sensor data using a wireless unidirectional point-to-point connection.
To create this connection, RF-modules using the free radio band have to be used.
•
Communication over the internet between two nodes, using TCP/IP. One node simply
needs to send the sensor data to the other node.
•
Providing a way to check if the last node received the sensor data correctly. If
possible, with a user interface, that doesn’t require any technical knowledge about the
project.
To meet the first requirement, two digital sensors (a motion detector and a door/window
position detector) and four buttons (simulating simple digital sensors) were used. The data
was combined and transformed to serial data using an Atmel microcontroller. Obviously,
doing so, the first requirement was met.
81
The second requirement then. The proposal made here was a design, with a serial data input
and a serial data output. In between, the data was sent wirelessly, using RF-modules. These
RF-modules use 433MHz. This is a frequency located in the free radio band. Unfortunately,
these RF-modules need a parallel data input and deliver a parallel data output. To solve this
problem, two Atmel microcontrollers were used. They were programmed to perform serial-toparallel and parallel-so-serial conversions, and to regulate interaction with the RF-modules,
for example by handling the handshakings. The result was a wireless unidirectional point-topoint connection, capable of transporting the data from the previous part to a sensor node
using the air interface (= wireless). Thus, the second requirement was met.
The third requirement was met by using two TINI boards. They served as sensor nodes. The
data from the wireless connection was send to one of the nodes. This node makes a
connection to the other node through the internet, using TCP/IP. Then, the data is sent to the
second node, using this connection. Obviously, this is exactly what the third requirement says.
The fourth and final requirement then. Creating a website was the solution that was proposed
here. The second node creates a website where the results are shown. Anyone can now check
which sensors were triggered. Just surf to the website. No knowledge of the technical part of
the project is needed to do this. The last requirement was met.
Conclusion: all the requirements were met. This is a good solution for the project, and using it
requires no knowledge of the technical side.
82
Part 3
RANDOM NUMBER GENERATOR
83
Chapter 1
Goal
In the future, all data traffic in the wireless sensor network will be encrypted. All
communication over the different technologies will be encrypted using a public key
encryption scheme based on an elliptic curve cryptographic system.
For our test application this was not yet necessary. Although it will be developed in the near
future.
Information that has to be encrypted needs a secret key. A secret key can be created through
software, using a random number. So called computer-generated "random" numbers are more
properly referred to as pseudorandom numbers. Random numbers can also be generated
through hardware. We had to develop a random number generator based on a radioactive
source.
Next is a short theoretical explanation of the basics of encryption and especially ECC (Elliptic
Curve Cryptography). Also some commentary on the principles of radioactivity is given.
Furthermore an explanation of the functioning of a smoke detector which leads to the actual
random number generator.
84
Chapter 2
Theoretical background
2.1
Symmetric and asymmetric encryption
When someone wants to send sensitive data over an insecure medium, encrypting this data is
a must. There are two systems used, symmetric and asymmetric encryption.
Symmetric encryption relies on a single key, which both the sending and receiving end have
in their possession. The newer, more secure system is asymmetric encryption, which relies on
a keypair, one public key and one private. The private key is in possession of the side wishing
to prove its identity. The public key is in the possession of the side wishing to verify the
identity of the holder of the private key. Asymmetric authentication methods are the
technology behind digital signatures and certificates. Asymmetric encryption is used every
day, when making a secure connection to a bank, to online shopping …
The private key cannot be extracted from the public key. This makes key-exchange much
more simple then, like when using symmetric cryptography, when there is only one key.
It also solves a big problem symmetric cryptography has: one cannot know which party
signed a certain message, as both sender and receiver use the same key for both authentication
and signature generation.
In asymmetric authentication, only one party knows the private key, with which the message
is signed. Everyone may know the public key. Since the private key cannot be derived from
85
the public key, the signature serves as a unique identifier. If the message verifies as having
been signed by the person with knowledge of the private key, we know who sent the message.
But any number of people may have knowledge of the public key, and all of them can
therefore verify the identity of the sender.
However, asymmetric cryptography is demanding and complex. The way key-generation
works, the mathematically demanding algorithms, are very hard and need a lot of CPU-power
and sufficient resources for the implementation are needed. They need much more resources
than for symmetric cryptography. This presents problems for many resource-constrained,
embedded systems. But if one needs to have a secure way of transmitting data from an
embedded system to the outside world, there really is no other choice than to make use of
Elliptic Curve Cryptography.
86
2.2
Elliptic Curve Cryptography
Elliptic curve cryptography was invented by Neil Koblitz in 1987 and by Victor Miller in
1986. The principles of elliptic curve cryptography can be used to adapt many cryptographic
algorithms, such as Diffie-Hellman or ElGamal.
ECC becomes the more practical system for use. And as security requirements become more
demanding, and processors become more powerful, considerably more modest increases in
key length are necessary, if you're using the ECC cryptosystem. This keeps ECC
implementations smaller and more efficient than other implementations. ECC can use a
considerably shorter key and offer the same level of security as other asymmetric algorithms
using much larger ones. Moreover, the gulf between ECC and its competitors in terms of key
size required for a given level of security becomes dramatically more pronounced, at higher
levels of security.
This feature of asymmetric cryptography greatly simplifies key exchange. In a large network
of N communicating entities, if it is fully meshed, maintaining unique symmetric keys for
each communicating pair of entities would require the management of (N x (N-1))/2 keys.
Using asymmetric cryptography, this quantity can be reduced to N key pairs. In a group of
1000 users, it's the difference between managing 1000 key pairs or 499500 keys.
An asymmetric cryptographic key pair can be seen as a pair of numbers which have some
relationship associated with a mathematical function which is relatively easy to compute in
one direction, but whose inverse is in practical terms impossible to determine. This feature,
the function which is easy to calculate in one direction, but impossible to find in the other, is
common to all asymmetric cryptographic systems, including ECC.
The way that the elliptic curve operations are defined is what gives ECC its higher security at
smaller key sizes. An elliptic curve is a set of points (x, y), for which it is true that
y2 = x3 + ax + b,
given certain chosen numbers a and b. Typically the numbers are integers, although in
principle the system also works with real numbers. Despite what the name suggests, the
87
curves do not have an elliptic shape. For example, a = -4 and b = 0.67 gives the elliptic curve
with equation
y2 = x3 - 4x + 0.67.
This curve is illustrated in the following figure.
Fig. 3. 1 - RNG - Elliptic Curve Cryptography
If x3 + ax + b contains no repeated factors, or equivalently if 4a3 + 27b2 is not 0, then the
elliptic curve can be used to form a group. A group is simply a set of points on the curve.
Because it is a group, it is possible to "add up" points which gives another point on the curve.
On the graph, two points are added up by drawing a line through both and taking as the
outcome where the line intersects the curve. For cryptographic purposes, an elliptic curve
must have only points with all coordinates integers in the group. The trick with elliptic curve
cryptography is that if you have a point F on the curve, all multiples of this point are also on
the curve.
The best way to show the working of this principle is by giving an example. The example
shows how the public key is generated and following the encryption and decryption of the
message. Also the possibility of cracking the key.
88
How the generation of an elliptic curve public key works?
Annelies and Bert agree on an elliptic curve and pick a certain point F on this curve. They
can do this with Eric listening in. Annelies next picks a random number AS (which does not
have to be a point on on the curve) and computes AP = AS*F. The point AP is on the curve,
because it is a multiple of F. This is easy to compute.
Annelies’ public key is AP and her secret key is AS. Bert does the same thing and ends up with
BP and BS.
How does the encryption and decryption of the messages works?
Annelies and Bert can now secretly agree on a key with which they can encrypt messages
using secret key cryptography. The key simply is the product of Annelies’ public key and
Bert's secret key (which is the same as the product of Annelies’ secret key and Bert's public
key). It will be clear that Annelies and Bert can compute this product after they have
exchanged their public keys, but Eric cannot since he has none of the secret keys.
Can the elliptic curve key be cracked?
If Eric wanted to crack the key, he would have to reconstruct one of the secret keys. This
means having to compute AS given AP and F (because AP = AS * F). And that is very
difficult. The number of discrete points on the curve (points with both X and Y coordinates
being integers) is called the order of the curve. If the order of the point F is a prime number
of n bits, then computing AS from AS*F and F takes roughly 2n/2 operations. If F is, say, 160
bits long, then Eric needs about 280 operations. If he can do a billion operations per second,
this takes about 38 million years.
This problem is commonly referred to as the elliptic curve discrete logarithm problem.
The conclusion is that Elliptic Curve Cryptography is the solution for a lot of problems. ECC
has a huge advantage compared to other asymmetric crypto systems.
The smaller ECC keys mean the cryptographic operations that must be performed by the
communicating devices can be squeezed into considerably smaller hardware, that software
89
applications may complete cryptographic operations with fewer processor cycles, and
operations can be performed that much faster, while still guaranteeing equivalent security.
This means, in turn, less heat, less power consumption, less real estate consumed on the
printed circuit board, and software applications that run more rapidly and make lower
memory demands, leading in turn to more portable devices, which run longer, and produce
less heat.
90
2.3
Principles of radioactivity
The radioactive source we used for our random number generator, was retrieved from a
smoke detector. Next is a short explanation about the basics of radioactivity and the working
of a smoke detector. This will help you to better understand the random number generator.
The vital ingredient of household smoke detectors is a very small quantity (<35 kBq) of
americium-241 (Am-241). Americium is a man-made radioactive metal, with Atomic Number
95. The most important isotope of Americium is Am-241. Americium is a silver-white,
crystalline metal that is solid under normal conditions. All isotopes of americium are
radioactive. Americium-241 primarily emits alpha particles, but also emits gamma rays.
Americium-241 has a half-life of 432,7 years.
Alpha particles are made of 2 protons and 2 neutrons. This means that they have a charge of
+2, and a mass of 4 (the mass is measured in "atomic mass units", where each proton and
neutron = 1). Alpha particles are relatively slow and heavy. They have a low penetrating
power. Because they have a large charge, alpha particles ionise other atoms strongly.
Beta particles have a charge of minus 1, and a mass of about 1/2000th of a proton. This means
that beta particles are the same as an electron. They are fast, and light. Beta particles have a
medium penetrating power. They are stopped by a sheet of aluminium or plastics such as
perspex. Beta particles ionise atoms they pass, but not as strongly as Alpha particles do.
Gamma rays are waves, not particles. This means that they have no mass and no charge.
Gamma rays have a high penetrating power. It takes a thick sheet of metal such as lead, or
concrete to reduce them significantly. Gamma rays do not directly ionise other atoms,
although they may cause atoms to emit other particles which will then cause ionisation.
The alpha particles emitted by the Am-241 collide with the oxygen and nitrogen in air in the
detector’s ionisation chamber to produce charged particles called ions. A low-level electric
voltage applied across the chamber is used to collect these ions, causing a steady small
electric current to flow between two electrodes. When smoke enters the space between the
91
electrodes, the alpha radiation is absorbed by smoke particles. This causes the rate of
ionisation of the air and therefore the electric current to drop, which sets off an alarm.
The alpha particles from the smoke detector do not themselves pose a health hazard, as they
are absorbed in a few centimetres of air or by the structure of the detector. Alpha particles are
easily stopped by thin barriers (sheets of paper, dead layers of skin, … ), so that as a
radiological hazard alpha particles are only dangerous if they are generated inside one's body
(where the skin cannot protect tissue from damage). Americium-241 poses a significant risk if
swallowed or inhaled. It can stay in the body for decades and continue to expose the
surrounding tissues to both alpha and gamma radiation, increasing the risk of developing
cancer. Americium-241 also poses a cancer risk to all organs of the body from direct external
exposure to its gamma radiation.
To prove the low power of the alpha particles generated by the Americium-241 of the smoke
detector, some measurements were done. To do this a simple Geiger counter was used. The
aim was to measure the amount of radioactivity in function of the distance. This was done
three times, without anything between the source and the counter, with an aluminium shield in
between and with only a paper in between.
Fig. 3. 2 - RNG - Geiger counter and radioactive source
92
The table and graph given below shows the results.
Without Aluminium shield
Distance
(cm)
With Aluminium shield
Radioactivity
(pulses/s)
With paper
Distance
(cm)
Radioactivity
(pulses/s)
Distance
(cm)
Radioactivity
(pulses/s)
0
200
0
10
0
20
0,2
150
0,2
8
0,2
15
0,4
80
0,4
6
0,4
10
0,6
50
0,6
5
0,6
8
0,8
15
0,8
4
0,8
6
1
10
1
4
1
5
2
6
2
4
2
4
3
4
3
4
3
4
Radioactivity in function of the distance
200
180
160
Radioactivity (pulses/s)
140
120
Without shield
With shield
With paper
100
80
60
40
20
0
0
0,2
0,4
0,6
0,8
1
1,2
1,4
1,6
1,8
2
2,2
2,4
2,6
2,8
3
Distance (cm)
The results clearly show the low penetrating power of the alpha particles. After a very short
distance there’s almost no radioactivity anymore.
When we measure the radioactivity in the air in the environment, the indicator of the counter
continously switched between the value 0 and 4 pulses/s. So from the moment we measure
this value, the result isn’t useful anymore.
93
The second conclusion is the alpha particles are easily stopped by thin barriers. With only one
single paper in between the amount of radioactivity decreases very much. The use of a shield
gives even better results.
94
2.4
Random number generator
People working with computers often sloppily talk about their system's "random number
generator" and the "random numbers" it produces. But numbers calculated by a computer
through a deterministic process, cannot, by definition, be random. Given knowledge of the
algorithm used to create the numbers and its internal state, you can predict all the numbers
returned by subsequent calls to the algorithm, whereas with genuinely random numbers,
knowledge of one number or an arbitrarily long sequence of numbers is of no use whatsoever
in predicting the next number to be generated.
Computer-generated "random" numbers are more properly referred to as pseudorandom
numbers, and pseudorandom sequences of such numbers. A variety of clever algorithms have
been developed which generate sequences of numbers which pass every statistical test used to
distinguish random sequences from those containing some pattern or internal order. There are
programs available which applies such tests to sequences of bytes and reports how random
they appear to be, and if you run this program on data generated by a high-quality
pseudorandom sequence generator, you'll find it generates data that are indistinguishable from
a sequence of bytes chosen at random. Indistinguishable, but not genuinely random.
Today, one can get random bits from a radioactive source over the Internet through a service
called 'HotBits'. HotBits is an Internet resource that brings genuine random numbers,
generated by a process fundamentally governed by the inherent uncertainty in the quantum
mechanical laws of nature, directly to your computer in a variety of forms. HotBits are
generated by timing successive pairs of radioactive decays detected by a Geiger-Müller tube
interfaced to a computer.
In fact, radioactive sources creating random bits have been used for a long time. Since the
1960's, this method has been used. You order up your serving of HotBits by filling out a
request form specifying how many random bytes you want and in which format you'd like
them delivered. Your request is relayed to the HotBits server, which flashes the random bytes
back to you over the Web. Since the HotBits generation hardware produces data at a modest
rate (about 30 bytes per second), requests are usually filled from an "inventory" of pre-built
HotBits. Once the random bytes are delivered to you, they are immediately discarded. The
95
same data will never be sent to any other user and no records are kept of the data at this or any
other site.
The major problem with this method is that it has a “dead time” which prevents
measurements while the radiation detector recovers from a previous event.
This is a better method, when continous measurement is prefered.
The radioactive source used in a smoke detector is placed in the center of a plastic block and
connected to ground. Typical ion chambers are 3 to 5 cm in diameter and 2 to 3 cm tall. A
metal plate with a hole in the center is mounted in the plastic about 2 to 5 mm from the
radiation source. An outer cover of steel surrounds the top and sides of the grid and source.
Openings are punched into the cover to allow air to filter in. The radioactive source used in
smoke alarms is Americium 241 which has a half life of 432,7 years. Americium 241 decays
via a 5 MeV alpha particle. This alpha has a range of about 5 cm in air. The material holding
the Americium absorbs some of the energy from decays occurring deeper within the bonder
so there is a large spread of energies and ranges within the ion chamber.
The alpha particles ionize the air in the chamber creating a very weak plasma. By grounding
the alpha source and charging the outer shell, positive ions drift into the source and negative
ions diffuse to the shell. The floating grid sees the plasma potential. Because the plasma
density is low compared to the neutral background the grid floats to a DC value half way
between the source and outer cover.
As an alpha particle rips through the air it strips electrons off nearby atoms with enough force
to cause these electrons to ionize other atoms. This process occurs in nanosecond time scales.
When the energy is expended many electrons are absorbed by the air. Some return to
previously ionized atoms creating neutrals and others create negative ions and molecules in
the air. This recovery time is over within microseconds. Negative charges are drawn to the
outer cover and positive charges towards the radiation source. The charges diffuse at thermal
sound speed due to collisions with neutrals. Because the radiation source is practically
constant, the current flow in the ion chamber is constant. Each decay event creates an electric
shock wave when the free electrons interact with the background plasma. This shock is
coupled to the neutral atmosphere and slowed down to a sound wave which soon hits the grid.
96
Like all natural noise sources the ion chamber exhibits an inverse amplitude to frequency
relationship. There is a spike in amplitude vs. frequency proportional to the decay rate.
The geometry of the ionization chamber determines what fraction of the source can be
detected. For smoke detectors this amounts to 1/8 full solid angle (PI/2 radians).
Since a 1 microcurie source (standard amount listed on all smoke alarms) generates 3,7 x 104
alphas per second we expect to see 4,6 x 103 events per second. Some of these events will be
from low energy alphas. The distribution of Americium within the source material determines
how many radioactive decays have enough energy to ionize the entire length of the ion
chamber.
97
Chapter 3
Hardware
+9V (c)
Radioactive
source
High Pass filter
Low Pass filter
1M
470p
+9V (a)
270k
-
OUT
OUT
+
100k
0
3k
V+
1u
V-
-
+9V (a)
V-
V+
1130p
3u
V-
220
+
10k
OUT
+
2.2n
0
V+
+9V (c)
1u
3.9k
X
-9V (b)
-9V (b)
0
0
0
Aluminium boxes
33n
Y
0
VIN
GND
7809
+15V
0
+9V (a)
VOUT
10u
120n
10u
0
VIN
GND
7909
-15V
-9V (b)
VOUT
10u
120n
Power supply
10u
0
7809
+15V
VIN
GND
0
0
+9V (c)
VOUT
10u
120n
10u
0
Fig. 3. 3 - RNG - schematic
98
The hardware needed for the random number generator, consists of four separate PCB boards.
One of those boards simply takes care of the ADC (analogue to digital conversion). Although
the design for that board already exists, it is not included in this thesis.
The figure above shows the schematic for the other three boards. The dotted lines are actually
aluminium boxes. They are both connected to the ground, and they’re meant to protect the
two PCBs inside against interference and sound. Especially the shielding of the radioactive
source is important. Sounds for example can already have enough influence on it, to negate
the randomness.
As is visible in the figure, the first board contains the radioactive source. The only thing that
happens on this board, is reading a signal from the source, and amplifying it. This board is
concealed in an aluminium box.
The second board is also in an aluminium box. This box is bigger then the first one. It
contains both the board, and the smaller aluminium box. The function of this board is to
created the desired ‘frequency window’. It will filter out the highest and lowest, unwanted
frequencies. To do this, it uses a high and a low pass filter. After filtering, only the
frequencies around 400 Hz remain. A Pspice simulation can be seen in the picture below. The
output of this board is brought outside of the box. It is a random signal. This output will be
connected to the digital board, in order to create the desired digital random numbers.
1.0K
100
10
1.0
100m
10m
1.0m
1.0Hz
V(Vo) / V(Vi)
10Hz
V(X) / V(Vo)
100Hz
V(X) / V(Vi)
Frequency
99
1.0KHz
10KHz
The third board is the power supply for the other boards. It creates three separate DC voltages.
Once –9V, and two times + 9V. These last two are completely independent. The voltages are
used to power the OPAMPs used in the filters and amplifiers.
Fig. 3. 4 - RNG - PCB: power supply
Fig. 3. 5 - RNG - PCB: radioactive source and filter
The pictures above show the physical boards. The first one is the power supply. The second
one shows both the radioactive source board and the filter board. Normally these board are in
aluminium boxes.
100
Chapter 4
Testing and conclusion
The testing of this random number generator was done using an oscilloscope. It was
connected to the output of the filter board. Doing so, a random signal should be visible on the
oscilloscope.
Does this random number generator meet the requirements?
This part of the project only had one requirement:
•
Create a random number generator that delivers true random numbers. The design has
to be based on the random alpha-particle emission of a small radio-active source.
The source used in the proposed solution is the radioactive source of a smoke detector. The
randomness is indeed created based on the alpha-particle emission. However, while this
random number generator was tested, a minor flaw occurred. The generated signal is indeed
random, but it is quite weak. Much weaker then expected. This can of course be solved very
easily, just by amplifying the signal.
Although this random number generator needs further refinement, it does meet the
requirements. In the future, it will need further however.
101
Part 4
FINAL CONCLUSION
102
Final conclusion
In the end, this thesis turned out to be a success. Both parts of the project, the testing
application and the random number generator, meet the requirements that were stated by the
supervisor at the beginning.
The testing application is a good start for the wireless sensor network. It is easy to do tests
with. No knowledge of the technologies is required, it has an easy-to-use user interface. Also,
it is a good starting point to take the next step. The hardware works splendidly, and only some
changes in the software are required to, for example, include a multiple point wireless
connection between the sensors and the nodes. So as a first step in the development process,
this testing application is certainly a success.
The random number generator also meets its requirements. It still has a minor flaw, being that
the random output signal is a bit weak, but nevertheless, it works. This flaw can be easily
solved in the next step of the process, by adding an amplifier. So, this part too provides an
excellent starting point.
This thesis succeeded in its aim.
103
Part 5
APPENDIX
104
PCB designs
In the appendix you find all the PCB designs of the boards we made by ourself.
RF-board
105
Random Number Generator
Power supply
Radioactive source
106
Filter
TOP
BOTTOM
107
Bibliography
ATMEL, 2005.
http://www.atmel.com
GNU. The GNU Operating System.
http://www.GNU.org
LANCOS, 2005.
http://www.LancOS.com
MAXIM DALLAS, 2005.
http://www.maxim-ic.com
RADIOMETRIX, 2003.
http://www.radiometrix.co.uk
SDCC, 2003. Small Device C Compiler.
http://sdcc.sourceforge.net
VAASA POLYTECHNIC.
http://www.puv.fi
WALKER JOHN. Genuine random numbers, generated by radioactive decay.
http://www.fourmilab.ch/hotbits
BARR, Michael, 1999. Programming embedded system in C and C++. 174 p.
DAMS, Johan, 2005. An Introduction to Elliptic Curve Cryptography. 24 p.
DE SMET, Pieter en SCHEPENS, Dieter, 2004. Implementatie van een ad hoc sensorweb op
een microcontroller. 158 p.
108
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertisement