As an additional comments I am also looking for a way to modify the initial BLE_PROFILE_CFG structure later in the application from user input hence part of the reason for asking if bleprofile_CFGRegister() and whether this structure has good reasons for being defined as a CONST.
I will ask the developers to respond.
As they were struggling with this problem as well.
As ShawnA_01 mentioned, one would think the current draw would indeed tightly track the transmit power level. However the radio is only on for a very short period of time and without a power meter to measure the consumption at very fast intervals, you probably won't even see the increase when using a traditional ammeter.
This same issue may plague using RSSI for validation of this operation as well.
Unless these gentleman know and can share with us what they ended up trying, I will need to check around internally to see if anyone knows the best way to verify whether or not the Tx power level has changed.
I spoke to the developers/team about the concerns relayed above related to testing whether or not Tx Xmit power changes have been made and they agreed with ShawnA_01 's post related to measuring current to determine the change.
In addition, RSSI is also not effective.
Here is the feedback:
Not only that, there are two unknowns – TX power and distance. RSSI alone is not sufficient. ADV can include the TX power. Once you know the TX power and the RSSI, you can calculate the path loss and so get a fair idea about the distance (assuming free space). If there are other idems, multipath etc. then things will be incorrect. So, in general, RSSI is not very reliable
MBT is another tool we include which makes changes to the Tx power levels at the HCI layer, but it will not verify that the functions you noted in the original post are being called and the setting changed.
It seems that at this point, a spectrum analyzer may be the only means by which you can verify the change is being made.
I had another member of the team confirm with me today that in order to validate the desired change, that you need a spectrum analyzer with a peak hold setting.
As it turns out, BLE doesn’t have true power control as it uses a form of fixed power. However, the function calls themselves can enable advertising at one fixed level and connection power at another.
Advertising should be pretty easy to analyze since it’s only on 3 channels and really a tx only function.
For connections, since you’ll want to go conducted, you’ll need to use some circulators to remove the TX of the central/scanner device from the input of the spectrum analyzer, or if you can probably get away with putting a 20dB+ attenuator, on the central/scanner. That should knock it down enough to distinguish it’s TX from the peripheral.
Once you do that, just do peak hold, for the entire BW, or a specific channel, you’ll just have to wait for the hops to populate.
1 of 1 people found this helpful
I have used blecm_setTxPowerInConnection() and
verified it actually changes TX power by using BLE sniffer.
One thing to note is that blecm_setTxPowerInConnection() should be called before making connection.
It had no effect for the already active connection.
1 of 1 people found this helpful
That is the 'Golden' answer. My expectation was that I could 'dynamically' change the TX Power level after a connection was made. In observing the Tx with an Energy Meter and looking at RSSI strength I saw zero difference going from -25dBm to +4dBm but as you indicate the function is only valid if it is used 'Before' a connection is established.
Thanks for the clarification!!