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.
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?
Thank you and best regards,
Isak
Hi Isak,
On Tue, 2022-01-25 at 15:20 +0000, Isak Westin wrote:
> 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.
> 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.
>
> Thank you and best regards,
> Isak
>
--Brian
Hi Isak,
On Tue, 2022-01-25 at 19:41 +0000, Gix, Brian wrote:
> Hi Isak,
>
> On Tue, 2022-01-25 at 15:20 +0000, Isak Westin wrote:
> > 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.
>
> > 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.
>
> >
> > Thank you and best regards,
> > Isak
> >
>
> --Brian
Hi Brian and Inga,
Thank you for the response!
> Hi Isak,
>
> On Tue, 2022-01-25 at 19:41 +0000, Gix, Brian wrote:
> > Hi Isak,
> >
> > On Tue, 2022-01-25 at 15:20 +0000, Isak Westin wrote:
> > > 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?
>
>
> >
> > > 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.
> >
> > >
> > > Thank you and best regards,
> > > Isak
> > >
> >
> > --Brian
>
>