Thread is an IPv6-based, low-power mesh networking technology for IoT products, intended to be secure and future-proof. It is gaining popularity in the IoT space with chips from NXP, Nordic, and others. The newest generation of development boards from Particle use the Thread protocol for communication. The Thread Specification is attached.
Vendors can choose to create their own software libraries, but OpenThread provides an open source implementation of the protocol. OpenThread works on many processors and has surprisingly good documentation. This article is a good overview of OpenThread. This document explains all the commands available in the CLI.
HardwareThe NXP Rapid IoT Prototyping Kit is a comprehensive development kit that is capable of communicating over the Thread protocol. The User Guide is attached. There is an online IDE available called Rapid IoT Studio. It is GUI-based but code is available behind the scenes. The only available Thread code is made by an external product engineering company and was designed to communicate with their $450 gateway. These details alone make it very difficult to use the NXP Rapid IoT Prototyping Kit for Thread Development out of the box. Fortunately, the device contains a KW41Z processor which is compatible with OpenThread. To ease programming this device outside of the recommend IDE, a docking station is available which also supports additional click boards.
Particle Mesh devices use a Nordic Semiconductor nRF52840 to facilitate Thread communication. The Xenon device (datasheet here or schematic attached) exclusively communicates over Thread and only has a nRF processor (their other Mesh boards have coprocessors for WiFi or cellular). Particle Mesh devices have a JTAG header on board and there's a programmer available to debug them. This OCD and telnet solution seems to be the only method that works to program this generation of chips (this whole thread explains how to debug on the Xenon but it never worked for me).
These nRF52840 devices split their memory into a few sections with separate purposes. Particle's Xenon memory map is explained here. The Bootloader is used to start the device or update other sections. The SoftDevice is the library for communicating over the wireless protocol (here is the specific documentation for the Bluetooth variant). The User Application is the code you write (you can think of it as a program running on an operating system). The System is Particle-specific and contains the code to talk with their ecosystem. Particle exposes some of the mesh networking functions through their Device OS API.
There's a few other companies that make development boards with the nRF52840. Sparkfun has one and it has some excellent documentation on how to write code for it. There's an official Nordic nRF52840 Dongle (P/N PCA10059) which is also a popular choice but it is hard to find and often cloned (one such clone is the nRF52840 MDK USB Dongle ).
SoftwareIn addition to the official libraries from the manufacturers, some other companies make software that supports the Thread protocol. OpenThread supports the nRF52840 (processor-specific example). Mbed has an example for mesh networking including Thread. Platformio has specific documentation for the various parts:
- Freescale Kinetis FRDM-K64F (main NXP IoT Kit processor)
- Freescale Kinetis FRDM-KW41Z (coprocessor on NXP IoT Kit processor to support wireless comms)
- Hexiwear (similar product to the NXP IoT Kit)
- Nordic nRF52840-DK (used on Particle and other dev boards)
The above resources were found as I was trying to design a project where the NXP Rapid IoT Prototyping Kit could communicate to a Particle Xenon over the Thread protocol. Both of these devices support Thread but have chips from different manufacturers and different software stacks so it is not straightforward to communicate between them. To accomplish this project, I broke it down into smaller tasks to try and narrow down the problems into management chunks.
My first step was to reprogram the Particle Xenon. Particle uses OpenThread behind the scenes but it seems that enough has been modified that it's not completely compatible. Using the knowledge I shared above, I tried to program the Xenon's application section with my own code, but I never got this working. I spent a considerable time on this task, so my failure here is why I never finished this project. Since I wasn't using the Xenon with Particle's services, it didn't seem fair to ask questions on their forum, although I think the experts at Particle may be the only people that could help me. My best bet here is completely erasing the data from the chip and starting from scratch, but I didn't want to brick my device if something went wrong.
If I were to erase it all and start fresh, I think I can use this OpenThread example code for the nRF52840 with some modifications. I would need to remove hardware flow control because those pins are used for something else on the xenon. It looks like I can change UART_HWFC_ENABLED to 0 in platform-config.h to accomplish that. The UART's TX and RX pins come out to the header on the corner of the board. It uses the typical UART configuration of 115200 baud, 8 data bits, 1 stop bit, no parity. It looks like this person has a similar idea to me, but the lack of code makes it seem like they are also having issues.
An alternative to reprogramming the Xenon is to use the nRF52840 Dongle since it has specific instructions in the OpenThread documentation.
After I can program OpenThead on the Xenon, I can establish Xenon to Xenon communication over Thread. Following this, I can program OpenThread onto the NXP IoT Kit's KW41Z wireless processor. Since only this one processor is running OpenThead, I should still be able to use Rapid IoT Studio to program the other processor and reuse their drivers and example code.
Even if I could get that far, my solution is so far removed from Particle's default configuration that I wouldn't be able to talk with other devices on their system, which makes all this work to communicate with the NXP IoT Kit an exercise in futility.
All this goes to say that I think Thread is an exciting protocol for networking IoT devices, but the differences in libraries makes it difficult for a hobbyist to use it on a simple project. I'm hoping with time, that all manufacturers settle on the OpenThread libraries and it becomes as easy to use as microcontrollers with Arduino or WiFi with Espressif's ESP devices. Until then, stay away from hacking it yourself and let the big companies handle the hard part for you.
Comments