Increased BLE TXPower during Repeater OTA for nRF52833 or nRF52840

[KPrivitt]

[FEATURE REQUEST] Increased BLE Transmit Strength for Repeaters using BLE during OTA #2119

The nRF52840 supports a transmit power level of up to +8dBm maximum.
// - nRF52840: -40dBm, -20dBm, -16dBm, -12dBm, -8dBm, -4dBm, 0dBm, +2dBm, +3dBm, +4dBm, +5dBm, +6dBm, +7dBm and +8dBm.

This changes the BLE Transmit power from +4dBm to +8dBm only for repeaters using an nRF52833 or nRF52840. For other devices it remains at the previous +4dBM.

BLE is normally disabled in a repeater. In OTA mode BLE is enabled to allow for the transfer of the file during the "Over the Air" firmware update. Updating a repeater using BLE OTA eliminates the need to physically connect to the repeater (bring it down, reflash and return it, which can be "risky" on a highly slanted roof). The increased power can increase the range of the BLE connection (it may be high up on your roof).

The power utilization impact of the increased transmit signal is minimal since this mode is only used during a Firmware update. A low BLE signal level can slow the speed of the data transfer, an increase in transmit signal can improve speed and the success rate of an OTA update.

[KPrivitt]

Please approve.

[oltaco]

To be clear, this would only change tx power of advertising the bootloader DFU service, the change still has to be made to the bootloader.

I have the change ready to go and I'm hoping to push a new version of the OTAFIX Bootloader this weekend.

[KPrivitt]

I will look for the new bootloader. I have updated to the UF2 Bootloader 0.9.2-OTAFIX2.1-BP1.2 for all of my repeaters except for the one up on the roof which is still at 1.14.0 and the old bootloader.

For testing should I bring down the repeater, load your new bootloader but keep the 1.14.0 version. Reinstall it up on the roof and update to 1.14.1 via OTA.

I can use the BLE Serial nRF52 tool to verify if the Power Level is now set to 8. But, as you stated this is only the advertising power level, how can I verify the transfer power level?
(there is a power "bar" that is shown during the transfer, is there a better place to verify this?)

[recrof]

For testing should I bring down the repeater, load your new bootloader but keep the 1.14.0 version. Reinstall it up on the roof and update to 1.14.1 via OTA.

you can flash the bootloader via DFU app as well - there is minimal risk, as it uses app partition to write new bootloader, crc checks it and only after that replaces old bootloader. you will then need to send repeater zip image via DFU, as it was erased by bootloader update.

[KPrivitt]

oltaco,
Is the new bootloader ready?
What is the new version number I should be looking for?

[recrof]

oltaco, Is the new bootloader ready? What is the new version number I should be looking for?

https://github.com/oltaco/Adafruit_nRF52_Bootloader_OTAFIX/releases/tag/0.9.2-OTAFIX2.2-BP1.3

[KPrivitt]

Testing Completed:

1) Loaded new bootloader (over USB through copy to attached drive)
UF2 Bootloader 0.9.2-OTAFIX2.2-BP1.3 lib/nrfx (v2.0.0) lib/tinyusb (0.12.0-145-g9775e7691) lib/uf2 (remotes/origin/configupdate-9-gadbb8c7)
Model: WisBlock RAK4631 Board
Board-ID: WisBlock-RAK4631-Board
Date: Apr 13 2026
SoftDevice: S140 6.1.1

2) With 1.14.1 467959c started OTA and verified BLE Power = 4 (-56db) with BLE Serial nRF52 iOS App

3) Generated custom compiled Firmware with PR #2214 using Visual Studio Code and installed with VSCode (USB)

4) Started OTA verified BLE Power = 8 (-39db) with BLE Serial nRF52 iOS App

5) Started and successfully completed OTA update to official release 1.14.1 ~5min.

6) With reinstalled 1.14.1 467959c started OTA and verified BLE Power = 4 (-41db) with BLE Serial nRF52 iOS App

Successful testing and verification. This is ready to start acceptance workflow.

[recrof]

there is another issue that needs to be addressed - we only want to enable 8dBm if OTAFIX 2.2 bootloader is installed. else there is big chance that user will be able to connect and switch board to BLE DFU bootloader mode, however it will be set to 4dBm, so link will degrade - that might mean inability to update the firmware.

[KPrivitt]

I'm not sure how to check for the version of the bootloader. I believe there is a CLI to get the version of the bootloader and that could be added to the conditional check that is already there. Is there someone that would know what that "variable" is to check to verify it is >= to 0.9.2-OTAFIX2.2-BP1.3? With this added then this should be ready.

One good thing is the I was able to verify that the power increase worked.

[recrof]

Is there someone that would know what that "variable" is to check to verify it is >= to 0.9.2-OTAFIX2.2-BP1.3?

I believe that @oltaco will be able to help with this.

[KPrivitt]

I found a function to get the Bootloader version in the same file NRF52Board.cpp

But I'm not sure which part of the retrieved data will indicate the current version
(I assume the current version const char* ver should be compared with the compatible version which is ??):

bool NRF52Board::getBootloaderVersion(char* out, size_t max_len) {
static const char BOOTLOADER_MARKER[] = "UF2 Bootloader ";
const uint8_t* flash = (const uint8_t*)0x000FB000; // earliest known info.txt location is 0xFB90B, latest is 0xFCC4B

for (uint32_t i = 0; i < 0x3000 - (sizeof(BOOTLOADER_MARKER) - 1); i++) {
    if (memcmp(&flash[i], BOOTLOADER_MARKER, sizeof(BOOTLOADER_MARKER) - 1) == 0) {
        const char* ver = (const char*)&flash[i + sizeof(BOOTLOADER_MARKER) - 1];
        size_t len = 0;
        while (len < max_len - 1 && ver[len] != '\0' && ver[len] != ' ' && ver[len] != '\n' && ver[len] != '\r') {
            out[len] = ver[len];
            len++;
        }
        out[len] = '\0';
        return len > 0; // bootloader string is non-empty
    }
}
return false;

}