Improve consumption by UUID organisation

[Olfox]

Hi Nordic ,

My product is working fine but i'm focusing on improving consumption at maximum because it is working on small battery  ( evoluated tpms application)

It uses two sensors : a thermal camera and a second sensors for tpms( air pressure/batterie level/air temperature sensor).

I read that, by reducing UUID size from 128 to 16, it is possible to save 7times more energy each time UUID is send over the air, but it is reserved for standard services. 

 At the moment, i have 7 custom services with in total 8 customs characeterics that can deliver temperature or pressure, battery level etc...

Services (128bit) :

- Historic : contain Temperature / Pressure historic data ( 64 temperature values), read only one times with Mobile app when we open the Historic view mode 

- Secure code : used to write a secure code to enter in full secure connexion and allow setting services to be written

- Settings (50bytes) : used to write some settings value for the fw application , written after each secure connexion

- Temperature Matrix data ( 12*16 pixels = 192bytes  temperature values), only read for debug purpose, as i prefer to transmit only column average value (16 byte instead of 192) to avoid too much data on the radio.

- Temperature Matrix averaged: 16 bytes. Read in loop 10times per second, in connected mode

- Sensor2: 18 bytes. Read each second , air pressure / batterie level / air temperature sensor)

- DFU

My idea was first to create only one charac with the temperature average data + sensors 2 data and "hack" a standard uuid to reduce sized.

The charac has to contain only 16 pixel temperature +18 tms data = 34 bytes of really usefull data send each 100ms

Questions are:

1) Is all the charac and services UUID send at each connexion to allow central to list services in peripheral? 

              -> If yes, i should reduce the number of services to only keep the really usefull one).

2) Does central send UUID of the charac to be read in each read request (meaning,128bits =  10 times per second in my case?)

              -> if yes, it is a big waste of energy !  I could may be use a standart UUID that has enough data to contain my 34bytes of usefull data, right ?

3) Even if tpms value will be 9/10 the same, Is it more profitable to have all data in one charac or keep as it is at the meoment in a second charac?

            -> I'm thinking to fixed cost of header, radio switch etc... ?)

Thanks a lot for your clarifications and optimizations idea.

I don't need to interact with other mobile app or else so idee is only to increase at the  maximum power saving.

[Sigurd]

Hi,

1) Is all the charac and services UUID send at each connexion to allow central to list services in peripheral? 

No. If there is nothing to send, only an Empty PDU will be sent.

2) Does central send UUID of the charac to be read in each read request (meaning,128bits =  10 times per second in my case?)

No, it uses the  Attribute Handle, not the complete UUID.

3) Even if tpms value will be 9/10 the same, Is it more profitable to have all data in one charac or keep as it is at the meoment in a second charac?

- Temperature Matrix averaged: 16 bytes. Read in loop 10times per second, in connected mode

The value is the same 9 out 10 times? The central read this value 10 times per second? Why not just send a notification with the value when it changes?

[Olfox]

Hi Sigurd,

OK that's clear now that UUID is not send every time, but i guess just at each service discovery when it connect. so the less service and charac i have the less data will be send.

Sigurd said:

The value is the same 9 out 10 times? The central read this value 10 times per second? Why not just send a notification with the value when it changes?

The 16byte data of ircam will change each 100ms for sure.

The pressure sensor is read each second.

So we decide that mobil app read 10times per second the carac ircam, and one time per second the pressure charac.

Idea was to use only one carac with both data but i realise that it is a waste of radio on time if uuid is not send each time and only 3byte with attribute opcode and attribute handle are send during read request.

Is notification (even at 10hz) more energy efficient ? Because i guess it send notification, then receive a read request, and finally read response with data s i 'loose' 10 notifications per second instead of just let the mobile app read by it self at its interval.

[Sigurd]

The main benefit with notifications is that it's GATT server initiated, so you can send it whenever the value changes. But if you don't need all the values, then the read request is a good choice as well. I was not suggesting use both.

I think there are better ways improve power consumption in this case, e.g. take a look at the BLE connection interval you are using, if you have DCDC components on your board, enable DCDC mode, add external LF crystal to your board if you don’t have that.

You might find this blog post useful: https://devzone.nordicsemi.com/nordic/nordic-blog/b/blog/posts/optimizing-power-on-nrf52-designs

[Olfox]

Hi Sigurd, 

Thanks a lot for your help and advices. Now it is clear with UUID :) .

You are right, now i will fine tune with these parametre and check if it doesn't bring to much latency to the user exeprience.

i'm using module ( insight sip isp1907ht), 

And DCDC is enable in main.c init

I had to change my thermal camera recently, i'm facing a new " issue" that i quikly solved but not sur it is the good way to proceed.

But i created a new ticket for that :)

in case you are interrested to have a look ;)

 Communicate with sensor in timer interrupt occurs issue 

Thanks a lot again for your help, it is precious !