Wireless 6loWPAN mesh "Particle Compound" core

Social Project Share
1

Particle devices are great for many applications. However, the there are some applications where the sensor nodes have to function on small batteries for months, if not years, or even be self-powered from ambient energy sources. Ultra low power BLE devices (such as Bluz, aka SparkLE) could address some of these use cases, but, still, they would not be a good fit for many others. For example, BLE is point-to-point protocol, thus has a limited range. BLE can’t form large mesh wireless networks (some proprietary solutions started to appear, but the standard BLE mesh protocol is yet to come).

On the other hand, Zigbee while successful in the M2M (Machine-to-Machine) applications, is not general enough due to siloed application profiles and is problematic for interfacing with the cloud.

This is where 6loWPAN mesh networking based on IEEE 802.15.4 fills the void. It’s ultra low power, provides robust, mid-range wireless mesh networking, and makes each sensor node individually IP-addressable. (For a good summary of 6loWPAN benefits, read this article: http://www.eetimes.com/document.asp?doc_id=1278794).

I would like to get the community’s feedback about the usefulness of creating such 6loWPAN mesh “Particle compound” nodes. Specifically, the system would be composed of nodes which would self-form a wireless mesh network. The mesh would connect to the cloud via a IP gateway device, such as Photon or Electron (IP gateway could also be a non-Particle device, such as Rasperry Pi or Intel Edison). Each mesh node would show up in the Particle.io cloud as an independent core (just like a Photon) which could be interacted with and programmed over-the-air.

Each node could be powered by a battery or an energy harvesting board (configurable for solar, thermal, or EM field sources).

There are several versions of 6loWPAN implementation with the most dominant being Thread and Contiki. Since Thread is a closed-source implementation, I’d like to propose using Contiki which is fully open source and mature - it has had great traction in academia as well as in industry (via Thingsquare).

There are still a lot of technical questions and challenges to implementing such a solution since the two “operating systems” (ie. Particle and Contiki) would need to be fused together while preserving the overall functionality and system security. And, the wireless MCU’s we are looking have more constrained hardware resources than the Particle devices.

Please let me know if this new type of core would be useful to your projects and what would the the critical features you’d like to see.

12 Likes
2

A IEEE 802.15.4 particle compound is a key piece of hardware that is missing from Particle’s offering. Those type of devices are really designed to run from batteries for long time. WIFI is simply too power hungry for doing mesh sensor networks. You got my vote, I would buy them in a heartbeat if you build them.

2 Likes
3

A quick update.

After doing some investigations, the RAM demands of the TLS secure handshaking with the Particle server (RSA key ciphering, in particular) are too much for the 802.15.4 microcontroller I initially selected. I wanted to use Texas Instruments’ latest wireless MCU - CC2630/CC2650 which has excellent low-power specs (from what I’ve seen the best in the industry at the moment) and a very rich feature set. It also now has Contiki stack ported to it. In addition, it provides seamless migration path to sub-GHz radios, using pin- and software-compatible CC1330 device which provides much better radio range (especially useful for industrial or enterprise applications).

However, CC2630 has quite much less RAM and Flash memory compared other devices, only 20KB and 128KB, respectively. While running Contiki and TLS handshaking concurrently, 20kB RAM is just too tight and 128KB Flash is also very tight to store both Contiki and Particle firmware stacks, along with a user’s application code. Potentially, given enough time to hand-craft and optimize the memory usage, it might be possible to fit it all in (I was looking at different software architectures to offload RSA to the Photon gateway using proxy servers, for example), but the time to market is very important.

So, I investigated other alternatives, namely CC2538 (also from TI). It does not have as good radio performance and low-power specs as CC2630, but it does make up for it with abundant memory (RAM is 32KB and Flash as big as 512KB). It also has more mature Contiki support. So, I decided to pick my battles wisely and go with CC2538 instead. It’s architecturally similar to CC2630/CC1330, so future migration won’t be too bad once TI releases configurations with more memory.

4

I have a few questions to the community to better define the project:

  • what would be the preferred form-factor and the pin headers? XBee is the first to come to my mind since it provides a reasonable balance between the size, cost, and popularity. But, is there any significant downside to this or a much better option I should consider?

  • how about antenna type - internal or external or both? Internal antenna will have a somewhat reduced range compared to external antenna, but it’s more much more compact. Supporting both options will add cost and complexity, especially for narrow-band type of RF radio - 802.15.4 (we are talking about serious “black arts” of RF design :smile:) I’m leaning with internal-only design for now. to keep it compact and easy for people to use.

  • what would be the desired cloud gateways for the mesh network: Ethernet, Photon, Electron, something else (eg. RPi)? I know it would be the best to have them all, but we have to prioritize…

If you have any opinion on these, please chime in.

5

Just FYI - Mesh is one of the design goals for bluz. While it is true that the BLE standard doesn’t officially support it yet, there are many ways to do it. You can read more about it here: http://neighborhood.bluz.io/t/bluz-dk-and-mesh-networking/32

Still, very excited to see more and more hardware options becoming available to Particle users. I’m glad to offer my help if you had any questions, we are pretty far down this road already of integrating into Particle.

As for your questions, my opinion would be to keep the same form factor/pin map as Core/Photon. This way you can use all the awesome existing shields out there. I would also go with an internal antenna just to make it as practical as possible.

As for the gateway, I would recommend a shield approach as we did for bluz. We use SPI to talk from the BLE central module to a Particle device in the socket, this way we can easily switch from Photon to Electron (or whatever comes down the pipe) without changing much, if anything. That is one of the great things about Particle, the ability to switch to different hardware and connected platforms but still use the same underlying code, so it’s good to take advantage of.

Good luck, let me know if I can be of any assistance.

6

I was working on this a while back but life intruded and I had to stop. I believe I was gravitating to an Atmel 802.15.4 chip but I can’t recall at the top of my head what it was (have to check my notes). I’m very enthused that you are taking this up! I also was unsatisfied with the point-to-point nature of BLE.

I agree with eely22, that Core/Photon form factor is desired with an internal antenna. We aren’t resurrecting Zigbee here.

As for the gateway, I do not like the shield approach as the first option. I would like an RPi gateway in the interest of making it as easy as possible for folks to get an 802.15.4 network up and also giving the maximum flexibility for their applications possible.

7

@eely22 and @Stickboy thanks for the constructive feedback.

I think there will be distinct and unique use cases for both BLE Mesh and 802.15.4 networks. They are aiming at similar functionality, but they came from very different backgrounds, so they are likely to have quite different characteristics in the end. But, today, BLE Mesh standard is still up in the air as to how it will trade off power, performance, functionality, and cost parameters. Technology takes time to develop and stabilize. The existing proprietary BLE mesh solutions prevent second-sourcing of IC’s, and don’t work in sub-GHz bands (both may be a concern for commercial customers) as well as lose the major benefit of BLE - universal compatibility (will be a concern for consumers). However, BLE has some serious advantages over 802.15.4: cost and availability of IC’s and modules (at least until Thread starts to drive the demand in the consumer market).

I have considered Particle form factor and pinout, but I ran into the implementation feasibility issues with the narrow form factor. I could not find any modules that were small enough, cost effective, and supported Contiki. In addition, the energy harvesting board (which I think will be a great combo with the mesh node) I already developed with the Xbee form factor is pretty much ready to go to production (already optimized performance with PCB layout and finalized test harness). However, I agree being able to use Particle shields would be very nice, so I’ll still keep on thinking how to achieve this.

@eely22, the Particle gateway design is where, I think, we could collaborate on if your data traffic is IP-based between the edge BLE and the Particle device. In my case, I’m envisioning to connect 6LBR device (6loWPAN edge border router) and Photon/Electron with UART using SLIP protocol. 6LBR would do NAT64 address translation from IPv6 to IPv4 before sending packets into SLIP. The Particle device would just route the IPv4 packets back and forth using a RAW socket (btw, Spark Core does not support RAW sockets, so it wouldn’t be applicable as a gateway device). The nice thing about this approach is that it provides “clean” system partitioning and allows to use the same 6LBR firmware with RPi, Beaglebone, or PC gateways as well.

2 Likes
8

I would love to build a 802.15.4 to Wifi gateway using this chip

but it is not out yet. They say it will be pretty inexpensive.

1 Like
9

Yes, this is an amazing level of integration in a very small form factor. It would be great to use it for the applications requiring significant “processing at the edge” of the mesh network to reduce the response latency and intermittent connectivity with the cloud servers. Intel Edison could be another great choice for this.

It would be great for Particle team to develop a Javascript client for their node stack, so Linux- or Windows10-based systems like these could be used as gateways.

10

@Roman For home/office applications, using a BLE chipset is more economical with offers a smaller footprint. (e.g. Bluz + Photon) specially that Bluz will offer some sort of mesh capability. I have read the article you referred too. Could you suggest some use cases for 6loWPAN networking? What’s the major benefit to the end user?

11

I’m all in for you’re proposal! I have a few private projects in mind which would require Mesh networking. For those I’m currently considering buying a bunch of bluz boards. After a brief discussion on Twitter with @eely22.

Still there are some projects which would profit from an 802.15.4 implementation (all business related). In this context it’s easier to refer to such a specification than to Bluetooth based stuff.

Edit:
In addition I would also prefer some kind of RaspberryPI based Gateway. E.g. USB implementation.

1 Like
12

@Amir, either BLE or 15.4 radios could be used as physical layer for 6loWPAN. 6loWPAN has a very powerful, and distinct property - native IP support, which powers the Internet and allows seamless support for popular internet application layers, such as TCP, UDP, CoAP, WS, along with proven security implementations (TLS, DTLS). These internet technologies are mature and there is a lot of competency around them in the industry. So, while the use cases might not be unique, they can be implemented in more standard way and, thus, at lower cost.
Now, I think your question was more about comparing BLE with 802.15.4-based radios in mesh configuration. Here are my thoughts:

  • 15.4 standard has been around for many years, and thus it is mature and well understood
  • 15.4 has been successfully used in industrial and enterprise use cases on a large scale, and, to some degree, in home/office use cases (ie. Zigbee)
  • 15.4 will be supported by modern home routers, such as Google OnHub, so the interoperability advantage of BLE will be less important in home/office environments
  • BLE mesh is not a standard today and, until the spec is released (it may be a year or two) , I don’t know what power/latency/performance/feature set/cost tradeoffs have been made. These tradeoffs will affect which use cases it will be suitable for vs 15.4
  • I have not studied Nordic nor CSR proprietary mesh-BLE specs, so I don’t know how the above trade-offs stack up against 15.4, but, the general issues with them being proprietary are: (1) no interoperability with smartphones or regular BLE devices (in mesh configuration), (2) single-source IC supply for products which is risky, (3) less mature, which is also a risk factor. (BTW, can anyone comment on the comparison of 15.4 mesh with Nordic/CSR mesh-BLE?)

My opinion (being my own opinion, you may take it with “a grain of salt”) is that both mesh implementations will exist in the long run in home/office environments, especially thanks to 802.15.4-based Thread protocol being adopted by big players: Google, Samsung, ARM, and thanks to some IC vendors (ie. TI) implementing both radio standards in the same IC hardware. In industrial use cases, I think 15.4 is better established (in part thanks to longer-range sub-GHz capability) and will dominate.

I hope this helps.

2 Likes
13

If I can help… I’ve worked professionally for many years with IEEE802.15.4 (omitting Zigbee for good reasons, and using the layer 2.5 MAC).
I feel that 6loWPAN has come and gone. Due mainly to the expected mess with IP header compression and how incompatible that is with 802.15.4’s 100 byte max packets.

Zigbee Pro’s bogged in licensing issues, and the viable “profile” for it seems to have been ignored by the target market: Utilities’ meter reading - where the meter makers went proprietary by intent.
Zigbee’s trying to get the inside-the-home load shedding, load-management future.

So in our context… in a residential setting, Zensys Z-Wave, proprietary, has the greatest market share, but they are tenuous in their prognosis. Intermec’s similar quasi-mesh works well. Quasi because its not self-forming, self healing.

BLE is too low power, IMO. But it is freq. hopping (anti-interference), whereas last I checked, '15.4 has no hopping option standardized.

The sub-GHz form or '15.4 is a totally different MAC than 2.4GHz. And as you know, there’s no single RF band sub-GHz for international. Regulations vary widly, with 902.-928MHz in No. America and elsewhere, 868MHz (fewer channels) in much of the EU for cellular compatibility.

In the open source world, Airespace’s “RadioHead” stack is good.
http://www.airspayce.com/mikem/arduino/RadioHead/
Used mostly with sub-GHz radios, ranging from crummy on/off keying (OOK) radios to nice GFSK (FM) radios with bit rates into the 100’s of Kbps. But all with packet sizes around 128 bytes. CRC in the radio. Lots of HopeRF radios which are modules on which there is a radio chip from one of two American vendors. I’ve worked a lot with these radios and the RH stack, written in C++ with heavy use of inheritance up the stack.

RadioHead’s layers include
MAC
Unreliable datagram with 8 bit addresses and broadcast
Reliable datagram with 8 bit addresses
Routed datagrams with static routing tables (sent OTA)
Mesh routing, self-forming, self-healing. Shortcoming is no end to end reliable datagrams - only inter-node reliable datagrams. Also lacks mutual exclusion use of the radio for mesh packet forwarding vs. local node traffic.

But it does work well for many situations. I did a high traffic star topology with it and lots of radios for telemetry and command/control - with both 8 bit AVR and with ARM Cortex M4 without Arduino dependencies.

14

Hi! Has anyone decided to pursue a SLIP gateway or similar on the Particle stack?

There are a lot of available options out there as far as 802.15.4 mesh networking…but it seems the missing link is using a Photon as a “transparent” gateway between the (6LBR) mesh node and WiFi.

Let me just come out and say what everyone knows this really means. I want to use a Photon as the ethernet adapter for a SAMR21 ok? DOES THE TECHNOLOGY EXIST? Is this the future or what?!

15

Any news on doing a CC2538 based Particle with 6LoWPAN? I have been working quite a lot on the CC2538 platform and Contiki OS and I would be very happy to try such a particle out (and provide some testing support, etc).

16

@msolters, @joakime,

I have looked into using Photon as a SLIP gateway for 6lowpan some time ago. It should be possible without too much hassle as Photon wifi IC supports “raw sockets”, that is, it can pass-through IP packets (layer 3). BTW, older Particle Core (using CC3000) does not provide firmware support for this - only TCP/UDP sockets (layer 4) are supported.

I have not implemented the code since the bigger issue was to make Contiki 6lowpan device to impersonate a Particle device, that is, supporting the same TLS security handshaking and Wiring application API’s, as it would be connecting to the Particle cloud service. There were a number of challenges there, but the main ones were:

  • Contiki OS incompatibility with Particle API’s: Contiki mesh networking stack relies on Protothreads - light and efficient, but with significant limitations on the coding style (especially mixing time delays and functions). This would require lots of code rewriting to both stacks, and/or adding special pre-processor to resolve for low power operation, perhaps with limiting user APIs.

  • MCU resource limitations: TLS handshaking uses a lot of RAM. Having the Contiki network+OS stack and Particle stack running concurrently was putting the 32KB of RAM to the limit, requiring lots of optimizations on a single-chip solution.

  • Due to FCC-certified cost competitive module unavailability for CC2538, I moved to SAM R21, but later discovered Contiki-implementation maturity issues there especially related to low power MAC-layer modes. In general, seems many semiconductor companies are waiting for Thread to take the driver role behind 6lowpan, and Contiki is not getting priority or any (for most 802.15.4 SoC’s out there) support.

All of these challenges could likely be resolved with right level of effort, but it’s a major trail blazing. Between Thread about to be widely deployed in home automation use cases as part of bigger consumer ecosystems and LPWAN technology seemingly better suited for many environmental/commercial/industrial use cases, I’m not now convinced about undertaking this effort/risk tradeoff, so I’ve put this project on hold for now. I’ve been focusing on another wireless sensor node project that does not try to predict precisely the winners of the future IoT wireless standards, but focuses instead on sensor integration and energy management system with various radio modules to be useful in a multitude of IoT use cases.

2 Likes
17

@roman I can confirm everything you have said regarding Contiki support with ATMEL.

Having reached out to one of the primary authors of ATMEL’s fledgling and deeply flawed Contiki support, he said only that “it has many problems,” and that “If your network is small and you are not going for interoperability, then it may work. […] On the other hand, upcoming Thread promises to solve all of this, and if you think that future migration to Thread makes sense for this application, then starting with Contiki is a good way to go.”

I entirely agree that unless you have the manpower to devote to a native Contiki port centered on one of their modules, ATMEL is definitely not the path to a convenient mesh solution. They talk the talk but fail to walk the walk.

This is one of the many reasons that I think a Contiki port to the Photon architecture would be a huge game-changer in terms of the available IoT solutions out there. It would fulfill a solution that, despite claims to the abject contrary, is experimentally unfulfilled by current providers such as ATMEL.

18

@roman, @msolters Well maybe Atmel is not at the moment strongly supporting Contiki but TI, ST, NXP and others are pushing Contiki ports upstream and are not at the moment waiting for Thread to get 6LoWPAN support. Thread will be a good thing for 6LoWPAN interoperability in smart homes and similar “use cases” but have limited scalability and no options for routing with battery powered devices that we can do with Contiki (6LoWPAN, RPL, ContikiMAC or TSCH). But I fully agree with your path on WiFi - 6LoWPAN might or might not succeed and taking a high FCC certification cost might not be the thing to do at the moment. I have not looked much at the Particle API’s so far but know the Contiki stack by heart. I know that a CC2538 can implement a full LWM2M CoAP stack + DTLS with less than half its flash memory used - so I would not consider handling TLS/TCP being a resource problem. I know that Thingsquare do make use of Websockets and TLS on a variety of Contiki devices - but since I do not really know how much the Particle stack would add I am not 100% sure that it would fit.

Maybe we should just pick a “random” CC2538 device and see if we could do a quick hack on combining them?
(not saying I have time right now - but…).

1 Like
19

@joakime that’s exactly what I’m looking at doing right now – in a sense. My first attempt is little more than to bridge a TI module like the CC2650 to a Photon at layer 7 and then just parse and pass TCP traffic that way. But ultimately I’d like to make the Photon a first-class citizen of Contiki:

While I am familiar with Particle and RIOT-OS, Contiki is pretty new to me.

I see there is already an STM32F103 CPU implementation in Contiki. Together with the contents of platform/MCU, I don’t think it should be too difficult to get Contiki to build for the Photon’s STM32F205.

The real question to me is going to be peripheral support, and perhaps you can shed some light on that.

I’m not too sure what the recommended approach is for implementing the Broadcom chip in the Photon boards for Contiki – and, further confusing the issue, Electron support would require an entirely separate stack of drivers. We’d also have to get the Photon/Electron to talk on some 802.15.4 hardware, but I’ve already got something like that working. I’d be surprised if something like that had to be reimplemented in something as mature as Contiki though (?)!

I think that implementing drivers using protothreads in Contiki would be much more comfortable than what’s currently possible in Photon’s default firmware.

20

The main benefit of 6loWPAN is that t allows seamless integration with IPv6 using a relatively simple router. 6loWPAN is essentially IPv6 with header compression optimized for 802.15.4 radios. As such a
6loWPAN <->IPv6 internet gateway is a relatively simple software build on any machine equipped with an 802.15.4 radio and some form of internet connection (Serial, Ethernet, WiFi, POSIP, etc.)

There’s also coming 6LoRaWAN coming from IEEE and IETF which offers some promise for IPv6 integration with LoRaWAN radios.

Frankly, I won’t be looking at any solutions for my future products without IPv6 capability in the chip, especially if I’m using WiFi (e.g. Photon is dead to me until IPv6 support comes up).

For Meshed radios, it’s got to have 6LoWPAN or 6LoRaWAN as appropriate. If BLE ends up getting an IPv6 standard through BTC and IETF, then that might also become a viable alternative, but networking stacks that don’t integrate with IPv6 are just stupid when it comes to IoT at this point.