RIOT Summit

Yesterday, I remotely attended the discussion on the web and the IOT at the RIOT Summit. It was interesting to hear about designs for a Web of Things on top of the protocols currently being built out, as well as CoAP-specific security.

I also got the chance to describe the gCoAP implementation I'm developing. I presented a few slides and accompanying audio that other might be interested to review.

Many thanks to the RIOT team for organizing the summit, and to Carsten Bormann for arranging the remote access!

RIOT Investigation

As mentioned in the Nethead roadmap, I have been investigating RIOT. It now provides a solid border router and 802.15.4 wireless networking. The GNRC networking stack is well done. The project also is very well run, and welcoming to newcomers.

I plan to advance with porting Nethead to work with RIOT, on SAMR21 Xplained Pro motes. I already have implemented a minimal CoAP client for the GNRC networking stack.

As part of developing the client, I ran across a bug with the layer 4 checksum. It was a pleasure to work with Martine Lenders to integrate the fix.

Nethead with Linger

I added an interactive network map, dubbed Linger, to Nethead. It shows the motes and links for low-power/lossy network. You can see a screenshot on the Nethead wiki home page.

The source for the project is integrated into my fork of Adagios.

Nethead on GitHub

The mote monitoring project now is minimally useful. I call it Nethead, and it lives on GitHub. Motes report RSS readings via CoAP to a Python-based Nethead process on the monitoring server. Nethead uses the pynag library to programatically create host and service records in a Nagios 3 instance, for the motes and neighbor links. Adagios provides an attractive Django-based UI for Nagios.

See the Nethead site for details and a roadmap. Contributors welcome!

Tracking Kaji Development

Development of my mote monitoring project is ready for a sustainable user interface. So, I am picking up on the Kaji project, which is working toward version 0.2, with influxdb and grafana integration. The UI is not yet usable, but you can follow the state of the effort on a separate page.

OpenMotes at Full Strength

The OpenMote developers also were surprised at the low signal strength I reported in my last post: -69 dBm at 25 cm separation. It wasn't clear which of the two motes was malfunctioning, so they replaced both of them. Thanks, guys!

It turns out that only one of the original batch of motes was causing the trouble. The other mote and the replacements all report a signal strength around -40 dBm at 25 cm.

RSS Monitoring with OpenMote

I have upgraded my network monitoring setup to use OpenMotes, as you can see in the photo below.


I only had to recompile the OpenWSN firmware with the proper board and toolchain parameters:

scons board=cc2538 toolchain=armgcc oos_openwsn

OpenMotes require use of a Segger J-Link to flash the program code. I followed the instructions on the OpenWSN wiki. The J-Link will be valuable for debugging, but I also look forward to flashing directly via USB with the cc2538-bsl utility.

I was able to run my network monitoring demo of RSS reporting using this setup. I found the Toggle button to establish the DAGroot on the OpenVisualizer web app less reliable with OpenMotes than with TelosB. However, once the network was established, it worked as expected.

I was surprised to see a signal strength of -69 dBm with a pair of motes only 25 cm apart. I would have expected at least another 10 dB, even with the stubby antennas. I plan to contact the OpenMote developers for their experience.

[Update 2014-09-29: As described in a follow-up post, one of the motes was faulty. With a free replacement from the OpenMote team, the signal strength is around -40 dBm.]

At any rate, we now have the infrastructure to start development of CoAP-based RESTCONF monitoring. I may work a little more on OpenMote setup, but then it's time for some prototyping and design.

OpenVisualizer on BeagleBone

I'm upgrading my setup for network monitoring experimentation. I wanted to remove the requirement for a full-on workstation to host the OpenVisualizer border router. It's running now on a BeagleBone Black as you can see from the blue lights below!


The BeagleBone runs Debian by default, which I also run on my laptop workstation, so setup was pretty straightforward. I've summarized the steps on a separate page. Let me know of any experience reports or improvements.

I was able to run my network monitoring demo of RSS reporting using this setup. I think the next upgrade step is to replace the TelosB mote with an OpenMote. Then we'll have some code space to develop a CoAP-based monitoring module.

Standardized LLN Monitoring with RESTCONF

My last post described some RSS monitoring I hacked together, including some questions on how to develop a usable system going forward. I have been following reports from IETF90 with an eye toward these questions, and it sounds like this topic was on the minds of participants as well. The word I hear is that concensus is building around a CoAP-ified RESTCONF.

I just added a web page with some plans for implementation of a demonstration system built around RESTCONF, Kaji/Shinken, OpenWSN, and OpenMotes. This work should be immensely fun and interesting, and also help to materialize the goal of interoperable sensor networking. I look forward to the possibility of participating in the standardization around this work.

RSS Monitoring and SOS CoAP

I have implemented passive monitoring in Shinken of RSS values from an OpenWSN mote. The screenshot below shows RSS received by the single remote node in a two node network. The graph is rendered by Graphite.


The exercise was worthwhile to understand the requirements on both the mote and server sides. On the mote, I reused the RSS data already in the neighbor module. Going forward, the mote side will need some overall structure to manage the data and functions for monitoring its various components.

On the server side, I was able to use the Python-based SOS CoAP library I have been developing to receive the notifications. Also, I was able to copy and adapt Shinken's ws-arbiter module to accept RSS-specific CoAP and write Nagios service check records. As we develop monitoring in Shinken, we need some automation to manage the various notifications across the possibly large number of nodes in a sensor network.

I plan to continue development of the SOS CoAP library to support this monitoring work. I just added a README so others can start to play with it.