Custom bluetooth profile structure advice?

[Sensors]

I've been thinking recently about how to structure the custom profile for some hardware I'm developing, which has a a few sensor components and a button onboard.

What I'd like to have in terms of functionality is this:

• Read data from 4 different sensors
• Set up the ability for each sensor to create a smartphone alert
• Configure the sensor thresholds (or range) which trigger the alerts
• Configure the sensor sample rates
• activate/deactivate sensors if not used to save power

I'm not totally sure what way to go about structuring this, despite having read through the tutorials on custom characteristics and services.

I think there may be two options, but please let me know if there is a better way to go about it:

1. Separate into services based on action: A data service, a configuration service, and an alert service

• Data service: holds characteristics containing data from each sensor
• Config service: Holds configuration characteristics that can be set for each sensor
• Alert service: Holds alert notification characteristics to generate alerts preset by config service

2. Services based on sensor

• A service for each sensor, containing a data characteristic, a config characteristic, and an alert notification characteristic
• This would assume I could store multiple pieces of data under one charactersistic.

Which, if either, of these is the best approach? are there other ways? and are there things I'm not considering?

[MartinBL]

Hi

I don't think there is a definite answer to this. I guess it is mostly up to you and what you think will provide the cleanest implementation on both client and server side. However, three factors come to mind:

Power: To save power you would want to separate your characteristics and services in such a way that you don't transmit any unnecessary data. For example, your configuration characteristic is probably rarely read and written, but the sensor data might be read frequently. Hence, you don't want to bundle configuration and sensor values in the same characteristic (it doesn't sound like you plan to do this anyway, but just as an example). A different example would be if sensor 1 updates once every minute, but sensor 2 updates every 10 ms. To save power you don't want to put these values in the same characteristic and hence transmit the same value from sensor 1 600 times.

Bandwidth: Bandwidth and power consumption can be two opposing forces. You often need to chose one or the other or a middle way. If, for example, you need to transmit all sensor values frequently it might be wise to bundle them together. This way you will avoid some overhead. I.e. if you have one value characteristic for each of your four sensors you will have to prepare and process four different transmissions. If you bundle all four values together you only need to prepare and process one packet. Although the packet will be slightly longer you will save a lot of overhead and the total airtime will be shorter (Bundling like this might actually save you some power as well).

Code size: Lots of services will take up more space in memory than a few well structured services, even though they contain the same amount of data.