IoT Tutorial by Matthias Kovatsch

Yesterday there was an online event about the technology enabling the Internet of Things. The event, which as organized by the Eclipse Foundation, was in the form of a video tutorial presented by Matthias Kovastsch, researcher at ETH Zurich and author of Copper, Erbium, Californium, Scandium and Actinium. The tutorial, named “Connecting Sensor Networks“, presented a holistic overview of the Internet of Things technologies, from the physical layer (IEEE 802.15.4e) to the application (IETF CoAP) layers, and also presenting the open source hardware and software tools that are currently available to implement it. Of course, the OpenMote platform was there together with the Contiki operating system. Notice, however, that there are other open source software implementations of IoT standards, for example OpenWSN. If you missed the event, you can watch the video and the slide deck again here. We hope you enjoy it!

OpenMote at the IoT & Smart Cities PhD School in Lerici, Italy

The OpenMote team has taken part in organizing and sponsorizing the 2nd edition of the IoT & Smart Cities PhD School. The event is organized by Prof. Gianluigi Ferrari and its team from the WASNLab at the University of Parma and takes place every year during a week in the beatiful town of Lerici. This year several people related to the Internet of Things have been present at the school and presented their research activities, including Prof. Karsten Borman, Prof. Andrea Basso, Dr. Simon Duquennoy, Dr. Màrius Monton, Matthias Kovatsch and many others. We, the team at OpenMote, have participated in two activities.

First, the industrial consortium, where we presented our vision for an open source Internet of Things, both hardware and software,  that will foster its development and growth by enabling research, development and learning at various levels; universities and research centers to develop new technologies and to educate new generations of engineers, companies to prototype their solutions and, finally, individuals to develop their personal projects. All of them can count on the OpenMote platform and the open source stacks that are currently available (Contiki, OpenWSN and RiOT) for such purpose.

Second, the hackaton, where the attendees were divided in small groups (8 people) and had to complete an IoT related project in a short ammount of time (4 h). In the hackaton we provided the hardware (OpenMote kits) to develop the projects as well as the assistance to complete them in the required time. Out of three groups that were formed, two used the OpenMote platform for their projects. Using Contiki they were able to create a full 6LoWPAN network where resources (e.g. a temperature sensor) could be read on demand using CoAP. In the next picture you can see the various groups working in their projects while the mentors were providing support.

OpenMote at IoT School 2014

Overall, we have to say that we are very happy of our participation in the IoT & Smart Cities PhD School. It has been an amazing event from all perspectives and we want to thank the organizers and participants for making it so. Let’s hope that we can see each other again next year for the third edition.

The OpenMote team.

OpenMote at IETF90 in Toronto, Canada

From July 20 to July 28, 2014, the Internet Engineering Task Force (IETF) is celebrating its 90th meeting in Toronto, Canada. As last time in London, United Kingdom, the OpenMote team is participating in the Low-Power and Lossy and Networks (LLN) Plugfest, which encompases different IETF working groups like 6TiSCH, 6lo and ROLL. This time more than 20 people participated in the Plugfest with various prestentations and demos for draft standards and hardware/software tools, which are briefly summarized next.

For example, Qin Wang and Tengfei Chang from the University of Science and Technology Beijing, demonstrated the 6TiSCH Operation Sublayer (6top) [draft-wang-6tisch-6top-sublayer-01]. In summary, 6top is a management layer build on top of IEEE802.15.4e TSCH that aims to standardize the way the schedules are build and maintained. On its behalf, Nicola Accettura from UC Berkeley demonstrated On-The-Fly (OTF) scheduling [draft-dujovne-6tisch-on-the-fly-03], as depicted in the next picture. OTF provides mechanisms to dynamically adapt the allocated softcells between two TSCH neighbor nodes in order to satisfy a given set of bandwidth or delay constraints. Pascal Thubert from Cisco and Thomas Watteyne from Dust Networks/Linear Technology demonstrated the use of Proxy ND as a mechanism to reduce the amount of traffic flooded to the LLN by backbone IPv6 infrastructure (draft-thubert-6lowpan-backbone-router-03). The demo presented two Smart Mesh IP networks from Dust Networks connected through two Cisco switches froming a single IPv6 network domain.

IETF90_OnTheFly

Finally, Xavier Vilajosana Universitat Oberta de Catalunya demonstrated an IPv6 Flow Label within a RPL Domain [draft-thubert-6man-flow-label-for-rpl], as you can see in the next picture. IPv6 Flow Label replaces the RPL option inside an IPv6 flow label allowing to save 44 bits in each frame, and provides rules for the root to set/reset the flow label when forwarding packets to the Internet.

IETF90_Flowlabel

Besides the importance of the work presented and demonstrated in the plugfest regarding the standardization of LLN networks, we want to remark that most of these demonstrations made extensively use of the OpenMote platfrom running the OpenWSN stack. However, there are also other operating systems for the IoT being developed today. In that sense, OpenMote has donated an OpenMote bronze kit to RiOT developers in order to accelerate the porting of RiOT to the OpenMote platform.

The OpenMote team.

Flashing OpenMote via UART

Over the last weeks we have received several e-mails asking wether the OpenMote-CC2538 could be flashed via UART using the USB-to-UART (FTDI) port on the OpenBase. The answer was in all cases “Yes, indeed!“, but the devil is hidden in the details (as usual). Let’s start by getting back to the basics.

The Texas Instruments CC2538 supports flashing through UART or SPI under two conditions as described in the CC2538 User’s Guide. First, if no valid image is found in the Flash memory. Second, forcing it by pulling a configurable GPIO pin of port A to a certain level, e.g. high or low, within 10 us from startup. In both cases the CC2538 will enter a bootloader mode where it can be programmed through either port using the commands described in the CC2538 ROM User’s Guide.

Said that, it is technically possible to flash the OpenMote-CC2538 via UART. In fact, it was specifically designed to enable that and there are already certain tools that allow you to do it already: the cc2538-bsl and the cc2538-prog. Both are available at GitHub under an open source license; the first is written in Python and the second is written in C. We have only tried the first one since it is more portable, but we have to say that it works really good!

However, with the two first batches of OpenMote-CC2538 boards that we have shipped so far it impossible to do BSL programming out of the box since the Flash image that we loaded to test them after production has a locked bootloader. We know it’s a setback, but at that time we thought everyone would be using a JTAG probe to program the boards, since it is more convenient for debugging purposes. Of course, we were wrong and we have changed that. Now all the OpenMote-CC2538 boards that we ship come with a Flash image that has an unlocked bootloader.

Thus, for all those that have an OpenMote-CC2538 shipped prior to July 1st you will need a JTAG, for example the Segger J-Link, to upload a Flash image that has the bootloader unlocked. You can find information on how to upload the Flash image using the Segger J-Link here. In the upcoming weeks we will publish a tutorial that describes in detail how to unlock the bootloader and program the OpenMote-CC2538 using the cc2538-bsl, so stay tuned.

The OpenMote team.

OpenMote-CC2538 running FreeRTOS on tickless mode

That’s right, last week we got the OpenMote-CC2538 platform to run FreeRTOS on tickless mode and it only consumes 1.6 uA while it is is LPM2! Here’s a picture to testify it. We know, it has been published on Twitter already, but we believe it is so cool that we needed to post it again. If you also think it’s cool and want to learn more about the FreeRTOS tickless mode running on the OpenMote platfrom, keep reading.

OpenMote Tickless

So what does the tickless demo do? There is a single task that runs every 5 seconds and cycles the red led; the led is on for 250 ms and off for 4750 ms. While there is no other task ready to be run (e.g., because we only have one task and it is sleeping), the operating system enters tickless mode. In tickless mode the operating system disables the periodic tick interrupt that runs at 100 Hz, programs an asynchronous wake-up interrupt when the following task needs to be ready to run and, finally, it  puts the microcontroller to a sleep mode. When the interrupt fires the microcontroller wakes-up and resumes execution. This enables to greatly reduce energy consumption since the microcontroller does not need to necessarily wake up every 10 ms to just increment the tick count. Here’s a video to demonstrate it. We know, it is a very boring video in the world to demonstrate it, but it’s worth it.

 

However, if you plan to use the FreeRTOS tickless mode there is something that you need to know. Different sleep modes consume different energy and require different ammounts of time to wake-up depending on your microcontroller. Thus, the optimal sleep mode is not always the one that consumes the lowest energy; it will depend on the expected sleep time and the time required to wake-up from the selected sleep mode. For example, under LPM0 the CC2538 draws around 2 mA but is able to enter sleep mode and resume code execution immediately (0 us). Contrarily, under LPM1 the CC2538 draws less current (600 uA) but requires 4 us in order to start executing code. Finally, under LPM2 the CC2538 draws 1.6 uA but it requires up to 136 us in order to start executing code. Thus, for sleep times under under ~300 us it is not worth to go to LPM1 and for sleep times under ~3 ms it is not worth to go to LPM2, as you will be spending more energy overall due to the time spent in the transition states. We have already taken that into account and th FreeRTOS tickless port for the OpenMote-CC2538 decides which sleep mode is better according to the expected sleep time. This allows to minimize energy consumption regardless of the taks execution pattern of your application.

In the following days we will publish the (unofficial) FreeRTOS port to the OpenMote-CC2538 platform so that you can play with it. Stay tuned!

The OpenMote team.

PS: By the way, the first most boring video on the Internet to demonstrate asynchronous task scheduling is probably this one (source).

OpenBattery, now with sensors!

After receiving many requests from our customers, we have finally decided to ship the OpenBattery board with the sensors populated. This means that now the OpenBattery board is capable of sensing temperature and relative humidity (Sensirion SHT21), acceleration (Analog Devices ADXL346) and light (Maxim MAX44009) out of the box, no need to get your hands dirty with the soldering iron! By the way, all the sensors are digital and connected to the OpenMote-CC2538 via the I2C bus, which is passed through the XBee pins. Be quick and place your order in our shop before they are gone.

OpenBattery sensors

Celebrating 3 months

Today OpenMote is celebrating its third month of activity. The truth is that our work started a little bit earlier, when we started designing the hardware and talking about creating a small company to sell it, but production and shipping could not start until we were officially incorporated (and as you all know, in Spain these things take a while!). In order to celebrate we want to share two figures with you that are amazing.

First, in these three months of activity we have already shippied more than 100 OpenMote-CC2538 to our customers. It may not seem much to you, but to us it is kind of a magic number. It’s 10² and it sets our next milestone: 1000. Let’s see if we can make that happen before the year ends, but we will need your help to achieve it.

Second, the kits we have sold so far have gone to 15 different counties! These are the countries that have at least one OpenMote kit right now (in alphabetical order): Canada, China, France, Germany, Greece, Ireland, Italy, Portugal, Spain, Russia, Sweeden, Switzerland, United Kingdom, United States of America and Uruguay. How cool is that? The truth is that we could never imagine that such a small idea could spread that fast and that far.

Thanks for trusting us and keep spreading the word.

The OpenMote team.

Building OpenWSN with Scons in Eclipse

This short tutorial aims to provide a quick guide to setup Scons as an external tool to build OpenWSN in Eclipse on a Linux machine. Note that Scons is the building environment provided by OpenWSN which really simplifies setting up the project.

We assume that:

  • An openwsn-fw repository is cloned somewhere in your PC (e.g ~/cool_stuff/openwsn/openwsn_fw)
  • A system variable pointing to openwsn-fw home  exists in the environment (e.g $OPENWSN_HOME)
  • Eclipse is installed
  • Scons is installed
  • You are able to compile OpenWSN from a terminal using Scons.

First, import your project into Eclipse. This can be done by right-clicking on the Project Explorer (left side of eclipse) and selecting Import. Browse to the project directory,

e.g $OPENWSN_HOME/firmware/openos/projects/cc2538/03oos_openwsn

Then we will need to create one or more external builder according to the Scons targets we want to execute. To do so, select the Run-> External Tools -> External Tools Configurations

And on the left side “Program” right click and select new. The following image shows an example configuration to build cc2538 with GNU ARM toolchain.

More external tool configurations can be added, for example:

Apply changes or Run them.

And that’s it, now you can build OpenWSN in Eclipse using Scons.

Getting started with Contiki and OpenMote

Today we are going to explain how to start developing with Contiki using OpenMote hardware. To follow this tutorial you will need the following materials:

  • Computer running GNU/Linux
  • OpenMote bronze kit (available at our shop for 200€)
  • Segger ARM J-Link (available at Mouser for 48€)
  • ARM-JTAG-20-10 adapter (available at Olimex for 4.95€)
  • GitHub account

First of all, we assume that you are using a Debian-based operating system. In particular we provide instructions for the latest long-term support release of Ubuntu (14.04 LTS), which was released in May 2014. However, installation in other Debian-based distributions, e.g. Debian itself, should be similar if not equal. We are also aware that the whole process is available in Windows and MacOS X, since all the tools that we use are available for such operating systems, but at the moment we do not provide instructions for them. Alternatively you can download Instant Contiki, a virtual machine for VMWare Player that contains the operating system (Ubuntu) and all the software required to follow this tutorial. The password is user.

Assuming that you have a working GN/Linux based on Ubuntu, start by installing the tools to cross-compile C/C++ code for ARM microcontrollers. The tools are not available in the default Ubuntu repositories but are available through PPA repositories. Open a terminal and type the following commands.

sudo add-apt-repository ppa:terry.guo/gcc-arm-embedded
sudo apt-get update
sudo apt-get install gcc-arm-none-eabi gdb-arm-none-eabi

In addition take into account that, at the moment of writting this article, the gdb-arm-none-eabi packet is broken in Ubuntu 14.04 LTS since it conflicts with the standard GCC tools. In order to be able to install the package it you will need to issue the following command. Hopefully the issue will be resolved soon and this will no longer be needed.

sudo dpkg --install --force-overwrite /var/cache/apt/archives/gdb-arm-none-eabi_7.6.50.20131218-0ubuntu1+1_amd64.deb

To load code and debug you will also need to download and install the latest version of the Segger J-Link drivers for GNU/Linux. At the time of writing the latest version of Segger J-Link is 4.84.6. For Debian-based distributions you can download the DEB package for 32 bits or 64 bits systems from the Segger website. There are versions for Fedora-based distributions (RPM package), as well as for Windows (EXE) and MacOS X (DMG). To download the software you will need to provide the serial number of your Segger J-Link probe or confirm that you do not have a pirate probe version.

Once the download is complete move to the appropriate folder. To install de DEB package just type the following command and follow the onscreen instructions. Notice that we are using the 64 bit version and that by default the software installs to the /opt/SEGGER/JLink directory.

sudo dpkg --install jlink_4.84.6_x86_64.deb

Finally, you will need two additional packages: git and putty. First, git in order to be able to clone the Contiki repository from GitHub to your computer. Second, putty to be able to communicate with the OpenMote-CC2538 through a serial port. You can install both packages issuing the following commands in a terminal.

sudo apt-get install git putty

Now that you have all the tools required to compile, load and debug code for ARM microcontrollers, we need to obtain the Contiki source code. To do that, go to GitHub and create an account if you do not have one already. After that, go to the Contiki repository in gitHub and create a repository that forks it, as displayed below (top right corner).

Fork Contiki

Once you have forked the Contiki repository into your GitHub account you need to clone it into your computer by issuing:

git clone https://github.com/username/contiki.git ~/Contiki

If you plan on contributing to Contiki you can also add the original Contiki repository as an upstream tracking branch in git. That way you will be able to integrate changes in the Contiki main branch into your own Contiki branch, as well as contribute your changes back to the Contiki main branch by creating a pull request. To do so issue the following commands in a terminal:

git remote add upstream https://github.com/contiki-os/contiki.git
git fetch origin -v
git fetch upstream -v
git merge upstream/master

Now that you have the Contiki source code in your computer is time to compile it. Let’s start with a simple “Hello World” project. Issue the following commands on a terminal:

cd ~/Contiki/examples/hello-world
make TARGET=cc2538dk hello-world

The first command changes the current directory to the Contiki directory where the “Hello World” project resides. The second command triggers the compile of the whole Contiki operating system using its Makefile-based build system.

Compile Contiki

After a certain ammount of time you will see that various files have been compiled and the binaries for the CC2538 generated, as depicted next.

Compiled Contiki

Now that the code is compiled you need to upload it to the OpenMote. Prior to that make sure that the OpenMote is connected to the OpenBase and that the OpenBase is connected to the computer via the USB_FTDI USB port. Also make sure that the OpenBase on/off switch is in the USB_FTDI position. If so, you should see a green led on the OpenBase lighting. Next, make sure that the Segger J-Link is connected to the computer and connected to the OpenBase using the ARM-JTAG-20-10 adapter, as depicted next.

Contiki Setup

Once everything is properly connected you need to open a new terminal and start the Segger GDB Server by issuing the following command:

/opt/Segger/JLink/JLinkGDBServer -device CC2538SF53

This command executes the JLinkGDBserver to debug a CC2538SF53 device, which is the one we use for the OpenMote-CC2538 board. It is mandatory to include the “-device CC2538SF53” parameter since the Segger JLink needs to configure the CC2538 chip for standard JTAG operation (4 wire) instead of the new cJTAG (2 wire). You should see a dialog similar to the one depicted next where the JLinkGDBServer waits for a connection from the GDB client.

JLinkGDBServer

Once the Segger JLinkGDBServer is connected to the target device you need to go back to the other terminal and issue the following command:

arm-none-eabi-gdb

After issuing this command you should see a window like the following. Here GDB is waiting for you to input the commands to load the target code and start debugging.

arm-none-eabi-gdb

Once GDB is executing, issue the following commands one by one in the GDB window:

target remote localhost:2331
monitor interface jtag
monitor speed 5000
monitor endian little
monitor flash download = 1
monitor flash breakpoints = 1
monitor reset
load hello-world.elf

This commands are responsible for configuring the GDB client to talk to the GDB server (the one executing in the other terminal) and loading the “Hello World” machine code compiled for the CC2538 (located in the hello-world.elf file) to the OpenMote. At this point you should see the code loading to the OpenMote, as depicted next.

Loaded GDB

Each command that you execute in the GDB client reflects in the GDB server, as depicted next.

Loaded JLink

Once the code has been successfully loaded into the OpenMote-CC2538 board, launch PuTTY and open the appropriate serial port, probably under the name of /dev/ttyUSBX. In our case the serial port is under /dev/ttyUSB0, as depicted next. The default serial parameters are 115200 bps, 8 bits, no parity, 1 stop bits and no flow control. In addition, remember that to be able to open the serial port PuTTY will need super user privileges (hint: use sudo!).

PuTTY

Once the code has been successfully loaded and PuTTY is connected to the appropriate serial port press the reset button on the OpenMote. You will see three leds fade shortly and a “Hello world” message will be sent through the serial port, as shown next.

PuTTY Contiki

And that’s it, congratulations! You have successfully compiled Contiki and loaded into the OpenMote. In following tutorials we will show how to compile and run more advanced examples.

Understanding IEEE 802.15.4e Enhanced Beacons in OpenWSN

This post is aimed at understanding the header format of the Enhanced Beacons (EB) sent by the IEEE 802.15.4e implementation at OpenWSN.org. We dealt with that some time back and we almost forget, so let’s see what’s in there again!

openwsn_logo

First of all, we flash two OpenMote-CC2538 with the head of the develop branch of the firmware project from OpenWSN. We also clone the software project to be able to control the network with OpenVisualizer. In the next image you can see OpenVisualizer running. In addition to that, we also need a Texas Instruments CC2531 USB packet sniffer and the Packet Sniffer software from the Texas Instruments’s website. You can also setup a sniffer with Wireshark using an additional OpenMote-CC2538 and an OpenBase, as described in our last post.

OV1

Once the motes have been flashed we start the IEEE 802.15.4e network. The mote with MAC address 1415:920B:0301:00ED (alias ED) is set as DAGROOT in OpenVisualizer by toggling the button in the user interface. The mote with MAC address 0012:4B00:041E:F0BE (alias BE) joins the network. In parallel, the TI Packet Sniffer has been connected to the USB port of the laptop and the Packet Sniffer tool has been started, as depicted in the next figure. The sniffer channel has been set to 20 (0×14), the default channel in OpenWSN when Channel Hopping is not enabled.

photo1    photo2

 As a reference we use the IEEE 802.15.4e Standard specification, which can be download here. Note that the format of the packets is little endian.

154eHeader

An interesting packet to look at is the Enhanced Beacon (EBs), which contains information about the schedule of the network. OpenWSN implements a new specification being developed at the IETF 6TiSCH working group which aims to standardize a minimal schedule configuration. This enables devices implementing IEEE 802.15.4e to be able to communicate amongst them without requiring an scheduler node. The draft-ietf-6tisch-minimal states that the EB carries 2 Information Elements (IE), namely the Sync IE and the SlotFrame and Link IE. Let’s see them!

The first 2 bytes are the Frame Control field that contains information defining the frame type, addressing fields, and other control flags. For details see page 59 of the 802.15.4e standard.

EB1

 The next byte is the MAC sequence number, as depicted in the following image.

EB2

 And the PANID as a network indentifier. Please notice that CAFE (coffee in Spanish) is the PANID of OpenWSN networks.

EB3

The PANID is then followed by the destination address. In an EB the destination address is a broadcast address as the beacon is used to announce the presence of the network.

EB4_destinationAddress

 Following that, the source address is the MAC of  our DAGROOT node (ED).

EB5_srcAddress

If OpenWSN had security enabled the security header would come next. However we are working with plain packets (no encryption), so next bytes on the headers are concerned to Information Elements (IE).

An Information Element (IE) provides a flexible, extensible, and easily implementable method of encapsulating information. The general format of an IE consists of an identification (ID) field, a length field, and a content field. IEs may be either part of the MAC header or MAC payload. Header IEs are used by the MAC to process the frame immediately, i.e., they cover security, addressing, etc., and are part of the MAC header. Payload IEs are destined for another layer and are part of the MAC payload.

As expected, we find 2 payload IEs in the OpenWSN EB. Of these the Sync IE comes first, as depicted next.

EB6_syncIE

Its length is 10 bytes. The first 2 are the Payload IE descriptor that indicates length of the IE, groupID and type. Following that we have the MLME subheader indicating the length of the IE that follows and type (Sync IE). The last 6 bytes are the Sync IE content, formed by the ASN (0×00 0×00 0×00 0×31 0xB7) -note little endian in the capture-, and 0×00 for the Join Priority field. This is because this node is the DAGROOT and advertises its join priority according to its rank in the network (which is 0). Again, see draft-ietf-6tisch-minimal for more details.

Finally my favorite IE, the SlotFrame and Link IE which announces the static schedule defined by the draft-ietf-6tisch-minimal.

EB7_slotframeAndLinkIE

The IE is composed by a variable number of bytes as it depends on the schedule being advertised. The first 2 bytes are the Payload IE descriptor that indicates length of the IE, groupID and type. Following that we have the MLME subheader indicating the length of the IE that follows and type (SlotFrame and Link IE). The following 4 bytes contain the SlotFrame and Link IE subheader, which indicate the slotframe size (0×65==101) and the number of active slots (0×06), as depcited in the two following images.

EB8_slotframesize

EB8_slotframesize

 The rest of the packet is one entry per slot as a tuple [timeslot_num (2B), ch.offset(2B), link_option (1B)]. For example, we can look at slot 3 being defined  as [timeslot_num == 0x03, ch.offset == 0x00, link_option == 0x0E] which translated to shared, transmit and receive slot. Please see draft-ietf-6tisch-minimal and IEEE.802.15.4e standard for further details.

EB10_linkInfo

And that’s it! We hope this post is useful for those that are dealing with bits and bytes of this protocol.

Powered by WordPress. Designed by Woo Themes