UNIT - 4

WORKING WITH
SENSORS
TOPICS TO BE COVERED
 Working principles of Sensors
 IoT deployment for Raspberry Pi /Arduino/Equivalent platform
 Reading from Sensors
 Communication
 Connecting microcontroller with mobile devices
 Communication through Bluetooth
 Wi-Fi

 USB

 ContikiOS Cooja Simulator.

 Clustering
 Clustering for Scalability
 Clustering Protocols for IOT
WORKING PRICIPLES OF
SENSOR
 SENSOR
 A device which provides a usable output in response to a specified measurand

 A sensor acquires a physical parameter and converts it into a signal suitable for
processing (e.g. optical, electrical, mechanical)
 A transducer
 Microphone, Loud Speaker, Biological Senses (e.g. touch, sight,…etc.)
WORKING PRICIPLES OF
SENSOR
STIMULUS QUANTITY

Acoustic Wave (amplitude, phase, polarization), Spectrum, Wave Velocity, Distance

Biological & Chemical Fluid Concentrations (Gas or Liquid)

Charge, Voltage, Current, Electric Field (amplitude, phase, polarization),

Electric
Conductivity, Permittivity

Magnetic
Magnetic Field (amplitude, phase, polarization), Flux, Permeability

Optical
Refractive Index, Reflectivity, Absorption

Thermal
Temperature, Flux, Specific Heat, Thermal Conductivity

Mechanical Position, Velocity, Acceleration, Force, Strain, Stress, Pressure, Torque

FACTORS INFLUENCING
SENSOR
PIR SENSOR – HC SR 501
USING PIR MOTION SENSORS
ULTRA SONIC SENSOR HC-
SR04
 Specifications
 power supply :5V DC
 quiescent current : <2mA
 effectual angle: <15°
 ranging distance :4– 400 cm
 40KHz ultrasonic signal
HC-SR04

 Control
HC-SR04

 Effectual Angle: <15°

HC-SR04
 There are 4 pins
 VCC , Trig, Echo, GND

 Control
 pull the Trig pin to high level for more than 10us impulse , the module start ranging

 finish ranging, If you find an object in front, Echo pin will be high level, and based on
the different distance,

 it will take the different duration of high level.

 So we can calculated the distance easily :

 Distance = High Level Duration*(Sonic:340m/s)/2

OPEN – SOURCE HARDWARE
 Open source hardware is hardware whose design is made publicly
available so that anyone can study, modify, distribute, make, and sell
the design or hardware based on that design.

 The hardware's source, the design from which it is made, is available in

the preferred format for making modifications to it.

 Ideally, open source hardware uses readily‐available components and

materials, standard processes, open infrastructure, unrestricted
content, and open‐source design tools to maximize the ability of
individuals to make and use hardware.

 Open source hardware gives people the freedom to control their

technology while sharing knowledge and encouraging commerce
through the open exchange of designs.
OPEN – SOURCE HARDWARE

 As no costs for design are incurred for the manufacturers, the price of
open source hardware is very low.
 Key Benefits:
 big source of good ideas,
 a high participation of the community and a high level of transparency in the development
process,
 a high development speed,
 often a high modularity in their solutions, extra development potential for free and a high
level of continuous improvement.
 Closed source hardware is governed by the vendor. Product changes or
upgrades are common. If the customer uses the vendor’s product as a
component or platform to develop new products, the customer has to
update his product because the older version will be no more available
sooner or later.
OPEN – SOURCE HARDWARE

 Furthermore, the customer is not allowed to manufacture it by himself

without owning the appropriate patent.
 Open source developments are differing in the sense that every
direction of development remains available and the customer is allowed
to manufacture the product by himself.
 Open source hardware mainly takes the form of platforms that are easy
to be modified and to be learned, with the aim of developing various
individual solutions.
 Examples:
 Arduino
 Raspberry Pi
 Fritzing
RASPBERRY PI ARCHITECTURE
RASPBERRY PI ARCHITECTURE
RASPBERRY PI 3 MODEL B TECHNICAL SPECIFICATIONS

 PROCESSOR
 Broadcom BCM2387 chipset.
 1.2GHz Quad-Core ARM Cortex-A53 (64Bit) 802.11 b/g/n Wireless LAN and Bluetooth 4.1
(Bluetooth Classic and LE)
 IEEE 802.11 b / g / n Wi-Fi. Protocol: WEP (Wired Equivalent Privacy), WPA (Wireless
Protected Access) WPA2, algorithms AES-CCMP (maximum key length of 256 bits), the
maximum range of 100 meters.
 IEEE 802.15 Bluetooth, symmetric encryption algorithm Advanced Encryption Standard
(AES) with 128-bit key, the maximum range of 50 meters.
 GPU
 Dual Core Video Core IV® Multimedia Co-Processor.
 Capable of 1Gpixel/s, 1.5Gtexel/s or 24GFLOPs with texture filtering and DMA infrastructure
 MEMORY
 1GB LPDDR2
 Boots from Micro SD card, running a version of the Linux operating system or Windows 10
RASPBERRY PI 3 MODEL B TECHNICAL SPECIFICATIONS
 POWER
 Micro USB socket 5V1, 2.5A
 CONNECTORS
 ETHERNET
 10/100 BaseT Ethernet socket

 VIDEO OUTPUT
 HDMI (rev 1.3 & 1.4)

 Composite RCA (PAL and NTSC)

 AUDIO OUTPUT
 Audio Output 3.5mm jack

 USB
 4 X USB 2.0 CONNECTOR

 GPIO CONNECTOR
 40-pin 2.54 mm (100 mil) expansion header: 2x20 strip

 Providing 27 GPIO pins as well as +3.3 V, +5 V and GND supply lines

 CAMERA CONNECTOR
 5-pin MIPI Camera Serial Interface (CSI-2) Display Connector

 Display Serial Interface (DSI) 15 way flat flex cable connector with two data lanes and a clock lane

 MEMORY CARD SLOT

 Push/pull Micro SDIO
RASPBERRY PI GPIO HEADER
HIGH LEVEL PROGRAMMING
 COMPILATION

 INTERPRETATION

 CROSS – COMPILATION
ARDUINO UNO
ARDUINO IDE
Name of current sketch
Main menus
Action buttons/icons
Verify (AKA compile)
Text area for Upload (send to Arduino)
writing/editing
sketches. Start a new sketch
Open a sketch (from a file)
Save current sketch (to a file)
Open Serial Monitor window

Error messages and other

feedback show up here.
ARDUINO IDE
USING PIR AS MOTION DETECTION
SENSORS
const int ledPin = 77; // pin for the LED
const int inputPin = 2; // input pin (for the PIR sensor)
void setup() {
pinMode(ledPin, OUTPUT); // declare LED as output
pinMode(inputPin, INPUT); // declare pushbutton as input
}
void loop(){
int val = digitalRead(inputPin); // read input value
if (val == HIGH) // check if the input is HIGH
{
digitalWrite(ledPin, HIGH); // turn LED on if motion
detected
delay(500);
digitalWrite(ledPin, LOW); // turn LED off
}
}
USING ULTRASONIC SENSORS
const int pingPin = 5;
const int ledPin = 7; // pin connected to LED
long microsecondsToCentimeters(long microseconds)
void setup()
{
{
// The speed of sound is 340 m/s or 29
Serial.begin(9600); microseconds per centimeter.

pinMode(ledPin, OUTPUT); // The ping travels out and back, so to find

the distance of the object we take half of the
} distance travelled.

void loop() return microseconds / 29 / 2;

{ }

long duration, cm;

pinMode(pingPin, OUTPUT);
digitalWrite(pingPin, LOW);
delayMicroseconds(2);
digitalWrite(pingPin, HIGH);
delayMicroseconds(5);
digitalWrite(pingPin, LOW);
pinMode(pingPin, INPUT);
duration = pulseIn(pingPin, HIGH);
// convert the time into a distance
cm = microsecondsToCentimeters(duration);
Serial.print(“Distance : “);
Serial.println(cm);
}
IoT DEPLOYMENT FOR RASPBERRY PI /
ARDUINO
CONTIKI OPERATING SYSTEM
 Contiki is an open source operating system for the Internet of Things.
 runs on networked embedded systems and wireless sensor nodes.
 It is designed for microcontrollers with small amounts of memory.
 A typical Contiki configuration is 2 kilobytes of RAM and 40 kilobytes
of ROM.
 Contiki provides IP communication, both for IPv4 and IPv6.
 It has an IPv6 stack that, combined with power-efficient radio
mechanisms such as ContikiMAC, allow battery-operated devices
to participate in IPv6 networking.
 Contiki supports 6lowPAN header compression and the CoAP
application layer protocol.
Source: http://www.contiki-os.org
CONTIKI- FUNCTIONAL
ASPECTS
 It’s kernel functions as an event-driven kernel; multithreading is
supported by an application library. In this sense it is a hybrid OS.

 The services communicate with each other through the kernel by

posting events.

 The ContikiOS kernel does not provide any hardware abstraction; but it
allows device drivers and application directly communicate with the
hardware.

 Each Contiki service manages its own state in a private memory space
and the kernel keeps a pointer to the process state.
OPERATING SYSTEM
OVERVIEW
THE CONTIKI OS

Loadable programs
Loaded program Can be easily updated

Communication service

Core Language runtime

Services Core: single binary
Program Loader Usually never modified

Kernel
PROTOTHREADS
 Protothreads can be seen as lightweight (stackless) threads.

 They can be also seen as interruptible tasks in event-based programming.

 A protothread provides a conditional blocking “wait” statement which takes a

conditional statement and blocks the protothread until the statement is
evaluated true.

 By the time the protothread reaches the wait time if the conditional
statement is true, it continues executing without any interruption.

 A protothread is invoked whenever a process receives a message from

another process or a timer event.
PROTOTHREADS- EXAMPLE
 For example consider a MAC protocol that turns off the radio subsystem on
a periodic basis; but you want to make sure that the radio subsystem
completes the communication before it goes to sleep state.
1. At t=t0 set the radio ON
2. The radio remains on for a period of tawake seconds
3. Once tawake is over, the radio has to be switched off, but any on-going
communication needs to be completed.
4. If there is an on-going communication, the MAC protocol will wait for a
period, twait_max before switching off the radio.
5. If the communication is completed or the maximum wait time is over,
then the radio will go off and will remain in the off state for a period of
tsleep.
6. The process is repeated.
RADIO SLEEP CYCLE CODE WITH
EVENTS Event driven code can be messy and
complex
THE CONTIKI CODE
Header files
#include "contiki.h"

Defines the name of

PROCESS(sample_process, "My sample process");
the process

AUTOSTART_PROCESSES(&sample_process);
Defines the process
will be started every
PROCESS_THREAD(sample_process, ev, data) {
time module is loaded
PROCESS_BEGIN();
while(1) {
PROCESS_WAIT_EVENT(); contains the process
code
}
PROCESS_END();

Threads must have an process can receive data

Event parameter; process during an event
can respond to events
end statement
PROTOCOLS SUPPORTED BY
CONTIKI
 Contiki supports standard protocols and recent enabling protocols for IoT

 uIP (for IPv4) − This TCP/IP implementation supports 8-bit and 16-bit
microcontrollers.
 uIPv6 (for IPv6) − This is a fully compliant IPv6 extension to uIP.
 Rime − This alternative stack provides a solution when IPv4 or IPv6 prove
prohibitive. It offers a set of primitives for low-power systems.
 6LoWPAN − This stands for IPv6 over low-power wireless personal area
networks. It provides compression technology to support the low data rate
wireless needed by devices with limited resources.
 RPL − This distance vector IPv6 protocol for LLNs (low-power and lossy
networks) allows the best possible path to be found in a complex network of
devices with varied capability.
 CoAP − This protocol supports communication for simple devices, typically
devices requiring heavy remote supervision.
COOJA EMULATOR
 EMULATOR
 An emulator is a hardware or software system that enables one computer
system (called the host) to behave like another computer system (called
the guest): e.g. Cooja enabling your laptop to behave like a Z1 mote.

 A system that typically enables the host system to run software or use
peripheral devices designed for the guest system: e.g. Cooja enabling your
laptop to run the RPL protocol, LIBP and/or other IoT protocols of interest.

 SIMULATOR
 A system designed to recreate the operation or behaviour of the guest
system. The underlying principles can be the same as the original or
different.
COOJA EMULATOR
 Cooja is a Contiki network emulator
 An extensible Java-based simulator capable of emulating motes or and other nodes.
 The code to be executed by the node is the exact same firmware you may upload
to physical nodes
 Allows large and small networks of motes to be simulated
 Motes can be emulated at the hardware level
 Slower but allows for precise inspection of system behaviour
 Motes can also be emulated at a less detailed level
 Faster and allows simulation of larger networks
 Cooja is a highly useful tool for Contiki development
 It allows developers to test their code and systems long before running it on the
target hardware
 Developers regularly set up new simulations to
 debug their software
 to verify the behaviour of their systems
CLUSTERIN
G
CLUSTERING
 The management of an escalating number of connected
devices, increasing autonomy and relatively limited
capabilities of the devices impose many challenges such as
routing, energy consumption and security.
 One solution to the problem is Clustering. With clustering, a
set of nodes are grouped together to form a cluster. Each
cluster has an elected Cluster Head (CH) which takes care of
routing of the traffic originated from the entire network.
 While the clustering in MANET aims largely on network
reliability and node access, the clustering in WSNs and
Internet of Things aims at energy consumption, load
balancing, reduced packet delays and increased connectivity.
CLUSTERING FOR SCALABILITY
CLUSTERING PRINCIPLES IN AN IoT ARCHITECTURE
 A clustering design for the Internet of Things requires the use of active
networking to create collaborative, multi-hop and always-dynamic
interactions among objects, which are equipped with wireless embedded
devices.
 Clustering protocols specify the topology of the hierarchical non-
overlapping clusters of sensor nodes. A robust clustering technique is
essential for self-organizing sensor networks.
 The characteristics of Active Networking are
 Multi-hop communication
 Cooperative applications
 Events triggered inside the network.
 A clustering design for the Internet of Things requires the use of active
networking to create collaborative, multi-hop and always-dynamic
interactions among objects, which are equipped with wireless embedded
devices.
CLUSTERING FOR SCALABILITY
CLUSTERING PRINCIPLES IN AN IoT ARCHITECTURE
 With in-network processing, the devices can now report their status to the head of the
cluster using multi-hop communication .
 Active networking also creates the possibility of extending the information of an object
by using other nearby object’s information to enrich its status. Each node can create a
data structure containing the information about its neighbors and pass on to the
cluster head thereby maintaining a real-time repository of network and object
information.
 Since the nodes in the IoT network will operate for months and years with the same
battery charge, energy should be preciously used. With clustering nodes will perform
only in-network processing. The elected cluster head (CH)collects all the
communication within the network (data aggregation)and forwards it to the outside or
external networks. But, this model will exhaust the CH nodes and hence they need to
be periodically rotated.
 The selection is based on the dynamic characteristics of the node such as residual
energy and radio range or computational power. The CH selection should be made
based on the distributed and collaborative mode as the centralized modes are not
feasible with the scalability offered by IoT where clusters are formed by hundreds and
CLUSTERING FOR SCALABILITY
DESIGN GUIDELINES – Addressing and Routing

 Dynamic address allocation is a common problem for wireless ad-hoc networks where
mobile nodes constantly join and leave the network.
 One of the main challenges in the mobile object networks of the Internet of Things is
the support for dynamic associations of objects.
 The purpose of considering dynamic association of objects is to provide a flexible
solution in which the network members do not need to be known in advance. This
helps in making the network suitable for any kind of applications.
 The following requirements for an Internet of Things addressing scheme:
 Addresses must be unique inside a network
 Addresses must be reused when objects leave
 Addressing must be dynamic. Address assignation should be fully distributed
 Addressing must be scalable
 Support for network merge and split should be provided
 The protocol overhead must be minimized
CLUSTERING FOR SCALABILITY
DESIGN GUIDELINES – Ideal Properties of Addressing Schemes

 Hierarchical: The nodes involved in this addressing scheme are the devices that represent
objects. Nodes receive addresses organized in a tree structure. When two or more objects
associate, the object that computes an address becomes a parent. Hence, senders of association
requests become children.
 Distributed and unique: Each node should be only responsible for assigning addresses to its
children. The address a child receives should be derived from its parent address in a way that
makes that address unique for the network.
 Scalable: If a node leaves a group, its address should become automatically available for any
other node joining with the same parent. Moreover, the addresses should not be limited in size
by the scheme, but rather increase their size as the network becomes bigger. Network merges
should also be supported by reassigning the addresses of the network with the smallest number
of nodes.
 Low overhead: A parent should only need to know its immediate children to assign addresses in
a unique manner. Hierarchical assignation of addresses should allow parents to provide shortcuts
to the destination in an equally simple way by routing packets to neighbors that are closer to the
destination than following the tree.
 Extensible: The addressing scheme should provide mechanisms to allow an unlimited number
of children per parent even if the original limits for address space assignation per parent have
LEACH
 LEACH (Low-Energy Adaptive Clustering Hierarchy), a clustering-based protocol that
minimizes energy dissipation in sensor networks.
 LEACH outperforms classical clustering algorithms by using adaptive clusters and
rotating cluster-heads, allowing the energy requirements of the system to be distributed
among all the sensors.
 LEACH is able to perform local computation in each cluster to reduce the amount of data
that must be transmitted to the base station.
 LEACH uses a CDMA/TDMA MAC to reduce inter-cluster and intra-cluster collisions.
 Sensors elect themselves to be local cluster-heads at any given time with a certain
probability.
 Each sensor node joins a cluster-head that requires the minimum communication energy.
 Once all the nodes are organized into clusters, each cluster-head creates a transmission
schedule for the nodes in its cluster.
 In order to balance the energy consumption, the cluster-head nodes are not fixed. This
position is self-elected at different time intervals.
LEACH
100 m
叢 集 區

觀 測 區 域

~100m

Sensor (Non Cluster Head)

Sensor (Cluster Head)
Initial Data
Aggregated Data

Base Station
LEACH: Adaptive Clustering
 Periodic independent self-election
 Probabilistic

 CSMA MAC used to advertise

 Nodes select advertisement with strongest signal
strength
 Dynamic TDMA cycles
LEACH Algorithm
 Periodic process
 Two phases per round:
 Setup phase
 Advertisement: Execute election algorithm
Members join to cluster
Cluster-head broadcasts schedule

 Steady-State phase
Data transmission to cluster-head using TDMA
Cluster-head transfers data to BS (Base Station)
LEACH Algorithm
LEACH Algorithm
 Set-up phase
 Node n choosing a random number m between 0 and 1
 If m < T(n) for node n, the node becomes a cluster-head where

 P
 if n  G
T ( n )  1  P [ r * mod(1/ P )]
0 otherwise ,


 where P = the desired percentage of cluster heads (e.g., P= 0.05), r=the current
round, and G is the set of nodes that have not been cluster-heads in the last 1/P
rounds. Using this threshold, each node will be a cluster-head at some point within 1/P
rounds. During round 0 (r=0), each node has a probability P of becoming a cluster-
head.
LEACH Algorithm
 Set-up phase
 Cluster heads assign a TDMA schedule for their members where
each node is assigned a time slot when it can transmit.
 Each cluster communications using different CDMA codes to
reduce interference from nodes belonging to other clusters.
 TDMA intra-cluster
 CDMA inter-cluster
 Spreading codes determined randomly
 Broadcast during advertisement phase
LEACH Algorithm
 Steady-state phase
 All source nodes send their data to their cluster heads
 Cluster heads perform data aggregation/fusion through local
transmission
 Cluster heads send aggregated data back to the BS using a
single direct transmission
LEACH Algorithm
 Advantages
 Increases the lifetime of the network
 Even drain of energy

 Distributed, no global knowledge required

 Energy saving due to aggregation by CHs
 Disadvantages
 LEACH assumes all nodes can transmit with enough power to
reach BS if necessary (e.g., elected as CHs)
 Each node should support both TDMA & CDMA
 Need to do time synchronization
 Nodes use single-hop communication
END OF UNIT - 4