when i send a msg through whatsapp,it does not get sent.the two arrows in the wifi signal disappears.then when i start browsing the net, then the arrows appears.so, wen i need to send a txt via whatsapp,i have to browse simultaneously so that the wifi remains active.any solution??
[KERNEL] [GPL] [GN] franco.Kernel r398
- Thread starter franciscofranco
- Start date
It is most likely to be app related not kernel related. Try reinstalling whatsapp and set up your account again, i have no issues whatsoever with whatsapp on wifi nor mobile network.
In the OMAP kernel driver we set nominal values for the frequency steps. Those values are the starting point. Then SmartReflex kicks in and calculates a much lower value that the device can handle for each of the steps.
For example:
1228Mhz Nominal: 1250mV - Calibrated: 1050mV
When we undervolt we are changing the nominal value ONLY. So if we undervolt to 1100mV the Calibrated value will still be 1050mV what means we are still using the same voltage.
However if we undervolt to 1025mV the Calibrated value will obviously decrease to 1025mV but the chance of crashing the device will increase much more.
For 1536Mhz steps and beyond I made it so SmartReflex won't calibrate to prevent crashes so we're using the nominal values directly from the kernel.
Sent from my GT-I9300 using xda premium
For example:
1228Mhz Nominal: 1250mV - Calibrated: 1050mV
When we undervolt we are changing the nominal value ONLY. So if we undervolt to 1100mV the Calibrated value will still be 1050mV what means we are still using the same voltage.
However if we undervolt to 1025mV the Calibrated value will obviously decrease to 1025mV but the chance of crashing the device will increase much more.
For 1536Mhz steps and beyond I made it so SmartReflex won't calibrate to prevent crashes so we're using the nominal values directly from the kernel.
Sent from my GT-I9300 using xda premium
So if I've changed the nominal values in the undervolt settings but didn't go lower than the calibrated values then in reality it didn't have any effect on anything? Just trying to understanding this stuff
Sent from my Jelly Bean powered Galaxy Nexus using Tapatalk 2
I've been reading these type of threads for 3 years, and still haven't seen explanation on how to undervolt. From what I've read it's the way to getting longer life on my battery. Please explain how to undervolt.
Oozed from my sick Jelly Bean Nexus Prime via tapatalk2
Oozed from my sick Jelly Bean Nexus Prime via tapatalk2
osm0sis
Senior Recognized Developer / Contributor
UVing is useful for improving power consumption and heat reduction, especially at higher frequencies. If you UV too much it crashes/freezes. So basically we're talking about finding the sweet spot here and SR does a great job of that for all frequencies it operates on (per franco's post above).
DO NOT UV THE SAME ACROSS THE BOARD. Different frequencies can take different levels of UVing, so adding or subtracting 25 could work for one or two but be unnecessary or unstable for others. Each frequency must be UVed separately.
Here's the reference doc I made for myself, pulled from several other peoples' posts, so all credit to them (not sure who anymore, my apologies!):
And here's some more recent information, on what to look for with GPU and IVA undervolting to know you've gone too far:
http://xdaforums.com/showpost.php?p=42835670&postcount=42344
After all that I'd like to mention that UVing isn't really necessary! SR does a spectacular job and I'm not worried too much about the higher frequencies as I only clock to 1.5 GHz (the TI OMAP 4460 chipset factory specifications - so I'm not overclocking, I'm de-underclocking
).
Edit. As nemotheblue pointed out, a lot of this likely came from rogersnm's extremely informative posts. So many thanks and all credit to him and anyone else I might have gotten some of this from but forgot.
DO NOT UV THE SAME ACROSS THE BOARD. Different frequencies can take different levels of UVing, so adding or subtracting 25 could work for one or two but be unnecessary or unstable for others. Each frequency must be UVed separately.
Here's the reference doc I made for myself, pulled from several other peoples' posts, so all credit to them (not sure who anymore, my apologies!):
And here's some more recent information, on what to look for with GPU and IVA undervolting to know you've gone too far:
http://xdaforums.com/showpost.php?p=42835670&postcount=42344
After all that I'd like to mention that UVing isn't really necessary! SR does a spectacular job and I'm not worried too much about the higher frequencies as I only clock to 1.5 GHz (the TI OMAP 4460 chipset factory specifications - so I'm not overclocking, I'm de-underclocking
).Edit. As nemotheblue pointed out, a lot of this likely came from rogersnm's extremely informative posts. So many thanks and all credit to him and anyone else I might have gotten some of this from but forgot.
Last edited:
Just to add to the under voting info train here's something I copied from a post way back is this very thread I believe. Just something about the POTENTIAL benefits of under voting, not guaranteeing these results. Me personally I just let SR do all the work.
Laziness is nothing more than the habit of resting before one gets tired!
Laziness is nothing more than the habit of resting before one gets tired!
franco.Kernel updater patch
6.4
Common:
* Re-code all the download kernel functions - clean and improved code
* Re-implement the kernel download dialog information - now it shows real percentage of the file plus file sizes
* Touch events won't cancel kernel download dialogs anymore
* Some more bug fixings
If you have any issues please email me.
As usual you need to wait until Google takes care of the update push into their servers.
6.4
Common:
* Re-code all the download kernel functions - clean and improved code
* Re-implement the kernel download dialog information - now it shows real percentage of the file plus file sizes
* Touch events won't cancel kernel download dialogs anymore
* Some more bug fixings
If you have any issues please email me.
As usual you need to wait until Google takes care of the update push into their servers.
Hey Franco I just found something odd, I was running #248 since you first uploaded but I was getting a lot of data drops. At first I shook it off but then it got more aggressive and I reverted to #246 and now I get better signal and it doesn't drop as much.. Weird.
I got 99 problems but bamf ROMs ain't one! -nnnnr12
I got 99 problems but bamf ROMs ain't one! -nnnnr12
UV may get u like 5% better battery but by then most people are looking for a charger, don't waist your time it's been proven over and over agn that no real benefits. I've done my own tests weeks at a time and 5% was all I got, most people install a kernel screw with all the settings before they ever tested stock so there input is worthless
gianton
Inactive Recognized Contributor
Now it's crystal clear to me, NO more Undervolting!
Thanks for the heads up mate!!
i did that.not once but twice.prevoiusly i was on trinity kernel.now changed to franco.but same problem... :S
Last 2-3 pages made it more clear. No reason to UV.SR does a great job and we have to undervolt below the calibrated SR value which increases the risk of crashing much more than the real power save we get. So no UV and for me from now on.
Besides our Super Amoled is what drains most power on our phone!
Besides our Super Amoled is what drains most power on our phone!
So with 248 overall its great, iv had more microlags than I did with 246 which was very good overall. This 'interactive' interactive is good, my battery life has been acceptable (I normally stick to lazy) and the performance is good, I find he microlags happen more after having a long time without a reboot. Overall am very happy to continue testing 248
Sent from my Galaxy Nexus
Sent from my Galaxy Nexus
Just to add to the under voting info train here's something I copied from a post way back is this very thread I believe. Just something about the POTENTIAL benefits of under voting, not guaranteeing these results. Me personally I just let SR do all the work.
Laziness is nothing more than the habit of resting before one gets tired!
I believe that was the wizard known as rogersnm!
@osm0sis - O/T: I note in your sig you're running a yakju build with the new UGLH1, working well? Could I use that radio in Europe on my yakju?
Similar threads
Top Liked Posts
-
There are no posts matching your filters.
-
1562I hate big OPs.
Works on all roms. r390 and newer versions are ONLY for 4.3 or newer.
F.A.Q:
1. My device rebooted or crashed, how can I help?
A: Get me /proc/last_kmsg on pastie.org.
2. Battery sucks, my device is not entering deep sleep. FIX PLOX!
A: Fix it yourself, it's an app waking your device up not the kernel's problem
3. Signal is dropping since I flashed the kernel, amg u sucks!
A: The kernel has nothing to do with gsm/cmda signal. Make sure you have the latest radios
4. Do I need to wipe anything when flashing this kernel?
A: No.
5. Does this kernel has X or Y mod?
A: Learn to read, everything you need to know is in the features list, changelog or public repo.
Downloads:
4.3: http://192.241.177.15/GalaxyNexus/4.3/
4.4: http://192.241.177.15/GalaxyNexus/4.4/
Kernel changelog:
http://192.241.177.15/GalaxyNexus/4.3/appfiles/changelog.xml
Source:
https://github.com/franciscofranco/Tuna_JB_pre1/tree/nightlies-4.3
franco.Kernel updater Free apk: http://xdaforums.com/showthread.php?t=1867127
203[KERNEL][GPL][5 JUN - #Milestone 4][r200-ICS r210-JB] franco.Kernel | 4.0.3/4 |
Terminal commands for all the options in this kernel:
Color Multipliers:
echo r g b > /sys/class/misc/colorcontrol/multiplier
Replace r g and b for 2000000000 for stock color. If you want to change the colors just replace the first 3 numbers of each r/g/b with 0-400 of your choice.
Gamma Control:
echo r g b > /sys/class/misc/colorcontrol/v1_offset
Replace r/g/b by -255/200 of your choice.
Fsync:
echo 1 > /sys/module/sync/parameters/fsync_enabled - to enable
echo 0 > /sys/module/sync/parameters/fsync_enabled - to disable
Sound Control:
echo i > /sys/devices/virtual/misc/soundcontrol/volume_boost
Replace i with 0-3 of your choice.
Sound High Performance:
echo 1 > /sys/devices/virtual/misc/soundcontrol/highperf_enabled - to enable
echo 0 > /sys/devices/virtual/misc/soundcontrol/highperf_enabled - to disable
USB Fast Charge:
echo 1 > /sys/kernel/fast_charge/force_fast_charge - to enable
echo 0 > /sys/kernel/fast_charge/force_fast_charge - to disable
wifi_pm:
echo 1 > /sys/module/bcmdhd/parameters/wifi_pm - to enable
echo 0 > /sys/module/bcmdhd/parameters/wifi_pm - to disable
Trinity's Contrast:
echo i > /sys/module/panel_s6e8aa0/parameters/contrast
Replace i with -25/16 of your choice.
BLX:
echo i > /sys/class/misc/batterylifeextender/charging_limit
Replace i with 0-100 of your choice.
OMAP Gamma interface:
echo i > /sys/devices/platform/omapdss/manager0/gamma
Replace i with 5-10 of your choice.
Thermal Throttle:
echo 1 > /sys/module/omap_temp_sensor/parameters/throttle_enabled - to enable
echo 0 > /sys/module/omap_temp_sensor/parameters/throttle_enabled - to disable
TCP Congestion Algorithm interface
To check all the available options:
sysctl net.ipv4.tcp_available_congestion_control
To change to other option:
sysctl -w net.ipv4.tcp_congestion_control=NAME_OF_THE_ALGORITHM
Detailed test of all the algorithms:
167
haha. It's been a crazy two days. But it's been a blast.
Now, sleep is over, time to get back to work!
Yes and no. Here's what we're thinkin' so far.
THIS POST WILL BE A RECAP OF THE LAST FEW PAGES OF RESEARCH!
This was my original settings that I've been using for weeks:
So to make the short hand easier, we kept it in that order and just said: 20000/50/40000/20000 became 20k/50/40k/20k became 2/5/4/2. Make sense?
Here is a breakdown of what they each mean:
This is a good explanation that I wrote back on page 3038:
So Google's default is 10/5/6/2. Lower numbers are all better for performance except min_sample_time (there higher is faster). So our goal is to find a sweet spot.
The default 10 is for "Once speed is set to hispeed_freq, wait for this long before bumping speed higher in response to continued high load." So we think 10 is too high, but if you go too low, then you'll be using the higher freqs a lot more than you need and it will hurt the battery. So we are leaning towards 6 (60000) for above_hispeed_delay.
The default 5 is for "when the CPU hits X% amount of load, then jump to the hispeed_freq." Again if this one is too low then it will cause the higher freqs to be used more often then they need, so we actually turn go_hispeed_load up a little bit to 7 (70).
The default 6 is for "how long do I wait before lowering the clock speed from what it's currently at." So the lower we put this, the better battery will be. We're still trying to decide between 3 (30000) and 5 (50000). Osm0sis is getting more lag at lower levels, and finds the best performance mark at 5. So we turn min_sample_time down a little from stock to help with the battery.
The default 2 is for "wait this long before changing the clockspeeds from what it's at now." While technically 2 sounds better because it's changing more often, Franco believes that by setting the timer_rate to be the same thing as the CPU sample_rate (which is preset at 30000), then that will make the CPU more efficient at switching. So we increased it from 2 (20000) to 3 (30000).
So TO RECAP: Using the stuff from above, Google's defaults for these settings are 10/5/6/2 and we are changing them to 6/7/3/3 or 6/7/5/3 (again, still testing that third number for the min_sample_time).
Does that make sense for everyone interested in following along? Any questions? Feel free to try out these settings yourself (the easiest way is with Franco's app or something like Trickster). We want as much feedback as possible on this.
The next kernel release will have the totally tweaked settings for everyone to test without having to change their own stuff.
:laugh::good:111Kernel Emergency Settings Reset Zip
Alright so here's something that's been requested for awhile.
I wrote it up recently with Franco's stamp of approval, so I'm posting it here now. Please direct people back to this post from other threads.
This can/should be everyone's go-to when experiencing problems after updating to a new kernel build, you get stuck in a bootloop, or you think there's a conflict between ROM and kernel (or kernel tweaking app) you can't track down, since likely some leftover settings (voltages, etc.) are at fault. It's also useful if you just want to make sure you're running clean defaults. This should work on any device franco.Kernel and f.Ku support, as well as a variety of other devices, kernels and control apps: eXperience (Free/Pro), GLaDOS Control, TricksterMod, Trinity Kernel Toolbox, ROM Toolbox (Lite/Pro), SetCPU, Faux123 Kernel Enhancement Project, Performance Control and Synapse.
Flashing this via custom recovery of your choice will delete the kernel app settings file(s), disable init.d and userinit.d scripts by moving them to a subfolder (/system/etc/init.d/off/ and /data/local/userinit.d/off/ respectively) and wipe cache and dalvik-cache for good measure.
Hopefully it helps!
Note: If your ROM has a Performance/Tweaking App built-in you should also manually disable any Set On Boot options it has. For example, I couldn't include clearing CM's Advanced Settings since they're built into the main com.android.settings/Settings.apk along with a lot of other Android OS settings (APNs, Developer Options, etc.), so to run clean and without conflicts on CM you need to unset them yourself.
You should also avoid having more than one control app installed at a time. Conflicts have been reported even with everything "unset" in two apps.
I also chose not to disable anything your ROM may have in /data/cron or /system/addon.d since some rely on it heavily, so you can choose to review those directories' contents and whether you want to leave them enabled on your own. I also left out disabling sysctl.conf since that's done by f.K and the Franco's Dev Team scripts, and also seemed a bit heavy-handed for this zip script.
Download counts for the previous versions: 790; 2678.105Sure. Happy to post my franco.Kernel settings here for anyone who wants to try them. I'll keep these up-to-date if I change them.
These are my f.K settings, my DirtyV settings can be found here.
Fsync on just in case anything ever happens I want my data protected. That said I do disable it temporarily if I ever want a bit more performance in an app or game. SR is hardcoded disabled in the latest builds.
The other thing worth noting is I set my color settings on boot with an init.d script. Doing it that way you can end up with a completely different result from the same values. The contrast, blacks and colors are much more natural. Also it's seamless which is nice; they take effect during the Google logo. Attached is my init.d script for that. Alter it to your own color settings, remove the .txt extension, push to /system/etc/init.d/ and set the correct perms; rwxr-xr-x (chmod -R 755 /system/etc/init.d in Terminal Emulator).
900colorsettings can be found with my other init.d scripts (from Franco Dev Team), here: https://s.basketbuild.com/filedl/devs?dev=osm0sis&dl=osm0sis/scripts/900colorsettings
Note: On my new replacement screen, setting the color multiplier too early in the boot (any time before the boot animation) made everything look dark, oversaturated, uncontrasted and dusky; basically the opposite of the way it used to work on my old panel. Adding sleep 2; before that line in the init.d script fixed this, so experiment if your panel is more like my new one, and the init.d as-is after you put in your settings makes it look worse.
[ New init.d script with my new colors. I need the sleep 4 because of my problem in my "Note" above, so comment it out if you don't need it, it will make it look worse. Previous download counts were 1880, 646, and 307. Thanks everyone! ]
New posts
-
-
-
-
Question Pixel 7 Pro, I think I bricked my phone trying to root it
- Latest: Darla Fredrick
