RE: BLE-UART vs dedicated service

Karl Ylvisaker — Sun, 28 May 2023 12:23:05 GMT

Hello,

[quote user=""]With a short distance like 2 meters (max), would BLE-UART be a reliable connection? Should I include CRC and packet sequence etc? Is the lower level layer of BLE already handle all of this already?[/quote]

Yes, unless you are operating in an extremely noisy 2.4 GHz environment BLE will be very reliable in this range.
You will also not need to worry about adding CRC or packet sequence numbers yourself - this is all innate features of the BLE protocol :)
The BLE protocol is lossless, which means that no data can be lost in the link - either all the data makes it across and is acknowledged by the peer, or the connection will be terminated.

[quote user=""]For a continuous data stream from the NRF52 to the phone, should I use another instance of BLE-UART (with different TX,RX address) or should I use a dedicated service characteristics with read/notification?[/quote]

All data is sent as packets in BLE, so it is not strictly 'continuous', but you can have a connection interval of as low as 7.5 ms (meaning that a packet transfer will be initiated every 7.5 ms), and you can also send multiple packets per connection interval (which essentially lets you send packets continuously, if need be), but it will still be divided into separate packets for sending, as opposed to a 'continuous stream' of data.
I dont think this should be any issue for your application since this is more an issue of 'semantics', but I thought I should mention it anyways to highlight how the BLE protocol works.

Over to your question: the use of different services and characteristics in BLE lets you separate all different 'data streams' into different containers, so that they are easily managed. In essence, a single characteristic holds a single value, and you can bundle multiple characteristics into a single service. So you should use different characteristics and services for your different 'data streams' or values. In essence, you use a separate characteristic for each sensor measurement (one for heart rate, one for temperature, one for humidity, and so on.), as an example.
In the 'Nordic UART over BLE service/characteristics' case we have made a custom service - the NUS service - which emulates a hardware UART connection though holding a byte value, so that you can feed through whatever data you would like so long as you parse it correctly on the receiving end.

Please do not hesitate to ask if anything should be unclear, or if you should have any follow-up questions! :)

Best regards,
Karl