UARTService and Client

[AGlass0fMilk]

BLE Standard Service: No
Proposed UUID(s):

A commonly-requested service for BLE is a UARTService.

Requirements (please comment below to discuss and add yours):

• RX and TX Characteristic
• Ability to handle multiple simultaneous, separate connections
• Should also make a corresponding UARTServiceClient class for GattClients to use
• Configurable buffering to abstract away MTU limitations of BLE
• Ability to build in baremetal or with RTOS (maybe?)
• Subclass of FileHandle -- similar to BufferedSerial
• Blocking and non-blocking read/writes

A buffered GattCharacteristic class can be made to encapsulate code that can be used for other "streaming" characteristics.

See working implementation here: https://github.com/EmbeddedPlanet/ep-oc-mcu/tree/ble-uart-service

Most implementations use unreliable BLE transport mechanisms, ie: write w/o response and notifications. Another, similar class, GuaranteedUARTService can be created to use reliable BLE transport mechanisms, ie: normal write (w/ response) and indications. A corresponding GuaranteedUARTServiceClient can be also be implemented.

[idea--list]

IMHO a GuaranteedUARTService would be really useful (actually invention of BT Classic was mainly driven by this need).
Okay, here we are talking about BLE, but even with that technology people want to stream data. Also such use cases are not science fiction anymore and LE Audio is nothing else but streaming a ton of data over BLE.

With streaming people will most probably want to transfer continous sensor data with high sampling rate (eg. gyroscope data, etc.) or maybe even logfiles in which cases packet loss would render the stream almost useless...and that is why guarantee of delivery would make a huge difference.

[pan-]

@AGlass0fMilk What would be the Bluetooth target for service ? I think BT4.x using characteristics would be the most appropriates for a start as it is present everywhere. However for performance reasons, connection oriented channel would be more appropriate for data transfer. As a second step we can add CoC support in Mbed OS (there's not much to add here!) and amend the service and client to take advantage of the feature of the feature if CoC is supported.

In general, I think it would be valuable to have building blocks for data transfer that address the common concerns: Throughput, reliability, power, real time streaming, ... These building blocks could then be reused in services that requires transfer of a large amount of data (DFU, UART, ...).

@idea--list A new type of channel is used to transfer BLE audio: Isochronous channels. A good summary of the technology is available in the BT5.2 feature overview document. It seems to be well suited for that type of use cases but the current availability in silicons and stack would prevent usage on most setup.
I think it should be possible to offer a service that can be configured at run time depending on the capabilities of the devices connected:

• Baseline: GATT
• Next: CoC
• Far Future: CoIC

We also wouldn't need different classes for Reliable and Unreliable data transfer, this can be configured by the client and offer in the service.

[pan-]

Blocking and non-blocking read/writes

That one is tricky, BLE require processing and it is often made inside the main thread. It can be made with a proxy that calls into the service running with BLE in a different thread. It should be possible to verify thread IDs to provide debug information if the application is blocking from the same thread that is processing BLE.

[idea--list]

I can imagine people using this future UART service for streaming sensor data. GattService.write() can work with uint8_t payload data. This is ideal for ASCII text and numbers 0-255. However most sensors output more than 8-bit resolution, furthermore if the API would allow using int16_t payload data we would be able to reduce the amount of bytes to transfer like this:

int8_t or int16_t would allow also negative values and would make it possible to send only the delta between the current and previous sample. Imagine a wireless potentiometer as an example: the first voltage sample could have a value of 12345 the second sample would differ by +123, the third sample could have a delta of -126 to the second sample, etc. When the difference between 2 consecutive samples is not huge, we could fall back to transfer only 1 byte per sample and still interpret each sample in 16-bit resolution. While in case of huge deltas we still could transfer 2 bytes per sample.