We have moved to a new Sailfish OS Forum. Please start new discussions there.
28

Flight mode problem with both Jolla 1 and Jolla C

asked 2016-08-10 13:04:03 +0200

N9Sailfish gravatar image

updated 2016-10-10 09:34:42 +0200

Dear All! After updating both Jolla original and Jolla C into version of 2.02.48 Aurajoki, the following problem has arisen:

When both the phones are set into Flight mode(s) overnight (7 hours), the battery drain of in order of magnitudes of 14 - 16 % over night are resulting. Earlier (with Jolla phone) the percentage of only max. 2 % was attained.

Is the previous resulting from bug or something else? Please, could you help. Have you noticed the equal error functions?

edit retag flag offensive close delete

Comments

1

My guess: perhaps you didn't re-enable LPM (low power mode) after upgrade? (http://www.jollausers.com/tag/low-power-mode/)

objectifnul ( 2016-08-10 14:51:54 +0200 )edit

Trimmed the headline a bit for clarity. Fixed the headline too. ...and added some tags. I hope that's OK.

vattuvarg ( 2016-08-10 22:08:24 +0200 )edit

Absolutely, thank you very much. (Dvs.ett nordiskt samarbete). : ) :)

N9Sailfish ( 2016-08-11 08:54:16 +0200 )edit
1

I have the same problem. Over night, my battery drops 15-25%, in flightmode. @objectifnul lpm doesnt make sense on the jolla ips screen. It will drain the Battery even faster.

HansA ( 2016-08-11 09:59:30 +0200 )edit

I'm also with the same problem.

jfebrer ( 2016-08-12 21:11:38 +0200 )edit

14 Answers

Sort by » oldest newest most voted
11

answered 2016-08-10 21:33:17 +0200

Sailor_John_Doe gravatar image

updated 2016-08-10 22:43:21 +0200

Using the app SystemDataScope I found out, that the CPU is not going to sleep mode when FlightMode is enabled (on 2.0.2.43). In contrast, without activation of FlightMode, the CPU is regularly entering sleep mode in low idle states. I'll post some SystemDataScope graphs later...

Edit: Here are the graphs:

Screenshot 1: image description

Screenshot 2: image description

Screenshot 3: image description

Screenshot 4: image description

As you can see, during night when I have FlightMode enabled, all connections are shut down (Screenshot 1). Although the CPU load is very low in the FlightMode setting, sleep mode is not entered (Screenshot 2). However, before activation of FlightMode the CPU is entering sleep mode regularly (Screenshot 2). The CPU is doing so after deactivation of the FlightMode, too (Screenshot 2). Happily, manually setting the CPU-governer to ondemand works pretty well since the CPU is mostly working at 200mhz in low idle states (Screenshot 3). Although battery current is between 20mA and 40mA in FlightMode, which is pretty low, the battery charge drops by 6% during night (Screenshot 4).

Strangely, when I arrive at work (around 6:30a.m.), where cellular signal strength is very bad (approx. 16%, see Screenshot 1), the battery current rises significantly, but the battery charge is dropping slower than during night...

edit flag offensive delete publish link more

Comments

6

That's a pretty neat app! And kudos to you for figuring this all out. I had been wondering about the fast discharge(7-9%) at night.

utkarsh ( 2016-08-11 08:24:43 +0200 )edit
1

Thank you Sailor-John-Doe. You released us from confusion and suspect.

N9Sailfish ( 2016-08-11 08:56:32 +0200 )edit
7

I believe that this is a bug in our suspend handling in msyncd, most prominently reproducible if you have an email account set up with different peak and off-peak (rush-switch) sync schedules. This should be fixed in 2.0.4.x - see https://git.merproject.org/mer-core/buteo-syncfw/merge_requests/8 for more information.

chris.adams ( 2016-08-11 09:57:34 +0200 )edit
2

Probably handling of msyncd induces a wakelock that prevents a sleep. In addition, from these graphs, its clear that all CPU cores are working (idle and frequencies sum up to 100%). This is in contrast to normal operation when they don't. In addition, when just sleep is prevented but there is not much to do, all but one CPU core should be switched off. That happens on Nexus 4 during charging, for example. In N4 during charging 3 out of 4 CPU cores are off and, as a result, reported frequency and idle state distributions sum up towards 25%. So, there is a problem preventing switching off CPU cores in J1 & JC in these conditions.

In addition, I do wonder whether ondemand is any better than interactive CPU scheduler. Have you tried to see the differences in CPU frequencies when using that scheduler?

rinigus ( 2016-08-11 10:47:22 +0200 )edit

As I wrote in my 2nd answer, the problem persists even if sync schedules are disabled and set to "manual", respectively. But you guys can try it out, too. Just download the app SystemDataScope and run some tests. Together we will solve this problem!

Sailor_John_Doe ( 2016-08-11 21:51:51 +0200 )edit
6

answered 2016-08-11 21:29:19 +0200

Sailor_John_Doe gravatar image

updated 2016-08-11 21:55:13 +0200

I performed this test with the standard cpu governor setting "interactive", too. Here are the results:

Screenshot 1: image description

Screenshot 2: image description

Screenshot 3: image description

Screenshot 4: image description

As you can see from the graphs, the situation is the same for the interactive CPU governor setting. The CPU is just not entering sleep mode when FlightMode is activated (Screenshot 2). The minimum CPU frequency in low idle states is 800mhz (Screenshot 3). The battery discharges by approx 10% in the 11p.m. to 6:30a.m. time frame. Thus, using the "ondemand" CPU governor setting saves me about 4% of battery charge during night.

Strangely, in this case the CPU was not able to enter sleep mode again after deactivation of the FlightMode around 6:00a.m. To be honest, I can't make too much sense out if this graphs... where are the linux experts?

I performed the test setting all of the sync services (Twitter, Email...) from auto to manual, too. Still the same situation. Also, instead of activating FlightMode directly I disabled the SIM card and shut down the WLAN connection. Still the same situation. No sleep mode observed during this manual FlightMode setting.

edit flag offensive delete publish link more

Comments

2

Thanks for testing it! Yes, the scheduler would not have changed entering the sleep - that's controlled differently. As told by @chris.adams this is probably a bug in syncing daemon. I presume, it does not release wakelock when you cut off the net.

I am surprised to see that interactive scheduler keeps so high CPU frequencies even on idle. I haven't read into it, maybe minimal frequency can be changed in interactive, maybe not. But surely, when comparing these configurations, ondemand makes much more sense.

What concerns me is that all your CPU cores are active during the idle time. While absence of CPU sleep could be caused by wakelocks, I would expect that only one core would be active and others switched off. Maybe its a hardware limitation on your device, maybe its another bug. To check that you could see what was summed up CPU frequency distribution while you charged. During charging CPU is not entering sleep, but on my phone 3 out of 4 cores are switched off. So, the recorded data would sum up to 25%. If you have used collectd/systemdatascope for some time, you should have this data in your history and you could just move along time axis to earlier points to see it.

Whether cores are sleeping is clearly reported by Aida64. So, you could also use that app to see whether CPU cores get switched off individually. If they are, this flight mode bug could be combination of several bugs.

rinigus ( 2016-08-11 21:48:36 +0200 )edit
2

Thank you @rinigus for your informative comment. Seems that you are actually one of those linux experts! As you can see from the graphs above, I charged my Jolla C phone during 10p.m. and 11p.m. that day. So this data is already included in the graphs above.

I'm curious about your comment concerning the summed up CPU frequencies of all cores. Where can you see this information in the graphs above? In the graph "used idle states"? I don't understand this graph, there are only three cores mentioned in the legend (c0, c1, c2), but the Jolla C phone actually has 4cores... Can you please explain that to me?

Sailor_John_Doe ( 2016-08-11 22:07:31 +0200 )edit
2

Let me start with the background and then move towards what you see. Since I don't know your background, please bear with me if info seems to be too basic.

On phones, while running in your pockets, kernel takes care of keeping the phone in suspended state for as much as it can. Its as if your laptop is suspended when you don't use it. In laptop world its usually done by user, in the phone world its done automatically. While suspended, phone can wake up automatically to process cellular, WiFi, timer, or some other data/interrupt. As soon as required processing is done, it goes to sleep again. This cycle can happen many times and in systemdatascope/collectd (sds for short) the average suspend cycle is reported under CPU sleep graph. Depending on the conditions that could range from sub-second to few minutes. Overall fraction of time spent in suspended condition is reported as CPU sleep. So, indeed, when you don't do anything with your phone and there are no inputs (flight mode), you expect this fraction to be high. Something about 95+% would be common.

Sometimes, when apps need it, automatic suspend is stopped. For that, wakelock is created and it should be released when not needed anymore. If there is a bug in a software and wakelock is not released, your phone will not enter suspend => CPU sleep would be zero. Now, it is common not to let the phone go to sleep while charging and this is done usually by acquiring wakelock. To see wakelocks, you could checkout /proc/wakelocks.

Even when not on suspended state, CPU usage is monitored and, usually, if there is no load, CPU cores are switched off one by one and leaving the core 0 as active. This is done probably differently on different platforms. On Nexus 4 and many other phones there is an extra service that switches on/off CPU cores (all except core 0).

/due to the char limitations, I'll continue in the next post/

rinigus ( 2016-08-11 23:40:44 +0200 )edit
3

/continued from prev post, part 2/

What you see in the graphs is calculated as follows. CPU frequency distribution is found using https://www.kernel.org/doc/Documentation/cpu-freq/cpufreq-stats.txt . In particular, file time_in_state is used. For each CPU core the distribution is reported separately. The reported times, for each frequency, are summed up and divided by number of CPUs. By repeating this measurement over period of time (2.5 minutes by default), its easy to see how much from the wall time (https://en.wikipedia.org/wiki/Wall-clock_time) CPU cores were in a particular frequency. SDS/collectd reports the time spent on any of the CPU frequencies as a fraction of the corresponding wall time. Now, if CPU was sleeping, the total time spent by CPU in all frequencies would be less than 100%. In addition, in the phone that does not sleep, if 3 out of 4 CPU cores would be switched off, again total CPU time spent in any of the frequencies would be 25%. This total is easy to see by following the upper edge in SDS frequency distribution graph. For example, while on flight mode, its about 100% (the imprecision maybe related to collectd plugin internals, working on it).

CPU idle is somewhat similar to CPU frequency, but reports CPU idle states. In ARM, they are frequently called as C0, C1, ... (don't confuse with core count). This seems to be some reasonable background info on CPU idle: http://www.hardwaresecrets.com/everything-you-need-to-know-about-the-cpu-c-states-power-saving-modes/ . Again, times are summed up among all cores and divided by number of cores. So, if phone is asleep, the total idle time would also go below 100%. If core is switched off, total idle should be reduced by corresponding fraction.

/ continued in the next part /

rinigus ( 2016-08-11 23:59:43 +0200 )edit
3

/continued from prev post, part 3/

Now looking on your graphs there are several strange things:

  1. During charging you observe that phone is entering sleep. This is very unusual. So far, I have always seen that the phones do not enter sleep state during charging. I suspect its a bug in software that controls charging.

  2. While doing nothing your phone is not entering the sleep. This maybe caused by wakelock, as I suspect what @chris.adams was suggesting in his reply. However, since there is no CPU activity (and the schedulers bring CPU frequency down), I would expect that 3 of 4 cores would be shut down. That's what I usually see on Nexus 4, even while the phone is in use. In your graphs, CPU frequency distribution totals to 100% - so, the cores are all on. From that I conclude that the service which is supposed to switch off cores is buggy OR your hardware does not support switching off cores one by one (doubt it though).

As to whether cores are switched on and off you could test it using aida64. Start that app, go to CPU section and follow the CPU core frequencies. If there is nothing running particularly intensively on the background, you should see cores going on and off. You could repeat the same while in flight mode or out of it. While aida64 does not make stats and record history as SDS, its an independent measurement.

So, if I am right, there maybe 3 bugs which are causing your problems (1 charging, 1 wakelock, 1 cpu core handling).

PS: Saw your graphs below and I think it covers them as well

rinigus ( 2016-08-12 00:15:54 +0200 )edit
5

answered 2016-08-12 09:15:50 +0200

HansA gravatar image

updated 2016-08-15 12:43:04 +0200

The link, https://git.merproject.org/mer-core/buteo-syncfw/merge_requests/8 which was posted by @chris.adams gave me an idea: To prevent synch from triggering, I turned flightmode on and then rebooted the device and went to bed.. The next morning: Screenshot_20160812_002.png

I lost about 1% in 6 hours. I know, this is no nice workaround, and I only tested it once, last night! Maybe some of you, that do have the same problem can verify this.

P.s.: Tested on Jolla C

Update: Last three days, it did not work :( Lost 7-10% overnight. But always the first 2-3 hours no Battery drain at all.

edit flag offensive delete publish link more

Comments

That's interesting. I'll do this tonight.

utkarsh ( 2016-08-12 12:33:18 +0200 )edit
1

The very first time I tried this my phone, Aqua Fish, lost about 3% charge in about 8 hours. Last night when I tried it again I had 100% charge on my phone. Got the phone in airplane mode, restarted it and battery showed 98%. I went to sleep, got up after 6.5 hours to find my phone at 89%. No apps running and android support switched off.

utkarsh ( 2016-08-14 09:52:22 +0200 )edit

I can confirm, that following the described reboot-procedure results in a battery decharge of about 3% in 8 hours. The phone is actually entering sleep mode, the used frequencies sum up to 4%-5%, which means that 3 out of 4 cores are fully switched off and that the remaining core is in sleep mode most of the time (approx. 98%). Not too bad, maybe this is a starting point!

Sailor_John_Doe ( 2016-08-14 15:52:51 +0200 )edit
5

answered 2016-08-20 16:18:29 +0200

rinigus gravatar image

I am posting it as an answer, to get the topic bumped up. As suggested by the recent bugfix of buteo, I compiled a new version of buteo-syncfw and installed it on Nexus 4 port of SFOS (2.0.2.48). Unfortunately, the PR by @chris.adams did not fix the lack of sleep. The locked wakelock was mce_cpu_keepalive. Please let me know, how should I debug it further. I don't know whether I can expose somehow mce wakelock sources. Maybe there is some ENV variable doing it?

My setup:

  • SFOS 2.0.2.48
  • Lack of sleep as soon as you remove the net (no cellular, no wifi)
  • Hardware: Nexus 4, CM12.1 base
  • CPU sleep monitored by collectd/systemdatascope
  • Wakelocks monitored by small python script [no keepalive]

As an alternative work around, I use custom kernel that enables CPU modes with lower MHz. That helps [probably], but is not a proper fix.

edit flag offensive delete publish link more

Comments

2

Thank you for this information. I have added it to internal bug JB#35984 and will ping Simo about the MCE stuff.

chris.adams ( 2016-08-22 13:43:45 +0200 )edit
1

@chris.adams: I'd be happy to help you to debug the issue. Is it possible its fixed in some other buteo- packages, such as sync plugins? I have stock 2.0.2.48 buteo installed, with the exception of syncfw. Are there any ENV vars or some compile switches for buteo that I could enable to see on buteo side what's locking MCE wakelock? I don't mind to recompile all buteo packages and install upstream latest versions, if you think its fixed somewhere or if its easier to debug the issue that way.

rinigus ( 2016-08-23 11:20:00 +0200 )edit

if I set flight mode and reboot, the phone is back to 2% overnight draining.

shining ( 2016-08-25 08:07:03 +0200 )edit
1

@chris.adams: ping. I have updated other packages from buteo family to check if there is any additional update that could help with unlocking mce wakelock. The list of installed buteo packages is pasted below. Unfortunately, no change. As soon as the IP network is off, the wakelock is locked after a bit of time and sleep is prevented. On that setup, I have only gmail and jolla accounts. I presume that gmail sync starts up and locks the system.

Is there any buteo compile flag which could help to debug the issue? Some verbose log option?

List of installed buteo packages:

buteo-syncfw-qt5-msyncd-0.8.6-1.armv7hl buteo-mtp-qt5-0.4.16-1.armv7hl buteo-syncml-qt5-0.5.9-1.5.4.armv7hl buteo-sync-plugins-email-0.0.16-10.7.2.jolla.armv7hl buteo-sync-plugins-qt5-0.8.23-1.17.5.armv7hl buteo-syncfw-qt5-0.8.6-1.armv7hl buteo-sync-plugin-caldav-0.1.35-1.armv7hl buteo-mtp-qt5-sync-plugin-0.4.16-1.armv7hl buteo-sync-plugin-carddav-0.0.24-1.14.1.armv7hl

rinigus ( 2016-08-27 18:12:45 +0200 )edit
2

@rinigus thanks for your help tracking this issue down, it's greatly appreciated. Please enable extra logging with msyncd by setting the environment variable MSYNCD_LOGGING_LEVEL=8, perhaps by adding it to /var/lib/environment/nemo/50-jolla-ui.conf (and note that you may also need to set /etc/systemd/journald.conf values RateLimitBurst=5000 and RateLimitInterval=5s and then reboot if you had to change those).

The journal can then be inspected for instances of the string "BackgroundSync" - see e.g. https://git.merproject.org/mer-core/buteo-syncfw/blob/master/msyncd/BackgroundSync.cpp#L107

chris.adams ( 2016-09-05 11:34:26 +0200 )edit
4

answered 2016-08-11 23:21:15 +0200

Sailor_John_Doe gravatar image

updated 2016-08-11 23:27:45 +0200

Ok this will be my last investigation of this issue (sorry for the graph spamming!): I followed the advice of the user @rinigus and monitored data during charging my Jolla C. Here are the results:

Screenshot 1: image description

Screenshot 2: image description

Screenshot 3: image description

Screenshot 4: image description

As you can see, after 30 mins of charging I activated FlightMode (Screenshot 1). What happens then is interesting: sleep mode is apparently not disabled instantaneously but rather gradually (Screenshot 2). Simultaneously, the sum of the CPU frequencies is growing towards 100% (Screenshot 3) which basically means that all cores are woken up and working. Now what could be the reason for this?

edit flag offensive delete publish link more
4

answered 2016-09-09 13:09:38 +0200

rinigus gravatar image

updated 2016-09-09 13:34:59 +0200

For those, who don't want to wait till 2.0.4: build your own buteo-sync packages. I have done it as a part of testing and this worked for me. Now the phone is sleeping while its without network.

Build is not super-easy, but possible. Unfortunately, I was not able to build using Sailfish SDK as provided at https://sailfishos.org/wiki/Application_SDK_Installation [build crashed due to gcc error?]. You would need HADK-provided image.

So, instructions:

Alternative: ask Jolla to provide packages via OBS.

2nd alternative: wait.

Good luck!

edit flag offensive delete publish link more
3

answered 2016-11-03 19:51:09 +0200

Sailor_John_Doe gravatar image

updated 2016-11-03 20:16:31 +0200

In the following I'll present to you some plots of system parameters recorded on my Jolla C running Fiskarsinjoki. According to the first plot, FlightMode is set between midnight and 6am.

image description

After one hour in FlightMode, the CPU load suddenly increases and settles at the higher level. Accordingly, CPU SleepMode is entered less often (88% vs. 96%).

image description

image description

This adversely affects the power consumption, which is very low during the first hour in FlightMode but which is steadily increasing between 1am and 6am as shown in the following plot:

image description

As a result, there is a battery discharge of about 5% between midnight and 6am.

image description

I have set my accounts' synchronisation mode to “manual”. To sum it up, there still seem to be processes running in the background causing a higher than necessary battery discharge in FlightMode. This effect gets worse over time as indicated by the steadily increasing power consumption.

edit flag offensive delete publish link more

Comments

Great work! Thank you very much. Let's hope some progress in the near-future updates. Because I'm just a happy end user, could you estimate how all the four cores influnce in for this excess power consumption? Jolla-1 has "only" two ones, that results to only 2 % battery drain over night in the flight mode.

N9Sailfish ( 2016-11-03 21:05:33 +0200 )edit

Hi, Sailor_John_Doe! One question, what does it mean ”SLEEP MODE” on the picture? MSM8909 doesn't support real-time managment of ”sleep mode”. The core sets on-line or off-line (sleep) when the phone boots on. Best regards!

Asmir ( 2016-11-03 22:03:02 +0200 )edit

@Sailor_John_Doe: It looks to me that you have an app that starts periodically waking up the phone from 01:00. This is visible from the drop of CPU sleep % and increase in a overall CPU usage (as shown by frequency distribution). There is one more stat that would confirm this suspicion: Go to CPU details/CPU sleep and take a look on number "of Suspend events per second" and "Duration of a single suspend, s". If my hypothesis is right, you should see dramatic increase in number of Suspend events and decrease in the duration from 01:00.

Notice that the used CPU frequency is low during the wakeups, so, its probably caused by some app or service that wakes the phone, sees that there is nothing to do, and lets it fall asleep again for a little bit. So, the question is now, which part of the system or app is doing it. Maybe journal can help and you could see some messages from some app there?

PS: Note that in the last version of SystemDataScope there is a new mode allowing you to generate reports for pasting them into web sites. To use it, select the time window that you want to be covered in report (Time in pulley menu) and then, when in the mode showing graphs, choose "Report" from pulley menu. That would generate all plots covered by the program and save them under Documents/SystemDataScope. You could choose plots in Gallery app (plots are shown as 'photos') or email them by selecting plots by name. As soon as you are done, go and delete the folder Documents/SystemDataScope to clean up your Gallery photos list and free the storage.

rinigus ( 2016-11-04 09:12:51 +0200 )edit

@N9Sailfish: I think that in this case, the multiple cores are switched on during wakeup. Used frequencies are reported by following amount of time spent in each state and dividing by number of cores. These numbers could be underestimated if CPU cores are switched off between the readings and Linux kernel resets the stats to zero (that's what it does on Nexus 4). In this case, sum is about 12% that looks to be very close to 100-CPUsleep(88%). This suggests that wakeup was short and during this time all CPU cores were 'boosted' to work.

@Asmir: sleep is a difference between two kernel clocks: https://github.com/rinigus/collectd/blob/sailfish/src/cpusleep.c#L53 . It should show amount of time the prone is in "suspended state".

rinigus ( 2016-11-04 09:21:32 +0200 )edit

I am also in the feeling that this same occurs without flight mode operation , too. Eg., when I left Jolla C in the operation mode of 2G + mobile connection off + A Dalvik support off: the battery drain gets 5 to10 % over night. (And also if I have 2G + internet connections on, the battery drain gets 10- 20 % over night). Thus, when I'm sleeping, my Jolla C doesn't sleep at all. :)

Why internet connection is on also with 2G on? I have read for few years ago that it usual with modern smart phones that internet connection is automatically cut off when you are moving to 2G. With especially Jolla C I have received e-mails at night if I have forgotton to cut off internet connection with 2G mobile net !

N9Sailfish ( 2016-11-04 09:24:41 +0200 )edit
1

answered 2016-08-11 09:04:34 +0200

N9Sailfish gravatar image

updated 2016-08-11 09:05:41 +0200

PS. Will this something-failure-peculiarity be officially corrected by Jolla in the update? I am not happy to add some codes everytime after I have rebooted my phone. Honestly, I may notice some failures in operation, but I am not capable in Linux programming. My history stops to Fortran 77. :)

edit flag offensive delete publish link more

Comments

6

I believe that this will be corrected in the 2.0.4.x update, see https://git.merproject.org/mer-core/buteo-syncfw/merge_requests/8

chris.adams ( 2016-08-11 09:55:31 +0200 )edit
1

answered 2016-10-06 07:54:39 +0200

N9Sailfish gravatar image

Thank you Jollla for 2.0.4.13 update. Perhaps the flight mode works perfect now, but the Situations app seems to need updating very soon. If I am right, the Situations doesn't change orders as time is changing when Jolla 1 / Jolla C are sleeping / not active. Or is the problem now with the change of the profile by Situations?? Jolla C produces 13 % battery drain and Jolla 1 over 10% over night, but I noticed that the operation modes were not changed by Situations. Just when I waked up both the displays, the Situatioin changed the operation modes related to specific time periods. I guess this is not serious, just a little updating of the Situations App?

edit flag offensive delete publish link more

Comments

Uups! I will take back the answer above this. I noticed that I have used 'Close Alien Dalvik' app from SFOS 2.02.xx version. If Situations is android-based app, so ClADlvk app prevented Situations app to work! Everything ok. I am very sorry for this!

N9Sailfish ( 2016-10-06 12:18:54 +0200 )edit

Ps. I took contact to Pastilli Labs. Yes, there are problems in Situations App with SFOS 2.04.13. Let's hope they had time to give us an update very soon. Hopefully the battery of Jolla C won't damage too much as a result relatively high electricity drain. Same was with Jolla 1 in until March 2014 before the battery drain due to TOH was fixed. Do you remember it?

N9Sailfish ( 2016-10-06 21:50:51 +0200 )edit

Took Situations off. Set Jolla C on flight mode. Result: 5 % battery drain over 9 hours. Very good. Looking forward to update for Situations as soon as it is possible.

N9Sailfish ( 2016-10-07 08:39:18 +0200 )edit
1

answered 2016-10-10 08:00:11 +0200

N9Sailfish gravatar image

updated 2016-10-10 08:07:44 +0200

Good morning again. Very bad luck indeed. The flight mode bug is continuing in a different way:

When I turn flight mode on with 2G on, everything is ok. This results to 5% battery drain over 9 hours as early written.

When I turn flight mode on with 4G, location / paikannus remains on.This results to 8% battery drain over 7 hours, respectively.

Please Jolla, could you correct this in the next step. Thank you. This is valid at least with Jolla C.

edit flag offensive delete publish link more
Login/Signup to Answer

Question tools

Follow
13 followers

Stats

Asked: 2016-08-10 13:04:03 +0200

Seen: 4,221 times

Last updated: Nov 24 '16