Constant or Repeating BLE connection, what is best?

Projects General Guidance
1

My project requires a peripheral MCU (an nRF52840 chip) to send data streams regularly to a central Android device via BLE. This is not like a typical beacon monitor that will take a temperature measurement once every 5-30 minutes, and transmit one value for 30 seconds at a time.

Roughly speaking, for 60 seconds the MCU will sample its sensor at high frequency, sending +30kB of data for each transmission period. Then, it will pause for 60-120 seconds, before resuming the cycle of recording and transmitting.

The device will run for ~12 hours each time, resulting in +115 mB of data. The reason for the pause is to both extended battery life, and manage the amount of recorded data.

It's not clear if it's better SOP to either: (1) keep a continous BLE connection, where the MCU pauses transmission with a delay() or (2) break the BLE connection, enters a sleep period, and then reconnects each time.

The most important factor is that data is being collected. If the BLE connection goes down for >10 minutes, this would waste the whole 12 hour measurement period. Extended battery life is only a minor bonus

Additional information:

Devices will never be further apart than 3 meters, and normally will be at a distance of 1-1.5 meters, in the same room.

(1) Regarding a continous connection:

  • During transmission, current consumption is 6mA, and during the delay() it is 3mA.
  • Due to size physical constraints, a 280 mAh battery is the max. But, even a small 120 mAh battery should last more than 24 hours with these measurements.
  • The initial BLE connection will be made manually from the Android App
  • This seems like the "stablest" approach. Don't normally experience dropped BLE connections, and avoids issue with potential reconnections not working. Possible to also code in "reconnection" if lost BLE connection

(2) Regarding a repeating connection:

  • Unknown what the sleep current consumption is, but it shouldn't be >1mA.
  • With the above assumption, a 120 mAh battery should last +32 hours.
  • It seems both a risky but flexible approach. If the connection is designed to go off, but reconnect, then eventually it will reconnect even if there is an initial reconnect error...
  • I've no experience with coding "reconnection" after a disconnect, so there is a time cost
2

Don't normally experience dropped BLE connections

You will be spectacularly lucky if this happens!

My experience is with BLE sensors that transmit at a much higher rate, so we always kept a connection open since reconnecting is time consuming. But realize that even if you do this, you need to plan for the connection going down and having to automatically reconnect. Something as simple as two people standing between your sensor and the receiver could cause the connection to drop out.

Therefore, in your situation I think it would be best to make the connection, send the data and then disconnect, since you'll have to handle the loss of connection case anyway.

3

Thanks @cedarlakeinstruments. What is the appropriate way to go about reconnecting BLE, from the peripheral or the central?

I imagine from the central once it has details about the peripheral it's supposed to connect to?

4

Correct.
Never having used arduino BLE framework, I don't know how difficult this is. On most modern event-driven frameworks it's pretty simple.