Mesh Hello World

Try this code when you finally get your Mesh Argon working with a few Xenons. Just change the number for each Mesh Device. I use 1 for the Argon and comment out the particle.publish line for the Xenons.

IMPORTANT: This code has been updated to make the Particle Featherwing Plug and Play

Also now includes an Antenna for both the Xenon and the Argon

See High School Robotics Course using the Mesh Devices Blog for distance testing.

// next 2 lines are for plug and play particle featherwing

/////////////////////////// important globals here ///////////////////////////////

int  myCode = 3;  // different number for each device
bool myXenonAntennaAttached = false;  
bool myArgonBothAntennaAttached = false;  
bool myPublishToConsole = false;        // set true for Argon or debugging

/////////////////////////////// end globals ////////////////////////////

void setup() {
   pinMode(D7, OUTPUT);
   Mesh.subscribe("mySendToAll", myHandler);
   if (myXenonAntennaAttached){
	       digitalWrite(ANTSW1, 0);
	       digitalWrite(ANTSW2, 1);
    if (myArgonBothAntennaAttached){
	       digitalWrite(ANTSW1, 1);
	       digitalWrite(ANTSW2, 0);

void loop() {
    Mesh.publish("mySendToAll", String(myCode));
    for (int myLoop = 0; myLoop < myCode; myLoop++){ 
       digitalWrite(D7, HIGH);
       delay(200);   // very quick flash
       digitalWrite(D7, LOW);
    delay(30000);   // mesh publish every 30 seconds

// Event listener for "mySendToAll" event from Xenons
void myHandler(const char *event, const char *data) {

    String parse = data;  //Cast char*data to String class
    int myNumber = parse.toInt();
    if (myPublishToConsole){  // mainly for Argon gateway unless debugging
        Particle.publish("Talked to device number:", parse); 
    for (int myLoop = 0; myLoop < myNumber; myLoop++){
       digitalWrite(D7, HIGH);
       delay(200);   // very quick flash
       digitalWrite(D7, LOW);

The code is kind of fun. Remember to flash the Xenons before you flash the Argon and pull the Argons plug and replug it in before testing everything. I flash the xenons when only one is connected to the Argon.
Also be aware that the gold star determines which Xenon gets flashed, not sure how many times I have messed that up and flashed the wrong code to the wrong Xenon.

If you uncommented the particle.publish for the Argon you can use the console to monitor the connections. You can uncomment the Particle.publish for each Xenon but that is a lot of traffic.

What does it do:

It is a 30 second cycle.When the Argon flashes once, all the other devices flash once. The first Xenon flashes twice all the other Xenons flash twice. If they overlap, then reset one Xenon until they have a space between flashes. When you walk away with Xenon #2 it will always flash twice, but it should also flash once for the Argon and 3 or 4 times for the other Xenons.

Note: Disconnect the Argon and the local mesh still works. Very Cool. Reset a Xenon and it reconnects without the Argon. Pull the plug on a xenon and everything dies, can’t reset to the other Xenons. Re plug in the Argon and everything is fine again.

My blog is at High School Robotics Course using the Mesh Devices Blog

I am still waiting for the ability to connect multiple Argons to a mesh.

Note: Working with a mesh is a bit more complex than using a single Photon. With the mesh you need to make sure the correct device gets the correct code. For the Mesh Hello World program you must make sure the devices have a different myCode number so that when they flash the D7 LED your know which device is talking.

Do not set the antenna true unless you have an antenna attached.

Example of a Xenon with an antenna attached

Example of an Argon with both antenna attached and console data published.

An Argon with both antennas and a Xenon with a mesh antenna. I got this result 230 m. May have done better if the buildings weren’t near

And after losing connection they returned but reconnected at 120 m


Mind telling us what we’re supposed to see/expect (for those who can’t interpret the code quite yet)?

1 Like


With 3 Xenons my Students got 75 meters away from the Argon, inside the school. Each Xenon about 25 meters apart.

Should be able to get much more distance apart when everything is outside.

1 Like

Rickkas provide some code below that allows you to plug in a Argon antenna to the BT Ufl connector on the Xenon if you want to try the range with and without a antenna attached.

1 Like

I will not be trying the Antenna's on the Xenons, since my Argons need every antenna I own and at least with the Photon I found the antennas did not remove well. Once you attach an Antenna leave it on. I broke the attachment pad on my Photon trying to remove an antenna. (Photon still worked just can't use an antenna again) I thought that was my random bad luck so I tried on two more photons and broke them as well :laughing::laughing::laughing:

I’ve never had any issue adding and removing the Ufl antennas numerous times but I have heard they are only designed for a few connections.

My problem with the code above is that I can set everything to blink at different times (start with the higher number Xenon and connect the other ones), but if any Xenon does a reset then the timing can gets all messed up.

The positive is that if a device does any set of blinking other than the devices own number then it is connected to at least one other mesh device.

I guess it is possible for the mesh to split into 2 unconnected meshes. Think I will test that out.

So you can definitely separate a mesh into 2 local meshes that work but don’t talk to each other. That is part of why I really want multiple Argons to be able to be setup to give a mesh some redundancy.

Having at least 2 neighbours is what makes a mesh redundant. If you have two "local" meshes then you don't have true mesh. You have two unconnected mesh segments. This is the purpose of repeaters in a mesh. Their only purpose is to bridge mesh segments.

However, the use of redundant gateways at different "ends" of a mesh certainly adds internet/cloud redundancy.

I agree @peekay123, what I am saying is that if a repeater dies, how do you know that your local mesh is still one mesh or two separate meshes.

P.S. I am just trying politely to get Particle to quickly allow multiple Argons added to a mesh :grinning:


Thought as much, though I don't think it quite works that way. Particle is very much aware of the need and desire for HA networks, so there's little to add to that. Stability and reliability are at the forefront of priorities right now. Only after those are satisfactory will new features be added.

My Xenons at school are stable and reliable (They don't work at all at home) I don't think multiple Argons are a new feature. I think people are purchasing Argons expecting it as per the docs:

Here is a quote from the FAQ section of the original preorder page.

For mesh deployments, Particle will charge product creators an additional monthly fee in addition to our baseline Device Cloud pricing for Argon and Boron devices acting as gateways within a Particle Mesh network. All Particle customers will get 10 free gateway upgrades for prototyping and evaluating Particle Mesh. All local communications between mesh endpoints are free.

With 10 free gateways, you could build:

One giant network of 100+ devices
Ten different networks of 10+ devices
Five different networks with redundant gateways (Ethernet + Cellular backup, for example)

1 Like

I'm well aware of that quote, after seeing it multiple times now :wink:
That doesn't change the fact that reliability and stability should have priority, as you yourself point out:

What good is a multi-gateway network when it doesn't work?

As for the quote:

For mesh deployments, Particle will charge product creators

Currently, Mesh devices aren't supported under products in the console quite yet, nor are there any HA available. As such, there shouldn't really be any deployments other than prototyping as of yet, if you ask me. As a product creator I wouldn't want to deploy something that isn't stable/reliable yet. No amount of additional gateways is going to make a difference there.

Mind you, I'm not saying this shouldn't become available (preferably soon), I'm just saying that other things have priority -rightfully so- and quoting those docs/pushing might not have as much effect as you hope at this point. Trust me when I say Particle is very much aware of the desires regarding this, but has to deal with stability/reliability first.

(Excuse me in advance for the possibly dumb analogy, first thing to come to mind.)
"According to biology and the fact that babies have legs, they should be able to walk. However, I'd very much prefer it if they start breathing first." In the greater scheme of things, both are essential parts of a system, but one is a pre-requisite for the other if it is to function at all. As such it has to take priority, even though it doesn't seem as exciting.


I think this is very large new feature. In the past, every device that published an event could only get to the cloud one way, so device events and cloud events were always one-to-one (and onto in the mathematical sense). Similarly subscribed events could only go to one device.

With multiple gateways, a single Xenon event would have more that one way to get to the cloud. Should the gateways talk among themselves to see who should sent an event? Or should the cloud expect two or more events and somehow identify and ignore the duplicates? Should there be a primary gateway and then the secondary gateway subscribes to its events and if it gets a mesh publish but doesn't see a cloud publish in a timely fashion it publishes the event itself? If duplicates are sent (which seems likely), which timestamp should be used? Which return path for a subscribe?

I think there are a lot details to get right and I think learning to breath before learning to walk is a good analogy.


Thanks @Moors7and @bko for the reminders and the analogy.

So today I made an important discovery. Hopefully this will change as things get more stable.

  1. I setup my gateway
  2. I took 2 Xenons for a walk about 20 m from the gateway.
  3. I plugged a 4th Xenon into an outlet and waited to see if it could get connectivity from the 2 Xenons 20 m away from the gateway. It could not. So presently All Xenons must, on power up be close enough to the gateway to get their connectivity. They can not get their connectivity from a another Xenon.)

Similar to issues with powering down a gateway. The Xenons can keep a local mesh going, they can even reconnect after a reset, but they can’t reconnect after a full unplug and plug back in.

I love analogies/stories let me try one:

2 Hipsters, strangely both called Sack, start a cool mattress company called Particle Beds that sparks everyone’s imagination with their core product. Their success leads them to make the even superior Futon that is amazing, best sleep ever, but the 2 Hipsters have worked really hard and haven’t yet reached their financial goals. So they begin a great new concept in sleep technology called the Mesh, made from the materials Steal, Boron, Silicon, Argon and Xenon.

This product is going to revolutionize sleep, by interconnecting the entire family’s sleep patterns. So the Hipsters aggressively monetize the Mesh, blocking out their roots, the developers, before it has lived up to the hype.

They ship the product before getting everything well tested, assuming their community will work tirelessly for free to help them solve all the issues, but the software issues of connectivity, security and now monetization prove very complex.

The 2 Sacks begin to realize that their loving community is very fickle and likely to hop into the next warm bed, such as a new product looming in the future called Free GoogleMattress.

Even worse, accurate but negative reviews on Social Media about the product, start going viral, creating a firestorm of smoke in the bay area.

Not wanting to end up sleeping in the gutter, the Hipsters listen to their community, thank them for being very patient, even after spending lots of money and waiting many, many months for the product. The Sacks back off with the financial push and together with their community of developers make the best product ever for the soon to be huge Internet of Beds.


Hey there @rocksetta,

You win points for the entertaining analogy, even if I don't agree with 100% of the commentary :slight_smile:

You are right. Although it seems like launching Particle Mesh might have been three times as much work as launching the Electron (3 products instead of 1), the scope of work to get to what we deemed MVP required closer to ten times as many engineering hours.

Our third generation of hardware is by far our most ambitious product initiative in the history of the company. Though we did not believe the product would be perfect on day one by any means, we fully acknowledge that various issues like inconsistent bluetooth compatibility across Android devices has led to an experience that is rougher around the edges than we intended for initial customer ship.

What I can say is that our intention is and never was to "move on to the next product", and we don't think about Mesh as a short term "financial push". We believe that Mesh networking represents a major new stage for IoT, and expect our development kits to be used by engineers and product creators alike for years to come.

We're swarming on early reliability issues now and intend to resolve them as quickly as possible (we've got early fixes for many of the most interruptive issues coming shortly). We adore our community and sincerely appreciate your help and feedback. We're committed to investing deeply in this product line, and look forward to delivering exciting new features for everyone's new hardware as quickly as possible.

Our engineering team is reminded daily of the reality that what we're trying to do – to build – is hard to do. We also recognize, though, that it's the same reason that we have a business in the first place. If there are other IoT Mesh development platforms that you think we could learn from, Free GoogleMattress included, we're always happy to hear feedback.


The best MESH IOT platform that is really close to what your working on is the XBee line of radios + LTE radios + their Open Thread of radios.

I found that the range of the 802 MESH your working on will not meet my needs so I moved forward with the XBee Digi Mesh 900mhz line and I have to say the features, realibiltiy, PC software, and documentation is top notch and everything works.

Their new XBee3 line of Open Thread + Bluetooth modules for $15 each is a direct competitor of the Xenon in many ways but not all.

I would say they are a good example of how to get it done. But they have also been around longer than Particle and have shipped 10 million units so they are ahead of you guys in that respect.

Coming from a end users point of view who has been with Particle since receiving the first Spark Core that had its own issues and was not reliable when first received, I know you guys will get it all worked out as time goes on.

I love the Particle Platform and this community so don’t take this the wrong way.

I think a lot of people bought expecting the devices would be able to do most of what they were advertised to do, but the reality is that it does little of what it was supposed to do. Alot of what does work is not reliable and nobody warned us about this and what to expect.

You guys billed everybody, shipped the products late, and then left us to find out nothing will work reliably until future firmware releases fixes the problems.

It’s obvious that this project is a lot more complicated and more work than expected.

I’m more than happy to put the equipment on the shelf as the platform is brought up to speed. I just wish you guys were more upfront about what to expect before we received or were billed for the products.

The amazing Photon & Electron are working perfectly and I love using them.

Hope nobody hates me for saying how I feel about the MESH preorder process.

I’m sure in the future it will be amazing like the other products lines have worked out to be.

I just bought 4 Photons off Amazon today.


@RWB, is there an IoT backend to that? IoT is not only the things you have locally around yourself. For IoT the hard stuff is done in the I part of that.
I might have missed the initiative by Xbee to enter that part of the field but AFAICT it's mainly focusing on the T part of IoT while Particle does I and T out of one hand.

After all, while we might mostly see Particle as producer of hardware which happens to also offer some backend, but reality is rather the other way round (IMO) - the backend is the primary product and Particle dev kits (most people in this thread are working with) are exactly that - dev kits or reference designs to illustrate what's possible with that backend and to get PoCs quickly done to check out viability of commercial products.
It costs big money to keep the infrastructure running and enable new soft- and hardware design. The few dollars that come in from the sale of a few thousand moderately priced dev kits (including free backend access) wouldn't be enough to sustain that for more than a few weeks (if that).

But that's my personal view - @Will may want to correct me where I'm wrong :blush:

1 Like

Yes, but it's not nearly as nice as what Particle is building in my personal opinion.

The cellular modems are able to push data to IOT platforms directly to platforms like Amazon IOT.

I totally agree with that. But you have to provide working hardware that interfaces with that backend if you want people to build products that provide value in the world which will end up generating the revenue that keeps Particle alive and thriving.

It's perfectly fine that MESH has turned out to be more of a job to tackle than expected.

It's the lack of communication on what we should expect after paying for the equipment is what has left a sour taste in many of the early adopter's mouths.

I get that they probably figured they could quickly fix it by the time everything arrived but we all quickly learned how much work was left to be done to bring this up to speed.

I applaud Particle for trying new things and I look forward to when everything is working and the initial vision is realized.

The Particle Community is a great place full of specialized knowledge and that to me is just as important as the superior backend they are building for product creators and businesses.

I have 4 Photons arriving tomorrow.


The hardware is, it's the firmware that's lacking/lagging maturity (yet) and Particle is aware of the issues, but would calling back all the delivered devices now and giving up the whole endeavour for the bad start help anybody?
I'd rather have Paricle focus on improving what we've got than tie them down in that effort by forcing them to keep appologising and confessing their sins and crying over spilt milk.

They have heard and acknowledged the complaints and their part for it.
Many of the issues that pop up now were not anticipated - some even couldn't be

  • nd6 vs. IPv4: Who'd thought that in a pure IPv4 setting nd6 packets would be floating around?
  • Do you know or even care how many DNS servers your router sends out? There were many brands tested, but for some reason they all just used two. But surprise, surprise in the wild there are others that don't do the same (there is no rule for or against it)
  • Android fragmentation is a problem for many app creators, testing against each and every flavour or customised version will always be impossible.

How do you communicate issues before you become aware of them?

There should have been a lot more time for beta testing with a wider audience (e.g. including Elites) but due to the manufacturing delays (mostly not Particle's responsibility) that period has been cut short.
Most Elites got their devices for "testing" and prepping up for community support after some people started reporting about their issues.

Bigger companies also trip up bodging their established product lines and are usually nowhere near as open in admitting that.
Particle has been creating an entirely new kind of product line for them and IMO has always been rather open and transparent about their mishaps, limitations and even bodges. They might have been considered slow in their responses at times or overly optimistic about possible resolutions (e.g. timeline updates), but defintly not out of lack of consideration for their user base.