• State Not Answered
  • Replies 12 replies
  • Subscribers 69 subscribers
  • Views 1996 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 299391
Options

Google Thread protocol vs. BLE Mesh

Jeffery

Hi Nordic team

I am skilled in BLE Mesh and developed BLE mesh at several projects.

At BLE mesh, 

1. Provisioner was hard-code consistent. It could be smartphone with nRF Mesh apps or standalone solution as a Nordic chip.

2. Provisionee broadcasted unprovisioned beacon to let provisioner find it and add it to this network. Then, this provisionee become a node in this network.

3. Provisioner can configure models of every node in order to divide all nodes in network into several groups. Then, client node can control multi server nodes in same group. 

My questions about Thread

Q1. Tested COAP client and COAP server, client can send multicast message to all FTDs/MEDs. Or, single paired between client and one server, client can send message

       only to paired server. If we want group division same as BLE mesh, can Thead make it? Through which interface to manually configure it? As BLE mesh, user can configure group at

       smartphone.

Q2. If we selected COAP client and server samples at nrf SDK connect as a start point to develop our own project, it seems nothing to do for Thread network management, after reboot many

       client and many server devices, they will form a Thread network automatically, including who was leader, who was assigned to commissioner, controlling router numbers (16~23), router

       path and others. So, what we can do at a device is very simple to send or receive user message data after network was formed. Right?  

Q3. For Q2, if there are two independent Thread networks at office A and B. Several COAP client and server devices in each office. How can I modify code or parameters in COAP samples

       to prevent communication between office A and B?

Q4. At COAP client and server samples, after commission done, did the network information store at flash memory?

Q5. Did Thread define model spec. similar as BLE mesh?

Thanks

Jeffery

  

  • 0 in reply to Sigurd Hellesvik

    Thanks. So, actually, commissioning is not all necessary for thread communication. It just let both sides got same thread configurations, right?

  • 0 in reply to Jeffery

    Thread devices with the same thread configurations will automatically connect yes.

    But in the field, you likely want devices to use commissioning instead.
    Here are some reasons to why:

    • Thread devices for smart homes often needs to work on other thread networks. If you hard-code Thread configs, devices can only work with your devices(as only they have the same config). You loose interoperability.
    • Security is a nice feature in Thread networks. If consumer A buys your thread device, consumer B can buy another of the same device and connect to Consumer A home network without Consumer A knowing.

    So it is most often better to have thread networks with generated network configurations and use Commisioning.

    Regards,
    Sigurd Hellesvik

  • 0 in reply to Sigurd Hellesvik

    Hi Sigurd

    I tried ur  CoAP Client+Server with automatic commissioning samples.

     Below was what I did

    - Download ZIP of samples_for_nr_connect_sdk. Unzopped it amd extracted commissioner and joiner

      folders to my local folder.

    - At VS code,  "Adding an existing application" for commissioner and joiner folders each.

    - Then, build configuration was nrf52840dk_nrf52840.

    At SDK v2.2.0 environment, Build failed for both projects. It showed "FATAL ERROR command status 1"

    At SDK v2.1.2 and v1.9.1, build successfully.

    - Then, flash commissioner and joiner to two DK boards. Open serial terminal for both.

    - At commissioner, "ot commissioner start" and "ot commissioner joiner add * J01NU5 20"

     DK returns "Done" without problem.

     However, after 20 seconds timeout, it showed "joiner remove". The results were 

     same for v2.1.2 and v1.9.1.

    Q1. Shall I send any "ot" command to joiner board? 

    Q2. How can I solve SDK2.2.0 build failed issue?

    Q3. If commissioning was successful, how to verify they are at same network? Only

        by "ping"?

    Jeff

  • 0 in reply to Jeffery

    Hi Sigurd

    For SDK2.1.2 &2.2.0 Openthread COAP client and server samples, I flashed the code to two nrf52840 DK

    boards. Recycle the power, and observed serial terminal. I found these two became Leader and cannot

    communicate. I tried several time and result was same.

    Jeff

  • 0 in reply to Jeffery

    Hi Jeff,

    Jeffery said:
    Q1. Shall I send any "ot" command to joiner board? 

    The joiner should be able to join automatically, so no.

    Jeffery said:
    Q2. How can I solve SDK2.2.0 build failed issue?

    Do your build log fore 2.2.0 include any more detailed error messages?
    If you wish to insert the whole log, remember to use Insert->Code to keep DevZone tidy.

    Jeffery said:

    Q3. If commissioning was successful, how to verify they are at same network? Only

        by "ping"?

    You can use "ot state" to see if the device is child or leader. One should be child and the other leader.
    Then the leader can use "ot child table" to list the child.

    Jeffery said:

    For SDK2.1.2 &2.2.0 Openthread COAP client and server samples, I flashed the code to two nrf52840 DK

    boards. Recycle the power, and observed serial terminal. I found these two became Leader and cannot

    communicate. I tried several time and result was same.

    Can you do the following commands to both, and post it here in 2x Insert->Code?

    ot state
ot panid
ot extpanid
ot channel
ot networkkey

    Regards,
    Sigurd Hellesvik

Related