Consider merging txPower and rssi into pathLoss

[jyasskin]

03150ae split the pathLoss field into the primitive fields that Bluetooth exposes, in line with https://extensiblewebmanifesto.org/'s emphasis on providing the lowest level capabilities.

I think this particular field is a reasonable exception to that guideline because the only use I've heard of for these two fields is to compute the path loss as txPower - rssi. If there's no use case for the components, should we just expose the derived value, instead of making users figure out what to type?

Bluetooth exposes this information as 2 fields because they're computed in two different places: TX Power comes from the transmitting device, while RSSI comes from the receiving device.

See previous discussion at #71 (comment)

[jyasskin]

@jhedberg mentions that applications have been able to give a rough distance estimate using only RSSI when TX Power isn't available. This implies that many devices are transmitting at similar powers: maybe we can document that assumed power so people can combine lists sorted by path-loss and by just RSSI.

This either seems like a good reason to keep the fields split out, or a reason to use that assumed power in computing the pathLoss field. But we'd need to add a marker that the pathLoss is approximate, which argues more toward keeping the fields separate.

[ghost]

Sometimes the TX Power isn't placed in a standard field, but in
manufacturer data (e.g. iBeacon) - in which case you'd need the RSSI to
calculate path loss in your app after extracting the data yourself.

On Thu, Mar 19, 2015 at 12:23 PM Jeffrey Yasskin notifications@github.com
wrote:

@jhedberg https://github.com/jhedberg mentions that applications have
been able to give a rough distance estimate using only RSSI when TX
Power isn't available. This implies that many devices are transmitting at
similar powers: maybe we can document that assumed power so people can
combine lists sorted by path-loss and by just RSSI.

This either seems like a good reason to keep the fields split out, or a
reason to use that assumed power in computing the pathLoss field. But
we'd need to add a marker that the pathLoss is approximate, which argues
more toward keeping the fields separate.

—
Reply to this email directly or view it on GitHub
#76 (comment)
.

[g-ortuno]

An example of a popular devices that needs RSSI as a separate value is the UriBeacon. Including the TxPower flag in the adv packet takes up three extra bytes: one for length, one for type and one for value. The UriBeacon project decided to include the Tx Power inside Service Data to save two bytes. I can imagine other manufacturers trying to save some bytes by doing something similar.

[pzboyz]

In Section 4.3.3 of https://webbluetoothcg.github.io/web-bluetooth/ is this trying to define the data/arguments of how this device, which is hosting and running the UA is configured to send adverts or defining a type to contain the information received in an advert packet when the UA is scanning? It is not clear to me.

[jyasskin]

@pzboyz Can you file a new issue for that? It's not related to the topic of this issue.

@keybuk @g-ortuno 'k, I'm convinced. We should have 2 separate fields and make people subtract them to get the path loss.

[pzboyz]

It seemed a simple question :(

[jyasskin]

@pzboyz It's a fine question, which I should clarify in the spec. But you should ask new questions in new issues (https://github.com/WebBluetoothCG/web-bluetooth/issues/new), not just append them to whatever issue you happened to be looking at when the question came up. You can also ask pure questions on the mailing list, if you don't think they need a change to the spec: https://lists.w3.org/Archives/Public/public-web-bluetooth/