RE: Bluetooth Mesh: Option to retrieve RSSI value from received mesh messages

Hi Brian and Inga,

Thank you for the response!

Hi Isak,

On Tue, 2022-01-25 at 19:41 +0000, Gix, Brian wrote:

quoted

Hi Isak,

On Tue, 2022-01-25 at 15:20 +0000, Isak Westin wrote:

quoted

Hi all,

In my company we are building a Bluetooth Mesh application on top of
the bluetooth-mesh daemon, using the DBUS interface.
We want to use the RSSI value of mesh messages received from
provisioned nodes as part of evaluating the general quality of a
bigger mesh network. Also, e.g. to decide which nodes should have
the relay feature enabled.
The RSSI value is delivered in the LE Advertising Reports via HCI,
but there seems to be no way to make the daemon pass this
information further to the application.

The only messages currently with RSSI propagated up to the application
are the Unprovisioned Beacons, which are used to indicate signal level
of devices seeking to be provisioned.
The RSSI measurement is really only useful for determining signal
strength of direct neighbors, or the "last hop" of a mesh path, so
from a perspective of measuring the larger quality of the mesh
network, it won't really tell you what you are looking for.

Maybe Heartbeat pub/sub mechanism would be more useful when analysing the topology of a mesh network?
Specifically, keeping track of min/max hop values received on the subscriber's side.

I correct myself: It is the signal strength of the direct neighbours only that we would like to determine.
For now in our application, we expect all nodes in the network to be direct neighbours.

We are using the Heartbeat pub/sub to determine general network quality. The idea has been to additionally use
the RSSI values of direct neighbours to simply have more information in order to make better decisions regarding relaying.
For example, it could be useful cover the (perhaps rare) cases when a node is on the edge of the maximum range
and a change in the external environment would temporarily interrupt the "direct communication". If we are unlucky,
the min/max hop values will not display the need of a relaying node in-between.
Here, the RSSI value could help to determine if a node is located at such an "unreliable range".

However, I understand that it might not really fit into the Bluetooth mesh concept and that it might not be worth an interface change.
If I'm not mistaking, the intention in the future is to use the MGMT interface to send and receive mesh packages, as well as allowing co-existance
between bluetoothd and bluetooth-meshd. Would you expect that the RSSI will be more accessible after that change?

quoted

quoted

Is there an easy way, that I have missed, to get the RSSI values for
received mesh messages? If not, what are your thoughts about making
the information available somehow, perhaps as part of the DBUS
methods MessageReceived and DevKeyMessageReceived?

A tool that measures the signal strength of each hop would require not
only DBus API changes, but also a Vender style application that
resides on each node, and collects measurements, forwarding them to a
central data collection point.  This would require controlling the
software of
*every* node in the meash network, making it impractical for an end
customer setup that has nodes from multiple manufacturers.

quoted

Thank you and best regards,
Isak

--Brian