Boron + 5-Xenon Setup Questions


The radio is capable of BLE and that is planned for the future, but Mesh runs on 6LoWPAN on the same radio.

Range is highly dependent on the conditions. If someone says the range is “15 feet through walls” do they mean concrete block walls or stone walls or wooden stud walls? Is there lots of interference from other radios? The best advice is that outdoors without obstructions, you can have very long range (there are several posts here about that) but indoors, it depends on lots of factors. The fact that Xenons act as repeaters to extend the range means that adding nodes can improve range.

An aside:

My sit/stand desk at my day job in a typical commercial building has BLE so you can move it up/down for standing or sitting with an app. The app alerts me when I come back to my office to ask if I want to change from standing to sitting or vice-versa. During the day when everyone is here, the range is maybe 15-20 ft. At night, after everyone else has gone home, the range is maybe 40-50 ft. Nothing has physically moved but the amount of interference has gone down and the range has improved.


One further comment from me. I went to the particle spectra 2018 in San Francisco assuming that the xenons were BLE ready. That was the impression I had from reading the PR and advertising for the mesh products. Obviously, I did not read carefully enough.
I read the google post by Brandon Satrom (August 30, 2018) “Get a peek of the new particle mesh hardware:Hands-on with the xenon.” Brandon mentions BLE in reference to the xenons in that post. Brandon’s Bio says he is the Developer Evangelist for Particle. I bought. How long before BLE will be available?


Nope. Currently BLE is only used for setting up new devices via a phone app. Later, a full BLE API will be made available. The Mesh devices communicate using 6LoWpan over 802.15.4 (think Zigbee) using OpenThread. In simpler terms, it is a low power network protocol with Particle’s magic sauce added for security and connectivity.

As for range, these are still early days to get good metrics. 802.15.4 operates at 2.4GHz which is both a busy frequency and, like WiFi, susceptible to signal degradation from building materials, etc. An external antenna connector is available on mesh devices but has not yet been enabled in firmware so much more experimenting will need to be done.

Designing mesh topologies is much more than point-to-point distance. Connection redundancy, number of nodes and other factors must be considered. Again, lots of lessons learned and FAQs will need to be produced through experience.

Again, I stress that this is early days. Particle is working flat out to complete and improve the firmware. Documentation will continue to evolve and so will examples and member-submitted projects. For now, I suggest you DO experiment and engage in this forum with questions, discoveries and anything else! And most of all, have fun :wink:


He makes important points here:

Here’s my general Workflow for laying out a Mesh Project:

  • determine the locations that you can provide continuous power for Mesh Repeaters or Routers. These are the “backbone” of the Network. They provide the data “backhaul” to the Gateway.

  • These 24/7 powered Mesh Routers need to be within range of multiple other Routers to create a fortified Network over your entire Project area’s footprint. Redundancy and overlap are beneficial.

  • Battery Powered End Nodes within the Mesh Coverage footprint will wake up, perform their duties and go back to sleep.

If your project cant have 24/7 powered Mesh Routers to fulfill the required Coverage Area Footprint (and/or you need more range that point-to-point provides), then a synchronized sleeping network of battery operated nodes can be used instead. My guess is that’s the direction the Xenon firmware evolution will take after initial bug squashing, to open up more use-cases.


@Rftop, good stuff! There is no question that Xenon’s will be configurable as repeaters or “sleepy nodes”. This has been made clear by Particle.

One important thing that will need characterizing is latency as a function of the number of nodes and topology. Another will be the partitioning of Cloud functionality on nodes vs gateways - is Cloud traffic best kept (mostly) to the gateways to reduce mesh traffic? Which brings the next question - what is too much mesh traffic (saturation)? What happens to a busy mesh when an OTA to a node is done? All these metrics (and more) will ultimately guide better designs.


Do you know what the data rates are for the Thread Mesh standard that the new boards are using.


@RWB, Thread/Mesh runs at 250Kbps. UDP is used to minimize traffic.


My first application was intended to be simply a point to point BLE connection, Sensor to Xenon, BLE connected to the Boron (Electron replacement). Since our products already use the Electrons successfully, I was hoping that this would be a gateway to adding additional sensors rather quickly. One at first, then others as we became comfortable with the technology.
Since the BLE is used for setup of new devices, is there any information on communicating with it now using BLE and iphones, or other BLE transmitters and receivers? Our product already employs a BLE transmitter/receiver to communicate with a phone app. Maybe we could communicate that way until the mesh icommunication is developed.


@TomEldredge, Particle has committed to developing a BLE API for users and it is high in the punch list. However, device setup and configuration is their primary focus right now. Stay tuned!


Could any of you experienced support engineers take a shot at an estimate on when you think Particle will implement BLE communications? I am trying to consider all options for business purposes.


@TomEldredge, here is the official response from Particle:

Stability and reliability is top priority for the Particle team. Once we are confident in the stability and reliability of Mesh and Cloud connectivity, they will start tackling new features. BLE is on top of that list but there is no ETA at this time.


As @will states in this post, in order to transition customers from the ReadBear Duo, they need to have bluetooth on mesh up and running for end-users. The targets stated were end of Q1 2019.


@ninjatill, the response I posted was directly from @jberi this morning in regards to the timeline.


I just received one of my Particle orders and it has an Argon in it, so I will proceed with trying to do things with these products with the Argon instead of the Boron, because my home office does not have cell reception.
Are there any issues I need to be aware of concerning this change?

My three xenons seem to spend a lot of time flashing green rather than breathing cyan. They will stay breathing cyan a while then drop back to flashing green. I am wondering why they drop out from cloud connection. Also, one xenon often blinks red.


Understood. I know those targets are an estimate if anything… and if it goes anything like the pre-order timeline, it will shift “to the right” a bit.


I have not had good success with the Xenon stability with more than one Xenon endpoint on the mesh. I have 2 mesh networks; the one at home is 1 Argon with 1 Xenon, the one at work is 1 Argon with 4 Xenon. I have had both networks running the “Marco Polo” code since I unboxed them. The one at work is running with SYSTEM_THREAD(ENABLED).

The mesh at home is very stable. Never misses a beat. Most of the time latency for a round trip MarcoPolo is in the teens and well below 30ms. Occasionally, latency spikes in the 100ms range. Not sure why but I suspect RF noise. Here is the stability chart for the last 6 hours. Look like latency is fairly low and only 1 response missed that whole time:

The mesh at work is another animal. Even with all the Xenon endpoints in the same room, I cannot get it to reliably respond to every MarcoPolo. The latency almost always is in the 100-200ms range and it’s usually receiving 3 out of the 4 mesh node responses. For the last 24 hours, there has not been a 5 minute period where all 4 responses were received on every Marco. And as I’m typing this, I see that my mesh connection dropped at about 10:33 this morning and I just had to reset the Argon to get it reporting again.


If you have ruled out the Xenon router allergy then maybe you have an unlucky/bad hardware or interference.

I get 99.9% with 1 argon gateway, 3 xenon.

@TomEldredge did you try hooking your gateway (argon or whatever) to an old router - there are ip6 and dns issues with new routers AND multiple dns entries in router.

I believe Particle knows but we haven’t a fix yet.


They have a fix for many of the IPv6/DHCP/DNS issues but it’s not published yet.
But I know that rc.26 has resolved my immediate issues with Argon & Xenon and so should be others.


@gusgonnet Where ya at? Your new stuff arrive?


My new workaround is eliminating 3 DNS entries in my router (going down to two (or less)).
and disabling ip6

after that all is good with my linksys wrt1900ac router.

again, nothing wrong with the router - there is just a particle problem with mesh xenon’s connecting through a gateway with EITHER OF ip6 OR 3+ DNS entries.