One or many characteristics for this service ?

[Gabriele]

Hi,
I have built a BLE-enabled sensor that is capable of measuring the air flow and volume passing through a pipe. A new sample is generated every 10 ms.

In the language of bluetooth, the device is a GATT server. I need to design a custom bluetooth service exposing three characteristics:
Flow (type uint16_t, mL/s units), Volume (type uint16_t, mL units), Time displacement with respect to the nominal sampling interval (type uint16_t, us units). The remote client application is proprietary.

Now, I see two different design solutions in front of me

A) use three distinct characteristics, each with its 128-bit UUID, send and send notification state callbacks
B) use only one characteristic that provides all data bundled in a structure

struct mydata_t {
  uint16_t time;
  uint16_t volume;
  uint16_t flow;
};

I think the solution B could be more attractive in term of code simplicity and data consistency of flow and volume data with respect to time, though I've been always hearing of services exposing distinct charachteristics for distinct parameters (e.g. led, button, temperature, heart rate, body temperature, ecc.). Can anybody give an advice ? What about channel utilization ? 

[Einarh]

Hello

Both approaches are valid, I think it just depends on your application.

If the client will access the data often, and access all three data points each time, then I am a fan of solution B. In addition to the reasons you mention, sending all the data in one burst would also be more energy efficient than splitting it up.

Though if your client will access the data sporadically, and if only one of the values is needed at a time, then A might work better.

Best regards,

Einar

[Gabriele]

Thank you Einar