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 <[email protected]>
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
>
