Testing showed that the data rate for BLE notifications using our setup was less than we had originally expected, and would not likely support continuous data upload via BLE from the device. The workaround that the team decided on was to buffer data collected during the day and then bulk transfer it overnight when the wearer is not generating new data, presumably when the device is being charged and the wearer is asleep. This was deemed an acceptable change of user experience as the wearer would have needed to charge the device overnight in the original design and so adding data transfer in parallel is not deemed to degrade the user experience or the functional requirements.
This requires 2 things: a manner for detecting when the wearer has taken the device off, and code for reading from SD and sending the data over BLE.
This work was conducted in conjunction with BLE firmware integration. Originally the firmware for managing the sensors and SD card data buffering was separate from that used for the Bluetooth. We combined the BLE functionality into the code structure for the SD card, and added functionality to read buffered data from the SD card for transmission over BLE.
Data rate for BLE was a challenge. To transmit 24 bytes of data, which includes the timestamp and all the sensor readings, at the 200 Hz that it will be generated would require 38.4 kbps. BLE can send a maximum number of packets (device dependent) within a connection interval. So the smaller the connection interval the higher throughput is achievable. Android supports a minimum connection interval of 7.5ms, but the Adafruit BLE module only supports a minimum of 10 ms, so the connection was configured with a connection interval of 10 ms. The Adafruit BLE module only supports a maximum 20 B payload on notify packets. In testing, to send 400 20B packets took 9.5s, giving the average data rate of 6.7kbps, or just under 20% the required rate. This means that it would take more than 5 times longer to offload data generated during a time period than the time period itself, which is not usable even with overnight upload.
The team decided to leave the design in this state for the time being, to investigate whether data sampled at a lower frequency may be sufficient, and if not, to try and implement a manner for stopping data collection when the user is stationary, to reduce the average data collection rate during an operating period.