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
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
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.
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
Hey, i took one more reading,
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.
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
