In #14579@vcoubard mentioned that setTxPower only affects advertising but for connections it has no effect.
Somewhere else i read this is because BLE standards only mention power setting options in regard of advertising but tell no word about that in conjunction with connections. This means with Mbed APIs there is no way to increase the power for connections (meaning level would drop back to 0db once the user establishes a connection).
In addition for some boards there exists vendor specific code that also affects connection power. While that is something good, it also increases inconsistency as on other boards there is no way doing so.
IMHO the BLE standard is not interpreted right or the standard lacks common sense in this regard. Here is why:
If i need to double the range from within BLE is functioning between 2 peers, then for sure i will need to call setTxPower(6). But wait, that will have no effect for connections…
However if i need to restrict the range and call setTxPower(-6): now i have just restricted the range to half of the original distance for security reasons, goal reached i can relax at last. But wait, what if i already initialized the connection while i was still within the decreased advertising range…
Right now i think the best possible implementation would be something like this setTxPower(int dbAdv=0, int dbConn=0) Meaning one could set different power levels for advertising and connection, which would allow any combinations one just can think of. While it would also eliminate differences between boards that have vendor specific code vs boards without such.
There might be technical limitations i am not aware of (am still not mastering BLE) and can not guess how much effort would be needed to change the current implementation, but the new one would remain compatible with the current solution as the first parameter would set advertising power and the second defaults to 0db. So old user code would remain functional without any need to change user code.
Stacks and controllers implement setting TxPower differently. We used to have something similar to what you proposed, it wasn’t working uniformly in the end.
We introduced a set_tx_power function in Bluetooth driver: mbed-os/CordioHCIDriver.h at master · ARMmbed/mbed-os · GitHub . It isn’t a mandatory function and behavior is up to the driver implementer. It can be used for the WB55 for example, in that case it sets the default transmission power for both advertising and connection:
I have read several times about Cordio, but one thing is still not clear for me. How is that related to Mbed OS BLE APIs?
a) Is Cordio a second BLE solution, completely independent from Mbed’s BLE API, meaning there are 2 different possible ways to implement BLE functionality in Mbed OS
b) Or are Mbed OS BLE APIs just an abstraction of Cordio, meaning by using Mbed BLE APIs it will actually run Cordio code behind the the scene
Mbed OS BLE API used to be an abstraction over multiple Bluetooth stacks (it actually still can); one of these stack was the Cordio stack and was owned by ARM at the time.
It was difficult for vendors to provide proper Bluetooth support for their controller stack as there is about a hundred function to implement and similar abstractions can slightly change in behavior between two different stacks. Worse at the time, stack abstraction was made at a very high level and not a low level like it is today. It was making the process even more error prone.
We choose to simplify porting by capitalizing around the Cordio stack and standard Bluetooth HCI just asking vendors to provide a driver that communicates with the controller, all the heavy work being made by the Cordio host stack and its port in Mbed OS being maintained by the Mbed team.
@vcoubard
Thanks again for the clarification! Now i have a better understanding of Mbed OS’s BLE implementation.
I think it would worth to include this history into the BLE API documentation. It would take only 4-5 lines but would clarify some important details like in which direction BLE APIs evolve, and also tells we can fiddle around with Cordio building stones if we need something that is not part of the BLE APIs or find a bug.
