Understanding WiFi Performance - Samsung Galaxy S (4G Model)

Understanding WiFi Performance - Samsung Galaxy S (4G Model)

There has been a lot of reports of WiFi not performing as well with the current crop of ICS ROMs as compared to GB ROMs. There certainly is a difference in the reported signal strength between them; that is not debated. The question is if there is a performance difference between ICS ROMs and GB ROMs.
This thread discusses how WiFi works under Android, some opinions about what is "different" between GB and current ICS ROMs, and provides tools that allow one to perform tests about the actual performance of the WiFi of a specific configuration, as well as the reported RSSI.
Brief summary:
The important measure of WiFi performance is throughput.
The RSSI is the "Reported Signal Strength Indication" -- not a measurement of actual field strength. The RSSI is provided mainly as an indication of signal strength and is subject to "calibration" at several points; it does not measure performance. The link speed reported also does not measure performance; in fact, it has been shown that higher link speeds can result in lower throughput as the modulation and error correction schemes are different.
The throughput of WiFI connections have been tested comparing "stock" (with AntonX kernel) GB to an early stable build of AOKP. Testing was done under controlled conditions using strong and weak signals, from three APs; a WRT-54g with "rubber duckie" antennas in a cross-pol configuration, a WRT-54g with a cross-pol flat-panel gain antenna, and one WNDR3700 with its internal antenna. All APs were running OpenWRT and interconnected using GigE trunking through Netgear GS108T and Netgear GS724Tv2 switches. The power output of these were all controlled and adjusted from their maximum transmit power to the level at which the throughput dropped below 1 Mbps. At least five measurements were made for every configuration and power level.
No significant difference in throughput was seen between GB and ICS. In some cases, the ICS test performed slightly better than the GB test. Differences were less than 10%.
The RSSI from the supplicant appeared to be in dB; a 10 dB reduction in transmit power reduced the RSSI by approximately 10 on both GB and ICS configurations. However the reference point for them were very different; GB reporting positive numbers over 200 and ICS reporting negative numbers roughly in the -50 to -100 range.
As the throughput performance is comparable on both ROMs, it is believed that the "issues" being seen are related to the "calibration" of the RSSI. Lower levels than Android code expects have two primary impacts:
The UI represents the same actual signal strength with fewer bars
Android will not display or connect to certain APs as their RSSI is lower than its fixed threshold

In depth:
A basic understanding of how WiFi works in general, as well as in Linux is valuable.
The Broadcom BCM4329 data sheet has a block diagram that may be useful in understanding the chip's functions. I'll go through the recieve end of things, since that is where the "signal strength" information comes from. The transmit side is similar.
There is an antenna in the phone that converts radio-frequency (RF) electrical signals to radio waves and vice versa. This has a "gain" that relates the strength of the electrical signal and the strength of the radio wave.
Inside the chip, the RF signal is converted to a "baseband" signal using an analog-to-digital converted (ADC) and sent to an internal processor. The processor uses microcode to know how to demodulate the signal (extract the "bits" from the shape of the RF waves). Based on the numbers from the ADC, a number roughly representing "signal strength" is computed. For example, "32768" from the demodulated signal may mean "100" for signal strength. This reference point is picked by the chip manufacturer and might mean something in terms of physical signal strength (dbM, for example), when using the chip manufacturer's reference board. If you change the antenna, for example, it is no longer "calibrated" to anything. This demodulation process uses microcode that is downloaded into the chip on initialization by the driver. The chip also handles the low-level WiFi protocol; how to change channels, how to "associate" with a given access point (AP), how to scan available APs, how to do encryption, etc. This microcode is proprietary and generally supplied by the chip manufacturer.
There is a driver in the Linux kernel that is responsible for how to communicate with the chip and access its low-level functions in a "device independent" way. Think of it as someone that brings another person into the room with you, tells you who they are, then translates their Urdu to English and vice versa so you can have a conversation. This is open source in the kernel.
In most devices, from dedicated WiFi devices, through our phones and just about any computer running Linux, the next "person" in the chain is the "supplicant" -- It handles high-level commands and responses, including:
* Providing a list of available APs
* Connecting to a specific AP
* Managing lists of passwords for APs
* Providing the "Reported Signal Strength Indication" or RSSI
This is open source code in the Linux distribution
One thing to remember here is that RSSI is just that, reported and an indication of the signal strength. There is no guarantee what the numbers mean! By the time you get here, you've got an unknown antenna gain, a ADC-counts-to-strength conversion in the chip, and potentially another conversion in the driver.
Many phones and other devices have that factor in a "calibration file" that makes the output of the RSSI "look good" on the device's UI, or to other code in the device. This generally comes from the device manufacturer and it proprietary. In some cases, this has been reverse-engineered or supplied by the vendor. Other devices may have a /proc/calibration device, which can be used to send calibration information to the driver. This includes the bcm4329 driver in use by the "ICS" kernels:
Code:
config BCM4329_NVRAM_PATH
depends on BCM4329
string "NVRAM path"
default "/proc/calibration"
---help---
Path to the calibration file.
Code:
CONFIG_WLAN=y
CONFIG_BCM4329_PURE_ANDROID=y
CONFIG_BCM4329=m
CONFIG_BCM4329_FW_PATH="/system/vendor/firmware/fw_bcm4329.bin"
CONFIG_BCM4329_NVRAM_PATH="/system/vendor/firmware/nvram_net.txt"
That file contains some "magic incantations" including
Code:
# 11g rssi params
rssismf2g=0xa,0xa,0xa
rssismc2g=0xb,0xb,0xa
rssisav2g=0x3,0x3,0x3
From there, we go to the Android level. Java code communicates with the supplicant and gets lists of APs, their RSSI, and supplies passwords, when needed. With the information it has on RSSI, it converts it to "bars" using something equally arbitrary. You can look at the source in frameworks/base/wifi/java/android/net/wifi/
In WifiManager.java you can see how Android views WiFi and how it handles things. You can even see how to "fix" the issue at the Android level from this (the commented-out MIN_RSSI and MAX_RSSI are "stock" -- the numbers there are ones that are based on the throughput measurements I made).
Code:
/** Anything worse than or equal to this will show 0 bars. */
// private static final int MIN_RSSI = -100;
private static final int MIN_RSSI = -95;
/** Anything better than or equal to this will show the max bars. */
// private static final int MAX_RSSI = -55;
private static final int MAX_RSSI = -65;
Code:
/**
* Calculates the level of the signal. This should be used any time a signal
* is being shown.
*
* @param rssi The power of the signal measured in RSSI.
* @param numLevels The number of levels to consider in the calculated
* level.
* @return A level of the signal, given in the range of 0 to numLevels-1
* (both inclusive).
*/
public static int calculateSignalLevel(int rssi, int numLevels) {
if (rssi <= MIN_RSSI) {
return 0;
} else if (rssi >= MAX_RSSI) {
return numLevels - 1;
} else {
float inputRange = (MAX_RSSI - MIN_RSSI);
float outputRange = (numLevels - 1);
return (int)((float)(rssi - MIN_RSSI) * outputRange / inputRange);
}
}
If you're not Java-saavy, what is basically happening there is that Android says there are numLevel "bars" and they lie evenly between the MIN_RSSI and MAX_RSSI values. Other code reveals that anything below MIN_RSSI isn't shown to the user and isn't a candidate for a connection.
So, where does this leave us?
Changing your ROM shouldn't change the antenna on the device. So that's out.
The microcode is supplied by Broadcom and they'd have sales problems if it was bad, so I'll rule that one out too.
There is the possibility that the calibration in the driver has changed. Given the way that the display of the RSSI was bouncing around when those GB leaks were coming out, this seems like a strong possibility. (If anyone has those leaks still available, please let me know. I'd like to look at them and most were hosted on now-FBI-ified websites).
There are proprietary drivers from Broadcom, as well as three open-source versions in the Linux distribution. These include microcode. "We" are using one of the open-source ones. If it were "bad" then the SGS4G wouldn't be the only thing out there with an issue. I doubt this is the problem. The same goes for the supplicant; it is too widely used to have a significant issue.
So, this basically leaves "calibration" of the numbers reported by the chip to numbers that work well with Android.

How to test it yourself:
First, realize that anything, metal, plastic, wood, a glass of water, your mouse, your body, even your hand, within about two feet of your phone or the AP can dramatically change how it receives and sends the 2.4 GHz radio waves. Differences in position of about a centimeter are significant compared to the ~12.5 cm wavelength. For my test, I had a corner of my desk with a ridge so I could very accurately place the phone into the exact same place. I also taped down my USB cable (for adb), so it would be in the same place each time.
I ran two kinds of tests. The first is using netperf, which measures the throughput of the connection. This is really what matters -- not what some number of bars say, but how fast can I reliably send data over the link. I used TCP so that the impact of packet loss was included. You'll need a machine that can run netperf, as well as a binary for your phone. I've attached a binary built from source using the AOSP build tools. You can also use the Android NDK.
The second is to look at the average RSSI reported by the supplicant. The attached Perl script assumes that have adb running, then polls the supplicant every second for the BSSID (AP name) you specify in the code. It provides the read RSSI, as well as exponential averages over 10, 100, and 1000 samples.

I'm having trouble using Wifi tether. When ever I try to connect I get an error that says "WTF!! Your phone is automatically shutting off the connection" lol it was pretty funny first time I saw it. The wifi tether signal still shows up on the devices I connect to but they don't register it. Is there any work around or fix? I used the roms codename and beam for this btw.
Sent from my SGH-T959V using xda app-developers app

Very informative post like usual, thanks jeff.
Although the wifi signal is the same as gingerbread, it seems to disconnect in places where gingerbread wouldn't. For example, in my room I have no wifi signal bars in ics (it still shows the wifi icon though) and it tends to disconnect every now and then (this only happens when the signal isn't good. On gingerbread it always stays at 1 or 2 bars and never disconnects.
Is it possible to keep the wifi from disconnecting?
Sent from my SGH-T959V using xda app-developers app

pisherthefisher said:
[The WiFi] seems to disconnect in places where gingerbread wouldn't. For example, in my room I have no wifi signal bars in ics (it still shows the wifi icon though) and it tends to disconnect every now and then (this only happens when the signal isn't good. On gingerbread it always stays at 1 or 2 bars and never disconnects.
Is it possible to keep the wifi from disconnecting?
Click to expand...
Click to collapse
You should be able to "hack in 10 more" -- I haven't taken the time yet to determine if the kernel/driver is the best place to do it, or if it is in calculateSignalLevel() as shown above, or somewhere else.
For me, I find that if the signal level is that low, I have better throughput with T-Mobile, at least here in the San Francisco Bay Area. I realize others have different needs than I do and I'll be looking at it again with the "Aries" kernel for the SGS4G.

jeffsf said:
There has been a lot of reports of WiFi not performing as well with the current crop of ICS ROMs as compared to GB ROMs. There certainly is a difference in the reported signal strength between them; that is not debated. The question is if there is a performance difference between ICS ROMs and GB ROMs.
Click to expand...
Click to collapse
Thanks for this thread.

Related

Changing MTU from 1428 to 1500 Yielding Speed Boost

I performed a cursory search and was not able to find much on this board, but feel free to point me in the right direction if I missed something.
I have always wondered why the MTU is set to 1428 in System>>Build.prop file. Knowing that my desktop computer does just fine using an MTU setting of 1500, I decided to test the impact that setting the MTU to 1500 would have on 4G LTE and Wifi speeds.
The results were surprising, but may not be repeatable for those who wish to try this. I live in Southeast Houston, which may help some of you to decide whether or not to try this. I accept no responsibility for damage to your phone, business, life or anything else if you do.
MTU 1428 (90+ Days)
4G LTE: Average 7-13 Mbps Down, Record 18 Mbps
Wifi 802.11n (Asus RT-N56U): Average 10-20 Mbps Down, Record 27 Mbps
MTU 1500 (24 Hours, Limited Data)
4G LTE: Consistent 17 Mbps Down
Wifi 802.11n (Asus RT-N56U): Consistent 13 Mbps Down
I realized a 5+ Mbps boost on 4G LTE Download speeds (Results will vary)
Standard Caution - back up your phone in case something goes wrong
Step #1 - Use Root Explorer or equivalent to create a copy of System>>Build.prop and place copy on SD Card (I use the Download folder)
Step #2 - Open the copy of the Build.prop you created and locate the default MTU entry, which should be 1428, change this entry to either 1492 (DSL) or 1500 (Cable) and save the change
Step #3 - Use edited copy of the Build.prop file to overwrite the one in System>>Build.prop
Step #4 - Reboot your phone and test your 3G/4G and Wifi speeds for improvement/degredation and repeat steps above to find optimal setting (Max=1500)

My buddy works at the Columbus Vzw building and is a 4G engineer. When I spoke to him last week he JUST mentioned the MTU as well and said its going to be changed with an OTA radio update. He said theyre always working on radio updates but whether or not they are all released is another question ha.

biglipps66 said:
My buddy works at the Columbus Vzw building and is a 4G engineer. When I spoke to him last week he JUST mentioned the MTU as well and said its going to be changed with an OTA radio update. He said theyre always working on radio updates but whether or not they are all released is another question ha.
Click to expand...
Click to collapse
I forgot to mention that my 4G LTE upload speed average increased and became consistent as well. I am now seeing 8 Mbps Upload in a location that had averaged 3-5 Mbps before I changed the MTU to 1500. My Wifi is limited to 2-3 Mbps Upload, so I am not sure how my Upload speed would be on a connection with more bandwidth.

I've been running 1492 since you posted it and giving it a try out. Doesn't seem to help the tether speed, but helps the phones speed of loading pages in the browser, tapatalk to servers, and loading news much quicker.

savagebunny said:
I've been running 1492 since you posted it and giving it a try out. Doesn't seem to help the tether speed, but helps the phones speed of loading pages in the browser, tapatalk to servers, and loading news much quicker.
Click to expand...
Click to collapse
Glad to hear! I have used this tweak for years on Windows computers, so it makes sense that it should work on our phones as well. My only concern was data fragmentation, but that does not seem to be an issue for me. Mileage will vary though, so improvements are not guaranteed for all.

Been using stock since day one, today just broke 60mbps here in NYC:
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Been seeing 40's and 50's on a daily basis. Never changed the MTU.
Maybe once I root the device I'll mess with it.

Yep, web browser seem to load qicker than usual, tether is no changed, speed test many times ;/ buddy, how u config that on your window pc anyway?
Sent from my ADR6400L using Tapatalk

davidkim99b said:
Yep, web browser seem to load qicker than usual, tether is no changed, speed test many times ;/ buddy, how u config that on your window pc anyway?
Sent from my ADR6400L using Tapatalk
Click to expand...
Click to collapse
The easiest way to do this on a Windows computer is to visit Speedguide.net and run the TCP/IP Analyzer utility (Link on Bottom-Left of site's main page), then, if needed, download the TCP/IP Optimizer. This utility is a portable app, so there is nothing to install. Just remember that a reboot is needed for changes to take effect.
Here is the manual method for setting MTU on a Windows computer:
1. Open a command line window as an Administrator (ie. Right-Click on All Programs > Accessories > Command Prompt and select Run as administrator)
2. Type the command 'netsh' and wait for prompt
3. Type the command 'interface' and wait for prompt
4. Type the command 'ipv4' and wait for prompt
5. Type the command 'set subinterface "Local Area Connection" mtu=xxxx store=persistent'
6. Reboot
Hope this helps. I know a lot of Windows tweaks, including many Registry settings that are not well known. Perhaps I will put together a self-help document if there is any interest.
Here is a good starting point: http://www.speedguide.net/articles/windows-7-vista-2008-tweaks-2574 (Mods, please remove this link if it violates the TOS here)

milan03 said:
Been using stock since day one, today just broke 60mbps here in NYC:
Been seeing 40's and 50's on a daily basis. Never changed the MTU.
Maybe once I root the device I'll mess with it.
Click to expand...
Click to collapse
Using the newly leaked 906 radios, my download speed jumped from 17 to 40 Mbps yesterday on 4G LTE! Upload & Wi-Fi Speeds remained unchanged for the most part.
I didn't believe it at first, so I reset the MTU to 1428, rebooted my phone and my Download speed returned to the 13-20 Mbps range. Changed the MTU back to 1500, rebooted and jumped right back to 40 Mbps.
I encourage others to try changing the MTU setting to 1500 (For those using Cable) or 1492 (For those using DSL)

stupid question here, but would this increase speeds while in a 3g area or the mtu specifically for 4g data rates?

vdChild said:
stupid question here, but would this increase speeds while in a 3g area or the mtu specifically for 4g data rates?
Click to expand...
Click to collapse
MTU is not specifically tied to either 3G or 4G. In fact, this setting is used on Windows based computers all the way back to the early versions of Windows. MTU is used to optimize the connection between the host and client. If MTU is set too low, bandwidth is reduced because more packets of data are managed. If MTU is set too high, fragmentation will occur and there will usually be a need for more re-transmissions of data. As a rule, 1500 is the Maximum MTU setting for cable based internet, while 1492 is the maximum for DSL.
"A larger MTU brings greater efficiency because each packet carries more user data while protocol overheads, such as headers or underlying per-packet delays, remain fixed; the resulting higher efficiency means a slight improvement in bulk protocol throughput. A larger MTU also means processing of fewer packets for the same amount of data. In some systems, per-packet-processing can be a critical performance limitation."
http://en.wikipedia.org/wiki/Maximum_transmission_unit (Mods, please remove this link if it violates the TOS here)

Lyondellic said:
MTU is not specifically tied to either 3G or 4G. In fact, this setting is used on Windows based computers all the way back to the early versions of Windows. MTU is used to optimize the connection between the host and client. If MTU is set too low, bandwidth is reduced because more packets of data are managed. If MTU is set too high, fragmentation will occur and there will usually be a need for more re-transmissions of data. As a rule, 1500 is the Maximum MTU setting for cable based internet, while 1492 is the maximum for DSL.
"A larger MTU brings greater efficiency because each packet carries more user data while protocol overheads, such as headers or underlying per-packet delays, remain fixed; the resulting higher efficiency means a slight improvement in bulk protocol throughput. A larger MTU also means processing of fewer packets for the same amount of data. In some systems, per-packet-processing can be a critical performance limitation."
http://en.wikipedia.org/wiki/Maximum_transmission_unit (Mods, please remove this link if it violates the TOS here)
Click to expand...
Click to collapse
Everything you said is correct, but just to elaborate for those that might get mixed up, MTU has *nothing* to do with windows itself nor did Microsoft create the protocol. MTU predates Windows by some years and was set up as part of the greater Internet Protocol and OSI Model by DARPA in the late 70s/early 80s.
In theory, a larger MTU is a good thing, assuming the connection can handle the larger MTU. Slower connections trying to handle a high MTU can cause a bottleneck and lead to less efficiency than greater though. When that happens, it has to slice up the data units into smaller pieces (fragmentation).
Think of it as like having to carry a stack of bricks from one end of your yard to the other. Sure, if you're strong, you can carry a ton at once, but if you're not and you try to do so, you're going to have a heck of a time getting them from point A to point B and probably end up having to split up the load, slowing yourself down as you do so.

yareally said:
Everything you said is correct, but just to elaborate for those that might get mixed up, MTU has *nothing* to do with windows itself nor did Microsoft create the protocol. MTU predates Windows by some years and was set up as part of the greater Internet Protocol and OSI Model by DARPA in the late 70s/early 80s.
In theory, a larger MTU is a good thing, assuming the connection can handle the larger MTU. Slower connections trying to handle a high MTU can cause a bottleneck and lead to less efficiency than greater though. When that happens, it has to slice up the data units into smaller pieces (fragmentation).
Think of it as like having to carry a stack of bricks from one end of your yard to the other. Sure, if you're strong, you can carry a ton at once, but if you're not and you try to do so, you're going to have a heck of a time getting them from point A to point B and probably end up having to split up the load, slowing yourself down as you do so.
Click to expand...
Click to collapse
Thanks for filling in the gaps. I sometimes skim over information that requires a little more clarity, so I thank you for chiming in.

Edit: Nevermind. I changed to 1492 cause I use DSL at home so we shall see if I can get some better speeds with this change.

Mustang302LX said:
Edit: Nevermind. I changed to 1492 cause I use DSL at home so we shall see if I can get some better speeds with this change.
Click to expand...
Click to collapse
Guys you're forgetting your LTE service is not DSL. If you're changing MTU which by the way is "maximum transmission unit" and have been in existence way before Windows, use 1500. LTE is a flat IP based technology, and it doesn't matter if your home (WiFi) connection is DSL, you're using Verizon's 4G LTE and that's where you're applying MTU. 1492 is used on home computers that are wired connected to a DSL modem.

milan03 said:
Guys you're forgetting your LTE service is not DSL. If you're changing MTU which by the way is "maximum transmission unit" and have been in existence way before Windows, use 1500. LTE is a flat IP based technology, and it doesn't matter if your home (WiFi) connection is DSL, you're using Verizon's 4G LTE and that's where you're applying MTU. 1492 is used on home computers that are wired connected to a DSL modem.
Click to expand...
Click to collapse
I'll change it to 1500 then. Thanks.

btw I've been using stock since the launch date, and am seriously considering rooting for the first time after seeing this post. MTU can definitely help the throughput and I've been wondering for a long time if tweaks are possible on Android platform.
I know it's sounds noob (and when it comes to rooting I am) which leaked radios currently give the best data performance?
this is what I'm currently seeing on my Bolt: http://www.youtube.com/watch?v=RTwRm3QMqUs
I wonder if I can get closer to that 73.6mbps maximum theoretical throughput.
Thank you.

You must live underneath a cell tower. Lol. Highest ive seen on my phone is 25 down and 10 up.
Sent from my HTC ThunderBolt using Tapatalk

It's NYC lol. Every corner has some kind of pico cell and it's usually fed by preexistent fiber. NYC is loaded with dark fiber.
Still trying to figure out if I should just root and flash with that latest Gingerbread RUU or should I just keep it stock. I'm just trying to get the best possible data performance, don't really care too much about the features of the ROM.

milan03 said:
Guys you're forgetting your LTE service is not DSL. If you're changing MTU which by the way is "maximum transmission unit" and have been in existence way before Windows, use 1500. LTE is a flat IP based technology, and it doesn't matter if your home (WiFi) connection is DSL, you're using Verizon's 4G LTE and that's where you're applying MTU. 1492 is used on home computers that are wired connected to a DSL modem.
Click to expand...
Click to collapse
This is true for 3G/4G, but not when the phone is connected to Wi-Fi. A max MTU setting of 1492 is needed when connected to a Wi-Fi network that originates from DSL.

[REF] Tweaking the GPS for Speed and Accuracy

I don't take credit for this, I'm just basically confirming that if you are inside the US, the following tweak should improve lock speeds and accuracy. I was able to lock on inside my house < 10 secs, with a 6 meter accuracy. It's been done on a number of phones -- just posting it for the folks here who haven't found the tweak yet.
It requires root - see the threads in this forum.
To install it, you should create a backup of your /system/etc/gps.conf file before doing anything. The easiest way is to use Root Explorer and then copy the file to somewhere on your sd card. (Make a directory, or put it in a safe place).
[ Edit: Sorry, I'm having trouble getting the new file attached - the links below work (I think) but look sort of funny ]
Download and unzip the file View attachment 784134, then copy the attached file to /system/etc/gps.conf. Reboot or power off/on and you are done. (Again, use Root Explorer if you aren't comfortable enough with terminal/adb shell to do this on your own.)
Alternately you can edit your existing file with the text editor of your choice. All you are doing is replacing the NTP server and adding the SUPL lines at the bottom.
Code:
# Thanks to Da_G from the xda-forums for additional information on data for
# the below changes. Switch to the us.pool.ntp.org for better time resolution
# inside the US, but the xtra1 servers are good worldwide. You can
# Also just choose one of the below *.pool.ntp.org areas for where you plan
# to use your GPS.
########################################
###Uncomment only one NTP_SERVER line!##
########################################
##### US Time Servers
NTP_SERVER=us.pool.ntp.org
##### Worldwide
#NTP_SERVER=xtra1.gpsonextra.net
##### Continental Servers
##### Asia
#NTP_SERVER=asia.pool.ntp.org
##### Europe
#NTP_SERVER=europe.pool.ntp.org
###North America
#NTP_SERVER=north-america.pool.ntp.org
XTRA_SERVER_1=http://xtra1.gpsonextra.net/xtra.bin
XTRA_SERVER_2=http://xtra2.gpsonextra.net/xtra.bin
XTRA_SERVER_3=http://xtra3.gpsonextra.net/xtra.bin
# DEBUG LEVELS: 0 - none, 1 - Error, 2 - Warning, 3 - Info
# 4 - Debug, 5 - Verbose
DEBUG_LEVEL = 5
# Intermediate position report, 1=enable, 0=disable
INTERMEDIATE_POS=0
# GPS Capabilities bit mask
# SCHEDULING = 1
# MSB = 2
# MSA = 4
# default = MSA | MSB | SCHEDULING
CAPABILITIES=0x7
# The SUPL_HOST and SUPL_PORT lines below can be commented out if
# you will be using your GPS outside the AT&T network and/or outside.
# the US. The Skyrocket is configured to use the AT&T servers by
# default, and Da_G's says that the AT&T has a more accurate
# geolocation database.
#SUPL_HOST=supl.google.com
#SUPL_PORT=7276
After you have made the changes reboot your phone. (power off/on)
Here's the gps.conf file - just unzip it and replace. It is *NOT* something that can be flashed, just the conf file: View attachment 784134
Enjoy.

tejones36 said:
I don't take credit for this, I'm just basically confirming that if you are inside the US, the following tweak should improve lock speeds and accuracy. I was able to lock on inside my house < 10 secs, with a 6 meter accuracy.
...
Click to expand...
Click to collapse
My phone already does this, even while indoors. Has anyone been having worse GPS quality?

Mine was at 25ft previously. It's been reported on quite a few forums to improve both lock time (mine improved here as well) and accuracy.

Two seconds to first lock with 3 sats. 4 seconds later floating between 9 and 10 sats locked.
F'n sweet. No tweaks needed.

gheck911 said:
Two seconds to first lock with 3 sats. 4 seconds later floating between 9 and 10 sats locked.
Click to expand...
Click to collapse
Mine improved from 5m to 3m accuracy indoors and better lock times so I thought I'd share something I found useful.

Daedalus_ said:
My phone already does this, even while indoors. Has anyone been having worse GPS quality?
Click to expand...
Click to collapse
Same here. We shouldn't be scaring people into thinking that the SR has accuracy issues.

Dranakin said:
Same here. We shouldn't be scaring people into thinking that the SR has accuracy issues.
Click to expand...
Click to collapse
By that logic, we shouldn't be building custom kernel's or ROMs - we shouldn't be scaring people into thinking that the SR has UI or development issues right?

tejones36 said:
By that logic, we shouldn't be building custom kernel's or ROMs - we shouldn't be scaring people into thinking that the SR has UI or development issues right?
Click to expand...
Click to collapse
You know that's not even a logical analogy. Don't be a douche now.

Does this file work on all GB devices, or at least Samsung devices, or at least least an Infuse?
thx

Yup, pretty much everything that I've seen so far.
Sent from my SAMSUNG-SGH-I727 using Tapatalk

(nothing to see here, move along...)

How is the GPS Lock and Tracking say compared to HTC or Motorola? Just wondering because I am debating on going back to BB tomorrow and swapping out my HTC Vivid for this phone. Just slightly worried as I have hear horror stories about Samsung and horrible GPS.

malickie said:
How is the GPS Lock and Tracking say compared to HTC or Motorola? Just wondering because I am debating on going back to BB tomorrow and swapping out my HTC Vivid for this phone. Just slightly worried as I have hear horror stories about Samsung and horrible GPS.
Click to expand...
Click to collapse
I don't know about either of those phones, but I had the Captivate which was pretty horrible. both the SGS2 and the skyrocket are excellent right out of the box with none of those problems.
This post was meant to be about getting that last couple percent of accuracy and lock time, or to possibly help if someone had a restricted view of the sky via the SUPL lines at the bottom of the config along with closer geographic time servers. I've used the GPS heavily in the last couple of weeks and it's been terrific.
( Obviously the Skyrocket was only released this past Sunday, but I was using the OGS2 prior to returning it for the Skyrocket upgrade. )

tejones36 said:
I don't know about either of those phones, but I had the Captivate which was pretty horrible. both the SGS2 and the skyrocket are excellent right out of the box with none of those problems.
This post was meant to be about getting that last couple percent of accuracy and lock time, or to possibly help if someone had a restricted view of the sky via the SUPL lines at the bottom of the config along with closer geographic time servers. I've used the GPS heavily in the last couple of weeks and it's been terrific.
( Obviously the Skyrocket was only released this past Sunday, but I was using the OGS2 prior to returning it for the Skyrocket upgrade. )
Click to expand...
Click to collapse
Very good to know. I am actually one of those that has issues getting gps lock in my house not sure even this will help considering I have a tin roof. Still good to know that this has good GPS out of the box.

(wave) Hi
On the topic of this thread,
I did some disassembly on the GPS kernel module, and it is looking at 3 seperate config files for configuration infos. /etc/gps.conf, /data/data/angryGps/secgps.conf (i think there's a com.android in there, have to go double check, don't remember from memory) and /etc/loc_parameter.ini.
loc_parameter.ini appears to be the most interesting one, with a number of previously undocumented configurations. Notably the GPS is always defaulting to start up in "driving mode" vs. "pedestrian mode" which anyone familiar with the function of GPS will know means there is a filtering algorithm active to prevent some GPS updates from getting to the user (if the location has not moved more than 5 meters in any direction since the last update, assume this falls within the margin of error and report no movement)
Pedestrian mode is desirable in many cases as there are no GPS reports filtered out and you get the constant position updating every second.
Also the GPS driver reports 1Hz update mode, which is common for consumer level GPS receivers. More expensive/higher level receivers can report as fast as 3 times per second. It might be possible to tweak our GPS to perform similarly (boy wouldn't that be sweet)
Lastly, the GPS driver defaults to full verbosity in logcat output. This might be slightly detrimental to performance and flipping a simple bit in loc_parameter.ini cuts the amount of output by a large amount with every position update.
Out of box the GPS daemon is configured to use AT&T's SUPL server, so switching to google's SUPL server should actually be detrimental to GPS time-to-first-fix performance, since AT&T has a much more accurate geolocation database driving their SUPL platform vs. google. Outside of the US however, I imagine google's SUPL server will perform better. Also, outside of AT&T's data network their SUPL server is not accessible, so this is another case switching to google's SUPL server would be advantageous.
Further disassembly tonight

Da_G,
Thanks for the very informative post! Glad to see someone well versed in the subject commenting.
Da_G said:
I did some disassembly on the GPS kernel module, and it is looking at 3 seperate config files for configuration infos. /etc/gps.conf, /data/data/angryGps/secgps.conf (i think there's a com.android in there, have to go double check, don't remember from memory) and /etc/loc_parameter.ini.
loc_parameter.ini appears to be the most interesting one, with a number of previously undocumented configurations.
.
.
Click to expand...
Click to collapse
This does sound pretty interesting and worth playing with. Is there an easy way (like killing a process, like in system panel or from a terminal) to get the process to reread the config file short of a reboot? I have no idea if mobile phones can take a kill -HUP <pid> and reread, or just a -TERM and the system restarts it.
Pedestrian mode is desirable in many cases as there are no GPS reports filtered out and you get the constant position updating every second.
Click to expand...
Click to collapse
That does sound interesting - I wonder if the "pedestrian" routing on google maps actually does something besides changing how it routes - maybe it also changes the gps functionality as well?
It might be possible to tweak our GPS to perform similarly (boy wouldn't that be sweet)
Click to expand...
Click to collapse
Definitely!
Lastly, the GPS driver defaults to full verbosity in logcat output. This might be slightly detrimental to performance and flipping a simple bit in loc_parameter.ini cuts the amount of output by a large amount with every position update.
Click to expand...
Click to collapse
If you'd like me to include that file with instructions in the first post, I can certainly do so (and properly accredit you of course).
Out of box the GPS daemon is configured to use AT&T's SUPL server, so switching to google's SUPL server should actually be detrimental to GPS time-to-first-fix performance, since AT&T has a much more accurate geolocation database driving their SUPL platform vs. google. Outside of the US however, I imagine google's SUPL server will perform better. Also, outside of AT&T's data network their SUPL server is not accessible, so this is another case switching to google's SUPL server would be advantageous.
Click to expand...
Click to collapse
Good to know. What amount of time do you think the first fix might be delayed, order of magnitude wise? (1s, 10s, etc.) I'd trade a short period of time for better global/rural data possibly, but it's good to know the trade offs.
Further disassembly tonight
Click to expand...
Click to collapse
Awesome, thanks for the info!

So I tried to download the attachment didnt work. Then I tried to put in that information and rebooted. But it still doesnt lock on with google maps.

atomoverride said:
So I tried to download the attachment didnt work. Then I tried to put in that information and rebooted. But it still doesnt lock on with google maps.
Click to expand...
Click to collapse
I've included the full file now in the main post, it's working on my phone. Here's a copy of the file as well - I'll try to relink it in the original post.
gps.zip - gps.conf replacement: View attachment gps.zip

@Da_G
Is the 5 meter update condition meant to filter out noise from inaccuracy? Does increasing the Hz on the position update compromise battery life?
@tejones36
Earlier I wasn't trying to be rude, I was just saying that my GPS works fine and if yours isn't it might've been broken.

What is the address for AT&T supl? Or does it default to this if you have no supl lines?

[Q] Any interest in radio.img/amss.bin?

Has anyone been able to extract amss.bin from radio.img? Or the efs filesystem (Not the same as /efs btw.)?
Would anyone be interested in helping me rip apart a radio image?
I've googled around looking for any instances of extracting the radio firmware from radio.img and have come up with nothing.
More information for those who know less about the baseband:
What is it?
AMSS is the name Qualcomm gives the software that runs the phones modem. When the modem software is compiled, it is encrypted and stored in a file called amss.bin. There is a small entry point in amss.bin which decrypts the image into the phones memory during boot and then executes it.
What does it do?
Its job is to find, connect, and decode cell phone signals and convert them to usable data. In most older cell phones the phones operating system was a part of this as well, but with android the modem runs along side android (Question: Is it a separate processor for the baseband? or is it somehow multiplexed with android on the main CPU?)
This software reads settings that were set either by the phone itself (2G/3G or 4G data, PRL on cdma, APN settings, and other radio related things.) or by the carrier/manufacturer (NVRAM) and changes its behavior accordingly.
It then accepts commands and gives responses to another piece of software (In this case android) which does something useful with the phones modem. (Dials a phone number, connects to a data service, etc) and lets the software know when events happen (Text messages, incoming calls, etc)
The modem firmware (amss.bin) is inside radio.img for the nexus s 4g, This much should be blatantly obvious. However, the phones EFS filesystem (FAT12 IIRC) is also located here as well. radio.img may be encrypted or compressed, (Why it takes so long to flash a radio update to the nexus s 4g)
Why?
With access to amss.bin it can be decrypted and disassembled to show the phones true inner workings, and I may be able to develop a solution to the absolutely terrible data speeds for the nexus s 4g (No matter where I go, with 3 different D720's now, I get 56k dialup speeds and once in a great while it will go up to 3g, unless I'm sitting right next to my airave.) or at least have an insight as to why this phones data is so slow.
How do you know all of this?
I originally tried to get android running on a Samsung Eternity, I was able to decode the first part of AMSS.BIN but then realized that writing the radio interface layer for android was going to be a real challenge, not to mention that the phones hardware was barely capable of running 1.5 (And by barely I mean not really capable at all). But I learned an awful lot about the internals of Qualcomm phones along the way, and even wrote a small utility to edit the boot images and EFS filesystem (In this case, EFS also held the OS itself, not just the radio stuff)

Great read. I have no experience in this, nor any worthwhile software experience so I doubt i can help you, but if you think I can just let me know. I havn't experienced any particular issues on my GSM Nexus though. It's not like I get to use data very often anyway considering how little data i have and the state of Vodas current data network.
Question: Is it a separate processor for the baseband? or is it somehow multiplexed with android on the main CPU?
Answer: On phones like the Nexus S where the "Sleep" state (and even "Deep Idle" state) shuts off the CPU entirely, there must be a seperate low-power processor just for decoding and sorting through cell signals. This, in turn, will wake up the main CPU when something happens (call, text message, push notification, etc). That should clear a little up for you.

If I had skills required I would gladly help you, But I don't. It seems like you have done your homework, and done this before, so what exactly do you need help with? Re-writing it?
By the way that was a very interesting read!
Sent from my Nexus S 4G using XDA App

Very good read, and useful info. Have you tried mounting the radio.img in Linux, yet? I don't know exactly how to do it, but you should be able to. I run Linux dual booted with Windows, and have mounted the system.img no problem. I tried with the recovery.img, but no luck. I think you have to mount it as another filesystem.

mabry said:
Very good read, and useful info. Have you tried mounting the radio.img in Linux, yet? I don't know exactly how to do it, but you should be able to. I run Linux dual booted with Windows, and have mounted the system.img no problem. I tried with the recovery.img, but no luck. I think you have to mount it as another filesystem.
Click to expand...
Click to collapse
I doubt that radio.img would mount, Android is based on linux and uses linux filesystems. The radio is different, its more the same class as a bootloader (or rather, somewhere between). It does have a filesystem in that radio.img, but its likely encrypted.
Code:
Mar 15 17:45:28 localhost kernel: EXT3-fs (loop0): error: can't find ext3 filesystem on dev loop0.
Mar 15 17:45:28 localhost kernel: EXT2-fs (loop0): error: can't find an ext2 filesystem on dev loop0.
Mar 15 17:45:28 localhost kernel: EXT4-fs (loop0): VFS: Can't find ext4 filesystem
Mar 15 17:45:28 localhost kernel: SQUASHFS error: Can't find a SQUASHFS superblock on loop0
Mar 15 17:45:28 localhost kernel: FAT-fs (loop0): bogus number of reserved sectors
Mar 15 17:45:28 localhost kernel: FAT-fs (loop0): Can't find a valid FAT filesystem
Mar 15 17:45:28 localhost kernel: FAT-fs (loop0): bogus number of reserved sectors
Mar 15 17:45:28 localhost kernel: FAT-fs (loop0): Can't find a valid FAT filesystem
Mar 15 17:45:28 localhost kernel: ISOFS: Unable to identify CD-ROM format.
Mar 15 17:45:28 localhost kernel: hfs: unable to find HFS+ superblock
Mar 15 17:45:28 localhost kernel: hfs: can't find a HFS filesystem on dev loop0.
Mar 15 17:45:28 localhost kernel: ufs was compiled with read-only support, can't be mounted as read-write
Mar 15 17:45:28 localhost kernel: UDF-fs: warning (device loop0): udf_load_vrs: No VRS found
Mar 15 17:45:28 localhost kernel: UDF-fs: Rescanning with blocksize 2048
Mar 15 17:45:28 localhost kernel: UDF-fs: warning (device loop0): udf_load_vrs: No VRS found
Mar 15 17:45:28 localhost kernel: UDF-fs: warning (device loop0): udf_fill_super: No partition found (1)

NS4G.John said:
If I had skills required I would gladly help you, But I don't. It seems like you have done your homework, and done this before, so what exactly do you need help with? Re-writing it?
By the way that was a very interesting read!
Sent from my Nexus S 4G using XDA App
Click to expand...
Click to collapse
I need help getting amss.bin out of radio.img. I know how to deal with amss.bin once I have it, but I cannot find it in radio.img by signature (And indeed it would be hard to find anyway, due to how many signatures there are, and the length of the file is unknown.)
I mean, to clarify, I know I'm looking right at it, and I know when I'm in the middle of it. but I don't get where it starts and ends. And that is the important part.
A string dump of radio.img makes it appear as though the radio is un-encrypted. I could be wrong.
Stuff that makes me think its unencrypted:
Code:
desktop crespo4g # strings radio.img | grep amss
amss_start = 0x%x, amss_size = 0x%x
Code:
desktop crespo4g # strings radio.img | grep AMSS
0:AMSS
0:AMSS
0:AMSS
0:AMSS
0:AMSS
0:AMSS
AMSS
AMSS
AMSS_BOOT
AMSS_FILL_PAD_1
AMSS_EMPTY_PAD_1
AMSS_ZI_REGION
AMSS_EMPTY_PAD_2
AMSS_AUTOGENERATED_CODE_1
AMSS_AUTOGENERATED_CODE_2
AMSS_MODEM_CODE_1
AMSS_FILL_PAD_2
AMSS_MODEM_DATA_2
AMSS_MODEM_DATA_1
AMSS_APP_RAM
AMSS_FILL_PAD_3
AMSS_INTERNAL_BOOT_RAM_1
AMSS_INTERNAL_BOOT_RAM_2
AMSS_FILL_PAD_4
AMSS_MAIN_APP_2
AMSS_MAIN_APP_3
AMSS_MAIN_APP_4
AMSS_MAIN_APP_4_REDBEND
AMSS_FILL_PAD_5
AMSS_MAIN_APP_DATA_1
AMSS_FILL_PAD_6
AMSS_SHARED_RAM
AMSS_EMPTY_PAD_3
AMSS_UNINIT_RAM
AMSS_EMPTY_PAD_4

Harbb said:
Great read. I have no experience in this, nor any worthwhile software experience so I doubt i can help you, but if you think I can just let me know. I havn't experienced any particular issues on my GSM Nexus though. It's not like I get to use data very often anyway considering how little data i have and the state of Vodas current data network.
Question: Is it a separate processor for the baseband? or is it somehow multiplexed with android on the main CPU?
Answer: On phones like the Nexus S where the "Sleep" state (and even "Deep Idle" state) shuts off the CPU entirely, there must be a seperate low-power processor just for decoding and sorting through cell signals. This, in turn, will wake up the main CPU when something happens (call, text message, push notification, etc). That should clear a little up for you.
Click to expand...
Click to collapse
If you look at things like XEN, it would be entirely possible that the host os (radio, in this case) is trapping and preventing CPU halting. As a matter of fact I believe that the evidence points in the opposite direction due to the fact that "Deep Idle" produces no measurable battery savings. Its entirely possible, and perhaps likely, that the radio acts as a sort of, hypervisor, that controls Android's access to the underlying hardware. I don't know if this type of virtualization is available on ARM though. It really could go either way. And even in a halt state, interrupts are usually still possible, So the radio may be running inside of a timer even.
The crespo/d720/Nexus S 4G/Whatever else you'd like to call it, has severe issues regarding data speeds. Sprint pretends the issue doesn't exist, Samsung pretends the issues doesn't exist, Google is mostly powerless because its a radio issue that Sprint and Samsung are responsible for fixing. Hacking this radio may be the solution, but I've gotta get amss.bin out of radio.img. Until I do, there is nothing I can do either.

Quick update
Pouring over radio.img I came across the following string
Code:
NICTOKL4 - (provider: Open Kernel Labs) built on May 19 2009 00:21:02 using
gcc version 3.4.4.
What does this mean?
It mean's that AMSS Runs on the same CPU as android, and that it runs as a Hypervisor (Microvisor as Open Kernel Labs calls it). It has control over what the android kernel has access to. This is pure speculation, but I would guess this is why Deep Idle doesn't provide any real tangible benefit when it really should.

Thanks for the informative read. D

plaguethenet said:
If you look at things like XEN, it would be entirely possible that the host os (radio, in this case) is trapping and preventing CPU halting. As a matter of fact I believe that the evidence points in the opposite direction due to the fact that "Deep Idle" produces no measurable battery savings. Its entirely possible, and perhaps likely, that the radio acts as a sort of, hypervisor, that controls Android's access to the underlying hardware. I don't know if this type of virtualization is available on ARM though. It really could go either way. And even in a halt state, interrupts are usually still possible, So the radio may be running inside of a timer even.
The crespo/d720/Nexus S 4G/Whatever else you'd like to call it, has severe issues regarding data speeds. Sprint pretends the issue doesn't exist, Samsung pretends the issues doesn't exist, Google is mostly powerless because its a radio issue that Sprint and Samsung are responsible for fixing. Hacking this radio may be the solution, but I've gotta get amss.bin out of radio.img. Until I do, there is nothing I can do either.
Click to expand...
Click to collapse
Unfortunately a lot of your work is out of my league. However, Deep Idle (and the Sleep state, and even the idle state) all have proven benefits in various ways. Deep Idle shuts off the processor for, generally (for music), 19ms out of 20ms if i remember correctly. Idle would clock the processor at zero in much the same way, however i don't understand exactly what benefit (or process) there is to it aside from effectively minimizing power consumption (estimating CPU power consumption relies on the frequency, turning this to 0 in a perfect system would eliminate power use with the processor "on".. in theory). Either way, even Idle has shown power savings - while idle is used there is a far lower power draw. Without it, the results are much more believable and expected for the frequency, showing that it saves power by clocking the cpu to 0.
Further, i havn't tried this myself, but isn't Android perfectly capable to run without a radio at all? Because of this i highly doubt the radio is a hypervisor of any sort aside from anything radio-specific. I'm fairly certain the Radio acts more like a WoL chip, invoking the rest of the system as soon as it is triggered. Some reading material, maybe those two links add some insight too.
There is evidence of my argument here. Maybe you have confused Deep Idle and Sleep, but either way the two have proven benefits.
One thing to note, all of this is done on GSM Nexus S'. It could very well be different for the 4G CDMA radio, and even for the i9020A variant (i have the i9023 and think bedalus has a i9020T - ONLY difference is the screen). I have no experience with either the i9020A or 4G so it's all hearsay if it comes from me.

Harbb said:
Unfortunately a lot of your work is out of my league. However, Deep Idle (and the Sleep state, and even the idle state) all have proven benefits in various ways. Deep Idle shuts off the processor for, generally (for music), 19ms out of 20ms if i remember correctly. Idle would clock the processor at zero in much the same way, however i don't understand exactly what benefit (or process) there is to it aside from effectively minimizing power consumption (estimating CPU power consumption relies on the frequency, turning this to 0 in a perfect system would eliminate power use with the processor "on".. in theory). Either way, even Idle has shown power savings - while idle is used there is a far lower power draw. Without it, the results are much more believable and expected for the frequency, showing that it saves power by clocking the cpu to 0.
Further, i havn't tried this myself, but isn't Android perfectly capable to run without a radio at all? Because of this i highly doubt the radio is a hypervisor of any sort aside from anything radio-specific. I'm fairly certain the Radio acts more like a WoL chip, invoking the rest of the system as soon as it is triggered. Some reading material, maybe those two links add some insight too.
There is evidence of my argument here. Maybe you have confused Deep Idle and Sleep, but either way the two have proven benefits.
One thing to note, all of this is done on GSM Nexus S'. It could very well be different for the 4G CDMA radio, and even for the i9020A variant (i have the i9023 and think bedalus has a i9020T - ONLY difference is the screen). I have no experience with either the i9020A or 4G so it's all hearsay if it comes from me.
Click to expand...
Click to collapse
Quite the opposite, I was saying that because android and the RTOS (Real time os, for the radio) run under a "Microvisor" which is much like XEN, Android can halt the CPU all it wants, but the underlying OS that is virtualizing android wont really allow it. There are others that say the opposite of deep idle. I myself have noticed no benefit from it.
This is the results of a real study about battery life, specifically stating that deep idle does nothing, and indeed, as I noted above, I myself have also noticed no benefit. (But it SHOULD give a MAJOR benefit, which is why its so puzzling)
You can read it here.
I'll go into a bit more detail to clarify:
The phones basic startup process is:
Hardcoded Cryptographically secure bootloader -> NICTOKL4 (OS Hypervisor, or as OKL calls it, Microvisor)
NICTOKL4 Starts up the RTOS, and FASTBOOT
Fastboot then loads either the battery charging screen, Android, or Recovery (Or boots into fastboot mode) depending on the state of the phone.
(I could be wrong about what launches what, and may be missing, but I know that RTOS and Androids boot code are started at the same time by the microvisor)
RTOS Is running at all times after the phone is first powered on after having the battery removed, However it will disconnect from the cell network and sleep if told to, or if it has nothing to talk to. (Airplane mode and "off")
This is very similar to say, Linode. Where BIOS/EFI Loads an OS (The hypervisor Dom-0) and that OS Launches multiple guest OS's (Dom-U)
NICTOKL4 Is the only part of the phone that has true access to the hardware, and marshalls requests (usually blocking requests) to modify other OS Memory space, or access hardware.
The radio itself is actually just another guest OS, running under NICTOKL4. Android is entirely capable of running without a radio, but not on a phone without replacing the radio with android boot code.
Back to Deep Idle and Sleep. Sleep can be done and should provide benefit, because the microvisor can sleep too. Guest Sleeps, Microvisor sees all guests sleeping, so it sleeps too.
However, the radio software absolutely requires realtime communication with the hardware and network, or else synchronization would be lost. So halting the CPU (As deep idle does) cannot be allowed by the radio, and therefore cannot be allowed by the microvisor.
The information about the microvisor is fact by the way, I've found it in the radio.img for both my phone, and the i90xx radios.
I'm not trying to outright reject what you're saying Harbb, I just feel like I'm having trouble translating what I know into words others can understand.
You can learn more about the microvisor and its capabilities here

plaguethenet said:
Quite the opposite, I was saying that because android and the RTOS (Real time os, for the radio) run under a "Microvisor" which is much like XEN, Android can halt the CPU all it wants, but the underlying OS that is virtualizing android wont really allow it. There are others that say the opposite of deep idle. I myself have noticed no benefit from it.
This is the results of a real study about battery life, specifically stating that deep idle does nothing, and indeed, as I noted above, I myself have also noticed no benefit. (But it SHOULD give a MAJOR benefit, which is why its so puzzling)
You can read it here.
Click to expand...
Click to collapse
That battery life Portal post was a preliminary finding, which now is FOR deep idle, not against it. The thread that is linked to in it actually takes you to the same thread that i posted above proving my argument on deep idle. Go through the first 5 or so posts in the thread it links to, you'll find my own findings and bedalus' findings, and now even nathanson666's findings which is basically a deep idle experiment under a 1kHz ampmeter which provides proof to the millisecond level (which is where deep idle works). The larger problem with deep idle is that there is very little besides music that can truly benefit from deep idle, aside from it helping the surrounding OS very slightly while awake with the screen off.
Also, do you mind clarifying the bolded part a bit more?
plaguethenet said:
I'll go into a bit more detail to clarify:
The phones basic startup process is:
Hardcoded Cryptographically secure bootloader -> NICTOKL4 (OS Hypervisor, or as OKL calls it, Microvisor)
NICTOKL4 Starts up the RTOS, and FASTBOOT
Fastboot then loads either the battery charging screen, Android, or Recovery (Or boots into fastboot mode) depending on the state of the phone.
(I could be wrong about what launches what, and may be missing, but I know that RTOS and Androids boot code are started at the same time by the microvisor)
RTOS Is running at all times after the phone is first powered on after having the battery removed, However it will disconnect from the cell network and sleep if told to, or if it has nothing to talk to. (Airplane mode and "off")
This is very similar to say, Linode. Where BIOS/EFI Loads an OS (The hypervisor Dom-0) and that OS Launches multiple guest OS's (Dom-U)
NICTOKL4 Is the only part of the phone that has true access to the hardware, and marshalls requests (usually blocking requests) to modify other OS Memory space, or access hardware.
The radio itself is actually just another guest OS, running under NICTOKL4. Android is entirely capable of running without a radio, but not on a phone without replacing the radio with android boot code.
Back to Deep Idle and Sleep. Sleep can be done and should provide benefit, because the microvisor can sleep too. Guest Sleeps, Microvisor sees all guests sleeping, so it sleeps too.
However, the radio software absolutely requires realtime communication with the hardware and network, or else synchronization would be lost. So halting the CPU (As deep idle does) cannot be allowed by the radio, and therefore cannot be allowed by the microvisor.
The information about the microvisor is fact by the way, I've found it in the radio.img for both my phone, and the i90xx radios.
I'm not trying to outright reject what you're saying Harbb, I just feel like I'm having trouble translating what I know into words others can understand.
You can learn more about the microvisor and its capabilities here
Click to expand...
Click to collapse
I am doing much the same, only friendly discussion here I don't have time at the moment but i'll get to reading some more on this soon.
Anyway. I can guarantee that the main CPU can entirely halt and effectively freeze EVERYTHING in the phone so long as the screen is off and nothing is keeping it awake, and likely the exact same thing happens with Deep Idle but while processing something (this runs on the race-to-idle principle, even if slightly lower clocks may be more efficient here - hurry the hell up so i can shut down the CPU). If such a thing can happen, how can you conclude that the CPU must stay awake? This is why i've narrowed it down to another chip that must be aiding the radio.
I'd write more but i must get going. Keen to see where this takes us.

Harbb said:
That battery life Portal post was a preliminary finding, which now is FOR deep idle, not against it. The thread that is linked to in it actually takes you to the same thread that i posted above proving my argument on deep idle. Go through the first 5 or so posts in the thread it links to, you'll find my own findings and bedalus' findings, and now even nathanson666's findings which is basically a deep idle experiment under a 1kHz ampmeter which provides proof to the millisecond level (which is where deep idle works). The larger problem with deep idle is that there is very little besides music that can truly benefit from deep idle, aside from it helping the surrounding OS very slightly while awake with the screen off.
Also, do you mind clarifying the bolded part a bit more?
Click to expand...
Click to collapse
The radio is a real time operating system. I'd imagine that halting the CPU and bringing it back up is too costly for the radio, and therefore would be prevented by the radio. As far as WoL like functionality, I don't see any chip on the board that could provide that for the radio (or indeed anything for that matter). The only thing that has any radio capability is the main Application Processor, which has to be shared.
Harbb said:
I am doing much the same, only friendly discussion here I don't have time at the moment but i'll get to reading some more on this soon.
Click to expand...
Click to collapse
I get a bit excited and tend to get very technical and often miss things or seem like I'm trying to argue when i'm not. I just wanted to clarify that it wasn't intended as such.
Harbb said:
Anyway. I can guarantee that the main CPU can entirely halt and effectively freeze EVERYTHING in the phone so long as the screen is off and nothing is keeping it awake, and likely the exact same thing happens with Deep Idle but while processing something (this runs on the race-to-idle principle, even if slightly lower clocks may be more efficient here - hurry the hell up so i can shut down the CPU). If such a thing can happen, how can you conclude that the CPU must stay awake? This is why i've narrowed it down to another chip that must be aiding the radio.
I'd write more but i must get going. Keen to see where this takes us.
Click to expand...
Click to collapse
The freezing may only be for android though, You can independenly suspened/halt and resume virtualized applications (Either at their request, or preemptively). So its entirly possible for Deep Idle to behave properly in android, but not have the overall effect that one would think it would have. The processor would have much less to do and as such it likely does have some effect but the allowing an OS to execute such a disruptive instruction defeats the purpose of virtualization, if that makes any sense. Indeed the virtualized machine is halted, and nothing else is executing in the virtualized instance during this time. But the radio and Microvisor are very much alive during this. (You wouldn't be able to get an incoming call if they weren't.)
So in summary my argument is this:
Android cannot completely disable the CPU, this would cause NUMEROUS issues with the underlying radio software. WoL/WoR like functionality would be implemented in the radio software, From a development standpoint the complications FAR outweigh the benefits of such a design, It would not be fiscally responsible to design radio software in this way. If the processor were truly off, the microvisor would be unable to run and it would defeat the purpose of having said microvisor in the first place.
It would appear to android that the CPU Was off, and everything would halt (for android only). This should produce some battery savings (As even when idle an android system as some upkeep to do), but no where near the kind of savings you'd see with a truly halted CPU (that is woken by external interrupts). I will admit I was unaware additional testing was done.
If the system was truly halted for any period of time, When it was woken, the radio would be disconnected and would have to reconnect. You'd lose the ability to get notified of an incoming call or text (and to the cell network, your phone would be offline). You'd know if the cpu was TRULY frozen/halted/suspended.
Now, I'm not saying that the CPU Can't be put into a stopped state, just that android itself cannot make this happen. The microvisor would need permission from the radio, and the microvisor itself, would also need to be set to sleep as well. The radio is unlikely to give permisison, and as long as the microvisor, any of its children, or server processes, require the CPU, it will not actually happen. But the OS that halted itself will enter a fake halted state. (In reality, the hyper/microvisor would replace a HLT with a NOOP and stop executing the child. To the child this seems like being halted, but other things are still at work here.)

Another quick thought on deep idle. Perhaps the radio spends alot of time sleeping. Ideally it would know how often to wake up the delay may be as large as 50ms, which would explain the battery savings.

I don't know how often the phone would be polling the tower so can't comment on how often the radio would be sleeping, however i can say that i've had averages of around 50-60ms of deep idle time and possibly more. This is of course with the radio active.
I did try to erase the radio in fastboot, and BOOM! an error. It won't let me erase it to see how far it would boot. I'd rather not flash a bad file purposely, so i can't give any hard evidence on the radio being a primary boot initiator or kernel of sorts.
The minimum frequency of the CPU is 100mhz to my knowledge. Anything below this will likely get more and more inefficient and potentially useless. This is why on the Tegra 3's we now have a quad core main CPU + a little, much weaker (and much more efficient) core dedicated to low loads and the ability to rapidly switch between any setup you can imagine. Couldn't such interfaces such as WoL/WoR be entirely integrated into the radio chip?
Maybe i'm entirely deluded here, but i've yet to find hard evidence on either side and i'm leaning toward the ability to entirely shut off the CPU so far. Right now though, anything's possible.

Harbb said:
I don't know how often the phone would be polling the tower so can't comment on how often the radio would be sleeping, however i can say that i've had averages of around 50-60ms of deep idle time and possibly more. This is of course with the radio active.
I did try to erase the radio in fastboot, and BOOM! an error. It won't let me erase it to see how far it would boot. I'd rather not flash a bad file purposely, so i can't give any hard evidence on the radio being a primary boot initiator or kernel of sorts.
The minimum frequency of the CPU is 100mhz to my knowledge. Anything below this will likely get more and more inefficient and potentially useless. This is why on the Tegra 3's we now have a quad core main CPU + a little, much weaker (and much more efficient) core dedicated to low loads and the ability to rapidly switch between any setup you can imagine. Couldn't such interfaces such as WoL/WoR be entirely integrated into the radio chip?
Maybe i'm entirely deluded here, but i've yet to find hard evidence on either side and i'm leaning toward the ability to entirely shut off the CPU so far. Right now though, anything's possible.
Click to expand...
Click to collapse
I cant comment on tegra's design, I've never played with anything with a Tegra chipset. What I am speaking of is Qualcomm specific, its not a general truth for all phones. The problem with WoR/WoL in the radio chip, is all the radio chip does is pass demodulated data to the radio software, and modulate data thats going out on a requested frequency. ie, the radio hardware is dumb, and does exactly what its name implies, its a radio. It may be possible for it to say "Hey, I have data" but that would happen so frequently it would be pointless.
Erasing the radio would require JTAG to get the phone booted again, At least, I am 90% sure. The flash software for the radio also verifies the cryptographic signature and CRC's, so you won't be able to flash a "bad" radio at all. Only way to simulate this would be to yank the battery during a radio flash. But I believe there are also systems in place to prevent this from bricking the phone as well. If someone has a phone to sacrifice, this would be an interesting experiment and would yield some clues as to the boot process.
Also, On the tegra's, they may use a dedicated baseband processor instead of virtualizing it on the main CPU like the MSM chipsets do. If you want to point me to some tegra radio flash images I can give you some insight.

plaguethenet said:
I cant comment on tegra's design, I've never played with anything with a Tegra chipset. What I am speaking of is Qualcomm specific, its not a general truth for all phones. The problem with WoR/WoL in the radio chip, is all the radio chip does is pass demodulated data to the radio software, and modulate data thats going out on a requested frequency. ie, the radio hardware is dumb, and does exactly what its name implies, its a radio. It may be possible for it to say "Hey, I have data" but that would happen so frequently it would be pointless.
Erasing the radio would require JTAG to get the phone booted again, At least, I am 90% sure. The flash software for the radio also verifies the cryptographic signature and CRC's, so you won't be able to flash a "bad" radio at all. Only way to simulate this would be to yank the battery during a radio flash. But I believe there are also systems in place to prevent this from bricking the phone as well. If someone has a phone to sacrifice, this would be an interesting experiment and would yield some clues as to the boot process.
Also, On the tegra's, they may use a dedicated baseband processor instead of virtualizing it on the main CPU like the MSM chipsets do. If you want to point me to some tegra radio flash images I can give you some insight.
Click to expand...
Click to collapse
Good thing my phones smarter than me then, but it would've made a damn pretty paperweight
By the way, my suspicions seem to be correct, The Nexus S does have an integrated Baseband Processor, it can be found in step 10 of that page. Courtesy of iFixIt, of course.
After a quick look i couldn't find a radio for the Tegra 3s but i'm sure they'll pop up soon in the HTC One forums soon, even though it may not mean much now.

Harbb said:
Good thing my phones smarter than me then, but it would've made a damn pretty paperweight
By the way, my suspicions seem to be correct, The Nexus S does have an integrated Baseband Processor, it can be found in step 10 of that page. Courtesy of iFixIt, of course.
After a quick look i couldn't find a radio for the Tegra 3s but i'm sure they'll pop up soon in the HTC One forums soon, even though it may not mean much now.
Click to expand...
Click to collapse
Thats not a processor, Its an antenna selector and noise filter. SPI is too slow to handle GSM/UMTS/CDMA traffic.
Its purpose is to select the frequency band, detect if there is a signal, and select an antenna (Low gain, hi gain, etc) and connect the antenna to something else with the correct frequency. Thats all it really does.
You can see for yourself in the functional diagram located in this PDF: http://www.skyworksinc.com/uploads/documents/201206b.pdf
The radio of the Tegra would me most interesting to me, and but certainly not relevant to this project.
EDIT: Apologies, I missed the Infineon chip. I'll have to see if i can find a data sheet for it to see what it can do. I'll get back to you as soon as I know more.
EDIT2:
I found this PCI-Express card that uses the same baseband processor, The PDF has a pinout of the same baseband chip.
http://module.amod.com.tw/files/Product/2012215113150.pdf
It seems to me that this does most of the protocol/baseband processing, and makes me curious as to why they multiplex the application CPU At all in this case? This makes no sense to me. I mean, I know they do, and I know AMSS.BIN is supposed to run the radio, but it seems like it may be more of a driver between RIL and that chip in this case. Question is, why not write the RIL to use the chip directly using GPIO pins on the CPU? Puzzling...
More questions than answers. But in this case, WoL/WoR functionality is possible at least on GSM Models. Although it's more likely a hardware event (Interrupt) that would wake the processor anyway. Perhaps the seperate modem software is to implement extra AT commands for the modem, and hide the interrupts from Android's RIL? I wonder if we can send random AT Commands to that chip... I'll see what I can figure out with my phone.

Good luck mate. Let us know your progress.

Reading this conversation is quite intriguing.
Where can I find more information to feebly attempt to gain knowledge of what I've just read (besides Google )?

[APP][2.3+] Advanced Signal Status 1.5.1

Annoyed at the lack of network signal information for your Android phone?
Wish you could know more about the statistics your carrier uses to determine many bars your phone has and the tower it connects to?
Want to see what your 3g and 4g signals are at the same time?
Try out this app and see all that information you've been missing!
App works best for phones with either a CMDA or LTE data connection, but may work for GSM only phones as well.
Note: not all information may be available depending on the OEM/OS. Info not displayed will show as "N/A"
Any feedback, suggestions for improvement, etc are welcome
UPDATE (2015-05-01):
-1.5.1 changes -
► Regression fix network shortcut
UPDATE (2015-05-01):
-1.5 changes -
► I can't fix devices not working for the network settings shortcut because Samsung locks down their phones. Rooted Samsung devices generally work. Pick what is more important, network switching or owning a Samsung device
► bugfixes (crashed instead of telling user device was locked down)
► Translations for French & Spanish. Thank you contributors
► Updated Google libs (Lollipop issues)
► App is now written in Scala, yay
UPDATE (2014-01-06):
► Devices with root/super user can now access the "additional settings area" if they were being blocked by Samsung and their carrier (Note 3 / Galaxy S4 / etc). Contact me if you experience issues and have root
► GSM ECIO added for supported devices
► Bug fixes (Huawei and a few older LG)
► Overhaul of the parser that grabs the readings from the system. More flexible with older devices
► Performance enhancements. Using async for tasks
UPDATE (2013-09-03):
Added RSSI signal for GSM/HSPA devices
LTE SNR and CDMA/EVDO ECIO are now listed in decibels instead of the Android default of centibels.
Few bug fixes for devices crashing on startup. If it still crashes for you, you need to contact me for fixes.
UPDATE (2013-06-04):
Fixed a bug for anyone on Android 2.2. Google for some reason in their wise choice decided to leave out Arrays.copyof() in Android 2.2, despite it being a core part of the Java JDK. I decided to use it for something, assuming it was there (because why wouldn't it be, heh). Anyways, if you're on Android 2.2, it should show up in the Android Market later today
UPDATE (2013-06-03):
Bug fix that would cause the app to close when rotating the screen.
Relative percentages were adjusted a bit based on feedback.
UPDATE (2013-06-02):
Lots of improvements (see screenshot below):
- New ways to monitor your signal quality via easy to read percentages %
- Monitor your signal based on 0-100% percentages
- ActionBar + options area for all
- Performance/stability improvements.
Compare your signal quality based on % instead of just decibels. Now, you can instantly see how great each signal reading is for your device based on a scale of 0% (worst) to 100% (best). Percentages are configured to give the best reading for your carrier by default.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
UPDATE (2013-01-13): Performance tweaks through code cleanup and restructuring. If nothing else is needed, next version will have some new information for GSM users and maybe some other things if I have time.
A few users were getting a permission denied error/crash when accessing additional settings (Huawei M865C & Samsung Galaxy Ace). Access problem is with your phone's current OS and the manufacturer so I cannot fix it. However, the crash will no longer happen and you get a friendly message.
UPDATE (2012-12-20): I have no idea what devices a few people have as it just shows as OTHER (probably non-approved devices running Android), but this fix is to keep them from crashing. However, I don't know how much info those devices will see if they aren't totally compliant.
Also a fix for devices that don't support the additional info/settings area that Google adds for devices and some manufacturers remove (like those with the Galaxy Note 1). You still won't see it as it's beyond my control, but it won't crash.
UPDATE (2012-12-11): Array out of bounds error fixes for devices like the Galaxy Y and ZTE Warp. If you never had crashes, then no reason to update as there's nothing else new.
UPDATE (2012-12-07): Fixed for anyone most likely getting a force close due not having full network support. If the app is not working on your phone (mostly seems to be a few GSM ones), please contact me and we can figure out the issue.
Added the app version number at the bottom of the app.
Added a button to reach your additional phone radio/network settings. Please only use this button and change the settings under it if you're sure of what you're doing
UPDATE (2012-11-13): Fixed a crash bug for users on Android 2.3 and before.
UPDATE (2012-11-12): Now added to the Android Market. The app on the market has a small banner ad to support my continued development, but the version below (scroll down) does not have them. Otherwise, they are the same.
New in Update (2012-11-12):
Bug fixes - few fields showed values when they shouldn't for phones that don't supply all the stats (like the Galaxy S3).
Performance enhancements - Much of the code was rewritten to be smaller and more efficient
Android compatiblity - Should now work on any Android phone with Android 2.2 or later, regardless of carrier or network type (GSM, LTE, CDMA).
UPDATE (2012-05-29): Created an app to test your signal. If you give out the link to the app, please link directly to the topic and not the apk/app itself so that people can read the topic before getting it. App signal readings update every time the phone notifies of a signal change. So in other words, it updates as often as the signal does under settings → status. RSRP is the same signal you see under there if you wanted to match it up. Also added more to the definitions for the terms shown in the app in my post above so you can see how they equate to your signal quality. App should work on Android 2.2 and above and on any sort of carrier (including GSM), but it may not show everything for non-ics devices.
NEXT UPDATE: add logging to the app and give stats on the signal logs taken (mean, median, standard deviation, variance, etc). Maybe a built in "speedtest" for your connection as well.
If anyone has any suggestions for things to add to it, feel free to let me know.
--Download Links--
If you like what I do and wish to support further development of this app in my spare time, feel free to get this one instead. It's the same as the version below, just with a small banner ad. I make next to nothing off ads, so it's just peanuts.
Non Play Store Version
This version is the same as the market version, but for those that don't/won't use the play store. You won't be able to update from the market most likely due to market licensing unless you overwrite it with the market version (may also have to uninstall).
It's available here
Basic App Source (to prove data shown is correct): https://github.com/yareally/SignalInfo. App is written in Scala. There's also an older Java version (for Android 2.2+ devices) I no longer support in the same repository. Questions about the Java version will be ignored as I don't support it.
Screen Shot:
--Android Signal Info Statistics Information--
All other LTE phones (excluding the Nexus) are reporting the RSSI of the cdma 1x signal in android 2.3, NOT the LTE signal. Android 2.3 was not capable of properly reporting the LTE signal and support was added for it in ICS. Phones on Android 4.0 and above also use RSRP to determine your signal. RSRP has a huge difference to RSSI (for example):
RSSI = -79 dBm, RSRP = -93 dBm
This is why a Motrola Razr or HTC Rezound will show -79 dBm in the same spot a GNex will display -93 dBm if you are comparing it with Android 2.3 to a phone using Android 4.0+.
Also, the higher your ASU under settings the better. ASU or "Arbitrary Strength Unit" is an integer value proportional to the Reference Signal Received Power (RSRP) measured by the mobile phone. The higher the number for ASU, the less interference you have between you and the towers. It varies by your current type of connection, but ASU a number in the range of 0 to 99 (99 means you have no signal [unknown] and closer to 0 means it's also bad).
Your ASU on LTE is your current signal + 140. So if you have a signal of -93, then your LTE based ASU is (-93 + 140 = 47). See picture below for example:
Technically, your ASU will never be 98, as it hits a ceiling of 97 and if you were somehow able to get a signal of -43db (-43 + 140 = 97). If your signal is somehow worse than -140, then it will report zero, but that should also not be possible.
It's a little more complicated for CDMA ASU. On CDMA, it's some power of 2 up to 16 (1, 2, 4, 8, 16) with 16 being the best or 99 if it's unknown. It's also measured by not only your signal in db, but also by your your signal to noise ratio which is not shown to you.
Source for the above was SignalStrength.java under getLteAsuLevel()
If you're wondering how the signal bars for phones using Android 4.0 or above are computed, they mostly follow the following specification. The bars are mostly just a relative measurement based on what we think is good or bad as we already knew. However, Google did adjust them to make them to look like you have a "better" signal in 4.0.4 though for LTE if you had a device with Android 4.0.2 or 4.0.1.
The below link is a reference to the above mentioned change:
https://github.com/a...28b7fc2f6ef8bce
The link shows how they were before/after 4.0.4. Mostly increased everyone's LTE bars in most cases by 1 bar, but the change was only visually and not a performance increase.
Google also uses the signal to noise ratio (SNR) to determine whether your normal signal statistic listed under settings gets priority or the SNR for showing the bars now. They take the one that looks better and use that for mapping to the bars as shown here: https://github.com/a...5a9b6889851d887
Signal To Noise ratio is just a computed number based on how much interference is in your connection. It's not exactly the best measure for data as it's just measuring interference.
--------------------------------------------------------------------------------
Before you start comparing your signal to other phones not on ICS, at least read this and look at this link to the Android source for ICS:
Use LTE SNR and RSRP to set signal level bar.
The LTE signal strength level is the smaller one
between lte rsrp level and lte snr level if both
rsrp and snr are valid.
Click to expand...
Click to collapse
In short, Android now uses the RSRP data to measure how many bars you see and also is what is shown under settings when you're on LTE 4G.
Definitions:
RSRP:
Reference signal received power (RSRP), is defined as the linear average over the power contributions in Watts of the resource elements that carry cell-specific reference signals within the considered measurement frequency bandwidth. Used to measure the signal of your LTE (GSM/4g) connection. In short, it's what's used to determine the best cell tower your LTE device can connect to at the given time. Anything below say -80db is considered pretty good and you're pretty close to a tower. -80db to -90db is average what you should expect most of the time. -90db or above and you're probably in an "extended network" area for LTE and getting close to a likely handoff. -105db and above you would be likely to see a handoff to 3G if your signal does not get better.
Throughput for your connection measured with LTE is estimated to decline between 30-50% if your signal goes from -75db to -90db for RSRP. Above -95db and your throughput dramatically drops. At around -108db and worse, your throughput for download drops to nearly 3G rates or worse. Note that this doesn't exactly represent how strong your signal is, just the potential of how efficiently it will send that data.
"But why can I have a super awesome RSRP signal and still my download/upload speeds are not that good (or why is it still sometimes good when RSRP is low)?"
Click to expand...
Click to collapse
Because it's only measuring the efficiency between you and the tower, not the rest of the network or the end source (the website). There are many network hops along the way to the destination and some may also handle connections inefficiently. The more hops, the slower the connection generally is.
However, it does also represent the greater likelihood that your connection will drop more packets of data that need to be retransmitted and thus not only slowing your connection but also causing it to have to work harder and draining more battery when it's actively downloading/uploading. That's why having it hand off is for the best than fighting it to stay on LTE. This is most likely why people always complained about the Thunderbolt having such poor battery life as no one ever saw what their RSRP was on it, only their RSSI like all other Gingerbread devices.
You can also consider RSRP the "absolute strength" of your current connection.
RSSI:
Received Signal Strength Indicator (RSSI), is the linear average of the total received power in Watts. This is used to measure the db signal for CDMA (3g/2g [2g being your 1x and voice]) signals and used in determining the "signal to noise ratio". It was what was shown on all devices as the "signal" under the Android settings before Android 4.0. Basically this is how much noise/interference is in your connection. Not so good for measuring the overall power of it. It should be in the range of like -58db and greater (like -32db). In other words, the closer it is to being positive, the better. If it's in the high 80s or 90s, your signal is probably starting to cause some slight battery drain when idle. RSSI has less to do with how great your network speeds are and more to do with how good your potential battery life will be.
SNR (Signal to Noise Ratio):
The higher your SNR, the more throughput (better download/upload speed) your connection will have. The lower the number, the worse it will be. The Nexus tends to have a lower SNR on average than phones with Qualcomm chipsets, such as the Galaxy S3. What does that mean? It means you are more prone to have interference on your connection to the towers when your signal is obstructed by scenery or the building you are currently located in. That means slower speeds and higher potential for unstable connections.
CQI (Channel Quality Indicator):
CQI is measured 0 to 15, with higher being better. It's a measure of how good the quality is for the current channel the cell tower has you on. CQI is derived from the SNR (signal to noise ratio) and the SINR (Signal Interferance Noise Ratio).
RSRQ (the overall quality of your signal in general) and SINR "Signal Interference Noise Ratio on LTE":
This is the great your connection is overall (the stability of it and how close it is to handing off to 3G). RSRQ ranges from -3db to -19.5db with a number closer to -3db being better. SINR is similar to RSRQ, but the measure may differ. I still need to verify which variable relates to SINR in the source (the RSRQ weirdly shows as positive in the Nexus SDK, which shouldn't be possible, but SINR can be positive so I'm not sure if they have it linked wrongly or what just yet). It takes in account of both your overall signal strength (RSRP) and the noise/interference in the connection (RSSI). Your phone is using this to determine when to hand off to 3G or go back to LTE. Reference Signal Received Quality (RSRQ) is defined for Verizon as 17db + (RSRP signal + | RSSI signal |) | | being absolute value. The graph below shows how RSRQ helps to determine when you it should hand off versus just RSRP alone:
From Verizon themselves :
The LTE SINR should be greater than 12.5db. The connection may drop to a 3G network with an SINR value of -6, resulting in slow speeds.
Click to expand...
Click to collapse
Randomly Asked Questions
It is upsetting my wife's Charge gets a much better signal than my Nexus sitting right next to it knowing it has the same radios.
Click to expand...
Click to collapse
It's not really "better." It's (the Charge) just measuring something different (the RSSI of the 3G connection) to obtain the signal which isn't even related to LTE. If you changed the above, the signal would probably be nearly the same. From my testing, my RSSI is nearly the same as what I got at my current location on my Thunderbolt (which everyone claims has amazingly better radios and Qualcomm chipset). This is true for all phones running Android 2.3 or before with LTE 4G connections.
"Why does my Nexus not hand off exactly the same as <insert proprietary android os based phone here>?"
Click to expand...
Click to collapse
Because it goes back to what I already mentioned in that other OEMs don't measure the LTE signal with the same metrics as they do on the Nexus (it was only added to the Android source with ICS and before then each carrier just "rolled their own" thing probably using the RSSI of the LTE signal to handle when to hand off) so the phone thinks the LTE signal is also better than it actually is and so it's staying on what is really a *worse* LTE signal when it should be handing off to a better CDMA/3g signal. Also see the part about RSRQ above and the graph. It'll be far easier to tell what they're doing when they update to ICS though as we'll have access to more information.
RSSI is an okay metric to handle 3g/cdma, but it's not nearly as good for LTE as RSRP is or RSRQ. OEMs are still using it other than for the Nexus and it's those other phones hold LTE longer than they should in many cases as that was the metric they had to go on with Gingerbread and before RSRP became the standard measure of LTE signal for Android.
From a few tests of pulling the signal info out of my phone directly using the ICS source (I was in a crap signal area when I took them):
cdma db = -100
cdma ecio = -150
evdo db = -105
evdo ecio = -150
evdo snr = 1
lte sig strength = 10
lte rsrp = -109
lte rsrq = -8
lte snr = 10
lte cqi (channel quality indicator) = 7 (measured 0 to 15, higher being better)
cdma db = -100
cdma ecio = -150
evdo db = -105
evdo ecio = -150
evdo snr = 1
lte sig strength = 10
lte rsrp = -108
lte rsrq = -8
lte snr = -30
lte cqi = 7
You can caculate my RSSI from knowing the RSRP and the RSRQ:
rsrq = 17 + (rsrp + x)
-8 = 17 + (-108 + x)
x = -83db → my LTE RSSI
Additional Info/Further Reading:
http://www.scribd.co...353976/12/RSRQ? (probably the best reference on what RSRQ is and RSRP)
http://docs.google.c...28qjNF66uPBYmfA
https://docs.google....fUvgTfFjRQ-4Mhw

Updated to version 1.1 with a small bug fix and a few other changes listed in the OP.

The "Ad free version" link isn't working matey

Listy2021 said:
The "Ad free version" link isn't working matey
Click to expand...
Click to collapse
Heh, I forgot I was in the middle of updating my webserver software last night and forgot to restart my screen session on my server so I didn't realize it was still shut down. Fixed things now though and the link should work

yareally said:
Heh, I forgot I was in the middle of updating my webserver software last night and forgot to restart my screen session on my server so I didn't realize it was still shut down. Fixed things now though and the link should work
Click to expand...
Click to collapse
No it doesn't

Updated to 1.1.1. Array out of bounds error fixes for devices like the Galaxy Y and ZTE Warp. If you never had crashes, then no reason to update as there's nothing else new.

Thank you for the app, latest release seems to work just fine :good:

Not sure why it does not work for you offhand (it really does download I can assure you). This is my personal server so I do block a lot of subnet blocks when they're known for spam/malware and some innocents might get blocked in that as well. I may have your current subnet block "blocked." If you PM me your current IP (http://whatismyip.com or google "my ip"), I will whitelist it in iptables. I don't want to unblock everything (especially not for a free app), but I can help out any user that is willing to help me to help them.

Hopefully fixed a crash issue with the Galaxy Note when it pressed the additional info/settings button and also fixes for random devices that are running Android and not totally compliant (can't describe much better as they show as OTHER on the market).

Very useful app
Sent from my TECNO N3 using Tapatalk 2

Anyone that would like this translated to their native language and is willing to work with me to do so, please contact me here or at my email listed in the Android Market. For what it's worth, you'll also get credit for the translation

UPDATE (2013-01-13): Performance tweaks through code cleanup and restructuring. If nothing else is needed, next version will have some new information for GSM users and maybe some other things if I have time.
A few users were getting a permission denied error/crash when accessing additional settings (Huawei M865C & Samsung Galaxy Ace). Access problem is with your phone's current OS and the manufacturer so I cannot fix it. However, the crash will no longer happen and you get a friendly message.

I need some help from anyone currently using my app. The RSSI in my app has to be manually calculated due to limitations of information in the Android OS. Many carriers are not using the same channels/frequency for LTE and it operates on many different ones, which causes the RSSI to be different. In order to make it easy on all you guys, I would like to try to calculate what your RSSI is for you so you don't have to select it as an option (though I will still add that as well for any that are not covered by automation).
Finding the channel bandwidth offline is not hard (as many sites show what carriers use). However, figuring what carrier you guys are on is a bit tougher if I don't know 100% what the carrier name will appear as (example: Tmobile versus T-Mobile or ATT versus AT&T). I currently have devices for AT&T, Sprint, Verizon and T-Mobile at my disposal, but other carriers I need some help with. I want to have this done before the next update if possible, but I will add more as I get them.
I wish there were a more elegant way to do this, but that's the best there is for now
--What I need from you guys (those not on Verizon, T-Mobile, AT&T or Sprint with LTE)--
Simply paste your carrier name as it is shown in my app under "carrier" (punctuation included) in this thread or PM it to me. That's all I need and I can properly show you your RSSI signal for LTE. Right now it's set to only show properly for 700mhz LTE, but that's mainly due to legacy purposes as only one carrier had LTE at the time of making the app over a year ago.
Thanks!

UPDATE (2013-06-02):
Lots of improvements (see screenshot below):
- New ways to monitor your signal quality via easy to read percentages %
- Monitor your signal based on 0-100% percentages
- ActionBar + options area for all
- Performance/stability improvements.
Compare your signal quality based on % instead of just decibels. Now, you can instantly see how great each signal reading is for your device based on a scale of 0% (worst) to 100% (best). Percentages are configured to give the best reading for your carrier by default.

UPDATE (2013-06-03):
Bug fix that would cause the app to close when rotating the screen.
Relative percentages were adjusted a bit based on feedback.
Assuming no other issues, should be working on adding some more features useful for those on GSM carriers (mostly calculating some additional readings that are possible).

Fixed a bug for anyone on Android 2.2. Google for some reason in their wise choice decided to leave out Arrays.copyof() in Android 2.2, despite it being a core part of the Java JDK. I decided to use it for something, assuming it was there (because why wouldn't it be, heh). Anyways, if you're on Android 2.2, it should show up in the Android Market later today

The adverse version downloads, but won't install for me. Says "App not installed" every time. Play store version of installs fine, though.

Morningstar said:
The adverse version downloads, but won't install for me. Says "App not installed" every time. Play store version of installs fine, though.
Click to expand...
Click to collapse
Hmm, it can happen for a number of reasons.
Switching between the market version and non market version without uninstalling first is the primary reason though. I sign the market one with my key, but I don't sign the one on my server since it could complicate things for me later on doing that.
Some more info about your error though if it's not because of that: http://stackoverflow.com/questions/4226132/application-not-installed-error-on-android
Let me know if you get it worked out though (or don't). I mostly keep the server version up for people that don't have access to the Android market, since some countries don't.

If the app crashes when you open it (I see a few of you guys in error reports every now and then), it's probably something I would need you guys to contact me to fix. The reason why is your phone/tablet most likely deviates way too much from the standard radio interface layer for Android and I need specific information that an error report you send me will not give. If I don't have that information, then I can only guess as to why it's not working and most of the time, a guess is no better than not doing anything at all. I try to account for most of the random possibilities without killing performance, but like a leaky dam, I plug one hole and then another opens up.

Hello- Really hoping this app will begin working for me. I have a CDMA Samsung Epic on Sprint, and once installed, the app always shows EVDO and 1XRTT signal strength exactly the same, all the time. My modem version is EC05 on the Epic, and I'm currently running MIUI 2.3.23 so if you could advise, let me know.
Thanks!

Question Fix wifi

been having trouble with wifi after updating to 12
this is my second device, first device was on android 11 worked great, wifi hadd to return it because the sim tray broke while under warranty as i tried to insert sim card,
have had 2nd device for about 6 months now and updated software right away , thats when i noticed changes on my wifi . from low signal to wifi disconnecting and displaying a messege that reads,,,, connect when signal is stronger or not connected
any help is apprecited

anyone?

I'm not sure if it is any different since the update but this phone has given me problems for over a year with wifi and devices. I even made a forum post regarding the components/hardware of this phone and it being cheap. People told me "it was the same" as many other phones and it was fine.
I connect to a 360 camera (the camera is the WAP) for work and this phone always has problems with range. My older phone, a Moto Z2 worked just fine. I have came to the conclusion that the 2.4ghz band on this phone sucks. It has no range or weak signal. My internet is 330mbps but if I am standing 5 feet from my router doing a speed test, it is 60mbps with this phone. Phone is also slow, no faster than my much older Moto Z2 I got in 2018. I can't wait to replace it soon.

ospfrat said:
connect when signal is stronger or not connected
Click to expand...
Click to collapse
Given Occam's Razor, my first suggestion is for you to determine if the signal is, indeed, needing to be stronger or not connected... and whether or not there is strong interference nearby.
Those are the first things ANYONE would do, so they're not specific to your problem other than you NEED to do them first, just as anyone would need to do them first - before blaming the phone.
To run that first basic test, the first suggestion always is for you to run a local Wi-Fi survey using any Wi-Fi Analyzer to assess the received signal strength.
For example...
Cellular-Z by JerseyHo
Free, ad free, gsf free, rated 4.0/1.82K reviews @ 100K Downloads
<https://play.google.com/store/apps/details?id=make.more.r2d2.cellular_z>
... and, maybe even set up a snitch in the USB Debugging options (either method will tell you the received signal strength).
Android 12 Settings > Developer options > Networking >
Enable Wi-Fi Verbose Logging = on
In my case, that verbose logging says, for each SSID I'm connected to, something like the following (reading from my phone just now):
mySSID_nomap
Connected
Autoreconnect turned off
f = 2432 DE:AD:BE:EF:CA:FE
standard = 4 rssi = -33 score = 60 tx=2.0
If you put two similar phones side by side, the interference and signal strength readings should be the same, and if they're not, that would be a useful clue in the direction that you seek answers for.

Database Info

welcome