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,

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

[AdityaN]

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

[Edvin]

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

[AdityaN]

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.

AdityaN said:

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.

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

[Edvin]

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.