nRF52 Firmware: Add delay between transmission of packets

[chipaudette]

PROBLEM: Currently the Tympan BLE firmware must maintain a delay of at least ~12 msec between each 24-byte data packet or else the remote device (phone/tablet) fails to get all the data. (Beware that the 12 msec is an approximate value obtained through anecdotal testing. Our long-standing value is 24 msec. The real answer could be 12 msec, or it could something between 12 and 24.)

CAUSE: We do not know the cause for certain. Originally, it was assumed to be the baud rate between the Tympan processor and the BLE module, but as the baud rate is 115200, a 24-byte packet (using 8-N-1 UART comms) should only require (8+1)*24 / 115200 = 1.9 msec, not 12. So, something else is causing the need for the delay. Is it some latency in my BLE firmware on the BLE module? Is it some latency in the underlying nRF firmware on the BLE module? Is it some latency in the RF comms? Is it some latency in the servicing by the remote device (phone/tablet)?

WORKAROUND: Even though we don't know why we need this delay, let's accept that we do need it. Let's move the implementation of this delay out of the Tympan BLE library and move it into the BLE module itself. This requires us to add deep buffering to the BLE module, but it will allow us to free up the Tympan module to do other work.

BLE FIRMWARE REVISION: Here are the features of the revision required to the BLE module's firmware:

• Enlarge the buffering of in-coming data from the Tympan.
  • This can be implemented either by a deeper buffer of the raw in-coming bytes
  • Or, it can be implemented as buffer of formatted ready-to-go BLE messages (whatever that means)
• Add a delay between transferring each data packet to the underlying nRF firmware
  • The default "connection interval" for iOS is slower than android, so set the default delay to 15 msec
  • We believe that the connection interval is negotiated during connection so, ideally, we'd adapt the delay to match the connection interval
• Add a SET option to the firmware to allow the user to change the value of the delay
• Add a GET option to the firmware to allow the user to query the space remaining in the deep buffer

TYMPAN BLE LIBRARY REVISION:

• For the nRF52 portion of the BLE library (not the legacy portions that support the older modules), remove the delay() statements
• For the nRF52 portion of the BLE library, add support for the new GET/SET options added above

TABLET/PHONE APP REVISIONS:

• None?

Tag @cab-creare-com , @eyuan-creare

[chipaudette]

I have an initial implementation completed, which I've started to test. I was surprised by this finding:

• After connecting to the TympanRemote app on my Android phone, I asked the nRF52840 its "connection interval" and it seems to report a connection interval of 49 msec. That's much longer than the 8-15 msec value that I had been expecting.

I had thought that we wanted to set the delay between the packets as being at least as long as the connection interval. Back when I thought that the value was 8-15 msec, our experimental finding that we needed 10-24 msec of delay made sense. But, now that I'm finding a 49 msec connection interval, why would a mere 10-24 msec of delay have worked? Clearly, we still don't understand why we needed the 10-24 msec of delay.

At the moment, I'm going to leave the BLE firmware as setting the delay to be the connection interval (plus 1 msec). The user can always override this value via a SET command from the Tympan if they want it faster.

[chipaudette]

I've modified the BLE firmware again to try to mitigate the slowness of the 49msec connection interval.

Now, upon every connection, the BLE module requests a change of the connection interval to 10 msec. When connecting to my phone, the BLE module reports that the connection interval is now 11 msec. Hooray!

I found that the change is not instantaneous (I don't know how long, but it seems to take more than 50 msec to take effect). So, I also have the BLE firmware check in on its connection interval every 250 msec. If/when it detects a change in the connection interval, the firmware self-updates the inter-packet delay time used by my TX queue. So, now, the queue delay time will follow the changes in the connection interval. Presuming that they should be related, this seems like a good thing.

As before, the user can still manually specify a delay time. If the user does this, it will disable the automatic tracking of the connection interval. The user's delay value will be used until the system reboots.

[chipaudette]

@cab-creare-com ,

With the current settings (11 msec connection interval), it takes something around 38 sec for the BLE module to transmit 50kB worth packets. That's only about 10.5 kbps. Ouch. And, yes, I already subtracted off the 4 seconds that it takes simply to get the data to the BLE module via 115200 bps 8-N-1.

Let's do the math on what we think the transmission time should be. Given the 11 msec connection interval, my firmware will employ a queue delay of 12 msec. If there's 50kB of data broken up into 24-byte packets, that'd be 2083 packets. At 12 msec delay per packet, we ought to see a minimum transmission time of about 25 seconds. That's sorta similar to my observed value of 38 seconds. But, it'd be nice to understand where the extra 13 seconds is going.

Even better, it'd be nice to radically increase the speed beyond just getting down to 25 seconds. Even 25 seconds seems much too slow. Perhaps if we could make our tiny packets bigger, we'd have fewer packets requiring our inter-packet wait time. Presumably, the size of our packets is related to the MTU setting? I don't know what our current MTU is (are we max'ing it out already?), but my additional experience with the Adafruit nRF52 library means that we could probably figure out how to manipulate this setting pretty easily.

For example, I found this Adafruit example throughput.ino. In the comments in this example, they saw speeds of 64-384 kbps, depending upon MTU settings. That'd be a 6x to 30x speed up for us. That would be nice to have!

...but as we're getting low on funding, I'm going to wait until someone says that improving throughput is critical.

[cab-creare-com]

@chipaudette Thanks for your work on this. For now, I think we're going to have to stick with the improvements you've already achieved, and we'll try to avoid sending packets any longer than necessary.

If we have the opportunity to work on this later, I'll be curious to see what is different between that Adafruit example and our current BLE communication.