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

[AdityaN]

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.

[Edvin]

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

[AdityaN]

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

[Edvin]

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

[AdityaN]

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);}