Tomorrow’s Workforce: Surfing for solutions Tomorrow’s Workforce: Surfing for Solutions.
Tomorrow’s Internet of Things: Latest Standardization Trends and · PDF fileBuilding...
Transcript of Tomorrow’s Internet of Things: Latest Standardization Trends and · PDF fileBuilding...
Building Tomorrow’s Internet of Things:
Latest Standardization Trends and
Hands‐on Programming Tutorial
Dr. Thomas Watteyne Berkeley Sensor and Actuator Center
University of California, Berkeley
WCNC 2010, Sydney
18 April 2010
Building Tomorrow’s Internet of Things: Latest Standardization Trends andHands-on Programming Tutorial
Dr. Thomas WatteyneBerkeley Sensor and Actuator Center
University of California, Berkeley
WCNC, 18 April 2010
2
Outlook
1. Introduction to Sensor Networks
2. Industrial Developments
3. Towards A Standards-Based Stack
4. IoT in Practice
5. Programming Tour
3
Acknowledgments
• Some slides and the contents of some slides have been either entirely or partially reproduced with thanks from:
– Mischa Dohler, CTTC, Spain
– Kris Pister, UC Berkeley, USA
– Abdelmalik Bachir, Imperial College, UK
– Zach Shelby, Sensinode, Finland
– IETF ROLL presentations
– companies’ websites
• Thanks to Texas Instruments for providing the eZ430-RF2500 kits– Cathy Wicks
– Robert Owen
– Jacob Borgeson
4
Installation Required! [1/5]
Step 0: Requirements
• A laptop running Windows (XP preferred)
• An eZ430-RF2500 kit
5
Installation Required! [2/5]
Step 1: eZ430-RF2500 Sensor Monitor Demo
While we will never run the Sensor Monitor (a graphical interface to the Texas Instruments Sensor Monitor Demo), installing this is the quickest way of installing the driver for Windows to understand the eZ430-RF2500 connected to your computer.
• Download the eZ430-RF2500 Sensor Monitor Demo from http://www.ti.com/ (currently revision C, 3MB)
• Unzip that file and run Sensor Monitor Installer.exe
• Use default configurations during installation
• Do not keep the Sensor Monitor program running after the install, as it will interfere with the other tools we will be using
6
Installation Required! [3/5]
Step 2: IAR Kickstart for MSP430
IAR is the tool used to program the eZ430-RF2500 boards. Kickstart is the free edition, which can compile binary code up to 4kB in size. For larger sizes (not used in this tutorial), you need to buy the full version of IAR.
• Download the latest IAR Embedded Workbench kickstart edition for MSP430 from http://www.iar.com/ (currently version 4.21, 106MB)
• Use the default configuration settings during installation
7
Installation Required! [4/5]
Step 3: PuTTY
PuTTY is used to read from the serial COM port created when the eZ430-RF2500 board is connected to the host computer.
• Download http://the.earth.li/sgtatham/putty/latest/x86/putty.exe (currently release 0.60, 444kB)
• There is no installation needed, double-clicking should start the application
8
Installation Required! [5/5]
Step 4: Python and PySerial
We will use Python scripts to interface our laptops with the eZ430-RF2500.
• Download and install Python from http://www.python.org/, versions 2.5.4 and 2.6.4 are known to work
• Download and install PySerial (which allows Python to connect to a serial, or COM, port) from http://pyserial.sourceforge.net/,pyserial-2.5-rc1.win32.exe is known to work
1
Thomas Watteyne @ WCNC 2010
1. Introduction to Sensor Networks
2
Section 1 - Overview
1. Introduction to Sensor Networks1.1 From Smart Dust to Smart Plants
1.2 Applications
1.3 The Nature of Wireless
1.4 Conclusions
Thomas Watteyne @ WCNC 2010
3
Thomas Watteyne @ WCNC 2010
1.1 From Smart Dust to Smart Plants
4
The Promise of Wireless
time
$
sensing
computation
communication
Thomas Watteyne @ WCNC 2010
5
The Promise of Wireless
time
size
power
cost
Thomas Watteyne @ WCNC 2010
6
1997, the Smart Dust vision
Thomas Watteyne @ WCNC 2010
7
1999, Optical Communication
Thomas Watteyne @ WCNC 2010
8
Off-the-Shelf Hardware
Thomas Watteyne @ WCNC 2010
9
2001, Intel Developers Forum
• 800 motes
• 8-level dynamic network
Thomas Watteyne @ WCNC 2010
10
2001, 29 Palms Demo
Thomas Watteyne @ WCNC 2010
11
S. Oh et al, "Tracking and coordination of multiple agents using sensor networks: system design, algorithms and experiments," Proc. of the IEEE, 2007.S. Kim et al, “Health Monitoring of Civil Infrastructures Using Wireless Sensor Networks,” IPSN, Cambridge, MA, April 2007A. Ledezci, http://www.isis.vanderbilt.edu/projects/countersniperJ. Lees et al, “Reventador Volcano 2005: Eruptive Activity Inferred from Seismo-Acoustic Observation”, Jnl, of of Volcanology and Geothermal Research, 2007
Wireless Sensor Networks
Sensor Networks for SecurityStructural Monitoring
Sniper Localization
Environmental Monitoring
Thomas Watteyne @ WCNC 2010
12
Thomas Watteyne @ WCNC 2010
1.2 Applications
13
We all agree…
Thomas Watteyne @ WCNC 2010
14
Building Monitoring
• UC Berkeley’s Center for Built Environment
• Seismic testing demo: real-time data acquisition
• hundreds of sensors on 3 floors
• wiring cost by far outweighs sensor cost.
• $200 vs. $5,000 per node in a wireless version.
• A few days installation(vs. weeks)Thomas Watteyne @ WCNC 2010
15
Habitat Monitoring
• Overview– Study the Leach's Storm Petrel's Habitat
– UC Berkeley, Prof. Dave Culler
– Deployed during summer 2002 for 4 months on an uninhabited island 15km off the coast of Maine, USA
• Platform– 43 mica motes
– TinyOS
– Humidity, pressure, temperature, light, IR radiation
• Networking– Transmit-only nodes
– One transmission every 70 seconds
– 1.7% duty cycle
– Simple CSMA MAC
Thomas Watteyne @ WCNC 2010
16
Precision Agriculture• Overview
– Micro-climate study in a potato field
– Delft U. Technology, Prof. Langendoen
– Deployed during Summer 2005 for 3 months in a potato field in Holland
• Platform– 100 motes (AtMega128L, CC1000)
– TinyOS
– Humidity, temperature
• Networking– T-MAC
– Single-hop (Mint routing)
– 11% duty cycle
Thomas Watteyne @ WCNC 2010
17
Automated Meter Reading• Overview
– Urban-wide Water Meter Reading
– Coronis Systems, Elster group
– Deployed since 2005 in Sable-d'Olonne, France
• Platform– 25,000 proprietary nodes
• Networking– Static routing tree
– Parent association done at deployment
– 10+ years (<.1% duty cycle)
Thomas Watteyne @ WCNC 2010
18
Building Automation
Smart Grid Applications
IndustrialAutomation
Industrial Applications
Thomas Watteyne @ WCNC 2010
19
Thomas Watteyne @ WCNC 2010
1.3 The Nature of Wireless
20
Costs in Wireless Sensor Networks
Operation Time PowerEnergy
RequiredTechnology
Fill a packet with analog samples
1 s 0.025 mW 25 µJMSP430 @ 4 MHz,
80 Samples
Transmit or Receive a packet
0.006 s 50 mW 400 µJ CC2420
2.5 mJ to generate and pass this packet along100x more than to build it
Thomas Watteyne @ WCNC 2010
21
Reliability
Reliability is challenged by:• external interference• multi-path fading
Thomas Watteyne @ WCNC 2010
22
External Interference
Thomas Watteyne @ WCNC 2010
23
First Challenge: External Interference
IEEE802.11(Wi-Fi)IEEE802.15.1(Bluetooth)IEEE802.15.4(ZigBee)
Thomas Watteyne @ WCNC 2010
24
Typical Tx power
• IEEE802.11-2007: 100mW
• IEEE802.15.4-2006: 1mW
First Challenge: External Interference
2.4 GHz
Channels 11-26
2.4835 GHz
5 MHz
2.4 GHz PHY
Thomas Watteyne @ WCNC 2010
25
IEEE802.11b/g/nIEEE802.11a/n
First Challenge: External Interference
868 MHz
433 MHz
2.4 GHz 5 GHz
IEEE802.15.4
Thomas Watteyne @ WCNC 2010
26
First Challenge: External Interference
• 45 motes*
• 50x50m office environment
• 12 million packets exchanged, equaly over all 16 channels
*data collected by Jorge Ortiz and David Culler, UCBPublicly available at wsn.eecs.berkeley.edu
Thomas Watteyne @ WCNC 2010
27
Second Challenge: Multipath Fading
Thomas Watteyne @ WCNC 2010
28
Second Challenge: Multipath Fading
• Separate sender and receiver by 100cm
• Have sender send bursts of 1000 packets
• Have receiver count the number of received packets
• Move transmitter around in a 20cmx35cm square and start over
Thomas Watteyne @ WCNC 2010
29
Second Challenge: Multipath Fading
ch.11Thomas Watteyne @ WCNC 2010
30
Second Challenge: Multipath Fading
ch.11 ch.12
0% reliability 100% reliability
Thomas Watteyne @ WCNC 2010
31
Second Challenge: Multipath Fading
ch.11
ch.13
ch.15
ch.17
ch.12
ch.14
ch.16
ch.18
ch.19
ch.21
ch.23
ch.25
ch.20
ch.22
ch.24
ch.26
changing channel improves performance
Thomas Watteyne @ WCNC 2010
32
Taking A Real-World Example
• Doherty, Lindsay, Simon. “Channel-Specific Wireless Sensor Network Path Data”, ICCCN 2007.
• 44 nodes, 26 days
Thomas Watteyne @ WCNC 2010
Thomas Watteyne @ WCNC 2010
Thomas Watteyne @ WCNC 2010
Thomas Watteyne @ WCNC 2010
36
Pathloss
0 50 100 150 200 250 300-100
-90
-80
-70
-60
-50
-40
-30
-20
distance in feet
RS
SI (
dBm
) RSSI does not give an indication
about distance
Thomas Watteyne @ WCNC 2010
37
Stability over all paths, all channels
Thomas Watteyne @ WCNC 2010
38
2.405 GHz
2.480 GHz
802.
15.4
Cha
nnel
s
802.
11bg
Cha
nnel
s
* each dot represents 15 minutes
Stability over all paths, all channels
Thomas Watteyne @ WCNC 2010
39
Stability over all paths, all channels
Thomas Watteyne @ WCNC 2010
40
Stability over all paths, all channels
Thomas Watteyne @ WCNC 2010
41
Thomas Watteyne @ WCNC 2010
1.4 Conclusions
42
Conclusions
• Research– many network degrees of freedom, hence a lot of work
– focus is on intra wireless sensor network communication
– impact era has passed but numerous problems are still open
• Development– keep it simple and tailor to required application
– focus is on communication between WSN and Internet
– impact era is yet to come
• Business– WSN promise significant financial cost savings
– business takes off slower than anticipated due to various reasons
Thomas Watteyne @ WCNC 2010
1
Thomas Watteyne @ WCNC 2010
2. Industrial Developments
2
Section 2 - Overview
2. Industrial Developments2.1 The Promise of Wireless
2.2 Standardization Bodies
2.3 Startups
2.4 Conclusions
Thomas Watteyne @ WCNC 2010
3
Thomas Watteyne @ WCNC 2010
2.1 The Promise of Wireless
4
The Promise of Wireless
Thomas Watteyne @ WCNC 2010
90%?
time
$
sensors
computation &communication
installation, connection,
commissioning
wired cost
reduced wiring cost
traditional wireless
wireless mesh
networking
5
Barriers to Adoption
Thomas Watteyne @ WCNC 2010
* source: OnWorld, 2005
Reliability
Standards
Ease of use
Power consumption
Development cycles
Node size
0% 20% 20% 60% 80% 100%
6
Interoperability Issues
Thomas Watteyne @ WCNC 2010
The Internet
7
Thomas Watteyne @ WCNC 2010
2.2 Standardization Bodies
8
What are Standards?
• Normative standardization documents are– elaborated by a community
– publicly available without any discriminatory conditions
– published by Standards Developing Organizations (SDOs)
• SDO (Standards Developing Organization):– publish standards which
– rely upon national or international regulations
• Further facts about standards:– pushed for by consortia or forums
– popularity is reflected by the market
– serve as references for compliance purposes
Thomas Watteyne @ WCNC 2010
9
Benefit of Standards
• Service Providers benefit because– they can design, develop and operate a wide range of services
– whatever the underlying but standard-compliant, heterogeneous technologies
• Vendors benefit because – they can access markets more easily with standard-compliant products
– proprietary technologies are restricted to niche markets (at best)
– at the risk of blurring competitive differentiation
• Customers benefit because – they can access a wide range of services
– without the burden of being tied to a given service provider or technology
Thomas Watteyne @ WCNC 2010
10
Corporate View
• Standardization as a profitable business:– defend business stakes
– promote patents through the enforcement of a consistent IPR policy
• Standardization as a decision-making tool:– privileged space for consolidating and developing leadership positions
• Speed up the introduction of new products and/or services:– facilitated by a set of available standards
• Slow down the standardization process:– to extend the lifetime of an already-introduced yet proprietary product or service
Thomas Watteyne @ WCNC 2010
11
Regulatory View
• Technology space is very complex:– stringent regulations are hence needed
– to facilitate control and possible billing (e.g. UMTS spectrum license)
• Standards serve as the technical references for regulation rules:– European directives and derived domestic laws
– part of the legal resolution of conflicts between competitors
– and/or customers and service providers
• Part of the corporate strategy:– corporate solutions evolve in a regulated manner
– mainly if regulators see a (financial) opportunity
Thomas Watteyne @ WCNC 2010
12
Standardization Bodies
• Standards Developing Organization bodies can be – international (e.g. ITU-T, ISO, IEEE),
– regional (e.g. ANSI, ETSI), or
– national (e.g. CCSA)
• Standardization efforts pertinent to WSNs are:– IEEE (link and physical layer solutions)
– ETSI (complete M2M solutions)
– ISA (regulation for control systems)
– IETF (routing and network solutions)
Thomas Watteyne @ WCNC 2010
13
IEEE – Overview
• Institute of Electrical and Electronics Engineers:– is one of the leading standards-making organizations in the world
– Standardization through IEEE Standards Association (IEEE-SA)
• IEEE standards affect a wide range of industries: – power and energy
– biomedical and healthcare
– information technology
– telecommunications
– transportation
– nanotechnology, etc.
• IEEE has close to 900 active standards, with 500 standards under development.
Thomas Watteyne @ WCNC 2010
14
IEEE – The 802 “soup”• 802.1 High Level Interface (HILI) Working Group
• 802.3 CSMA/CD (Ethernet) Working Group
• 802.11 Wireless LAN (WLAN) Working Group
• 802.15 Wireless Personal Area Network (WPAN) Working Group– TG1 – WPAN, Bluetooth
– TG3c - mmWave
– TG4c - WPAN Alternative PHY for China
– TG4d - WPAN Alternative PHY for Japan
– TG4e - WPAN Enhancements
– TG4f - RFID
– TG4g - Smart Utility Neighborhood
– TG5 - WPAN Mesh Networking
– TG6 - Body Area Networks
– TG7 - Visible Light Communication
– IGthz - Interest Group Terahertz
– WNG - Standing Committee Wireless Next Generation
• 802.16 Broadband Wireless Acces s (BWA) Working Group
• 802.17 Resilient Packet Ring (RPR) Working Group
• 802.18 Radio Regulatory Technical Advisory Group
• 802.19 Coexistence Technical Advisory Group
• 802.20 Mobile Broadband Wireless Acces s Working Group
• 802.21 Media Independent Handover Working Group
• 802.22 Wireless Regional Area Networks Working GroupThomas Watteyne @ WCNC 2010
15
IEEE – WSN Related Standards
• The IEEE usually standardizes:– PHY layer of the transmitter
– MAC protocol rules
• The following IEEE standards are applicable to WSNs:– IEEE 802.15.4 (technology used by ZigBee and IETF 6LowPan)
– IEEE 802.15.1 (technology used by Bluetooth/WiBree)
– IEEE 802.11x (technology used by WiFi)
• Some facts and comments:– IEEE 802.15.4 has been the obvious choice but will get
– serious competition from ultra-low power (ULP) IEEE 802.15.1 (WiBree)
– low power IEEE 802.11 solutions are emerging (e.g. Marvell)
Thomas Watteyne @ WCNC 2010
16
IETF – Overview
• Internet Engineering Task Force:– formed in 1986
– not approved by the US government
– composed of individuals, not companies
– quoting the spirit: “We reject kings, presidents and voting. We believe in rough consensus and running code.” D. Clark, 1992
• Quick overview on the IETF:– meets 3 times a year, and gathers an average of 1,300 individuals
– more than 120 active working groups organized into 8 areas
– IETF management (including area directors) is chosen by the community
Thomas Watteyne @ WCNC 2010
17
IETF – Overview
• General scope of IETF:– above the wire/link and below the application
– TCP/IP protocol suite: IP, TCP, routing protocols, etc.
• However, layers are getting fuzzy:– MAC & application layers influence routing in WSN
– hence a constant exploration of "edges"
• Some curiosities:– there is no formal recognition for IETF standards by governments or SDOs
– IETF publications are very interesting for SDOs because of quick implementation
Thomas Watteyne @ WCNC 2010
18
IETF – WSN Related Standards
• IETF 6LoWPAN [2005]– add IPv6 capabilities to wireless sensors
– end-to-end connectivity to/from the Internet
• IETF ROLL [2007]– identify application domains
– define a routing protocol for Wireless Sensor Networks
• IETF 6LoWApp [2009]– what goes on top of IP?
– brand new…
Thomas Watteyne @ WCNC 2010
19
Thomas Watteyne @ WCNC 2010
2.3 Startups
20
Dust Networks [US]
• Dust Networks facts:– founded in 2002 by industry pioneer Prof. Kris Pister, Berkeley, USA
– vision of a world of ubiquitous sensing – a world of connected sensors scattered around like specs of dust, or smart dust, gathering information economically and reliably, that had previously been impractical or impossible to acquire
– inventors of TSMP which are used in ISA100, Wireless HART and IEEE 802.15.4E
– emphasis on industrial control
Thomas Watteyne @ WCNC 2010
21
Arch Rock [US]
• Arch Rock facts:– founded in May 2005 with a vision of providing a high quality, seamless integration of the
physical and virtual worlds that would enhance the information awareness of the individual and the enterprise
– company builds upon a decade of research at the University of California, Berkeley and Intel Research by David Culler et al.
– founder of a new operating system, TinyOS and Berkeley Mote, for small wirelessly connected computers that sense the physical environment and form vast embedded networks; emphasis on environmental monitoring & ind. control
Thomas Watteyne @ WCNC 2010
22
Crossbow [US]
• Crossbow facts:– Global Leader in Sensory Systems; founded in 1995 by Mike Horton
– Products MEMS-Based Inertial Systems & Wireless Sensor Networking
– World-Wide Employee Base; Headquartered in San Jose, CA
– $25M in Venture Capital
– Cisco Systems, Intel Corporation, Morgenthaler Ventures, Paladin Capital
– emphasis on asset management & tracking
Thomas Watteyne @ WCNC 2010
23
Coronis/Elster [FR, US]
• Coronis, France, (now bought by Elster, USA) in short:
Thomas Watteyne @ WCNC 2010
24
Sensinode [FI]
• Sensinode facts:– leader in IP-based wireless sensor network (WSN) technology
– 1st on the market with a 6lowpan stack
– 6lowpan products and services: 6lowpan Devkits, Network Products, NanoStack 6lowpan Stack
– Engineering Services
– Sensinode is headquartered in Finland
– A 2005 spin-off of the University of Oulu, Finland based on a decade of research
Thomas Watteyne @ WCNC 2010
25
etc.
Thomas Watteyne @ WCNC 2010
Adurahttp://www.aduratech.com/
Berkeley Lighting control
Arch Rockhttp://www.archrock.com/
Berkeley
Elster Coronishttp://www.coronis.com/
Montpellier, France Automated Meter Reading
Crossbowhttp://www.xbow.com/
Berkeley
Dust Networkshttp://www.dustnetworks.com/
Berkeley Industrial Automation
Emberhttp://www.ember.com/
MIT
Federspiel Controlshttp://www.federspielcontrols.com/
Berkeley HVAC
Libeliumhttp://www.libelium.com/
Zaragoza, Spain
Maxforhttp://www.maxfor.co.kr/
Seongnam, South Korea
Millenial Nethttp://www.millennial.net/
MIT Smart Energy
Sensicast Systemshttp://www.sensicast.com/
Pinpoint
Sensinodehttp://www.sensinode.com/
Oulu, Finland
Sensys Networkshttp://www.sensysnetworks.com/
Berkeley Traffic light sensor
Sentilla (was MoteIV)http://www.sentilla.com/
Berkeley
Skywise Systemshttp://www.skywisesystems.com/
Beijing, China
Smartgrainshttp://www.smartgrains.com/
Paris, France Smart Parking
Streetline Networkshttp://www.streetlinenetworks.com/
Berkeley Smart Parking
26
Thomas Watteyne @ WCNC 2010
2.4 Conclusions
27
Conclusions
• The Past– loads of proprietary wireless solutions have been mushrooming over past decade
– no or little inter-operability between these solutions
– danger of de-fragmented market is a reality
• The Present– proprietary solutions are still being developed and pushed for
– however, standardization is wrapping up at all layers of the stack
• The Future– integration of the to-be-finalized standards
– realization of Internet-of-Things
Thomas Watteyne @ WCNC 2010
1
Thomas Watteyne @ WCNC 2010
3. Towards A Standards-Based Stack
2
Application OpenADR, XML
Transport TCP, UDP
routingIETF RPL
IETF 6LoWPAN
MAC IEEE 802.15.4E
PHY IEEE 802.15.4-2006
Protocol Stack
Thomas Watteyne @ WCNC 2010
IETF
IEE
E
3
Section 3 - Overview
3. Towards A Standards-Based Stack3.1 IEEE 802.15.4E
3.2 IETF 6LoWPAN
3.3 IETF RPL
3.4 OpenWSN
3.5 Conclusions
Thomas Watteyne @ WCNC 2010
4
Thomas Watteyne @ WCNC 2010
3.1 IEEE802.15.4E
5
15.4-2006, 15.4 PHY, 15.4 MAC, 15.4E?
• IEEE 802 LAN/MAN Standards Committee– standardizes a.o. 802.3 (Ethernet) 802.11
– http://www.ieee802.org/
• IEEE 802.15 Working Group for WPAN– wireless Personal Area Network
– standardizes a.o. 802.15.1 (Bluetooth), 802.15.4
– http://www.ieee802.org/15/
• IEEE 802.15 WPAN Task Group 4– low data rate solution with multi-month to multi-year battery life, very low complexity
– operating in an unlicensed, international frequency band
– sensors, interactive toys, smart badges, remote controls, and home automation, etc.
– first standard in 2003, updated in 2006
– standardizes both PHY and MAC
– http://www.ieee802.org/15/pub/TG4.html
• IEEE 802.15 WPAN Task Group 4e– define a MAC amendment to the existing standard 802.15.4-2006
– enhance and add functionality to the 802.15.4-2006 MAC to better support the industrial markets
– uses 802.15.4-2006 PHY
– draft standard on 03/08/2010, integrated in next revision of the 802.15.4 standard (exp. 2011)
– http://www.ieee802.org/15/pub/TG4e.html
Thomas Watteyne @ WCNC 2010
6
IEEE802.15.4 – Overview
• Emphasis of IEEE 802.15.4 is:– low-cost, low-speed ubiquitous communication between nearby devices with little to
no underlying infrastructure– basic framework assumes 10-meter communications area @ 250 kbit/s– lower transfer rates of 20, 40 and 100 kbit/s are now considered too– to meet embedded constraints, several PHY layers are available
• Key technology features are: – real-time suitability by reservation of guaranteed time slots– collision avoidance through CSMA/CA– integrated support for secure communications (128-bit AES encryption)– power management functions such as link quality and energy detection– 16 channels in ISM bands for operation, i.e. 868-868.8 MHz (Europe), 902-928 MHz
(North America), 2400-2483.5 MHz (worldwide)– star and mesh topologies can theoretically be built– support for low-latencies and dynamic device addressing
Thomas Watteyne @ WCNC 2010
7
IEEE802.15.4 – PHY Layer
• The 2006 revision of the standard defines 4 PHY layers:– 868/915 MHz DSSS with binary phase shift keying (BPSK)
– 868/915 MHz DSSS with offset quadrature phase shift keying (OQPSK)
– 2450 MHz DSSS with offset quadrature phase shift keying (OQPSK)
– 868/915 MHz PSSS, i.e. combination of binary keying and amplitude shift keying
• The 2007 IEEE 802.15.4a version includes 2 PHY layers more:– Chirp Spread Spectrum (CSS) @ 2450 MHz ISM
– Direct Sequence Ultra-wideband (UWB) @ < 1GHz, 3-5GHz, 6-10 GHz
• Beyond these PHYs at the three bands, there are:– IEEE 802.15.4c for 314-316, 430-434 and 779-787MHz bands in China
– IEEE 802.15.4d for 950-956MHz band in Japan
Thomas Watteyne @ WCNC 2010
8
IEEE802.15.4 – PHY Layer
• binary phase shift keying (BPSK)
• quadrature phase shift keying (QPSK)
• offset quadrature phase shift keying (OQPSK)
Thomas Watteyne @ WCNC 2010
9
IEEE802.15.4 – 2.4GHz PHY
• O-QPSK, 250 kb/s, 62.5 ksymbol/s
• Direct Sequence Spread Spectrum
• Max PSDU = 127B
• Turnaround: TX-RX ≤ RX-TX ≤ 192us
• ED over 8 symbol periods
DSSS: 4 bits of information = 32 chips(raw data rate of 2Mbps)
Thomas Watteyne @ WCNC 2010
10
IEEE802.15.4 – MAC Layer
• Some key attributes:– CSMA/CA channel access– manages access to the physical channel and network beaconing– controls frame validation, guarantees time slots, handles node associations– offers hook points for secure services
• In more details:– networks which are not using beaconing mechanisms utilize an un-slotted variation
which is based on the listening of the medium, leveraged by a random exponential backoff algorithm (acknowledgments do not adhere to this discipline)
– confirmation messages may be optional under certain circumstances, in which case a success assumption is made; timeout-based retransmission can be performed a number of times
– due to the maximization of battery life, the protocols tend to favor methods implementing periodic checks for pending messages, the intensity of which depends on application needs
Thomas Watteyne @ WCNC 2010
11
IEEE802.15.4 – MAC Layer
• There are two general channel access methods:
• Non-Beacon Network:– simple, traditional multiple access system used in simple peer networks– standard CSMA conflict resolution– positive acknowledgement for successfully received packets
• Beacon-Enabled Network– can be used in beacon-request mode without superframes– superframe structure - network coordinator transmits beacons at predetermined
intervals– dedicated bandwidth and low latency– low power consumption mode for coordinator
Thomas Watteyne @ WCNC 2010
12
IEEE802.15.4 – MAC Layer
• Super-Frame Structure for Beacon-Enabled Mode:
Thomas Watteyne @ WCNC 2010
13
IEEE802.15.4 – Packet Format
Thomas Watteyne @ WCNC 2010
4B of data(all 0’s) 0x7A
0-127
synchronization header physical header
MAC header
16-bit CRC
beacon, ACK, DATA, command
14
IEEE802.15.4 – Device Classes
• Full function device (FFD)– any topology
– network coordinator capable
– talks to any other device
• Reduced function device (RFD)– limited to star topology
– cannot become a network coordinator
– talks only to a network coordinator
– very simple implementation
Thomas Watteyne @ WCNC 2010
15
Full function device
Reduced function device
Communications flow
Master/Slave
PANCoordinator
IEEE802.15.4 – Star Topology
Thomas Watteyne @ WCNC 2010
16
Full function device Communications flow
Point to point Cluster tree
IEEE802.15.4 – P2P Topology
Thomas Watteyne @ WCNC 2010
17
Full function device
Reduced function device
Communications flow
Clustered stars - for example,cluster nodes exist between roomsof a hotel and each room has a star network for control.
IEEE802.15.4 – Combined Topology
Thomas Watteyne @ WCNC 2010
18
IEEE802.15.4 Scenario
• First node makes sure it is alone, scans for a “good” frequency and transmits beacons.
• New node scans (active or passive) and hears beacon. Sends an association request (indirect response). Tracks beacon periodically.
• Upstream data transmitted in CAP using CSMA/CA. If downstream data, coordinator set pending data field.
• Device can ask to (dis)allocate a GTS to the coordinator. GTS slots are announced in beacon, CSMA is not used in GTS slot.
• Secondary coordinators to create a generalized star topology.
Thomas Watteyne @ WCNC 2010
19
IEEE802.15.4 - Problems
• Powered Routers– router nodes have their radio on all the time
– if battery-powered: 2400mAh AA pack @ 81mA (CC2420) -> 29h of lifetime
– assumption: mains powered
• Single channel operation– WiFi-like: one channel for the whole network– suffers from external interference (WiFi, Bluetooth)– suffers from persistent multipath fading (especially indoors)
• Topologies– works great in star topologies
– e.g. multiple switches connected to a single lamp
– extended star topologies are hard to manage
Thomas Watteyne @ WCNC 2010
20
A
B
C
D
IEEE802.14.4E - TSCH
• Time Synchronized Channel Hopping
• cut time into slots
• have nodes follow a common schedule
Thomas Watteyne @ WCNC 2010
21
IEEE802.14.4E - TSCH
• The channel offset is translated to frequency using a translation function
• This insures that successive packets sent over a same link are sent over all frequencies– iff the superframe length and
number if frequencies are mutually prime
frequency = (absolute slot number + channel offset)%16
superframe ASN channel offset frequency
1 8 1 9
2 18 1 3
3 28 1 12
4 38 1 6
Thomas Watteyne @ WCNC 2010
22
IEEE802.14.4e - TSCH
A B
Thomas Watteyne @ WCNC 2010
23
Thomas Watteyne @ WCNC 2010
24
Thomas Watteyne @ WCNC 2010
SETTING_CHANNEL
STARTING STARTED TXDATA RXACK STOPPED
Startup_time+Guard_time_large
TsTxOffset
Watchdog_TXDATA
TsRxAckDelay
TsAckWaitTime
SETTING_CHANNEL
STARTINGSTARTED
RXDATA TXACK STOPPED
Startup_time
TsRxOffset
TsPacketWaitTime
TsTxAckDelay
Watchdog_TXACK
Watchdog_TXACK+Guard_time_small
1 2 4 5 6 10 11
1 2 7 8 9 10 11
WAIT_TXACK STOPPING
WAIT_RXACK
STOPPING
Guard_time_large Guard_time_small
Stopping_time
SLOT_TIME>TsRxOffset+TsPacketWaitTime+TsTxAckDelay+Watchdog_TXACK+Stopping_time
26
Improved Reliability
Thomas Watteyne @ WCNC 2010
27
Improved Connectivity
Thomas Watteyne @ WCNC 2010
28
Improved Throughput
Thomas Watteyne @ WCNC 2010
29
Improved Energy Consumption
• 2ms maximum de-synchronization
• 20ppm relative drift
• Resynchronization every 100 seconds (10ms slots)
0.010% idle duty cycle
• 25mA when mote is active
• 2400mAh batteries(AA batteries)
lifetime of 109 years(>> shelf-life)
Thomas Watteyne @ WCNC 2010
30
Improved Throughput
Thomas Watteyne @ WCNC 2010
31
visible light sensor
IR light sensor
humidity sensor
antenna
CC2420radio
MSP430 microcontroller
1 2 3 4
IEEE 802.15.4e - TSCH
• TelosB mote
• TinyOS operating system
• 30ms time slots
• 19kB ROM / 3kB RAM
• 10kbps over 14 hops
Thomas Watteyne @ WCNC 2010
32
Thomas Watteyne @ WCNC 2010
33
Thomas Watteyne @ WCNC 2010
3.2 IETF 6LoWPAN
34
IPv4 vs. IPv6
• Internet Protocol v4 (IPv4):– IPv4 (RFC 791) originates from 1981
– upper layer protocols responsible for end-to-end reliability
– works over almost any layer 2 network and with many routing protocols
– addressing is being pushed to extremes by Internet growth
• Internet Protocol v6 (IPv6):– IPv6 (RFC 2460) is the next generation of the Internet Protocol
– complete redesign on IP addressing: hierarchical 128-bit address with decoupled host identifier; stateless auto-configuration; etc
– simple routing and address management
– majority of traffic not yet IPv6 but most PC operating systems already have IPv6, governments are starting to require IPv6, most routers already have IPv6 support
– IPv6 transition is coming slowly but quietly
Thomas Watteyne @ WCNC 2010
35
• IPv4 ...
... versus IPv6 addressing:
IPv4 vs. IPv6
Thomas Watteyne @ WCNC 2010
36
IPv4 vs. IPv6M
onday, September 26, 2011
Thomas Watteyne @ WCNC 2010
37
IP headers
IPv4 header [RFC791], 1981
IPv6 header [RFC791], 1998Thomas Watteyne @ WCNC 2010
38
IETF 6LoWPAN - Overview
• Key properties:– IP for very low power embedded devices
– IETF Standard for IPv6 over IEEE 802.15.4: RFC4944, to be obsolete by IPHC
– 80% compression of headers
– IPv6 40-byte header -> 2 bytes (best case)
– UDP 8-byte header -> 4 bytes
– end-to-end Internet integration
– fragmentation (1260 byte IPv6 frame -> 127 byte 802.15.4 frames)
Thomas Watteyne @ WCNC 2010
39
Header Compaction
Not compacted
Well-known value
Value inferred from IEEE802.15.4 header
Thomas Watteyne @ WCNC 2010
40
Internet Integration
Thomas Watteyne @ WCNC 2010
41
Thomas Watteyne @ WCNC 2010
3.3 IETF RPL
42
IETF ROLL - Overview
• Routing Over Low-Power and Lossy Networks (ROLL):– IETF information discussion started in 2008
– Finalizing “RPL: IPv6 Routing Protocol for Low power and Lossy Networks”
– website: http://tools.ietf.org/wg/roll
– list: http://www.ietf.org/mail-archive/web/roll/current/threads.html
• Since WSNs are application specific, 4 scenarios are dealt with:– building applications: draft-ietf-roll-building-routing-reqs
– home applications: draft-ietf-roll-home-routing-reqs
– industrial applications: RFC 5673
– urban applications: RFC 5548
Thomas Watteyne @ WCNC 2010
43
IETF ROLL – RPL
• Adopted as a working document by IETF ROLL on August 3, 2009
• Close integration with IPv6/6LoWPAN– DAG Information Option (DIO)
– Destination Advertisement Option (DAO)
• Core operation:– build a Directed Acyclic Graph (DAG) onto the connectivity graph of the
network, directed toward a DAG root
– each node has at least one DAG parent; nodes send inward traffic to their DAG parent
– nodes announce their presence to the DAG root using Destination Advertisement
– Source routing is used for outward traffic
Thomas Watteyne @ WCNC 2010
44
• Constraint Based Routing– finding the shortest path according to some metrics satisfying a set of
constraints
• Objective Code Point (OCP) included in DIO:– The set of metrics used within the DAG
e.g. Expected Transmission Count (ETX)
– The objective functions used to determine the least cost constrained paths in order to optimize the DAGe.g. minimize ETX
– The function used to compute DAG Depthe.g. DAG Depth is equivalent to ETX
– The functions used to construct derived metrics for propagation within a DIOe.g. additive
IETF ROLL – RPL
Thomas Watteyne @ WCNC 2010
45
IETF ROLL – RPL
Thomas Watteyne @ WCNC 2010
wsn
.eec
s.er
kele
y.ed
u
46
IETF ROLL – RPL
Thomas Watteyne @ WCNC 2010
wsn
.eec
s.er
kele
y.ed
u
47
IETF ROLL – RPL
Thomas Watteyne @ WCNC 2010
48
Thomas Watteyne @ WCNC 2010
3.4 OpenWSN
49
Charter
The OpenWSN project serves as a repository for open-source implementations of protocol stacks based on Internet of Things standards, using a variety of hardware and software platforms.
Thomas Watteyne @ WCNC 2010
50
Open Source
• http://openwsn.berkeley.edu/
• Source code repository: Subversion with public check out
• Documentation: wiki
• Project management: Timeline & Roadmap
• Bug reporting: ticketing system
Thomas Watteyne @ WCNC 2010
51
Hardware/Software Platforms
• Hardware:– TelosB (2004)
MSP430f1611 (16-bit, 8MHz, 10kB RAM, 48kB ROM)CC2420
– Jennic JN5140 (2009)32-bit, 32MHz, 128kB RAM, 128kB ROM15.4 radio with RF ToF engine
– Atmel RAVEN Stick (2009)AT90USB1287 (8-bit, 16MHz, 8kB RAM, 128kB ROM), AT86RF230
– GINA 2.0 (2009)
• Software:– TinyOS
– Contiki
– FreeRTOS
– uC-OS II/III
– no-OSThomas Watteyne @ WCNC 2010
52
//Slot Durationsenum {
Startup_time = 114, //32kHz ticks = 3.479ms Guard_time_large = 33, //32kHz ticks = 1.007msGuard_time_small = 16, //32kHz ticks = 0.488msWatchdog_TXDATA = 393, //32kHz ticks = 11.993msWatchdog_TXACK = 213, //32kHz ticks = 6.500msStopping_time = 17, //32kHz ticks = 0.519ms
TsRxOffset = Startup_time,TsTxOffset = Startup_time+Guard_time_large,TsPacketWaitTime = Watchdog_TXDATA+Guard_time_large TsRxAckDelay = 1, //go in reception mode immediatelyTsTxAckDelay = TsRxAckDelay+Guard_time_small,TsAckWaitTime = Watchdog_TXACK+Guard_time_small//SLOT_TIME >= TsRxOffset+TsPacketWaitTime+TsTxAckDelay+Watchdog_TXACK+Stopping_timeSLOT_TIME = 983, //ticks = 29.999ms
};
Slot Organization
Thomas Watteyne @ WCNC 2010
53
Full Debugging Environment
Thomas Watteyne @ WCNC 2010
54
Memory Usage
ROM RAM
48kB
30788 B
RPL 802.15.4E
2196
0 B
OS
8828
B
10kB
2920B 1352 B1568 B
Thomas Watteyne @ WCNC 2010
55
Next Step
OpenADRserver
sensor.network.com
datacollection
actuation
Thomas Watteyne @ WCNC 2010
56
Thomas Watteyne @ WCNC 2010
3.5 Conclusions
57
Conclusions
• Lifting barriers to adoption– Robust wireless communication through channel hopping
– A fully standards-based solution
– Internet integration provides ease of use
– Aggressive duty cycling provides <1% duty cycle
– Being implemented on the low-end of today’s motes
• openwsn.berkeley.edu
Thomas Watteyne @ WCNC 2010
The Internet
1
Thomas Watteyne @ WCNC 2010
4. IoT in Practice
2
Section 4 - Overview
4. IoT in Practice4.1 Off-the-Shelf Hardware
4.2 Operating Systems
4.3 Development Environment
4.4 Tips & Tricks
Thomas Watteyne @ WCNC 2010
3
Thomas Watteyne @ WCNC 2010
4.1 Off-the-Shelf Hardware
4
Hardware - Overview
micro-controller radiosensors
battery
mote
Thomas Watteyne @ WCNC 2010
5
Hardware - Criteria
• Micro-controller– Reasonably fast
– Low-power
– Multiple I/O options
– Reasonable amount of memory
– Timing capabilities
– Community / support
• Radio-chip– Low-power
– Standards compliant?
– Community / Support
Thomas Watteyne @ WCNC 2010
6
Hardware - Microcontrollers
family name arch speedPower
active/asleepRAM ROM Timers I/O used in
ARM
ARM7TDMI 32-bit 115-236MHz 2mW/MHz 8kBa -6 Timers, RTC
3 USART, SPI, 8 10-bit ADC, JTAG
Game Boy Advance,Nintendo DS, iPod
ARM920T 32-bit 180-200MHz 22.4mA/250uA 16kBa 128kBa extensive
UART, USB, Ethernet, 4 USART, I2S, SPI,JTAG
SunSpot
MSP
MSP430f2274 16-bit 16MHz 390uAb/100nAb 1kB 32kB2 timers with 3 CCR
UART/LIN/IrDA/SPI and I2C/SPI
TI eZ430
MSP430f1611 16-bit 8MHz 500uAb/200nAb 10kB 48kB16-bit (3CCR), 16-bit (7CCR)
1 USART (SPI or UART or I2C), 1 USART (SPI or UART)
TelosB,t-mote
AVR ATmega128A 8-bit 16MHz 9.8mAc/1mAc 4kB 128kB2 8-bit, 2 16-bit
2 USART, SPI mica2
a used as cache, primary memory is off-chipb at 1MHzc at 8MHz
Thomas Watteyne @ WCNC 2010
7
Hardware - Radios
Brand name 802.15.4 Band sensitivityPower
Tx/Rx/sleepused in
TI
CC2520 Yes 2.4GHz -98dBm 25.8mAa/18.8mA/30nA
CC2420 Yes 2.4GHz -95dBm 17.4mAa/18.8mA/20nATelosB, MICAz, SunSpot EPIC
CC1101 No868/
915MHz-94dBm 16.8mAa/17.1mA/200nA WSN430
CC2500 No 2.4GHz -89dBm 21.2mAa/16.6mA/400nA eZ430-RF2500
AtmelAT86RF230 Yes 2.4GHz -101dBm 16.5mAb/15.5mA/20nA IRIS
AT86RF231 Yes 2.4GHz -101dBm 14mAb/12.3mA/20nA
a at 0dBm transmission powerb at 3dBm transmission power
Thomas Watteyne @ WCNC 2010
8
Hardware - Motes
name micro-controller radio battery price
ez430-RF2500 MSP430f2274 CC2500 2 AAA $20 e.a.
eZ430-RF2480 MSP430f2274 CC2480A1 2 AAA $30 e.a.
MICAz AtMega128L CC2420 2 AA $99 e.a.
IRIS AtMega128L AT86RF230 2 AA $119 e.a.
TelosB MSP430f1611 CC2420 2 AA $99 e.a.
RZ USBstick AT90USB1287 AT86RF230 USB $39 e.a.
deUSB2400 AT91SAM7S256 AT86RF231 USB €35 e.a
TI CC2531EMK CC2531 CC2531 USB $49 e.a.
Thomas Watteyne @ WCNC 2010
9
Hardware - TelosB
User-defined push
reset
visible light sensor
IR light sensor
humidity sensor
expansion port
internal antenna
external antenna
CC2420
MSP430f1611 (back)
3 LEDs (RGB)
USB for programming
and UART
2 AA (back)Thomas Watteyne @ WCNC 2010
10
eZ430-RF2500
2 LEDspushbutton
CC2500
chip antenna
26MHz crystal
for radio
extension ports
MSP430
USB programmer:• Power• Debug (JTAG) • Interface (serial)
Thomas Watteyne @ WCNC 2010
11
Thomas Watteyne @ WCNC 2010
4.2 Operating Systems
12
Software - Requirements
• Reduced Memory Footprint– binary code occupies a small amount of ROM
• Hardware Independency– through abstraction of lower layers
• Re-useability– code is divided in chunks communicating through APIs
• Real-time– Easy to measure time (access to timer registers)
– Reasonably fast
– Guaranteed execution timeThomas Watteyne @ WCNC 2010
13
Software - Options
Name Footprint license real-time community
TinyOS(UC
Berkeley)overhead
open-source
best-effort scheduler
large (academia)
Contiki(SICS,
Sweden)overhead
open-source
best-effort scheduler
large (academia)
Think(Orange
Labs)overhead
open-source
experimentalscheduler
modest
uC-OS II overheadfree
academic use
hard real-timescheduler
large (industry)
From scratch optimalopen-source
- -
Thomas Watteyne @ WCNC 2010
14
Software - TinyOS
• component-based architecture– code is cut in components
– components communicate through APIs
• component library– TinyOS has been ported to a dozen platforms
– Drivers exist for different micro-controllers and radios
• event-driven execution model– a schedule executes tasks on a FCFS basis
– tasks can be halted by interrupts
Thomas Watteyne @ WCNC 2010
15
Thomas Watteyne @ WCNC 2010
4.3 Development Environment
16
Development Tools
• Firmware development is complex– not complicated!
– develop top-down, always keep an eye on where you’re going
– the vast majority of the cases, you’re wrong (not the compiler, not the protocols)
– bugs are always due to simple errors
– build from atomic building blocks
• Multi-dimensional Debugging– choose a meaning for each LED, and stick with it
– print out error codes, not text
– Use the extension pins with an oscilloscope, the easiest way to measure time
– Use a spectrum analyzer to see on what channels you are occupying
– Use a sniffer to see the packets flying through the air
– A GUI is faster than lines text
– Use a JTAG debugger whenever possible
Thomas Watteyne @ WCNC 2010
17
Development Tools• Choosing a scope
– analog channels for energy (put resistor in series with power source)
– the more digital channels, the better
– you don’t need a fast scope
– some oscilloscopes will interpret SPI, I2C, UART (e.g. Tektronic MSO2024)
– cheap USB scopes available
• Spectrum analyzers– are expensive
– can be replaced by a sniffer
– can be replaced by the poor man’s spectrum analyzer
• Sniffer– CC2531 EMK ($49)
• Graphical User Interface– Python+PySerial is a good candidate
Thomas Watteyne @ WCNC 2010
18
Thomas Watteyne @ WCNC 2010
4.4 Tips & Tricks
19
A MAC Protocol is a State Machine
IDLE
RXUF
RXCW
BACKOFFACK
RXDATATXFIN
TXACK
SENTACK
TXUF
TXCW
RXACK
TXDATA
RXFIN Thomas Watteyne @ WCNC 2010
20
Clock Drift
Thomas Watteyne @ WCNC 2010
21
Gotcha’s - Synchronization
1. A sends packet with slot offset α
2. B records the epoch of the time of arrival β
3. B calculates the epoch of the start of the last slot (β- α)
4. B sets its counter register accordingly
A
B
α
β
Thomas Watteyne @ WCNC 2010
22
Gotcha’s - Packet Timestamps
1. MSP430 writes packet to CC2420 with error code in timestamp
2. MSP430 triggers the start of the transmission
3. MSP430 records the time of SFD (interrupts)
4. MSP writes to correct timestamp in the Tx buffer
5. Transmission completes
MSP430 CC2420
Thomas Watteyne @ WCNC 2010
23
Synchronization
Thomas Watteyne @ WCNC 2010
24
Integration into the Internet
NSLU2 by Linksys as a gateway($100)
http://tunnelbroker.net/ for tunnelinginto the IPv6 cloud
(free)
http://sensor.network.com/ by Sunto store your data
(free) http://code.google.com/apis/visualization/http://code.google.com/apis/maps/
to visualize your data onlineThomas Watteyne @ WCNC 2010
1
Thomas Watteyne @ WCNC 2010
5. Programming Tour
2
Section 5 - Overview
5. Programming Tour5.1 Crash-course on the Hardware
5.2 Development Environment
5.3 Blinking the LEDs
5.4 Enabling Wireless
5.5 Wireless Chat
5.6 The Importance of CRC
5.7 Poor Man’s Spectrum Analyzer
5.8 Wonderful Wireless Waterfall
5.9 ConclusionsThomas Watteyne @ WCNC 2010
3
Thomas Watteyne @ WCNC 2010
5.1 Crash-course on the Hardware
4
MSP430
• “Heart” of the eZ430-RF2500– 16-bit 16MHz RISC
– 32kB ROM, 1kB RAM
– 2 Timers, USCI, 10-bit ADCs
• Debug capabilities using JTAG
• Low Power Operation
Thomas Watteyne @ WCNC 2010
5
CC2500• Any frequency on the 2.4-
2.485GHz band– Not 802.15.4-compliant
• Wake-on-radio support– Preamble sampling in
hardware
• 47 configuration registers– Switch Tx/Rx/idle
– TXBUF, RXBUF
– Tx power and frequency
• Follows a state machineSmartRF StudioThomas Watteyne @ WCNC 2010
6
Interconnection
Chip Select
Clock
SPI interfaceinterrupts Thomas Watteyne @ WCNC 2010
7
eZ430-RF2500
2 LEDspushbutton
CC2500
chip antenna
26MHz crystal
for radio
extension ports
MSP430
USB programmer:• Power• Debug (JTAG) • Interface (serial)
Thomas Watteyne @ WCNC 2010
8
Extension Pins• P1: GND• P2: VCC_EXT• P3: P2.0 I/O, ACLK, OA010• P4: P2.1 I/O, Timer_A3.INCLK, SMCLK, OA0O• P5: P2.2 I/O, Timer_A3.CCI0B, Timer_A3.TA0, OA• P6: P2.3 I/O, Timer_A3.CCI1B, Timer_A3.TA1, OA• P7: P2.4 I/O, Timer_A3.TA2, OA• P8: P4.3 I/O, Timer_B3.CCI0B, Timer_B3.TB0, OA• P9: P4.4 I/O, Timer_B3.CCI1B, Timer_B3.TB1, OA• P10: P4.5 I/O, Timer_B3.TB2, OA• P11: P4.6 I/O, OA• P12: GND• P13: GDO0 I/O from the CC2500 (configurable)• P14: GDO2 I/O from the CC2500 (configurable)• P15: P3.2 I/O, UC1SOMI• P16: P3.3 I/O, UC1CLK• P17: P3.0 I/O• P18: P3.1 I/O, UC1SIMO Thomas Watteyne @ WCNC 2010
9
Thomas Watteyne @ WCNC 2010
5.2 Development Environment
10
IAR Kickstart
project file navigator
compile
open files
Thomas Watteyne @ WCNC 2010
11
Talking with your mote over “USB”
• Use Windows Device Manager to idenfify the COM port the eZ430-RF2500 is on
• Use PuTTY to connect to that port
Thomas Watteyne @ WCNC 2010
12
Thomas Watteyne @ WCNC 2010
5.3 Blinking the LEDs
13
Operations on binary data
• A = 0b01101001
• ~A = 0b10010110• A |= 0b00000010 => A=0b01101011• A &=~0b00001000 => A=0b01100001• A ^= 0b10001000 => A=0b11100001• A<<2 => A=0b10100100• A>>2 => A=0b00011010
Thomas Watteyne @ WCNC 2010
14
I/O port registers
• P1DIR: direction, 0=in, 1=out
• P1OUT: set output
• P1IN: read input
Thomas Watteyne @ WCNC 2010
15
A steady LED
led_steady
Disable watchdog
timer
P1.0 and P1.1 as output
P1.0=1 and P1.1=1
Continue executing
#include "io430.h"
#include "in430.h"
int main( void )
{
WDTCTL = WDTPW + WDTHOLD;
P1DIR |= 0x03;
P1OUT |= 0x03;
while(1);
}
Thomas Watteyne @ WCNC 2010
16
Active Waiting Loop
led_loop
#include "io430.h"
#include "in430.h"
int main( void )
{
WDTCTL = WDTPW + WDTHOLD;
int i;
P1DIR |= 0x03;
while (1) {
P1OUT ^= 0x03;
for (i=0;i<10000;i++) {
__no_operation();
}
}
}
P1.0 and P1.1 as output
Change Led state (aka toggle)
Thomas Watteyne @ WCNC 2010
17
Interrupt
• Interrupt only when both– General interrupt enabled in status register
– Specific interrupt enabled in specific register
• Interrupt Service Routine written as:#pragma vector=TIMERA0_VECTOR
• ISR sometimes needs to clear an interrupt flag in a specific register
Thomas Watteyne @ WCNC 2010
18
Button-Driven Toggle Through Interrupts
led_button
#include "io430.h"#include "in430.h"int main( void ){WDTCTL = WDTPW + WDTHOLD;P1DIR |= 0x03;P1DIR &= ~0x04;P1REN |= 0x04;P1OUT |= 0x04;P1IE |= 0x04;__bis_SR_register(GIE);while(1);
}
#pragma vector=PORT1_VECTOR__interrupt void Port_1 (void){P1IFG &= ~0x04;P1OUT ^= 0x03;
}
P1.2 as input
enable resistor (for button)
enable interrupt for P1.2 globally enable
interrupts (do this last)
Executed when interrupt from P1
Actual function name has no importance
Clear interrupt flag (mandatory)
Toggle LEDsThomas Watteyne @ WCNC 2010
19
Timer
• A timer is a counter which– Counts in a certain way (up, down, continuous)
– At every clock tick
• Can be used in two ways:– Triggers interrupts when reaching a given value
(compare mode)
or
– Records its timer value on other interrupts(capture mode)
Thomas Watteyne @ WCNC 2010
20
Timer-Driven Toggle Through Timer Interrupts
led_timer
#include "io430.h"
#include "in430.h"
int main( void )
{
WDTCTL = WDTPW + WDTHOLD;
P1DIR |= 0x03;
TACCTL0 = CCIE;
TACCR0 = 1000;
TACTL = TASSEL_1 + MC_1;
__bis_SR_register(GIE+LPM3_bits);
}
#pragma vector=TIMERA0_VECTOR
__interrupt void Timer_A (void)
{
P1OUT ^= 0x03;
}
Timer_A interrupt enable Capture Compare
to 1000
Count following ACLK
Count in up mode
interrupt interrupt
Globally enable interrupt
low power mode, waiting for interrupts
Executed at each Timer_A interruptThomas Watteyne @ WCNC 2010
21
Thomas Watteyne @ WCNC 2010
5.4 Enabling Wireless
22
Simple Tx/Rx
txrx_simple
#include "mrfi.h"
int main(void)
{
BSP_Init();
P1REN |= 0x04;
P1OUT |= 0x04;
P1IE |= 0x04;
MRFI_Init();
MRFI_WakeUp();
MRFI_RxOn();
__bis_SR_register(GIE+LPM4_bits);
}
void MRFI_RxCompleteISR()
{
P1OUT ^= 0x02;
}
#pragma vector=PORT1_VECTOR
__interrupt void Port_1 (void)
{
P1IFG &= ~0x04;
mrfiPacket_t packet;
packet.frame[0]=8+20;
MRFI_Transmit(&packet, MRFI_TX_TYPE_FORCED);
P1OUT ^= 0x01;
}
Init MSP430 (clock, leds, button)
Init CC2500 (pins, SPI, registers)
Start CC2500 oscill. (IDLE state)
CC2500 to RX state
low power mode, waiting for interrupts
Executed when packet received
(“meta” interrupt declaration)
Executed when button pushed
clear button interrupt flag
declare packet w. max length
declare useful length
copy to cc2500 TXFIFO and send
Length (1B) Source (4B) Destination (4B) Payload (Length-8 bytes long)
Thomas Watteyne @ WCNC 2010
23
#include "mrfi.h"
int main(void)
{
BSP_Init();
P1REN |= 0x04;
P1OUT |= 0x04;
P1IE |= 0x04;
MRFI_Init();
MRFI_WakeUp();
MRFI_RxOn();
__bis_SR_register(GIE+LPM4_bits);
}
void MRFI_RxCompleteISR()
{
P1OUT ^= 0x02;
}
#pragma vector=PORT1_VECTOR
__interrupt void Port_1 (void)
{
P1IFG &= ~0x04;
mrfiPacket_t packet;
packet.frame[0]=8+20;
MRFI_Transmit(&packet, MRFI_TX_TYPE_FORCED);
P1OUT ^= 0x01;
}
Change Channel
txrx_simple
#include "radios/family1/mrfi_spi.h"
mrfiSpiWriteReg(CHANNR,0x10);
Removing this line cause continuous
transmissions
Thomas Watteyne @ WCNC 2010
24
Continuous Transmission
Thomas Watteyne @ WCNC 2010
25
#include "mrfi.h"
int main(void)
{
BSP_Init();
P1REN |= 0x04;
P1OUT |= 0x04;
P1IE |= 0x04;
MRFI_Init();
MRFI_WakeUp();
MRFI_RxOn();
__bis_SR_register(GIE+LPM4_bits);
}
void MRFI_RxCompleteISR()
{
P1OUT ^= 0x02;
}
#pragma vector=PORT1_VECTOR
__interrupt void Port_1 (void)
{
P1IFG &= ~0x04;
mrfiPacket_t packet;
packet.frame[0]=8+20;
MRFI_Transmit(&packet, MRFI_TX_TYPE_FORCED);
P1OUT ^= 0x01;
}
Change Transmission Power
txrx_simple
#include "radios/family1/mrfi_spi.h"
mrfiSpiWriteReg(PATABLE,0xFF);
Thomas Watteyne @ WCNC 2010
26
Impact of Transmission Power
setting power current
0X84 -24dBm 16.1mA
0x55 -16dBm 16.5mA
0x97 -10dBm 18.3mA
0xA9 -4dBm 22.6mA
0xFE 0dBm 27.6mA
0xFF 1dBm 27.9mA
Thomas Watteyne @ WCNC 2010
27
Thomas Watteyne @ WCNC 2010
5.5 Wireless Chat
28
Wireless Chat [1/3]
chat
#include "radios/family1/mrfi_spi.h"
#include "mrfi.h"
uint8_t index_output = 9;
mrfiPacket_t packetToSend;
int main(void)
{
BSP_Init();
MRFI_Init();
P3SEL |= 0x30; // P3.4,5 = USCI_A0 TXD/RXD
UCA0CTL1 = UCSSEL_2; // SMCLK
UCA0BR0 = 0x41; // 9600 from 8Mhz
UCA0BR1 = 0x3;
UCA0MCTL = UCBRS_2;
UCA0CTL1 &= ~UCSWRST; // Initialize USCI state machine
IE2 |= UCA0RXIE; // Enable USCI_A0 RX interrupt
MRFI_WakeUp();
MRFI_RxOn();
index_output=0;
__bis_SR_register(GIE+LPM4_bits);
}
Enable UART
Thomas Watteyne @ WCNC 2010
29
Wireless Chat [2/3]
void MRFI_RxCompleteISR()
{
uint8_t i;
P1OUT ^= 0x02;
mrfiPacket_t packet;
MRFI_Receive(&packet);
char output[] = {" "};
for (i=9;i<29;i++) {
output[i-9]=packet.frame[i];
if (packet.frame[i]=='\r') {
output[i-9]='\n';
output[i-8]='\r';
}
}
TXString(output, (sizeof output));
}
when received a packet
Copy RXFIFO into “packet”
write over serial portnewline(for PuTTY)
chat Thomas Watteyne @ WCNC 2010
30
Wireless Chat [3/3]
#pragma vector=USCIAB0RX_VECTOR
__interrupt void USCI0RX_ISR(void)
{
char rx = UCA0RXBUF;
uint8_t i;
packetToSend.frame[index_output]=rx;
index_output++;
if (rx=='\r' || index_output==29) {
packetToSend.frame[0]=28;
MRFI_Transmit(&packetToSend, MRFI_TX_TYPE_FORCED);
index_output = 9;
for(i=9;i<29;i++) {
packetToSend.frame[i]=' ';
}
P1OUT ^= 0x01;
}
P1OUT ^= 0x02;
TXString(&rx, 1);
}
when received one character
over serial port
copy serial input buffer to “rx”
Append to the packet being constructed
newline or packet fullcopy to TXFIFO,
trigger Tx
re-initialize
echo over serial portchat Thomas Watteyne @ WCNC 2010
31
Thomas Watteyne @ WCNC 2010
5.6 The Importance of CRC
32
CRC: Cyclic Redundancy Check
• If PKTCTRL0.CRC_EN=1:– At Tx, data is hashed and result append to the
packet as a 2-byte field
– At Rx, data is hashed and result compared to CRC field, packet dropped if fails
• How CRC works– Calculate the remainder
of a (binary) division
– In CC2500,CRC-16-IBM (x16 + x15 + x2 + 1)
Single bit errors 100%
Double-bit errors 100%
Odd-Numbered errors 100%
Burst Errors Shorter than 16 bits 100%
Burst Errors of exactly 17 bits 99.9969%
All other burst errors 99.9984%
Thomas Watteyne @ WCNC 2010
33
CRC: Cyclic Redundancy Check1101001110110010110110001110110010110111011101100101101011110110010110000110110010110001101100101100110110010110110110010110110100101101100010110111010110101
• Pick a CRC length– e.g. 3 bits
• Pick a polynom– e.g. x4+x+1 (1011)
– (Always a leftmost 1!)
• While bits in data– Write under leftmost data bits
– iif leftmost data bit is 1, XOR(leftmost bit always turns to 0)
– Shift right one place
• Collect 3-bit CRCThomas Watteyne @ WCNC 2010
34
The Importance of CRC [1/3]
crc
#include "radios/family1/mrfi_spi.h"
#include "mrfi.h"
mrfiPacket_t packetToSend;
int main(void)
{
BSP_Init();
P1REN |= 0x04;
P1OUT |= 0x04;
P1IE |= 0x04;
MRFI_Init();
mrfiSpiWriteReg(PATABLE,0xBB);
mrfiSpiWriteReg(PKTCTRL0,0x41);
P3SEL |= 0x30;
UCA0CTL1 = UCSSEL_2;
UCA0BR0 = 0x41;
UCA0BR1 = 0x3;
UCA0MCTL = UCBRS_2;
UCA0CTL1 &= ~UCSWRST;
MRFI_WakeUp();
MRFI_RxOn();
__bis_SR_register(GIE+LPM4_bits);
}
Enable UART
reduce the TxPower for more frequent errors
disable CRC
Thomas Watteyne @ WCNC 2010
35
The Importance of CRC [2/3]
void MRFI_RxCompleteISR()
{
uint8_t i;
P1OUT ^= 0x02;
mrfiPacket_t packet;
MRFI_Receive(&packet);
char output[] = {" \r\n"};
for (i=9;i<packet.frame[0];i++) {
output[i-9]=packet.frame[i];
}
TXString(output, (sizeof output));
}
when receiving a packet
Copy RXFIFO to “packet”
format string
send string over serial
crc Thomas Watteyne @ WCNC 2010
36
The Importance of CRC [3/3]
#pragma vector=PORT1_VECTOR
__interrupt void Port_1 (void)
{
P1IFG &= ~0x04;
char character = 'a';
uint8_t index;
mrfiPacket_t packet;
for (index=9;index<30;index++) {
packet.frame[index]=character++;
}
packet.frame[0]=++index;
MRFI_Transmit(&packet, MRFI_TX_TYPE_FORCED);
P1OUT ^= 0x01;
}
when button is pressed
comment out for continuous Tx
Fill frame with ‘abcdef…’
Copy to TXFIFO and send
crc Thomas Watteyne @ WCNC 2010
37
Thomas Watteyne @ WCNC 2010
5.7 Poor Man’s Spectrum Analyzer
38
Poor Man’s Spectrum Analyzer [1/2]
#include "mrfi.h"
#include "radios/family1/mrfi_spi.h"
void print_rssi(int8_t rssi)
{
char output[] = {" 000 "};
if (rssi<0) {output[0]='-';rssi=-rssi;}
output[1] = '0'+((rssi/100)%10);
output[2] = '0'+((rssi/10)%10);
output[3] = '0'+ (rssi%10);
TXString(output, (sizeof output)-1);
}
void MRFI_RxCompleteISR()
{
}
prints out a signed int as characters
spectrum
send string over serial
we’re not interested in actually receiving
packets
Thomas Watteyne @ WCNC 2010
39
int main(void)
{
int8_t rssi;
uint8_t channel;
BSP_Init();
MRFI_Init();
P3SEL |= 0x30;
UCA0CTL1 = UCSSEL_2;
UCA0BR0 = 0x41;
UCA0BR1 = 0x3;
UCA0MCTL = UCBRS_2;
UCA0CTL1 &= ~UCSWRST;
MRFI_WakeUp();
__bis_SR_register(GIE);
while(1) {
for (channel=0;channel<200;channel++) {
MRFI_RxIdle();
mrfiSpiWriteReg(CHANNR,channel);
MRFI_RxOn();
rssi=MRFI_Rssi();
print_rssi(rssi);
}
TXString("\n",1);
}
}
Poor Man’s Spectrum Analyzer [2/2]
spectrum
change channel
Enable UART
switch radio on
read current noise level
Thomas Watteyne @ WCNC 2010
40
Poor Man’s Spectrum Analyzer
spectrum.py Thomas Watteyne @ WCNC 2010
41
Thomas Watteyne @ WCNC 2010
5.8 Wonderful Wireless Waterfall
42
Wonderful Wireless Waterfall
• Receiver listens
• When button pressed sender sends a burst of packets– 100 packets with counter from 1 to 100
– 20 packets with counter to 101
• When receiving a packet– If packet counter <101, increment a counter and
store the RSSI
– For the first packet with counter==101, display “average RSSI – channel success probability”
Thomas Watteyne @ WCNC 2010
43
Wonderful Wireless Waterfall [1/4]
#include "mrfi.h"
uint8_t counter, num_received, bool_counting;
int16_t cumulative_rssi;
mrfiPacket_t packet;
void print_probability(int16_t cumulative_rssi, uint8_t number)
{
char output[] = {" 000 0.00\n"};
if (cumulative_rssi<0) {
output[0]='-';
cumulative_rssi=-cumulative_rssi;
}
output[1] = '0'+((cumulative_rssi/100)%10);
output[2] = '0'+((cumulative_rssi/10)%10);
output[3] = '0'+ (cumulative_rssi%10);
output[5] = '0'+((number/100)%10);
output[7] = '0'+((number/10)%10);
output[8] = '0'+ (number%10);
TXString(output, (sizeof output)-1);
}
e.g. “-55 0.75”
Prepare string transmit string over serial
waterfall Thomas Watteyne @ WCNC 2010
44
Wonderful Wireless Waterfall [2/4]
int main(void)
{
BSP_Init();
P1REN |= 0x04;
P1IE |= 0x04;
MRFI_Init();
mrfiSpiWriteReg(PATABLE,0x50);
P3SEL |= 0x30;
UCA0CTL1 = UCSSEL_2;
UCA0BR0 = 0x41;
UCA0BR1 = 0x3;
UCA0MCTL = UCBRS_2;
UCA0CTL1 &= ~UCSWRST;
MRFI_WakeUp();
MRFI_RxOn();
__bis_SR_register(GIE+LPM4_bits);
}
when button is pressed
enable serial communication
Wait for interrupts in low power mode
waterfall Thomas Watteyne @ WCNC 2010
45
Wonderful Wireless Waterfall [3/4]
void MRFI_RxCompleteISR()
{
P1OUT ^= 0x02;
MRFI_Receive(&packet);
counter = packet.frame[9];
if (counter==101) {
if (bool_counting == 1) {
print_probability(cumulative_rssi/num_received,num_received);
}
bool_counting=0;
num_received=0;
cumulative_rssi=0;
} else {
bool_counting=1;
num_received++;
cumulative_rssi+=(int8_t) packet.rxMetrics[0];
}
}
When I receive a packet
waterfall Thomas Watteyne @ WCNC 2010
46
Wonderful Wireless Waterfall [4/4]
#pragma vector=PORT1_VECTOR
__interrupt void interrupt_button (void)
{
P1IFG &= ~0x04;
P1OUT ^= 0x01;
mrfiPacket_t packet;
packet.frame[0]=8+3;
for (counter=1;counter<101;counter++){
packet.frame[9]=counter;
MRFI_Transmit(&packet, MRFI_TX_TYPE_FORCED);
}
for (counter=0;counter<20;counter++){
packet.frame[9]=101;
MRFI_Transmit(&packet, MRFI_TX_TYPE_FORCED);
}
}
when button is pressed
waterfall Thomas Watteyne @ WCNC 2010
47
Wonderful Wireless Waterfall
waterfall.py Thomas Watteyne @ WCNC 2010
48
Thomas Watteyne @ WCNC 2010
5.9 Conclusions
49
Conclusions
• A building block approach– Blinking LEDs
– Interacting with button
– Measuring time
– Interacting with the serial port
– Sending/receiving packets
• More?– http://cnx.org/content/col10684/latest/
• Contribute!– [email protected]
Thomas Watteyne @ WCNC 2010
1
Thomas Watteyne @ WCNC 2010 1/TBC
6. Conclusions and Road Ahead
2
Conclusions
Thomas Watteyne @ WCNC 2010 2
• General:– ‘R’ is rather focused on large-scale and highly resource constrained
– ‘D’ is rather focused on connection to Internet to facilitate Internet of Things
• Industrial Developments:– business takes off slower than anticipated, possibly because of defragmentation
– endless proprietary solutions available with little inter-operability
• Standardization Activities:– IEEE have standardized a solution for robust communication
– IETF is enabling seamless integration into the Internet
– Open source implementations as enablers
3
Multirate IEEE802.15.4
S. Lanzisera, A. Mehta, K. Pister, "Reducing Average Power in Wireless Sensor Networks Through Data Rate Adaptation," IEEE International Conference on Communications (ICC), June 2009.
Thomas Watteyne @ WCNC 2010 3
4
Multirate IEEE802.15.4
• Decrease transmit power– Inefficient
• Variable Rate Signaling– Use excess SNR to send messages faster
– Usually done to increase throughputAdditional
SNRPA Energy
SavingsData Rate Variable
Rate Savings
0 dB 0% 250 kbps 0%
2.6 dB 16% 500 kbps 48%
5.6 dB 31% 1000 kbps 72%
14.1 dB 55% 2000 kbps 84%Thomas Watteyne @ WCNC 2010 4
5
Multirate IEEE802.15.4
Thomas Watteyne @ WCNC 2010 5
6
The Promise of Wireless
7
The Promise of Wireless
“I do not think that the wireless waves that I have discovered will have any practical application.”
- Heinrich Hertz 1890
Building Tomorrow’s Internet of Things: Latest Standardization Trends andHands-on Programming Tutorial
Thomas WatteyneBerkeley Sensor and Actuator Center
University of California, Berkeley
WCNC, 18 April 2010
Thank you.