-
-
- Preparing your device +
- Addressing and Radio Frequency basics
- Device addressing
-
@@ -2247,29 +2255,30 @@
Internet of Things (IoT) in 5 days
+
+ - Set up a wireless sniffer +
- UDP on IPv6 and the Border Router + -
- UDP and TCP basics - -
- CoAP, MQTT and HTTP
- CoAP example
@@ -2281,7 +2290,7 @@
Internet of Things (IoT) in 5 days
- MQTT example
- Hands on: connecting to a real world IoT platform (HTTP-based) @@ -2301,10 +2310,10 @@
-
-
Two phidget connectors for 3.3 V sensors.
-
- -
-
Two phidget connectors for 5 V sensors.
-
- -
-
Two phidget connectors, one for 3.3 V and one for 5 V sensors.
-
- -
+
Two phidget connectors for 3.3 V sensors.
+
+ -
+
Two phidget connectors for 5 V sensors.
+
+ -
+
Two phidget connectors, one for 3.3 V and one for 5 V sensors.
+
+ -
-
Specific hardware settings: parameters such as the default I2C pins, ADC channels, module-specific pin assignment and platform information can be found at
-platform/zoul/remote/dev/board.handplatform/z1/platform-conf.h.
- -
-
Specific Contiki settings: UART settings, MAC driver, radio channel, IPv6, RIME and network buffer configuration, among others, can be found at
-platform/zoul/contiki-conf.handplatform/z1/contiki-conf.h.
- -
-
To reduce the power consumption.
-
- -
-
To test a multi-hop network without placing the nodes too far (too much power can saturate the receiver).
-
- -
-
To avoid interference among co-located networks in the same area.
-
- -
+
Turn a lamp on and off by controlling a relay
+
+ -
+
Check if a window is open or close using a reed switch
+
+ -
+
Specific hardware settings: parameters such as the default I2C pins, ADC channels, module-specific pin assignment and platform information can be found at
+platform/zoul/remote/dev/board.handplatform/z1/platform-conf.h.
+ -
+
Specific Contiki settings: UART settings, MAC driver, radio channel, IPv6, RIME and network buffer configuration, among others, can be found at
+platform/zoul/contiki-conf.handplatform/z1/contiki-conf.h.
+ -
+
To reduce the power consumption.
+
+ -
+
To test a multi-hop network without placing the nodes too far (too much power can saturate the receiver).
+
+ -
+
To avoid interference among co-located networks in the same area.
+
+ -
+
The first one is an indication of the amount of power present in the wireless medium at the given frequency and at given time. In the absence of any packet in the air, this will be the noise floor. This measurement is also used to decide if the medium is free, and available to send a packet. A high value could be due to interference or to the presence of a packet in the air.
+
+ -
+
The second measurement is performed only after a packet has been correctly decoded, and gives the strength of the packet received from a specific node.
+
+ -
+
Multipoint-to-point (MP2P)
+
+ -
+
Point-to-multipoint (P2MP)
+
+ -
+
Point-to-point (P2P)
+
+ -
-
The first one is an indication of the amount of power present in the wireless medium at the given frequency and at given time. In the absence of any packet in the air, this will be the noise floor. This measurement is also used to decide if the medium is free, and available to send a packet. A high value could be due to interference or to the presence of a packet in the air.
-
- -
-
The second measurement is performed only after a packet has been correctly decoded, and gives the strength of the packet received from a specific node.
-
- -
+
RSSI (Received signal strength indication) and LQI (Link quality indicator)
+
+ -
+
Radio channel
+
+ -
+
PAN ID (network identifier)
+
+ -
-
Multipoint-to-point (MP2P)
-
- -
-
Point-to-multipoint (P2MP)
-
- -
-
Point-to-point (P2P)
-
- -
+
How does the RSSI/LQI change when moving the devices apart?
+
+ -
+
What happens if you put an obstacle between both devices? a metallic obstacle would yield the same effect as a wooden one?
+
+ -
+
Rotate the
+RE-Moteor theZ1so the antenna position is not the same in all cases, what do you think it will happen?
+ -
+
Decrease the transmission power close to the minimum and try to move the devices away from each other until you cannot receive any more packets, note the distance and the RSSI/LQI values.
+
+ -
+
What is the maximum range you get using the maximum transmission power between two devices with line of sight? what will happen if you increase the height of one of the devices by a metre?
+
+ -
+
Learn how to create a CoAP resource and build a CoAP server
+
+ -
+
Show how to use the Copper client plugin to interact with our CoAP server
+
+ -
+
Learn how to discover the resources our CoAP server exposes
+
+ -
+
Learn how to use the
+GETmethod to retrieve sensor data from the CoAP server
+ -
+
Subscribe to events (be notified each time the user button is pushed)
+
+ -
+
Request sensor readings in different formatting (application/json, text/plain, etc)
+
+ -
+
Control the on-board LEDs remotely using
+PUT/POSTrequests
+ -
-
Device name.
-
- -
-
An incremental sequence number.
-
- -
-
Device uptime (in seconds).
-
- -
-
On-chip temperature.
-
- -
-
Battery value.
-
- -
+
Create an account with Ubidots and log in
+
+ -
+
Create a single data source
+
+ -
+
Under this data source, create two variables: One for the uptime and another for the sequence number.
+
+ -
+
Go to your account and request a short API token.
+
+ -
+
The choice between IP and IPv6. If you are planning to connect to Ubidots over NAT64, you will also want to configure the Ubidots server’s IP address in a NAT64 format.
+
+ -
+
The authentication token
+
+ -
+
The variable IDs
+
+
<
This "IoT in five days" release version correspond to:
-Version: 1.0
+Version: 1.1
-Date: 7th February 2016
+Date: 24th June 2016
+-Marco Zennaro received his M.Sc. degree in Electronic Engineering from University of Trieste in Italy. He defended his PhD thesis on “Wireless Sensor Networks for Development: Potentials and Open Issues” at KTH-Royal Institute of Technology, Stockholm, Sweden. -His research interest is in ICT4D, the use of ICT for development. In particular, he is interested in Wireless Networks and in Wireless Sensor Networks in developing countries. He has been giving lectures on Wireless technologies in more than 20 countries.
--When not traveling, he is the editor of the wsnblog.com. He is coauthor of the book “Wireless Networking for the Developing World”.
+His research interest is in ICT4D, the use of ICT for development. In particular, he is interested in Wireless Networks and in Wireless Sensor Networks in developing countries. He has been giving lectures on Wireless technologies in more than 20 countries. He is coauthor of the book “Wireless Networking for the Developing World”.Ermanno Pietrosemoli is currently a researcher at the Telecommunications/ICT for Development Lab of the International Centre for Theoretical Physics in Trieste, Italy, and President of Fundación Escuela Latinoamericana de Redes, “EsLaRed”, a non-profit organization that promotes ICT in Latin America through training and development projects. EsLaRed was awarded the 2008 Jonathan B.Postel Service Award by the Internet Society.
@@ -3370,6 +3376,27 @@Figure 19. Wireshark charts
++
++ ++ + ++ +++If you are using Ubuntu probably you would not be able to run wireshark as non-root user (if you miss this installation option). Type the following to enable non-root:
+++++
+sudo dpkg-reconfigure wireshark-common +$ sudo usermod -a -G wireshark $USER +$ gnome-session-quit --logout --no-promptIPv6 Exercises
@@ -4350,8 +4377,7 @@Install Contiki
-There are several ways to install Contiki, from scratch by installing from sources or using -virtual environments, depending on the flavour and time availability.
+There are several ways to install Contiki, from scratch by installing from sources or using virtual environments, depending on the flavour and time availability.
-The remainder of the book assumes Contiki will run in an Unix environment, -as the virtualized environments run on Ubuntu.
+The remainder of the book assumes Contiki will run in an Unix environment, as the virtualized environments run on Ubuntu.
-Install from sources
+Fresh Contiki Installation
+++The following instructions will guide you to install Contiki on your machine. These instructions were tested in Ubuntu-like devices (version 12.04 and onwards). If you are looking for a ready to use setup, skip this section and download one of the Virtual Machines in the next section.
+++This will install support for the ARM Cortex-M3 and MSP430 platforms, as well as support for Cooja, the Contiki’s emulator to be discussed in the next sections.
+++The "IoT in five days" Virtual Machine has a comprehensive lists of additional tools and libraries installed, check the next section for a complete list.
+++Install the toolchain and required libraries
+++The following are the minimal recomended libraries to run Contiki.
+++Ubuntu (Linux) installation
+++To install the toolchain and required dependencies, run in a terminal the following:
+++++
+sudo apt-get update +sudo apt-get install gcc-arm-none-eabi gdb-arm-none-eabi +sudo apt-get -y install build-essential automake gettext +sudo apt-get -y install gcc-arm-none-eabi curl graphviz unzip wget +sudo apt-get -y install gcc gcc-msp430 +sudo apt-get -y install openjdk-7-jdk openjdk-7-jre ant++OSX (MAC) installation (RE-Mote only)
+++++
+# Install Homebrew - http://brew.sh/ +brew tap PX4/homebrew-px4 +brew update + +# Install GCC Arm Toolchain +brew install gcc-arm-none-eabi-49++Windows installation (RE-Mote only)
+++ +Download the GCC ARM toolchain (Windows installer) from:
+++Tested with
+gcc-arm-none-eabi-5_3-2016q1-20160330-win32.exe.++Execute and select the
+add path to environment variableoption.++Next download MINGW, install and make sure the following packages are selected: mingw32-base, mingw32-gcc-g++, msys-base.
+++Under "All Packages" select the msys-mintty package for terminal support. This will install
+MINTTYin the default locationC:\MinGW\msys\1.0\bin\mintty.exe. Create a shortcut and add this to the Shortcut target command:++
+C:\MinGW\msys\1.0\bin\mintty.exe /bin/bash -l++Add the following paths to your
+$pathenvironment variable:++
+C:\MinGW\bin;C:\MinGW\msys\1.0\bin++Run
+MINTTYand execute the following commands:++++
+mingw-get update +mingw-get install msys-wget +mingw-get install msys-zlib +mingw-get install msys-unzip+Get Contiki on your machine
@@ -4382,6 +4494,15 @@Contiki source code is actively supported by contributors from universities, research centers and developers from all over the world.
Contiki GitHub repository:
++ +The latest Contiki release is 3.0, the release tag is available at:
+++Nevertheless you should use the latest commit available, as Contiki releases are produced on a yearly base. Many bug fixes, new features and improved support is normally present on the latest
+masterbranch.To grab the source code open a terminal and execute the following:
@@ -4390,6 +4511,29 @@+
+
++ ++ + ++ +++At the moment of this release, the current Contiki commit corresponds to the
+a8989f9f1c9794233a712ef4f689d1ba35a9a405HASH. You can use the following GIT command to place yourself on this commit:++
+git checkout HASH++Replace
+HASHwith the actual value.++As Contiki ensures the platform and application support by using a strict code revision procedure and regression tests, this is a safe point if you encounter any problem. Be sure to update your Contiki local repository if using
+Instant Contiki!-What is git?@@ -4421,75 +4565,57 @@-
To install the toolchain and required dependencies, run in a terminal the following:
---+
+sudo echo "deb http://ppa.launchpad.net/terry.guo/gcc-arm-embedded/ubuntu trusty main" > /etc/apt/sources.list.d/gcc-arm-embedded.list -sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-key FE324A81C208C89497EFC6246D1D8367A3421AFB -sudo apt-get update -sudo apt-get -y install build-essential automake gettext -sudo apt-get -y install gcc-arm-none-eabi curl graphviz unzip wget -sudo apt-get -y install gcc gcc-msp430 -sudo apt-get -y install openjdk-7-jdk openjdk-7-jre antAdditionally there is a
branchavailable with theIoT in five dayscontent in a workshop-like format. The branch is available at:-+This will install support for the ARM Cortex-M3 and MSP430 platforms, as well as -support for Cooja, the Contiki’s emulator to be discussed in the next sections.
+It is recomended to add this
branchas aremote repositoryof the already cloned Contiki repository, so you can keep track of the development done in themasterbranch.++-cd /home/user/contiki +git remote add iot-workshop https://github.com/alignan/contiki +git fetch iot-workshop +git checkout iot-workshop-Instant Contiki Virtual Machine
--Instant Contiki is an entire Contiki development environment in a single download. It is an Ubuntu Linux virtual machine and has Contiki OS and all the development tools, compilers, and simulators required already pre-installed.
-Grab Instant Contiki from the Contiki website:
+The above commands will add the
https://github.com/alignan/contikirepository to the list ofremoterepositories, making theiot-workshopbranch available in your machine as aworking copy. Now you can track any changes and updates.--http://www.contiki-os.org/start.html
+This branch has ready to use examples and applications to guide you through Contiki and building real IoT applications. In the next sections this content will be further discussed.
--The latest Instant Contiki release is 3.0, following the Contiki 3.0 source code release.
-+This book is heavily based on this release, the use of earlier versions is not recommended.
++Using a virtualized environment
-The release tag is available at:
+Even if installing Contiki should be straightforward, there are already built Virtual Machines available for you to download and use out of the box.
-https://github.com/contiki-os/contiki/tree/release-3-0
+The available Virtual Machines images are available for VMWare.
--Nevertheless you should use the latest commit available, as Contiki releases are produced on a yearly base. Many bug fixes, new features and improved support is normally present on the latest
+masterbranch.Download VMWare player for Windowws and Linux to run Contiki’s virtual machine, it is free and widely used.
--
+- -- - -At the moment of this release, the current Contiki commit corresponds to the
+daa83ee3ef32f5b48f647e1c614fe6523ab440bbHASH. You can use the following GIT command to place yourself on this commit:In OSX you can download VMWare Fusion
+Instant Contiki Virtual Machine
-
+git checkout daa83ee3ef32f5b48f647e1c614fe6523ab440bbInstant Contiki is an entire Contiki development environment in a single download. It is an Ubuntu Linux virtual machine and has Contiki OS and all the development tools, compilers, and simulators required already pre-installed.
--As Contiki ensures the platform and application support by using a strict code revision procedure and regression tests, this is a safe point if you encounter any problem. Be sure to update your Contiki local repository if using
-Instant Contiki!Grab Instant Contiki from the Contiki website:
-Download VMWare player for Windowws and Linux to run Contiki’s virtual machine, it is free and widely used.
+-In OSX you can download VMWare Fusion
+The latest Instant Contiki release is 3.0, following the Contiki 3.0 source code release.
+Using VMWare just open the
@@ -4507,6 +4633,37 @@Instant_Contiki_Ubuntu_12.04_32-bit.vmxfile, if prompted about the VM source just chooseI copied itthen wait for the virtual Ubuntu Linux boot up.+
Notice the
+Instant Contikidoes not have theIoT workshopbranch with the examples of this book, read the previous section on how to clone.+Official "IoT in five days" Virtual Machine
+++ +A Virtual Machine with the content of the book is provided as a free download from the following location:
+++In a nutshell it packs everything the
+Instant Contikihas, but it has been built usingUbuntu Server 16.04 LTS (Xenial)instead. Additionally several packages has been installed to make development easier, including a fully-configured Eclipse IDE workspace.++++
+Figure 32. IoT in five Days Virtual Machine+++The "IoT in five days" book, its source and ready to use Contiki examples are included.
+++Log into the Virtual Machine. The password and user name is
+user.++The "IoT in five days" Virtual Machine has already the
+iot-workshopbranch cloned and available, with the suggested book examples and a ready-to-use Contiki configuration.@@ -4528,7 +4685,7 @@-arm-gcc-none-eabi-gcc --version +arm-none-eabi-gcc --version arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors) 4.9.3 20150529 (release) [ARM/embedded-4_9-branch revision 224288] Copyright (C) 2014 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO @@ -4605,13 +4762,44 @@<
++If you cloned the
+iot-workshopbranch (or if you are using the "IoT in five days" Virtual Machine), you will find also the following folder:++
+contiki/examples/zolertia/tutorial++The content of the
+tutorialis:+ ++++The examples work out of the box for both Zolertia
+Z1andRE-Moteplatforms to be shown next.++The examples are written to be followed in order, so be sure to start from the very first and make your way to the last in an ordered fashion.
+In the following sections we will cover the examples and specific platform files for the Zolertia platforms.
Run Contiki on real hardware
-For the remainder of the book we will use Zolertia Z1 and RE-Mote hardware development platforms. Other platforms can be used as well, but are out of the scope of this book.
+For the remainder of the book we will use the Zolertia Z1 and RE-Mote hardware development platforms. Other platforms can be used as well, but are out of the scope of this book.
-Contiki drivers and libraries are (normally) platform independent, most examples can be run in both Z1 and RE-Mote platforms by taking into consideration specific platform settings.
@@ -4647,10 +4835,10 @@
Figure 32. Zolertia Zoul module and the RE-Mote platform+Figure 33. Zolertia Zoul module and the RE-Mote platform--The RE-Mote has a Zoul on board and also packs:
+The RE-Mote (revision A) has a Zoul on board and also packs:
Figure 33. Zolertia Z1 mote+Figure 34. Zolertia Z1 moteThe Zolertia Z1 mote can run TinyOS, Contiki OS, OpenWSN and RIOT, and has been used actively for over 5 years in universities, research and development centers and in commercial products in more than 43 countries, being featured in more than 50 scientific publications.
@@ -4737,7 +4925,7 @@@@ -4754,41 +4942,52 @@-cd examples/hello-world +cd examples/zolertia/tutorial/01-basics make TARGET=zoul savetarget-
+make hello-worldmake 01-hello-world-To start compiling the code (ignore the warnings), if everything works OK you should see something like:
+if everything works OK you should see something like for the
Z1mote:
+CC 01-hello-world.c +CC ../../../../../platform/z1/./contiki-z1-main.c +LD 01-hello-world.z1 +rm obj_z1/contiki-z1-main.o 01-hello-world.coCC symbols.c AR contiki-z1.a -CC hello-world.c -CC ../../platform/z1/./contiki-z1-main.c -LD hello-world.z1 -rm obj_z1/contiki-z1-main.o hello-world.co-The
+hello-world.z1file should have been created and we are ready to flash the application to the device.The
01-hello-world.z1file should have been created and we are ready to flash the application to the device.-At any given point you can override the saved target and redefine at compilation time by running instead:
+And likewise if we were to compile for the
RE-Moteplatform:+-
+make TARGET=zoul hello-world - CC hello-world.c - LD hello-world.elf -arm-none-eabi-objcopy -O binary --gap-fill 0xff hello-world.elf hello-world.binmake TARGET=zoul 01-hello-world + CC 01-hello-world.c + LD 01-hello-world.elf +arm-none-eabi-objcopy -O binary --gap-fill 0xff 01-hello-world.elf 01-hello-world.bin++
+ ++ + +This will ignore the saved
+Makefile.targetfile and use the targetzoulinstead.If a
+Makefile.targetalready exists and you don’t want to change the current definedTARGET, you can just compile your code specifying aTARGET. Runningmake TARGET=zoulfor example will ignore the savedMakefile.targetfile and use the targetzoulinstead.-In the following sections and chapters the examples can be compiled for both the Z1 and RE-Mote platform, unless specified otherwise.
+In the following sections and chapters the examples can be compiled for both the Z1 and RE-Mote platforms.
-Adding an LED to the example
+Test the LEDs and Button
-The next step is adding an LED (light emitting diode) to interact with our application.
+This section will show how to use the LED (light emitting diode) to interact with our application. Also it will be shown how to use the on-board
user buttonto trigger specific events and change the way our application works.You have to add the
@@ -4980,10 +5187,10 @@dev/leds.hwhich is the library to manage the LEDs. To check the available functions go tocore/dev/leds.h.-
In the Z1 mote these LEDs are defined in
+platform/z1/platform-conf.h, as well as other hardware definitions.In the
Z1mote these LEDs are defined inplatform/z1/platform-conf.h, as well as other hardware definitions.-The RE-Mote uses an RGB LED, basically 3-channel LEDs in a single device, allowing to show any color by the proper combination of Blue, Red and Green. In
+platforms/zoul/remote/board.hheader the following are defined:The
RE-Moteuses an RGB LED, basically 3-channel LEDs in a single device, allowing to show any color by the proper combination of Blue, Red and Green. Inplatforms/zoul/remote/board.hheader the following are defined:-@@ -4994,53 +5201,69 @@+-
Now try to turn on only the red LED and see what happens, create a new example named
+test-leds.c:Accordingly you need to add
+dev/button-sensor.hto add support for theuser button.+The
02-led-and-button.cexample show how the configuration is done.-#include "contiki.h" #include "dev/leds.h" +#include "dev/button-sensor.h" #include <stdio.h> /*-------------------------------------------------*/ -PROCESS(test_leds_process, "Test LEDs"); -AUTOSTART_PROCESSES(&test_leds_process); +PROCESS(led_button_process, "LEDs and button example process"); +AUTOSTART_PROCESSES(&led_button_process); /*-------------------------------------------------*/ -PROCESS_THREAD(test_leds_process, ev, data) +PROCESS_THREAD(led_button_process, ev, data) { PROCESS_BEGIN(); - leds_on(LEDS_RED); + SENSORS_ACTIVATE(button_sensor); (1) + + while(1) { (2) + printf("Press the User Button\n"); + PROCESS_WAIT_EVENT_UNTIL(ev == sensors_event && data == &button_sensor); (3) + /* When the user button is pressed, we toggle the LED on/off... */ + leds_toggle(LEDS_GREEN); (4) + + /* + * And we print its status: when zero the LED is off, else on. + * The number printed when the sensor is on is the LED ID, this value is + * used as a mask, to allow turning on and off multiple LED at the same + * time (for example using "LEDS_GREEN + LEDS_RED" or "LEDS_ALL" + */ + printf("The sensor is: %u\n", leds_get()); (5) + } + PROCESS_END(); }--Now let’s compile and upload the new project with:
-----
-make clean && make test-leds.upload--The
-make cleancommand is used to erase previously compiled objects.--Now the red LED should be on!
-++
-- -- - -- +--If you make changes to the source code, you must rebuild the files, otherwise your change might not be pulled in. It is always recommended to do a
-make cleancommand before compiling.1 +The LED initialization is done at booting by the platform itself, so there is no need to initialize again. The user buttonis required to initialize+ +2 +Loop forever: the code inside the while-loop will run always and not reach +PROCESS_END()macro.+ +3 +To avoid wasting processing cycles, the application is paused until we press the +user button+ +4 +When the +user buttonis pressed, alternate between turning the LED on and off+ + +5 +Prints the current LED mask, that is, which LED channels are on and off +--Printing messages to the console
---You can use printf to visualize on the console what is happening in your application. It is really useful to debug your code, as you can print values of variables, when certain block of code is being executed, etc.
--Let’s try to print the status of the LED, using the
-unsigned char leds_get(void);function that is available in the documented functions (see above).-Get the LED status and print it on the screen, modify the current
+test-leds.cfile as follows:Now let’s compile and upload the new project with:
-
+#include "contiki.h" -#include "dev/leds.h" -#include <stdio.h> -char hello[] = "hello from the mote!"; -/*-------------------------------------------------*/ -PROCESS(test_leds_process, "Test LEDs"); -AUTOSTART_PROCESSES(&test_leds_process); -/*-------------------------------------------------*/ -PROCESS_THREAD(test_leds_process, ev, data) -{ - PROCESS_BEGIN(); - leds_on(LEDS_RED); - printf("%s\n", hello); - printf("The LED %u is %u\n", LEDS_RED, leds_get()); - PROCESS_END(); -}make clean && make 02-led-and-button.upload--If one LED is on, you will get the LED number, which is defined by each platform in its
+platform-conf.horboard.hheader.The
make cleancommand is used to erase previously compiled objects.+--
-- + -Exercise: what happens when you turn on more than one LED? What number do you get? are these the same numbers for the Z1 and the RE-Mote? - --+Adding button events
--We now want to detect if the user button has been pressed.
---The button in Contiki is regarded as a sensor. We are going to use the
+core/dev/button-sensor.hlibrary.If you make changes to the source code, you must rebuild the files, otherwise your change might not be pulled in. It is always recommended to do a
make cleancommand before compiling.--
- - - --The RE-Mote platform has extra button functionalities, such as detect long-press sequences, enabling to further expand the events that can be triggered using the button. Check platform/zoul/dev/button-sensor.cfor more details, andexamples/zolertia/zoul/zoul-demo.cfor an example.--Create a new example called
+test-button.cand add thedev/button-sensor.hheader and button event as follows:The
RE-Moteuser and reset buttons are shown below:+@@ -5242,507 +5453,561 @@---
+#include "contiki.h" -#include "dev/leds.h" -#include "dev/button-sensor.h" -#include <stdio.h> -/*-------------------------------------------------*/ -PROCESS(test_button_process, "Test button"); -AUTOSTART_PROCESSES(&test_button_process); -/*-------------------------------------------------*/ -PROCESS_THREAD(test_button_process, ev, data) -{ - PROCESS_BEGIN(); - SENSORS_ACTIVATE(button_sensor); - while(1) { - PROCESS_WAIT_EVENT_UNTIL((ev==sensors_event) && - (data == &button_sensor)); - printf("I pushed the button!\n"); - } - PROCESS_END(); -}
-This process has an infinite loop, given by the
+wait(), to wait for the button the be pressed. The two conditions have to be met (event from a sensor and that event is the button being pressed), as soon as you press the button, you get the string printed.Figure 35. RE-Mote buttons and micro USB portsTimers
-For our implementation we are going to choose the event timer, because we want to change the application behavior when the timer expires every given period.
+The
03-timers.cexample implements the aforementioned timers and shows their functionality.-+We create a timer structure and set the timer to expire after a given number of seconds. When the timer expires we execute the code and restart the timer.
+First let’s see how the timer’s libraries are included:
+++
+/* The event timer library */ +#include "sys/etimer.h" + +/* The seconds timer library */ +#include "sys/stimer.h" + +/* The regular timer library */ +#include "sys/timer.h" + +/* The callback timer library */ +#include "sys/ctimer.h" + +/* The "real-time" timer library */ +#include "sys/rtimer.h"-Create an example called
+test-timer.cas follows:Next each timer needs to have its corresponding timer structure defined, this will allow the application to store the configuration and operational values of each timer at request.
+-+#include "contiki.h" -#include "dev/leds.h" -#include <stdio.h> -/*-------------------------------------------------*/ -#define SECONDS 2 -/*-------------------------------------------------*/ +
+/* The following are the structures used when you need to include a timer, it + * serves to keep the timer information. + */ +static struct timer nt; +static struct stimer st; +static struct etimer et; +static struct ctimer ct; +static struct rtimer rt;++Then we need to implement
+callbacks, generally these are functions called by the application whenever something occurs. As said before, bothctimerandrtimerare capable of invoking a function whenever an event happens (like a timer expiration). Below is the format of thecallbacks:++++
+/*---------------------------------------------------------------------------*/ +static void +rtimer_callback_example(struct rtimer *timer, void *ptr) +{ + /* Something happens here */ +} +/*---------------------------------------------------------------------------*/ +static void +ctimer_callback_example(void *ptr) +{ + /* Something happens here */ +} +/*---------------------------------------------------------------------------*/++The actual
+03-timers.chas the missing snippet of code in each callback, we will return later to these.++Here’s what our thread looks like:
++@@ -5231,7 +5438,11 @@+/*-------------------------------------------------*/ PROCESS(test_timer_process, "Test timer"); AUTOSTART_PROCESSES(&test_timer_process); /*-------------------------------------------------*/ PROCESS_THREAD(test_timer_process, ev, data) { PROCESS_BEGIN(); - static struct etimer et; - while(1) { - etimer_set(&et, CLOCK_SECOND*SECONDS); (1) - PROCESS_WAIT_EVENT(); (2) - if(etimer_expired(&et)) { - printf("Hello world!\n"); - etimer_reset(&et); - } + static uint32_t ticks = 0; + timer_set(&nt, CLOCK_SECOND); (1)(2) + while(!timer_expired(&nt)) { (3) + ticks++; } - PROCESS_END(); + printf("timer, ticks: \t%ld\n", ticks); }Timers
2 -PROCESS_WAIT_EVENT()waits for any event to happen.The most basic timer type is +timer, it will keep running up toCLOCK_SECOND+ 3 +We need to manually check if the timerhas expiredTimers
-Exercise: can you print the value of CLOCK_SECONDto count how many ticks you have in one second? Try to blink the LED for a certain number of seconds. Make a new application that starts only when the button is pressed and stops when the button is pressed again. +Exercise: can you print the value ofCLOCK_SECONDto count how many ticks you have in one second?++The remaining of our thread is as follows:
+++++
+ticks = 0; + stimer_set(&st, 1); (1) + while(!stimer_expired(&st)) { (2) + ticks++; + } + printf("stimer, ticks: \t%ld\n", ticks);+-+
+ +1 +Same as +timer, but its time-base is seconds+ +2 +And we also need to check if the +stimerhas expired-Sensors
-A sensor is a transducer whose purpose is to sense or detect a characteristic of its environment, providing a corresponding output, generally as an electrical or optical signal, related to the quantity of the measured variable.
+Probably now in this point it is clear the disadvantages of using the previous timers: we need to manually check for expiration in a while-loop, which means a lot of wasted CPU cycles.
-Sensors in Contiki are implemented as follow:
+The next timer allow us to yield our application, meaning it will generate an event informing the application about its expiration, thus the system can perform other tasks in the meantime.
-
+SENSORS_SENSOR (sensor, SENSOR_NAME, value, configure, status);ticks = 0; + etimer_set(&et, CLOCK_SECOND * 2); + + ticks++; + PROCESS_WAIT_EVENT_UNTIL(ev == PROCESS_EVENT_TIMER); + printf("etimer, now: \t%ld\n", ticks);--This means that a method to
+configurethe sensor, poll the sensorstatusand request avaluehave to be implemented. Thesensorstructure contains pointers to these functions. The arguments for each function are shown below.When the
etimeris scheduled, we yield our application and wait for aPROCESS_EVENT_TIMERevent, this is a type of process event sent by the timer to notify applications.--
+struct sensors_sensor { - char * type; - int (* value) (int type); - int (* configure) (int type, int value); - int (* status) (int type); -};++
+ ++ + ++ +++If you run the example the first noticeable thing is the
ticksvalue, what do you think this value will be in this case?-+To better understand please refer to the
+platform/zoul/dev/adc-sensors.c, for an example of how analogue external sensors can be implemented (to be further discussed in the next sections).The next timer to test is the
+ctimer. Let’s see how it is implemented in the example:++
+ticks++; + ctimer_set(&ct, CLOCK_SECOND * 2, ctimer_callback_example, &ticks); + + /* And we keep the process halt while we wait for the callback timer to + * expire. + */ + + while(1) { + PROCESS_YIELD(); + }-The following functions and macros can be used to work with the sensor:
+As comented before the
ctimerwill invoke a function whenever it expires, in this case thectimer_callback_examplefunction after 2 seconds since triggered. Notice we are also passing to thectimer_callback_examplethe content of the variableticks, meaning we can pass as argument any type of variable to the callback function, as it defines this parameter asvoid *ptr. Let’s check now the complete callback implementation:-
+SENSORS_ACTIVATE(sensor) (1) -SENSORS_DEACTIVATE(sensor) (2) -sensor.value(type); (3)static void +ctimer_callback_example(void *ptr) +{ + uint32_t *ctimer_ticks = ptr; (1) + printf("ctimer, now: \t%ld\n", *ctimer_ticks); + + /* The real timer allows execution of real-time tasks (with predictable + * execution times). + * The function RTIMER_NOW() is used to get the current system time in ticks + * and RTIMER_SECOND specifies the number of ticks per second. + */ + + (*ctimer_ticks)++; (2) + rtimer_set(&rt, RTIMER_NOW() + RTIMER_SECOND, 0, (3) + rtimer_callback_example, ctimer_ticks); +}-
-1 -Enable the sensor, typically configures and turns the sensor on +Create a pointer to the variable passed as argument 2 -Disables the sensor, it is useful to save power +Increment the variable ticksusing our pointer3 -Request a value to the sensor. As one sensor chip might have different types of readings (temperature, humidity, etc.), this is used to specify which measure to take. ---
- - - -- +--Although this is the default way to implement sensors in Contiki, there might be alternatives, depending on the sensor and developer. Always check the specific sensor driver implementation for details. Normally sensors are provided in the same location as the example, in the
-devfolder, or in theplatform/zoul/devdirectory for example.Schedule a rtimerto expire after 1 second and pass as argument our pointer to theticksvariable--The
-SENSORSmacro provides external linkage to the sensors defined for the platform and application, allowing to iterate between the available sensors. The following are the sensors defined as default for the RE-Mote platform:---+
-SENSORS (&button_sensor, &vdd3_sensor, &cc2538_temp_sensor, &adc_sensors);In our example when
ctimerexpires it will set a real-timer event using thertimertype of timer. TheRTIMER_NOW()is a macro used to retrieve the current tick value (rtimeris always ticking thus running in the background), we use this as base value then add the number of ticks in which we want our event to be triggered in the future. TheRTIMER_SECONDin the same fashion asCLOCK_SECONDdefines the number of ticks in a second.+- + -The button is considered a sensor in Contiki, and it shares the same sensor implementation
+Print the value of
RTIMER_SECONDand compare to the value ofCLOCK_SECOND.-This macro extends to:
+When
rtimerexpires it invokes its corresponding callback function, let’s check its full implementation in our example:-
+const struct sensors_sensor *sensors[] = { - &button_sensor, - &vdd3_sensor, - &cc2538_temp_sensor, - &adc_sensors, - ((void *)0) -};static void +rtimer_callback_example(struct rtimer *timer, void *ptr) +{ + uint32_t *rtimer_ticks = ptr; + printf("rtimer, now: \t%ld\n", *rtimer_ticks); + + /* We can restart the ctimer and keep the counting going */ + (*rtimer_ticks)++; + ctimer_restart(&ct); +}--The number of sensors can be found with the
-SENSORS_NUMmacro:-+-
+#define SENSORS_NUM (sizeof(sensors) / sizeof(struct sensors_sensor *))As done in the
ctimercallback we also create a pointer to the originalticksvariable, print and increment its value. We restart thectimerusing the initial expiration value configured before. From now on,ctimercallback will configure a newrtimertimer and viceversa, incrementing theticksvalue in a linear way.+Processes in Contiki
--Sensors can be of two types: analogue or digital. In the following sections examples will be shown for both types, detailing how to connect and use both the platform’s internal sensors as well as the external ones.
+We learned in previous section how to create a
PROCESSand the meaning of thePROCESS_BEGIN()andPROCESS_END()macros. Let’s take a closer look at how processes are implemented in Contiki.-Analogue Sensors
--+-Analogue sensors typically require being connected to an ADC (analogue to digital converter) to translate the analogue (continuous) reading to an equivalent digital value in millivolts. The quality and resolution of the measure depends on both the ADC resolution (up to 12 bits in the Z1 and RE-Mote) and the sampling frequency.
+A process thread contains the code of the process. The process thread is a single protothread that is invoked from the process scheduler. A protothread is a way to structure code in a way that allows the system to run other activities when the code is waiting for something to happen. The concept of protothreads was developed within the context of Contiki.
-+As a rule of thumb, the sampling frequency must be at least twice that of the phenomenon you are measuring. As an example, if you want to sample human speech (which may contain frequencies up to 8 kHz) you need to sample at twice that frequency (16 kHz).
-Protothread provides a way for C functions to work in a way that is similar to threads, without the memory overhead of threads. Reducing the memory overhead is important on the memory-constrained systems on which Contiki runs.
+The protothreads starts and ends with two special macros,
PROCESS_BEGINandPROCESS_END(). Between these macros, a set of protothread functions can be used.--The Z1 mote has a built-in voltage sensor provided as an ADC input channel, as well as a generic implementation to read external analogue sensors.
+Libraries and applications in Contiki uses processes to run and to communicate with other modules, by creating its own processes or using the already available. The timers for example use the existing
PROCESS_EVENT_TIMER, and applications could also use thePROCESS_EVENT_EXITEDprocess to indicate an early exit. These areevent identifiersreserved by the Contiki Kernel.--
+- -- - -Analogue sensors can be connected to both the Z1 and the RE-Mote over phidget ports, which are basically 3-pin connectors (Ground, VCC and signal) with 2.54 mm spacing. This is a legacy name from the Z1 release, as these ports were meant for the commercially available Phidget sensors. Nowadays there are also sensors from other providers, such as seeedstudio that have the same pin-out but with a different pin spacing (2 mm). This is not a problem, as there are cables to adapt the pin spacing.
+As probably noticed by now, we normally refer to yielding and waiting for a process. Contiki has two execution contexts: cooperative and preemptive. Processes are cooperative and sequential, interrupts (button, sensors events) and the real-timer are preemptive.
---
+
Figure 34. Analogue sensors+Figure 36. Execution contexts: processes and interrupts+As we have learned before, there are two ways so far to yield a protothread:
-The ADC results in the RE-Mote returns the reading in voltage.
+PROCESS_YIELD()will wait for any type of process event to happen, it will not check which process has occured. Often a check likeif(ev == PROCESS_EVENT_NAME){}is used to catch one or more processes.--For the Z1 mote the ADC output must be converted by means of the following formula: We multiply the measured value by the voltage reference and divide the product by the ADC’s maximum output. As the resolution of the ADC is 12 bits (212 = 4096), we get:
+On the other hand the
PROCESS_WAIT_EVENT_UNTIL(…)allows to catch a process event direclty, in the case of theetimeras previously shown, we can yield until:--Voltage, mV = (units * Vref) / 4096;
+++PROCESS_WAIT_EVENT_UNTIL(ev == PROCESS_EVENT_TIMER)+Or simply:
-The voltage reference limits the range of our measure, meaning if we use a
+Vrefof 2.5 V, the sensor will saturate when reading a higher voltage. The reference can be chosen while configuring the ADC, for both the Z1 and RE-Mote normally 3.3 V is used.PROCESS_WAIT_EVENT_UNTIL(etimer_expired(&et))-Both the Z1 and the RE-Mote allow up to 6 analogue sensors to be connected, but only two phidget connectors can be soldered at the same time.
+To catch just an
etimerevent from timeret.--For the RE-Mote it is possible to have one phidget connector for a 3.3 V analogue sensor (ADC1) and another for 5 V sensors (ADC3).
+Similar to
PROCESS_YIELD(), thePROCESS_PAUSE()macro will pause the thread, but instead of waiting for an event to happen it will temporatily pause the process, by posting an event to itself and yielding. This allows the system to execute other processes and whenever done then resume our process.--
+- -- - -The RE-Mote is based on an ARM Cortex-M3, this allows to map any given pin to a controller (as opposite to the MSP430, for which a pin has predefined functions other than GPIO), but only pins in the PA port can be used as ADC.
+The
PROCESS_EXIT()macro will allow the application to exit before reachingPROCESS_END(), it will send aPROCESS_EVENT_EXITEDprocess notification whenever that happens.+The
04-processes.cexample shows how to create and terminate process, more importantly how to communicate between process.--For the Z1 mote is possible to have the following combinations (see Figure below):
----
-
---
-Figure 35. Pin assignement+Processes are useful as they allow to run different parts of our application, in its own semantic context, allowing a cleaner and efficient implementation. For example imagine a process running all the networking part, while separate processes take readings from individual sensors, each one running on its own context.
-In the snippet below the ADC channels ADC0 (5V1), ADC3 (5V2), ADC1 (3V1) and ADC7 (3V2) are mapped by default to be used as input for external analogue sensors.
+The example consist of 3 processes, one will spawn another process and receive events about a variable being incremented. When the variable value reaches a limit, the first process will terminate its child process. A third process listening in stand-by will receive a notification about the terminated process and restart it again.
+-
+/* MemReg6 == P6.0/A0 == 5V 1 */ -ADC12MCTL0 = (INCH_0 + SREF_0); -/* MemReg7 == P6.3/A3 == 5V 2 */ -ADC12MCTL1 = (INCH_3 + SREF_0); -/* MemReg8 == P6.1/A1 == 3V 1 */ -ADC12MCTL2 = (INCH_1 + SREF_0); -/* MemReg9 == P6.7/A7 == 3V_2 */ -ADC12MCTL3 = (INCH_7 + SREF_0);
+PROCESS(process1, "Main process"); +PROCESS(process2, "Auxiliary process"); +PROCESS(process3, "Another auxiliary process"); + +/* But we are only going to automatically start the first two */ +AUTOSTART_PROCESSES(&process1, &process2);+We define the three processes to run, but notice we only automatically start the first two. As opposite to what we have been working with before, after the
Z1orRE-Moteplatform finishes booting it will only call the processes declared within theAUTOSTART_PROCESSES(…)macro, leavingprocess3not started for now.-To read from a sensor connected to the ADC7 channel of the Z1 mote, in my code I would need to make the following steps:
+Let’s review how the first process is implemented:
-
+#include "dev/z1-phidgets.h" (1) -SENSORS_ACTIVATE(phidgets); (2) -printf("Phidget 5V 1:%d\n", phidgets.value(PHIDGET3V_2)); (3)PROCESS_THREAD(process1, ev, data) +{ + PROCESS_BEGIN(); + static uint8_t counter; + printf("Process 1 started\n"); + process_start(&process3, "Process 1"); (1) + + while(1) { + PROCESS_YIELD(); (2) + if(ev == event_from_process3) { (3) + counter = *((uint8_t *)data); (4) + printf("Process 3 has requested shutdown in %u seconds\n", counter); + etimer_set(&et1, CLOCK_SECOND); + } + + if(ev == PROCESS_EVENT_TIMER) { (5) + if(counter <= 0) { + process_exit(&process3); (6) + } else { + printf("Process 3 will be terminated in: %u\n", counter); + counter--; + leds_toggle(LEDS_RED); + etimer_reset(&et1); + } + } + } + PROCESS_END(); +}1 -Include the driver header +When process1starts, it will launchprocess3, when starting a process one can pass variables or data as a argument (in this example a string "Process 1")2 -Enable the ADC sensors, as default all 4 ADC channels are enabled +And then will wait for any event… 3 -Request a reading +Note the +process1has two additional arguments:evanddata, when a process posts information to another process, it uses these arguments to pass information such as a pointer to a variable.+ +4 +If we receive an event from +process3it will mean that process has requested an early termination, so we start anetimer…+ +5 +And when our +etimerexpires…+ 6 +We will terminate process3--The Z1 is powered at 3.3 V, but when connected over the USB (standard voltage 5 V) it allows to connect 5 V sensors to the phidget ports, namely 5V1 (ADC3) and 5V2 (ADC0) as there is a voltage divider in the input to adapt the reading from 5 V to 3.3 V.
---Details about the Z1 implementation of the analogue sensors driver are available at
-platform/z1/dev/z1-phidgets.c.There is also a driver for the MSP430 internal voltage sensor atplatform/z1/dev/battery-sensor.c, with an example atexamples/zolertia/z1/test-battery.c.--to see the ADC implementation with an example, let’s connect the Phidget 1142 precision Light Sensor.
-----
-Figure 36. Light sensor---The example called
-test-phidgets.cinexamples/zolertia/z1will read values from an analog sensor and print them to the terminal.-Connect the light sensor to the 3V2 Phidget connector and compile the example:
+As seen above
process3is terminated byprocess1whenever "something" happens atprocess3, but what aboutprocess2?--
+make clean && make test-phidgets.upload && make z1-reset && make loginPROCESS_THREAD(process2, ev, data) +{ + PROCESS_BEGIN(); + printf("Process 2 started\n"); + + while(1) { + PROCESS_YIELD(); + if(ev == PROCESS_EVENT_EXITED) { (1) + printf("* Process 3 has been stopped by Process 1!\n"); + etimer_set(&et2, CLOCK_SECOND * 5); (2) + } + + if(ev == PROCESS_EVENT_TIMER) { (3) + printf("Process 2 is restarting Process 3\n"); + process_start(&process3, "Process 2"); (4) + } + } + + PROCESS_END(); +}+- +- - -- +--You can pipeline commands to be executed one after another, in this case the
-make z1-resetrestarts the mote after flashed, thenmake loginprints to console the output of anyprintfcommand in our code. You may need to use the argumentMOTES=/dev/ttyUSB[0…9]to specify a mote over a particular USB port.1 +When +process3is terminated byprocess1, we receive a notification+ +2 +And start a 5-second timer… ++ +3 +When the +etimerexpires…+ 4 +process2will launch back againprocess3, and will send its own name as string-This is the result:
+We have now read the implementation of
process1andprocess2and learned how to start and end processes, and receive data using thedataargument. Let’s check howprocess3is implemented:---
-Starting 'Test Button & Phidgets' -Please press the User Button -Phidget 5V 1:123 -Phidget 5V 2:301 -Phidget 3V 1:1710 -Phidget 3V 2:2202--The light sensor is connected to the 3V2 connector, so the raw value is 2202. Try to illuminate the sensor with a flashlight (from your mobile phone, for example) and then cover it with your hand so that no light can reach it.
+PROCESS_THREAD(process3, ev, data) +{ + PROCESS_BEGIN(); + static char *parent; + parent = (char * )data; (1) + static uint8_t counter; (2) + + printf("Process 3 started by %s\n", parent); + event_from_process3 = process_alloc_event(); (3) + etimer_set(&et3, CLOCK_SECOND); + + counter = 0; + + while(1) { + PROCESS_WAIT_EVENT_UNTIL(etimer_expired(&et3)); + counter++; + leds_toggle(LEDS_GREEN); + + if(counter == 10) { + process_post(&process1, event_from_process3, &counter); (4) + } + etimer_reset(&et3); (5) + } + PROCESS_END(); +}--From the Phidget website we have the following information about the sensor:
-
- - -- - - - - -Parameter -Value -- - - -Light level max (5 V)
1000 lux
- +Sensor type
Light
+
+- Light level min
1 lux
1 +Create a pointer to read the processes name passed as string argument to us - Supply Voltage Min
2.4 V
2 +Create a variable to increment - Supply Voltage Max
5.5 V
3 +Allocate a process event to use and communicate to other processes - Max current consumption
5mA
4 +When the counter reaches 10, send an event_from_process3event toprocess1with a pointer to thecountervariable- -Light level max (3.3 V)
660 lux
5 +Reset the etimerusing the current expiration value previously configured-As you can see, the light sensor can be connected to either the 5 V or the 3.3 V Phidget connector. The max measurable value depends on where you connect it.
+The
event_from_process3process event was previously declared in our example as:-+The formula to translate SensorValue into luminosity is: -
+Luminosity(lux)=SensorValue
+process_event_t event_from_process3;+Sensors
-+The RE-Mote platform also allows to connect 5 V sensors to the ADC3 port, using the same voltage divider as the Z1 mote. As seen in the next snippet, the ADC3 port is mapped to the PA2 pin.
+A sensor is a transducer whose purpose is to sense or detect a characteristic of its environment, providing a corresponding output, generally as an electrical or optical signal, related to the quantity of the measured variable.
++Sensors in Contiki are implemented as follow:
--
+/* - * This driver supports analogue sensors connected to ADC1, ADC2 and AND3 inputs - * This is controlled by the type argument of the value() function. Possible - * choices are: - * - REMOTE_SENSORS_ADC1 (channel 5) - * - REMOTE_SENSORS_ADC2 (channel 4) - * - REMOTE_SENSORS_ADC3 (channel 2) - */SENSORS_SENSOR (sensor, SENSOR_NAME, value, configure, status);+++This means that a method to
+configurethe sensor, poll the sensorstatusand request avaluehave to be implemented. Thesensorstructure contains pointers to these functions. The arguments for each function are shown below.+--
+struct sensors_sensor { + char * type; + int (* value) (int type); + int (* configure) (int type, int value); + int (* status) (int type); +};Figure 37. Connecting sensor+++
++ ++ + +Then to read data from an attached sensor (as we did in the previous example):
+If you need to further expand the available functions (change the
+intreturn value of thevaluefunction to return a pointer instead, etc) or add your own, you can edit this structure, but keep in mind it will probably break other sensors developed based on this. You can define additional sensor and actuators functions in your header file instead.++To better understand please refer to the
+platform/zoul/dev/adc-sensors.c, for an example of how analogue external sensors can be implemented (to be further discussed in the next sections).+The following functions and macros can be used to work with the sensor:
-
+#include "dev/zoul-sensors.h" (1) -adc_sensors.configure(SENSORS_HW_INIT, REMOTE_SENSORS_ADC_ALL); (2) -printf("Phidget ADC2 = %d raw\n", adc_sensors.value(REMOTE_SENSORS_ADC2)); (3) -printf("Phidget ADC3 = %d raw\n", adc_sensors.value(REMOTE_SENSORS_ADC3));SENSORS_ACTIVATE(sensor) (1) +SENSORS_DEACTIVATE(sensor) (2) +sensor.value(type); (3)-1 -Include the ADC driver header +Enable the sensor, typically configures and turns the sensor on 2 -Enable and configure the ADC channels (can selectively choose which to enable) +Disables the sensor, it is useful to save power 3 -Request a reading +Request a value to the sensor. As one sensor chip might have different types of readings (temperature, humidity, etc.), this is used to specify which measure to take. --Check the RE-Mote example at
-example/zolertia/zoul/zoul-demo.cfor more details.++- + -Exercise: make the sensor take readings as fast as possible. Print to the screen the ADC raw values and the millivolts (as this sensor is linear, the voltage corresponds to the luxes). What are the max and min values you can get? What is the average light value of the room? Create an application that turns the red LED on when it is dark and the green LED on when the room is bright. In between, all the LEDs should be off. Add a timer and measure the light every 10 seconds. + +Although this is the default way to implement sensors in Contiki, there might be alternatives, depending on the sensor and developer. Always check the specific sensor driver implementation for details. Normally sensors are provided in the same location as the example, in the
+devfolder, or in theplatform/zoul/devdirectory for example.+-The
SENSORSmacro provides external linkage to the sensors defined for the platform and application, allowing to iterate between the available sensors. The following are the sensors defined as default for the RE-Mote platform:-Digital Sensors
-+---Digital sensors are normally interfaced over a digital communication protocol such as I2C, SPI, 1-Wire, Serial or depending on the manufacturer, a proprietary protocol normally on a ticking clock.
+SENSORS (&button_sensor, &vdd3_sensor, &cc2538_temp_sensor, &adc_sensors);-+Digital sensors allow a more extended set of commands (turn on, turn off, configure interrupts). With a digital light sensor for example, you could set a threshold value and let the sensor send an interrupt when reached, without the need for continuous polling.
++
+ ++ + +Remember to check the specific sensor information and data sheet for more information.
-The button is considered a sensor in Contiki, and it shares the same sensor implementation
--The Z1 mote has two built in digital sensors: temperature and 3-axis accelerometer. Let us start with the latter, there is an example called
+test-adxl345.cavailable for testing.-The ADXL345 is an I2C ultra-low power sensor able to read up to 16g, well suited for mobile device applications. It -measures the static acceleration of gravity in tilt-sensing applications, as well as dynamic acceleration resulting from motion or shock. Its high resolution (3.9mg/LSB) enables measurement of inclination changes smaller than 1.0°.
+This macro extends to:
---
-[37] DoubleTap detected! (0xE3) -- DoubleTap Tap -x: -1 y: 12 z: 223 -[38] Tap detected! (0xC3) -- Tap -x: -2 y: 8 z: 220 -x: 2 y: 4 z: 221 -x: 3 y: 5 z: 221 -x: 4 y: 5 z: 222--The accelerometer can read data in the x, y and z axis and has three types of interrupts: a single tap, a double tap and a free-fall (be careful to not damage the mote!).
+const struct sensors_sensor *sensors[] = { + &button_sensor, + &vdd3_sensor, + &cc2538_temp_sensor, + &adc_sensors, + ((void *)0) +};-The code has two threads, one for the interruptions and the other for the LEDs. When Contiki starts, it triggers both processes.
-The
+led_processthread triggers a timer that waits before turning off the LEDs. This is mostly done to filter the rapid signal coming from the accelerometer. The other process is the acceleration. It assigns the callback for theled_offevent. -Interrupts can happen at any given time, are non periodic and totally asynchronous.For the
Z1mote theSENSORSmacro is defined within theplatforms/z1/contiki-z1-main.c:-Interrupts can be triggered by external sources (sensors, GPIOs, Watchdog Timer, etc) and should be cleared as soon as possible. When an interrupts happens, the interrupt handler (which is a process that checks the interrupt registers to find out which is the interrupt source) manages it and forwards it to the subscribed callback.
+SENSORS(&button_sensor);-In this example, the accelerometer is initialized and then the interrupts are mapped to a specific callback functions. Interrupt source 1 is mapped to the free fall callback handler and the tap interrupts are mapped to the interrupt source 2.
+The number of sensors can be found with the
SENSORS_NUMmacro:-
+/* - * Start and setup the accelerometer with default - * values, _i.e_ no interrupts enabled. - */ -accm_init(); -/* Register the callback functions */ -ACCM_REGISTER_INT1_CB(accm_ff_cb); -ACCM_REGISTER_INT2_CB(accm_tap_cb);#define SENSORS_NUM (sizeof(sensors) / sizeof(struct sensors_sensor *))--We then need to enable the interrupts like this:
+Sensors can be of two types: analogue or digital. In the following sections examples will be shown for both types, detailing how to connect and use both the platform’s internal sensors as well as the external ones.
++-Analogue Sensors
+-In the while loop we read the values from each axis every second. If there are no interrupts, this will be the only thing shown in the terminal.
+The
Z1mote and theRE-Motehave a built-in voltage sensor provided as an ADC input channel, as well as a generic implementation to read external analogue sensors.--For the next example we will use the ZIG-SHT25, an I2C digital temperature and humidity sensor based on the SHT25 sensor from Sensirion.
+The ADC results in the
RE-Motereturns the reading in voltage directly, there’s no need to further conversion.+-++For the Z1 mote the ADC output must be converted by means of the following formula: We multiply the measured value by the voltage reference and divide the product by the ADC’s maximum output. As the resolution of the ADC is 12 bits (212 = 4096), we get:
+---
+Voltage, mV = (units * Vref) / 4096;
Figure 38. Temperature and humidity sensor-
- - -- - - - - -Parameter -Value -- - - -Max current consumption
300 uA
- -Sensor type
Temperature and Humidity
- -Supply Voltage [V]
2.1 - 3.6
- -Energy Consumption
3.2 uW (at 8 bit, 1 measurement / s)
- -Data range
0-100 % RH (humidity), -40-125ºC (temperature)
- - -Max resolution
14 bits (temperature), 12 bits (humidity)
--The ZIG-SHT25 sensor example is available in both
+examples/zolertia/zoul/test-sht25.candexamples/zolertia/z1/test-sht25.c, an output example is given below:The voltage reference limits the range of our measure, meaning if we use a
Vrefof 2.5 V, the sensor will saturate when reading a higher voltage. The reference can be chosen while configuring the ADC, for both theZ1andRE-Motenormally 3.3 V is used.+-++Both the
+Z1and theRE-Moteallow up to 6 analogue sensors to be connected, but only two analogue connectors can be soldered at the same time.++For the
+RE-Moteit is possible to have one analogue connector for a 3.3 V analogue sensor (ADC1) and another for 5 V sensors (ADC3).-+
+Starting 'SHT25 test' -Temperature 23.71 ºC -Humidity 42.95 % RH -Temperature 23.71 ºC -Humidity 42.95 % RH -Temperature 23.71 ºC -Humidity 42.95 % RH -Temperature 23.71 ºC -Humidity 42.98 %RH
Figure 38. RE-Mote ADC pin-out-+As usual you can check the driver implementation at the
+platform/z1/devandplatform/zoul/devdirectories. Check out these locations for other sensors and examples to guide you to implement your own.Note the location of the analogue connectors in the image below.
++++
+Figure 39. Available connectors in the RE-Mote--Emulate Contiki with Cooja
--Cooja is the Contiki network emulator. Cooja allows large and small networks of Contiki motes to be emulated at the hardware level, which is slower but allows precise inspection of the system behavior, or at a less detailed level, which is faster and allows simulation of larger networks.
+For the
Z1mote is possible to have the following combinations (see Figure below):-Cooja is a highly useful tool for Contiki development as it allows developers to test their code and systems long before running it on the target hardware. Developers regularly set up new simulations both to debug their software and to verify the behavior of their systems.
++--
+
-Most of the examples below can be emulated in Cooja as well (except the sensor ones).
++++
+Figure 40. Pin assignment-In the terminal window go to the Cooja directory:
+In the snippet below the ADC channels ADC0 (5V1), ADC3 (5V2), ADC1 (3V1) and ADC7 (3V2) are mapped by default to be used as input for external analogue sensors.
-
+cd contiki/tools/cooja/* MemReg6 == P6.0/A0 == 5V 1 */ +ADC12MCTL0 = (INCH_0 + SREF_0); +/* MemReg7 == P6.3/A3 == 5V 2 */ +ADC12MCTL1 = (INCH_3 + SREF_0); +/* MemReg8 == P6.1/A1 == 3V 1 */ +ADC12MCTL2 = (INCH_1 + SREF_0); +/* MemReg9 == P6.7/A7 == 3V_2 */ +ADC12MCTL3 = (INCH_7 + SREF_0);-Start Cooja with the command:
+To read from a sensor connected to the ADC7 channel of the
Z1mote, in my code I would need to make the following steps:--
+ant run#include "dev/z1-phidgets.h" (1) +SENSORS_ACTIVATE(phidgets); (2) +printf("Phidget 5V 1:%d\n", phidgets.value(PHIDGET3V_2)); (3)--When Cooja is compiled, it will show a blue empty window. Now that Cooja is up and running, we can try it out with an example simulation.
+++
+ +1 +Include the driver header ++ +2 +Enable the ADC sensors, as default all 4 ADC channels are enabled ++ +3 +Request a reading +-Go to
+File,Open Simulation,Browsethen navigate to theexamples/hello-worldand select thehello-world-example.csc. This will load the previously saved hello world example.The
Z1is powered at 3.3 V, but when connected over the USB (standard voltage 5 V) it allows to connect 5 V sensors to the phidget ports, namely 5V1 (ADC3) and 5V2 (ADC0) as there is a voltage divider in the input to adapt the reading from 5 V to 3.3V.-+If you want to edit an example (for istance, to use a different type of platform), instead of choosing the
-Browseoption, selectOpen and Reconfigure, this will walk you through the steps to configure the example.Details about the
Z1implementation of the analogue sensors driver are available atplatform/z1/dev/z1-phidgets.c.-Create a new simulation
--Click the
+Filemenu and clickNew simulation. Cooja now opens up theCreate new simulationdialog. In this dialog, we may choose to give our simulation a new name, but for this example, we’ll just stick withMy simulation. Leave the other options at default values. Click theCreatebutton.There is also a driver for the MSP430 internal voltage sensor at
platform/z1/dev/battery-sensor.c, with an example atexamples/zolertia/z1/test-battery.c.-Cooja brings up the new simulation. You can choose what you want to visualize by using the
+Toolsmenu. TheNetworkwindow shows all the motes in the simulated network, it should be empty now since we have no motes in our simulation. TheTimelinewindow shows all communication events in the simulation over time - very handy for understanding what goes on in the network. TheMote outputwindow shows all serial port printouts from all the motes. TheNoteswindow is where we can put notes for our simulation. And theSimulation controlwindow is where we start, pause, and reload our simulation.+-+#include "dev/battery-sensor.h" +/*---------------------------------------------------------------------------*/ +PROCESS(test_battery_process, "Battery Sensor Test"); +AUTOSTART_PROCESSES(&test_battery_process); +/*---------------------------------------------------------------------------*/ +PROCESS_THREAD(test_battery_process, ev, data) +{ + static uint32_t battery; + PROCESS_BEGIN(); + SENSORS_ACTIVATE(battery_sensor); + + while(1) { + battery = battery_sensor.value(0); + battery *= 5000; + battery /= 4096; + printf("Battery: %u.%02uV\n", (uint16_t)battery / 1000, (uint16_t)battery % 1000); + } + PROCESS_END(); +}-Add motes to the simulation
--Before we can simulate our network, we must add one or more motes. We do this via the
+Motesmenu, where we click onAdd motes. Since this is the first mote we add, we must first create a mote type to add. ClickCreate new mote typeand select one of the available mote types. For this example, we clickZ1 moteto create an emulated Z1 mote type. Cooja opens theCreate Mote Typedialog, in which we can choose a name for our mote type as well as the Contiki application that our mote type will run.When the USB is connected or the battery is full, the result is similar to:
-For this example, we stick with the suggested name, and click on the
+Browsebutton on the right hand side to choose our Contiki application.+++Battery: 3.21V +Battery: 3.18V +Battery: 3.20V +Battery: 3.18V +Battery: 3.20V +Battery: 3.20V +Battery: 3.18V +Battery: 3.20V +Battery: 3.18V++It is possible also to connect an external analogue sensor, like the Phidget 1142 precision Light Sensor or the Grove/Seeedstudio Light Sensor (P).
++-
-Wireless with Contiki
----In the previous section we covered some of the core features of Contiki, basics of sensors and a general overview of how the applications are built, programmed and simulated in Contiki. This section introduces the wireless communication, details about radios, and basics ideas about configuring our platforms.
+Figure 41. Phidget 1142 Light sensor-Preparing your device
--The very first step is understanding how our platform is configured.
+++-
-Each platform implements its own set of default values and configurations, to be used by underlying modules like the radio, the serial port, etc.
+Figure 42. Seeedstudio (Grove) Light sensor--The places to visit for the Zolertia platform are the following:
---
-
The example called
test-phidgets.cinexamples/zolertia/z1will read values from an analog sensor and print them to the terminal.-As a general good practice, user configurable parameters are normally allowed to be overridden by the applications, this also serves as a guideline to discern which values can be changed by the casual user, from those meant to be changed only if you really know what you are doing. Below is an example:
+Connect the light sensor to the 3V2 Phidget connector and compile the example:
--+
-#ifndef UART0_CONF_BAUD_RATE -#define UART0_CONF_BAUD_RATE 115200 -#endifmake clean && make test-phidgets.upload && make z1-reset && make login-By defining
UART0_CONF_BAUD_RATEin our application’sproject-conf.h, we can change the default 115200 baud rate. Notice that generally it is a good practice to addCONFto the user configurable parameters.-+In the next section we will review the most notable parameters to configure, but as usual depending on your application and setup, the best way to ensure everything is properly set is by reviewing the specific platform configuration files, and modify or redefine accordingly.
+This is the result:
+++-Starting 'Test Button & Phidgets' +Please press the User Button +Phidget 5V 1:123 +Phidget 5V 2:301 +Phidget 3V 1:1710 +Phidget 3V 2:2202-Device addressing
---To start working you must first define the Node ID of each node, this will be used to generate the mote’s MAC address and the IPv6 addresses (link-local and global).
-RE-Mote addresses
--The RE-Mote platform comes with two pre-loaded MAC addresses stored in its internal flash memory, but the user can instead choose a hardcoded one. The following switches at
-platform/zoul/contiki-conf.hselects the chosen one.--+
-/** - * \name IEEE address configuration - * - * Used to generate our RIME & IPv6 address - * @{ - */ -/** - * \brief Location of the IEEE address - * 0 => Read from InfoPage, - * 1 => Use a hardcoded address, configured by IEEE_ADDR_CONF_ADDRESS - */ -#ifndef IEEE_ADDR_CONF_HARDCODED -#define IEEE_ADDR_CONF_HARDCODED 0 -#endif - -/** - * \brief Location of the IEEE address in the InfoPage when - * IEEE_ADDR_CONF_HARDCODED is defined as 0 - * 0 => Use the primary address location - * 1 => Use the secondary address location - */ -#ifndef IEEE_ADDR_CONF_USE_SECONDARY_LOCATION -#define IEEE_ADDR_CONF_USE_SECONDARY_LOCATION 0 -#endifThe light sensor is connected to the 3V2 connector, so the raw value is 2202. Try to illuminate the sensor with a flashlight (from your mobile phone, for example) and then cover it with your hand so that no light can reach it.
--If using your own hardcoded address, the following define can be overridden by the application:
---+
+#ifndef IEEE_ADDR_CONF_ADDRESS -#define IEEE_ADDR_CONF_ADDRESS { 0x00, 0x12, 0x4B, 0x00, 0x89, 0xAB, 0xCD, 0xEF } -#endifFrom the Phidget website we have the following information about the sensor:
+
++ + ++ + + + + +Parameter +Value ++ + + +Light level max (5 V)
1000 lux
+ +Sensor type
Light
+ +Light level min
1 lux
+ +Supply Voltage Min
2.4 V
+ +Supply Voltage Max
5.5 V
+ +Max current consumption
5mA
+ + +Light level max (3.3 V)
660 lux
++As you can see, the light sensor can be connected to either the 5 V or the 3.3 V analogue connector. The max measurable value depends on where you connect it.
+-The formula to translate SensorValue into luminosity is: +
Luminosity(lux)=SensorValue-Z1 mote addresses
-Let’s use the ID from the mote list:
+The RE-Mote platform also allows to connect 5 V sensors to the ADC3 port, using the same voltage divider as the Z1 mote. As seen in the next snippet, the ADC3 port is mapped to the PA2 pin.
---
-Reference Device Description --------------------------------------------------- -Z1RC3301 /dev/ttyUSB0 Silicon Labs Zolertia Z1--The node ID should be
+3301(decimal) if no previously saved node ID is found in the flash memory./* + * This driver supports analogue sensors connected to ADC1, ADC2 and AND3 inputs + * This is controlled by the type argument of the value() function. Possible + * choices are: + * - REMOTE_SENSORS_ADC1 (channel 5) + * - REMOTE_SENSORS_ADC2 (channel 4) + * - REMOTE_SENSORS_ADC3 (channel 2) + */--Let’s see how Contiki uses this to derive a full IPv6 and MAC address. At
platforms/z1/contiki-z1-main.c+-+
+#ifdef SERIALNUM - if(!node_id) { - PRINTF("Node id is not set, using Z1 product ID\n"); - node_id = SERIALNUM; - } -#endif -node_mac[0] = 0xc1; /* Hardcoded for Z1 */ -node_mac[1] = 0x0c; /* Hardcoded for Revision C */ -node_mac[2] = 0x00; /* Hardcoded to arbitrary even number so that the 802.15.4 MAC address is compatible with an Ethernet MAC address - byte 0 (byte 2 in the DS ID) */ -node_mac[3] = 0x00; /* Hardcoded */ -node_mac[4] = 0x00; /* Hardcoded */ -node_mac[5] = 0x00; /* Hardcoded */ -node_mac[6] = node_id >> 8; -node_mac[7] = node_id & 0xff; -}
Figure 43. RE-Mote ADC3 voltage divider for 5V analogue sensors-So the mote should have the following addresses:
+Then to read data from an attached sensor (as we did in the previous example):
--
+MAC c1:0c:00:00:00:00:0c:e5 -Node id is set to 3301. -Tentative link-local IPv6 address fe80:0000:0000:0000:c30c:0000:0000:0ce5#include "dev/zoul-sensors.h" (1) +adc_sensors.configure(SENSORS_HW_INIT, REMOTE_SENSORS_ADC_ALL); (2) +printf("ADC1 = %d raw\n", adc_sensors.value(REMOTE_SENSORS_ADC1)); (3) +printf("ADC3 = %d raw\n", adc_sensors.value(REMOTE_SENSORS_ADC3));-Where
+0xce5is the hex value corresponding to3301. The global address is only set when an IPv6 prefix is assigned (by now you should know this from earlier sections).++
+ +1 +Include the ADC driver header ++ +2 +Enable and configure the ADC channels (can selectively choose which to enable) ++ +3 +Request a reading +-If instead you wish to have your own addressing scheme, you can edit the node_mac values at
+contiki-z1-main.cfile. If you wish to replace the node id value obtained from the product id, you need to store a new one in the flash memory, luckily there is already an application to do so:Note the ADC3 voltage reading has to be multiplied by 3/2 to get the actual 0-5V range value, as there is a voltage divider with a 500K/200K relationship.
--Go to
+examples/zolertia/z1location and replace the158for your own required value:Now let’s connect a
Grove Light Sensorto theRE-Mote:+-+
+make clean && make burn-nodeid.upload nodeid=158 nodemac=158 && make z1-reset && make login
Figure 44. RE-Mote and Grove light sensor-You should see the following:
+Compile and program the RE-Mote example at
example/zolertia/zoul/zoul-demo.c, the output should be similar to:-
+MAC c1:0c:00:00:00:00:0c:e5 Ref ID: 3301 -Contiki-2.6-1803-g03f57ae started. Node id is set to 3301. -CSMA ContikiMAC, channel check rate 8 Hz, radio channel 26 -Tentative link-local IPv6 address fe80:0000:0000:0000:c30c:0000:0000:0ce5 -Starting 'Burn node id' -Burning node id 158 -Restored node id 158connecting to /dev/ttyUSB0 (115200) [OK] +----------------------------------------- +Counter = 0x00000000 +VDD = 3299 mV +Temperature = 33333 mC +ADC1 = 112 raw +ADC3 = 1516 raw--As you can see, now the node ID has been changed to 158, when you restart the mote you should see that the changes have been applied:
+The above result was taken with the light sensor covered, so aproximately with no light the voltage value is 0.112V. This light sensor has a light-dependent resistor (LDR), the output in voltage units correlates to the equivalent LDR. The Grove wiki page shows how the resistance/luxes graphs to obtain proper lux values, but probably a better option is to calibrate by using a known lux source, or just knowing the smaller the value the darkest the ambient is.
--
+MAC c1:0c:00:00:00:00:00:9e Ref ID: 3301 -Contiki-2.6-1803-g03f57ae started. Node id is set to 158. -CSMA ContikiMAC, channel check rate 8 Hz, radio channel 26 -Tentative link-local IPv6 address fe80:0000:0000:0000:c30c:0000:0000:009e+++
+ ++ + ++Exercise: make the sensor take readings as fast as possible. Print to the screen the ADC raw values and the millivolts (as this sensor is linear, the voltage corresponds to the luxes). What are the max and min values you can get? What is the average light value of the room? Create an application that turns the red LED on when it is dark and the green LED on when the room is bright. In between, all the LEDs should be off. Add a timer and measure the light every 10 seconds. + +++Note the
RE-Motehas built-in voltage and core temperature sensors. The voltage sensor provides the voltage level of theCC2538system on chip, whereas the core temperature gives the operation temperature. As shown in the previous code snippet, thezoul-demo.cexample also shows how to use both sensors:+-+printf("VDD = %d mV\n", + vdd3_sensor.value(CC2538_SENSORS_VALUE_TYPE_CONVERTED)); + + printf("Temperature = %d mC\n", + cc2538_temp_sensor.value(CC2538_SENSORS_VALUE_TYPE_CONVERTED));-+Set the bandwidth and channel
-The bandwidth and allowed channels depend on the operating frequency band. They will be determined by the spectrum regulation agency of the country, along with maximum transmitted power allowable. -.The IEEE 802.15.4 standard
+Both sensors are initialized at booting by the
+RE-Mote.+Digital Sensors
-The IEEE 802.15.4 is a standard for wireless communication, it specifies the physical and media access control layers for low-rate wireless personal area networks (LR-WPANs).
+Digital sensors are normally interfaced over a digital communication protocol such as I2C, SPI, 1-Wire, Serial or depending on the manufacturer, a proprietary protocol normally on a ticking clock.
-+The standard specifies the use of the 868-868.8 MHz (in Europe and many other countries), the 902-928 MHz (in United States, Canada, and some Latin America countries), or the world-wide 2.400-2.4835 GHz band part of the Industrial Scientific and Medical applications (ISM).
+Digital sensors allow a more extended set of commands (turn on, turn off, configure interrupts). With a digital light sensor for example, you could set a threshold value and let the sensor send an interrupt when reached, without the need for continuous polling.
++-Remember to check the specific sensor information and data sheet for more information.
---
Figure 39. IEEE 802.15.4 2.4 GHz regulation requirements (electronicdesign.com, 2013)-In practice the 2.4 GHz band is being heavily used due to its world-wide availability. The ZigBee proprietary protocol by the ZigBee alliance was one of the early adopters of IEEE 802.15.4. It did so leveraging the physical and MAC layer of IEEE 802.15.4, specifying on top additional routing and networking functionality to build mesh networks.
+The Z1 mote has two built in digital sensors: temperature and 3-axis accelerometer. The
ADXL345accelerometer has an example namedtest-adxl345.cinexamples/zolertia/z1showing how the sensor works.--Quite recently the Thread Group -has proposed its own simplified IPv6-based mesh networking protocol for connecting products around the home to each other, to the Internet and to the cloud. This will surely boost the adoption of IEEE 802.15.4 and IPv6.
+The
ADXL345is an I2C ultra-low power sensor able to read up to 16g, well suited for mobile device applications. It measures the static acceleration of gravity in tilt-sensing applications, as well as dynamic acceleration resulting from motion or shock. Its high resolution (3.9mg/LSB) enables measurement of inclination changes smaller than 1.0°.++--
+[37] DoubleTap detected! (0xE3) -- DoubleTap Tap +x: -1 y: 12 z: 223 +[38] Tap detected! (0xC3) -- Tap +x: -2 y: 8 z: 220 +x: 2 y: 4 z: 221 +x: 3 y: 5 z: 221 +x: 4 y: 5 z: 222Figure 40. Thread layers and standards (Thread group, 2015)++The accelerometer can read data in the x, y and z axis and has three types of interrupts: a single tap, a double tap and a free-fall (be careful to not damage the mote!).
+-Having an accelerometer on-board is quite useful: you can detect if anyone is tampering with the device, or detect if someone falls, monitor vibration and generate an alarm if exceeds a given threshold (causing a component to break), etc.
-Working at 2.4 GHz
--As the 2.4 GHz band is also used by other technologies like WiFi and Bluetooth, this spectrum is shared and overlaps might occur. The Figure below shows the channel allocation of the 2.4 GHz IEEE 802.15.4, and the recommended channels to avoid interferences with other co-located devices. With the rise of the Bluetooth Low Energy, and the ubiquitous WiFi present in our lives, the selection of a proper operating channel is crucial in any deployment.
+The code has two threads, one for the interruptions and the other for the LEDs. When Contiki starts, it triggers both processes.
--
++-The
led_processthread triggers a timer that waits before turning off the LEDs. This is mostly done to filter the rapid signal coming from the accelerometer. The other process is the acceleration. It assigns the callback for theled_offevent. +Interrupts can happen at any given time, are non periodic and totally asynchronous.Figure 41. Channel assignment++Interrupts can be triggered by external sources (sensors, GPIOs, Watchdog Timer, etc) and should be cleared as soon as possible. When an interrupts happens, the interrupt handler (which is a process that checks the interrupt registers to find out which is the interrupt source) manages it and forwards it to the subscribed callback.
-The default channel of the RE-Mote is defined as follows:
+In this example, the accelerometer is initialized and then the interrupts are mapped to a specific callback functions. Interrupt source 1 is mapped to the free fall callback handler and the tap interrupts are mapped to the interrupt source 2.
-
+#ifndef CC2538_RF_CONF_CHANNEL -#define CC2538_RF_CONF_CHANNEL 26 -#endif /* CC2538_RF_CONF_CHANNEL *//* + * Start and setup the accelerometer with default + * values, _i.e_ no interrupts enabled. + */ +SENSORS_ACTIVATE(adxl345); +/* Register the callback functions */ +ACCM_REGISTER_INT1_CB(accm_ff_cb); +ACCM_REGISTER_INT2_CB(accm_tap_cb);-The Z1 mote defines its default channel as:
+We then need to enable the interrupts like this:
--+
-#ifdef RF_CHANNEL -#define CC2420_CONF_CHANNEL RF_CHANNEL -#endif - -#ifndef CC2420_CONF_CHANNEL -#define CC2420_CONF_CHANNEL 26 -#endif /* CC2420_CONF_CHANNEL */accm_set_irq(ADXL345_INT_FREEFALL, + ADXL345_INT_TAP + + ADXL345_INT_DOUBLETAP);-The radio channel can be defined from the application’s
project-conf.hor theMakefile.--The radio drivers in Contiki are implemented to comply with the
-struct radio_driverincore/dev/radio.h. This abstraction allows to interact with the radio using a standardized API, independently of the radio hardware. The functions to set and read radio parameters are explained below.---+
+/** Get a radio parameter value. */ -radio_result_t (* get_value)(radio_param_t param, radio_value_t *value); - -/** Set a radio parameter value. */ -radio_result_t (* set_value)(radio_param_t param, radio_value_t value);In the while loop we read the values from each axis every second. If there are no interrupts, this will be the only thing shown in the terminal.
++
+ ++ + ++Exercise: put the mote in different positions and check the values of the accelerometer. Try to understand which is x, y and z. Measure the maximum acceleration by shaking the mote. Turn on and off the LED according to the acceleration on one axis. + +-To change the channel from the application use
+RADIO_PARAM_CHANNELas follows:The
TMP102digital temperature sensor on-board theZ1platform has a +/-5ºC accuracy and can measure temperatures from -25ºC to 85ºC. There is an example ready to use atexamples/zolertia/z1/test-tmp102.cshowing how the sensor works.---
-rd = NETSTACK_RADIO.set_value(RADIO_PARAM_CHANNEL, value);--Where
-valuecan be any value from 11 to 26, and rd will be eitherRADIO_RESULT_INVALID_VALUEorRADIO_RESULT_OK.-Working at 863-950 MHz
---The RE-Mote has a dual 2.4 GHz and 863-950 MHz RF interface, which can be selected alternatively, or used simultaneously (the latter currently not supported in Contiki at the moment).
---As default the RE-Mote uses the IEEE 802.15.4g mandatory mode for the 868 MHz band, configured for 2-GFSK modulation, 50 kbps data rate and with 33 channels available.
+PROCESS_THREAD(temp_process, ev, data) +{ + PROCESS_BEGIN(); + int16_t temp; + SENSORS_ACTIVATE(tmp102); + while(1) { + etimer_set(&et, TMP102_READ_INTERVAL); + PROCESS_WAIT_EVENT_UNTIL(etimer_expired(&et)); + temp = tmp102.value(TMP102_READ); + printf("Temp = %d.%02d\n", temp / 100, temp % 100); + } + PROCESS_END(); +}-The RE-Mote uses the Texas Instruments CC1200 RF transceiver, referred to in Contiki as
dev/cc1200. The default configuration file is located indev/cc1200/cc1200-802154g-863-870-fsk-50kbps.c.-To change channels from the application we use the RF API:
+The output is similar to below:
+-
+rd = NETSTACK_RADIO.set_value(RADIO_PARAM_CHANNEL, value);Temp = 27.75 +Temp = 28.12 +Temp = 28.31 +Temp = 28.18 +Temp = 28.12 +Temp = 28.06+-+
+ ++ + +Where
-valuecan be any value from 11 to 26, and rd it will be eitherRADIO_RESULT_INVALID_VALUEorRADIO_RESULT_OK.The TMP102 is placed close to the CP2102 Serial to USB converter of the
+Z1mote, thus when powered over USB it will overheat and increase the temperature nearby the sensor. Consider substracting 4-5ºC to the actual readings when powered over USB. If theZ1is powered over battery the measurements will be OK.-@@ -9897,7 +12058,7 @@Set the transmission power
--The radio frequency power transmission is that at the output of the transmitter before reaching the antenna. The higher the transmission power the higher the wireless range, but the power consumption usually increases as well. The range is heavily dependent on the frequency, the antenna used and its height above the ground.
+External digital sensors can be connected to the
Z1andRE-Moteplatforms.-Changing the transmission power for the Z1 (CC2420) and the RE-Mote (CC2538)
--The RE-Mote platform uses the CC2538 built-in 2.4 GHz radio. As default the transmission power is set to 3 dBm (2 mW) in the
+cpu/cc2538/cc2538-rf.hheader as shown below.As shown in Figure 8, the
RE-Moteand theZ1allows I2C and SPI sensors to be connected to theZigletport: a 5-pin connector with 2.54mm pitch spacing as follows:+-+
+CC2538_RF_TX_POWER_RECOMMENDED 0xD5
Figure 45. RE-Mote 5-pin digital port (I2C and/or SPI)--This recommended value is taken from the SmartRF Studio.
+For the next example we will use the SHT25, an I2C digital temperature and humidity sensor from Sensirion.
-@@ -9608,16 +11713,20 @@Other values and its corresponding output power levels are shown in the next table.
+++-
-
Table 1. CC2538 Transmission power recommended values (from SmartRF Studio) +Figure 46. SHT25 Temperature and humidity sensor+ +
+- TX Power (dBm) +Parameter Value - -24
0x00
Max current consumption
300 uA
- +7
0xFF
Sensor type
Temperature and Humidity
- +5
0xED
Supply Voltage [V]
2.1 - 3.6
- +3
0xD5
Energy Consumption
3.2 uW (at 8 bit, 1 measurement / s)
- +1
0xC5
Data range
0-100 % RH (humidity), -40-125ºC (temperature)
- + +0
0xB6
Max resolution
14 bits (temperature), 12 bits (humidity)
++As usual you can check the driver implementation at the
+platform/z1/devandplatform/zoul/devdirectories. Check out these locations for other sensors and examples to guide you to implement your own.++When adding an external sensor to your application, you will need to tell the compiler to include the sensor libraries. In the previous examples this was not required as the platforms include its on-board sensor automatically. Adding the external sensor libraries to the application is done in the
+Makefile. This is how theRE-MoteMakefile looks like:++++
+DEFINES+=PROJECT_CONF_H=\"project-conf.h\" (1) + +CONTIKI_PROJECT = zoul-demo test-tsl2563 test-sht25 test-power-mgmt (2) +CONTIKI_PROJECT += test-bmp085-bmp180 test-motion test-rotation-sensor +CONTIKI_PROJECT += test-grove-light-sensor test-grove-loudness-sensor +CONTIKI_PROJECT += test-weather-meter test-grove-gyro test-lcd test-iaq +CONTIKI_PROJECT += test-pm10-sensor test-vac-sensor test-aac-sensor +CONTIKI_PROJECT += test-zonik + +CONTIKI_TARGET_SOURCEFILES += tsl2563.c sht25.c bmpx8x.c motion-sensor.c (3) +CONTIKI_TARGET_SOURCEFILES += adc-sensors.c weather-meter.c grove-gyro.c +CONTIKI_TARGET_SOURCEFILES += rgb-bl-lcd.c pm10-sensor.c iaq.c zonik.c + +all: $(CONTIKI_PROJECT) + +CONTIKI = ../../.. +include $(CONTIKI)/Makefile.include++
+- -1
0xB0
1 +The location of the project-conf.hfile for specific application configuration.- -3
0xA1
2 +The test examples to compile automatically if no application is defined. If you run makeit will compile all of them at once!- +-5
0x91
3 +The name of the libraries to include. As default it will search the platform/devfolder++The
+sht25.cis the library of the SHT25 sensor.++The SHT25 sensor example is available in both
+examples/zolertia/zoul/test-sht25.candexamples/zolertia/z1/test-sht25.c.++++
+/*---------------------------------------------------------------------------*/ +#include "dev/sht25.h" +/*---------------------------------------------------------------------------*/ +PROCESS(remote_sht25_process, "SHT25 test"); +AUTOSTART_PROCESSES(&remote_sht25_process); +/*---------------------------------------------------------------------------*/ +static struct etimer et; +/*---------------------------------------------------------------------------*/ +PROCESS_THREAD(remote_sht25_process, ev, data) +{ + int16_t temperature, humidity; + + PROCESS_BEGIN(); + SENSORS_ACTIVATE(sht25); (1) + + /* Check if the sensor voltage operation is over 2.25V */ + if(sht25.value(SHT25_VOLTAGE_ALARM)) { (2) + printf("Voltage is lower than recommended for the sensor operation\n"); + PROCESS_EXIT(); + } + + /* Configure the sensor for maximum resolution (14-bit temperature, 12-bit + * relative humidity), this will require up to 85ms for the temperature + * integration, and 29ms for the relative humidity (this is the default + * setting at power on). To achieve a faster integration time at the cost + * of a lower resolution, change the value below accordingly, see sht25.h. + */ + sht25.configure(SHT25_RESOLUTION, SHT2X_RES_14T_12RH); (3) + + /* Let it spin and read sensor data */ + + while(1) { + etimer_set(&et, CLOCK_SECOND); + PROCESS_WAIT_EVENT_UNTIL(etimer_expired(&et)); + temperature = sht25.value(SHT25_VAL_TEMP); (4) + printf("Temperature %02d.%02d ºC, ", temperature / 100, temperature % 100); + humidity = sht25.value(SHT25_VAL_HUM); (5) + printf("Humidity %02d.%02d RH\n", humidity / 100, humidity % 100); + } + PROCESS_END(); +}++
+- -7
0x88
1 +Enable the sensor - -9
0x72
2 +Check if the sensor powering voltage is below 2.25V. The sensor requires at least 2.25V to work properly, else it might yield unreliable measures - -11
0x62
3 +Configure the sensor resolution - -13
0x58
4 +Retrieve a temperature reading - --15
0x42
5 +Retrieve a humidity reading ++An output example is given below:
++++
+Starting 'SHT25 test' +Temperature 23.71 ºC +Humidity 42.95 % RH +Temperature 23.71 ºC +Humidity 42.95 % RH +Temperature 23.71 ºC +Humidity 42.95 % RH +Temperature 23.71 ºC +Humidity 42.98 %RH@@ -6317,919 +6742,2435 @@ --As illogical as it may sound, there might be some reasons to reduce transmission power:
---
-
Exercise: convert the temperature to Fahrenheit. Try to get the temperature and humidity as high as possible (without damaging the mote!). Try to print only “possible” values (if you disconnect the sensor, you should not print anything, or print an error message!).
-+The current consumption can go from 24 mA to 34 mA when changing the transmission power from 0 dBm to 7 dBm (AN125).
+The next section will continue with the walkthrough on how to work with the on-board sensors, shown in the analogue and digital sensors section.
++
+ + + +The Z1 mote uses the Texas Instrument CC2420 RF transceiver. As default the transmission power is set to 0 dBm (1 mW), which is the maximum allowed by the radio.
+Normally when working with sensors it is often recommeded to operate as follows:
+++
+SENSOR_ACTIVATE(...) +/* configure, retrieve readings, etc */ +SENSOR_DEACTIVATE();--The available output power and its corresponding configuration values are listed in the table below, as well as the current consumption at each level.
+This ensures the sensor is configured as expected. It is quite common to have more than one digital sensor sharing the same communication bus (I2C/SPI), or having a driver configuring the ADC ports with a general configuration thus overriding the expected one.
-
+ + +Table 2. CC2420 Transmission power (CC2420 datasheet, page 51) -- - -- - - - - - -TX Power (dBm) -Value -mA -- - - --25
3
8.5
- -0
31
17.4
- --1
27
16.5
- --3
23
15.2
- --5
19
13.9
- --7
15
12.5
- --10
11
11.2
- --15
7
9.9
+On-board sensors and ADC
-+For both platforms the transmission power can be changed with:
+The
+05-onboard-sensors.cexample shows a mixture of the on-board sensors of each platforms shown in the section before. This example is compatible with both theZ1and theRE-Moteplatform, so it can be compiler for both.+The following snippet shows how is this done:
-
+rd = NETSTACK_RADIO.set_value(RADIO_PARAM_TXPOWER, value);#if CONTIKI_TARGET_ZOUL + batt = vdd3_sensor.value(CC2538_SENSORS_VALUE_TYPE_CONVERTED); + printf("VDD = %u mV\n", (uint16_t)batt); + + temp = cc2538_temp_sensor.value(CC2538_SENSORS_VALUE_TYPE_CONVERTED); + printf("Core temperature = %d.%u C\n", temp / 1000, temp % 1000); + +#else /* Assumes Z1 mote */ + x_axis = adxl345.value(X_AXIS); + y_axis = adxl345.value(Y_AXIS); + z_axis = adxl345.value(Z_AXIS); + temp = tmp102.value(TMP102_READ); + batt = battery_sensor.value(1); + + /* Print the readings */ + printf("Acceleration: X %d Y %d Z %d\n", x_axis, y_axis, z_axis); + printf("Temperature: %d.%u C\n", temp / 100, temp % 100); + + /* Convert the ADC readings to mV */ + batt *= 5000; + batt /= 4095; + printf("Battery: %u\n\n", (uint16_t)batt); +#endif-+Where
+valuecan be any value from the above table, and rd it will be eitherRADIO_RESULT_INVALID_VALUEorRADIO_RESULT_OK.The key is the
CONTIKI_TARGET_ZOULpreprocesor value.+-Whenever we compile using
TARGET=zoultheCONTIKI_TARGET_ZOULis defined, thus allowing us to differentiate at compilation time which block of code will be included in our application.-Changing the transmission power for the RE-Mote (CC1200)
-+As mentioned earlier, the RE-Mote has an on-board sub-1 GHz interface based on the CC1120 radio transceiver, configured to operate in the 863-950 MHz bands. The maximum transmission power allowed depends on the specific band and regulations in place, which can also impose limits on the maximum antenna gain, be sure to check the local regulations before changing the output power.
+For the
+Z1mote the output is similar to:++
+Acceleration: X -13 Y -73 Z -38 +Temperature: 28.50 C +Battery: 3018 + +Acceleration: X -14 Y -75 Z -39 +Temperature: 28.43 C +Battery: 3020-+The regulations are country specific and out of the scope of this section.
+And for the
+RE-Mote:++
+VDD = 3300 mV +Core temperature = 33.571 C +VDD = 3297 mV +Core temperature = 33.809 C--The following values are taken from the SmartRF Studio, using default IEEE 802.15.4g ETSI compliant configuration.
+The
06-adc.cexample also summarizes the analogue sensors into a single test application compatible for both platforms: TheZ1and theRE-Mote:-
Table 3. CC1200 Transmission power recommended values (from SmartRF Studio) +++ + +++
+#if CONTIKI_TARGET_ZOUL + printf("ADC1 = %u mV\n", adc_zoul.value(ZOUL_SENSORS_ADC1)); + printf("ADC3 = %u mV\n", adc_zoul.value(ZOUL_SENSORS_ADC3)); +#else + printf("Phidget 5V 1:%d\n", phidgets.value(PHIDGET5V_1)); + printf("Phidget 5V 2:%d\n", phidgets.value(PHIDGET5V_2)); + printf("Phidget 3V 1:%d\n", phidgets.value(PHIDGET3V_1)); + printf("Phidget 3V 2:%d\n\n", phidgets.value(PHIDGET3V_2)); +#endif++ + + +General input/output pins (GPIO)
+++The General input/output pins are generic pins used either as input or output (0-3.3V), useful in case you need to actuate on something, or read the digital voltage level as high/low (3.3V or 0V).
+++Some examples are:
+++-
+
++The way the
+LEDsworks is setting a given pin as output, and setting its value high or low (depending on the actual pin logic and pull-up or pull-down resistors it might have).++The
+user buttonis actually a GPIO configured as input, and then detecting whenever the value transitions from one level to another (high to low or viceversa), thus generating an interrupt event.++The
+Z1and theRE-Motehave a very different way to configure and work with GPIO, as currently Contiki lacks an unified GPIO API. The07-gpio.cexample covers both cases.++The
+RE-Moteand theCC2538library implements macros to directly configure and set the pins/ports registers. TheCC2538has four ports (namely A, B, C, D) each one with a numeric value from zero to three:++++
+/** \name Numeric representation of the four GPIO ports + * @{ + */ +#define GPIO_A_NUM 0 /**< GPIO_A: 0 */ +#define GPIO_B_NUM 1 /**< GPIO_B: 1 */ +#define GPIO_C_NUM 2 /**< GPIO_C: 2 */ +#define GPIO_D_NUM 3 /**< GPIO_D: 3 */ +/** @} */++Subsequently each port has up to eight pins, numbered from zero to seven. The pins then are normally referred to
+PA0and alike, indicating is the pin zero at the port A. The image below shows the pin-out of theRE-Mote:++++
+Figure 47. RE-Mote pin-out+++It is possible to configure and use one or more pins at the same time, this is done using masks. As we have 8 pins per port, we treat the pin relative position in a mask fashion. For example if we want to enable pins 2 and 4 of the port A at the same time:
++
Table 1. Pin mask example - - + + + + + + + + - - -TX Power (dBm) -Value +bit 7 +bit 6 +bit 5 +bit 4 +bit 3 +bit 2 +bit 1 +bit 0 - --40
0x41
- -+14
0x7F
- -+13
0x7C
- -+12
0x7A
- -+11
0x78
- -+8
0x71
- -+6
0x6C
- -+4
0x68
- -+3
0x66
- -+2
0x63
- -+1
0x61
0
0x5F
- --3
0x58
- --6
0x51
- --11
0x46
- -24
0x42
0
0
1
0
1
0
0
-+These values correspond to the
+CC1200_PA_CFG1register.So the value we would need to use is 0x14 in hexadecimal or 20 in decimal base.
+++The conversion of a single pin number to the required pin mask can be done using the following macro:
+++
+GPIO_PIN_MASK(pin number)++Also the actual port register address can be obtained from the port number by using the following macro:
+++
+GPIO_PORT_TO_BASE(port number)++In the
+07-gpio.cexample this is how a pin is configured as an output pin (PA5).++The
+GPIO_SOFTWARE_CONTROL(…)macro configures the pin to be controlled by the user, instead of being driven by the hardware as other function (I2C, SPI, etc).++++
+/* The masks below converts the Port number and Pin number to base and mask values */ + #define EXAMPLE_PORT_BASE GPIO_PORT_TO_BASE(GPIO_A_NUM) + #define EXAMPLE_PIN_MASK GPIO_PIN_MASK(5) + + /* We tell the system the application will drive the pin */ + GPIO_SOFTWARE_CONTROL(EXAMPLE_PORT_BASE, EXAMPLE_PIN_MASK); + + /* And set as output, starting as high */ + GPIO_SET_OUTPUT(EXAMPLE_PORT_BASE, EXAMPLE_PIN_MASK); + GPIO_SET_PIN(EXAMPLE_PORT_BASE, EXAMPLE_PIN_MASK);++Then in a loop we read the pin status (if it is high or low), and toggle its state. Notice the
+GPIO_READ_PIN(…)macro also uses a pin mask as argument, meaning you can read in a single instruction the status of all the pins of the port. The return of this macro will give a mask of pins, in which all pins set as high will have a value of one, and zero otherwise.++In this example if pin
+PA5is active, theGPIO_READ_PIN(…)will return a value of 0x20 in hexadecimal, or 20 in decimal base, as this is the pin 5 mask value (1 << 5).++++
+while(1) { + PROCESS_WAIT_EVENT_UNTIL(etimer_expired(&et)); + + if(GPIO_READ_PIN(EXAMPLE_PORT_BASE, EXAMPLE_PIN_MASK)) { + GPIO_CLR_PIN(EXAMPLE_PORT_BASE, EXAMPLE_PIN_MASK); + } else { + GPIO_SET_PIN(EXAMPLE_PORT_BASE, EXAMPLE_PIN_MASK); + } + + leds_toggle(LEDS_GREEN); + etimer_reset(&et); + }++The
+Z1mote on the other hand uses directly the register values to configure and actuate on the pins:++++
+#define EXAMPLE_PIN_MASK (1<<2) + + /* The MSP430 MCU names the pins as a tupple of PORT + PIN, thus P6.1 refers + * to the Pin number 1 of the Port 6. + * We need first to select the operation mode of the Pin, as a Pin can have + * a special function (UART, ADC, I2C) also. The GPIO operation is selected + * by writting the pin's bit as zero to the PxSEL register. The below snippet + * changes 00010000 to 11101111, so when writting to the register we only + * clear our pin, leaving the others untouched (as it is an AND operation) + */ + P4SEL &= ~EXAMPLE_PIN_MASK; + + /* Next we set the direction of the pin. Output means the pin can be high + * (3.3V) or low (0V), while being as Input will allow us to read the digital + * value the pin has. To enable the pin as Output, write an 1. + */ + P4DIR |= EXAMPLE_PIN_MASK;++We need to configure first the pin function (we select the pin as GPIO by setting the pin mas value on the
+PxSELregister to zero). ThePxDIRconfigures the direction of the pin, if writting a zero to the pin mask value it will be configured as input, otherwise if set to one it will be configured as output.++++
+/* This toggles the pin, if low then sets the pin high, and viceversa. + * Alternatively to set the pin high, use P4OUT |= EXAMPLE_PIN_MASK, and to + * drive low use P4OUT &= ~EXAMPLE_PIN_MASK + */ + P4OUT ^= EXAMPLE_PIN_MASK;++And then to set the pin high or low we use the
+PxOUTregister (it assumes the pin is configured as output, its value is ignored otherwise). Writting a one to the pin mask value on the register will set the pin as high, and low otherwise is writting a zero.+Wireless with Contiki
++++In the previous section we covered some of the core features of Contiki, basics of sensors and a general overview of how the applications are built, programmed and simulated in Contiki. This section introduces the wireless communication, details about radios, and in general how to configure our platforms.
+++Addressing and Radio Frequency basics
+++The very first step is understanding how our platform is configured.
+++Each platform implements its own set of default values and configurations, to be used by underlying modules like the radio, the serial port, etc.
+++The places to visit for the Zolertia platform are the following:
+++-
+
++As a general good practice, user configurable parameters are normally allowed to be overridden by the applications, this also serves as a guideline to discern which values can be changed by the casual user, from those meant to be changed only if you really know what you are doing. Below is an example:
+++++
+#ifndef UART0_CONF_BAUD_RATE +#define UART0_CONF_BAUD_RATE 115200 +#endif++By defining
+UART0_CONF_BAUD_RATEin our application’sproject-conf.h, we can change the default 115200 baud rate. Notice that generally it is a good practice to addCONFto the user configurable parameters.+++
++ ++ + ++ +++One of the most used tools is probably
+grep, a handy command to search for a text string in any document or location. One way to run this command isgrep -lr "alinan" ., if executed at the root of our Contiki installation, it will list recursively all the files authored by Antonio Linan. This is a good way to check the location of a specific definition, if you are not using an IDE like Eclipse. +Checkman grepfor more information.++For windows Astrogrep is a good option.
+++In the next section we will review the most notable parameters to configure, but as usual depending on your application and setup, the best way to ensure everything is properly set is by reviewing the specific platform configuration files, and modify or redefine accordingly.
+++Device addressing
+++To start working you must first define the Node ID of each node, this will be used to generate the mote’s MAC address and the IPv6 addresses (link-local and global).
+++RE-Mote addresses
+++The
+RE-Moteplatform comes with two pre-saved MAC addresses stored in its internal flash memory, but the user can instead choose a hardcoded one. The following switches atplatform/zoul/contiki-conf.hselects the chosen one.++++
+/** + * \name IEEE address configuration + * + * Used to generate our RIME & IPv6 address + * @{ + */ +/** + * \brief Location of the IEEE address + * 0 => Read from InfoPage, + * 1 => Use a hardcoded address, configured by IEEE_ADDR_CONF_ADDRESS + */ +#ifndef IEEE_ADDR_CONF_HARDCODED +#define IEEE_ADDR_CONF_HARDCODED 0 +#endif + +/** + * \brief Location of the IEEE address in the InfoPage when + * IEEE_ADDR_CONF_HARDCODED is defined as 0 + * 0 => Use the primary address location + * 1 => Use the secondary address location + */ +#ifndef IEEE_ADDR_CONF_USE_SECONDARY_LOCATION +#define IEEE_ADDR_CONF_USE_SECONDARY_LOCATION 0 +#endif++If using your own hardcoded address, the following define can be overridden by the application:
+++++
+#ifndef IEEE_ADDR_CONF_ADDRESS +#define IEEE_ADDR_CONF_ADDRESS { 0x00, 0x12, 0x4B, 0x00, 0x89, 0xAB, 0xCD, 0xEF } +#endif++Z1 mote addresses
+++Let’s use the ID from the mote list:
+++++
+Reference Device Description +-------------------------------------------------- +Z1RC3301 /dev/ttyUSB0 Silicon Labs Zolertia Z1++The node ID should be
+3301(decimal) if no previously saved node ID is found in the flash memory.++Let’s see how Contiki uses this to derive a full IPv6 and MAC address. At
+platforms/z1/contiki-z1-main.c++++
+#ifdef SERIALNUM + if(!node_id) { + PRINTF("Node id is not set, using Z1 product ID\n"); + node_id = SERIALNUM; + } +#endif +node_mac[0] = 0xc1; /* Hardcoded for Z1 */ +node_mac[1] = 0x0c; /* Hardcoded for Revision C */ +node_mac[2] = 0x00; /* Hardcoded to arbitrary even number so that the 802.15.4 MAC address is compatible with an Ethernet MAC address - byte 0 (byte 2 in the DS ID) */ +node_mac[3] = 0x00; /* Hardcoded */ +node_mac[4] = 0x00; /* Hardcoded */ +node_mac[5] = 0x00; /* Hardcoded */ +node_mac[6] = node_id >> 8; +node_mac[7] = node_id & 0xff; +}++So the mote should have the following addresses:
+++++
+MAC c1:0c:00:00:00:00:0c:e5 +Node id is set to 3301. +Tentative link-local IPv6 address fe80:0000:0000:0000:c30c:0000:0000:0ce5++Where
+0xce5is the hex value corresponding to3301. The global address is only set when an IPv6 prefix is assigned (by now you should know this from earlier sections).++If instead you wish to have your own addressing scheme, you can edit the node_mac values at
+contiki-z1-main.cfile. If you wish to replace the node id value obtained from the product id, you need to store a new one in the flash memory, luckily there is already an application to do so:++Go to
+examples/zolertia/z1location and replace the158for your own required value:++++
+make clean && make burn-nodeid.upload nodeid=158 nodemac=158 && make z1-reset && make login++You should see the following:
+++++
+MAC c1:0c:00:00:00:00:0c:e5 Ref ID: 3301 +Contiki-2.6-1803-g03f57ae started. Node id is set to 3301. +CSMA ContikiMAC, channel check rate 8 Hz, radio channel 26 +Tentative link-local IPv6 address fe80:0000:0000:0000:c30c:0000:0000:0ce5 +Starting 'Burn node id' +Burning node id 158 +Restored node id 158++As you can see, now the node ID has been changed to 158, when you restart the mote you should see that the changes have been applied:
+++++
+MAC c1:0c:00:00:00:00:00:9e Ref ID: 3301 +Contiki-2.6-1803-g03f57ae started. Node id is set to 158. +CSMA ContikiMAC, channel check rate 8 Hz, radio channel 26 +Tentative link-local IPv6 address fe80:0000:0000:0000:c30c:0000:0000:009e++Set the bandwidth and channel
+++The bandwidth and allowed channels depend on the operating frequency band. They will be determined by the spectrum regulation agency of the country, along with maximum transmitted power allowable. +.The IEEE 802.15.4 standard
+++++++The IEEE 802.15.4 is a standard for wireless communication, it specifies the physical and media access control layers for low-rate wireless personal area networks (LR-WPANs).
+++The standard specifies the use of the 868-868.8 MHz (in Europe and many other countries), the 902-928 MHz (in United States, Canada, and some Latin America countries), or the world-wide 2.400-2.4835 GHz band part of the Industrial Scientific and Medical applications (ISM).
+++++
+Figure 48. IEEE 802.15.4 2.4 GHz regulation requirements (electronicdesign.com, 2013)+++In practice the 2.4 GHz band is being heavily used due to its world-wide availability. The ZigBee proprietary protocol by the ZigBee alliance was one of the early adopters of IEEE 802.15.4. It did so leveraging the physical and MAC layer of IEEE 802.15.4, specifying on top additional routing and networking functionality to build mesh networks.
+++Quite recently the Thread Group +has proposed its own simplified IPv6-based mesh networking protocol for connecting products around the home to each other, to the Internet and to the cloud.
+++++
+Figure 49. Thread layers and standards (Thread group, 2015)+++Working at 2.4 GHz
+++As the 2.4 GHz band is also used by other technologies like WiFi and Bluetooth, this spectrum is shared and overlaps might occur. The Figure below shows the channel allocation of the 2.4 GHz IEEE 802.15.4, and the recommended channels to avoid interferences with other co-located devices. With the rise of the Bluetooth Low Energy, and the ubiquitous WiFi present in our lives, the selection of a proper operating channel is crucial in any deployment.
+++++
+Figure 50. Channel assignment+++The default channel of the RE-Mote is defined as follows:
+++++
+#ifndef CC2538_RF_CONF_CHANNEL +#define CC2538_RF_CONF_CHANNEL 26 +#endif /* CC2538_RF_CONF_CHANNEL */++The Z1 mote defines its default channel as:
+++++
+#ifdef RF_CHANNEL +#define CC2420_CONF_CHANNEL RF_CHANNEL +#endif + +#ifndef CC2420_CONF_CHANNEL +#define CC2420_CONF_CHANNEL 26 +#endif /* CC2420_CONF_CHANNEL */++The radio channel can be defined from the application’s
+project-conf.hor theMakefile.++The radio drivers in Contiki are implemented to comply with the
+struct radio_driverincore/dev/radio.h. This abstraction allows to interact with the radio using a standardized API, independently of the radio hardware. The functions to set and read radio parameters are explained below.++++
+/** Get a radio parameter value. */ +radio_result_t (* get_value)(radio_param_t param, radio_value_t *value); + +/** Set a radio parameter value. */ +radio_result_t (* set_value)(radio_param_t param, radio_value_t value);++To change the channel from the application use
+RADIO_PARAM_CHANNELas follows:++++
+rd = NETSTACK_RADIO.set_value(RADIO_PARAM_CHANNEL, value);++Where
+valuecan be any value from 11 to 26, and rd will be eitherRADIO_RESULT_INVALID_VALUEorRADIO_RESULT_OK.++Working at 863-950 MHz
+++The RE-Mote has a dual 2.4 GHz and 863-950 MHz RF interface, which can be selected alternatively, or used simultaneously (the latter currently not supported in Contiki at the moment).
+++As default the RE-Mote uses the IEEE 802.15.4g mandatory mode for the 868 MHz band, configured for 2-GFSK modulation, 50 kbps data rate and with 33 channels available.
+++The RE-Mote uses the Texas Instruments CC1200 RF transceiver, referred to in Contiki as
+dev/cc1200. The default configuration file is located indev/cc1200/cc1200-802154g-863-870-fsk-50kbps.c.++To change channels from the application we use the RF API:
+++++
+rd = NETSTACK_RADIO.set_value(RADIO_PARAM_CHANNEL, value);++Where
+valuecan be any value from 11 to 26, and rd it will be eitherRADIO_RESULT_INVALID_VALUEorRADIO_RESULT_OK.++Set the transmission power
+++The radio frequency power transmission is that at the output of the transmitter before reaching the antenna. The higher the transmission power the higher the wireless range, but the power consumption usually increases as well. The range is heavily dependent on the frequency, the antenna used and its height above the ground.
+++Changing the transmission power for the Z1 (CC2420) and the RE-Mote (CC2538)
+++The RE-Mote platform uses the CC2538 built-in 2.4 GHz radio. As default the transmission power is set to 3 dBm (2 mW) in the
+cpu/cc2538/cc2538-rf.hheader as shown below.++++
+CC2538_RF_TX_POWER_RECOMMENDED 0xD5++This recommended value is taken from the SmartRF Studio.
+++Other values and its corresponding output power levels are shown in the next table.
++
+Table 2. CC2538 Transmission power recommended values (from SmartRF Studio) ++ + ++ + + + + +TX Power (dBm) +Value ++ + + +-24
0x00
+ ++7
0xFF
+ ++5
0xED
+ ++3
0xD5
+ ++1
0xC5
+ +0
0xB6
+ +-1
0xB0
+ +-3
0xA1
+ +-5
0x91
+ +-7
0x88
+ +-9
0x72
+ +-11
0x62
+ +-13
0x58
+ + +-15
0x42
+++
++ ++ + ++ +++As illogical as it may sound, there might be some reasons to reduce transmission power:
+++-
+
++The current consumption can go from 24 mA to 34 mA when changing the transmission power from 0 dBm to 7 dBm (AN125).
+++The Z1 mote uses the Texas Instrument CC2420 RF transceiver. As default the transmission power is set to 0 dBm (1 mW), which is the maximum allowed by the radio.
+++The available output power and its corresponding configuration values are listed in the table below, as well as the current consumption at each level.
++
+Table 3. CC2420 Transmission power (CC2420 datasheet, page 51) ++ + ++ + + + + + +TX Power (dBm) +Value +mA ++ + + +-25
3
8.5
+ +0
31
17.4
+ +-1
27
16.5
+ +-3
23
15.2
+ +-5
19
13.9
+ +-7
15
12.5
+ +-10
11
11.2
+ + +-15
7
9.9
++For both platforms the transmission power can be changed with:
+++++
+rd = NETSTACK_RADIO.set_value(RADIO_PARAM_TXPOWER, value);++Where
+valuecan be any value from the above table, and rd it will be eitherRADIO_RESULT_INVALID_VALUEorRADIO_RESULT_OK.++Changing the transmission power for the RE-Mote (CC1200)
+++As mentioned earlier, the RE-Mote has an on-board sub-1 GHz interface based on the CC1120 radio transceiver, configured to operate in the 863-950 MHz bands. The maximum transmission power allowed depends on the specific band and regulations in place, which can also impose limits on the maximum antenna gain, be sure to check the local regulations before changing the output power.
+++The regulations are country specific and out of the scope of this section.
+++The following values are taken from the SmartRF Studio, using default IEEE 802.15.4g ETSI compliant configuration.
++
+Table 4. CC1200 Transmission power recommended values (from SmartRF Studio) ++ + ++ + + + + +TX Power (dBm) +Value ++ + + +-40
0x41
+ ++14
0x7F
+ ++13
0x7C
+ ++12
0x7A
+ ++11
0x78
+ ++8
0x71
+ ++6
0x6C
+ ++4
0x68
+ ++3
0x66
+ ++2
0x63
+ ++1
0x61
+ +0
0x5F
+ +-3
0x58
+ +-6
0x51
+ +-11
0x46
+ + +-24
0x42
++These values correspond to the
+CC1200_PA_CFG1register.++As default the CC1200 driver in Contiki starts with the maximum transmission power, defined as follows:
+++++
+/* The maximum output power in dBm */ +#define RF_CFG_MAX_TXPOWER CC1200_CONST_TX_POWER_MAX++The minimum and maximum allowed values are set in
+dev/cc1200/cc1200-const.has shown below.++++
+/* Output power in dBm */ +/* Up to now we don't handle the special power levels PA_POWER_RAMP < 3, hence + * the minimum tx power is -16. See update_txpower(). + */ +#define CC1200_CONST_TX_POWER_MIN (-16) +/* + * Maximum output power will probably depend on the band we use due to + * regulation issues + */ +#define CC1200_CONST_TX_POWER_MAX 14++The CC1200 driver calculates the proper
+CC1200_PA_CFG1register value, so we need to pass asvalueargument the required transmission power.++++
+rd = NETSTACK_RADIO.set_value(RADIO_PARAM_TXPOWER, value);++Where
+valuecan be any value from -14 to 16, and rd will be eitherRADIO_RESULT_INVALID_VALUEorRADIO_RESULT_OK.++Checking the wireless link
+++Due to the changing environment conditions that normally affect the wireless systems, such as rain, interferences, obstacles, reflections, etc., measuring the wireless medium and links quality is important.
+++Checking the wireless medium should be done in three stages: before deploying your network, at deployment phase and later at network runtime, to ensure that the nodes create and select the best available routes.
+++++Link Quality Estimation+++Link Quality Estimation is an integral part of assuring reliability in wireless networks. Various link estimation metrics have been proposed to effectively measure the quality of wireless links.
+++++
+Figure 51. Link quality estimation process+++The ETX metric, or expected transmission count, is a measure of the quality of a path between two nodes in a wireless packet data network. ETX is the number of expected transmissions of a packet necessary for it to be received without error at its destination. This number varies from one to infinity. An ETX of one indicates a perfect transmission medium, where an ETX of infinity represents a completely non-functional link. Note that ETX is an expected transmission count for a future event, as opposed to an actual count of a past events. It is hence a real number, generally not an integer.
+++ETX can be used as the routing metric. Routes with a lower metric are preferred. In a route that includes multiple hops, the metric is the sum of the ETX of the individual hops.
+++Below we describe how to read the LQI and RSSI to have a first approximation of the link conditions.
+++++What is RSSI?+++RSSI (Received Signal Strenght Indicator) is a generic radio receiver technology metric used internally in a wireless networking device to determine the amount of radio energy received in a given channel. The end-user will likely observe an RSSI value when measuring the signal strength of a wireless network through the use of a wireless network monitoring tool like Wireshark, Kismet or Inssider.
+++The image below shows how the Packet Reception Rate (PRR) dramatically decreases as the CC2420 RSSI values worsen.
+++++
+Figure 52. Packet reception rate vs RSSI+++There is no standardized relationship of any particular physical parameter to the RSSI reading, Vendors and chipset makers provide their own accuracy, granularity, and range for the actual power (measured in mW or dBm) and the corresponding RSSI values.
+++There are 2 different types of RSSI readings available:
+++-
+
++The first measurement can be read using the radio API as follows:
+++++
+rd = NETSTACK_RADIO.get_value(RADIO_PARAM_RSSI, value);++Where
+valueis a variable passed as a pointer to store the RSSI value, and rd it will be eitherRADIO_RESULT_INVALID_VALUEorRADIO_RESULT_OK.++To read the RSSI value of a correctly decoded received packet, at the
+receivecallback:++++
+packetbuf_attr(PACKETBUF_ATTR_RSSI);++More information about the
+packetbufattributes is available incore/net/packetbuf.h.++For the CC2420 radio frequency transceiver on the Z1 mote, the RSSI can range from 0 to -100, values close to 0 mean good links while values close to -100 are indicators of a bad link, which could be due to multiple factors such as distance, environment, obstacles, interferences, etc.
+++++What is LQI?+++LQI (Link Quality Indicator) is a digital value often provide by Chipset vendors as an indicator of how well a signal is demodulated, in terms of the strength and quality of the received packet, thus indicating a good or bad wireless medium.
+++The example below shows how the Packet Reception Rate decreases as the LQI decreases.
+++++
+Figure 53. Packet reception rate vs LQI+++To read the LQI value we use the Radio API:
+++++
+rd = NETSTACK_RADIO.get_value(PACKETBUF_ATTR_LINK_QUALITY, value);++Where
+valueis a variable passed as a pointer to store the LQI value, and rd it will be eitherRADIO_RESULT_INVALID_VALUEorRADIO_RESULT_OK.++The CC2420 radio used by the Z1 mote typically ranges from 110 (indicates a maximum quality frame) to 50 (typically the lowest quality frames detectable by the transceiver).
+++Detailed information about the CC2538 LQI calculation is found in the CC2538 user guide.
+++Configure the MAC layer
+ +++The medium access implementation in Contiki has 3 different layers: Framer, Radio Duty-Cycle (RDC) and Medium Access Control (MAC).
+++++
+Figure 54. Contiki MAC stack+++The network layer can be accessed through the global variables
+NETSTACK_FRAMER,NETSTACK_RDCandNETSTACK_MAC, which are defined at compilation time.++The variables are located in
+core/net/netstack.h, and can be defined by each platform as default and overridden by applications.++MAC driver
+++Contiki provides two MAC drivers: CSMA and NullMAC
+++CSMA (Carrier-Sense Multiple Access) receives incoming packets from the RDC layer and uses the RDC layer to transmit packets. If the RDC layer or the radio layer detects that the medium is busy, the MAC layer may retransmit the packet at a later point in time. CSMA protocol keeps a list of packets sent to each of the neighbors and calculate statistics such as number of retransmissions, collisions, deferrals, etc. The medium access check is performed by the RDC driver.
+++NullMAC is a simple pass-through protocol. It calls the appropriate RDC functions.
+++As default both Z1 mote and RE-Mote uses the CSMA driver.
+++++
+#ifndef NETSTACK_CONF_MAC +#define NETSTACK_CONF_MAC csma_driver +#endif++Alternatively, a user can choose NullMAC as follow:
+++++
+#define NETSTACK_CONF_MAC nullmac_driver++RDC driver
+++Radio Duty-Cycle (RDC) layer handles the sleep period of nodes. This layer decides when packets will be transmitted and ensures that nodes are awake when packets are to be received.
+++The implementation of Contiki’s RDC protocols are available in
+core/net/mac. The following RDC drivers are implemented:contikimac,xmac,lpp,nullrdcandsicslowmac. The implementation and details of the aforementioned RDC drivers are out of the scope of this chapter. The most commonly used is ContikiMAC. NullRDC is a pass-through layer that never switches the radio off.++++
+#ifndef NETSTACK_CONF_RDC +#define NETSTACK_CONF_RDC contikimac_driver +#endif++RDC drivers try to keep the radio off as much as possible, periodically checking the wireless medium for radio activity. When activity is detected, the radio is kept on to check if it has to receive the packet, or it can go back to sleep.
+++The channel check rate is given in Hz, specifying the number of times the channel is checked per second, and the default channel check rate is 8 Hz. Channel check rates are given in powers of two and typical settings are 2, 4, 8, and 16 Hz.
+++++
+#ifndef NETSTACK_CONF_RDC_CHANNEL_CHECK_RATE +#define NETSTACK_CONF_RDC_CHANNEL_CHECK_RATE 8 +#endif++A packet must generally be retransmitted or "strobed" until the receiver is on and receives it. This increments the power consumption of the transmitter and increases the radio traffic, but the power savings at the receiver compensates for this and there is a net overall power saving.
+++One alternative to optimize the RDC is to enable "phase optimization", which delays strobing until just before the receiver is expected to be awake. This however requires a good time synchronization between the transmitter and the receiver (more details in RDC Phase Optimization). To enable phase optimization change the 0 below to one.
+++++
+#define CONTIKIMAC_CONF_WITH_PHASE_OPTIMIZATION 0 +#define WITH_FAST_SLEEP 1++Framer driver
+++The Framer driver is actually a set of functions to frame the data to be transmitted, and to parse the received data. The Framer implementations are located in
+core/net/mac, of which the most noticeable ones areframer-802154andframer-nullmac.++In the RE-Mote platform the following configuration is the default:
+++++
+#ifndef NETSTACK_CONF_FRAMER +#if NETSTACK_CONF_WITH_IPV6 +#define NETSTACK_CONF_FRAMER framer_802154 +#else /* NETSTACK_CONF_WITH_IPV6 */ +#define NETSTACK_CONF_FRAMER contikimac_framer +#endif /* NETSTACK_CONF_WITH_IPV6 */ +#endif /* NETSTACK_CONF_FRAMER */++Meaning that when IPv6 is used, the
+framer-802154is selected, else thecontikimac_frameris used (default one for thecontikimac_driver).++The
+framer-nullmacframer should be used together withnullmac_driver(MAC layer). This simply fills in the 2 fields ofnullmac_hdr, which are: receiver address and sender address.++The
+framer-802154is implemented incore/net/mac/framer-802154.c. The driver frames the data in compliance to the IEEE 802.15.4 (2003) standard. The framer insert and extracts the data to thepacketbufstructure.+IPv6 and Routing
+++One of Contiki’s most prominent feature is the support of IP protocols, being one of the first embedded operating systems to provide IPv6 support.
+++Alternatively Contiki also supports IPv4 and non-IP communication (Rime), however the remainder of this book will focus in IPv6. There is a good set of rime examples available at
+examples/rime. The RE-Motezoul-demo.cmost basic example atexamples/zolertia/zouluses rime as well.++IPv6
+++The uIP is an Open Source TCP/IP stack designed to be used even with tiny 8 and 16 bit microcontrollers. It was initially developed by Adam Dunkels while at the Swedish Institute of Computer Science (SICS), licensed under a BSD style license, and further developed by a wide group of developers.
+++The implementation details of the uIP/uIPv6 is out of the scope of this section. The remainder of this section explains the basic configurations at the platform and application level.
+++To enable IPv6 the following has to be defined, either in the application’s
+Makefileor in itsproject-conf.hfile:++++
+#define UIP_CONF_IPV6 1++++
+#ifndef NBR_TABLE_CONF_MAX_NEIGHBORS +#define NBR_TABLE_CONF_MAX_NEIGHBORS 20 +#endif +#ifndef UIP_CONF_MAX_ROUTES +#define UIP_CONF_MAX_ROUTES 20 +#endif + +/* uIP */ +#ifndef UIP_CONF_BUFFER_SIZE +#define UIP_CONF_BUFFER_SIZE 1300 +#endif + +#define UIP_CONF_IPV6_QUEUE_PKT 0 +#define UIP_CONF_IPV6_CHECKS 1 +#define UIP_CONF_IPV6_REASSEMBLY 0 +#define UIP_CONF_MAX_LISTENPORTS 8+++
++ ++ + ++ +++Depending on your application and your platform you might eventually ran out of RAM memory, specially true for platforms with 8-10KB RAM. A good way to save RAM is to reduce the
+UIP_CONF_MAX_ROUTESandNBR_TABLE_CONF_MAX_NEIGHBORSnumber in yourproject-conf.h.+-RPL
+++There are several routing flavors to chose, but ultimately all do the same thing: ensure that packets arrive at the right destination. This is done in different ways depending on factors such as the routing metric (how a route is qualified as better than others), whether the routing is done dynamically or statically, etc.
+++In Contiki the default routing protocol is RPL. Other protocols such as Ad hoc On-Demand Distance Vector (AODV) are out of the scope of this section.
+++The specifics of the RPL implementation are out of the scope of this section, we merely describe the common configurations and provide a brief introduction to RPL. For more details, check the RPL implementation at
+core/net/rpl.++++What is RPL?+++RPL is an IPv6 routing protocol for low power and lossy networks designed by the IETF Routing Over Low power and Lossy network (ROLL) group, used as the de facto routing protocol in Contiki. RPL is a proactive distance vector protocol, it starts finding the routes as soon as the RPL network is initialized.
+++++
+Figure 55. RPL in the protocol stack+++It supports three traffic patterns:
+++-
+
++RPL builds Destination Oriented DAGs (DODAGs) rooted towards one sink (DAG ROOT) identified by a unique identifier DODAGID. The DODAGs are optimized using an Objective Function (OF) metric identified by an Objective Code Point (OCP), which indicates the dynamic constraints and the metrics such as hop count, latency, expected transmission count, parents selection, energy consumption, etc. A rank number is assigned to each node which can be used to determine its relative position and distance to the root in the DODAG.
+++Within a given network, there may be multiple, logically independent RPL instances. An RPL node may belong to multiple RPL instances, and may act as a router in some and as a leaf in others. A set of multiple DODAGs can be in an RPL INSTANCE and a node can be a member of multiple RPL INSTANCEs, but can belong to at most one DODAG per DAG INSTANCE.
+++A trickle timer mechanism regulates DODAG Information Object (DIO) message transmissions, which are used to build and maintain upwards routes of the DODAG, advertising its RPL instance, DODAG ID, RANK and DODAG version number.
+++A node can request DODAG information by sending DODAG Information Solicitation messages (DIS), soliciting DIO messages from its neighborhoods to update its routing information and join an instance.
+++Nodes have to monitor DIO messages before joining a DODAG, and then join a DODAG by selecting a parent Node from its neighbors using its advertised latency, OF and RANK. Destination Advertisement Object (DAO) messages are used to maintain downward routes by selecting the preferred parent with lower rank and sending a packet to the DAG ROOT through each of the intermediate Nodes.
+++RPL has two mechanisms to repair the topology of the DODAG, one to avoid looping and allow nodes to join/rejoin, and other called global repair. Global repair is initiated at the DODAG ROOT by incrementing the DODAG Version Number to create a new DODAG Version.
+++More information about RPL can be found in RFC6550.
+++Routing support is enabled as default in the Z1 mote and RE-Mote platform. To enable routing the following has to be enabled:
+++
+#ifndef UIP_CONF_ROUTER +#define UIP_CONF_ROUTER 1 +#endif-As default the CC1200 driver in Contiki starts with the maximum transmission power, defined as follows:
+To enable RPL add the following to your application’s
Makefileor itsproject-conf.hfile.-
+/* The maximum output power in dBm */ -#define RF_CFG_MAX_TXPOWER CC1200_CONST_TX_POWER_MAX#define UIP_CONF_IPV6_RPL 1-The minimum and maximum allowed values are set in
+dev/cc1200/cc1200-const.has shown below.The following is the default configuration done in the RE-Mote:
+-
+/* Output power in dBm */ -/* Up to now we don't handle the special power levels PA_POWER_RAMP < 3, hence - * the minimum tx power is -16. See update_txpower(). - */ -#define CC1200_CONST_TX_POWER_MIN (-16) -/* - * Maximum output power will probably depend on the band we use due to - * regulation issues - */ -#define CC1200_CONST_TX_POWER_MAX 14/* ND and Routing */ +#define UIP_CONF_ND6_SEND_RA 0 (1) +#define UIP_CONF_IP_FORWARD 0 (2) +#define RPL_CONF_STATS 0 (3)++
++ +1 +Disable sending routing advertisements ++ +2 +Disable IP forwarding ++ +3 +RPL Configuration statistics are disabled +-The CC1200 driver calculates the proper
+CC1200_PA_CFG1register value, so we need to pass asvalueargument the required transmission power.The
RPL_CONF_OFparameter configures the RPL objective function. The Minimum Rank with Hysteresis Objective Function (MRHOF) uses ETX as routing metric and it also has stubs for energy metric.-
+rd = NETSTACK_RADIO.set_value(RADIO_PARAM_TXPOWER, value);#ifndef RPL_CONF_OF +#define RPL_CONF_OF rpl_mrhof +#endif-+Where
+valuecan be any value from -14 to 16, and rd will be eitherRADIO_RESULT_INVALID_VALUEorRADIO_RESULT_OK.The Expected Transmissions metric (ETX) measure how many tries it takes to receive an acknowledgment (ACK) of a sent packet, keeping a moving average for each neighbor, computing the sum of all ETXs to build the routes.
+As default Contiki uses
storing modefor RPL downward routes. Basically all nodes store in a routing table the addresses of their child nodes.-Checking the wireless link
--+Due to the changing environment conditions that normally affect the wireless systems, such as rain, interferences, obstacles, reflections, etc., measuring the wireless medium and links quality is important.
+Set up a wireless sniffer
--Checking the wireless medium should be done in three stages: before deploying your network, at deployment phase and later at network runtime, to ensure that the nodes create and select the best available routes.
+A packet sniffer is a must-have tool for any wireless network application, it allows to see what you are transmitting over the air, verifying both that the transmissions are taking place, the frames/packets are properly formatted, and that the communication is happening on a given channel.
--Link Quality Estimation-Link Quality Estimation is an integral part of assuring reliability in wireless networks. Various link estimation metrics have been proposed to effectively measure the quality of wireless links.
+There are commercial options available, such as the Texas Instruments SmartRF packet Sniffer, which can be used with a CC2531 USB dongle to capture packets like the one below.
--
+
Figure 42. Link quality estimation process+Figure 56. Sniffer packet capture-The ETX metric, or expected transmission count, is a measure of the quality of a path between two nodes in a wireless packet data network. ETX is the number of expected transmissions of a packet necessary for it to be received without error at its destination. This number varies from one to infinity. An ETX of one indicates a perfect transmission medium, where an ETX of infinity represents a completely non-functional link. Note that ETX is an expected transmission count for a future event, as opposed to an actual count of a past events. It is hence a real number, generally not an integer.
+We will use for this exercise the SenSniff application, paired with a RE-Mote and Wireshark (already installed in instant Contiki). This setup will allow us to understand how the wireless communication is done in Contiki.
-+ETX can be used as the routing metric. Routes with a lower metric are preferred. In a route that includes multiple hops, the metric is the sum of the ETX of the individual hops.
+To program the RE-Mote or a Z1 as a packet Sniffer:
++cd examples/zolertia/tutorial/02-ipv6/06-sniffer--Below we describe how to read the LQI and RSSI to have a first approximation of the link conditions.
+Compile and program:
+-+What is RSSI?+
+make TARGET=zoul sniffer.upload-+RSSI (Received Signal Strenght Indicator) is a generic radio receiver technology metric used internally in a wireless networking device to determine the amount of radio energy received in a given channel. The end-user will likely observe an RSSI value when measuring the signal strength of a wireless network through the use of a wireless network monitoring tool like Wireshark, Kismet or Inssider.
+Or
+++
+make TARGET=z1 sniffer.upload--The image below shows how the Packet Reception Rate (PRR) dramatically decreases as the CC2420 RSSI values worsen.
+Note this application has its own
project-conf.h, not shared with the other applications in the same02-ipv6folder.+++The
+project-conf.hhas specific platform settings to make the sniffer work (don’t change those unless you know what you are doing), only change the following:--
+#undef IEEE802154_CONF_PANID +#define IEEE802154_CONF_PANID 0xABCD + +#if CONTIKI_TARGET_ZOUL +/* The following are Zoul (RE-Mote, etc) specific */ +#undef CC2538_RF_CONF_CHANNEL +#define CC2538_RF_CONF_CHANNEL 26 + +#else /* Default is Z1 */ + +/* The following are Z1 specific */ +#undef RF_CHANNEL +#define RF_CHANNEL 26 + +#undef CC2420_CONF_CHANNEL +#define CC2420_CONF_CHANNEL 26Figure 43. Packet rejection rate versus received signal strenght indicator-+There is no standardized relationship of any particular physical parameter to the RSSI reading, Vendors and chipset makers provide their own accuracy, granularity, and range for the actual power (measured in mW or dBm) and the corresponding RSSI values.
+For the Z1 mote launch the sensniff application with the following command:
++python sensniff.py --non-interactive -d /dev/ttyUSB0 -b 115200-+There are 2 different types of RSSI readings available:
+For the RE-Mote:
+++-python sensniff.py --non-interactive -d /dev/ttyUSB0 -b 460800--
-
-The first measurement can be read using the radio API as follows:
+Sensniff will read data from the mote over the serial port, dissect the frames and pipe to
/tmp/sensniffby default, now we need to connect the other extreme of the pipe to wireshark, else you will get the following warning:-
+rd = NETSTACK_RADIO.get_value(RADIO_PARAM_RSSI, value);"Remote end not reading"-+Where
+valueis a variable passed as a pointer to store the RSSI value, and rd it will be eitherRADIO_RESULT_INVALID_VALUEorRADIO_RESULT_OK.Which is not worrisome, it only means that the other pipe endpoint is not connected. You can also save the sniffed frames for later opening with wireshark, adding the following argument to the above command
-p name.pcap, which will save the session output in aname.pcapfile. Change the naming and location for storing the file accordingly.+++
++ ++ + +To read the RSSI value of a correctly decoded received packet, at the
+receivecallback:At the moment of writing this tutorial changing channels from the Sensniff application was not implemented but proposed as a feature.
++Open another terminal and launch wireshark with the following command, which will add the pipe as a capture interface:
-
+packetbuf_attr(PACKETBUF_ATTR_RSSI);sudo wireshark -i /tmp/sensniff-+More information about the
+packetbufattributes is available incore/net/packetbuf.h.Select the
+/tmp/sensniffinterface from the droplist and clickStartjust above.+++
+Figure 57. Capture options--For the CC2420 radio frequency transceiver on the Z1 mote, the RSSI can range from 0 to -100, values close to 0 mean good links while values close to -100 are indicators of a bad link, which could be due to multiple factors such as distance, environment, obstacles, interferences, etc.
+Make sure that the pipe is configured to capture packets in promiscuous mode, if needed you can increase the buffer size, but 1 MB is normally enough.
+--What is LQI?--+LQI (Link Quality Indicator) is a digital value often provide by Chipset vendors as an indicator of how well a signal is demodulated, in terms of the strength and quality of the received packet, thus indicating a good or bad wireless medium.
+
+Figure 58. Interface settings-The example below shows how the Packet Reception Rate decreases as the LQI decreases.
+Now the captured frames should start to appear on screen.
+--
+
Figure 44. Packet rejection rate versus link quality indicator+Figure 59. Captured frames++You can add specific filters to limit the frames being shown on screen, for this example click at the
+Expressionbutton and a list of available attributes per protocol are listed, scroll down to IEEE 802.15.4 and check the available filters. You can also chain different filter arguments using theFilterbox, in this case we only wanted to check the frames belonging to thePAN 0xABCDand coming from nodec1:0c::0309, so we used thewpan.dst_panandwpan.src64attributes.+++
Figure 60. Wireshark filters-To read the LQI value we use the Radio API:
+When closing the Sensniff python application, a session information is provided reporting the following statistics:
-
+rd = NETSTACK_RADIO.get_value(PACKETBUF_ATTR_LINK_QUALITY, value);Frame Stats: + Non-Frame: 6 + Not Piped: 377 + Dumped to PCAP: 8086 + Piped: 7709 + Captured: 8086--Where
+valueis a variable passed as a pointer to store the LQI value, and rd it will be eitherRADIO_RESULT_INVALID_VALUEorRADIO_RESULT_OK.Now that we have a sniffer configured and ready to use, let’s create a first wireless application and start sniffing packets!
-+The CC2420 radio used by the Z1 mote typically ranges from 110 (indicates a maximum quality frame) to 50 (typically the lowest quality frames detectable by the transceiver).
++UDP on IPv6 and the Border Router
--Detailed information about the CC2538 LQI calculation is found in the CC2538 user guide.
-Now that we have covered the mote configurations and the MAC and routing layers, let us set up a UDP network.
-Configure the MAC layer
--The medium access implementation in Contiki has 3 different layers: Framer, Radio Duty-Cycle (RDC) and Medium Access Control (MAC).
+The UDP implementation is Contiki resides in
core/net/ip. The remainder of the section will focus on describing the UDP available functions.++The UDP API
+++We need to create a socket for the connection, this is done using the
+udp_socketstructure, which has the following elements:--
+struct udp_socket { + udp_socket_input_callback_t input_callback; + void *ptr; + struct process *p; + struct uip_udp_conn *udp_conn; +};Figure 45. Contiki MAC stack--The network layer can be accessed through the global variables
+NETSTACK_FRAMER,NETSTACK_RDCandNETSTACK_MAC, which are defined at compilation time.After creating the UDP socket structure, we need to register the UDP socket. This is done with the
udp_socket_register.-The variables are located in
+core/net/netstack.h, and can be defined by each platform as default and overridden by applications.++-/** + * \brief Register a UDP socket + * \param c A pointer to the struct udp_socket that should be registered + * \param ptr An opaque pointer that will be passed to callbacks + * \param receive_callback A function pointer to the callback function that will be called when data arrives + * \retval -1 The registration failed + * \retval 1 The registration succeeded + */ +int udp_socket_register(struct udp_socket *c, + void *ptr, + udp_socket_input_callback_t receive_callback);--MAC driver
--Contiki provides two MAC drivers: CSMA and NullMAC
-+CSMA (Carrier-Sense Multiple Access) receives incoming packets from the RDC layer and uses the RDC layer to transmit packets. If the RDC layer or the radio layer detects that the medium is busy, the MAC layer may retransmit the packet at a later point in time. CSMA protocol keeps a list of packets sent to each of the neighbors and calculate statistics such as number of retransmissions, collisions, deferrals, etc. The medium access check is performed by the RDC driver.
+As the UDP socket has been created and registered, let us listen on a given port. The
+udp_socket_bindfunction binds the UDP socket to a local port so it will begin to receive data that arrives on the specified port. A UDP socket will receive data addressed to the specified port number on any IP address of the host. A UDP socket bound to a local port will use this port number as source port for outgoing UDP messages.++
+/* + * \brief Bind a UDP socket to a local port + * \param c A pointer to the struct udp_socket that should be bound to a local port + * \param local_port The UDP port number, in host byte order, to bind the UDP socket to + * \retval -1 Binding the UDP socket to the local port failed + * \retval 1 Binding the UDP socket to the local port succeeded + */ +int udp_socket_bind(struct udp_socket *c, + uint16_t local_port);-NullMAC is a simple pass-through protocol. It calls the appropriate RDC functions.
+The
udp_socket_connectfunction connects the UDP socket to a specific remote port and optional remote IP address. When a UDP socket is connected to a remote port and address, it will only receive packets that are sent from that remote port and address. When sending data over a connected UDP socket, the data will be sent to the connected remote address.-As default both Z1 mote and RE-Mote uses the CSMA driver.
+A UDP socket can be connected to a remote port, but not to a remote IP address, by providing a
NULLparameter as the remote_addr parameter. This lets the UDP socket receive data from any IP address on the specified port.-
+#ifndef NETSTACK_CONF_MAC -#define NETSTACK_CONF_MAC csma_driver -#endif/** + * \brief Bind a UDP socket to a remote address and port + * \param c A pointer to the struct udp_socket that should be connected + * \param remote_addr The IP address of the remote host, or NULL if the UDP socket should only be connected to a specific port + * \param remote_port The UDP port number, in host byte order, to which the UDP socket should be connected + * \retval -1 Connecting the UDP socket failed + * \retval 1 Connecting the UDP socket succeeded + */ +int udp_socket_connect(struct udp_socket *c, + uip_ipaddr_t *remote_addr, + uint16_t remote_port);-Alternatively, a user can choose NullMAC as follow:
+To send data over a connected UDP socket it must have been connected to a remote address and port with
udp_socket_connect.+--
-#define NETSTACK_CONF_MAC nullmac_driver/** + * \brief Send data on a UDP socket + * \param c A pointer to the struct udp_socket on which the data should be sent + * \param data A pointer to the data that should be sent + * \param datalen The length of the data to be sent + * \return The number of bytes sent, or -1 if an error occurred + */ +int udp_socket_send(struct udp_socket *c, + const void *data, uint16_t datalen);-RDC driver
--Radio Duty-Cycle (RDC) layer handles the sleep period of nodes. This layer decides when packets will be transmitted and ensures that nodes are awake when packets are to be received.
-The implementation of Contiki’s RDC protocols are available in
+core/net/mac. The following RDC drivers are implemented:contikimac,xmac,lpp,nullrdcandsicslowmac. The implementation and details of the aforementioned RDC drivers are out of the scope of this chapter. The most commonly used is ContikiMAC. NullRDC is a pass-through layer that never switches the radio off.To send data over a UDP socket without being connected we use the function
udp_socket_sendtoinstead.--+
-#ifndef NETSTACK_CONF_RDC -#define NETSTACK_CONF_RDC contikimac_driver -#endif/** + * \brief Send data on a UDP socket to a specific address and port + * \param c A pointer to the struct udp_socket on which the data should be sent + * \param data A pointer to the data that should be sent + * \param datalen The length of the data to be sent + * \param addr The IP address to which the data should be sent + * \param port The UDP port number, in host byte order, to which the data should be sent + * \return The number of bytes sent, or -1 if an error occurred + */ +int udp_socket_sendto(struct udp_socket *c, + const void *data, uint16_t datalen, + const uip_ipaddr_t *addr, uint16_t port);-RDC drivers try to keep the radio off as much as possible, periodically checking the wireless medium for radio activity. When activity is detected, the radio is kept on to check if it has to receive the packet, or it can go back to sleep.
-The channel check rate is given in Hz, specifying the number of times the channel is checked per second, and the default channel check rate is 8 Hz. Channel check rates are given in powers of two and typical settings are 2, 4, 8, and 16 Hz.
+To close a UDP socket previously registered with
udp_socket_registerthe function below is used. All registered UDP sockets must be closed before exiting the process that registered them, or undefined behavior may occur.--+
-#ifndef NETSTACK_CONF_RDC_CHANNEL_CHECK_RATE -#define NETSTACK_CONF_RDC_CHANNEL_CHECK_RATE 8 -#endif/** + * \brief Close a UDP socket + * \param c A pointer to the struct udp_socket to be closed + * \retval -1 If closing the UDP socket failed + * \retval 1 If closing the UDP socket succeeded + */ +int udp_socket_close(struct udp_socket *c);-A packet must generally be retransmitted or "strobed" until the receiver is on and receives it. This increments the power consumption of the transmitter and increases the radio traffic, but the power savings at the receiver compensates for this and there is a net overall power saving.
-One alternative to optimize the RDC is to enable "phase optimization", which delays strobing until just before the receiver is expected to be awake. This however requires a good time synchronization between the transmitter and the receiver (more details in RDC Phase Optimization). To enable phase optimization change the 0 below to one.
+Each UDP socket has a callback function that is registered as part of the call to
udp_socket_register. The callback function gets called every time a UDP packet is received.+-
+#define CONTIKIMAC_CONF_WITH_PHASE_OPTIMIZATION 0 -#define WITH_FAST_SLEEP 1/** + * \brief A UDP socket callback function + * \param c A pointer to the struct udp_socket that received the data + * \param ptr An opaque pointer that was specified when the UDP socket was registered with udp_socket_register() + * \param source_addr The IP address from which the datagram was sent + * \param source_port The UDP port number, in host byte order, from which the datagram was sent + * \param dest_addr The IP address that this datagram was sent to + * \param dest_port The UDP port number, in host byte order, that the datagram was sent to + * \param data A pointer to the data contents of the UDP datagram + * \param datalen The length of the data being pointed to by the data pointer + */ +typedef void (* udp_socket_input_callback_t)(struct udp_socket *c, + void *ptr, + const uip_ipaddr_t *source_addr, + uint16_t source_port, + const uip_ipaddr_t *dest_addr, + uint16_t dest_port, + const uint8_t *data, + uint16_t datalen);+Alternatively there is another UDP library called
+simple-udp, which simplifies the UDP API to fewer functions. The library is located incore/net/ip/simple-udp.c. For the next example we are going to use thesimple-udplibrary, to show how to create a very first wireless example. In a later example we will come back to the full-fledged UDP API.-Framer driver
+UDP Link-Local multicast example
-The Framer driver is actually a set of functions to frame the data to be transmitted, and to parse the received data. The Framer implementations are located in
+core/net/mac, of which the most noticeable ones areframer-802154andframer-nullmac.This is the first example of the
02-ipv6folder.--In the RE-Mote platform the following configuration is the default:
--+-+
+#ifndef NETSTACK_CONF_FRAMER -#if NETSTACK_CONF_WITH_IPV6 -#define NETSTACK_CONF_FRAMER framer_802154 -#else /* NETSTACK_CONF_WITH_IPV6 */ -#define NETSTACK_CONF_FRAMER contikimac_framer -#endif /* NETSTACK_CONF_WITH_IPV6 */ -#endif /* NETSTACK_CONF_FRAMER */The
01-udp-local-multicastsummarizes how to read and set radio parameters, such as:+-
+
-Meaning that when IPv6 is used, the
+framer-802154is selected, else thecontikimac_frameris used (default one for thecontikimac_driver).We will also learn how to use the
Simple-UDPlibrary, which allows to create wireless applications on top of IPv6/UDP, and transmit data such as sensor readings and system information.-The
+framer-nullmacframer should be used together withnullmac_driver(MAC layer). This simply fills in the 2 fields ofnullmac_hdr, which are: receiver address and sender address.You will need at least two Zolertia motes, the
RE-MoteandZ1can be used together in the same network as the network implementation is platform-independent.-+The
-framer-802154is implemented incore/net/mac/framer-802154.c. The driver frames the data in compliance to the IEEE 802.15.4 (2003) standard. The framer insert and extracts the data to thepacketbufstructure.Flash the two Zolertia devices as:
++-make 01-udp-local-multicast.upload-IPv6 and Routing
--+One of Contiki’s most prominent feature is the support of IP protocols, being one of the first embedded operating systems to provide IPv6 support.
+++
+ ++ + +Alternatively Contiki also supports IPv4 and non-IP communication (Rime), however the remainder of this book will focus in IPv6. There is a good set of rime examples available at
+examples/rime. The RE-Motezoul-demo.cmost basic example atexamples/zolertia/zouluses rime as well.Remember to use the
PORTargument to specify the USB port in which a given Zolertia platform is connected. If you have aRE-Moteconnected in/dev/ttyUSB0port and another one in/dev/ttyUSB1but you only want to flash the first one, then:-IPv6
--The uIP is an Open Source TCP/IP stack designed to be used even with tiny 8 and 16 bit microcontrollers. It was initially developed by Adam Dunkels while at the Swedish Institute of Computer Science (SICS), licensed under a BSD style license, and further developed by a wide group of developers.
+++-make TARGET=zoul 01-udp-local-multicast.upload PORT=/dev/ttyUSB1-The implementation details of the uIP/uIPv6 is out of the scope of this section. The remainder of this section explains the basic configurations at the platform and application level.
-To enable IPv6 the following has to be defined, either in the application’s
+Makefileor in itsproject-conf.hfile:Likewise to open a serial console over USB to see the debug output:
+-+
+#define UIP_CONF_IPV6 1
+make TARGET=zoul login PORT=/dev/ttyUSB0+The
RE-Moteplatform will show something similar to:+-#ifndef NBR_TABLE_CONF_MAX_NEIGHBORS -#define NBR_TABLE_CONF_MAX_NEIGHBORS 20 -#endif -#ifndef UIP_CONF_MAX_ROUTES -#define UIP_CONF_MAX_ROUTES 20 -#endif +
+*** +Sending packet to multicast adddress ff02::1 (7) +ID: 171, core temp: 37.619, ADC1: 2332, ADC2: 0, ADC3: 1496, batt: 3300, counter: 1Contiki-3.x-2576-g4499d80 +Zolertia RE-Mote platform +Rime configured with address 00:12:4b:00:06:15:ab:25 (1) + Net: sicslowpan (2) + MAC: CSMA (3) + RDC: nullrdc (4) -/* uIP */ -#ifndef UIP_CONF_BUFFER_SIZE -#define UIP_CONF_BUFFER_SIZE 1300 -#endif +* Radio parameters: + Channel 15 (Min: 11, Max: 26) (5) + Tx Power 3 dBm (Min: -24 dBm, Max: 7 dBm) (6) + PAN ID: 0xBEEF -#define UIP_CONF_IPV6_QUEUE_PKT 0 -#define UIP_CONF_IPV6_CHECKS 1 -#define UIP_CONF_IPV6_REASSEMBLY 0 -#define UIP_CONF_MAX_LISTENPORTS 8+-+
+ +1 +MAC address of the +RE-Mote+ +2 +6LoWPAN implementation in Contiki ++ +3 +Carrier Sense Multiple Access Medium Access Control CSMA ++ +4 +Radio Duty cycling disabled (NullRDC) ++ +5 +2.4GHz RF channel (11-26 available) ++ +6 +Transmission power (-24dBm to 7dBm) +-RPL
--There are several routing flavors to chose, but ultimately all do the same thing: ensure that packets arrive at the right destination. This is done in different ways depending on factors such as the routing metric (how a route is qualified as better than others), whether the routing is done dynamically or statically, etc.
+As probably noticed, the default values for the 2.4GHz band channel is 26, not 15… why is now different? let’s take a closer look at the code:
-In Contiki the default routing protocol is RPL. Other protocols such as Ad hoc On-Demand Distance Vector (AODV) are out of the scope of this section.
+++-PROCESS_THREAD(mcast_example_process, ev, data) +{ + static struct etimer periodic_timer; + + /* Data container used to store the IPv6 addresses */ + uip_ipaddr_t addr; + + PROCESS_BEGIN(); + + set_radio_default_parameters(); + print_radio_values(); + + (...) +}--The specifics of the RPL implementation are out of the scope of this section, we merely describe the common configurations and provide a brief introduction to RPL. For more details, check the RPL implementation at
core/net/rpl.--What is RPL?--RPL is an IPv6 routing protocol for low power and lossy networks designed by the IETF Routing Over Low power and Lossy network (ROLL) group, used as the de facto routing protocol in Contiki. RPL is a proactive distance vector protocol, it starts finding the routes as soon as the RPL network is initialized.
+The
set_radio_default_parameters()configures the radio values to be used by the application:+--
+static void +set_radio_default_parameters(void) +{ + NETSTACK_RADIO.set_value(RADIO_PARAM_TXPOWER, EXAMPLE_TX_POWER); + NETSTACK_RADIO.set_value(RADIO_PARAM_PAN_ID, EXAMPLE_PANID); + NETSTACK_RADIO.set_value(RADIO_PARAM_CHANNEL, EXAMPLE_CHANNEL); +}Figure 46. RPL in the protocol stack--It supports three traffic patterns:
--+-
-
But where are the
EXAMPLE_CHANNEL,EXAMPLE_TX_POWERandEXAMPLE_PANIDvalues defined?++
+ ++ + +RPL builds Destination Oriented DAGs (DODAGs) rooted towards one sink (DAG ROOT) identified by a unique identifier DODAGID. The DODAGs are optimized using an Objective Function (OF) metric identified by an Objective Code Point (OCP), which indicates the dynamic constraints and the metrics such as hop count, latency, expected transmission count, parents selection, energy consumption, etc. A rank number is assigned to each node which can be used to determine its relative position and distance to the root in the DODAG.
+Try to do the following before reading further: +
grep -lr "EXAMPLE_CHANNEL" /home/user/contiki-Within a given network, there may be multiple, logically independent RPL instances. An RPL node may belong to multiple RPL instances, and may act as a router in some and as a leaf in others. A set of multiple DODAGs can be in an RPL INSTANCE and a node can be a member of multiple RPL INSTANCEs, but can belong to at most one DODAG per DAG INSTANCE.
+--A trickle timer mechanism regulates DODAG Information Object (DIO) message transmissions, which are used to build and maintain upwards routes of the DODAG, advertising its RPL instance, DODAG ID, RANK and DODAG version number.
+The
Makefileshows the location of theproject-conf.hconfiguration file:-A node can request DODAG information by sending DODAG Information Solicitation messages (DIS), soliciting DIO messages from its neighborhoods to update its routing information and join an instance.
+++-# Includes the project-conf configuration file +CFLAGS += -DPROJECT_CONF_H=\"../project-conf.h\" + +# This flag includes the IPv6 libraries +CONTIKI_WITH_IPV6 = 1-Nodes have to monitor DIO messages before joining a DODAG, and then join a DODAG by selecting a parent Node from its neighbors using its advertised latency, OF and RANK. Destination Advertisement Object (DAO) messages are used to maintain downward routes by selecting the preferred parent with lower rank and sending a packet to the DAG ROOT through each of the intermediate Nodes.
-RPL has two mechanisms to repair the topology of the DODAG, one to avoid looping and allow nodes to join/rejoin, and other called global repair. Global repair is initiated at the DODAG ROOT by incrementing the DODAG Version Number to create a new DODAG Version.
+Notice the
CONTIKI_WITH_IPV6flag, this effectively enabled IPv6 support in our application.-+More information about RPL can be found in RFC6550.
+The
+project-conf-hfile is in02-ipv6, and configures the following relevant values:+++/* Comment this out to use Radio Duty Cycle (RDC) and save energy */ +#undef NETSTACK_CONF_RDC +#define NETSTACK_CONF_RDC nullrdc_driver + +#undef IEEE802154_CONF_PANID +#define IEEE802154_CONF_PANID 0xABCD + +/* The following are Z1 specific */ +#undef RF_CHANNEL +#define RF_CHANNEL 26 + +#undef CC2420_CONF_CHANNEL +#define CC2420_CONF_CHANNEL 26 + +/* The following are Zoul (RE-Mote, etc) specific */ +#undef CC2538_RF_CONF_CHANNEL +#define CC2538_RF_CONF_CHANNEL 26+Now we know we are disabling Radio-Duty cycling and using
NullRDCand keeping the radio on, but the channel value default value is 26, not 15.-Routing support is enabled as default in the Z1 mote and RE-Mote platform. To enable routing the following has to be enabled:
+In the same
02-ipv6folder there is a header file namedexample.hwhich defines:+-
+#ifndef UIP_CONF_ROUTER -#define UIP_CONF_ROUTER 1 -#endif
+/* This is the UDP port used to send and receive data */ +#define UDP_CLIENT_PORT 8765 (1) +#define UDP_SERVER_PORT 5678 (2) + +/* Radio values to be configured for the 01-udp-local-multicast example */ +#define EXAMPLE_TX_POWER 31 (3) +#define EXAMPLE_CHANNEL 15 (4) +#define EXAMPLE_PANID 0xBEEF (5) + +/* This data structure is used to store the packet content (payload) */ +struct my_msg_t { (6) + uint8_t id; + uint16_t counter; + uint16_t value1; + uint16_t value2; + uint16_t value3; + uint16_t value4; + uint16_t battery; +};++
+ +1 +The UDP port opened by the device itself ++ +2 +The UDP port to send data to (opened by the server) ++ +3 +The new transmission power set in the example ++ +4 +The new channel set in the example ++ +5 +The new PAN ID configured in the example ++ +6 +The structure in which we are to store the data to be sent wirelessly +-To enable RPL add the following to your application’s
+Makefileor itsproject-conf.hfile.Let’s go back to the
01-udp-local-multicast.cexample:-
+#define UIP_CONF_IPV6_RPL 1/* The structure used in the Simple UDP library to create an UDP connection */ +static struct simple_udp_connection mcast_connection; + +/* Create the UDP connection. This function registers a UDP connection and + * attaches a callback function to it. The callback function will be + * called for incoming packets. The local UDP port can be set to 0 to indicate * that an ephemeral UDP port should be allocated. The remote IP address can + * be NULL, to indicate that packets from any IP address should be accepted. + */ +simple_udp_register(&mcast_connection, UDP_CLIENT_PORT, NULL, UDP_CLIENT_PORT, receiver);-The following is the default configuration done in the RE-Mote:
+First we have configured an UDP connection, passing as an argument the
mcast_connectionstructure to be used by thesimple-udplibrary. As the remote IP address is set toNULLany incoming packet will be accepted, invoking thereceivercallback handler whenever that happens:-
+/* ND and Routing */ -#define UIP_CONF_ND6_SEND_RA 0 (1) -#define UIP_CONF_IP_FORWARD 0 (2) -#define RPL_CONF_STATS 0 (3)static void +receiver(struct simple_udp_connection *c, + const uip_ipaddr_t *sender_addr, + uint16_t sender_port, + const uip_ipaddr_t *receiver_addr, + uint16_t receiver_port, + const uint8_t *data, + uint16_t datalen) +{ + radio_value_t aux; + struct my_msg_t *msgPtr = (struct my_msg_t *) data; (1) + leds_toggle(LEDS_GREEN); + uip_debug_ipaddr_print(sender_addr); (2) + + printf("\nData received on port %d from port %d with (3) + length %d\n", receiver_port, sender_port, datalen); + + NETSTACK_RADIO.get_value(RADIO_PARAM_CHANNEL, &aux); (4) + printf("CH: %u ", (unsigned int) aux); + + aux = packetbuf_attr(PACKETBUF_ATTR_RSSI); (5) + printf("RSSI: %ddBm ", aux); + + aux = packetbuf_attr(PACKETBUF_ATTR_LINK_QUALITY); (6) + printf("LQI: %u\n", aux); + + /* Print the received data */ (7) + printf("ID: %u, core temp: %u, ADC1: %d, ADC2: %d, ADC3: %d", + msgPtr->id, msgPtr->value1, msgPtr->value2, msgPtr->value3, + msgPtr->value4); + printf("batt: %u, counter: %u\n", msgPtr->battery, + msgPtr->counter); +}1 -Disable sending routing advertisements +Creates a pointer to dereference the message payload into the my_msg_tstructure defined inexample.h2 -Disable IP forwarding +A helper function used to print an IPv6 address in a readable form 3 -RPL Configuration statistics are disabled +Prints the UDP origin and destination port, and the message length ++ +4 +Retrieve the current RF channel number ++ +5 +Retrieve the RSSI level of the received message (on a 1-hop basis) ++ +6 +Retrieve the LQI value of the received message ++ 7 +Prints the payload content -The
+RPL_CONF_OFparameter configures the RPL objective function. The Minimum Rank with Hysteresis Objective Function (MRHOF) uses ETX as routing metric and it also has stubs for energy metric.As probably you have already noticed, we are sending the on-board sensor readings via wireless to the all-nodes multicast address:
-
+#ifndef RPL_CONF_OF -#define RPL_CONF_OF rpl_mrhof -#endifetimer_set(&periodic_timer, SEND_INTERVAL); + + while(1) { + PROCESS_WAIT_EVENT_UNTIL(etimer_expired(&periodic_timer)); + /* Create a link-local multicast address to all nodes */ + uip_create_linklocal_allnodes_mcast(&addr); + uip_debug_ipaddr_print(&addr); + printf("\n"); + + /* Take sensor readings and store into the message structure */ + take_readings(); + + /* Send the multicast packet to all devices */ + simple_udp_sendto(&mcast_connection, msgPtr, sizeof(msg), &addr); + + etimer_reset(&periodic_timer); + }--The Expected Transmissions metric (ETX) measure how many tries it takes to receive an acknowledgment (ACK) of a sent packet, keeping a moving average for each neighbor, computing the sum of all ETXs to build the routes.
+The
take_readings()function reads the sensors values and then stores it intomsg, amy_msg_tstructure.-As default Contiki uses
+storing modefor RPL downward routes. Basically all nodes store in a routing table the addresses of their child nodes.+-+/* Create a structure and pointer to store the data to be sent as payload */ +static struct my_msg_t msg; +static struct my_msg_t *msgPtr = &msg;-Set up a sniffer
-A packet sniffer is a must-have tool for any wireless network application, it allows to see what you are transmitting over the air, verifying both that the transmissions are taking place, the frames/packets are properly formatted, and that the communication is happening on a given channel.
+Notice the
simple_udp_sendtoaccepts any type of data as payload, we use themsgPtrpointer which points tomsgand thesizeof(msg)function to informsimple-udphow large is our payload.--There are commercial options available, such as the Texas Instruments SmartRF packet Sniffer, which can be used with a CC2531 USB dongle to capture packets like the one below.
----
-Figure 47. Sniffer packet capture+Program at least two
Z1orRE-Motewith the01-udp-local-multicast.capplication, and open a console connection usingmake loginfor each connected device.-+We will use for this exercise the SenSniff application, paired with a RE-Mote and Wireshark (already installed in instant Contiki). This setup will allow us to understand how the wireless communication is done in Contiki.
+You should be receiving messages from the other devices! Write down the node ID of other motes. This will be useful later.
++
+ ++ + +To program the RE-Mote as a packet Sniffer:
+Experiment with the channel, transmission power, RSSI and LQI levels:
--
+cd examples/cc2538-common/sniffer++-
+
-Compile and program:
+To change the sending interval you can also modify the values at:
--
+make TARGET=zoul sniffer.upload#define SEND_INTERVAL (15 * CLOCK_SECOND)+++- + -+At the moment of writing this section the Z1 sniffer was not officially included in Contiki, however a branch with the implementation is available at: -https://github.com/alignan/contiki/tree/z1_sniffer/examples/z1/sniffer
+Program at least one
+Z1orRE-Motewith the01-udp-local-multicastexample and another device with thesnifferapplication and sniff the traffic! try to filter outgoing and incoming data packets using your own rules.+Remember you are using the
01-udp-local-multicastapplication with the channel 15 and PAN ID 0xBEEF, you must change your sniffer settings also in itsproject-conf.hfile.+The Border Router
--Open a new terminal, and clone the sensniff project in your home folder:
+The border router or edge router is typically a device sitting at the edge of our network, which allow us to talk to outside networks using its built-in network interfaces, such as WiFi, Ethernet, Serial, etc.
+-+
+cd $HOME -git clone https://github.com/g-oikonomou/sensniff -cd sensniff/host
Figure 61. The border router--Then launch the sensniff application with the following command:
---+
+python sensniff.py --non-interactive -d /dev/ttyUSB0 -b 115200In Contiki the current and most used border router application implements a serial-based interface called SLIP, it allows to connect a given mote to a host using scripts like
tunslip6intools/tunslip6over the serial port, creating a tunnelled network interface, which can be given an IPv6 prefix to set the network global IPv6 addresses.+A simplification of
tunslip6and the Border Router is: IPv6 packets received by the host are forwarded over the USB connection to the Border Router viatunslip6, and subsequently all 6LoWPAN wireless packets are forwarded by the Border Router to the host as IPv6 packets via the USB connection throughtunslip6.-Sensniff will read data from the mote over the serial port, dissect the frames and pipe to
+/tmp/sensniffby default, now we need to connect the other extreme of the pipe to wireshark, else you will get the following warning:The border router application is located at
examples/ipv6/rpl-border-router, the following code snippets are the most relevant:-
+"Remote end not reading"/* Request prefix until it has been received */ +while(!prefix_set) { + etimer_set(&et, CLOCK_SECOND); + request_prefix(); + PROCESS_WAIT_EVENT_UNTIL(etimer_expired(&et)); +} + +dag = rpl_set_root(RPL_DEFAULT_INSTANCE,(uip_ip6addr_t *)dag_id); +if(dag != NULL) { + rpl_set_prefix(dag, &prefix, 64); + PRINTF("created a new RPL dag\n"); +}--Which is not worrisome, it only means that the other pipe endpoint is not connected. You can also save the sniffed frames for later opening with wireshark, adding the following argument to the above command
+-p name.pcap, which will save the session output in aname.pcapfile. Change the naming and location for storing the file accordingly.The snippet above bootstraps until a valid prefix has been given. Once the prefix has been assigned, the node will set the prefix and convert itself in the root node (DODAG).
--
+- -- - -At the moment of writing this tutorial changing channels from the Sensniff application was not implemented but proposed as a feature, check the Sensniff’s
+README.mdfor changes and current status.Normally it is preferable to configure the border router as a non-sleeping device, so that the radio receiver is always on (no radio duty cycling).
+By default the border-router applications includes a built-in web server, displaying information about the network, such as the immediate neighbors (1-hop away) and the known routes to nodes in their networks. To enable the web server, the
WITH_WEBSERVERflag should be enabled, and by default it will add thehttpd-simple.capplication.-Open another terminal and launch wireshark with the following command, which will add the pipe as a capture interface:
+The following assumes to use a RE-Mote platform, but the Z1 mote can be used as well.
-
+sudo wireshark -i /tmp/sensniffmake TARGET=zoul savetarget--Select the
+/tmp/sensniffinterface from the droplist and clickStartjust above.To compile, flash the mote and connect the border router to your host; run:
+--
+cd /home/user/contiki/examples/zolertia/tutorial/02-ipv6/02-border-router +make border-router.upload && make connect-routerFigure 48. Capture options--Make sure that the pipe is configured to capture packets in promiscuous mode, if needed you can increase the buffer size, but 1 MB is normally enough.
+By default it will try to connect to a mote at port
/dev/ttyUSB0using the following serial settings: 115200 baud rate, 8 bits, No parity and 1 bit stop. If you do not state an IPv6 prefix it will use the defaultaaaa::1/64, to specify a different one run the tunslip tool instead using the following:+--
+make connect-router PREFIX="2001:abcd:dead:beef::1/64"Figure 49. Interface settings--Now the captured frames should start to appear on screen.
+Or if you want to specify a different USB port:
+--
+make connect-router PREFIX="-s /dev/ttyUSB1 fd00::1/64"Figure 50. Captured frames--You can add specific filters to limit the frames being shown on screen, for this example click at the
+Expressionbutton and a list of available attributes per protocol are listed, scroll down to IEEE 802.15.4 and check the available filters. You can also chain different filter arguments using theFilterbox, in this case we only wanted to check the frames belonging to thePAN 0xABCDand coming from nodec1:0c::0309, so we used thewpan.dst_panandwpan.src64attributes.You can also compile and run the
tunslip6tool directly from the tools location, to compile just type:+--
+cd tools +cc tunslip6.c -o tunslip6Figure 51. Wireshark filters-When closing the Sensniff python application, a session information is provided reporting the following statistics:
+And to run with specific arguments, i.e. connect to a specific serial port, name your tunnel connection with a specific name, or proxify to a given address and port, use the following:
--
+Frame Stats: - Non-Frame: 6 - Not Piped: 377 - Dumped to PCAP: 8086 - Piped: 7709 - Captured: 8086./tunslip -s /dev/ttyUSB0 -t tun0 2001:abcd:dead:beef::1/64+-++Run
+tunslip -Hfor more information.-
-- + -Exercise: sniff the traffic! try to filter outgoing and incoming data packets using your own rules. - --The Border Router
--The border router or edge router is typically a device sitting at the edge of our network, which allow us to talk to outside networks using its built-in network interfaces, such as WiFi, Ethernet, Serial, etc.
+To enable IPv6 forwarding you need to run:
--
++-sudo sysctl -w net.ipv6.conf.all.forwarding=1Figure 52. The border router++To make this change permanent, edit the
/etc/sysctl.conffile and uncomment the following line:-+ + +In Contiki the current and most used border router application implements a serial-based interface called SLIP, it allows to connect a given mote to a host using scripts like
+tunslip6intools/tunslip6over the serial port, creating a tunnelled network interface, which can be given an IPv6 prefix to set the network global IPv6 addresses.
+net.ipv6.conf.default.forwarding=1-The border router application is located at
+examples/ipv6/rpl-border-router, the following code snippets are the most relevant:The output of the
tunslip6script is:-/* Request prefix until it has been received */ -while(!prefix_set) { - etimer_set(&et, CLOCK_SECOND); - request_prefix(); - PROCESS_WAIT_EVENT_UNTIL(etimer_expired(&et)); -} +
+tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 + inet addr:127.0.1.1 P-t-P:127.0.1.1 Mask:255.255.255.255 + inet6 addr: fe80::1/64 Scope:Link + inet6 addr: fd00::1/64 Scope:Global + UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 + RX packets:0 errors:0 dropped:0 overruns:0 frame:0 + TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 + collisions:0 txqueuelen:500 + RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) + +*** Address:fd00::1 => fd00:0000:0000:0000 +Got configuration message of type P +Setting prefix fd00:: +Server IPv6 addresses: + fd00::c30c:0:0:13c2 + fe80::c30c:0:0:13c2using saved target 'z1' +sudo ../../../../../tools/tunslip6 fd00::1/64 +[sudo] password for zolertia: +********SLIP started on ``/dev/ttyUSB0'' +opened tun device ``/dev/tun0'' +ifconfig tun0 inet `hostname` mtu 1500 up +ifconfig tun0 add fd00::1/64 +ifconfig tun0 add fe80::0:0:0:1/64 +ifconfig tun0 -dag = rpl_set_root(RPL_DEFAULT_INSTANCE,(uip_ip6addr_t *)dag_id); -if(dag != NULL) { - rpl_set_prefix(dag, &prefix, 64); - PRINTF("created a new RPL dag\n"); -}-The snippet above bootstraps until a valid prefix has been given. Once the prefix has been assigned, the node will set the prefix and convert itself in the root node (DODAG).
+This will create a
tun0interface in our host, try running theifconfigcommand in a terminal.-+Normally it is preferable to configure the border router as a non-sleeping device, so that the radio receiver is always on. You can configure the border router settings using the
+project-conf.hfile.Note the Border Router uses Stateless Auto Configuration SLAC to create its IPv6 address, by using the IPv6 prefix given to the
+tunslip6script and its own MAC address.+-+
+ ++ + ++ ++Contiki has changed the default prefix from
aaaa::/64tofd00::/64recently to the date of this book, so there might be example images and documentation still using the old prefix. You can use any of them, but it is preferred the later. Add the following to yourproject-conf.hfile and change the value accordingly to be consistent to the chosen prefix:--
+#undef NETSTACK_CONF_RDC -#define NETSTACK_CONF_RDC nullrdc_driver#define UIP_CONF_DS6_DEFAULT_PREFIX 0xaaaa-By default the border-router applications includes a built-in web server, displaying information about the network, such as the immediate neighbors (1-hop away) and the known routes to nodes in their networks. To enable the web server, the
+WITH_WEBSERVERflag should be enabled, and by default it will add thehttpd-simple.capplication.-Hands on: installing the border router
-The following assumes to use a RE-Mote platform, but the Z1 mote can be used as well.
+We can make a
ping6request to both thetun0interface and to theBorder Router:-
+make TARGET=zoul savetarget$ ping6 fd00::c30c:0:0:13c2 +PING fd00::c30c:0:0:13c2(fd00::c30c:0:0:13c2) 56 data bytes +64 bytes from fd00::c30c:0:0:13c2: icmp_seq=1 ttl=64 time=19.8 ms +64 bytes from fd00::c30c:0:0:13c2: icmp_seq=2 ttl=64 time=20.3 ms +64 bytes from fd00::c30c:0:0:13c2: icmp_seq=3 ttl=64 time=20.5 ms +64 bytes from fd00::c30c:0:0:13c2: icmp_seq=4 ttl=64 time=20.8 ms +64 bytes from fd00::c30c:0:0:13c2: icmp_seq=5 ttl=64 time=20.6 ms +64 bytes from fd00::c30c:0:0:13c2: icmp_seq=6 ttl=64 time=20.6 ms-To compile, flash the mote and connect the border router to your host; run:
+Furthermore, we can open a web browser and enter the Border Router’s IPv6 address, in this example:
--
+make border-router.upload && make connect-routerhttp://[fd00::c30c:0:0:13c2]--By default it will try to connect to a mote at port
-/dev/ttyUSB0using the following serial settings: 115200 baud rate, 8 bits, No parity and 1 bit stop. If you do not state an IPv6 prefix it will use the defaultaaaa::1/64, to specify a different one run the tunslip tool instead using the following:+-+
+make connect-router PREFIX=2001:abcd:dead:beef::1/64
Figure 62. Border Router web service--You can also compile and run the
+tunslip6tool directly from the tools location, to compile just type:The built-in web service will show the Border Router’s neighbors list and its routes. This is quite handy to check if the devices in our deployment have joined our Border Router’s network, retrieve their IPv6 addresses and even make a
ping6request.+-++Note we have been used a local IPv6 prefix, routable only in our network for testing purposes. It is also possible to assign the
+tunslip6a globally routable IPv6 prefix, thus connecting our Border Router to Internet.-+
+cd tools -cc tunslip6.c -o tunslip6
Figure 63. Border Router web service with IPv6 global address--And to run with specific arguments, i.e. connect to a specific serial port, name your tunnel connection with a specific name, or proxify to a given address and port, use the following:
+Using a public and globally reachable IPv6 prefix will make our Border Router, and subsequently all devices inside our IPv6/6LoWPAN network accessible over Internet:
+--+
+./tunslip -s /dev/ttyUSB0 -t tun0 2001:abcd:dead:beef::1/64
Figure 64. IPv6 online ping6-Run
+tunslip -Hfor more information.This means our 6LoWPAN network of constrained devices is reachable from anywhere in the world, and viceversa.
++-If you launch the sniffer you will be able to see how the Border Router starts sending the RPL control messages, such as
DIO(DAG Information Object) messages. If you flash another device with the previously used01-udp-multicast.cexample, you would be able to also see how a device joins the RPL network by exchangingDIO,DAO(Destination Advertisement Object) andDIS(DAG Information Solicitation) messages.-UDP and TCP basics
++++
++ ++ + +Now that we have covered the mote configurations and the MAC and routing layers, let us set up a UDP network.
+Remember the
01-udp-multicastand the02-border-routerexamples uses a different channel and PAN ID! don’t forget to change accordingly: probably the best place is to edit theexample.hheader file.-What is UDP?---UDP (User Datagram Protocol) is a communications protocol that offers a limited amount of services for messages exchanged among devices in a network that uses the Internet Protocol (IP).
+
--UDP is an alternative to the Transmission Control Protocol (TCP) and, together with IP, is sometimes referred to as UDP/IP. Like the Transmission Control Protocol, UDP uses the Internet Protocol to actually get a data unit (called a datagram) from one computer to another.
+Figure 65. Wireshark capture of a node joining a RPL network-+Unlike TCP, UDP does not provide message fragmentation and reassembling at the other end, this means that the application must be able to make sure that the entire message has arrived and is in the right order.
+Hands on: connecting an IPv6 UDP network to our host
-+Network applications that want to save processing time because they have very small data units to exchange (and therefore very little message reassembling to do) may prefer UDP to TCP
+In the
02-ipv6folder open the03-udp-client-and-serverexample.++The example shows how to send sensor information to an UDP server running on the host network, even on a different network over Internet.
+The UDP server is implemented in a python script, it allows to forward data also to other services.
--The UDP implementation is Contiki resides in
+core/net/ip. The remainder of the section will focus on describing the UDP available functions.The UDP server will send data to the MQTT broker of the Eclipse IoT foundation (at
iot.eclipse.org), or to IFTTT to easily configure different types of events using a HTTP message as trigger.-The UDP API
-We need to create a socket for the connection, this is done using the
+udp_socketstructure, which has the following elements:Depending on the device the UDP client runs (
Z1orRE-Mote), you need to adjust in theUDP-MQTT-server.pyorUDP-IFTTT-server.pythe following:-
+struct udp_socket { - udp_socket_input_callback_t input_callback; - void *ptr; - struct process *p; - struct uip_udp_conn *udp_conn; -};EXAMPLE_WITH_Z1 = 1--After creating the UDP socket structure, we need to register the UDP socket. This is done with the
-udp_socket_register.--+
+/** - * \brief Register a UDP socket - * \param c A pointer to the struct udp_socket that should be registered - * \param ptr An opaque pointer that will be passed to callbacks - * \param receive_callback A function pointer to the callback function that will be called when data arrives - * \retval -1 The registration failed - * \retval 1 The registration succeeded - */ -int udp_socket_register(struct udp_socket *c, - void *ptr, - udp_socket_input_callback_t receive_callback);This example is the easiest way if you want to send data to a service or server outside your network, and you don’t have an IPv6 network on your own. The Border Router as seen before can use a local
IPv6 prefixand then the UDP server running on the host can forward to anywhere and anyone.+This example requires at least two Zolertia devices: A Border Router and an UDP client. You can use alternatively
Z1andRE-Motesas both can interoperate with each other.-As the UDP socket has been created and registered, let us listen on a given port. The
+udp_socket_bindfunction binds the UDP socket to a local port so it will begin to receive data that arrives on the specified port. A UDP socket will receive data addressed to the specified port number on any IP address of the host. A UDP socket bound to a local port will use this port number as source port for outgoing UDP messages.You will also need to install the following python library if using the MQTT forwarder:
-
+* \brief Bind a UDP socket to a local port - * \param c A pointer to the struct udp_socket that should be bound to a local port - * \param local_port The UDP port number, in host byte order, to bind the UDP socket to - * \retval -1 Binding the UDP socket to the local port failed - * \retval 1 Binding the UDP socket to the local port succeeded - */ -int udp_socket_bind(struct udp_socket *c, - uint16_t local_port);pip install paho-mqtt-The
+udp_socket_connectfunction connects the UDP socket to a specific remote port and optional remote IP address. When a UDP socket is connected to a remote port and address, it will only receive packets that are sent from that remote port and address. When sending data over a connected UDP socket, the data will be sent to the connected remote address.You will need at least two Zolertia motes, the
RE-MoteandZ1can be used together in the same network.--A UDP socket can be connected to a remote port, but not to a remote IP address, by providing a
+NULLparameter as the remote_addr parameter. This lets the UDP socket receive data from any IP address on the specified port.The application (on the networking perspective) will be similar to:
+-+
+/** - * \brief Bind a UDP socket to a remote address and port - * \param c A pointer to the struct udp_socket that should be connected - * \param remote_addr The IP address of the remote host, or NULL if the UDP socket should only be connected to a specific port - * \param remote_port The UDP port number, in host byte order, to which the UDP socket should be connected - * \retval -1 Connecting the UDP socket failed - * \retval 1 Connecting the UDP socket succeeded - */ -int udp_socket_connect(struct udp_socket *c, - uip_ipaddr_t *remote_addr, - uint16_t remote_port);
Figure 66. UDP client and server network architecture--To send data over a connected UDP socket it must have been connected to a remote address and port with
+udp_socket_connect.And from the application service perspective the MQTT forwarder application will look like:
+-+
+/** - * \brief Send data on a UDP socket - * \param c A pointer to the struct udp_socket on which the data should be sent - * \param data A pointer to the data that should be sent - * \param datalen The length of the data to be sent - * \return The number of bytes sent, or -1 if an error occurred - */ -int udp_socket_send(struct udp_socket *c, - const void *data, uint16_t datalen);
Figure 67. UDP client and server MQTT application--To send data over a UDP socket without being connected we use the function
+udp_socket_sendtoinstead.And for the IFTTT example, we can implement a simple use case related to preventive maintenance: if the battery is close to deplete, or the device has been tampered (sensed by the accelerometer), or the radio link is close to fade (due to an unexpected obstacle), then schedule a calendar task to the maintenance crew.
+--+
+/** - * \brief Send data on a UDP socket to a specific address and port - * \param c A pointer to the struct udp_socket on which the data should be sent - * \param data A pointer to the data that should be sent - * \param datalen The length of the data to be sent - * \param addr The IP address to which the data should be sent - * \param port The UDP port number, in host byte order, to which the data should be sent - * \return The number of bytes sent, or -1 if an error occurred - */ -int udp_socket_sendto(struct udp_socket *c, - const void *data, uint16_t datalen, - const uip_ipaddr_t *addr, uint16_t port);
Figure 68. UDP client and server IFTTT application--To close a UDP socket previously registered with
-udp_socket_registerthe function below is used. All registered UDP sockets must be closed before exiting the process that registered them, or undefined behavior may occur.--+
-/** - * \brief Close a UDP socket - * \param c A pointer to the struct udp_socket to be closed - * \retval -1 If closing the UDP socket failed - * \retval 1 If closing the UDP socket succeeded - */ -int udp_socket_close(struct udp_socket *c);Let’s start!
-Each UDP socket has a callback function that is registered as part of the call to
+udp_socket_register. The callback function gets called every time a UDP packet is received.In the
03-udp-client.cexample first note the server address:---
-/** - * \brief A UDP socket callback function - * \param c A pointer to the struct udp_socket that received the data - * \param ptr An opaque pointer that was specified when the UDP socket was registered with udp_socket_register() - * \param source_addr The IP address from which the datagram was sent - * \param source_port The UDP port number, in host byte order, from which the datagram was sent - * \param dest_addr The IP address that this datagram was sent to - * \param dest_port The UDP port number, in host byte order, that the datagram was sent to - * \param data A pointer to the data contents of the UDP datagram - * \param datalen The length of the data being pointed to by the data pointer - */ -typedef void (* udp_socket_input_callback_t)(struct udp_socket *c, - void *ptr, - const uip_ipaddr_t *source_addr, - uint16_t source_port, - const uip_ipaddr_t *dest_addr, - uint16_t dest_port, - const uint8_t *data, - uint16_t datalen);-Alternatively there is another UDP library called
+simple-udp, which simplifies the UDP API to fewer functions. The library is located incore/net/ip/simple-udp.c. For the next example we are going to use thesimple-udplibrary, to show how to create a very first basic broadcast example. In a later example we will come back to the full-fledged UDP API./* Set the server address here */ +uip_ip6addr(&server_ipaddr, 0xfd00, 0, 0, 0, 0, 0, 0, 1);-Hands on: UDP example
-The objective of this example is to grasp the concepts shown in the preceding sections. We will create a UDP broadcast application using the
+simple-udp.As we are assuming we are going to use the
fd00::1/64IPv6 address for thetunslip6virtual interface, this will be the address of the host running theUDP-MQTT-server.pypython script, if not change accordingly.-There is a UDP broadcast example which uses RPL at:
+To verify that we have set the address correctly:
-
+cd examples/ipv6/simple-udp-rplprintf("Server address: "); +PRINT6ADDR(&server_ipaddr); +printf("\n");-Open the
+broadcast-example.cand theMakefile. Let’s see the contents of theMakefile:The
print_local_addresses(…)function will print the device configured addresses:--+
-UIP_CONF_IPV6=1 -CFLAGS+= -DUIP_CONF_IPV6_RPLstatic void +print_local_addresses(void) +{ + int i; + uint8_t state; + + PRINTF("Client IPv6 addresses:\n"); + for(i = 0; i < UIP_DS6_ADDR_NB; i++) { + state = uip_ds6_if.addr_list[i].state; + if(uip_ds6_if.addr_list[i].isused && + (state == ADDR_TENTATIVE || state == ADDR_PREFERRED)) { + PRINT6ADDR(&uip_ds6_if.addr_list[i].ipaddr); + PRINTF("\n"); + /* hack to make address "final" */ + if (state == ADDR_TENTATIVE) { + uip_ds6_if.addr_list[i].state = ADDR_PREFERRED; + } + } + } +}-The above adds the IPv6 stack and RPL routing protocol to our application.
-The
+broadcast-example.ccontains:Printing at boot something similar to:
-
+#include "net/ip/uip.h"Server address: fd00::1 +Client IPv6 addresses: +fe80::c30c:0:0:13c8--This is the main uIP library.
+Remember addresses starting with
fe80are link-local, this means the device has not joined the RPL network, as it has not received an IPv6 prefix from the Border Router (the DODAG) to create its own IPv6 global address using SLAC.--
+/* Network interface and stateless autoconfiguration */ -#include "net/ipv6/uip-ds6.h" - -/* Use simple-udp library, at core/net/ip/ */ -/* The simple-udp module provides a significantly simpler API. */ -#include "simple-udp.h" -static struct simple_udp_connection broadcast_connection;++As we know the prefix given to the Border Router is
fd00::/64, we know the device in this example will have thefd00::c30c:0:0:13c8IPv6 global address.+You can verify this later by checking the Border Router’s web service as done in the previous section.
-This structure allows storing the UDP connection information and mapped callback in which to process any received message. It is initialized in the following call:
+The UDP connection is created in the following block:
-
+simple_udp_register(&broadcast_connection, UDP_PORT, NULL, UDP_PORT, receiver);/* Create a new connection with remote host. When a connection is created + * with udp_new(), it gets a local port number assigned automatically. + * The "UIP_HTONS()" macro converts to network byte order. + * The IP address of the remote host and the pointer to the data are not used + * so those are set to NULL + */ + client_conn = udp_new(NULL, UIP_HTONS(UDP_SERVER_PORT), NULL); + + if(client_conn == NULL) { + PRINTF("No UDP connection available, exiting the process!\n"); + PROCESS_EXIT(); + } + + /* This function binds a UDP connection to a specified local por */ + udp_bind(client_conn, UIP_HTONS(UDP_CLIENT_PORT)); + + PRINTF("Created a connection with the server "); + PRINT6ADDR(&client_conn->ripaddr); + PRINTF(" local/remote port %u/%u\n", UIP_HTONS(client_conn->lport), + UIP_HTONS(client_conn->rport));-This passes to the simple-udp application the ports from/to in charge of handling the broadcasts, and the callback function to handle received broadcasts. We pass the NULL parameter as the destination address to allow packets from any address.
+As you have probably noticed, we are using the same
project-conf.hand theexample.hheaders from the previous01-udp-multicast.cexample. In this case we are using both UDP client and server port, opening the first to receive data from the UDP server running in the python script, and the second value to send data to the UDP server.-The receiver callback function is shown below:
+Upon receiving a message (from the UDP server for example) the
tcpip_handleris called to process the incoming data:-
+receiver(struct simple_udp_connection *c, - const uip_ipaddr_t *sender_addr, - uint16_t sender_port, - const uip_ipaddr_t *receiver_addr, - uint16_t receiver_port, - const uint8_t *data, - uint16_t datalen);static void +tcpip_handler(void) +{ + char *str; + + if(uip_newdata()) { + str = uip_appdata; + str[uip_datalen()] = '\0'; + printf("Received from the server: '%s'\n", str); + } +}-This application first sets a timer and when the timer expires triggers a randomly generated new timer interval (between 1 and the sending interval) to avoid flooding the network. Then it sets the IP address to the link local all-nodes multicast address as follows:
+And as done in the previous example the devices will send data from its on-board sensors using the
my_msg_tstructure to store the data as payload.-
+uip_create_linklocal_allnodes_mcast(&addr);while(1) { + PROCESS_YIELD(); + + /* Incoming events from the TCP/IP module */ + if(ev == tcpip_event) { + tcpip_handler(); + } + + /* Send data to the server */ + if((ev == sensors_event && data == &button_sensor) || + (ev == PROCESS_EVENT_TIMER)) { + + send_packet(); + + if(etimer_expired(&periodic)) { + etimer_reset(&periodic); + } + } + }--And then use the
-broadcast_connectionstructure (with the values passed at register) and send our data over UDP.--+
-simple_udp_sendto(&broadcast_connection, "Test", 4, &addr);The sensors information is sent periodically as configured by the
SEND_INTERVALvalue (default is every minute, change as you wish), or by pressing theuser buttonto request an immediate packet to be sent to the UDP server.-To extend the available address information, there is a library which allows to print the IPv6 addresses in a friendlier way, add this to the top of the file:
+The code snippet related to the payload sent to the UDP server address is shown next:
-
+#include "debug.h" -#define DEBUG DEBUG_PRINT -#include "net/ip/uip-debug.h"PRINTF("Send readings to %u'\n", + server_ipaddr.u8[sizeof(server_ipaddr.u8) - 1]); + +uip_udp_packet_sendto(client_conn, msgPtr, sizeof(msg), + &server_ipaddr, UIP_HTONS(UDP_SERVER_PORT));-So we can now print the multicast address, add this before the
+simple_udp_sendto(…)call:Compile and program the mote:
-
+PRINT6ADDR(&addr); -printf("\n");make TARGET=zoul savetarget +make 03-udp-client.upload && make login-Now let’s modify our receiver callback and print more information about the incoming message, replace the existing receiver code with the following:
+The output should be something similar to:
-
+static void -receiver(struct simple_udp_connection *c, - const uip_ipaddr_t *sender_addr, - uint16_t sender_port, - const uip_ipaddr_t *receiver_addr, - uint16_t receiver_port, - const uint8_t *data, - uint16_t datalen) -{ - /* Modified to print extended information */ - printf("\nData received from: "); - PRINT6ADDR(sender_addr); - printf("\nAt port %d from port %d with length %d\n", - receiver_port, sender_port, datalen); - printf("Data Rx: %s\n", data); -}Contiki-3.x-2611-g61576c3 +Zolertia RE-Mote platform +CC2538: ID: 0xb964, rev.: PG2.0, Flash: 512 KiB, SRAM: 32 KiB, AES/SHA: 1, ECC/RSA: 1 +System clock: 16000000 Hz +I/O clock: 16000000 Hz +Reset cause: External reset +Rime configured with address 00:12:4b:00:06:15:ab:25 + Net: sicslowpan + MAC: CSMA + RDC: nullrdc +UDP client process started +Server address: fd00::1 +Client IPv6 addresses: +fe80::212:4b00:615:ab25 +Created a connection with the server :: local/remote port 8765/5678 + +ID: 171, core temp: 34.47, ADC1: 2332, ADC2: 0, ADC3: 1500, batt: 3300, counter: 1 +Send readings to 1'--Before uploading your code, override the default target by writing in the terminal:
---+
-make TARGET=zoul savetargetRemember that you can also compile for the Z1 platform.
-Remember you can also use the Z1 mote as target.
+Remember to check the network and connection by using
ping6, like you normally would test a wireless device. Open the Border Router’s web service and see if you can find the node in your neighbor list!--Now clean any previous compiled code, compile, upload your code, restart the mote and print the serial output to screen (all in one command!):
+Once you found the node’s global IPv6 assigned address, make a
ping6request and check theICMPv6response. Don’t forget to use the wireless Sniffer and see how these ICMP packets looks like:+-+
+make clean && make broadcast-example.upload && make login
Figure 69. ICMPv6 ping messages--You will see the following result:
-----
+Rime started with address 193.12.0.0.0.0.0.158 -MAC c1:0c:00:00:00:00:00:9e Ref ID: 3301 -Contiki-2.6-1803-g03f57ae started. Node id is set to 158. -CSMA ContikiMAC, channel check rate 8 Hz, radio channel 26 -Tentative link-local IPv6 address fe80:0000:0000:0000:c30c:0000:0000:009e -Starting 'UDP broadcast example process' -Sending broadcast to -> ff02::1 - -Data received from: fe80::c30c:0:0:309 -At port 1234 from port 1234 with length 4 -Data Rx: Test -Sending broadcast to -> ff02::1With the Sniffer you are able to see the wireless messages within the 6LoWPAN network, but you can also capture in Wireshark the network traffic through the
tunslip6virtual interface (normallytundepending on the parameters you have used to create it).--
- - - --Exercise: Write down the node ID of other motes. This will be useful later. At this point you should also use the Sniffer and capture data over Wireshark. --To change the sending interval you can also modify the values at:
--+--
-#define SEND_INTERVAL (20 * CLOCK_SECOND) -#define SEND_TIME (random_rand() % (SEND_INTERVAL))There is a Wireshark capture saved as an example for you to take a look in
wireshark-ipv6-6lowpan.pcap.-+Hands on: connecting an IPv6 UDP network to our host
+Running the UDP server MQTT forwarder
-In the
+udp-client.cfile atexamples/ipv6/rpl-udp. set the server address to beaaaa::1(the host address), replace the options there (Mode 2 is default) and add:To execute the
UDP-MQTT-server.pyscript just run:-
+uip_ip6addr(&server_ipaddr, 0xaaaa, 0, 0, 0, 0, 0, 0, 1);python UDP-MQTT-server.py-To verify that we have set the address correctly let’s print the server address, in the
+print_local_addressesfunction add this to the end:This is the expected output when running and receiving a UDP packet from a
Z1node:-
+PRINTF("Server address: "); -PRINT6ADDR(&server_ipaddr); -PRINTF("\n");UDP6 server side application V0.1 +Started 2016-02-26 09:23:49.673940 +UDP server ready: 5678 +msg structure size: 13 + +MQTT: Connected (0) +2016-02-26 09:23:58 -> fd00::c30c:0:0:13c8:8765 14 +{ + "values": [ + { + "value": 171, + "key": "id" + }, + { + "value": 0, + "key": "counter" + }, + { + "value": 2320, + "key": "temperature" + }, + { + "value": -135, + "key": "x_axis" + }, + { + "value": 40, + "key": "y_axis" + }, + { + "value": -120, + "key": "z_axis" + }, + { + "value": 2981, + "key": "battery" + } + ] +} +MQTT: Publishing to {0}... 0 (171) +Sending reply to fd00::c30c:0:0:13c8 +MQTT: Published 2-The UDP connection is created in the following block:
+If we run the
mqtt-client.pypython script in a separate terminal we will receive a notification each time the UDP server publishes new data to thev2/zolertia/tutorialthings/#topic:+-
+/* new connection with remote host */ -client_conn = udp_new(NULL, UIP_HTONS(UDP_SERVER_PORT), NULL); -if(client_conn == NULL) { - PRINTF("No UDP connection available, exiting the process!\n"); - PROCESS_EXIT(); -} -udp_bind(client_conn, UIP_HTONS(UDP_CLIENT_PORT));python mqtt-client.py +connecting to iot.eclipse.org +Connected with result code 0 +Subscribed to v2/zolertia/tutorialthings/# +v2/zolertia/tutorialthings/171 {"values":[{"key": "id", "value": 171},{"key": "counter", "value": 0},{"key": "temperature", "value": 2326},{"key": "x_axis", "value": -129},{"key": "y_axis", "value": 38},{"key": "z_axis", "value": -122},{"key": "battery", "value": 2987}]}++
+ ++ + +And upon receiving a message the
+tcpip_handleris called to process the incoming data:The
udp-clientdevices publish to the following MQTT topic:-
+static void -tcpip_handler(void) -{ - char *str; - - if(uip_newdata()) { - str = uip_appdata; - str[uip_datalen()] = '\0'; - printf("DATA recv '%s'\n", str); - } -}v2/zolertia/tutorialthings/{{ID}}-Compile and program the mote:
+Where
{{ID}}corresponds to:--+
-cd examples/ipv6/rpl-udp -make TARGET=z1 savetarget -make udp-client.upload && make z1-reset && make login - -Rime started with address 193.12.0.0.0.0.0.158 -MAC c1:0c:00:00:00:00:00:9e Ref ID: 158 -Contiki-2.6-2071-gc169b3e started. Node id is set to 158. -CSMA ContikiMAC, channel check rate 8 Hz, radio channel 26 -Tentative link-local IPv6 address fe80:0000:0000:0000:c30c:0000:0000:009e -Starting 'UDP client process' -UDP client process started -Client IPv6 addresses: aaaa::c30c:0:0:9e -fe80::c30c:0:0:9e -Server address: aaaa::1 -Created a connection with the server :: local/remote port 8765/5678 -DATA send to 1 'Hello 1' -DATA send to 1 'Hello 2' -DATA send to 1 'Hello 3' -DATA send to 1 'Hello 4'msg.id = 0xAB;-Remember that you can also compile for the RE-Mote platform.
-UDP Server
+Thus the default topic will be
v2/zolertia/tutorialthings/171as shown in the previous snippet. To change the topic’s{{ID}}just change themsg.idvalue in03-udp-client.c.--The UDP server is a python script that echoes any incoming data back to the client, useful to test the bi-directional communication between the host and the network.
+The pound sign in
v2/zolertia/tutorialthings/#is a wildcard value, it will subscribe to any topic starting withv2/zolertia/tutorialthings/.-The
+UDP6.pyscript can be executed as a single-shot UDP client or as a UDP Server bound to a specific address and port, for this example we are to bind to addressaaaa::1and port5678.-The script content is below:
+If you want to change the default MQTT topic, change the following in
UDP-MQTT-server.py:-
+#! /usr/bin/env python - -import sys -from socket import * -from socket import error - -PORT = 5678 -BUFSIZE = 1024 - -#------------------------------------------------------------# -# Start a client or server application for testing -#------------------------------------------------------------# -def main(): - if len(sys.argv) < 2: - usage() - if sys.argv[1] == '-s': - server() - elif sys.argv[1] == '-c': - client() - else: - usage() - -#------------------------------------------------------------# -# Prints the instructions -#------------------------------------------------------------# -def usage(): - sys.stdout = sys.stderr - print 'Usage: udpecho -s [port] (server)' - print 'or: udpecho -c host [port] <file (client)' - sys.exit(2) - -#------------------------------------------------------------# -# Creates a server, echoes the message back to the client -#------------------------------------------------------------# -def server(): - if len(sys.argv) > 2: - port = eval(sys.argv[2]) - else: - port = PORT - - try: - s = socket(AF_INET6, SOCK_DGRAM) - s.bind(('aaaa::1', port)) - except Exception: - print "ERROR: Server Port Binding Failed" - return - print 'udp echo server ready: %s' % port - while 1: - data, addr = s.recvfrom(BUFSIZE) - print 'server received', `data`, 'from', `addr` - s.sendto(data, addr) - -#------------------------------------------------------------# -# Creates a client that sends an UDP message to a server -#------------------------------------------------------------# -def client(): - if len(sys.argv) < 3: - usage() - host = sys.argv[2] - if len(sys.argv) > 3: - port = eval(sys.argv[3]) - else: - port = PORT - addr = host, port - s = socket(AF_INET6, SOCK_DGRAM) - s.bind(('', 0)) - print 'udp echo client ready, reading stdin' - try: - s.sendto("hello", addr) - except error as msg: - print msg - data, fromaddr = s.recvfrom(BUFSIZE) - print 'client received', `data`, 'from', `fromaddr` - -#------------------------------------------------------------# -# MAIN APP -#------------------------------------------------------------# -main()MQTT_URL_PUB = "v2/zolertia/tutorialthings/"-+To execute the
+UDP6.pyscript just run:If you have an android mobile phone you can download the
+MyMQTTapplication and receive the notifications in your phone:+++
+Figure 70. MyMQTT android app-
+python UDP6.py -s 5678
+Server : "iot.eclipse.org" +Port : 1883 +Username/password not required +Topic: v2/zolertia/tutorialthings/#+Running the UDP server IFTTT forwarder
--This is the expected output when running and receiving a UDP packet:
+Create an IFTTT account and subscribe to the Maker Channel:
++-+
+udp echo server ready: 5678 -server received 'Hello 198 from the client' from ('aaaa::c30c:0:0:9e', 8765, 0, 0)
Figure 71. IFTTT Maker channel--The Server then echoes back the message to the UDP client to the given
+8765port, this is the expected output from the mote:And copy your
Keyas shown below:+++-+
+DATA send to 1 'Hello 198' -DATA recv 'Hello 198 from the client'
+Figure 72. IFTTT Maker channel configuration values+Then create the Recipe you want, for example to automatically create a calendar entry to the maintenance crew if the battery level is critical or the temperature of the room is too high, send an email whenever someones pushes the button, etc… you have plenty of channels to choose!
+--
+
Figure 53. Z1 mote talking to the PC host+Figure 73. IFTTT example recipe+- +In the
UDP-IFTTT-server.pyjust add theeventandkeyvalues:+TCP on IPv6
-What is TCP?@@ -7853,8 +9695,8 @@What is T
-The TCP implementation is Contiki resides in
core/net/ip. The remainder of the section will focus on describing the TCP available functions.-Hands on: TCP example
--+Now let us put to practice the TCP API described before and browse a TCP application. The
-tpc-socketexample is located inexamples/tcp-socket. The TCP server simply echoes back the request done on port 80.+Hands on: TCP example
--The
-Makefileenables as default the IPv4 stack, change it to IPv6:--+
-UIP_CONF_IPV6=1 -CFLAGS+= -DUIP_CONF_IPV6_RPLNow let us put to practice the TCP API described before and browse a TCP application. The
05-tpc-socketexample simply echoes back the request done on port 80.Then let us open the
@@ -8227,13 +10060,18 @@tcp-server.cexample and browse the implementation.CoAP, MQTT and HTTP
+In the previous section we covered some of the wireless basic, we should now have a good idea about working with Contiki. This section introduces two widely used protocols for the IoT: CoAP and MQTT. We will explain the basics and wrap up with ready to use examples.
+++
+Figure 74. MQTT and CoAP architectures+CoAP example
@@ -8242,6 +10080,12 @@CoAP ex
+More information about its implementation and author is available in the Erbium site.
+++
+Figure 75. CoAP: Constrained Application Protocol+Hands on: CoAP server and Copper
-+First get the Copper (Cu) CoAP user-agent.
+The objective of the lesson are:
++-
+
-Copper is a generic browser for the Internet of Things based on the Constrained Application Protocol (CoAP), a user-friendly management tool for networked embedded devices. As it is integrated into web browsers, it allows an intuitive interaction at the presentation layer making it easier to debug existing CoAP devices.
+You will need two Zolertia devices: a Border Router and a node acting as a CoAP server.
-More information available at Copper page
+This example works for both
Z1nodes andzoulplatforms like theRE-Mote, each one will expose its on-board sensors as aresource.-For this exercise we will use 2 motes: a Border Router and a CoAP server.
+Keep in mind the
Z1has lesser number ofresourcesenabled due to RAM constrains.+-
The application example itself can be understood as a finite state machine, although it seems complicated it is actually very straightforward. The
+mqtt_demo_processstarts as follows:The default values are set and now the topics and ID strings are going to be constructed by the
+update_config(…)function. This function sequentially calls other helpers functions, such asconstruct_client_id(…)andconstruct_pub_topic(…)and create the corresponding strings, stored in the following buffers:++++
+/* + * Buffers for Client ID and Topic. + * Make sure they are large enough to hold the entire respective string + */ +static char client_id[BUFFER_SIZE]; +static char pub_topic[BUFFER_SIZE]; +static char sub_topic[BUFFER_SIZE];+The
mqtt_demo_processstarts as follows:++
+PROCESS_THREAD(mqtt_demo_process, ev, data) { PROCESS_BEGIN(); - if(init_config() != 1) { (1) PROCESS_EXIT(); } - update_config(); (2) + while(1) { + PROCESS_YIELD(); + if((ev == PROCESS_EVENT_TIMER && data == &publish_periodic_timer) || + ev == PROCESS_EVENT_POLL) { (3) + state_machine(); + } + } + PROCESS_END(); +}+++
++ +1 +Initial configuration values, as described earlier ++ +2 +Creates the client ID, publish and subscribe topics. The initial state +STATE_INITis set and thepublish_periodic_timerevent is scheduled+ +3 +Handles the +publish_periodic_timer, this is where the application actually starts++The application example itself can be understood as a finite state machine, although it seems complicated it is actually very straightforward.
+++++
+Figure 89. MQTT example state machine+++Basically the
+state_machine(…)function sequentially handles the mqtt registration, configuration and connection to the Broker, then subscribe to the required topic. The code snippet below simplifies the state machine implementation to the basic taks done in each state:++++
+static void +state_machine(void) +{ + switch(state) { + case STATE_INIT: (1) + mqtt_register(&conn, &mqtt_demo_process, client_id, mqtt_event, + MAX_TCP_SEGMENT_SIZE); + state = STATE_REGISTERED; - uip_icmp6_echo_reply_callback_add(&echo_reply_notification, (3) - echo_reply_handler); - etimer_set(&echo_request_timer, conf.def_rt_ping_interval); (4) + case STATE_REGISTERED: (2) + if(uip_ds6_get_global(ADDR_PREFERRED) != NULL) { + /* Registered and with a public IP. Connect */ + connect_to_broker(); + } + etimer_set(&publish_periodic_timer, NET_CONNECT_PERIODIC); + return; + break; - while(1) { + case STATE_CONNECTING: (3) + break; - PROCESS_YIELD(); + case STATE_CONNECTED: (4) + /* Notice there's no "break" here, it will continue to subscribe */ - if(ev == sensors_event && data == PUBLISH_TRIGGER) { (5) - if(state == STATE_ERROR) { - connect_attempt = 1; - state = STATE_REGISTERED; + case STATE_PUBLISHING: (5) + if(mqtt_ready(&conn) && conn.out_buffer_sent) { + /* Connected. Publish */ + if(state == STATE_CONNECTED) { + subscribe(); + state = STATE_PUBLISHING; + } else { + publish(); } + etimer_set(&publish_periodic_timer, conf.pub_interval); + return; } + break; - if((ev == PROCESS_EVENT_TIMER && data == &publish_periodic_timer) || - ev == PROCESS_EVENT_POLL || - (ev == sensors_event && data == PUBLISH_TRIGGER)) { (6) - state_machine(); + case STATE_DISCONNECTED: (6) + if(connect_attempt < RECONNECT_ATTEMPTS || + RECONNECT_ATTEMPTS == RETRY_FOREVER) { + mqtt_disconnect(&conn); + etimer_set(&publish_periodic_timer, interval); + state = STATE_REGISTERED; + return; } + break; + } - if(ev == PROCESS_EVENT_TIMER && data == &echo_request_timer) { (7) - ping_parent(); - etimer_set(&echo_request_timer, conf.def_rt_ping_interval); - } + /* If we didn't return so far, reschedule ourselves */ + etimer_set(&publish_periodic_timer, STATE_MACHINE_PERIODIC); +}+++
++ +1 +Entry point, register the mqtt connection and move to the +STATE_REGISTEREDevent+ +2 +Attempts to connect to the broker. If the node has not joined the network (doesn’t have a valid IPv6 global address) it retries later. If the node has a valid address, then calls the +mqtt_connectfunction and sets the state toSTATE_CONNECTING, then sets thepublish_periodic_timerwith a faster pace+ +3 +This event just informs the user about the connection attempts. When the MQTT connection to the broker has been made, the +MQTT_EVENT_CONNECTEDis triggered at themqtt_eventcallback handler+ +4 +As we are connected now, proceed and publish. ++ +5 +Checks if the MQTT connection is OK in +mqtt_ready, then subscribe and publish+ +6 +Handles any disconnection event triggered from +MQTT_EVENT_DISCONNECTED++The
+mqtt_eventfunction is a callback handler in which we a notification from the mqtt library whenever an event happens. Themqtt_eventupdates the status of the application so thestate_machineknow what to do next.+@@ -9313,155 +11399,116 @@+static void +mqtt_event(struct mqtt_connection *m, mqtt_event_t event, void *data) +{ + switch(event) { + case MQTT_EVENT_CONNECTED: { (1) + state = STATE_CONNECTED; + break; + } + case MQTT_EVENT_DISCONNECTED: { (2) + state = STATE_DISCONNECTED; + process_poll(&mqtt_demo_process); + break; + } + case MQTT_EVENT_PUBLISH: { (3) + pub_handler(msg_ptr->topic, strlen(msg_ptr->topic), msg_ptr->payload_chunk, + msg_ptr->payload_length); + break; + } + case MQTT_EVENT_SUBACK: { (4) + break; + } + case MQTT_EVENT_UNSUBACK: { (5) + break; + } + case MQTT_EVENT_PUBACK: { (6) + break; } - - PROCESS_END(); }1
Initial configuration values, as described earlier +Event notification of a successful connection to the Broker 2 -Creates the client ID, publish and subscribe topics. The initial state +STATE_INITis set and thepublish_periodic_timerevent is scheduledDisconnection from the Broker event, immediately polls the mqtt_demo_processprocess and thestate_machinefunction is invoked.3 -Registers the event callback used when a ping event occurs +A publication from a topic we are subscribed has been received 4 -Starts the periodic ping timer +Successful subscription to a topic 5 -Allows to try and recover from +STATE_ERRORby pressing the user buttonSuccessful un-subscription to a topic 6 -Handles the -publish_periodic_timerand button events, this is where the application actually starts- 7 -When the periodic ping timer expires, pings the parent +Sucessful publication to a topic -+When the
+construct_client_idis first called with theSTATE_INIT, thestate_machineis called. A brief walkthrough of the state machine is shown next. Notice how in some events (likeSTATE_INIT) immediately the driver jumps to the next events as there is not abreakstatement.When receiving an event from a topic we are subscribed to, the
+MQTT_EVENT_PUBLISHevent is triggered and thepub_handleris called. The example allows to turn the red LED on and off alternatively.+The default topic the example subscribe to is
zolertia/cmd/leds, specifically to change the LED status we would need to publish to thezolertia/cmd/ledstopic with value1to turn the LED on, and0otherwise.++
+static void -state_machine(void) +pub_handler(const char *topic, uint16_t topic_len, const uint8_t *chunk, + uint16_t chunk_len) { - switch(state) { - - case STATE_INIT: (1) - /* If we have just been configured register MQTT connection */ - mqtt_register(&conn, &mqtt_demo_process, client_id, mqtt_event, - MAX_TCP_SEGMENT_SIZE); - state = STATE_REGISTERED; - - case STATE_REGISTERED: (2) - if(uip_ds6_get_global(ADDR_PREFERRED) != NULL) { - connect_to_broker(); - } else { - leds_on(STATUS_LED); - ctimer_set(&ct, NO_NET_LED_DURATION, publish_led_off, NULL); - } - etimer_set(&publish_periodic_timer, NET_CONNECT_PERIODIC); + /* If we don't like the length, ignore */ + if(topic_len != 17 || chunk_len != 1) { + printf("Incorrect topic or chunk len. Ignored\n"); return; - break; - - case STATE_CONNECTING: (3) - leds_on(STATUS_LED); - ctimer_set(&ct, CONNECTING_LED_DURATION, publish_led_off, NULL); - /* Not connected yet. Wait */ - DBG("Connecting (%u)\n", connect_attempt); - break; + } - case STATE_CONNECTED: (4) - /* Don't subscribe unless we are a registered device */ - if(strncasecmp(conf.org_id, QUICKSTART, strlen(conf.org_id)) == 0) { - DBG("Using 'quickstart': Skipping subscribe\n"); - state = STATE_PUBLISHING; + if(strncmp(&topic[13], "leds", 4) == 0) { + if(chunk[0] == '1') { + leds_on(LEDS_RED); + printf("Turning LED RED on!\n"); + } else if(chunk[0] == '0') { + leds_off(LEDS_RED); + printf("Turning LED RED off!\n"); } + return; + } +}++Alternatively we could subscribe to a topic
+zolertia/cmd/#and handle different types of commands, we would need to parse thetopicstring and handle the topic and payload (chunkstring).++The
+publishfunction create the string data to be published. Below is a snippet of the function highlighting only the most relevant parts.+@@ -9469,117 +11516,175 @@+static void +publish(void) +{ + int len; + uint16_t aux; + int remaining = APP_BUFFER_SIZE; (1) + buf_ptr = app_buffer; (2) - case STATE_PUBLISHING: (5) - /* If the timer expired, the connection is stable. */ - if(timer_expired(&connection_life)) { - /* - * Intentionally using 0 here instead of 1: We want RECONNECT_ATTEMPTS - * attempts if we disconnect after a successful connect - */ - connect_attempt = 0; - } + len = snprintf(buf_ptr, remaining, (3) + "{" + "\"d\":{" + "\"myName\":\"%s\"," + "\"Seq no\":%d," + "\"Uptime (sec)\":%lu", + BOARD_STRING, seq_nr_value, clock_seconds()); - if(mqtt_ready(&conn) && conn.out_buffer_sent) { - /* Connected. Publish */ - if(state == STATE_CONNECTED) { - subscribe(); - state = STATE_PUBLISHING; - } else { - leds_on(STATUS_LED); - ctimer_set(&ct, PUBLISH_LED_ON_DURATION, publish_led_off, NULL); - publish(); - } - etimer_set(&publish_periodic_timer, conf.pub_interval); - return; - } else { - /* - * Our publish timer fired, but some MQTT packet is already in flight - * (either not sent at all, or sent but not fully ACKd). - * - * This can mean that we have lost connectivity to our broker or that - * simply there is some network delay. In both cases, we refuse to - * trigger a new message and we wait for TCP to either ACK the entire - * packet after retries, or to timeout and notify us. - */ - } - break; + if(len < 0 || len >= remaining) { (4) + printf("Buffer too short. Have %d, need %d + \\0\n", remaining, len); + return; + } - case STATE_DISCONNECTED: (6) - DBG("Disconnected\n"); - if(connect_attempt < RECONNECT_ATTEMPTS || - RECONNECT_ATTEMPTS == RETRY_FOREVER) { - /* Disconnect and backoff */ - clock_time_t interval; - mqtt_disconnect(&conn); - connect_attempt++; + remaining -= len; (5) + buf_ptr += len; (6) - interval = connect_attempt < 3 ? RECONNECT_INTERVAL << connect_attempt : - RECONNECT_INTERVAL << 3; + /* Put our Default route's string representation in a buffer */ + char def_rt_str[64]; + memset(def_rt_str, 0, sizeof(def_rt_str)); + ipaddr_sprintf(def_rt_str, sizeof(def_rt_str), uip_ds6_defrt_choose()); + len = snprintf(buf_ptr, remaining, ",\"Def Route\":\"%s\"", + def_rt_str); (7) - DBG("Disconnected. Attempt %u in %lu ticks\n", connect_attempt, interval); + aux = cc2538_temp_sensor.value(CC2538_SENSORS_VALUE_TYPE_CONVERTED); + len = snprintf(buf_ptr, remaining, ",\"Core Temp\":\"%u.%02u\"", + aux / 1000, aux % 1000); (8) - etimer_set(&publish_periodic_timer, interval); + aux = adc_zoul.value(ZOUL_SENSORS_ADC1); + len = snprintf(buf_ptr, remaining, ",\"ADC1\":\"%u\"", aux); - state = STATE_REGISTERED; - return; - } else { - /* Max reconnect attempts reached. Enter error state */ - state = STATE_ERROR; - DBG("Aborting connection after %u attempts\n", connect_attempt - 1); - } - break; + aux = adc_zoul.value(ZOUL_SENSORS_ADC3); + len = snprintf(buf_ptr, remaining, ",\"ADC3\":\"%u\"", aux); - case STATE_CONFIG_ERROR: (7) - /* Idle away. The only way out is a new config */ - printf("Bad configuration.\n"); - return; + len = snprintf(buf_ptr, remaining, "}}"); (9) - case STATE_ERROR: (8) - default: - leds_on(STATUS_LED); - /* - * 'default' should never happen. - * - * If we enter here it's because of some error. Stop timers. The only thing - * that can bring us out is a new config event - */ - printf("Default case: State=0x%02x\n", state); - return; - } + mqtt_publish(&conn, NULL, pub_topic, (uint8_t *)app_buffer, + strlen(app_buffer), MQTT_QOS_LEVEL_0, MQTT_RETAIN_OFF); - /* If we didn't return so far, reschedule ourselves */ - etimer_set(&publish_periodic_timer, STATE_MACHINE_PERIODIC); + printf("APP - Publish to %s: %s\n", pub_topic, app_buffer); }1 -
Entry point, register the mqtt connection and move to the +STATE_REGISTEREDeventWe use the remainingvariable to store the remaining bytes in the buffer in which we are storing the string to be published2 -Attempts to connect to the broker. If the node has not joined the network (doesn’t have a valid IPv6 global address) it retries later. If the node has a valid address, then calls the +mqtt_connectfunction and sets the state toSTATE_CONNECTING, then sets thepublish_periodic_timerwith a faster paceUse a pointer to the buffer address, so we move the pointer position each time we add a new sensor value thus appending a new string 3 -This event just informs the user about the connection attempts. When the MQTT connection to the broker has been made, the +MQTT_EVENT_CONNECTEDis triggered at themqtt_eventcallback handlerThe snprintfcreates a formatted string at the position pointed by thebuf_otrpointer. The JSON string follows IBMM quickstart format.4 -As we are connected now, proceed and publish. Since we should not be using IBM’s quickstart, we skip changing the state to +STATE_PUBLISHINGand just go aheadIf the return value of snprintfis negative, or exceeds the remaining bytes in our buffer, it means the buffer is full. If this is the case for you, either increase theAPPP_BUFFER_SIZEvalue, or decrease the string content and lenght5 -Checks if the MQTT connection is OK in +mqtt_ready, then subscribe and publishUpdate the available bytes counter 6 -Handles any disconnection event triggered from +MQTT_EVENT_DISCONNECTEDAnd move the buf_ptrpointer to the end of the newly created string, so the next string to be written starts at the end of the previous one.7 -Halts the application, only allows valid configuration values +Store the IPv6 address of our next-hop neighbor. Steps 4-6 are omitted. 8 -Default event handler, stops the timer and do nothing +On-board sensors values are stored as string, only the +RE-Motesensors are shown but for theZ1mote is also done in the application+ 9 +Close the JSON string --The
+publishfunction create the string data to be published. Below is a snippet of the function highlighting only the most relevant parts. The example publishes periodically the following:The
mqtt_publishupdates the MQTT broker with the new values, publishing to the specifiedpub_topic. The default topic iszolertia/evt/statusas done in theconstruct_pub_topicfunction.--
-
+Now compile and upload the example:
+-
+static void -publish(void) -{ - len = snprintf(buf_ptr, remaining, - "{" - "\"d\":{" - "\"myName\":\"%s\"," - "\"Seq #\":%d," - "\"Uptime (sec)\":%lu", - BOARD_STRING, seq_nr_value, clock_seconds()); - - len = snprintf(buf_ptr, remaining, ",\"Def Route\":\"%s\",\"RSSI (dBm)\":%d", - def_rt_str, def_rt_rssi); - - len = snprintf(buf_ptr, remaining, ",\"On-Chip Temp (mC)\":%d", - cc2538_temp_sensor.value(CC2538_SENSORS_VALUE_TYPE_CONVERTED)); - - len = snprintf(buf_ptr, remaining, ",\"VDD3 (mV)\":%d", - vdd3_sensor.value(CC2538_SENSORS_VALUE_TYPE_CONVERTED)); - - mqtt_publish(&conn, NULL, pub_topic, (uint8_t *)app_buffer, - strlen(app_buffer), MQTT_QOS_LEVEL_0, MQTT_RETAIN_OFF); - - DBG("APP - Publish!\n"); -}
+make mqtt-example.upload++Compile and program a Border Router device as shown in the previous chapter. Verify the Border Router is online by making a
ping6request to it, then browse the Border Router’s web service and alsoping6the MQTT node.++
+ ++ + +The
+mqtt_publishupdates the MQTT broker with the new values, publishing to the specifiedpub_topic. The default topic isiot-2/evt/status/fmt/jsonas done in theconstruct_pub_topicfunction. This topic follows IBM’s format but it can be otherwise changed accordingly.The next screenshoots shows images of both Z1 and RE-Mote MQTT nodes, images and snippets are shown indistinctively.
+-When receiving an event from a topic we are subscribed to, the
+MQTT_EVENT_PUBLISHevent is triggered and thepub_handleris called. The example allows to turn the red LED on and off alternatively.The green LED will blink at a faster pace while the MQTT node is trying to connect to the MQTT broker, then when connected it will stop blinking.
-The default topic the example subscribe to is
+iot-2/cmd/+/fmt/json, specifically to change the LED status we would need to publish to theiot-2/cmd/leds/fmt/jsontopic with value1to turn the LED on, and0otherwise.Whenever the node publishes to the MQTT broker it will turn on the green LED, and off when it finishes publishing.
+-+
+static void -pub_handler(const char *topic, uint16_t topic_len, const uint8_t *chunk, - uint16_t chunk_len) -{ - if(strncmp(&topic[10], "leds", 4) == 0) { - if(chunk[0] == '1') { - leds_on(LEDS_RED); - } else if(chunk[0] == '0') { - leds_off(LEDS_RED); - } - return; - } -}
+Rime started with address 193.12.0.0.0.0.19.208 +MAC c1:0c:00:00:00:00:13:d0 Ref ID: 43981 +Contiki-3.x-2577-gea0738b started. Node id is set to 5072. +CSMA nullrdc, channel check rate 128 Hz, radio channel 26 +Tentative link-local IPv6 address fe80:0000:0000:0000:c30c:0000:0000:13d0 +Starting 'MQTT Demo' +MQTT Demo Process +Subscription topic zolertia/cmd/leds +Init +Registered. Connect attempt 1 +APP - MQTT Disconnect. Reason 3 +Disconnected +Disconnected. Attempt 2 in 1024 ticks +Registered. Connect attempt 2 +Connecting (2) +APP - Application has a MQTT connection +APP - Subscribing to zolertia/cmd/leds +APP - Application is subscribed to topic successfully +Publishing +APP - Publish to zolertia/evt/status: {"d":{"myName":"Zolertia Z1 Node","Seq no":1,"Uptime (sec)":63,"Def Route":"fe80::212:4b00:615:ab25","Temp":"2.768","X axis":"86"}}++There is a python script named
+mqtt-client.pyyou could use to subscribe to the MQTT broker and topic, and receive notifications whenever the MQTT node publishes.++In case of a Z1 node publishing to mosquitto’s MQTT broker:
+++++
+$ python mqtt-client.py +connecting to fd00::1 +Connected with result code 0 +Subscribed to zolertia/evt/status +Subscribed to zolertia/cmd/leds +zolertia/evt/status {"d":{"myName":"Zolertia Z1 Node","Seq no":1,"Uptime (sec)":63,"Def Route":"fe80::212:4b00:615:ab25","Temp":"27.68","X axis":"86"}}++For the RE-Mote:
+++++
+$ python mqtt-client.py +connecting to fd00::1 +Connected with result code 0 +Subscribed to zolertia/evt/status +Subscribed to zolertia/cmd/leds +zolertia/evt/status {"d":{"myName":"Zolertia RE-Mote platform","Seq #":5,"Uptime (sec)":239,"Def Route":"fe80::212:4b00:615:ab25","Core Temp":"34.523","ADC1":"2280","ADC3":"1452"}}++As explained before, the MQTT node subscribes to the following topic:
+++zolertia/cmd/led-+Note the
++in the subscribed topic, this allows to have different subsets of topics, such asleds.Sending as payload
+1will turn on the red LED, and a0off.++Execute this from the command line:
+++++
+mosquitto_pub -h "test.mosquitto.org" -t "zolertia/cmd/led" -m "1" -q 0++The above command will publish to the
+cmdtopic, all nodes subscribed to it will turn its red LED on.++++
+APP - Application received a publish on topic 'zolertia/cmd/leds'. Payload size is 1 bytes. Content: +Pub Handler: topic='zolertia/cmd/leds' (len=17), chunk_len=1 +Turning LED RED on! + +APP - Application received a publish on topic 'zolertia/cmd/leds'. Payload size is 1 bytes. Content: +Pub Handler: topic='zolertia/cmd/leds' (len=17), chunk_len=1 +Turning LED RED off!++
+ ++ + ++ +++Remember in Chapter 4 a MQTT Android application was shown, try to configure and command your
+RE-MoteorZ1from your mobile!-
At the present time the Ubidots example was to be merged to Contiki, however the functional example can be browsed and copied from George Oikonomou repository
+The original example and libraries were developed by George Oikonomou, available from George Oikonomou repository. At the time of writting it is not merged to Contiki, but available in the
iot-workshopbranch we are currently using in the book.-The Contiki’s Ubidots Library was written by George Oikonomou.
+The Ubidots example is located at: +
examples/zolertia/tutorial/99-apps/ubidots-example.-The Ubidots example is located at
+examples/ipv6/ubidots.Ubidots application is implemented at
apps/ubidots.-+Ubidots application is implemented at
+apps/ubidots.You will need a minimum of two Zolertia devices: a Border Router and a node acting as the Ubidots client.
++This example works for both
Z1nodes andzoulplatforms like theRE-Mote, each one will publish data from an attached SHT21 temperature and humidity sensor, shown in previous sections.-Ubidots application uses TCP sockets to connect to the host
@@ -9626,7 +11735,7 @@things.ubidots.com, which has the following IPv4 and IPv6 endpoints:
Figure 57. Ubidots endpoint IPv4/IPv6 addresses+Figure 90. Ubidots endpoint IPv4/IPv6 addresses+To check what’s going on enable the debug print statements in the
@@ -9637,11 +11746,53 @@ubidots.cfile, search for#define DEBUG DEBUG_NONEand replace with:-
As default the
+ubidotsapplication uses thethings.ubidots.comremote host, however if no NAT/NAT64 service is available to resolve the host address, the IPv6 endpoint can be explicitly defined as:First, you will have to register an account with Ubidots, create your data +source and variables and request an authentication token.
+++-
+
++There are three things to configure in the example:
+++-
+
++The example will build for IPv6 by default. If you have a NAT64 enabled Border Router or a similar software, open the example’s
+Makefile. ChangeCONTIKI_WITH_IPV6=1toWITH_IP64=1.+In the
project-conf.hfile configure the host address. If you don’t specify one, the Ubidots library will try to resolve the host name.--
+#define UBIDOTS_CONF_REMOTE_HOST "2607:f0d0:2101:39::2"/* IPv6 address of things.ubidots.com is "2607:f0d0:2101:39::2", leave + * commented to resolve the host name. The NAT64 address is "::ffff:3217:7c44" + */ +#define UBIDOTS_CONF_REMOTE_HOST "2607:f0d0:2101:39::2"+-+
+#define UBIDOTS_DEMO_CONF_UPTIME "XXXX" -#define UBIDOTS_DEMO_CONF_SEQUENCE "XXXX"
Figure 91. Ubidots API key--The last step is to assign an Ubidot’s fixed Short Token so we don’t have to request one when it expires, get one and add this to the
+Makefile, the file should look like this:This will be the value to be defined in
UBIDOTS_CONF_AUTH_TOKEN.++++As we are to post temperature and humidity values to Ubidots, create the variables and copy their
+Variable ID.-+
+DEFINES+=PROJECT_CONF_H=\"project-conf.h\" -CONTIKI_PROJECT = ubidots-demo -APPS = ubidots -UBIDOTS_WITH_AUTH_TOKEN=XXXXXXXX -ifdef UBIDOTS_WITH_AUTH_TOKEN - DEFINES+=UBIDOTS_CONF_AUTH_TOKEN=\"$(UBIDOTS_WITH_AUTH_TOKEN)\" -endif -all: $(CONTIKI_PROJECT) -CONTIKI_WITH_IPV6 = 1 -CONTIKI = ../../.. -include $(CONTIKI)/Makefile.include
Figure 92. Ubidots Temperature and humidity variables-+Note that you should replace the
+UBIDOTS_WITH_AUTH_TOKENwithout using "" quotes.Next in the
+project-conf.hfile replace accordingly:++
+/* User configuration */ +#define POST_PERIOD (CLOCK_SECOND * 40) +#define VARIABLE_BUF_LEN 16 +#define UBIDOTS_CONF_AUTH_TOKEN "" +#define VARKEY_TEMPERATURE "" +#define VARKEY_HUMIDITY "" +#define UBIDOTS_CONF_IN_BUFFER_SIZE 64-Now everything should be set, let’s compile and program a Z1 mote!
+Now compile and program:
-
+make TARGET=z1 savetarget -make clean && make ubidots-demo.upload && make z1-reset && make loginmake ubidots-client.upload++Compile and program a Border Router device as shown in the previous chapter. Verify the Border Router is online by making a
+ping6request to it, then browse the Border Router’s web service and alsoping6theubidots-clientnode.You should see the following output:
++The above shows how the
+ubidots-clientnode connects to the Ubidots server, and publishes data.+To visualize the data in a friendlier way, Ubidots provides ready to use dashboards with different visualization options (linear plot, scatter, tables, etc).
+---
+
Figure 58. Ubidots graphs--The values are displayed using a Multi-line chart and a Table-Values dashboard.
+Figure 93. Ubidots dashboardBibliog diff --git a/Releases/IoT in five days - v1.1 20160627.epub b/Releases/IoT in five days - v1.1 20160627.epub new file mode 100644 index 0000000..9c54133 Binary files /dev/null and b/Releases/IoT in five days - v1.1 20160627.epub differ diff --git a/Releases/IoT in five days - v1.1 20160627.pdf b/Releases/IoT in five days - v1.1 20160627.pdf new file mode 100644 index 0000000..8ada321 Binary files /dev/null and b/Releases/IoT in five days - v1.1 20160627.pdf differ
- CoAP example
@@ -2281,7 +2290,7 @@
- Device addressing
+
+
-