Thread "module" interface with UC

[alexandre pernot]

Hi everyone,

I start to play with openthread and it's a very good protocol !

I would like to use this protocol to create a mesh network over IP for my wireless devices.

My sensors have a main uC (approx 100MHz) which already interact with differents "modules" : RFID UHF reader, ADC, E-MMC memory, ... 

I prefere this solution with modules because the main processor, is not timing critical in this case.

That's why I love the co-processor approach of thread !

I saw thread support UDP, so I think I'll use Coap or MQTT-SN for application layer.

I would like to see openthread on my sensors like a "module" but I need your help to choose the best interface approach.

I thought of differents possibilities to communicate with this thread "module" (over UART) :

1. CLI interface
   
• Pros:
• simple to debug
  
• standard openthead interface (CLI-UDP and CLI-CoAp)
• no specific code to develop on module (SOC)
• CoAp lib in the SOC
• Cons :
• not easy to use in embeded software (difficult frame parsing)
• ASCII datas -> heavy embeded interface (big overhead)
• only Coap supported
  
  
2. NCP interface
   
• Pros : 
• standard openthead interface
• binary datas -> light embeded interface (little overhead)
• no specific code to develop on module (SOC)
• CoAp Lib in the SOC
• Cons : 
• I don't see UDP or Coap commande in Spinel Host-Controller Protocol, is it possible ?
• only Coap supported
  
  
3. custom interface (RPC for exemple)
• Pros :
• binary datas -> light embeded interface (little overhead)
• COAP or MQTT-SN lib on module
• simple commande to start the module (SOC)
• Cons :
• not standard
• specific code to develop on SOC

What solutions would you advise me ?

Do you see a better solution ?

Thanks for your reply and I'm happy to integrate openthread users !

[Jonathan Hui]

You have a couple approaches in this case.

1) You could have the "sensor MCU" appear as a peripheral to the OpenThread SoC. In this case, all of the sensor drivers and data processing would remain on the "sensor MCU", but the OpenThread SoC would be responsible for any protocol work.

2) You could have the "sensor MCU" also be responsible for handling the top-layer protocol (e.g. interactions with UDP and/or CoAP). This is the approach that you implied in your email below.

The first option gives you flexibility in defining your own "sensor MCU" serial interface between the two MCUs. However, you can perform all the protocol logic on the OpenThread SoC, where you can leverage all of the existing OpenThread APIs, including UDP and CoAP.

The second option allows you to collocate the application logic all on the "sensor MCU", but requires you to work within the constraints of the existing OpenThread interfaces (i.e. Spinel, CLI, etc.). You are correct that the current spinel implementation typically assumes integration with an existing IP stack on the "host MCU". While it is entirely possible to expose a higher-layer API (e.g. UDP or CoAP), those have not yet been implemented.

There is no right or wrong answer here. You will have to judge what is best given the existing constraints.

Hope that helps.

--

Jonathan Hui

--
You received this message because you are subscribed to the Google Groups "openthread-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openthread-use...@googlegroups.com.
To post to this group, send email to openthre...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/00b29c64-c74d-4160-ad1c-7dfdda320717%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[alexandre pernot]

Hi Joanathan,

Thanks for your answers, it's help me to be sure I was on the good way.

I think I'll not go to the CLI interface...

But I find Silicon Labs's module : https://www.silabs.com/products/wireless/mesh-networking/mighty-gecko-modules/mgm13p-mighty-gecko-module

Their differents thread's module have a custom interface protocol, which can support a multi-protocol version (BLE + Thread)

So I think I'll start with their module and use a custom interface.

Thanks a lot for your point of view

--

Alexandre

[tiago morais]

Hi everyone!

I'm planning to use nrf52840 dongle module as my openthread device together with a stm32 uC as mqtt-sn client (I have a raspberry pi 3b with another nrf dongle as ncp border router).

What I would' like to know is: 

    is it possible to make the pub/sub via CLI interface between the stm and the nrf? or is there any other way?

    

Please, have in mind that this is the first time I'm working with all of this (mqtt and openthread :D)

Thank you for your help!

[Jonathan Hui]

OpenThread NCP implements a binary serial protocol called Spinel. While the Spinel protocol does not expose primitives for things like MQTT, it could certainly be added.

Note that MQTT-SN is not something that the OpenThread project currently provides directly. I believe the implementation you reference is provided by the Nordic nRF5 SDK for Thread and Zigbee.

--

Jonathan Hui

To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/f648b424-6ee8-404a-ab7a-8e9f5b010e47%40googlegroups.com.