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:
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.
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.
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:
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!)
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.
" 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. "
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:
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.
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
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.
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.