Hi,
I am currently working on sensors such as EEG,ECG,PPG, & IMU.
Does BLE have any profile for respective sensors, to handle their raw data.
Thanks
Hi,
I am currently working on sensors such as EEG,ECG,PPG, & IMU.
Does BLE have any profile for respective sensors, to handle their raw data.
Thanks
Hello,
You can find the list of the assigned services in the Assigned Numbers document from Bluetooth:
Check out page 66.
I don't know exactly how these sensors work, but relevant services are at least Heart Rate Service (0x180D), and perhaps blood pressure Service (0x1810), or pulse oximeter service (0x1822)?
The format of all these services you need to look up individually. You can search for it on Bluetooth.com:
https://www.bluetooth.com/specifications/specs/?types=adopted&keyword=blood+pressure&filter=
But these are for a product. Not specifically for a sensor. And I don't think there are any standard services for an accellerometer/IMU.
So if you want to transmit the raw data from these sensors, then you need to use a custom, 128bit UUID service.
Best regards,
Edvin
Hi Edvin
I don't know exactly how these sensors work, but relevant services are at least Heart Rate Service (0x180D), and perhaps blood pressure Service (0x1810), or pulse oximeter service (0x1822)?
I guess the above mentioned profiles does some processing of the raw data, because of which I cannot use it.
So if you want to transmit the raw data from these sensors, then you need to use a custom, 128bit UUID service.
OK. Got it!
Indeed, it does a lot of processing. These standardized characteristics only holds the pulse (bpm), and some other stuff. Not raw sensor data. These are typically what is being used in smart watches.
So yes, if you want to stream raw data, you will need to use a custom service. A good place to start can be the Nordic UART Service (called peripheral_uart in NCS and ble_app_uart in nRF5 SDK). But you probably want to change the actual UUID before going to production. But for testing purposes, you can use this.
Best regards,
Edvin
Ok. Will try that!
Edvin Is there any Data streaming profile in BLE?
Hello,
No Data Streaming profiles. I am not sure if you are familiar with BLE, or Bluetooth Classic, for that matter, but the way you are talking about these profiles makes me think you are more used to something other than BLE. (I am not familiar with Bluetooth classic, by the way).
I pointed you towards the Nordic UART Service example, and the reason for it is that it is a quite versatile example. By default, it waits for a message over UART, and sends it once it either reaches a certain length, or a linefeed character. But you can easily adjust this, and just use the API for transmitting the data string that you want to send, making it independent of the UART. (I don't know what SDK you are using, so it is difficult to point to an API, so please let me know what type of SDK you intend to use).
So while it is not a "streaming profile", you can send whatever data you like. You do need to split them up in packets, but that is up to you how you want to do that. Longer packets allow for higher throughput, while shorter packets gives you lower latency.
Best regards,
Edvin
Hi Edvin
My application demands for data streaming wirelessly via BLE and has to send large amount of real-time data, that is why I want to use a streaming profile.
I am currently working with nrf connect SDK v2.6.1.
Best regards,
Pallavi
Hi Edvin
My application demands for data streaming wirelessly via BLE and has to send large amount of real-time data, that is why I want to use a streaming profile.
I am currently working with nrf connect SDK v2.6.1.
Best regards,
Pallavi
I understand,
Well, as mentioned, there is no dedicated streaming profile, but you can use the ncs\nrf\samples\bluetooth\peripheral_uart for testing. But you need to decide on the format of the data you are sending. If you need a lot of throughput, it would be beneficial to construct large packets before you send them via notifications bt_nus_send() or bt_gatt_notify_cb().
You may also need to adjust the connection parameters. How to do this is described in the Bluetooth Low Energy DevAcademy course, Lesson 3.
So longer packets means less overhead per payload byte. It does however mean added latency, so you need to experiment with what works for you.
Best regards,
Edvin
