This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Thread Border Router networking fail

Hello Nordic Taam:

I follow the WEB steps below

https://infocenter.nordicsemi.com/index.jsp?topic=%2Fsdk_tz_v4.1.0%2Fthread_ot_performance_measurement.html

Software Development Kit > nRF5 SDK for Thread and Zigbee v4.1.0 > Thread > Thread tools > Thread Border Router

nRF52840 DK Version:nRF5_SDK_for_Thread_and_Zigbee_v4.1.0_32ce5f8\examples\thread\ncp\ftd\uart\hex

Raspberry Pi 3 Version:RaspPi_OT_Border_Router_Demo_v4.1.0-1.alpha

Use nRF52840 DK UART connect Raspberry Pi 3 to get the following information

wpan0 => [
"NCP:State" => "associating"
"Daemon:Enabled" => true
"NCP:Version" => "OPENTHREAD/20191113-00534-gc6a258e3; NRF52840; Apr 5 2020 21:51:18"
"Daemon:Version" => "0.08.00d (; Apr 21 2020 19:11:43)"
"Config:NCP:DriverName" => "spinel"
"NCP:HardwareAddress" => [F4CE363EC3C45B0E]
]


pi@raspberrypi:~ $ sudo wpanctl status
wpan0 => [
"NCP:State" => "uninitialized"
"Daemon:Enabled" => true
"NCP:Version" => ""
"Daemon:Version" => "0.08.00d (; Apr 21 2020 19:11:43)"
"Config:NCP:DriverName" => "spinel"
"NCP:HardwareAddress" => [F4CE363EC3C45B0E]
]

If I have the wrong steps or have not completed, please give me some pointers, thank you.

Also, can you teach me how to set up the Thread Border Router successfully on Raspberry Pi 3?

Best Regards

Rick.

Parents
  • Hi,

    The instructions on Thread Border Router is the latest and should be correct. It also looks like you are using the correct versions of the firmware and border router image. 

    I have tested this multiple times before, and have not had any issues with getting the network up and running.

    Are you using a revision 1 DK or later? Did you have the DK connected to the RPi before you booted it? Did you run 'erase all' command on the DK before flashing the NCP FW? You did not run any other commands on the border router prior to the "sudo wpanctl status" command?

    If nothing works, I would suggest that you start over and flash the DK and border router image again to the devices to see if that solves any issues.

    Best regards,
    Jørgen

  • Hi Jørgen:

    How are you today!

    Is there any update?

    Pls kindly help advise how to solve it?

    Best Regards,

    Rick.

  • It looks like you are able to ping Google DNS from the CLI, so that indicates that the connection should be ok. 

    Can you try to do the DNS resolve command from the CLI, to check if you are able to get the IP from thethings.IO cloud solution, or if it is somehow blocked? I tested this on my setup right now, and it worked:

    dns resolve coap.thethings.io fdaa:bb:1::2
    > DNS response for coap.thethings.io - 64:ff9b:0:0:0:0:68c7:55d3 TTL: 299
    Done

    You should also make sure to use the examples from the latest SDK version (v4.1.0), and not the older v3.2.0.

  • Hi Jørgen

    Thanks for your help.

    My nRD52840 DK boards is revision 0.9.0 and 0.9.2. so I use SDK 2.0 and My phone share AP to Raspberry Pi, It can send data to thething.io. 

    after SDK 3.1 to 4.2 version is not successfully work.
    I will buy new boards to try the new versions.

    BTW:

    SDK can mixing use?
    ex:
    SDK 2.0 example thething for cloud is the device.
    SDK 3.2 Border Router + RaspPi_OT_Border_Router_Demo_v4.1.0-1.alpha
    or
    SDK 3.2 example thething for cloud is device.
    SDK 2.0 Border Router + RaspPi_OT_Border_Router_Demo_v2.0.0-1.alpha

    Best Regards,

    Rick.

  • Hi,

    Using example applications from older SDKs should work in general. For the cloud examples, external things outside our control can change over time, making the documentation outdated.

    Regarding the border router, there can be small changes in semantics between releases, breaking compatibility if you mix the versions. I would highly recommend using the NCP firmware from the corresponding SDK to the Border Router image used (i.e. nRF5 SDK for Thread and Zigbee v4.1.0 together with RaspPi_OT_Border_Router_Demo_v4.1.0-1.alpha, etc).

    Best regards,
    Jørgen

  • Hi Jørgen
    I use new boards and SDK 4.1 it is work.

    I can send temp data to thething.io server from coap.

    1. but how I can get thething.io control my device from coap?

    2. how can use CLI send to CoAP Command get/post to thething.io from nRF52840 EVK?
    I use command is fail.
    coap post coap.thethings.io/v2/things/GITM86uZNPu9Ukmja16PM-X-enajMxP01PODgS3tYVI/ temp {"values":[{"key":"temp","value":"9"}]}

    coap get coap.thethings.io/v2/things/GITM86uZNPu9Ukmja16PM-X-enajMxP01PODgS3tYVI/ temp

    Best Regards,
    Rick.

  • Hi Rick,

    1. Controlling the Thread node from the IPv4 based CoAP Cloud service is not trivial. There is no direct connection between the cloud and the node, so the cloud does not have any address to send the commands to. Communication from the node to cloud goes through NAT64, which translates the IPv6 packets to IPv4, and handles forwarding of the responses to the correct node. Something similar is possible using NAT46, but this is not supported by default in the border router image. If you get native IPv6 connection, this will provide a global IPv6 address for each node, that allows the cloud service to communicate directly with a node to control it.

    2. You can have a look at the CoAP CLI API reference here. I do not think this API is intended for sending CoAP messages to the cloud services, it is mainly for testing CoAP messages between Thread nodes in the same network. The API most certainly does not support converting the full URL with token to a correct CoAP message.

    Best regards,
    Jørgen

Reply
  • Hi Rick,

    1. Controlling the Thread node from the IPv4 based CoAP Cloud service is not trivial. There is no direct connection between the cloud and the node, so the cloud does not have any address to send the commands to. Communication from the node to cloud goes through NAT64, which translates the IPv6 packets to IPv4, and handles forwarding of the responses to the correct node. Something similar is possible using NAT46, but this is not supported by default in the border router image. If you get native IPv6 connection, this will provide a global IPv6 address for each node, that allows the cloud service to communicate directly with a node to control it.

    2. You can have a look at the CoAP CLI API reference here. I do not think this API is intended for sending CoAP messages to the cloud services, it is mainly for testing CoAP messages between Thread nodes in the same network. The API most certainly does not support converting the full URL with token to a correct CoAP message.

    Best regards,
    Jørgen

Children
No Data
Related