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.
1 Like
Hi Gus
- IPv6
- Mesh and resilient
- 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.
If anyone is interested, i just released .Net Core library for OpenThread.
Source code is available at GitHub - vgolovanov/OpenThreadDotNet: .Net Core library is designed to work with the Thread network. To develop 6LoWPAN applications, you will need a radio module running as an OpenThread Network Co-Processor (NCP)..
After bug fixes i planning port it to nanoframework and tinyclros.
2 Likes
Yes please 
Absolutely interested, great news!. All our coding now is fully in .NET core. On the mcu we are coding in nanoframework as well. Will definitely get our team to participate and contribute if we can. Heading over to github right away!
TI 26X2 is a great choice, because the sub GHz LPWAN standard is now open sourced though MIOTY Alliance. the sub GHZ looks really promising for long range IoT devices within buildings as well as open fields.
2 Likes
The whole structure of low-level data packets depends on the NCP co-processor and the Spinel protocol. A big advantage of the NCP design is that there is no binding to the manufacturer of chips and modules. Therefore, I did not have any special reasons for using the CC2652, just at that moment it was at hand.
But the Spinel protocol standard is very tied to IPv6 and mesh networks. As far as I know, MIOTY is designed for other purposes and uses a completely different principle of networking. MIOTY is more competes or complements Lora and Sigfox then 6lowpan technology.
Forgot to mention, there is two versions of CC2652. CC2652P is version of MCU with +20 dBm integrated power amplifier for long-range data transmission.
Very true regarding the sub GHz complexity as of now. But I see that as a really promising technology which will pick-up momentum because of the costs and open source compared to LoRa and SigFox. I can see it’s potential being used especially in applications in commercial buildings and possibly public utilities.
Updated library source code is published to a new location with possible support of TinyCLR (not tested yet on real hardware) GitHub - openthreaddotnet/OpenThreadDotNet: ​OpenThreadDotNet is a .Net library designed to work with the Thread network.
1 Like
What do you need to test on TinyCLR?