Particle Introduces New Hardware, Adds Mesh Support

Particle, makers of the WiFi and Cellular IoT modules everyone loves, is introducing their third generation of hardware. The Particle Argon, Boron, and Xenon are Particle’s latest offering in the world of IoT dev boards, and this time they’re adding something amazing: mesh networking.

New Particle boards named Argon, Boron, and XenonThe three new boards are all built around the Nordic nRF52840 SoC and include an ARM Cortex-M4F with 1MB of Flash and 256k of RAM. This chip supports Bluetooth 5 and NFC. Breaking the new lineup down further, the Argon adds WiFi with an ESP32 from Espressif, the Boron brings LTE to the table with a ublox SARA-U260 module, and the Xenon ditches WiFi and Cellular, relying only on Bluetooth, but still retaining mesh networking. This segmentation makes sense; Particle wants you to buy a ton of the Xenon modules to build out your network, and use either the Argon or Boron module to connect to the outside world.

The form factor of the boards conforms to Adafruit Feather standard, a standard that’s good enough, and much better than gigantic Arduino shields with offset pins.

Of particular interest is the support for mesh networks. For IoT solutions (whatever they may be), mesh networking is nearly a necessity if you have a sufficient number of nodes or are covering a large enough area. The technology going into this mesh networking is called Particle Mesh, and is built on OpenThread. While it’s a little early to see Particle’s mesh networking in action, we’re really looking forward to a real-world implementation.

Preorder pricing for these boards sets the Argon module at $15, the Boron at $29, and the Xenon at $9. Shipping is due in July.

33 thoughts on “Particle Introduces New Hardware, Adds Mesh Support

  1. “Of particular interest is the support for mesh networks. For IoT solutions (whatever they may be), mesh networking is nearly a necessity if you have a sufficient number of nodes or are covering a large enough area. ”

    Gotta read up on this, seeing if this is the next “wonder” technology.

    1. it seems simple, but routing is a bitch. you either maintain expensive (memorywise) routing tables, or have to define routes in your packets from the start, at least partially.

      if you dont route, and just flood-forward packets to anyone in range, even if you avoid retransmitting the same packages within a certain timeframe, the bigger the network, the greater the floodstorm, and the lower your useful datarate is, because you end up being 100% busy retransmitting someone else’s packets instead of your own payload….

      also, energy management is a b***h.

      it seems cool, but the implementation details are, so far in mesh networking, some sort of compromise that compromises too much of everything to catch on as a “wonder” tech.

      for special purposes, where you can carefully choose your compromises, its awesome.

      1. For mesh networking you need to have route discovery as part of the protocol, otherwise it does devolve to a spammy mess. But if you keep those messages down to a low enough rate, then it’s not a big deal overall. It gets more complicated if you have multiple gateways, then nodes which are halfway between might flip/flop back and forth. But that’s why you keep a simple routing table in each node pointing at the best upstream node(s) to get traffic to where it needs to go. You just send upstream unless there’s a timeout, then you can either A) fall back ot the next node on the list, or B) send out a route discovery request to all the other nodes looking for the best next hop. It doesn’t need to be a large packet either, just a small one will do.

        There’s lots of strategies you can use here.

  2. Internet connection required!
    Even the so called desktop ide cant compile the code without an internet connection.
    “Particle Dev is a desktop application that allows you to work with local copies of your firmware files. However, internet access is required as the files are pushed to the Particle Cloud for compilation and returns a binary. i.e. This is not an offline development tool, yet.”

    Not for me. Any product that requires an internet connection just to write and compile some code is a fail.

    1. Creeping of the “freeware” syndrome again?
      Always builds in getting people accustomed to ” Oh it’s only just a little thing/detail. Why are you worrying/hung up about it”

      1. I have been writing code for the Photon using Eclipse and gcc. You don’t have to use the online IDE. Indeed, it’s a lot faster compiling offline. So I would expect you could do the same with the new boards.

    1. Seems to be fairly diverse / relaxed development options. The mesh gateway functions and cloud connection stuff is very slick, but looks like it’s still just an ARM + radio, you could dig in and make an isolated network if necessary.

  3. Can anyone explain to me the fascination with Thread? It’s…basically ZigBee, which has already been around for ages. Same ‘sleepy node’ approach with a mandatory wall-powered node within 1 hop, same (enough) mesh routing, same (enough) border routers to link out to any actual Internets / not-theirs protocols. Both even do sorta-IPv6 (6LoWPAN), although I’m not clear on the fascination with this either (as long as you have beefy wall-powered border routers and translation of the 6LoWPAN header back to a real IPv6 header mandatory, just use short IDs locally and let the border router tack a proper IP header on/off as needed). It doesn’t seem like Thread solves any new problem, battery life or otherwise. Widespread adoption of 802.15.4e would be a real game-changer (same idea with TDMA rather than always-on receivers), although combining any known TDMA channel assignment scheme with any known routing protocol is a bit of patent Russian roulette. There was OpenWSN, but it seems to have stagnated.

  4. “Of particular interest is the support for mesh networks. For IoT solutions (whatever they may be), mesh networking is nearly a necessity if you have a sufficient number of nodes or are covering a large enough area. ”

    Mesh networking is very nice but not really an option if your network relies on a large amount of battery powered nodes.

    1. It is… just not with Thread or similar (see my griping a few comments above about reinventing ZigBee and the age-old “push the power problem to a set of continuously-listening receivers” approach). For the commercial (non-opensource) kit, Dust Networks makes a pretty popular product based on Time Synchronized Mesh Protocol (now in 802.15.4e). OpenWSN is a work-in-progress open-source implementation of a very similar idea. The Tx/Rx radios only wake during very short pre-arranged timeslots and are kept in sync by routine traffic. Routes are defined by two devices being assigned the same time/frequency allocation on a repeating hop pattern, making the main tradeoff of this approach (low bandwidth / high latency as each packet can only move 1 hop each time a suitable peer’s Rx timeslot comes around). In Dust/OpenWSN (probably WirelessHART and similar too), there is one master node responsible for doing the actual channel planning and often bridging to a conventional IP network. Especially in the latter case, this node uses the most power, but in many cases can still be battery powered. (There are definitely other low-power TDMA-based mesh protocols, largely used by wink-nudge-saynomore agencies for unattended ground sensors, but details about them might be harder to come by.)

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.