Using Particle Mesh Devices with the OpenThread Border Router


Here is a list of all the openthread platforms from their github: and the information here


I wonder how many cell phone apps have access to OpenThread and how many of the above platforms have USB dongles. Theoretically eventually all these platforms should be able to communicate.

I think along with @peekay123, who got the Nordic dongle, I need an early xmas present of a few dongles to try.

searching on the above information got this nice information page and long range part 2


@rocksetta, no cell phone has access to OpenThread as none have hardware that supports 802.15.4 used by OpenThread. Thus the need for the dongle and a PC.


As far as I know the PC must be a linux (or Mac). I believe the border router uses the cell phone to connect the hardware much like the particle system does.


When getting sensors working for the Photon I typically purchase 3 of the same type of sensor (say an accelerometer) but from different companies and I only tend to get one fully working, not sure if I give up on the others or if the other sensors don’t actually work with the Photon. So now I am looking to purchase 5 USB dongles to see what I can get going on a Linux box or the RPI3.

It looks like an openThread network can handle lots of border routers so I think I will get:

2 x $10 NRF 52840 Nordic USB dongles, so I can understand whatever @peekay123 gets working.

1 x $16 Seedstudio nRF52840 MDK Dongle

1 x $25 XBee Explorer USB Dongle

Can anyone make a suggestion for one more dev kit to try or if I am making any mistakes with the above purchases. I have found a few USB production ready OpenThread sticks but they are getting expensive.

kirale $49

em358 $??

ETRX358 USB Stick (not recommended for new designs ?? ) $??

Firefly about $53 USD if the Euro is really doing badly

The more I research the more I like the nordic usb dongle. Anyone know of any others?

High School Robotics Course using the Mesh Devices Blog

Found some nice OpenThread tutorials…


I posted this on the Google Groups Openthread-users

So I ordered:

3 x NRF 52840 Nordic USB dongles

3 x Seedstudio nRF52840 MDK Dongle

3 x Fanstel USB840F

I think it might be a big waste of money.


As mentioned here my Fanstel USB Dongles arrived, the other 2 types are on backorder.

I seem to be able to activate the OpenThread Border Router Docker on my Ubuntu laptop, but I am really confused about how to update software on the Dongles. I think it should be fairly easy with the USB connection and all, but finding simple working examples is not very easy. What makes things even more confusing is the terminology. Some pages talk about bluetooth 5, others Thread and others OpenThread. Most examples are for Dev boards and not for the Dongles.

Absolutely no information came with the Fanstel Dongles and I don’t even see a button of any kind on the USB stick. (There is however a Phillips screw that is just begging to be unscrewed.)

If anyone has worked with these or has any suggestions for sending programs to them I am all ears.
I know the firmware image is here and JLINK is supposed to be useful but I don’t even know how to install JLINK

I just like making bash files of all the installation commands and then never having to think about that stuff ever again.

@peekay123 did you get your Nordic Dongles yet?


I come from a hardware hacking background before I became a networker… I see that phillips screw head, and wonder if there are pushbuttons inside the case, and maybe a debug header… and you have three of them (you could open one,and still have two). :slight_smile:


@rocksetta, I only ordered the “sniffing” dongle which, in theory, should be able to sniff the OpenThread traffic only.

I personally would not have purchased anything NOT Nordic for testing only because they are so poorly supported. One thing I did notice re the Fanstel:

Bootloader is preloaded in Bluetooth module. SoftDevice and application can be loaded by Over-The-Air firmware update. A TAG connect cable TC2050-IDC-NL-050-ALL can be used to connect to nRF52DK to load bootloader and other codes.

You would most likely need the Nordic USB dongle to program the Fanstel dongles OTA though I have not looked into the documentation to know how. I believe Fanstel used “Thread” to mean OpenThread. Take a look at the Nordic dongle information:

I believe the dongle allows you to connect to a mesh of nRF52840 DK dev kits and use their tools to OTA, get mesh information, etc.


You might be right, that would explain some of my issues. Heres what I have so far:

I can’t mount the USB Dongle on Linux using a typical USB mount command like

sudo mkdir /mnt/mydongle

sudo mount /dev/ttyACM0 /mnt/myudongle

Gives a block error saying it can’t be found.

I have installed JLINK
on Ubuntu by using these steps:

sudo apt install gdebi-core

sudo gdebi JLink_Linux_x86_64.deb

I think JLINK should be enough to install the NCP image onto the USB Dongle but the instructions seem to think you need the Nordic nrf command line tools which have been deprecated. (That is a bit concerning that NordicSemiconductors has deprecated there NRF tools!)

Strangely they do seem active on a NodeJS github called pc-nrfjprog-js that mimics the nrf tools.

I am going to research if JLINK is enough to transfer the Image to the Dongle, and perhaps see if I can use node to transfer the hex file to the Dongle.

LOOKS LIKE WINDOWS TO THE RESCUE FOR LINUX. How many times do you get to say that :laughing:

I seem to be able to install nrf tools onto windows.

Just found this tutorial

Now installing windows

OK. Strangely easy. Not even sure what I have done, but dropped my NCP .hex file into the USB Dongle. Will now have to test it with the border router.


So after much head banging against the computer I think the latest problem is that the Fanstel USB Dongles use a secure DFU bootloader instead of just a regular DFU bootloader, which means everything needs to be signed to be installed.

What I thought was successful on the windows machine eventually was exactly the same on Ubuntu. nrf-Connect for desktop can find the USB Dongle and can find the .hex file to load, but will not allow activation of the write ability to move the hex file to the Dongle. I think the problem is the secure part. I have to somehow sign both the bootloader and the application.

I did have a few small successes:

I got the docker OpenThread Border Router web gui working. I originally thought it did not work but was not including the :8080 in the URL. What worked was:

This shows the FORM tab which makes your thread network. Since my Dongle does not work, this part can’t setup the network, hopefully this part will be easy when my other Dongles arrive.

I think once the Thread Network is created, I then use the Thread Commissioning App to add other devices.

I found out today that when installing Ubuntu applications for the desktop, the ones you don’t use a command line but just click on. You have to use:

chmod a+x filename.ext

before clicking on it. (This is standard behavior for running command line apps,I just never thought about needing to use it to run desktop apps)

I also found out that


to paste HTML text is very different from


which pastes plain text (not sure why it took so many years to find that out) :grin:

Using mesh without cloud?

After reading the OpenThread articles, I followed a link to OpenLabs for an RPi mesh radio module. I ordered two. Now that I have them, I spotted that I have RPi Model 2, not 3… $10(US) each.

" The module comprises a chip antenna, crystal oscillator, and an Atmel AT86RF233, which is a 2.4GHz SPI-to-antenna transceiver IC with 802.15.4 hardware assist. This is therefore an SPI-to-airwaves 802.15.4 solution.

The header pins are matched to pins 15-26 of the RPi P1 header, but this design is otherwise not RPi-specific. It would not be wrong to call this a simple AT86RF233 breakout board with an antenna and crystal. "

So, the AT86RF233 chip isn’t listed as a supported platform for OTBR ( but it may be useful to try to read it with SPI…


I have been using ubuntu laptops instead of my RPI3 anyway. Got any old windows laptops lying around?

My Ubuntu desktop running 18.04 works fine with the border router and nrf-connect-for-desktop , but I have been trying older 32 bit laptops which need ubuntu 16.04 LTS.

I have just caused myself a ton of headaches by forgetting to use the software updater once I installed 16.04. (I am my own worst enemy). Have just installed the updates so will try again with border routers.

By the way I am having huge success with po-util for loading OpenThread C code onto the Argon and Xenon, see thread here: (Everyone should try as an option for both local building and OTA over the air. It is a very easy to use and powerful combination of tools. I have it setup on the cloud then download my firmware.bin file to the computer and use DFU to install the code. Nice thing with DFU is it tells you if it worked or not. OTA is a bit of guesswork if it ever installed.)

I now have access to openThread RSSI and can start doing some fancy antenna testing, however I want to get these OpenThread functions working so I can connect the particle to the OpenThread Border Router or set the Particle Devices to use the regular OpenThread settings…

To retrieve the Particle device Thread Network configuration, you can use:

otDatasetGetActive() to retrieve all the parameters in one structure, or:


to retrieve them individually.

With the configuration information in hand, try the following commands on OTBR:

$ wpanctl leave
$ wpanctl join -T r -p panid -c channel -k masterkey -n networkname

I find the OpenThread API a bit confusing, I work best with example programs but not finding many of those. Any ideas about what the above methods return. Not sure if they return strings, integers or some special object. The first one (otDatasetGetActive() ) obviously returns an object but presently not sure how to get the data from that object.


Finding out some interesting stuff about RSSI values

RSSI typically has significant variance, depending on the environment. To help avoid unstable links, OpenThread implements a 10dB hysteresis on forming new links. In other words, the link margin or signal-to-noise ratio (SNR) needs to be at least 10 dB before a new link can be stablished.

If your Particle device is a Thread Router capable device, then the “disconnect/reconnect” is really demonstrating Thread’s partitioning and merging process. When the device moves too far away from the neighboring router, it eventually looses connectivity and forms its own Thread partition. When the device moves closer and regains connectivity, they merge back into a single Thread partition.

The first step in merging partitions is discovering each other. This is done through periodic MLE Advertisement messages, which are sent about every 32 seconds normally. Depending on how fast you’re moving, the RSSI may continue to increase above the threshold before the devices discover each other again.

Just joined the Nordic devzone to see if I can get any answers


Oh, wow, that explains the behavior that others have noted when doing range tests! Thanks for sharing this tidbit.


Presently trying to find out if it is dynamic. Since the devices can still talk mesh.publish still works, when a Xenon has become disconnected it would be great to be able to reduce this amount on demand when trying to re-connect a device that has lost its connection.

Or reduce this amount on startup to help connect a few distant Xenons. My problem is finding example code from OpenThread. API’s are great, but I work best with working examples that I can then alter.

Hey @dougal

update Jan 14, 2019:

From the openThread-users google group. info from Jonathon Hui.

The link margin threshold is OpenThread-specific and build-time configurable using OPENTHREAD_CONFIG_MLE_LINK_REQUEST_MARGIN_MIN.

The maximum MLE Advertisement period (32 seconds0 is specified in the Thread Specification and, as such, is hardcoded. However, if you want to play with changing it, see Mle::kAdvertiseIntervalMax.

So unfortunately both of these are hardcoded and not dynamic. However I guess a user request could be sent to openThread about making both of these dynamic for special situations.


So since my other dongles are on backorder and the Fanstels need secure firmware which I haven’t found out how to do, I thought I would open one.

Couple of things to note: These are labelled BT840F not USB840F like I have been searching for and finding almost nothing about. Also the serial numbers do not look long enough to be individual. Kind of want to open another Dongle to see if the numbers are different.

On the other side is the 2 buttons I might need, if this thing does not go into DFU mode. So that issue is solved, thanks for the suggestions to open it up @Zonker

I think nrf-Connect for Desktop can automatically put the device into DFU mode so that is probably why these Dongles are sealed up.

My seeedstudio dongles are supposed to ship late January. Hopefully as @peekay123 thinks, they are pre-installed with the OpenThread Border Router connection firmware.


Now you know where the buttons are… get out a dremel, and your micrometer, and make a couple extra holes in the cases… :slight_smile:


do a google on 4100a-bt840 and select images. that appears to be a generic identifier.


Not actually finding anything of use googling 4100a-bt840, what is the 4100a?

I often search for nrf52840 and PCA100059 or PCA100056

I did just find this
which at least has lots of entries.

I also have the Nordic SDK samples which seems to have encryption samples, but I am not sure how to load them or which ones to use.