Calculating RSSI without receiving user messages

[P Sumanth]

Hey 

I am working on Bluetooth mesh. I am able to find the RSSI from server whenever i received the message from client in mesh(light switch example). Now I have to find the RSSI for 3 seconds even without receiving any user message. I know that the RSSI can be calculated only when signal is received, but I also came to know that to order to maintain the connection in Bluetooth, link layer sends the empty messages for connection maintaining. If possible how can I calculate the RSSI for those messages. Is there any other possibility for my requirement.

I also saw that RSSI is displayed continuously in nRF connect app using the advertising data of ble devices,I need such mechanism of finding RSSI for 2 to 3 seconds, how can i achieve that?

Regards

Sumanth

[Hung Bui]

Hi Sumanth, 

I think you maybe confused between Bluetooth Low Energy and Bluetooth Mesh. They are not the same. Bluetooth Mesh doesn't have empty packets to keep the connection, there is no connection in Bluetooth mesh. 

But what you can do is to send HeartBeat packet instead. It's made for this purpose. Please have a look at section 3.6.7 in Bluetooth mesh spec v1.0 

You would need to configure the server to send heartbeat to a particular group address, and then configure other node to subscribe to that address. 

[P Sumanth]

Hey thanks and I have gone through the specs, My idea is I have two devices, one which publishes the data and other which subscribe, they should blink the led when both are out of range(ref distance), I want to do it in mesh because I have multiple publishers and one device that subscribes all publishers. I have also seen the post 

https://devzone.nordicsemi.com/f/nordic-q-a/39270/ble-mesh-heartbeat-example 

but couldn't understand the procedure, If possible explain the procedure and configuration of heartbeat messages and finding rssi?

Regards

Sumanth   

[Hung Bui]

Hi Sumanth, 

How many devices you have in the network ? What is the setup of the application ? I need to ask because if you have less than 20 devices and they are all in the range of the central device, you can think of using BLE instead of Mesh. 

Are you familiar with our mesh SDK ? 

[P Sumanth]

The number of devices will be around 40 and for now I working on 3 devices so i am choosing mesh, right now I am using nrf52 DK for the setup and i am little familiar with nrf Mesh SDK like creating custom models and looking forward to work more on mesh SDK.

Regards

Sumanth

[Hung Bui]

It's still possible to use BLE to connect a network with 40 nodes (by using multiple of BLE star network) But mesh maybe a better solution if power consumption is not your concern. 

I would suggest to study the mesh spec to have a rough idea of Heartbeat how it's configured. And then check the example to see the modification made in node_setup.c and provisioner_helper.c file that I did. 

Mainly it's about sending a configuration message to the configuration server to enable subscription and publication of heart beat. 

[P Sumanth]

I would like use BLE since we need to restrict power consumption, What will be the procedure for that.(star network) to find the distance between the connected devices .                                                                                                                                                                                                                                                                                                                                                                                  

[Hung Bui]

You would need to give us your exact application definition and requirements to be able to give you advice. You can convert this case to private if there is confidential information. 

To get the distance between connected device, you can use RSSI. But be aware that RSSI is relative and can't be used to calculate the exact distance to a node. It can be affected largely by for example if a human is stand between the devices, if there is some reflection etc.