dBm instead of signal bars? (similarly to supercircle battery) - Desire Q&A, Help & Troubleshooting

Hi all,
I would love to have something similar to the supercircle battery mod, but for the signal strength indicator (instead of the usual four bars).
Do you know if there is already some mod for doing this?
Do you think it is hard to develop something in that direction?
Maybe, the dev of the supercircle battery mod can give us some hint?
Best,
Wally
P.S. I am aware that the cyanogen Rom already has dBm on the tray, but what about all the others?
Sent from my HTC Desire using XDA App

wally80 said:
Hi all,
I would love to have something similar to the supercircle battery mod, but for the signal strength indicator (instead of the usual four bars).
Do you know if there is already some mod for doing this?
Do you think it is hard to develop something in that direction?
Maybe, the dev of the supercircle battery mod can give us some hint?
Best,
Wally
P.S. I am aware that the cyanogen Rom already has dBm on the tray, but what about all the others?
Sent from my HTC Desire using XDA App
Click to expand...
Click to collapse
OpenDesire and DeFrost have it too.

BlackDragonBE said:
OpenDesire and DeFrost have it too.
Click to expand...
Click to collapse
Because they are based on cyanogenmod, right?
Unfortunately I love HTC sense. :-(
Anyway, in cyanogenmod there is just a number that shows up in addition to the legacy bars.
This would even be OK for me, I would be very happy to have it in my leedroid.
But the idea I was posting is about something that REPLACES the bars and put a circle (with some more levels? don't know, maybe 8?) and the dBm value in the center. Exactly as the super circle battery.

wally80 said:
Because they are based on cyanogenmod, right?
Unfortunately I love HTC sense. :-(
Anyway, in cyanogenmod there is just a number that shows up in addition to the legacy bars.
This would even be OK for me, I would be very happy to have it in my leedroid.
But the idea I was posting is about something that REPLACES the bars and put a circle (with some more levels? don't know, maybe 8?) and the dBm value in the center. Exactly as the super circle battery.
Click to expand...
Click to collapse
No cake for you.
Sent from my HTC Desire using XDA App

I would also like this mod
Sent from my HTC Desire using XDA App

wardy277 said:
I would also like this mod
Sent from my HTC Desire using XDA App
Click to expand...
Click to collapse
No cake for you too.
Sent from my HTC Desire using XDA App

K900 said:
No cake for you.
Sent from my HTC Desire using XDA App
Click to expand...
Click to collapse
What do you mean?

me too would like to have this feature on sense roms
and I don't like cake
Sent from my HTC Desire using XDA App

+1 for this, but maybe a triangle or a square? to differ it from the battery, otherwise the create confuse.. so NO circle, but go for other shape

I meant it is not possible. Circle battery is based on the thing that Sense allows for a custom icon for every battery level (from 0% to 100%) and every icon of that set is replaced. It doesn't read anything from the system, it's just a pack of icons. And the signal level icon has 5 or so states, so it will require modding Sense to have more icons for signal strength, and I don't even know if it knows the dBm and doesn't get precalculated signal levels from the kernel/radio.
Sent from my HTC Desire using XDA App

I was thinking about that but it needs changing only 1 file in the sources codes:
The file is: services/java/com/android/server/status/StatusBarPolicy.java
Code:
......
122 //***** Signal strength icons
123 private IconData mPhoneData;
124 //GSM/UMTS
125 private static final int[] sSignalImages = new int[] {
126 com.android.internal.R.drawable.stat_sys_signal_0,
127 com.android.internal.R.drawable.stat_sys_signal_1,
128 com.android.internal.R.drawable.stat_sys_signal_2,
129 com.android.internal.R.drawable.stat_sys_signal_3,
130 com.android.internal.R.drawable.stat_sys_signal_4
131 };
......
This is for the icons in the code above and below the number of bars depends on the signal strength. There is no rule about setting signal strenght VS nb. of bars and so Apple and Google *could* cheat for overestimating the number of bars ^^
Code:
996 // ASU ranges from 0 to 31 - TS 27.007 Sec 8.5
997 // asu = 0 (-113dB or less) is very weak
998 // signal, its better to show 0 bars to the user in such cases.
999 // asu = 99 is a special case, where the signal strength is unknown.
1000 if (asu <= 2 || asu == 99) iconLevel = 0;
1001 else if (asu >= 12) iconLevel = 4;
1002 else if (asu >= 8) iconLevel = 3;
1003 else if (asu >= 5) iconLevel = 2;
1004 else iconLevel = 1;
The source file is located here:
http://android.git.kernel.org/?p=pl...f9b9cb71b1f057b4904c660318e20eff;hb=HEAD#l131
Otherwise, the services.jar can be edited but you need modifying the StatusBarPolicy.smali (if decompiled with smali tool)
I already tried the last method but it seems if I modify it a lot, my phone would end in a bootloop
So we need an expert for doing that.
PS: For your culture, look at the page 87 of the pdf to see how the dBm is converted to ASU:
http://www.quintillion.co.jp/3GPP/Specs/27007-940.pdf
... and the 3GPP specification
http://3gpp.org/ftp/Specs./html-info/27007.htm

Fightspit said:
I was thinking about that but it needs changing only 1 file in the sources codes:
The file is: services/java/com/android/server/status/StatusBarPolicy.java
Code:
......
122 //***** Signal strength icons
123 private IconData mPhoneData;
124 //GSM/UMTS
125 private static final int[] sSignalImages = new int[] {
126 com.android.internal.R.drawable.stat_sys_signal_0,
127 com.android.internal.R.drawable.stat_sys_signal_1,
128 com.android.internal.R.drawable.stat_sys_signal_2,
129 com.android.internal.R.drawable.stat_sys_signal_3,
130 com.android.internal.R.drawable.stat_sys_signal_4
131 };
......
This is for the icons in the code above and below the number of bars depends on the signal strength. There is no rule about setting signal strenght VS nb. of bars and so Apple and Google *could* cheat for overestimating the number of bars ^^
Code:
996 // ASU ranges from 0 to 31 - TS 27.007 Sec 8.5
997 // asu = 0 (-113dB or less) is very weak
998 // signal, its better to show 0 bars to the user in such cases.
999 // asu = 99 is a special case, where the signal strength is unknown.
1000 if (asu = 12) iconLevel = 4;
1002 else if (asu >= 8) iconLevel = 3;
1003 else if (asu >= 5) iconLevel = 2;
1004 else iconLevel = 1;
The source file is located here:
http://android.git.kernel.org/?p=pl...f9b9cb71b1f057b4904c660318e20eff;hb=HEAD#l131
Otherwise, the services.jar can be edited but you need modifying the StatusBarPolicy.smali (if decompiled with smali tool)
I already tried the last method but it seems if I modify it a lot, my phone would end in a bootloop
So we need an expert for doing that.
PS: For your culture, look at the page 87 of the pdf to see how the dBm is converted to ASU:
http://www.quintillion.co.jp/3GPP/Specs/27007-940.pdf
... and the 3GPP specification
http://3gpp.org/ftp/Specs./html-info/27007.htm
Click to expand...
Click to collapse
Nice find Though I don't really know if that will work with Sense
Sent from my HTC Desire using XDA App

Related

activity manager cpu 100%

Hi
i have a weird thing , dont know if its rom related but defenetly noticed it after rooting my device and installing cosutm roms. well i only used ARHD since 2.0.09 and i love it.
but , what happens is that suddenly and out of nothing (after like hours/days and the rom running smooth and ultra fast) , system cpu usage jumps to 100% and never bugs off only through a restart, and this seems to happen with all the different versions of ARHD i had, even though i install most of them with full wipes. but this i don't understand and it annoyes me cos it uses this cpu amount and drains battery and it happens suddenly and randomly , dunno what triggers it, and no matter how i tried to track it to see the error but couldn't find a thing.
i just hope u can help me by taking a look at this log i saved from android systeminfo app registering some errors (3 min log and it drained 14% battery ) , it shows something about "activity manager", im not a developer and i know nothing about those codes, but would be awesome if someone helps me out with any tip please.
thank you.
I am not a DEV but i don't think your log file includes any clue of what is causing your problem. Do you have sense account on? or any types of account that let you track your phone?
Activate usb debugging
Seems to be the bug with the .init process.
Sent from my Desire HD using Tapatalk
thank you for the replies , i already have usb debugging on. dunno what is causing this, its totally random and its driving me nuts.
can you see a process that uses 100% cpu in android system info? If yes, try to kill it and look at your cpu usage.
CPUNotify is a great tool. It shows cpu usage in the notification bar
Sent from my Desire HD using Tapatalk
the process showing 100% cpu usage (not always but randomly, no idea what triggers it ) is system , and u can't force close or end that task
Hmm strange... i can't even find a process called activity manager on my phone...
Well i don't know but maybe it's related to the DroidDream malware. Some apps in the market were infected with this virus. And i've read that the virus gains root access and can download other apps in the background.
Here's a link: http://forum.xda-developers.com/showthread.php?t=977154
I really don't know if it's related to this but it just came to my mind
Sent from my Desire HD using Tapatalk
thx for the help mate , but i dont think its related to droidream cos ive been having this issue since a while (long time before droidream was up )
im still monitoring to find out what is causing this issue.
i have the same issue since going to a rooted ROM (HD rev 2.0.12). tried every build up to 3.0 and i have the same issue. it seems to be randomly triggered (i've seen it trigger after playing "robo defense", playing music, making a call etc).
i have no sense account and dont have malware and have usb debugging on
I fix/hack it this way..open adb shell
type
chmod 700 /sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state
ie disallow anything (even system_server) from reading this file.
in fact i automate this command to run every 15 mins using an app called phone prioritizer. as soon as you type the chmod..your logcat will stop spinning and all will be well (iove not seen any side effects yet).
ps. you have to run this every time you open setcpu, as it will reset the permission on this file to 777/666 depending on the version of setcpu you have.
Activate usb debugging
Seems to be the bug with the .init process.
Click to expand...
Click to collapse
nope that totally different. that problem shows itself in "top -m 5" as init taking all the cpu ..this will show as system_server.
the "bug" manifests itself in this kernel file:
goto url github.com/android/platform_frameworks_base/blob/master/services/java/com/android/server/ProcessStats.java#L157
it spins on getCpuSpeedTimes() where it reads time_in_state..why it does this i dont know..it looks like mBuffer is corrupt as nosuchelementException would indicate that the buffer didnt have 2 words per line of the file yet the real file looks fine if you cat it (readFile seems not to initialise this on reading it to null first (but i'm not a java expert..maybe ".read" does this) so perhaps it has junk in it on certain conditions..any java guys out there can explain why they made this a glbal variable? it seems like it should be a local one)
by chmodding the file i cause an IOException to throw in readFile (which is then ignored and the return is gracefully set as null..this then skips the infinate loop).
you can see this issue in a few bugs like android issue 9733..oxygen rom issue 507 etc.
wow , cheers mate for the help , sounds a bit complicated for me but at least we know what it is now and how to get over it.
but how come mike1986 doesnt know about this bug and its fix ? he could incorporate this into his next build so it saves us that command run every 15 mins. or it cant be incorporated ?
someone should tell him to be honest
but cheers for explanation mate, thank you
Is Apache14 informed about this? Maybe he can solve it in next Kernelversion.
walda said:
Is Apache14 informed about this? Maybe he can solve it in next Kernelversion.
Click to expand...
Click to collapse
i have no idea about that , if he does then im sure he will fix it
As I read in mikes 3.0 thread, he is informed. Fine...
sent from my DHD via Tapatalk
further to this.
in ProcessStats.java (im not sure if this is a kernel file or if it sits just outside the kernel).
mBuffer looks to me to be the main problem.
1. in apaches rom, which is overclocked he defines 23 CPU speeds..ProcessStats.java only allows 20
Code:
private long[] getCpuSpeedTimes(long[] out) {
long[] tempTimes = out;
long[] tempSpeeds = mCpuSpeeds;
final int MAX_SPEEDS = 20;
if (out == null) {
tempTimes = new long[MAX_SPEEDS]; // Hopefully no more than that
tempSpeeds = new long[MAX_SPEEDS];
this is a minor issue..as this overflow is trapped in the loop anyway:
Code:
if (speed == MAX_SPEEDS) break; // No more
however, the definition of mBuffer is too small:
Code:
private byte[] mBuffer = new byte[256];
my file at the moment is 300 bytes. the readFile reads only once instead of looping until end of file:
Code:
int len = is.read(mBuffer);
is.close();
so only the first 256 bytes are ever read.
My assumption is that IF the files first 256 bytes ends up cutting off the last read line (and that line lies in the first MAX_SPEEDS lines of the file) before the speed time element..this causes a NoSuchElementException to throw..as the last line will be like
921600 255
960000 750
998400 8042
10368
ie the line
1036800 3089
was cut off too soon and this code
Code:
long val = Long.parseLong(token);
tempSpeeds[speed] = val;
token = st.nextToken(); <-- here
val = Long.parseLong(token);.
in getCpuSpeedTimes() fails as it cant see the timing?
would then fail on the second nextToken().
the big question is who owns that code in our custom ROM? is it the same as the original android code so we are at the mercy of Google to fix it or is this something Mike / Apache will be able to patch up ..assuming i'm making sense
the only workaround is as i said before: to chmod this file to 700 and ensure it stays there (avoid using setcpu as it changes the permissions).
You can probably also reduce this by limiting the CPU frequency range your phone uses (ie keep the filesize smaller)..if you have profiles that span 200mhz to 1.2ghz then you will probably hit this sooner
i did a test.
1. rebooted my phone..ensured time_in_state had permissions -r--r--r--
2. manipulated CPU frequency using cpu tuner to make all frequencies have at least 5 bytes per line.
once the first 20 lines were > 256 bytes and the 256nd byte sat between <cpu speed> and <time spent at that speed> i get the loop.
eg just before the issue arose i saw:
Code:
# cat time_in_state
cat time_in_state
245000 200030
422400 12676
460800 11929
499200 10333
537600 37021
576000 10685
614400 13672
652800 10646
691200 14864
729600 13956
768000 12662
806400 15025
844800 22094
883200 26741
921600 10389
960000 9937
998400 17606
1036800 6864
1075200 1560
1113600 1296
1152000 2158
1190400 2540
1228800 2463
i had my cpu pinned to 960 mhz.
the 256 at this point lies here:
Code:
1075200 1560
1113600 1
ie line 20 is cut off after 1..this is still "valid" in terms of the data in mBuffer..but once 960 rolled into five digits
Code:
# cat time_in_state
cat time_in_state
245000 200030
422400 12676
460800 11929
499200 10333
537600 37021
576000 10685
614400 13672
652800 10646
691200 14864
729600 13956
768000 12662
806400 15025
844800 22094
883200 26741
921600 10389
960000 10288
998400 17606
1036800 6864
1075200 1560
1113600 1296
1152000 2158
1190400 2540
1228800 2463
the 256 byte now meant the last line shifts to:
Code:
1036800 6864
1075200
the 2nd word is now totally missing!
as soon as this happened..my logcat started issuing
Code:
Unexpected exception collecting process stats
java.util.NoSuchElementException
at java.util.StringTokenizer.nextToken(StringTokenizer.java:272)
at com.android.server.ProcessStats.getCpuSpeedTimes(ProcessStats.java:596)
at com.android.server.ProcessStats.getLastCpuSpeedTimes(ProcessStats.java:568)
at com.android.server.am.ActivityManagerService.updateCpuStatsNow(ActivityManagerService.java:1657)
at com.android.server.am.ActivityManagerService$4.run(ActivityManagerService.java:1583)
errors.
something later on then causes this behavior to go into a full tight loop (as once the issue starts..it just issues this every few seconds..so most uses wont notice it).
didnt mike fixed it with his latest release (ARHD 3.1) ?
Goodm7sn said:
didnt mike fixed it with his latest release (ARHD 3.1) ?
Click to expand...
Click to collapse
mike changed the file permission to 700 to get around it. the bug is still there in the code though. also im not sure if hes scheduling it to make it stay at 700..if not then users with setcpu installed may still get the problem (as setcpu changes the file permission back to 777/666 when you open the gui).
DazzaL said:
i have the same issue since going to a rooted ROM (HD rev 2.0.12). tried every build up to 3.0 and i have the same issue. it seems to be randomly triggered (i've seen it trigger after playing "robo defense", playing music, making a call etc).
i have no sense account and dont have malware and have usb debugging on
I fix/hack it this way..open adb shell
type
chmod 700 /sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state
ie disallow anything (even system_server) from reading this file.
in fact i automate this command to run every 15 mins using an app called phone prioritizer. as soon as you type the chmod..your logcat will stop spinning and all will be well (iove not seen any side effects yet).
ps. you have to run this every time you open setcpu, as it will reset the permission on this file to 777/666 depending on the version of setcpu you have.
nope that totally different. that problem shows itself in "top -m 5" as init taking all the cpu ..this will show as system_server.
the "bug" manifests itself in this kernel file:
goto url github.com/android/platform_frameworks_base/blob/master/services/java/com/android/server/ProcessStats.java#L157
it spins on getCpuSpeedTimes() where it reads time_in_state..why it does this i dont know..it looks like mBuffer is corrupt as nosuchelementException would indicate that the buffer didnt have 2 words per line of the file yet the real file looks fine if you cat it (readFile seems not to initialise this on reading it to null first (but i'm not a java expert..maybe ".read" does this) so perhaps it has junk in it on certain conditions..any java guys out there can explain why they made this a glbal variable? it seems like it should be a local one)
by chmodding the file i cause an IOException to throw in readFile (which is then ignored and the return is gracefully set as null..this then skips the infinate loop).
you can see this issue in a few bugs like android issue 9733..oxygen rom issue 507 etc.
Click to expand...
Click to collapse
Thanks mate, your solution is really effective on my DHD with revolution 3.0.
I am going to reflash with revolution 3.1, hopefully 3.1 will cure the cpu 100% usage
im on android revolution HD and i can confirm this , 100% system cpu of death is still here, didnt get fixed , had to change setcpu frequency and it stopped
meh phone cant last 12 hrs without a restart, frustrating.
DazzaL said:
mike changed the file permission to 700 to get around it. the bug is still there in the code though. also im not sure if hes scheduling it to make it stay at 700..if not then users with setcpu installed may still get the problem (as setcpu changes the file permission back to 777/666 when you open the gui).
Click to expand...
Click to collapse
if setcpu changed the range once the gui is opened , what do u recommend us to use for overclocking ? something safer
thx for helping
I read that it happens with CPU tuner and even without anything also!
The only solution I see is to fix the frequency file.
sent from my DHD via Tapatalk

New registry ( possible tweaks) for rom builders

To increase the file system cache: ( There is more than 1 entry regarding this. so look into it)
HKLM\System\StorageManager\FATFS\CacheSize = 4096 (DWORD decimal)
enable Power management for sdcard
[HKEY_LOCAL_MACHINE\Comm\AsyncMac1\Parms]
"DisablePowerManagement"=dword:0
[HKEY_LOCAL_MACHINE\Drivers\SDCARD\ClientDrivers\Class\MMC_Class]
"DisablePowerManagement"=dword:0
[HKEY_LOCAL_MACHINE\Drivers\SDCARD\ClientDrivers\Class\SDMemory_Class]
"DisablePowerManagement"=dword:0
Enlarge the block transfer size for SD card ( multiple entries under the section)
\\registry\HKLM\Drivers\SDCARD\ClientDrivers\Class\SDMemory_Class\BlockTransferSize=4096
Auto data disconnect ( cant be edited at the moment)
HKEY_LOCAL_MACHINE\Comm\ConnMgr\Planner\Settings\
SuspendResume = ????
Disable HSPA , Operate only on 3G mode
HKEY_CURRENT_USER\Software\Microsoft\Windows\Curre ntVersion\Internet Settings
Value name: MaxConnectionsPer1_0Server
Value data: 32
Base: Decimal
Value Name: MaxConnectionsPerServer
Value data: 16
Base: Decimal
Disable hardware acceleration for Internet explorer
HKEY_LOCAL_MACHINE\software\Microsoft\windows\INTERNET explorer\main\feature control/Feature GPu Rendering/ (set Dword to 0)
here you have more:
http://forum.xda-developers.com/showthread.php?t=907971
what is it with this tweaks? have you checked the improvements with baterry meter? or do you only spamming a second tweak thread....
ahlMAR said:
what is it with this tweaks? have you checked the improvements with baterry meter? or do you only spamming a second tweak thread....
Click to expand...
Click to collapse
this values are from xboxmod
http://forum.xda-developers.com/showpost.php?p=21983831&postcount=2
and are similar tp WM 6.5 values
Old tweaks
I am afraid that all those tweaks are already in practicaly every custom rom.
but not in official interop unlocked rom.
updated with another major tweak, disable HSPA
Why would anyone want to implement the 3G tweak as standard? I can understand making the option available for the very few that might desire that, but shipping a custom rom like that with it implemented already would turn off the vast majority as most people actually use and like HSDPA. You can't screw over the masses to cater to the select few.
returned4good said:
Why would anyone want to implement the 3G tweak as standard? I can understand making the option available for the very few that might desire that, but shipping a custom rom like that with it implemented already would turn off the vast majority as most people actually use and like HSDPA. You can't screw over the masses to cater to the select few.
Click to expand...
Click to collapse
Using the tweak i dont see any data speed differences.
but possible battery life savings if u default to 3G, 3G is slower i know but it isnt that bad, iphone 3G users had great battery life because the phone does not use HSPA
given the 1ghz processor and 512 mb ram on most wp7 phones , surfing on 3G will be still be faster than iphone 3G
Multiple Entries?
What do you mean by "multiple entries in this section"? Does that mean that the change you indicate may not be the only one required? Or do you just want people to know that there are other entries and just be aware and no need to change these?
As an example, for your first recommendation, "Increase file system cache" I have "CacheSize (0)" and EnableCache (1). Do both need to be changed?
Magpir said:
Using the tweak i dont see any data speed differences.
but possible battery life savings if u default to 3G, 3G is slower i know but it isnt that bad, iphone 3G users had great battery life because the phone does not use HSPA
given the 1ghz processor and 512 mb ram on most wp7 phones , surfing on 3G will be still be faster than iphone 3G
Click to expand...
Click to collapse
how to aply that tweak? i would like to try it !
nickislauw said:
how to aply that tweak? i would like to try it !
Click to expand...
Click to collapse
this is for hd7 . U need to install the intrinsic custom Rom and registry editor 1.2.
Magpir said:
Using the tweak i dont see any data speed differences.
but possible battery life savings if u default to 3G, 3G is slower i know but it isnt that bad, iphone 3G users had great battery life because the phone does not use HSPA
given the 1ghz processor and 512 mb ram on most wp7 phones , surfing on 3G will be still be faster than iphone 3G
Click to expand...
Click to collapse
I do. I get nearly 6 Mbps on HSDPA and about 2.75 on 3G. That's a difference I wouldn't give up for anything and it's highly noticeable. It's nice to be aware of the tweak, but a lot of people like HSDPA to have it being disabled a default setting.
Also, the iPhone 3g had a comparable battery with a cpu that's half as powerful. Keep in mind that your comparing it to a phone that's now 4 years old, which also happened to be a time when 3G+ wasn't out very long yet.
returned4good said:
I do. I get nearly 6 Mbps on HSDPA and about 2.75 on 3G. That's a difference I wouldn't give up for anything and it's highly noticeable. It's nice to be aware of the tweak, but a lot of people like HSDPA to have it being disabled a default setting.
Also, the iPhone 3g had a comparable battery with a cpu that's half as powerful. Keep in mind that your comparing it to a phone that's now 4 years old, which also happened to be a time when 3G+ wasn't out very long yet.
Click to expand...
Click to collapse
Just to ask, is this ony r hpone which is a wp7? how do u know the exact figures?
if i am not wrong, HSPA doesnt automatically mean u get higher speed. on some networks there is this "throttle" effect where unless u are downloading a huge file like 50 MBs , u will not see the speeds like 6mb . Means the speed adjusts according to the size off data/ if u are surfing webpages, at the most u may get 1mbps even on HSPA which is more or less the same as 3G speed.
HSPA is a layer which operates on top the regular 3G. IT require the cell tower to be configured for HSPA
On some win mobile phones u get the options to disable HSPA. what i may be doing is just adjust power of radio or it may do the max connections thing
In fact APPle did not want to use Hspa in iphone 3G , it was around at the time, due to power requirements.
Magpir said:
Just to ask, is this ony r hpone which is a wp7? how do u know the exact figures?
if i am not wrong, HSPA doesnt automatically mean u get higher speed. on some networks there is this "throttle" effect where unless u are downloading a huge file like 50 MBs , u will not see the speeds like 6mb . Means the speed adjusts according to the size off data/ if u are surfing webpages, at the most u may get 1mbps even on HSPA which is more or less the same as 3G speed.
HSPA is a layer which operates on top the regular 3G. IT require the cell tower to be configured for HSPA
On some win mobile phones u get the options to disable HSPA. what i may be doing is just adjust power of radio or it may do the max connections thing
In fact APPle did not want to use Hspa in iphone 3G , it was around at the time, due to power requirements.
Click to expand...
Click to collapse
I used Bandwidth, one of the bandwidth testers on the marketplace. I notice the difference when I browse as well; pages do load faster. I understand what HSDPA is and how it works.
returned4good said:
I used Bandwidth, one of the bandwidth testers on the marketplace. I notice the difference when I browse as well; pages do load faster. I understand what HSDPA is and how it works.
Click to expand...
Click to collapse
so yr testing is with regards to my tweak ??
on my mozart both values are: 6 should I change both to:
HKEY_CURRENT_USER\Software\Microsoft\Windows\Curre ntVersion\Internet Settings
Value name: MaxConnectionsPer1_0Server
Value data: 32
Base: Decimal
Value Name: MaxConnectionsPerServer
Value data: 16
Base: Decimal
majkeljj said:
on my mozart both values are: 6 should I change both to:
HKEY_CURRENT_USER\Software\Microsoft\Windows\Curre ntVersion\Internet Settings
Value name: MaxConnectionsPer1_0Server
Value data: 32
Base: Decimal
Value Name: MaxConnectionsPerServer
Value data: 16
Base: Decimal
Click to expand...
Click to collapse
yes..........
JamesAllen said:
What do you mean by "multiple entries in this section"? Does that mean that the change you indicate may not be the only one required? Or do you just want people to know that there are other entries and just be aware and no need to change these?
As an example, for your first recommendation, "Increase file system cache" I have "CacheSize (0)" and EnableCache (1). Do both need to be changed?
Click to expand...
Click to collapse
No only change the CacheSize to 4096. EnableCache still 1 because if zero the cache is disabled.
MrPappy86 said:
No only change the CacheSize to 4096. EnableCache still 1 because if zero the cache is disabled.
Click to expand...
Click to collapse
there are mutiple instances saying cache size for fatfs and exfat.
so u need to change all of them since we dont know what each does.

Adjusting the "Touch Slop" in CM9 (from 8 to 16)

I responded in the larger CM9 thread but it will probably be buried in a day or so. And I think this will help devs who are working on CM9 builds at the moment.
------------------------------------------------------------------
jdommer said:
The correct settings for the our touch screen appear to be:
Code:
touch.deviceType = touchScreen
touch.orientationAware = 1
# Size
# Based on empirical measurements, we estimate the size of the contact
# using size = sqrt(area) * 28 + 0.
touch.size.calibration = default
touch.size.scale = 1
touch.size.bias = 0
touch.size.isSummed = 0
# Pressure
# Driver reports signal strength as pressure.
#
# A normal index finger touch typically registers about 80 signal strength
# units although we don't expect these values to be accurate.
touch.pressure.calibration = none
touch.pressure.scale = 1.0
# Orientation
touch.orientation.calibration = default
Unfortunately, that doesn't do anything for the tap/drag problem. The KF can't distinguish pressure or size of touch.
Looks like Android decides any touch where x1-x2 or y1-y2 > 8 as a drag. I can't find any place that that value is configurable after scouring the internets all morning, but if it could simply be turned up to maybe 12 that would probably alleviate 90% of our taps as drags problems.
Anyone have any idea, is there a config file or is that compiled in and has to be changed at source? I feel competent enough to dink with config files, but can't compile crap.
Click to expand...
Click to collapse
I build from the KFire-Android git as a testing model and i've been experimenting with a setting of "16" for touch slop, and in my opinion it's working much better.. could probably be 12, but who knows. I'm having a much easier time selecting things like Beautiful Widgets 1x1 Toggles, where before it was a trial of patience and about 10 touches.
This is a setting in the overlay config.xml file. I went ahead and committed it this morning to the KFire-Android org at Github:
https://github.com/KFire-Android/device-amazon-otter/commit/56b3d52fe6c645a18e60ab765e5b9831cb6a0663
Is the code that uses the clickSlop in android hackable for KFire?
I found on my device that most of the noise on taps was occurring in the last few samples (like the touchscreen firmware is averaging in some bad samples on finger release) and that by dropping the last few touch events I got much better touch response in my app. I'm not sure where to put such a state machine in the framework, though, or how to have it only for KFire...
(My state machine would buffer 3 samples ahead for the first 20 samples, and then drop the last 3 samples on finger up and patch N-3 to be a finger up instead of a move -- after 20 samples it just passed everything through with no buffering to avoid adding latency to drags).

Smarreflex - Values explained +1350mv calibration fix

Ok dears, I accidentally came across this. Now there is nothing smart about smartreflex.
voltage.h contains values about min and max range for smartreflex calibrations for CORE IVA and MPU, that we already knew...
Now I found this:
http://gitorious.org/pandroid/kerne...a10c87d6445/arch/arm/mach-omap2/smartreflex.c
Let's quit fooling around:
/* Default steps added for 1G volt is 5 in uV */
static unsigned long sr_margin_steps_1g = 62500;
/* Default steps added for less than 1G OPP's is 3 in uV*/
static unsigned long sr_margin_steps = 37500;
Click to expand...
Click to collapse
Does this explain enough for you? Below 1ghz each step is 3.7500, above it is 6.25
You don't get it?
static void sr_add_margin_steps(struct omap_sr *sr)
{
int i;
/*
* Add 5 steps for 1g and 3 steps for other OPP's by default
* REVISIT: Make it configurable through sysfs dynamically
*/
for (i = 1; i <= 3; i++)
sr1_opp_margin = sr_margin_steps;
sr1_opp_margin[4] = sr_margin_steps_1g;
for (i = 1; i <= MAX_VDD1_OPP; i++) {
printk(KERN_INFO "sr1_opp_margin[%d]=%ld\n", i,
sr1_opp_margin);
mpu_opps.sr_vsr_step_vsel = 0x0;
mpu_opps.sr_adjust_vsel = 0x0;
}
printk(KERN_INFO "steps added, volt will be"
"recaliberated automatically\n");
}
Click to expand...
Click to collapse
How did that translate for you? Is that just hardcoded to read the OPP table??? The first three elements in the MPU OPP table are below 1GHZ: 350, 700, 920
The rest is above...
I hope I helped some developers with this.
Since I'm no programmer I'm having a hard time to understand this.
Does it mean smartreflex is not good at all?
For me I hate smartreflex. I always get better battery uptime (especially in standby I get around 0.5% usage per hour) when I undervolt by myself.
When I use smartreflex my usage in standby is about 3 to 5%.
In my opinion smartreflex is for noobs who don't wanna fool around themselves...
Gesendet von meinem Galaxy Nexus mit Tapatalk 2

Poor Signal on Android 4.2 on LTE Gnex?

I've noticed some users have reported inferior signal on Android 4.2 on the LTE Gnex. This is actually not true. In fact below is the related function that changed from 4.1.2 to 4.2.
Jellybean 4.1.2:
https://github.com/android/platform...ny/java/android/telephony/SignalStrength.java
Code:
if (mLteRsrp == -1) levelLteRsrp = 0;
else if (mLteRsrp >= -95) levelLteRsrp = SIGNAL_STRENGTH_GREAT;
else if (mLteRsrp >= -105) levelLteRsrp = SIGNAL_STRENGTH_GOOD;
else if (mLteRsrp >= -115) levelLteRsrp = SIGNAL_STRENGTH_MODERATE;
else levelLteRsrp = SIGNAL_STRENGTH_POOR;
if (mLteRssnr == INVALID_SNR) levelLteRssnr = 0;
else if (mLteRssnr >= 45) levelLteRssnr = SIGNAL_STRENGTH_GREAT;
else if (mLteRssnr >= 10) levelLteRssnr = SIGNAL_STRENGTH_GOOD;
else if (mLteRssnr >= -30) levelLteRssnr = SIGNAL_STRENGTH_MODERATE;
else levelLteRssnr = SIGNAL_STRENGTH_POOR;
int level;
if (mLteRsrp == -1)
level = levelLteRssnr;
else if (mLteRssnr == INVALID_SNR)
level = levelLteRsrp;
else
level = (levelLteRssnr < levelLteRsrp) ? levelLteRssnr : levelLteRsrp;
if (DBG) log("Lte rsrp level: "+levelLteRsrp
+ " snr level: " + levelLteRssnr + " level: " + level);
return level;
}
JB 4.2:
https://github.com/android/platform...ny/java/android/telephony/SignalStrength.java
Code:
if (mLteRsrp > -44) rsrpIconLevel = -1;
else if (mLteRsrp >= -85) rsrpIconLevel = SIGNAL_STRENGTH_GREAT;
else if (mLteRsrp >= -95) rsrpIconLevel = SIGNAL_STRENGTH_GOOD;
else if (mLteRsrp >= -105) rsrpIconLevel = SIGNAL_STRENGTH_MODERATE;
else if (mLteRsrp >= -115) rsrpIconLevel = SIGNAL_STRENGTH_POOR;
else if (mLteRsrp >= -140) rsrpIconLevel = SIGNAL_STRENGTH_NONE_OR_UNKNOWN;
/*
* Values are -200 dB to +300 (SNR*10dB) RS_SNR >= 13.0 dB =>4 bars 4.5
* dB <= RS_SNR < 13.0 dB => 3 bars 1.0 dB <= RS_SNR < 4.5 dB => 2 bars
* -3.0 dB <= RS_SNR < 1.0 dB 1 bar RS_SNR < -3.0 dB/No Service Antenna
* Icon Only
*/
if (mLteRssnr > 300) snrIconLevel = -1;
else if (mLteRssnr >= 130) snrIconLevel = SIGNAL_STRENGTH_GREAT;
else if (mLteRssnr >= 45) snrIconLevel = SIGNAL_STRENGTH_GOOD;
else if (mLteRssnr >= 10) snrIconLevel = SIGNAL_STRENGTH_MODERATE;
else if (mLteRssnr >= -30) snrIconLevel = SIGNAL_STRENGTH_POOR;
else if (mLteRssnr >= -200)
snrIconLevel = SIGNAL_STRENGTH_NONE_OR_UNKNOWN;
As far as I can tell looking at the code (this is responsible for the number of bars displayed), that it's only LTE that changed from mr0 to mr1.
Probably new radios coming with 4.2 that play into this somehow. Can't imagine they would arbitrarily change the method of displaying signal strength in the notification bar.
Sent from my Galaxy Nexus using xda premium
Winesnob said:
Probably new radios coming with 4.2 that play into this somehow. Can't imagine they would arbitrarily change the method of displaying signal strength in the notification bar.
Sent from my Galaxy Nexus using xda premium
Click to expand...
Click to collapse
Doubt it. Not sure but they changed the mechanism a bit I think. Also this was 4.0.2:
Code:
if (mLteRsrp == -1) levelLteRsrp = 0;
else if (mLteRsrp >= -90) levelLteRsrp = SIGNAL_STRENGTH_GREAT;
else if (mLteRsrp >= -100) levelLteRsrp = SIGNAL_STRENGTH_GOOD;
else if (mLteRsrp >= -110) levelLteRsrp = SIGNAL_STRENGTH_MODERATE;
else if (mLteRsrp >= -118) levelLteRsrp = SIGNAL_STRENGTH_POOR;
else levelLteRsrp = 0;
which was more lenient about showing more bars than 4.2 and 4.0.4 introduced the first signal change for LTE.
As I posted this on rootzwiki I thought I'd share the commit related as someone there posted it for me:
https://github.com/android/platform_frameworks_base/commit/a44b137648c44cc29a8ce43f44a7934ff8045135#telephony/java/android/telephony/SignalStrength.java
Basically it's only a change to signal strength reporting. Would new radios help? I doubt it as signal is hardware/surroundings related.
tiny4579 said:
Basically it's only a change to signal strength reporting. Would new radios help? I doubt it as signal is hardware/surroundings related.
Click to expand...
Click to collapse
If the new radio firmware is interpreting reporting signal levels differently, then the dB values sent to the OS would need a different interpretation. I'm not an expert, but this is my only logical explanation.
Sent from my Galaxy Nexus using xda premium
Winesnob said:
If the new radio firmware is interpreting reporting signal levels differently, then the dB values sent to the OS would need a different interpretation. I'm not an expert, but this is my only logical explanation.
Sent from my Galaxy Nexus using xda premium
Click to expand...
Click to collapse
The change is simply a change in reporting bars. Signal never changed at all. There's no code in any ROM that affects signal itself. What changed I thought was clear in the commit.
The calculations based on SNR and RSRP were adjusted for determining number of bars for LTE. The lowest value wins. This is actually more to unify the different network modes. Also the 3g/CDMA signal uses the weaker of the two for bar reporting instead of always reporting CDMA.
tiny4579 said:
The change is simply a change in reporting bars. Signal never changed at all. There's no code in any ROM that affects signal itself. What changed I thought was clear in the commit.
The calculations based on SNR and RSRP were adjusted for determining number of bars for LTE. The lowest value wins. This is actually more to unify the different network modes. Also the 3g/CDMA signal uses the weaker of the two for bar reporting instead of always reporting CDMA.
Click to expand...
Click to collapse
I read your post and understand what you are saying. What I'm saying is that new radio firmware may "hear" signal levels differently, necessitating a change in the OS code that tells how many signal bars to display for a corresponding perceived signal strength. It's a logical explanation for that change in the android code. I have no doubt that new radio firmware will be pushed with the Toro update when it gets released in another few months.
Sent from my Xoom using xda premium
tiny4579 said:
I've noticed some users have reported inferior signal on Android 4.2 on the LTE Gnex. This is actually not true. In fact below is the related function that changed from 4.1.2 to 4.2.
Jellybean 4.1.2:
https://github.com/android/platform...ny/java/android/telephony/SignalStrength.java
Code:
if (mLteRsrp == -1) levelLteRsrp = 0;
else if (mLteRsrp >= -95) levelLteRsrp = SIGNAL_STRENGTH_GREAT;
else if (mLteRsrp >= -105) levelLteRsrp = SIGNAL_STRENGTH_GOOD;
else if (mLteRsrp >= -115) levelLteRsrp = SIGNAL_STRENGTH_MODERATE;
else levelLteRsrp = SIGNAL_STRENGTH_POOR;
if (mLteRssnr == INVALID_SNR) levelLteRssnr = 0;
else if (mLteRssnr >= 45) levelLteRssnr = SIGNAL_STRENGTH_GREAT;
else if (mLteRssnr >= 10) levelLteRssnr = SIGNAL_STRENGTH_GOOD;
else if (mLteRssnr >= -30) levelLteRssnr = SIGNAL_STRENGTH_MODERATE;
else levelLteRssnr = SIGNAL_STRENGTH_POOR;
int level;
if (mLteRsrp == -1)
level = levelLteRssnr;
else if (mLteRssnr == INVALID_SNR)
level = levelLteRsrp;
else
level = (levelLteRssnr < levelLteRsrp) ? levelLteRssnr : levelLteRsrp;
if (DBG) log("Lte rsrp level: "+levelLteRsrp
+ " snr level: " + levelLteRssnr + " level: " + level);
return level;
}
JB 4.2:
https://github.com/android/platform...ny/java/android/telephony/SignalStrength.java
Code:
if (mLteRsrp > -44) rsrpIconLevel = -1;
else if (mLteRsrp >= -85) rsrpIconLevel = SIGNAL_STRENGTH_GREAT;
else if (mLteRsrp >= -95) rsrpIconLevel = SIGNAL_STRENGTH_GOOD;
else if (mLteRsrp >= -105) rsrpIconLevel = SIGNAL_STRENGTH_MODERATE;
else if (mLteRsrp >= -115) rsrpIconLevel = SIGNAL_STRENGTH_POOR;
else if (mLteRsrp >= -140) rsrpIconLevel = SIGNAL_STRENGTH_NONE_OR_UNKNOWN;
/*
* Values are -200 dB to +300 (SNR*10dB) RS_SNR >= 13.0 dB =>4 bars 4.5
* dB <= RS_SNR < 13.0 dB => 3 bars 1.0 dB <= RS_SNR < 4.5 dB => 2 bars
* -3.0 dB <= RS_SNR < 1.0 dB 1 bar RS_SNR < -3.0 dB/No Service Antenna
* Icon Only
*/
if (mLteRssnr > 300) snrIconLevel = -1;
else if (mLteRssnr >= 130) snrIconLevel = SIGNAL_STRENGTH_GREAT;
else if (mLteRssnr >= 45) snrIconLevel = SIGNAL_STRENGTH_GOOD;
else if (mLteRssnr >= 10) snrIconLevel = SIGNAL_STRENGTH_MODERATE;
else if (mLteRssnr >= -30) snrIconLevel = SIGNAL_STRENGTH_POOR;
else if (mLteRssnr >= -200)
snrIconLevel = SIGNAL_STRENGTH_NONE_OR_UNKNOWN;
As far as I can tell looking at the code (this is responsible for the number of bars displayed), that it's only LTE that changed from mr0 to mr1.
Click to expand...
Click to collapse
You can say this and it might be true, but to flat out say that nothing going on is short sighted. Were you also someone that claimed the n4 could never hold lte BC it lacked an amplifier?
I may not be a Dev for android, but I'm no tech idiot. I code SAS, STATA and a few other stats and db languages. I've been on android since day one and always tinkered around.
I've eliminated every variable possible between the a 4.1 build and a 4.2 build and I can tell you, for me, without a doubt I am getting slower DL speeds on 4.2.
I have flashed back and forth about five times now checking locations where I know the average speeds (my work, my home, my in laws etc...) And in every single location my download speeds are approximately half when using 4.2.
I'm not saying I have the answers, but its not a placebo effect with the way the bars are presented. Something is definitely affecting DL speeds for me on 4.2.
Sent from my Galaxy Nexus using xda app-developers app
mb3030 said:
You can say this and it might be true, but to flat out say that nothing going on is short sighted. Were you also someone that claimed the n4 could never hold lte BC it lacked an amplifier?
I may not be a Dev for android, but I'm no tech idiot. I code SAS, STATA and a few other stats and db languages. I've been on android since day one and always tinkered around.
I've eliminated every variable possible between the a 4.1 build and a 4.2 build and I can tell you, for me, without a doubt I am getting slower DL speeds on 4.2.
I have flashed back and forth about five times now checking locations where I know the average speeds (my work, my home, my in laws etc...) And in every single location my download speeds are approximately half when using 4.2.
I'm not saying I have the answers, but its not a placebo effect with the way the bars are presented. Something is definitely affecting DL speeds for me on 4.2.
Sent from my Galaxy Nexus using xda app-developers app
Click to expand...
Click to collapse
Weird. My LTE signal and download speeds didn't change a bit. What band is VZW using where you are?
Sent from my Nexus 7 using Tapatalk 2
mb3030 said:
You can say this and it might be true, but to flat out say that nothing going on is short sighted. Were you also someone that claimed the n4 could never hold lte BC it lacked an amplifier?
I may not be a Dev for android, but I'm no tech idiot. I code SAS, STATA and a few other stats and db languages. I've been on android since day one and always tinkered around.
I've eliminated every variable possible between the a 4.1 build and a 4.2 build and I can tell you, for me, without a doubt I am getting slower DL speeds on 4.2.
I have flashed back and forth about five times now checking locations where I know the average speeds (my work, my home, my in laws etc...) And in every single location my download speeds are approximately half when using 4.2.
I'm not saying I have the answers, but its not a placebo effect with the way the bars are presented. Something is definitely affecting DL speeds for me on 4.2.
Sent from my Galaxy Nexus using xda app-developers app
Click to expand...
Click to collapse
I'm not saying download speeds are not affected just that there's hard evidence that the signal bars changed to a new algorithm and signal didn't change for me. Can you point in 4.2 an actual change that would affect more than just bars?
I made no claims on the n4. That statement sounds a bit rude.
Sent from my Galaxy Nexus using Tapatalk 2
raw snr value
Is there a mod that displays the raw snr value in the navbar instead of bars?
Maybe I sound a bit rude BC you came into the muzzy thread dismissed my claims and then referred me to this thread, which also dismisses the claims. You then show some code as "proof". I've tested this on my buddy's gnex as well and it has the same issue.
I live in NY and I'm picking up band 13 to answer the other question.
Sent from my Nexus 4 using xda app-developers app
My claims were only to address the change in signal speed and I was trying to give assurance that people's signals did not get worse. Now download speeds could be a result of not having full 4.2 binaries as you know that the binaries Google releases aren't all that's needed for a build of a ROM. Probably the proprietaries from verizon need to be updated to be more compatible. I can see how that may be the case. However my initial post was about the signal and signal only. I didn't mean to start an argument and apologize.
tiny4579 said:
My claims were only to address the change in signal speed and I was trying to give assurance that people's signals did not get worse. Now download speeds could be a result of not having full 4.2 binaries as you know that the binaries Google releases aren't all that's needed for a build of a ROM. Probably the proprietaries from verizon need to be updated to be more compatible. I can see how that may be the case. However my initial post was about the signal and signal only. I didn't mean to start an argument and apologize.
Click to expand...
Click to collapse
This. ^^^^^^
New radios will be packaged with the Verizon approved OTA. New OS + new binaries + old radio firmware= suboptimal results.
Sent from my Galaxy Nexus using xda premium
Winesnob said:
This. ^^^^^^
New radios will be packaged with the Verizon approved OTA. New OS + new binaries + old radio firmware= suboptimal results.
Sent from my Galaxy Nexus using xda premium
Click to expand...
Click to collapse
We actually may not even have all the new binaries but I'm not an expert on that. What I do know is good things should come from a Verizon OTA to 4.2 - if they release it.
I wonder if anyone's tried tweeting verizonwireless or vzwsupport about Android 4.2. Since I refuse to get a twitter account I haven't done it yet.
tiny4579 said:
We actually may not even have all the new binaries but I'm not an expert on that. What I do know is good things should come from a Verizon OTA to 4.2 - if they release it.
I wonder if anyone's tried tweeting verizonwireless or vzwsupport about Android 4.2. Since I refuse to get a twitter account I haven't done it yet.
Click to expand...
Click to collapse
You can Tweet until your battery is dead, and it won't do any good. Expect the official update in late January, and a leaked OTA sometime late December or early January.
Sent from my Galaxy Nexus using xda premium
Glad to hear its a software fix that's making me believe I have bad signal...come on Verizon bring on ota 4.2
tiny4579 said:
...good things should come from a Verizon OTA to 4.2 - if they release it.
Click to expand...
Click to collapse
http://www.randomphantasmagoria.com/myths-about-android-updates-on-the-verizon-galaxy-nexus/ - Myth #3.
mb3030 said:
Maybe I sound a bit rude BC you came into the muzzy thread dismissed my claims and then referred me to this thread, which also dismisses the claims. You then show some code as "proof". I've tested this on my buddy's gnex as well and it has the same issue.
I live in NY and I'm picking up band 13 to answer the other question.
Sent from my Nexus 4 using xda app-developers app
Click to expand...
Click to collapse
Strange. I'm on AWS LTE and wasn't affected at all, I'll be on a different band this weekend and I'll check again, seems it might be a band issue related to location.
Sent from my Nexus 7 using Tapatalk 2
So I just did a speed test on cm10.1 and for 3g I got 1.5mbps down and for 4g I got 13mbps down. That's about normal for my area. I can link a post explaining how little effect the ROM has on speed but from a testing perspective I don't see anything speed related broken by 4.2.
Sent from my Galaxy Nexus using Tapatalk 2

Categories

Resources