Join an existing mesh Network with a mesh provisioner (nrf mesh sdk)

[neicureuil]

Hi,

Is it possible to join an existing mesh network with a provisioner made on Nrf52840 (s140)  ?

I have used the provisioner example to make a provisioner which actually create a new mesh network. But after an "erase all" of the board, the provisioning data are lost and the board can't reconnect to the network because information are lost during the erase (logic).

Is there a way to extract the provisioning data and mesh network data from the board to use them later on an other board ?

My goal is to create a mesh network with a device, then store in a file all the information related to this network to be able later with another board to join this network and add new devices.

I have setup a serial connection to send data through the usb port to my computer so I could retrieve and return the data by this method.

I know that this is possible in the mobile application with the "export network" and "import network" functions but I can't reproduce the functionality with the mesh SDK.

Is this possible? If yes how?
Regards

Used sdk :

- nRF5_SDK_16.0.0_98a08e2

- nrf5_SDK_for_Mesh_v4.2.0_src

Board used :

- nrf52840 evaluation board

- nrf52832 evaluation board

[Hung Bui]

Hi Neicureuil, 

The easiest way of "exporting" the provisioner data to another board is to just do a hex dump of the flash content of the board (nrfjprog --readcode ). You can then use this hex file to flash on other board to access the network. 
However doing that doesn't allow to have multiple provisioner at the same time and every time you provision a new node you would need to do a new hex dump. And that you would have only one firmware for all the provisioner. 

A more advanced option is to only copy the specific data that need to be restored on a new board so that you can customized it to export and import. What you need to copy is : network key, application keys, device keys, the composition data of nodes.
We don't have the code of doing that. You would need to study the code and send such data back to PC.

I would suggest to go for option 1 if you don't need any extra requirement. If you don't want to clone the whole flash, you can think of only copy the flash area that the dsm store the database. This way you can customize the firmware, and only copy the database flash area. 

[neicureuil]

Hi,

Thank for your response.

Is there a way to copy the flash area without using "nrfjprog" because at the end, the goal is to put the code on a nrf52840 usb dongle which will be connected to a linux autonomous computer (maybe directly from the code).

[Hung Bui]

Hi Neicureuil, 

I would suggest to test trying to add a new "normal" node to the network by hardcoded provisioning, instead of adding the new provisioner. 
This way it's easier to test if the model that is not health model works or not. 
As I mentioned, you may want to compare what you hardcoded to what stored in the flash if they are the same. You can use two identical node, one is provisioned by a provisioner and one is hardcoded provisioning data that you added. 

[neicureuil]

Hi,

I don't find anything inconsistent in sending the model messages.
Is there another index that would be related to the number of messages sent by models (like IV but will be increase at each model message, or a thing like that) ?

Regards

[Hung Bui]

I guess you are looking for sequence number, please look for sequence_number in the code. 

[neicureuil]

Hi,

After few tests, its seems to be a sequence number issue. I will still do more tests to be sure.

Now what I don't understand is why when I reload my network and turn the nodes off and on, they respond directly to the provisioner's message without having to wait 5 minutes.
Normally the sequence_number and iv_index should be stored in flash and reloaded when the node is started. They should therefore theoretically take the same amount of time (5 mins) to respond to  messages (the time to re-synchronize with the provisioner).

Why would turning the nodes off and on solve the problem?

Regards

[tesc]

Hi,

There are two mechanisms at play, which can explain behaviors related to sequence numbers:

1) For incoming packets, the sequence numbers received from "known devices" are stored in RAM only. That means if you reset a device then it will accept a series of packets starting from any sequence number. (But when additional packets comes in, it will only accept those with a higher sequence number than any other packet received after the reset.)

2) For outgoing packets:

If the stack were to store the sequence number to flash every time the node sent a message, then the flash would quickly wear out. Therefore the sequence number is held in RAM.

It also must be able to start at a higher number after the next reset, so some information must be stored to Flash.

The solution is that a sequence number is written to Flash, but that number is significantly higher than the "real" sequence number in RAM. It does not have to be updated in Flash until the number in RAM gets close to it, but whenever that happens it is increased by a lot. That way it seldom writes to Flash, but still ensures we always have a higher number in Flash than what we have in RAM. That way, after a reset, the stack can continue from the value read from Flash, which guarantees it starts on a higher number than has ever been used earlier.

This mechanism has the side effect that every time the device is reset, it will increase its sequence number by a lot. (By default the number in Flash increases by 8192 both on reset and whenever the number in RAM gets close to the current number.)

Regards,
Terje