Thread capability

Any possibility to have Thread as part of the wi-fi stack?

It would be fantastic to have the Thread, since it is becoming the de facto standard for wireless sensing/control

Welcome to the forum. I’ve looked at the OpenThread source recently and it’s daunting. It would have to be done in native/firmware code and as a driver for one or more 6LoWPAN radios. I think it could work as a loadable module for TinyCLR.

So, yes, it is doable, but a pretty heavy lift. Seems like one of those things that’s big enough that you’ll either need to convince someone of the revenue opportunity; convince a hobbyist of the level of karma points, fame, and adulation; supply a suitable sack of money; or dig out a mainboard, 6LoWPAN radio, and a compiler.

Thank you Martin.

We are keenly looking to use Thread with .NET of course, for both wireless sensor/control scenario.Also powered, but Thread driven control for lighting control and occupancy/temp/light sensing and other varied applications.

Yes, about the heavy lifting for Thread implementation.

We are a small company, but we are open to a like minded crowd funded participation, if we can make this happen.

We are currently planning to evaluate GHI boards. As I noticed in the forum, SQL Lite and SignalR would almost be a necessity for resiliency and store/forward on failure capability in our case as well.

Why thread? With the different options tons and everyone saying their standard is the standard, why did you pick thread?

@PIyer - Thread defines multiple device roles. The Sleepy End Node is the most obvious and easiest place to apply Thread to TinyCLR. Routers should be straightforward as well. I can’t imagine that you would need SQLite or SignalR until you reach the Edge nodes, and by then you’re probably looking at a much more capable MCU. I’ve fallen out of touch with the state of things in TinyCLR, but Gus could let you know what the SQLite options are.

Another option is to try to port TinyCLR or netmf to the Particle boards which are Cortex M4 devices that already have a compatible radio on them. Some have GSM and/or wifi radios as well so they work as Edge nodes. The Xenon and Argon boards come with Thread firmware, but you could probably bake a netmf build with OpenThread on it as well. The point is, you have a working 6LoWPAN hardware design to start from.

@Gus_Issa - Thread is what Nest, Samsung, and a bunch of other big players use for home automation, so it’s becoming at least as relevant as Zigbee and friends.

Hi Gus

  1. IPv6
  2. Mesh and resilient
  3. Lowest power to range among the current wireless protocols on the 11.15.4

to add to this

the European Open AIS is already finalizing on Thread for Intelligent Lighting Systems

Google kind of lucked into it when they purchased Nest. Google is making it less open now, that is why the push towards the Open Thread is gaining momentum…

Thank you Martin

My apologies, we are looking at SQLite/SignalR for our wired controller with TinyCLR

Thread use case scenarios would not require that.

We will definitely looking at the possibility of TinyCLR on one of the Thread modules

Martin/Gus - You are the experts on TinyCLR on ST MCUs

ST has STM32WB with Thread stack already built-in. Not sure about the .NET capability

It would be great to the TinyCLR capability on this

The easiest and realistic solution to OpenThread support is by NCP design.

There’s a lot of Thread solutions, the trick here is compiling Thread into a netmf-derivative interpreter stack. Finding a Thread stack is not where the work lies - fining someone to build it into netmf/TinyCLR is.

My point was, instead of build NetMF on top of Thread HAL, to make NCP (coprocessor) driver. And control Thread programmed MCU by UART/SPI through Spinel protocol.

It maybe possible for very tiny solutions as these chips are limited in resources. You are better off pairing the “thread” chip with another running TinyCLR and doing everything you need.