Getting started with embeNET demo for NRF52-DK board

This document describes how to run the embeNET demo application on NRF52-DK boards.

What you'll need

To run the demo all you need is:

To build the project from source code and expand the demo you also need:

The embeNET demo package

The embeNET demo package for NRF52-DK is distributed as a single ZIP file. Unzip it into a convenient location on disk. Inside you'll find a couple of folders:

  • doc - contains this documentation
  • embenet_br - contains the border router application to run on the PC
  • embenet_demo_hex - contains the pre-built firmware hex files for the NRF52-DK boards
  • embenet_demo_src - contains the firmware source code for the NRF52-DK boards
  • enms_visualizer - contains a PC demo application that visualizes the network

Programming the NRF52-DK boards

To quickly test the functionality of the demo two pre-built firmware files are provided within the embenet_demo_hex folder. All you have to do is program the boards. To do that plug in each NRF52-DK board and make sure it shows up as a drive in Windows. To program the board with the firmware simply drag and drop the firmware hex file to the drive. Promptly the board should reset and the firmware should start working.

To run the demo you have to program one board using the embenet_root_demo.hex file (this will be our root node) and all other boards using the embenet_node_demo.hex.

Starting the Network

To start the network you need to connect the root node board to the PC. It should register as a COM port. Next go to the embenet_br folder and edit the config.json file that holds the border router configuration. The file will look similar to this:

{
"serial_port": "COMxx",
"interface_name": "embeNET",
"network": {
"k1": "0xc08b766277099e7d7e9c0222f168cc9e",
"panid": "0xe3be",
"prefix": "0xaaaabbbbccccdddd"
},
"join_rules": [
{
"uid": 0,
"psk": "0x46d7dc94e8ee7496ceaf54a3ab64cbeb"
}
]
}

The file has the following entries:

  • serial_port - defines COM interface for the root node, in COMxx format.
  • interface_name - defines the name of the network interface that will be created within the OS to communicate with the networked nodes
  • panid - it is the 16-bit network identifier - it should be unique for each root
  • k1 is a 128-bit, network-wide key used to authenticate information exchange in the network. This key can be specific to the network or even whole organization.
  • prefix - 64-bit IPv6 prefix of the wireless network
  • join_rules - set of join rules that define which nodes can join the network (see below)

‍Please edit the file to make sure that the serial_port entry matches the COM port registered for the root node board.

IPv6 address of the nodes

Each node in the network, including root has an IPv6 address consisting of two parts:

prefix:uid

where the prefix is set for the network in the config.json file and the uid should be the 64-bit IEEE EUI-64 identifier, also known as the MAC address. In case of nRF52 chips however this number is not assigned in production. So instead in the demo we take the built-in 64-bit Device identifier (DEVICEID). For development purposes this is perfectly fine. For production however we recommend to obtain a set of EUI-64 numbers from IEEE. This can also be done through a use of EUI-64 node address chips available as PCB components.

Join rules

Each node that wishes to join the embeNET network needs to be authorized by the built-in Authentication Authority. The authentication process uses a pre-shared key (psk), that needs to be configured in the nodes during commissioning. In the provided demo application firmware the key is hardcoded in the main.c file. During the authentication process both the uid and psk have to match what is defined in the join_rules in order to let the node join the network. However, when uid is set to 0, EVERY node with matching psk (pre-shared key) will be able to join the network. We call it the "zero rule". It is useful for testing and experimenting, however it should probably be disabled in the real deployment.

Running the border router application

The network is started once you run the border router application embenet_br.exe. The application will try to connect to the root node and then manage the network.

This is a console application that will also log a lot of information about what is going on in the network and what packets are received from the nodes. Analyzing this log may help dealing with problems, if they arise during the further development process.

Connecting the nodes

Once the border router application is running, all nodes within the communication range, should start to join the network. Be aware that this process may take couple of minutes depending on the network topology and the state of the nodes. For example: nodes that previously joined the network may require some time to notice that the border router was restarted before they attempt to join again.

Virtual network interface

While running, the border router application registers a virtual network interface within Windows. The interface name will be set according to the config.json file. You can check the presence of this interface by running the standard Windows command:

ipconfig

Also, each connected node is reachable by ICMPv6 'ping'.

Visualizing the network

The demo package includes an application that visualizes the network. It is called enms_visualizer and it is based on the ENMS service running in the background of the network. To use it simply run the application while the network is running. After a minute or so the ENMS messages will feed the application with the current state of the network, that will be visualized as a graph, spanning from the root node.

Exemplary topology with two nodes may look like this:

Network services

A network service in embeNET, is a separated piece of functionality built around the communication over a single UDP port (rarely - multiple UDP ports). Two examples of services built into the core embeNET stack are:

  • ENMS: embeNET Network Management service that allows to gather information about the network operation from the nodes
  • BOTA: Bulk-Over-The-Air service that allows to send large portions of data (for example - new firmware) between the nodes. Note that BOTA service is not available in this demo

The users however can easily develop their own services. An example of such a custom service is implemented in the demo nodes.

Custom service in the demo application

The custom service implemented in the demo works on UDP port number 1234. Please note that this service works on remote nodes only - it is not available in root node. The service does two things:

  • periodically sends a simple text message with counter to the border router node
  • reacts to some simple text commands that control the on-boards LEDs - these commands are: led1on, led1off, led2on, led2off, led3on and led3off

There are many ways you can interact with UDP ports to test this service. One of the easiest is to use an application called UDP - Sender/Reciever app from Microsoft Store. Once you run set the mode to Sender/Receiver. Next, in the Remote IP box input the IPv6 address of the remote node that you wish to communicate with. When using the default network prefix, this IP address will have the following form:

aaaa:bbbb:cccc:dddd:<UID>

where the <UID> will be the MAC address of the node.

In the Remote Port and Local Port boxes put port number: 1234

Once you hit Connect you should see incoming text messages. You can also send some commands to light the LEDs on and off.

Building the project from source code

Preparation of the tools.

Download and install the build toolchain for Arm: Arm GNU Toolchain. Download the NRF52 SDK (we tested it using version tagged nRF5_SDK_17.1.0_ddde560) and unzip it to a convenient location (better to avoid very long paths and paths with spaces). Go into the SDK folder and take a look at the components/toolchain/gcc/Makefile.windows file. You may want to adjust the GNU_INSTALL_ROOT path there to reflect the path where you've installed the toolchain. For example:

GNU_INSTALL_ROOT := c:/tools/GNU Arm Embedded Toolchain/10 2021.10/bin/

If you don't already have make

Following the nRF52 SDK convention the demo uses a Makefile. You'll need the make.exe tool to build it but chances are you already have it installed. If not you can download the minimum package here: embeshell-make

Building

The demo source code is located inside the embenet_demo_src folder. To build the project you have to run make like this:

make all SDK_ROOT=c:/tools/nRF5_SDK_17.1.0_ddde560

where SDK_ROOT should reflect the path where you've installed the NRF52 SDK on your local hard drive. This should build two hex files: embenet_root_demo.hex and embenet_node_demo.hex

Next steps

In order to get to know the internals of the demo and to modify or extend it refer to Internals of the embeNET demo for NRF52-DK board

Go to Top