Speeding up reconnection after light sleep

[tapir]

I have a BLE remote control project. It acts as a server and the Android TV box is the peer. Initial pairing takes around 5-10 seconds which is pretty good. The remote is sitting idle most of the time thus I'm putting it on light sleep after 60 seconds. The problem is eventhough the MCU wakes up almost instantly, it takes at least 4-5 seconds for bluetooth connection to resume. Obviously this is very annoying for a remote control. Since I know many BLE remote controls that can have very fast wake up times (including the NVIDIA Shield Remote) I'm assuming some of the thousand parameters of NimBLE might also do the trick. Any help would be appreciated.

My BLE code is here: https://github.com/tapir/RemoteBOY/blob/main/Arduino/RemoteBOY/BLERemote.cpp and below is the simplified sleep/connect code

static const uint32_t SLEEP_TIMEOUT = 60000;
uint32_t              sleepTimer    = millis();
BLERemote             blRemote;  // above link has the implementation

void setup() {
     blRemote.setup("Test", "Test", battery.getLevel());
     // more setups
}

void loop() {
    static bool           btOnce         = false;
    static uint32_t       lastBlinkTime  = 0;
    static const uint32_t TOGGLE_DELAY   = 500;
    static const uint32_t BLINK_DELAY    = 2000;

    // power management sleep and wake-up point
    if (millis() - sleepTimer > SLEEP_TIMEOUT) {
        btOnce = false;
        blRemote.setDisconnected(); // only sets the status variable
        sleep(); // sets wake up pins and starts sleep
        wakeup(); // unsets pins
        sleepTimer = millis();
    }

    // wait until bluetooth is connected
    if (!blRemote.isConnected()) {
        if (!btOnce) {
            leds.turnOn(LED1);
            leds.turnOff(LED2);
            btOnce = true;
            lastBlinkTime  = millis();
        }
        if (millis() - lastBlinkTime > TOGGLE_DELAY) {
            leds.toggle(LED1);
            leds.toggle(LED2);
            lastBlinkTime += TOGGLE_DELAY;
        }
        return;
    }
    // bluetooth connected
    if (btOnce) {
        leds.turnOff(LED1);
        leds.turnOff(LED2);
        btOnce = false;
    }

    // Do other stuff
}

[tapir]

Interestingly if I just reset esp32 it reconnects to the latest paired device in 1-2 seconds. Still not ideal but much faster than wakeup.

[tapir]

I might be misunderstanding some things.

After looking at the interval and latency descriptions I was very excited because it looked like I was thinking about it all wrong.

My initial idea was to optimize how fast my device reconnects however the definition of latency gave me the idea that the actual trick is to make the client device think that the connection didn’t dropped/end at all.

Thus I’m now requesting a connection parameter update from the client like this

void BLEStatus::onConnect(NimBLEServer* pServer, ble_gap_conn_desc* desc) {
    Serial.println("onConnect");
    size_t numClients = NimBLEDevice::getClientListSize();
    if (numClients > 0) {
        std::list<NimBLEClient*>* clientList = NimBLEDevice::getClientList();
        for (auto it = clientList->begin(); it != clientList->end(); it++) {
            if ((*it)->isConnected()) {
                // pServer->updateConnParams((*it)->getConnId(), 16, 24, 18000, 65535);
                (*it)->updateConnParams(16, 24, 18000, 65535);
            }
        }
    }
}

According to the number’s I have used

• 16*1.25 = 20 ms min communication interval.
• 24*1.25 = 30 ms max communication interval.
• 18000 * 20 = 6 minutes minimum and 18000 * 30 = 9 minutes maximum time until client can say that the connection is no more active.
• 65535*10 = 10.9 minutes until the connection is considered completely shut off.

So I assumed, unless I’m sleeping more than 6 minutes (let’s say a timer wakes the device up and sends a packet every 3-4 minutes), whenever I wakeup the connection should be instant.

However this is not what I see. Even If I wake up instantly after sleep, the whole connection will be reset and the process will start from scratch which takes 5 seconds all-in-all to reconnect.

Any ideas?

[tapir]

After more research I've learned that absolute max timeout value is 3200 and since latency*maxInterval should be lower than timeout, the max sleep time without breaking BLE connection can be only <32s. I'm willing to work with that but whatever I do, light sleep stops bluetooth connection. Is there a way to overcome this in ESP32?

[h2zero]

Good effort here, I think you've summed it up pretty well. If you need response speed you can try rapid advertising to connect faster after wakeup. Alternatively you can try to maintain the connection and wakeup every 16 seconds or so but that would require being able to configure the connection parameters, but this is dictated by the central not the peripheral so there is no guarantee you'll get what you ask for here.

This is a good summary https://devzone.nordicsemi.com/f/nordic-q-a/10636/what-are-latency-and-supervision-timeout-limits

[tapir]

In the end I went with espnow instead of bluetooth as it's connectionless and delivers instantly after wake up.

…

On Sat, 20 Apr 2024, 17:46 h2zero, ***@***.***> wrote: Good effort here, I think you've summed it up pretty well. If you need response speed you can try rapid advertising to connect faster after wakeup. Alternatively you can try to maintain the connection and wakeup every 16 seconds or so but that would require being able to configure the connection parameters, but this is dictated by the central not the peripheral so there is no guarantee you'll get what you ask for here. This is a good summary https://devzone.nordicsemi.com/f/nordic-q-a/10636/what-are-latency-and-supervision-timeout-limits — Reply to this email directly, view it on GitHub <#656 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABWV4F4YJZCMRL5D32UL7TY6KEWTAVCNFSM6AAAAABFZ2YECKVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TCNZUHE4TG> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[h2zero]

Interesting, I guess if you didn't need a connection you could have used the BLE advertisement data as well. Glad your project is working though.