Alright so I've been tweaking my cpu using setcpu. So far I've been forcing it to run on each stepping while i drop the voltage 25mV at a time. I've got both the 200 and 500 running at 850mV no problem. The problem occurred when after i set my 800Hz stepping 850 mV and then returned my min back to 200mhz. It locks up every time. 800mhz runs fine on its own @850mV but not with other steppings. I've been told before that big jumps in voltage between steppings can lead to instability but i have all three at 850mV. I was just wondering if anyone m ew why. Also if i force it to run only one frequency will it still go into deep sleep? Thanks
So I assume that the battery drain from leaving on NFC 24/7 is probably pretty small since it's not transmitting constantly... similar to leaving on bluetooth all day vs. actually being connected to something all day.
My question is this...
Suppose I have an NFC tag on my desk, and rather than just tapping my phone on it, I place the phone on it and leave it there. How will the phone/tag react in this situation and what are the battery implications of doing this? I assume that the phone will be smart enough to not repeatedly execute whatever that tag's action is, but I'm really curious how the two communicate when they are left in constant contact. Will the phone constantly receive (and dismiss) this NFC tag until they're moved apart? I feel like this constant "seeing" would drain the hell out of my battery, since it's actually engaging the NFC (like the bluetooth example above)? Maybe it acts exactly like that, but doesn't drain as much battery as I think? Maybe it doesn't act like that at all? That's what I'm trying to find out.
This is important because I'd like to stick a tag on the back of my car dock, and this would create a similar situation where the tag and phone would be left in constant contact. If anybody knows how this technology works, please let me know.
I want to do the same thing. I have modified my phone to use a TouchStone and I have a base at work, home and car and I want(when they come in) a NFC tag on each so that my phone knows which location I am at instead of using my GPS location. Mainly for changing things through Locale like bluetooth and volume. While my phone will be on the charger, I wonder how much power draw there will be.
ericlmccormick said:
I want to do the same thing. I have modified my phone to use a TouchStone and I have a base at work, home and car and I want(when they come in) a NFC tag on each so that my phone knows which location I am at instead of using my GPS location. Mainly for changing things through Locale like bluetooth and volume. While my phone will be on the charger, I wonder how much power draw there will be.
Click to expand...
Click to collapse
Hopefully somebody that is more knowledgeable about the technology itself will be able to answer.
demarcmj said:
Hopefully somebody that is more knowledgeable about the technology itself will be able to answer.
Click to expand...
Click to collapse
AFAICT, a passive NFC tag is only powered by your phone's NFC RF field for the few hundred milliseconds that it's either being read or written, and that's 15mA.
I'd bet $100 that even if you took a tag and swiped it all day that it'd barely put a dent in the battery life, but, that's an experiment I'll leave to someone else.
(If NFC was a hog, it'd be bigger news.)
UPDATE: According to the folks in this thread, NFC is off when the screen is off.
So for my desk example, it probably wouldn't be a problem. In that case, the screen will go off after a while, and you'll probably pick it up again when you want to turn the screen back on.
But for my car dock scenario, it's a little different. First, I might have the screen on longer, which means that I still want to know about the battery drain when the two are kept in constant contact with the screen on. Second, if the screen goes off, I probably won't be moving the phone to turn the screen back on (it's secured in the dock)... so every time I turn the screen on, will it read the tag and execute the task?
EDIT: Ok so this post came in as I was typing...
zmore said:
AFAICT, a passive NFC tag is only powered by your phone's NFC RF field for the few hundred milliseconds that it's either being read or written, and that's 15mA.
I'd bet $100 that even if you took a tag and swiped it all day that it'd barely put a dent in the battery life, but, that's an experiment I'll leave to someone else.
(If NFC was a hog, it'd be bigger news.)
Click to expand...
Click to collapse
So if it only reads for the first couple hundred milliseconds, then the constant contact issue wouldn't be a factor.
But what about the turning the screen off and then on again while still in contact with the tag? How will that one go down? (note, this isn't a battery question... this is something someone can actually verify)
demarcmj said:
But what about the turning the screen off and then on again while still in contact with the tag? How will that one go down? (note, this isn't a battery question... this is something someone can actually verify)
Click to expand...
Click to collapse
After turning the screen on (and unlocking it) ... the tag will be scanned again ....
and for the battery drain ... i had a look at the logs on my international gs3 while taped to a tag ...a lot of log messages and probably cpu activity while taped to a tag, repeated approx. every 150 milliseconds ...
Have a look --> this is just 1 second in the log .... and it´s repeated as long as the tag is taped to the device ...
Code:
07-12 02:47:25.057: D/NFC_LIST(10575): Allocated node: 0x1702e60 (0x5d5efbf4)
07-12 02:47:25.057: D/NFC JNI(10575): phLibNfc_RemoteDev_CheckPresence()
07-12 02:47:25.057: D/NFC JNI(10575): phLibNfc_RemoteDev_CheckPresence() returned 0x000d[NFCSTATUS_PENDING]
07-12 02:47:25.067: D/NFC JNI(10575): Callback: nfc_jni_presencecheck_callback() - status=0x0000[NFCSTATUS_SUCCESS]
07-12 02:47:25.067: D/NFC_LIST(10575): Deallocating node: 0x1702e60 (0x5d5efbf4)
07-12 02:47:25.192: D/NFC_LIST(10575): Allocated node: 0x17c6f28 (0x5d5efbf4)
07-12 02:47:25.192: D/NFC JNI(10575): phLibNfc_RemoteDev_CheckPresence()
07-12 02:47:25.192: D/NFC JNI(10575): phLibNfc_RemoteDev_CheckPresence() returned 0x000d[NFCSTATUS_PENDING]
07-12 02:47:25.202: D/NFC JNI(10575): Callback: nfc_jni_presencecheck_callback() - status=0x0000[NFCSTATUS_SUCCESS]
07-12 02:47:25.202: D/NFC_LIST(10575): Deallocating node: 0x17c6f28 (0x5d5efbf4)
07-12 02:47:25.332: D/NFC_LIST(10575): Allocated node: 0x1702e60 (0x5d5efbf4)
07-12 02:47:25.332: D/NFC JNI(10575): phLibNfc_RemoteDev_CheckPresence()
07-12 02:47:25.332: D/NFC JNI(10575): phLibNfc_RemoteDev_CheckPresence() returned 0x000d[NFCSTATUS_PENDING]
07-12 02:47:25.342: D/NFC JNI(10575): Callback: nfc_jni_presencecheck_callback() - status=0x0000[NFCSTATUS_SUCCESS]
07-12 02:47:25.342: D/NFC_LIST(10575): Deallocating node: 0x1702e60 (0x5d5efbf4)
07-12 02:47:25.467: D/NFC_LIST(10575): Allocated node: 0x17c6f28 (0x5d5efbf4)
07-12 02:47:25.467: D/NFC JNI(10575): phLibNfc_RemoteDev_CheckPresence()
07-12 02:47:25.467: D/NFC JNI(10575): phLibNfc_RemoteDev_CheckPresence() returned 0x000d[NFCSTATUS_PENDING]
07-12 02:47:25.477: D/NFC JNI(10575): Callback: nfc_jni_presencecheck_callback() - status=0x0000[NFCSTATUS_SUCCESS]
07-12 02:47:25.477: D/NFC_LIST(10575): Deallocating node: 0x17c6f28 (0x5d5efbf4)
07-12 02:47:25.607: D/NFC_LIST(10575): Allocated node: 0x1702e60 (0x5d5efbf4)
07-12 02:47:25.607: D/NFC JNI(10575): phLibNfc_RemoteDev_CheckPresence()
07-12 02:47:25.607: D/NFC JNI(10575): phLibNfc_RemoteDev_CheckPresence() returned 0x000d[NFCSTATUS_PENDING]
07-12 02:47:25.612: D/NFC JNI(10575): Callback: nfc_jni_presencecheck_callback() - status=0x0000[NFCSTATUS_SUCCESS]
07-12 02:47:25.612: D/NFC_LIST(10575): Deallocating node: 0x1702e60 (0x5d5efbf4)
07-12 02:47:25.672: D/KeyguardViewMediator(2098): handleTimeout
07-12 02:47:25.742: D/NFC_LIST(10575): Allocated node: 0x17c6f28 (0x5d5efbf4)
07-12 02:47:25.742: D/NFC JNI(10575): phLibNfc_RemoteDev_CheckPresence()
07-12 02:47:25.742: D/NFC JNI(10575): phLibNfc_RemoteDev_CheckPresence() returned 0x000d[NFCSTATUS_PENDING]
07-12 02:47:25.747: D/NFC JNI(10575): Callback: nfc_jni_presencecheck_callback() - status=0x0000[NFCSTATUS_SUCCESS]
07-12 02:47:25.752: D/NFC_LIST(10575): Deallocating node: 0x17c6f28 (0x5d5efbf4)
07-12 02:47:25.877: D/NFC_LIST(10575): Allocated node: 0x1702e60 (0x5d5efbf4)
07-12 02:47:25.877: D/NFC JNI(10575): phLibNfc_RemoteDev_CheckPresence()
07-12 02:47:25.877: D/NFC JNI(10575): phLibNfc_RemoteDev_CheckPresence() returned 0x000d[NFCSTATUS_PENDING]
07-12 02:47:25.887: D/NFC JNI(10575): Callback: nfc_jni_presencecheck_callback() - status=0x0000[NFCSTATUS_SUCCESS]
07-12 02:47:25.887: D/NFC_LIST(10575): Deallocating node: 0x1702e60 (0x5d5efbf4)
EDIT: Don´t get me wrong, having NFC enabled, usually doesn´t make a relevant difference for your battery life ... but keeping a tag permanently attached, seems to have a much higher impact ...
Today I was sick and I decided the spend the day testing the phone. This configuration is great for battery life and stable
For cpu
1200000 1175
1100000 1125
1000000 1075
900000 1025
800000 975
700000 950
600000 950
500000 950
400000 900
300000 850
200000 825
100000 800
According to the tests I've done 86% of the time, cpu is below 600MHz state. Also I've decided to insert the 100mhz. It works great without any problems and we can save up a bunch of juice, near - 150mv.
Would recommend you guys leave the 500mhz till 800MHz as is. Or it'll freeze the phone.
Any thoughts? Wanna know your opinion.
The Gpu cannot be undervolted the limit is 1000mv for 200mhz and 267mhz.
160mhz I would love to test with 925mv
100MHz is 900mv
64mhz us 850mv
The only thing we can do to make sure it'll conserve battery is to raise the percentage before he raises frequency. I've decided to make near 85% to raise and 75% to decrease with 5 steps. Seems to be A OK.
Wanna know opinions. Phone is working great for hours with gaming etc. Please let me know your opinion
Sent from my GT-I9100 using Tapatalk 2
Hi,
I ran some basic tests with some benchmarks and also use ROM Toolbox to look at CPU min/max frequency.
I can confirm that running things like AnTuTU and Vellamo cause the device to heat up and cap CPU speed at about 1.5 GHz.
This means that unless your device is sitting in a freezer it will throttle when running all out.
There are some files that look to control this behavior in /system/etc/
thermal-engine.conf
thermal-engine-8974.conf
thermal-engine-8974-default.conf
and finally thermald.conf which is a brokent sym link.
Anyone ever play with these?
I'm sure a great kernel Dev will fix us up soon
tech_head said:
Hi,
I ran some basic tests with some benchmarks and also use ROM Toolbox to look at CPU min/max frequency.
I can confirm that running things like AnTuTU and Vellamo cause the device to heat up and cap CPU speed at about 1.5 GHz.
This means that unless your device is sitting in a freezer it will throttle when running all out.
There are some files that look to control this behavior in /system/etc/
thermal-engine.conf
thermal-engine-8974.conf
thermal-engine-8974-default.conf
and finally thermald.conf which is a brokent sym link.
Anyone ever play with these?
Click to expand...
Click to collapse
The only one you need to play with is thermal-engine-8974.conf. Two of the others are sym links (one broken) and the other seems to hold values for shutting the phone down due to high cpu temps (115 Celsius), although these values are also in thermal-engine-8974.conf with slightly different values. It seems there is a lot of different types of throttling involved on this phone by looking at this file.
Although I don't know all the details, it seems threshold is the temp in Celsius (multiplied by 10000 under batt_therm_monitor, multiplied by 1000 in all other places) that the throttling takes place. Thresholds_clr seems to be where that throttling stops when the temp cools. Some categories have multiple levels of throttling. CPU_LCD_management has 6.
Changing these two values does work. You have to reboot after any changes you make for them to take effect. I have increased the memory speed throttle and the individual cpu throttle temps by 5 degrees (5000) on both the thresholds and thresholds_clr. I have increased all other thresholds and thresholds_clr by 10 degrees. I did not mess with the shutdown temps.
I should also note that I did try disabling thermal throttling entirely via the hidden menu and the phone would shutdown due to overheat during any benchmarks (thank goodness!). So this is why I decided to tweak these settings, since disabling it entirely seems to be a bad idea. Benchmarks are slightly higher and no shutdowns. Phone does get noticeably hotter.
This is what my thermal-engine-8974.conf looks like after modifying:
sampling 5000
c_mode 3
[CPU_LCD_management]
algo_type monitor
sensor xo_therm_pu2
sampling 10000
thresholds 55000 57000 59000 61000 63000 65000
thresholds_clr 54000 55500 57500 59500 61500 63500
actions cpu+lcd cpu+lcd cpu+lcd cpu+lcd cpu+lcd cpu+lcd
action_info FFFFFFF+255 1958400+255 1574400+245 1497600+235 1497600+225 1267200+225
action_type 25000
[GPU_management]
algo_type monitor
sensor xo_therm_pu2
sampling 10000
thresholds 59000
thresholds_clr 53000
actions gpu
action_info 330000000
action_type 25000
[battery_monitor]
algo_type monitor
sensor xo_batt
sampling 10000
thresholds 57000 58000 59000 60000 61000
thresholds_clr 56000 57000 58000 59000 60000
actions battery battery battery battery battery
action_info 1024 768 512 410 307
[iusb_monitor]
algo_type monitor
sensor xo_batt
sampling 10000
thresholds 57000 60000
thresholds_clr 55000 57500
actions iusb iusb
action_info 1500 1000
[wlchg_monitor]
algo_type monitor
sensor xo_therm_pu2
sampling 10000
thresholds 62000
thresholds_clr 60000
actions wlchg
action_info 512
[batt_therm_monitor]
algo_type monitor
sensor batt_therm
sampling 10000
thresholds 660000
thresholds_clr 620000
actions lcd
action_info 93
[CPU0_MONITOR]
algo_type monitor
sensor cpu0
sampling 65
thresholds 120000
thresholds_clr 115000
actions shutdown
action_info 0
[CPU1_MONITOR]
algo_type monitor
sensor cpu1
sampling 65
thresholds 120000
thresholds_clr 115000
actions shutdown
action_info 0
[CPU2_MONITOR]
algo_type monitor
sensor cpu2
sampling 65
thresholds 120000
thresholds_clr 115000
actions shutdown
action_info 0
[CPU3_MONITOR]
algo_type monitor
sensor cpu3
sampling 65
thresholds 120000
thresholds_clr 115000
actions shutdown
action_info 0
[SS-CPU0]
algo_type ss
sampling 65
sensor cpu0
device cpu
set_point 90000
set_point_clr 60000
action_type 10000
[SS-CPU1]
algo_type ss
sampling 65
sensor cpu1
device cpu
set_point 90000
set_point_clr 60000
action_type 10000
[SS-CPU2]
algo_type ss
sampling 65
sensor cpu2
device cpu
set_point 90000
set_point_clr 60000
action_type 10000
[SS-CPU3]
algo_type ss
sampling 65
sensor cpu3
device cpu
set_point 90000
set_point_clr 60000
action_type 10000
[SS-POPMEM]
algo_type ss
sampling 65
sensor pop_mem
device cpu
set_point 85000
set_point_clr 60000
time_constant 16
action_type 20000
I figured it out, but thanks.
I tweaked mine a bit different but it still works like yours does.
No throttling during benchmarks.
tech_head said:
I figured it out, but thanks.
I tweaked mine a bit different but it still works like yours does.
No throttling during benchmarks.
Click to expand...
Click to collapse
I've made a mod that tweaks the throttling you can check it out here
http://forum.xda-developers.com/lg-g3/development/thermal-mod-t2907363
For those of you using the modified thermal-engine-8996.conf files in this forum, I would recommend using these three specifications under the [KYRO_SS] area: (keep everything else the same)
set_point 49500
set_point_clr 45500
device_perf_floor 1324800
set_point determines a threshold for thermal throttling
set_point_clr determines when to stop thermal throttling
They don't equate exactly to the degrees in celsius for the CPU or battery, so I'm not sure exactly what the translation is. However, I found that this was a pretty good threshold to use to reduce the thermal throttling on the CPU.
By setting the device_perf_floor metric to a lower number, I could also make sure that thermal throttling DID happen when it was needed. This helped a lot to reduce the chances of my phone from overheating and shutting down during a hot summer day.
Hope this helps somebody! This really saved my phone.
this is the two i modified
p.s. do not go higher than 1824000... it went so hot my first Lgv20 screen got unglued from the case lol. now is working fine with my second lg v20 with below config
KRYO_SS]
algo_type ss
sensor skin_ap
sampling 5000
device cpu_voltage
set_point 40000
set_point_clr 38500
device_perf_floor 1824000
[GPU_MONITOR]
algo_type monitor
sensor vts
sampling 5000
thresholds 38000 39500 41000 42500
thresholds_clr 37000 38500 40000 41500
actions gpu gpu gpu gpu
action_info 642000000 560000000 510000000 401000000
paul999 said:
this is the two i modified
p.s. do not go higher than 1824000... it went so hot my first Lgv20 screen got unglued from the case lol. now is working fine with my second lg v20 with below config
KRYO_SS]
algo_type ss
sensor skin_ap
sampling 5000
device cpu_voltage
set_point 40000
set_point_clr 38500
device_perf_floor 1824000
[GPU_MONITOR]
algo_type monitor
sensor vts
sampling 5000
thresholds 38000 39500 41000 42500
thresholds_clr 37000 38500 40000 41500
actions gpu gpu gpu gpu
action_info 642000000 560000000 510000000 401000000
Click to expand...
Click to collapse
The difference betwen the two methods is that 1824000 is actually kind of a high frequency to be thermal throttling at. (especially during the hot summer days we've been having lately in my state, my phone would just continue heating up and shutting down) I find that modifying set_point and set_point_clr are actually better since it increases the temperature setting BEFORE it starts throttling, but still throttles when it really needs to. This is especially helpful when using extended life batteries like the 6700 mAh batteries or 8500 mAh batteries which tend to run hotter than the average 3200 mAh batteries.
What I've observed is that if the extended batteries go above 51 degrees celsius, it starts kind of a chain reaction of heat between the CPU and battery that eventually causes the phone to overheat. I targeted the set_point and set_point_clr settings to cause it to throttle around this time to still make the phone usable, just slower for a short time.
I found that 1324800 was a good frequency to actually bring the temperature back down. When I set it at higher frequencies, the temperature for the battery would still stay around 51 degrees celsius or higher which was too hot for my taste.
i think my phone can handle it since i replaced the cheap paste with a premium paste......anyway i will test your method out to see if theres improvement