NRF node (sensor server) loses provisioning automatically

Question

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 · Accepted Answer

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

Edvin · Answer

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

Edvin · Answer

That looks more correct. It looks like you still have an offset. 
 For current measurement purposes, try to disable the UART (typically used for logging). Add CONFIG_SERIAL=n in your prj.conf. 
 This is what I see with a 50ms advertising interval:

Best regards, 
 Edvin

NRF node (sensor server) loses provisioning automatically

Top Replies