NRF node (sensor server) loses provisioning automatically

RE: NRF node (sensor server) loses provisioning automatically

Edvin — Tue, 06 Jun 2023 07:26:40 GMT

Have you tried setting a breakpoint inside bt_le_start_scan(), to see where it hangs?

Is there some way for me to reproduce what you are seeing?

Best regards,

Edvin

RE: NRF node (sensor server) loses provisioning automatically

AdityaN — Mon, 05 Jun 2023 13:50:05 GMT

[quote userid="26071" url="~/f/nordic-q-a/99460/nrf-node-sensor-server-loses-provisioning-automatically/429183"]What sleep mode is this? What API do you use?[/quote]

I am using

pm_device_action_run(cons, PM_DEVICE_ACTION_SUSPEND);

to put device in suspended mode.

bt_le_scan_start() returns a 0 first time and the device doesn't print anything second time. Advertising is successful because it returns a 0.

printing and Logging stops when i call bt_le_start_scan() function second time.

RE: NRF node (sensor server) loses provisioning automatically

Edvin — Mon, 05 Jun 2023 07:37:19 GMT

[quote user="AdityaN"]Then the device goes into the normal sleep mode.[/quote]

What sleep mode is this? What API do you use?

Do you see any logging? Try printing the return value of bt_le_scan_start() regardless of it's value.

Also, do you advertise? What does that return?

BR,

Edvin

RE: NRF node (sensor server) loses provisioning automatically

AdityaN — Sun, 04 Jun 2023 14:42:41 GMT

Hey Edvin,

I am facing an issue in combining the advertiser and observer sample. I am able to advertise from one node and receive on other node.

But when i add the observer to advertiser, the program stops working(I have added debug statements, these statements are not getting printed.....hence i think the program stops working until i press reset).

After publishing, I start the observer( bt_le_scan_start()) and then i stop scanning(bt_le_scan_stop()) after few mili-seconds. Then the device goes into the normal sleep mode. When the device wakes up and starts this loop again, the program stops working(after publishing, while re-starting scanner)

I am not sure what the issue is, as i am not getting any error message from scan start or stop.

Do let me know if you need anything else.

Thanks in advance

Sincerely

Aditya Nerpagar

RE: NRF node (sensor server) loses provisioning automatically

Edvin — Tue, 30 May 2023 12:54:13 GMT

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

RE: NRF node (sensor server) loses provisioning automatically

AdityaN — Sat, 27 May 2023 14:33:25 GMT

Hey, i checked it with a DK, Power consumption is very low, i can see 996uA current, I've set publish interval to be 50msecs.

RE: NRF node (sensor server) loses provisioning automatically

Edvin — Thu, 25 May 2023 12:30:29 GMT

In that case, it is difficult to say what power consumption that is drawn by the nRF. You would need to run it on a separate device (perhaps a DK), and compare the current consumption with your two approaches.

BR,

Edvin

RE: NRF node (sensor server) loses provisioning automatically

AdityaN — Thu, 25 May 2023 08:55:48 GMT

Hey,

The nRF52832 has 2 components attached to it, one is the temperature sensor and other is the power cutting ic(also some capacitors and resistors and one led). This is my complete circuit.

I am using ADC read for temperature and battery reading.

Sincerely

Aditya Nerpagar

RE: NRF node (sensor server) loses provisioning automatically

Edvin — Thu, 25 May 2023 06:17:44 GMT

What exactly are you measuring the current on? Is it only the nRF52832, or do you power other external components as well, either directly from the nRF, or from the circuit that you are measuring on? I would expect an advertising application to look a bit different. It should have a lower base current.

Best regards,

Edvin

RE: NRF node (sensor server) loses provisioning automatically

AdityaN — Wed, 24 May 2023 13:45:46 GMT

Hey, i took one more reading,

RE: NRF node (sensor server) loses provisioning automatically

Edvin — Tue, 23 May 2023 07:59:49 GMT

Can you see what the measurement looks like if you exclude the first large spike? Please zoom in on the x axis so that it is cut out. I would just like to see what the graph looks like without the 300mA spike.

RE: NRF node (sensor server) loses provisioning automatically

AdityaN — Mon, 22 May 2023 12:30:19 GMT

Hey, Thanks for your suggestion. currently i am using k_msleep() between starting advertising and stopping it.

As you know in my project, i am following the same flow as below.

[quote userid="121262" url="~/f/nordic-q-a/99460/nrf-node-sensor-server-loses-provisioning-automatically/424931"]

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.

[/quote]

This same flow was implemented on ble mesh before, It took around 182ms and consumed 7mA

Now, that this same flow is implemented on ble protocol, It takes 573ms and consumes 8.2mA

From what you said, BLE was supposed to consume less current and time. Can you help in reducing this time and current.

Let me know if you need anything else.

Thanks in advance

Aditya Nerpagar

RE: NRF node (sensor server) loses provisioning automatically

Edvin — Mon, 22 May 2023 06:50:56 GMT

Hello,

No, there is not an API for this. Just to get an understanding on how advertising and scanning works, I suggest you take a look at this blog post. Particularly this figure is relevant for your use case:

Now, regarding counting advertising packets.

Please note that the figure above is slightly simplified. Every advertising interval there is a 0-10ms random delay added, so keep that in mind.

What you can do is to calculate how long you have to advertise with the advertising interval that you are using in order to achieve the desired amount of advertising packets, and then you can stop advertising after this amount of time. You can either do so using the built-in .ble_adv_fast_timeout (in most of our samples you will see this being set using a definition called APP_ADV_DURATION, set to 180 seconds). After this the device will stop advertising, and depending on your application, go to system off (turn off), from the BLE_ADV_EVT_IDLE event in your advertising handler.

Another option is to use an app_timer to set a timeout, where you can stop the advertisements in your app_timer timeout callback.

A third option, which is probably a bit more work, but a bit more accurate. If you are only advertising, you can use something called radio notifications. This will let you know whenever the softdevice intends to use the radio. So if you are only advertising you would know that all of these events are advertising events, and you can count them, and stop advertising after the desired amount is reached. Whether this is worth it compared to using a timer is up to you. I would go with the timer, as it doesn't sound like it is a dealbreaker if you send one extra, or one too few advertisements from time to time.

Best regards,

Edvin

RE: NRF node (sensor server) loses provisioning automatically

AdityaN — Sat, 20 May 2023 12:02:16 GMT

Hey Edvin,

Thanks for your suggestion, i am now able to send and receive data from BLE device without having to connect.

I wanted to know if there is a way to count number of advertisment packet sent from a device. Is there a function that will let me know number packets advertised?

Aditya Nerpagar

RE: NRF node (sensor server) loses provisioning automatically

Edvin — Fri, 19 May 2023 08:05:23 GMT

Hello,

If it is not too late, I would recommend that you don't use the eddystone protocol, as this is deprecated. It is an overly complicated beacon format that didn't catch on. I would rather suggest that you just use a normal beacon sample as a starting point, and then, in your scanner's application you will have access to the entire advertising packet in raw format. Depending on how you added the sensor data, you should be able to extract it in a similar fashion.

To set up a beacon, you can either use the beacon example, or you can take pretty much any of the ble_perpiheral examples, such as the ble_app_uart, and just remove the services that are initialized, and make the advertisements non-connectable, and modify what data you put into your advertisement.

Best regards,

Edvin

RE: NRF node (sensor server) loses provisioning automatically

AdityaN — Wed, 17 May 2023 02:43:28 GMT

Hey,

I am able to scan the advertised packets, And i am using name to filter devices, but i am not able to get the actual data. What function should i use to extract data. I am using EDDYSTONE URL type data(I am not sure how to use EDDYSTONE-TLM).

This is all the data i am getting from packet, but what should i do to get actual URL sent.

bt_addr_le_to_str(info->addr, le_addr, sizeof(le_addr));
	printk("[DEVICE]: %s, AD evt type %u, Tx Pwr: %i, RSSI %i "
	       "Data status: %u, AD data len: %u Name: %s "
	       "C:%u S:%u D:%u SR:%u E:%u Pri PHY: %s, Sec PHY: %s, "
	       "Interval: 0x%04x (%u ms), SID: %u\n",
	       le_addr, info->adv_type, info->tx_power, info->rssi,
	       data_status, data_len, name,
	       (info->adv_props & BT_GAP_ADV_PROP_CONNECTABLE) != 0,
	       (info->adv_props & BT_GAP_ADV_PROP_SCANNABLE) != 0,
	       (info->adv_props & BT_GAP_ADV_PROP_DIRECTED) != 0,
	       (info->adv_props & BT_GAP_ADV_PROP_SCAN_RESPONSE) != 0,
	       (info->adv_props & BT_GAP_ADV_PROP_EXT_ADV) != 0,
	       phy2str(info->primary_phy), phy2str(info->secondary_phy),
	       info->interval, info->interval * 5 / 4, info->sid);}

RE: NRF node (sensor server) loses provisioning automatically

Edvin — Tue, 16 May 2023 23:15:08 GMT

Hello,

In NCS, you can look at the NCS\zephyr\samples\bluetooth\central

This example will scan, and all advertising reports will trigger the device_found() callback in main.c. Just remove the line:

err = bt_conn_le_create(addr, BT_CONN_LE_CREATE_CONN,
				BT_LE_CONN_PARAM_DEFAULT, &default_conn);

And it will no longer try to connect to that device. Also remove the call to bt_le_scan_stop(), so that it doesn't stop scanning.

Then you can set up your own filter in this callback. Look for something that you know is present in all the advertising packs (UUID, address, or something else), and fetch the relevant sensor data from these advertising packets.

Best regards,

Edvin

RE: NRF node (sensor server) loses provisioning automatically

AdityaN — Mon, 15 May 2023 13:01:10 GMT

Hey, can you let know which example should i look at for scanning beacon values without connecting on nrf board. I am able to send connectionless beacons, but i am not sure how to scan for them using an nrf board.

I am using beacon example to publish data

Thanks,

Aditya Nerpagar

RE: NRF node (sensor server) loses provisioning automatically

Edvin — Mon, 15 May 2023 10:38:51 GMT

That makes sense if you need information two ways (both from the RX node to the TX node, and from the TX node to the RX node.

Remember that advertising is not a guaranteed way of communication. That means that even if the receiver scans 100% of the time, it is not guaranteed that it will pick up a single packet. It can be lost due to noise. Also, please note that in the softdevice's scheduler, it will either schedule an entire scan window or discard it. If you intend to also advertise on the RX node, it means that it will have to discard a scan window from time to time. Therefore, I suggest you keep the scan window/intervals small (default values), so that when a scan window is dropped, it doesn't stop scanning for many seconds.

This also means that you need to keep advertising for a little while to increase the possibility for the RX node to pick up the beacon.

You can experiment a bit with the advertising and scanning settings.

Keep in mind that it is also a possibility for the RX node to actually connect to the devices if you need bi-directional communication. I am not saying that it is better. You need to experiment. The advantage of this approach is that the TX nodes only need to transmit, not scan. Scanning is a power hungry operation. Transmitting only uses the radio in short bursts.

For some actual numbers, you can play around with the Online Power Profiler.

Best regards,

Edvin

RE: NRF node (sensor server) loses provisioning automatically

AdityaN — Sat, 13 May 2023 15:21:59 GMT

Hey, Thanks for your help, I really appreciate it.

We've decided to move ahead with the BLE advertising (beacon) solution.

The transmitter node will beacon the sensor data and the receiver node will beacon some config data.

So the flow of project will be as follows,

Tx node: after waking up, will read the config beacon and then advertise the sensor data and finally the power will be cut off as before.

Rx node: this will always stay on, and will continuously advertise the config data and read the sensor data.

Please let me know what you think of it.

RE: NRF node (sensor server) loses provisioning automatically

Edvin — Thu, 11 May 2023 07:35:49 GMT

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

RE: NRF node (sensor server) loses provisioning automatically

AdityaN — Wed, 10 May 2023 15:02:34 GMT

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.

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?

RE: NRF node (sensor server) loses provisioning automatically

Edvin — Wed, 10 May 2023 13:23:09 GMT

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

RE: NRF node (sensor server) loses provisioning automatically

AdityaN — Tue, 09 May 2023 13:07:11 GMT

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?

RE: NRF node (sensor server) loses provisioning automatically

Edvin — Mon, 08 May 2023 13:44:32 GMT

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