Need information on any App support for my setup

[UmaMaheswar]

 I have Raspbery pi flashed with nordic alpha 4.1.0.1 image + nrf52840 dongle in NCP design .

As an end device I have EFR32 MG12 WSTK flashed with OT-CLI-FTD code and connected to the BorderRouter as a child.

I have one more extra nrf52840 dongle too.

With the above setup I need to use a app from mobile and communicate with devices in Thread network.

Is it possible to do any kind of demo with above requirement?

And need information on what all I can do with the two nrf52840 dongles, Raspberry pi and EFR32MG12 WSTK.

If usage of App with current isn't possible what is must to demo something with thread network

Thanks in advance.

[Jørgen Holmefjord]

Hi,

Since the mobile phone does not have Thread capabilities, you need to do the communication over another network interface. You have two available options with your setup:

• Use our multiprotocol solution, to send data over BLE from the phone to the node in the Thread network, which can forward the data to other devices.
• Send the data from the phone over WiFi, through the border router and to the Thread end-node.

Sending data over WiFi depends a bit on the setup on both the phone and the border router. If both devices have global IPv6 connectivity, you can talk directly between the two devices without any translations. If you only have IPv4 connectivity, or the border router have too small address space to assign global IPv6 addresses to the end-node, the setup becomes more compex. Let me know more about what you are trying to achieve, and I will try to give you a more precise suggestion.

Best regards,
Jørgen

[Jørgen Holmefjord]

UmaMaheswar said:

If I wanted to go for WiFi dependency, How do I check if the mobile phone and BorderRouter has IPv6 Connectivity and what setup do I actually need if I need to go with WIFI process? 

You can see this from the ifconfig output of your Border Router:

pi@raspberrypi:~ $ ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.68.118  netmask 255.255.255.0  broadcast 192.168.68.255
        inet6 fe80::ba27:ebff:fe98:7d96  prefixlen 64  scopeid 0x20<link>
        ether b8:27:eb:98:7d:96  txqueuelen 1000  (Ethernet)
        RX packets 4978262  bytes 790060249 (753.4 MiB)
        RX errors 0  dropped 121  overruns 0  frame 0
        TX packets 263186  bytes 47391892 (45.1 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

If you see a inet6 line with scopeid 0x0<global> and a prefixlen of 62 or lower, you should be able to achieve IPv6 connectivity to the end nodes. In the output I posted above, there is no global IPv6 connectivity.

UmaMaheswar said:

If I want to go for BLE, What do I actually need? and the setup that I have is enough for this example?

Starting out with the BLE UART and Thread MTD CoAP Client Example may be the simples approach. Then you can use the nRF Toolbox app to send strings to the Thread device over BLE through the Nordic UART service (NUS). Other nodes in the network can run CoAP server example to receive data from the BLE-enabled node. You need to adapt the examples for your data types.

UmaMaheswar said:

Everywhere in that examples they have shown support for only for the DK but not for Dongle. Does it have support for dongle too?

The dongles are only supported for NCP and CLI examples. We high discourage using the dongles for firmware development, as they have not debug capabilities built-in. It is possible to adapt the examples to adapt the examples to run on the dongle, but using the DK is much simpler for development.

UmaMaheswar said:

Among these which is the simplest method to perform? and can you please guide me to install that with my current setup i.e. BorderRouter[Raspberry Pi with Nordic Alpha image+Nrf52840 Dongle flashed with NCP] and EFR32MG12 flashed with ot-cli-ftd code and acting as a child device ??

Given that your phone and the Thread nodes have global IPv6 connectivity, the WiFi approach is definitely the simples, as you can send packets directly using the IPv6 address without the need for any packet translation in between. Development on the phone side may be a bigger effort with the WiFi approach, as we do not have any applications providing this, but since this would be using standard IP tools, there should be 3rd party applications you can use.