[Tizen Application-dev] Periodic deterministic execution time without requiring a power lock

Semun Lee semun.lee at samsung.com
Fri Dec 4 00:15:04 UTC 2020


Yes, you're right that the device will not sleep.

Consider using Job scheduler API or Alarm API for periodic job in background. It will allow the device to sleep and wake up based on the schedule.


-----Original Message-----
From: Application-dev <application-dev-bounces at lists.tizen.org> On Behalf Of Luzian Scherrer
Sent: Thursday, December 3, 2020 10:37 PM
To: application-dev at lists.tizen.org
Subject: [Tizen Application-dev] Periodic deterministic execution time without requiring a power lock

Hello Tizen Developer Community,

I'm working on a Tizen Native API app for wearables and I would like to get some advice. 

The project consists of a service that is constantly running in background. It is listening and sending bluetooth data (using bt_adapter_le_start_scan() and bt_adapter_le_start_advertising_new() running constantly) and is periodically sending a few KB of data to a server using HTTPS. I call the latter a heartbeat because it is also used to determine from a centralised server if the device is still operational (battery ok, connection ok, etc). 

In order to have a deterministic heartbeat I use the following logic:

device_power_request_lock(POWER_LOCK_CPU, 0);
ecore_init()
ecore_timer_add(201, ecore_tick_wrapper, NULL);

...

Eina_Bool ecore_tick_wrapper(void *data) {
  tick();
  return ECORE_CALLBACK_RENEW;
}
...

The tick() function determines if a heartbeat is required by checking the last time is has been able to send one. Currently that is set to 10 minutes.

This is all working very well and reliably. On the recent Galaxy Watches that are running in standalone mode (ie no phone paired) and transmitting data via WiFi I get around 20 to 25 hours of battery lifetime using that method. The problem arises when I run the software on LTE models. On the LTE models, battery lifetime drops drastically down to only 10 hours using the very same logic. To my current understanding this is because the device is not going into sleep mode.

I am currently thinking about the following strategies:

A) Omitting the device_power_request_lock(POWER_LOCK_CPU, 0) with the downside of not having a deterministic tick() anymore. It is not required to happen exactly every X seconds, but I need to be certain that it happens at least at interval Y. Y should not be lower than one hour.

B) Bind the tick() to some kind of event/callback that is happening periodically, preferably at a time when the device is awake and ready to send network data anyway.

C) Instead of triggering the tick() on the devices, use the Push API to trigger it from the server. The downside of this is that it requires a more complex infrastructure.

My question is: which approach would you recommend? Is it one of the three mentioned above or are there other good strategies for this problem? Or am I following the wrong lead because the bluetooth scanning and advertising prevents the sleep mode anyway?

Thank you very much!
-Luzian


_______________________________________________
Application-dev mailing list
Application-dev at lists.tizen.org
https://protect2.fireeye.com/v1/url?k=56243804-09bf0108-5625b34b-000babff3563-eee3e6050d2ed1da&q=1&e=bfa7c9c1-820a-4fa3-ae44-d0dcbb9fd69c&u=https%3A%2F%2Flists.tizen.org%2Flistinfo%2Fapplication-dev



More information about the Application-dev mailing list