Power consumption when transmitting data via BROADCASTING vs NOTIFICATIONS

RE: Power consumption when transmitting data via BROADCASTING vs NOTIFICATIONS

dejans — Thu, 29 Sep 2022 13:14:05 GMT

Hi Adam,

I am glad that I was able to assist you.

Best regards,
Dejan

RE: Power consumption when transmitting data via BROADCASTING vs NOTIFICATIONS

adam_atmo — Thu, 29 Sep 2022 11:08:08 GMT

Thanks Dejan.

RE: Power consumption when transmitting data via BROADCASTING vs NOTIFICATIONS

dejans — Wed, 28 Sep 2022 14:11:36 GMT

Hi Adam,

Yes, there is no option to choose nRF52833. However, as this tool gives an estimate, the closest would be to look at the values for nRF52840.

Best regards,
Dejan

RE: Power consumption when transmitting data via BROADCASTING vs NOTIFICATIONS

adam_atmo — Tue, 27 Sep 2022 11:57:27 GMT

Hi Dejan,

Thank you. The Online Power Profiler tool doesn't provide data for the nRF52833. Is there another tool that I can use?

Kind Regards,

Adam

RE: Power consumption when transmitting data via BROADCASTING vs NOTIFICATIONS

dejans — Mon, 26 Sep 2022 08:17:54 GMT

Hi Adam,

You could have a look at Online Power Profiler tool. It allows you to measure current consumption for different chips under different Bluetooth settings, such as the role (connection or advertising). In practice, you could make comparisons for different chips using Power Profiler for Bluetooth LE.

Best regards,
Dejan

RE: Power consumption when transmitting data via BROADCASTING vs NOTIFICATIONS

adam_atmo — Mon, 26 Sep 2022 00:40:13 GMT

Hi Dejan,

[quote userid="111786" url="~/f/nordic-q-a/92215/power-consumption-when-transmitting-data-via-broadcasting-vs-notifications/387724"]Connection-oriented mode might be better suited for power efficiency[/quote]

Could you please explain why this is? Power efficiency is very important to us regarding our decision to use a connection or connectionless mode.

Regards,

Adam

RE: Power consumption when transmitting data via BROADCASTING vs NOTIFICATIONS

dejans — Fri, 23 Sep 2022 15:10:45 GMT

Hi Adam,

This was just a general remark. With periodic advertising, reliability in connectionless mode is quite good, but maybe just slightly below connection-oriented mode. Connection-oriented mode might be better suited for power efficiency and connectionless mode for scalability.

Best regards,
Dejan

RE: Power consumption when transmitting data via BROADCASTING vs NOTIFICATIONS

adam_atmo — Fri, 23 Sep 2022 00:43:15 GMT

Hi Dejan,

Thanks for the information.

[quote userid="111786" url="~/f/nordic-q-a/92215/power-consumption-when-transmitting-data-via-broadcasting-vs-notifications/387501"]Tx can potentially transmit without receiver listening which may lead to data loss.[/quote]

Surely this is also a problem with notifications during a connection since notifications are not acknowledged? How is this problem worse with a connectionless service?

Regards,

Adam

RE: Power consumption when transmitting data via BROADCASTING vs NOTIFICATIONS

dejans — Thu, 22 Sep 2022 12:52:03 GMT

Hi Adam,

There are some pros and cons to both connected and connectionless modes. From reliability perspective, it can be expected for connection-oriented service to be more reliable than connectionless service. In connectionless mode, Tx and Rx function independently. Tx can potentially transmit without receiver listening which may lead to data loss. In order to reduce potential data loss, high Rx duty cycles can be used which could cause higher power consumption. Another Bluetooth technology feature which is called periodic advertising can be used to allow advertising at specific time intervals which increases reliability in connectionless mode without compromising power efficiency. In connection-oriented communication, communication parameters are exchanged between devices and transmit power levels can be optimized dynamically. Connectionless mode allows one device to communicate with multiple other devices in one transmission without the need for communication from Rx back to Tx. Therefore, connectionless communication is highly scalable.

Best regards,
Dejan