Xenon only Mesh Experiment with BUG and Caveat


How to create a Xenon only mesh (unfortunately the caveat is an Argon or Boron is required to set it up)

Items needed
1) Argon or Boron(not tested)
2) Two Xenons

CAUTION Once you program your Xenons with the following code you won’t be able to OTA flash without putting them in safe mode. I don’t recommend doing this if you don’t know what OTA means or have never worked with Particle devices before. You won’t hurt your devices but you might find yourself confused, lost, or frustrated, and that is not what we want to do here.

That being said here goes…

Setup a network of the three devices, as a starting point probably running Tinker is best.
Once you have all three breathing cyan do the following

Flash one of your Xenons with this code


bool beat = FALSE;
unsigned long beatTimer = millis();
char pub[10];

void setup() {

    while(!Mesh.ready()) {
	pinMode(D7, OUTPUT);

void loop() {

	if (millis() - beatTimer >= 1000) {
	    beatTimer = millis();
	    beat = !beat;
	    digitalWrite(D7, beat);
	    snprintf(pub, sizeof(pub), "%d\n", beat);
	    Mesh.publish("Heartbeat", pub);

When it restarts it will breath green, that’s correct, breathing green, it is not connected to the particle cloud. It will also be flashing it’s blue LED.

Flash the second Xenon with this code


bool beat = FALSE;

void myHandler(const char *event, const char *data)
  beat = atoi(data);
  digitalWrite(D7, beat);

void setup() {
    while (!Mesh.ready()) {
    pinMode(D7, OUTPUT);
    Mesh.subscribe("Heartbeat", myHandler);

void loop() {

When this Xenon restarts it will also be breathing green and flashing it’s blue LED because it is listening to the published event of the first Xenon

When you have this working, pull the power from the Argon or Boron(not tested).

The Xenons however are still flashing their blue LED.

This is where the BUG shows up. After roughly 5 minutes both Xenons start to rapidly flash their green LEDs as if trying to connect to the Particle Cloud. They have not been told to do so by Particle.connect().

However the mesh network continues to function as the blue LEDs continue flashing.

What happens if you unplug one of the Xenons and plug it back in? The mesh reconnects and the blue LEDs start to flash again. Take your Xenons to another room and plug them in and boom, they reconnect and start flashing the blue LED.

If you can live with the rapid flashing green for now until we get newer firmware then you have yourself a Xenon only network.

I have tried a call to Particle.disconnect() in the publishing loop but it has no effect on the flashing green.

To change the firmware on these you need to plug the Argon or Boron back in and put the Xenon in safe mode to OTA flash.



Curious… if you re-purpose the Argon onto a new mesh, does the old mesh still show up in your console.particle.io? Not that I’m looking for a way around particle’s billing but that could be a hole. How many people will really create a mesh network that they can never update?.. Except maybe by serial flashing only?!?


A more common use case is a mesh network that’s intermittently connected. For example, you could connect the Argon via your phone hotspot to do updates, but it would be isolated and communicate between the Xenon mesh devices when the Internet is down.

That mostly works now (except for the incessant blinking) but is something that should work.


There are a number of cases where a Xenon mesh would be useful. Out in the wilderness or the backwoods of British Columbia (BC) Canada we do indeed not have WiFi or cellular coverage. This would allow a mesh of sensors to report back to a single Xenon that records data on an SD card for example. The quick connect time is also a great battery saver for solar powered devices.

I haven’t tried it yet but turning the WiFi radio off on an Argon could also save a lot of power and allow it to collect data purely on the mesh. Something for me to try tonight.

That way one doesn’t have to climb all over a mountainside with no connectivity to collect data from many sensors.


I’ve also found that when the Xenons are not connected to the cloud they are far more stable with the current firmware. Publishing this way to an Argon using Mesh.publish and having the Argon convert to a Particle.publish results in a lot less flashing cyan with intermittent red blinks.

Intermittent but recurrent Xenon mesh connectivity issues

The cloud connection from Xenons, in particular through an Argon gateway, is much more stable in 0.8.0-rc.26. It should be out this week.


Back in the office this morning my 2 Xenon mesh was down. Both were rapidly flashing green but no blinking blue on either the publisher or the receiver.

Luckily I thought for a minute instead of instinctively pushing reset on both of them. Are they both locked up? Is it possible to figure out which one is locked? How?

Without touching the Xenons I plugged in the Argon and the publisher Xenon starting flashing the blue light again as the Argon provided the second node to form the mesh. So the receiver Xenon was locked up. I’m not sure if my coding is to blame, not using much out of the ordinary except maybe atoi, or is something related to the flashing green eating up memory.

I’m sure people with better tools than I can figure it out. :slight_smile:

I’m looking forward to 0.8.0-rc.26.

@rickkas7, just thought I’d ask, is there a hardcoded limit to the number of publishes per second? Our current product uses the 802.15.4 protocol (Zigbee stack but not Zigbee compatible) with on average a few hundred devices per facility, at the extreme end just over 5000 devices. Our message load varies but technically we would need a maximum throughput of 50 messages per second carrying 30 bytes of data.


0.8.0-rc.26 appears to be much more stable, especially when the gateway is an Argon.

There is no rate limiting on the Mesh.publish, it’s limited by the speed of the mesh network, but I don’t have any numbers for what that might be. It also depends on the number of hops between nodes.


@Jseiler, large meshes will require careful planning of repeaters and nodes (non-repeating). The mesh topology will play a big role. When you say:

Is that the throughput at any node or at the gateway? If it is at the node then I don’t believe Particle Mesh is going to achieve that for the size mesh you are planning.


@peekay123, No, that is the throughput for the entire system.

Our end devices are excessively sleepy and only publish a twice daily system status update, any other transmissions are only to notify there is an issue, help request, temp out of range, low battery, door stuck open, water detected, sort of thing. Our 5000 device installation is broken down into 5 sections and data aggregated via Ethernet from there. Some of our devices are wandering, they need to be able to connect in any of the 5 sections, so the mesh would be the same in each section. Our end devices are extremely sleepy and power efficient drawing only 1.2uA - 2.3uA in sleep mode, these are based on the TI CC2530 chip.


If an Argon is moved to a new mesh, the old mesh remains until all of its Xenons have been removed from it.


And as I have already discovered, you won’t be able to add the Argon back in once you’ve removed it.


You don’t move Argons/Borons/Xenon+Ethernet since they are gateways. You move Xenons. They can act as both repeaters and sleepy nodes. An ideal scenario would be to have Argons or Xenon/Argon+Ethernet as mesh bridges (vs gateways) to connect mesh segments into a larger mesh. Again, ideally, in a High Availability mesh, you would have multiple gateways, possibly one per mesh segment. Still lots to do :wink:


I agree, but, excuse the dramatic, if you hit the Argon with a hammer, you need to be able to replace it without tearing the whole mesh down.

Not poking anyone in the eye here. This is open source hardware and as such all of us particle fans are part of the development team. Like i’ve said elsewhere it will only get better but as a first kick at the can I’m loving it :+1: Way to go Particle!


@Jseiler, totally agree on the Argon replacement AND on the kick at the can! :rocket: