RE: Custom bluetooth profile structure advice?

MartinBL — Mon, 22 Feb 2016 15:40:48 GMT

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.