Which are the allowed values for txPower? > BLEDevice::setTxPower(int8_t txPower)

[joseangeljimenez]

Hello,

I am developing with the latest version of the BLE_API. So far, I have successfully created fairly complex Peripheral examples. However, I have been only partially capable of changing the TX power.

I have been trying different values for txPower,
ble_error_t BLEDevice::setTxPower(int8_t txPower)

However, so far I only could make it work for txPower = 0 (0 dBm) and txPower = 4 (dBm). I have tried some negative values with no success.

Is there any documentation on the subject?

Best regards,
Jose Angel

[rgrover]

ble_error_t BLEDevice::setTxPower(int8_t txPower) resolves to sd_ble_gap_tx_power_set().

/**@brief Set the radio's transmit power.
 *
 * @param[in] tx_power Radio transmit power in dBm (accepted values are -40, -30, -20, -16, -12, -8, -4, 0, and 4 dBm).
 *
 * @note -40 dBm will not actually give -40 dBm, but will instead be remapped to -30 dBm.
 *
 * @return @ref NRF_SUCCESS Successfully changed the transmit power.
 * @return @ref NRF_ERROR_INVALID_PARAM Invalid parameter(s) supplied.
 * @return @ref NRF_ERROR_BUSY The stack is busy, process pending events and retry.
 */
SVCALL(SD_BLE_GAP_TX_POWER_SET, uint32_t, sd_ble_gap_tx_power_set(int8_t tx_power));

do you get an error as a return value? If not, then you'll need to take this up with Nordic. devzone.nordicsemi.com

[joseangeljimenez]

Hello Rohit,

Thanks for your help. I have now finished checking all the accepted values for setTxPower / sd_ble_gap_tx_power_set(), and verified that the underlying Nordic SoftDevice is working as expected.

For all -30, -20, -16, -12, -8, -4, 0, 4 dBm, the RSSI at the Central device follows. For instance, if the RSSI at the Central device is ~-50dBm for a TX power of 4dBm, changing the TX power setting to 0dBm is seen from the Central device as a RSSI of ~-54dBm. And so on...

As a nice to have improvement to the actual BLE API documentation, I suggest to add a the range of valid input values for setTxPower().

Best regards,
Jose Angel

[rgrover]

Hi Jose,

You commented "I suggest to add a the range of valid input values for setTxPower()."
Are you suggesting that we create a separate API which can return a set of valid TxPower values (using an iterator perhaps)?

[joseangeljimenez]

Hello Rohit,

As the library currently supports only one backend (nRF51822), you could simply add a little description to the high level documentation of the BLEDevice::setTxPower() method.

However, paving the way for new backends, a simple API like the one below will do,
std::deque<int8_t> getTxPowerPermittedValues(); // C++03

Regards,
Jose Angel

---

P.S.: For those landing in this page with little C++ experience...

C++ can get tricky really fast, and something apparentrly trivial as returning an array of integer values turns out to be not so trivial,
http://stackoverflow.com/questions/4264304/how-to-return-an-array-from-a-method

My rationale,

• Under C++11 I would definitevely go with std::array.
• Under C++03 and most MCU programming circumstances, std::deque is far more predictable and efficient than std::vector in terms of heap usage, specially for low count of elements,
  http://www.cplusplus.com/reference/deque/deque/
  http://stackoverflow.com/questions/1436020/c-stl-containers-whats-the-difference-between-deque-and-list
  http://baptiste-wicht.com/posts/2012/12/cpp-benchmark-vector-list-deque.html

[rgrover]

how about keeping things really simple: return a static array--i.e. pointer
to a const int32_t and a unsigned count?

On Tue, Feb 24, 2015 at 6:08 PM, José Ángel Jiménez <
[email protected]> wrote:

Hello Rohit,

As the library currently supports only one backend (nRF51822), you could
simply add a little description to the high level documentation of the
BLEDevice::setTxPower() method.

However, paving the way for new backends, a simple API like the one below
will do,
std::deque getTxPowerPermittedValues(); // C++

Regards,

Jose Angel

P.S.: For those landing in this page with little C++ experience...

C++ can get tricky really fast, and something apparentrly trivial as
returning an array of integer values turns out to be not so trivial,

http://stackoverflow.com/questions/4264304/how-to-return-an-array-from-a-method

My rationale,

• Under C++11 I would definitevely go with std::array.
• Under C++03 and most MCU programming circumstances, std::deque is
  far more predictable and efficient than std::vector in terms of heap usage,
  specially for low count of elements,
  http://www.cplusplus.com/reference/deque/deque/
  http://stackoverflow.com/questions/1436020/c-stl-containers-whats-the-difference-between-deque-and-list
  http://baptiste-wicht.com/posts/2012/12/cpp-benchmark-vector-list-deque.html

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

[joseangeljimenez]

Absolutely yes to the C style. Simpler for this case. Sorry, I jumped straight to C++ style.

[joseangeljimenez]

The signature could be,
void getTxPowerPermittedValues(int8_t* const, size_t* const); // C style

[rgrover]

fixed in f557237