6LoWPAN Gateway plus IBM IoT Foundation give instant SensorTag GratificationFollow article
Weptech gateway and IBM IoT Foundation accelerate TI SensorTag development.
The Weptech 6LoWPAN IoT Gateway provides both 2.4GHz and Sub-GHz radios, together with Ethernet and an ARM Cortex-M3 microcontroller. With out-of-the-box support for the Contiki border router firmware, this makes it trivial to integrate SensorTags with existing IP networks.
The second generation TI SensorTag ships with support for Contiki and providing a number of example applications, including one that publishes sensor data to an MQTT broker. With the IP address of the IBM IoT Foundation Quickstart broker configured you can be up and running and graphing live sensor data within minutes.
Together the gateway hardware and IBM cloud service make it possible to evaluate cutting edge, standards-based sensor network solutions in short order. Next we'll take a look at the steps involved.
The network architecture is simple, with one or more SensorTags using 6LoWPAN over IEEE802.15.4 wireless network links, communicating with an edge/border router which performs network address translation from IPv6 to IPv4 (NAT64). Thereby enabling SensorTags — and other 6LoWPAN devices for that matter — to connect to IPv4 hosts on a local LAN and via the Internet.
Setting up the 6LoWPAN IoT Gateway
The gateway package I received contained a PCB assembly, pin header, enclosure that can be desktop or wall mounted, rubber feet and a USB cable for flashing and supplying power.
At the time of writing the gateway firmware had yet to be upstreamed to the Contiki GitHub repository alongside the TI SensorTag demos. However, a business card was included in the package for a contact at Weptech, from whom the latest firmware can be obtained.
With the gateway plugged in to a USB port on a computer with Python, it was just a matter of resetting the board and pressing the button next to reset, before running a script that communicates with a bootloader on the gateway's CC2538, to program flash memory with the new firmware.
The gateway does not have a management interface for configuration and instead it simply gets an IPv4 address via DHCP. Just connect to the network and provide power!
First you need to make sure that you have a suitable ARM toolchain installed and the Contiki sources available. For details of how to set up the software environment see the TI Wiki. The MQTT example can then be found in the directory examples/cc26xx/cc26xx-web-demo.
At the time of writing the gateway firmware did not support IPv6 bridging or any other means of accessing a SensorTag from the wired network. Therefore I disabled the CoAP server and network UART, along with the 6LBR client, in the file project-conf.h:
/* Enable/Disable Components of this Demo */ #define CC26XX_WEB_DEMO_CONF_MQTT_CLIENT 1 #define CC26XX_WEB_DEMO_CONF_6LBR_CLIENT 0 #define CC26XX_WEB_DEMO_CONF_COAP_SERVER 0 #define CC26XX_WEB_DEMO_CONF_NET_UART 0
The IP address of the MQTT broker is configured in mqtt-client.c.
The one shown above uncommented is that of the IBM cloud service, whereas the commented out address is that of a Mosquitto instance running on a Raspberry Pi situated on the local network, with an IP address 10.0.10.21 (converted from dotted quad to hex, this becomes 0A000A15).
Note also that I had to change the prefix from 64:ff9b::/96 to that shown above (10 bytes of “00” followed by two of “FF”), before it would work with the gateway.
At this point the sources were built with:
It's important that the board type is specified and if you end up flashing a SensorTag only to discover that it does nothing, it's quite possible the firmware was built for the wrong target.
By far the most cost effective way of getting applications onto a SensorTag is to use a Debugger DevPack. This can be used together with either the SmartRF Flash Programmer (Windows only) or CCS Uniflash (Windows and Linux versions available), both of which are free to download.
With Uniflash installed on Linux I started up the GUI using sudo, so that I could check for and install any available updates.
The command I then used with a Debugger DevPack to flash the SensorTag is:
$ sudo /opt/ti/uniflash_3.4/uniflash.sh -ccxml ~andrew/SW/Contiki/CC2650F128.ccxml -operation Erase -program cc26xx-web-demo.elf
The ccxml file describes the target device and debug probe. I generated this by running up TI's official IDE, Code Composer Studio — also free to download — importing an example project, changing project settings so that it used the Debugger DevPack (select XDS110 Debug Probe), before saving this and then locating the updated CC2650F128.ccxml file.
The contents of the file are included below for convenience:
However, note that it is possible that the software and/or probe may be updated at some point in the future to use a different CCXML configuration than the one shown above.
With the SensorTag programmed the Debugger DevPack was disconnected and a green LED on the tag started flashing. Next to see if it could connect to the gateway.
Determining the Device-ID
A simple web interface on the Weptech IoT Gateway allows you to quickly ascertain the IPv6 addresses of any connected SensorTags. The unique “Device-ID” — as required by the IBM Quickstart cloud service — can then be constructed by taking the last 3 bytes of the address and prepending 00124b. For example, in my case I had a tag with the address:
Which translates to a Device-ID of: 00124b8fc203.
If you have more than one SensorTag, simply power them up one at a time and note the new IPv6 address before powering the next one up.
IBM Internet of Things Foundation Quickstart
With confirmation that the SensorTag was connected to the 6LoWPAN gateway and the Device-ID, this could now be entered into the Quickstart web page to get immediate access to live sensor readings, uptime and wireless link signal strength.
Selecting any of the above datapoints would then cause this to be graphed as shown in previous image.
As can be seen Quickstart provides access to a whole host of data from the tiny SensorTag.
However, this is only the beginning and from here it's possible to plumb this into applications running on the IBM Bluemix platform-as-a-service (PaaS), which is based on Cloud Foundry and supports numerous programming languages, including Java, Node.js, Go, PHP and Python.
The Bluemix catalogue also includes container images, a wide selection of services and, notably, Node-RED, the visual wiring tool for the Internet of Things. Thereby enabling rapid prototyping of hosted IoT applications that combine data from many different sources and types of source, carrying out processing and providing a wide selection of outputs.
Spinning up a new Node-RED instance took only a matter of minutes and once this was running it took but a couple of clicks to cut and paste an automtically generated “flow” from Quickstart to Node-RED, that imported the live SensorTag feed and output sensor readings via debug nodes. From here the flow could easily be modified to implement custom logic and provide outputs etc.
The Weptech IoT Gateway provides a neat solution for bridging 6LoWPAN wireless networks and Ethernet, that is a marked improvement on the solution of using a BeagleBone running Linux, plus edge router software and a USB IEEE802.15.4 radio. At the moment there are one or two features that the gateway does not support and which would be nice to have, such as IPv6 bridging, although it sounds as though this may be in the pipeline.
Downloading and setting up an ARM toolchain and flash programming tools does take a little time, but shouldn't take much more than an hour or so and these are required whatever you do with Contiki on the SensorTag. Then once set up, that's it. Also, since the SensorTag unique ID is based on its IPv6 address — which in turn is derived from its MAC address — this means that you can use a single binary firmware image for many tags and don't have to configure them individually.
The IBM cloud tools provide a fantastic and very immediate resource for SensorTag developers. Bluemix is a paid-for service, however, a 30 day trial is provided and after this there is a monthly free allowance. Furthermore, by using using MQTT and Node-RED in the IBM cloud, there is always the possibility of later switch to using instances hosted elsewhere in the cloud or locally.