google / eddystone

Specification for Eddystone, an open beacon format from Google
Apache License 2.0
3.08k stars 762 forks source link

Advertised Tx Power and VARIABLE_TX_POWER #178

Closed samueleforconi closed 7 years ago

samueleforconi commented 7 years ago

Hi, the Eddystone Spec. states that a beacon could support VARIABLE_TX_POWER, so each configured slot could have its own TX_POWER. The Advertised Tx Power is defined as:

the received power at 0 meters

But this value depends on the configured Tx Power (if the beacon is configured with a Tx Power of +4dBm this value will be different from a beacon configured with a Tx Power of -20dBm).

So, when VARIABLE_TX_POWER is supported, how should be interpreted the value of the Advertised Tx Power written in the Eddystone GATT characteristic? Should it be scaled accordingly to the current slot Tx Power?

mashbridge commented 7 years ago

Ciao Samuele. Let me try to clarify.

There are two Tx powers to consider, the radio Tx and the advertised Tx, and there are characteristics to set each.

If you set the rTx, then the beacon is in charge of what value is reported for the Tx power in the UID, URL and EID frame types. If you change the rTx, the beacon continues to change the aTx reported in those frames according to its own internal calibration table.

If you set the aTx, then you are in charge of what value is reported in those frame types. Once you've set the aTx for a slot, changing the rTx will change the radio Tx power of the beacon, but won't change the value that's reported in the frame types that carry that information.

For a beacon that supports IS_VARIABLE_TX_POWER_SUPPORTED, this is true for every slot. If you set the aTx for slot[0], then from that point you have to always set it if you change the rTx for that slot. But for slot[1] you can continue to change only the rTx and rely on the beacon changing the Tx reported in the frame broadcast.

If the beacon doesn't support IS_VARIABLE_TX_POWER_SUPPORTED, then if you set the aTx for any slot, you'll always have to change it in response to changing the rTx for any slot.

Does that make more sense?

samueleforconi commented 7 years ago

Ciao Michael, thanks for your explanation.

So, the aTx is one for each slot (I haven't understand this from the Spec.). If the user sets the aTx, that exact value will be set in the UID-URL-EID adv frames otherwise the beacon will use its internal calibration values (computed on the rTx value).

The other question is, can the user revert to use the rTx (with the internal calibration) once he has set the aTx?

mashbridge commented 7 years ago

So, the aTx is one for each slot

Correct. If the beacon supports per-slot Tx configuration (radio and advertised) then you can set the active slot and then apply the radio Tx and advertised Tx to that slot. If it doesn't, then every Tx value you set on any slot will be global, since the beacon's told you that it can only broadcast at a single Tx power.

The other question is, can the user revert to use the rTx (with the internal calibration) once he has set the aTx?

There's no provision for that in the specification beyond factory reset. Once you've set the aTx, you've told the beacon you want to own it.