You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mynewt.apache.org by Simon Ratner <si...@proxy.co> on 2016/06/09 21:53:14 UTC
Tx power is always advertised as 0dBm on nrf51
Here's some code to get started:
/* Set tx power level. */
rc = ble_phy_txpwr_set(tx_pwr_lvl); // tx_pwr_lvl == 4
if (rc != 0) {
BLEPRPH_LOG(ERROR, "error setting tx power level; rc=%d\n", rc);
return;
} else {
BLEPRPH_LOG(DEBUG, "tx_pwr_lvl=%d\n", ble_phy_txpwr_get()); // prints
'4' as expected
}
/* Set the data included in advertisement packet. */
memset(&fields, 0, sizeof(fields));
fields.tx_pwr_lvl = (uint8_t) tx_pwr_lvl;
fields.tx_pwr_lvl_is_present = 1;
/* ... */
rc = ble_gap_adv_set_fields(&fields);
if (rc != 0) {
BLEPRPH_LOG(ERROR, "error setting advertisement data; rc=%d\n", rc);
return;
}
The above doesn't seem to have an effect on the contents of the advertising
packet; it still advertises 0dBm. The comment in
https://github.com/apache/incubator-mynewt-core/blob/master/net/nimble/host/src/ble_hs_adv.c#L188
implies that this should be handled automatically, and the provided value
is ignored. Is this implemented as described, or am I doing something wrong?
The actual tx power does change, for what it's worth - I see the expected
difference in received signal between +4, 0, -12, -20.
Cheers,
simon.
Re: Tx power is always advertised as 0dBm on nrf51
Posted by Christopher Collins <cc...@apache.org>.
Hi Simon,
> In the meantime, until a full tx power API is implemented, do you think it
> makes sense to at least put the application-supplied value into the adv
> packet rather than ignoring it?
Yes, I think that is a great idea. It ought to be possible for the
application to specify a value for this field. Perhaps a good way to do
this is to have a special value for this field that instructs the host
to read the value from the controller.
Thanks,
Chris
Re: Tx power is always advertised as 0dBm on nrf51
Posted by Simon Ratner <si...@proxy.co>.
Thanks Chris, that's about what I expected when calling something prefixed
with ble_phy_ ;)
In the meantime, until a full tx power API is implemented, do you think it
makes sense to at least put the application-supplied value into the adv
packet rather than ignoring it? Here's a hacky hack I am using:
diff --git a/net/nimble/host/src/ble_gap.c b/net/nimble/host/src/ble_gap.c
index 5e5053b..6367d60 100644
--- a/net/nimble/host/src/ble_gap.c
+++ b/net/nimble/host/src/ble_gap.c
@@ -69,7 +69,7 @@
* inserted:
* o Flags (3 bytes)
* o Tx-power-level (3 bytes) - Only if the application specified a
- * tx_pwr_llvl_present value of 1 in a call to
ble_gap_set_adv_data().
+ * tx_pwr_lvl_is_present value of 1 in a call to
ble_gap_set_adv_data().
*/
#define BLE_GAP_ADV_DATA_LIMIT_PWR (BLE_HCI_MAX_ADV_DATA_LEN - 6)
#define BLE_GAP_ADV_DATA_LIMIT_NO_PWR (BLE_HCI_MAX_ADV_DATA_LEN - 3)
@@ -1355,10 +1355,12 @@ ble_gap_adv_start(uint8_t discoverable_mode,
uint8_t connectable_mode,
}
if (ble_gap_slave.adv_pwr_lvl) {
+ /* XXX
rc = ble_hci_util_read_adv_tx_pwr(&ble_gap_slave.tx_pwr_lvl);
if (rc != 0) {
goto done;
}
+ */
}
if (ble_gap_slave.conn_mode != BLE_GAP_CONN_MODE_DIR) {
@@ -1416,6 +1418,7 @@ ble_gap_adv_set_fields(struct ble_hs_adv_fields
*adv_fields)
&ble_gap_slave.adv_data_len, max_sz);
if (rc == 0) {
ble_gap_slave.adv_pwr_lvl = adv_fields->tx_pwr_lvl_is_present;
+ ble_gap_slave.tx_pwr_lvl = adv_fields->tx_pwr_lvl;
} else {
STATS_INC(ble_gap_stats, adv_set_fields_fail);
}
Cheers,
simon
On Fri, Jun 10, 2016 at 11:57 AM, Christopher Collins <cc...@apache.org>
wrote:
> Hi Simon,
>
> On Thu, Jun 09, 2016 at 02:53:14PM -0700, Simon Ratner wrote:
> [...]
> > The above doesn't seem to have an effect on the contents of the
> advertising
> > packet; it still advertises 0dBm. The comment in
> >
> https://github.com/apache/incubator-mynewt-core/blob/master/net/nimble/host/src/ble_hs_adv.c#L188
> > implies that this should be handled automatically, and the provided value
> > is ignored. Is this implemented as described, or am I doing something
> wrong?
> >
> > The actual tx power does change, for what it's worth - I see the expected
> > difference in received signal between +4, 0, -12, -20.
>
> As currently implemented, the nimble controller always indicates an
> advertising power of 0. I don't want to speak for Will who is more
> familiar with this part of the code, but I believe this is intentional,
> as the nimble link layer does not expect the transmit power to be
> changed "behind its back." Apps are not expected to make direct calls to
> the BLE drivers. Rather, the intended client is the BLE link layer.
> Since an interface into the transmit power has not been added to the
> Nimble API yet, I don't blame you for trying! I imagine that when
> a transmit power interface is added to nimble, the adverising power
> setting will get reported as configured.
>
> Chris
>
Re: Tx power is always advertised as 0dBm on nrf51
Posted by Christopher Collins <cc...@apache.org>.
Hi Simon,
On Thu, Jun 09, 2016 at 02:53:14PM -0700, Simon Ratner wrote:
[...]
> The above doesn't seem to have an effect on the contents of the advertising
> packet; it still advertises 0dBm. The comment in
> https://github.com/apache/incubator-mynewt-core/blob/master/net/nimble/host/src/ble_hs_adv.c#L188
> implies that this should be handled automatically, and the provided value
> is ignored. Is this implemented as described, or am I doing something wrong?
>
> The actual tx power does change, for what it's worth - I see the expected
> difference in received signal between +4, 0, -12, -20.
As currently implemented, the nimble controller always indicates an
advertising power of 0. I don't want to speak for Will who is more
familiar with this part of the code, but I believe this is intentional,
as the nimble link layer does not expect the transmit power to be
changed "behind its back." Apps are not expected to make direct calls to
the BLE drivers. Rather, the intended client is the BLE link layer.
Since an interface into the transmit power has not been added to the
Nimble API yet, I don't blame you for trying! I imagine that when
a transmit power interface is added to nimble, the adverising power
setting will get reported as configured.
Chris