nRF52: Better Bluetooth connection power saving

[gfwilliams]

Espruino implements some power saving on Bluetooth connections:

In 'high power' 7.5ms interval mode it draws around 600uA, but in low power 200ms mode it's 40uA

• If the connection is idle for ~2 minutes it drops into Low Power mode
• If there are two writes/reads within 2s (10 connection intervals) of each other , it enters high power mode

Code:

Espruino/targets/nrf5x/bluetooth.c

Lines 721 to 731 in 38bcf2c

	#ifdef DYNAMIC_INTERVAL_ADJUSTMENT
	if (jsble_has_peripheral_connection() &&
	!(bleStatus & BLE_DISABLE_DYNAMIC_INTERVAL) &&
	bleIdleCounter < 10) {
	// so we must have been called once before
	if (!bleHighInterval) {
	bleHighInterval = true;
	jsble_set_periph_connection_interval(BLE_DYNAMIC_INTERVAL_HIGH_RATE, BLE_DYNAMIC_INTERVAL_HIGH_RATE);
	}
	}
	bleIdleCounter = 0;

Personally I feel like this could be improved, since calling jsble_peripheral_activity twice is enough to go to a high MTU. Just a single read+write in one connection interval could do it now.

There are some specific use cases:

• When typing in the REPL we'll have a data coming in to the Bangle in small packets, in quick succession - we want to enter high speed mode when there's apprecialble lag (but the odd character or two shouldn't trigger it)
• A Puck.js might be used as a sensor/HID button. Someone presses the button and maybe a press+release event are sent - we don't want to enter high power mode for the next 2 minutes
• For Bangle.js with a Gadgetbridge connection, we send health info every 10 minutes, and also receive notifications. We'd hope that neither of those would push us into a high speed connection mode (especially using big MTUs) but I think they could be.

Maybe it makes sense to have a rolling list of connection intervals/whether they are busy or not, and then maybe if 3 of the last 5 are busy we go into high power mode? Also maybe drop back down after 1 minute?

[thyttan]

I think a somewhat relevant discussion to this was had following my (ignorant 🙄🙃) question/proposal in https://github.com/orgs/espruino/discussions/7021 .

[gfwilliams]

Thanks for the link! Past Gordon probably has a point:

So ~0.3mA in every-day use, and 0.04mA of that is BLE

So I guess for Bangle.js this probably isn't such a big deal. It might be more of an issue on the Puck.js HID example but then the people that I know that are doing it in products are using NRF.setConnectionInterval to force the interval anyway...

[thyttan]

https://codeberg.org/Freeyourgadget/Gadgetbridge/pulls/4854 may be relevant to this.

[gfwilliams]

https://codeberg.org/Freeyourgadget/Gadgetbridge/pulls/4854 may be relevant to this.

Thanks! That's interesting - hopefully Bangle.js will be fine as it's requesting rate changes itself