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).
@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
I seem to be able to install nrf tools onto windows.
Just found this tutorial
Now installing windows https://www.nordicsemi.com/Software-and-Tools/Development-Tools/nRF-Connect-for-desktop
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)
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…
https://openlabs.co/OSHW/Raspberry-Pi-802.15.4-radio $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 (https://openthread.io/platforms/) 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 http://po-util.com 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.
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…
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 https://forum.mysensors.org/topic/9717/everything-nrf52840/192
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.
all the bt840 appear to have the same icid. what you refer to as serial number i think.
Things are going well. I just need to get these Fanstels working or wait for the other types of Dongles to arrive. Looks like I should look at the Documentation:
Here is the link for Nordic SDK 15.2.0
And here is the link for its’s Documentation.
which on closer inspection is not what I need. Looks like this is more relevant.
with a thread sdk download here
What is a bit confusing is that Nordic uses the term MESH for their own Bluetooth 5 protocol, whereas Thread stands for OpenThread protocol which the Particle Devices are based on.
This is interesting? From this site https://www.threadgroup.org/support#specifications
Is An End-Product Based On OpenThread Automatically Thread-Certified?
No. If a company uses OpenThread to build a product, they need to be a member of the Thread Group in order to gain the Intellectual Property (IP) rights to ship Thread products and to complete product certification, which ensures that products using Thread work together effortlessly and securely right out of the box.
That last line is best part, I wonder if any of the development devices work effortlessly and securely right out of the box.
Strange that it is Open Source and Intellectual Property all at the same time, probably best to read the small print. This link shows the OpenThread license.
Would this mean that if you sold a product built with Particle Mesh you’d have to get it OpenThread certified?
Probably a good idea to put this in it’s own topic. Stuff like that this me glad I am a teacher and don’t have a startup.
Anyone know how much it costs to be a member of the thread group and to certify an OpenThread product?
There are multiple levels and it’s not cheap:
the bsd-3 license they use is the standard one.
the 3rd clause means that you can not use the names to endorse the product which i think in this case means certified. the way i interpret it is feel free to use the code but include the copyright. at the same time do not label the product a certified or endorsed by the copyright holders which in this case are the OpenThread authors unless you have their permission which probably would mean having to join the group. my guess is as long as the product does not say certified OpenThread or use any of the authors/group names but otherwise works it would be ok. thing is marketing it that way would limit traction in the marketplace. the copyright holders are ok with you using the code they just don’t want you mucking up their good name by marketing it as endorsed/certified unless you go through their process. that’s my opinion based on previous bsd license experience but not openthread. also, i’m not an IP lawyer.
This is getting off topic but, Particle is a certified Thread Product (I think) but it looks like I am the only one working on getting the Particle devices to work with other Thread devices which I think is the tone of the statement below.
I guess at some point Particle will have to activate OpenThread connection protocols to be compliant with their OpenThread certification.
To get back on topic. It looks like the Fanstel Dongles have a product download at
which would have been very helpful if I had found that 2 weeks ago.