NRF node (sensor server) loses provisioning automatically

[AdityaN]

I'm using NCS V2.2.0 with the UBLOX module (nrf52832). I changed the example of the sensor server. UBLOX module's power turns off, then turns back on extetrnally(through a separate IC) for my application. The module was automatically unprovisioned after five hours of flawless operation.

I am not able to debug why this is happening, and am not sure how to prevent it.

Can someone help me figure out the problem or even bypass it?

Let me know if you need anything else.

Thanks

[Edvin]

Hello,

For how long does the separate IC turn your device off? And how often?

When the device is unprovisioned, does the log from the nRF say anything when the application starts up again?

Best regards,

Edvin

[AdityaN]

Hey Edvin, Sorry for late reply

The IC is supposed to turn the device on after every 30 secs. The power is cut off when BLE mesh model is done publishing data(using a GPIO to indicate that publishing is done).  The device got unprovisioned after a few hours(about 5 hours).

The device was in the cycle of publishing and sleeping of 30 seconds for around 5 hours.

Unfortunately, i am unable to get logs from device, as when we power the module from debugger, the power doesn't get cut off. The power cuts off only when module is powered through a battery. And that's why is it becoming difficult to debug this problem. Can you recommend me a way to get logs from the module?

[Edvin]

Hello,

I needed to discuss the consequences of this with a colleague, and we concluded that it is a very bad idea to have normal Mesh nodes where you just cut the power regularly. There are several reasons for this, but our main theory is that what you are seeing is the following:

All mesh nodes have a sequence number (used by the mesh messages) that is strictly incrementing (to prevent replay attacks). These are stored in chunks in RAM, but after a reboot, it needs to discard the rest of the sequence numbers in that chunk. By default I think this number is 8192. This means that every 30 seconds, you will "waste" 8191 sequence numbers. In itself it is not a problem, but if you run out of these numbers, you need to wait for the Mesh networks next IV update. This happens roughly every week (192 hours).

So basically, you are running out of messages that you can use.

This is one of the reasons we don't recommend just turning off the mesh nodes when you don't want to use them.

I think we need to go back to the drawing board. You can consider friend nodes (low power nodes) in Mesh. This allows you to turn off the radio, which consumes most of the power. Compared to running a full Mesh node, it is basically powered off when it is sleeping. (at least negligible compared to having the radio in active TX/RX). 

This requires you to have some full nodes that can act as friend nodes for the low power nodes. It needs to hold messages for the nodes it is parent for, so it is not unlimited nodes per friend node. But it is restricted by the amount of traffic in the network.

Could your use case be solved by using normal advertisement and a normal scanner? How much data are you sending every 30 seconds?

Best regards,

Edvin

[AdityaN]

Hey,

Thanks for sharing this with me, now i know what the problem is. But it is crucial for me to cut off the power of this node. I am using a 3V battery, 1000mAH and I want to make it last for around 10 years. 

Let me explain the architecture of this particular transmitter node.

The node wakes up, takes an ADC reading of temperature and battery value, stores it in the NVS. Then depending on the following conditions, the node will publish the reading. Below are the conditions for publishing data:

1. If it hasn't published for 5 minutes.

2. if there is significant change in the temperature or battery reading.

Else the node doesn't publish and the power is cut off just after ADC reading.

We can have only one friend node(which will be the receiver), but since there can be around 8 transmitters, the memory might be an issue on it.

Can you recommend a solution for this issue?

[Edvin]

If you only have 8 nodes, why don't you just use A: normal BLE advertising (beacon), or B: advertise -> connect -> send data -> disconnect.

Either should work. Which one is better, current consumption wise, depends on the amount of data that you are transmitting every time.

I really think you should consider this. I don't know what current consumption you are currently looking at with your external IC + Mesh setup. But I would expect both of the options A and B above would consume less than what you are currently seeing, even without an external IC cutting the power. As long as the nRF goes to sleep with only a timer running, it's current consumption is neglible compared to a few seconds in Mesh mode. 

Advertisings and BLE connections are also using a lot less current than Bluetooth Mesh.

And please understand that we do in no way recommend taking out normal Bluetooth Mesh nodes like you do. Even if you would solve this issue, you will probably run into other issues eventually. I am not certain how long it would be (how much flash is used to update the sequence number block), but let us say you could do 100 reboots before it would require a cleanup of the flash (deleting old data marked as dirty). I don't know if this number (100) is feasible, but let us work with that for now. Then it means one read write cycle every 50 minutes. The flash is only rated for 10 000 erase write cycles. Total expected lifetime of flash** 500 000 minutes = about a year. 

However, if it takes 1000 reboots for a flash cleanup, then it will last 10 years. 

**We are not saying that the flash will start failing after 10 000 cycles, but we guarantee that it will work for 10 000 cycles. You will likely see a lot more under normal conditions (temperature, humidity). 

Then comes the issue about the IV updates. A node needs to pick up the IV updates to stay in the network. This happens at most every 192 hours = 8 days. So every 8 days, the device needs to stay powered on a little longer to receive these updates. A child node would get it from it's parent on wakeup, but not a full node that just disappears. This IV update is a bit complex. But the rule of thumb is that every 8 days you should make your nodes stay awake for a little longer than usual, to make sure it picks up the IV update before the process is complete (4 days). 

But again, I really think you should look into just using BLE connections or beacons (only advertising), and your current receiver can scan for these packets instead of hosting an openthread network.

Best regards,

Edvin