Database Info

Wi-Fi Supported Speeds

I've tried multiple ROM's on my Fuze and they all seem to give me a high Tx rate of 54Mbps but a low Rx rate of only 1Mbps. Has anyone else seen this behavior or have any ideas why I'm seeing this? I thought that Raphael had full support for WiFi at "g" speeds. This happens irrespective of "power save mode" setting. My network wireless router is configured to support both "g" and "b" speeds so not sure what's happening.
Thanks in advance.
Andrew

abs99 said:
I've tried multiple ROM's on my Fuze and they all seem to give me a high Tx rate of 54Mbps but a low Rx rate of only 1Mbps. Has anyone else seen this behavior or have any ideas why I'm seeing this? I thought that Raphael had full support for WiFi at "g" speeds. This happens irrespective of "power save mode" setting. My network wireless router is configured to support both "g" and "b" speeds so not sure what's happening.
Thanks in advance.
Andrew
Click to expand...
Click to collapse
I'm pretty sure 54Mbps is the top end of "G" speeds, not sure what you're asking?

Receive rate is what he is talking about 1Mb is what I see with various roms and settings for the wifi power, too.

the device connect as g
and can recieve 54Mbit/sec
but the cpu cant keep up with the wifi interface
same deal with fast sd cards really

It's never above 1Mb rx.
Funny that the radio can keep up with 4Mb downloads over H though.

Yes, the 1Mbps is what I was concerned about. Still not sure I'm fully understanding why the connection speed is limited. If the cpu is too slow, then the network interface should be able to leverage flow control or even error correction in TCP/IP stack to prevent data overflow conditions.
Does anyone know if other similar hardware (Diamond, Quartz) has the same limitations? Maybe we can improve network connection speeds with a different driver?
Andrew

Yes i have noticed the 1mbps rx speed also. When i connect it shows 10mpbs rx for a moment and then it drops at 1mbps. Copying files over resco 2008 is around 30kb per second and that is too slow, maybe is there some registry hack for this?

I will agree that wifi speeds aren't even all that great. Maybe we need to turn data off? I'll run a test here in a bit.

I hopped on another network that is UNENCRYPTED. It bounces from 1-12Mbs RX, but they are a weak signal.
My stuff is encrypted, so maybe that is the difference?
They are also on ch 1, I use ch 10.

Encryption is pretty processor intensive unless you have a hardware accelerator. Unfortunately I do not believe that is an option.

I will say that the iphone on the same encryption settings does things fast over wifi here. Is there a comparison between the cpus?
I'll have to have my friend with the tilt connect and do a speed test.

Yes, I've noticed that the speed seems slow when on wi-fi too and that's why I started looking into this issue. My last phone was a Treo 750 so didn't have wi-fi and I really don't know how the Tilt performed in this area. Having said that removing encryption on my wireless network is simply not an option . . .
Andrew

I agree, I would not recommend disabling encryption. You could disable it temporarily for a quick test to see if it makes a big difference. If it does, then you could try another type of encryption.

i've got tp wwe rom and same issue. wi-fi has speed problems. try streaming some xvid, it can't keep it up

I can't believe more ppl aren't kicking and screaming about this issue. I have the same issue, my RX is almost always 1mb. Also you can barely stream video or even complete a VoIP call over wifi. Doesn't make sense that it would be faster over 3G than over wifi..what gives?

jank0023 said:
I can't believe more ppl aren't kicking and screaming about this issue. I have the same issue, my RX is almost always 1mb. Also you can barely stream video or even complete a VoIP call over wifi. Doesn't make sense that it would be faster over 3G than over wifi..what gives?
Click to expand...
Click to collapse
if i didnt know better, i'd say that att is trying to scam us into using their data connection...

Edge Data Improvement for AT&T Users

There might not be many of us out there, but for those of us using unlocked and rooted mytouch on the ATT network I've found after some research a way to almost double my Edge speed. This information has been posted before in various pieces on various sites but not directly related to ATT/Edge only. Ive tested this on cyanogen 5.0.8 built will include instructions here that you can give this a shot depending on your rom. Prior to this tweak I ran three download tests, 63/38 84/41 81/41. After, I got 191/102, 133/114, 123/95.
Note that it seems that for me the speed increase takes about 10 seconds to kick in from sleep once the data connection is active.
Under the system directory, look for three files. Open each file and find a section called #GPRS class or #RIL settings. When you find the file containing this, this is the file to edit. Below I'm using system.prop. Also, when editing, do not use notepad or wordpad, I personally use EditPad Lite.
using the android sdk, and connecting your phone to pc ->
adb pull /system/build.prop build.prop
open build.prop with a unix compatible text editor
Change the following sections below:
# Default network type.
# 0 => WCDMA preferred.
ro.telephony.default_network=1
# RIL settings
ro.ril.gprsclass=32
ro.ril.hsxpa=0
ro.ril.hep=1
ro.ril.enable.dtm=1
eliminate all other lines that start with ro.ril if they exist.
then go back to your command prompt, and type
adb remount
adb push build.prop /system/build.prop
reboot phone twice after this.
The idea here is that these lines will force only searching for Edge networks, and improve the full use of multislot data/voice thoroughput on ATT Edge network. I would think technically that this would also maximize data thoroughput for those that want to save battery life from the sucking power of 3G.
I'm posting this because I'd like some feedback from ATT people that can try this. As I'm in metro Atlanta I'm not sure that these settings work for every area, and I've only tested in two spots here within a mile of each other in the three tests. I'm also at this point concerned about battery life outside of my one day testing and other areas.

I'll try this on two different G1's running on AT&T this next week and report back. Thanks
Update 8/31/10: Testing with Super D I see a difference. Was 0.07 mbps Down/ 0.08 mbps up. Now 0.18 mbps Down/ 0.16 mbps Up. Every little bit helps I guess. Thanks for posting this thread.

Which ROM are you using this on? I'll try this out on my phone at the end of the week. Also where did you find this exact same set up. I want to read more about it. I see other posts with different values but not with this same exact set up.
http://forum.xda-developers.com/showpost.php?p=5123531&postcount=46

As I mentioned I'm using Cyanogen 5.0.8. I didn't read where anyone is using this exact setup, I researched the values and put them together based on my best understanding of them.
As of now I'm seeing battery life unaffected to actually improved. Things like facebook and my MLB At Bat are majorly improved, takes much less time for the stats to populate so I'm spending less time in the apps and in turn I'm assuming that lends to battery life. I also used to drop a call in one particular spot and I'm not dropping that call so far. I've been in various parts of the city and the download speed is fairly consistent witht he 130-180k range.

Any word on this working with CM6? There only seems to be these in the RIL section:
ro.ril.hsxpa=1
ro.ril.gprsclass=10
Should the other two values be added?

SRDMizzou said:
Any word on this working with CM6? There only seems to be these in the RIL section:
ro.ril.hsxpa=1
ro.ril.gprsclass=10
Should the other two values be added?
Click to expand...
Click to collapse
As far as what should be added/removed, please more carefully read post one.
In answer to whether it works with CM6, these values directly support the gprs code of the phone so it should in theory work on any android based device.

I appreciate the time you've spent, thanks. I'm trying this asap. I have to test before and after, tho. I'll let you know. I never even considered looking into this, and what I see looks very promising. Thanks for the work.
BEFORE
Test 1: ping- i forgot to look
download- 79
upload-109
Test 2: ping-772
download- 90
upload-79
Test 3: break in between 2&3, for fun. it was asleep for a while.
ping- 767
download-51
upload-95
Test 4, another pretty long break
ping:927
download:23
upload:116
Test 5, no break
ping 16
download 44
upload 100
test 6, no break
ping 39
download 46
upload 111
AFTER
Same physical location, 2 reboots, cable unplugged as before.
Test 1: ping 551
download 33
upload 122
test 2 soon after
ping 541
download 27
upload 104
test 3 with an asleep break in between for a while
ping 428
download 47
upload 105
test 4 right after
ping 429
download 39
upload 102
Test 5 right after
ping 422
download 28
upload 116
Test 6, after a break with screen off/sleeping and a 30 second break with screen on before test
ping 430
download 26
upload 105
In conclusion, no it didn't make any benefit to me. In fact, there was a decrease in speed after applying the mods.
I used a nightly of cyanogenmod 6 from 2 days ago (right before rc3)
I will try donut soon. Eclair sucks. Note that cyanogenmod did not have the last two ro.ril lines, but it did have the telephony one. I added the necessary ones, of course.

i updated my post above.

Hi Jcarrz, thanks for the post. I think something is wrong with your location/configuration if you are getting 100% upload speed over download. It should be the reverse, but even before my config change I was getting double your download speed. Also, a ping time of <100 ms into an edge network is a bit unheard of as far as I know, what speedtest are you using? Did you delete the existing lines? the two most important lines to add are the dtm=1 lines and the grprsclass=32.
One thing about this is that not every city may support class 32 download. Also it may take some time for GPRS to establish 5 timeslots to get the full download speed. Another thing to follow up on my post, as I mentioned 10 seconds or so at least before starting the speedtest, but I've found that even 1-2 minutes after coming from sleep I'm occasionally getting 215k down in some places. But in your case there's definately something else going on....

hongkongpheoy74 said:
Hi Jcarrz, thanks for the post. I think something is wrong with your location/configuration if you are getting 100% upload speed over download. It should be the reverse, but even before my config change I was getting double your download speed. Also, a ping time of <100 ms into an edge network is a bit unheard of as far as I know, what speedtest are you using? Did you delete the existing lines? the two most important lines to add are the dtm=1 lines and the grprsclass=32.
One thing about this is that not every city may support class 32 download. Also it may take some time for GPRS to establish 5 timeslots to get the full download speed. Another thing to follow up on my post, as I mentioned 10 seconds or so at least before starting the speedtest, but I've found that even 1-2 minutes after coming from sleep I'm occasionally getting 215k down in some places. But in your case there's definately something else going on....
Click to expand...
Click to collapse
yea, that ping was pretty crazy. I live really close to los angeles, I don't think a crappy network is the problem. What do you mean by delete existing? i edited two that were there, and added two that weren't. I am using the ookla labs speedtest.net application. I have always had a higher upload than download. Everywhere. I waited for long periods of time between tests. And after waking up from sleep. The highest speed test I have seen is a 250, on htcclay's superfast 1.3.3. I'll have to take a look on the values in that rom.
Thanks for your help, prehaps you could upload the EXACT build.prop for, say, a cm6 build that I could use?
Jcarrz1

ro.ril.hsxpa=2
ro.ril.gprsclass=12
ro.telephony.default_network = 0
I seem to get the best speeds i've seen with this config. Namely the hsxpa=2, because that one, when changed to 1 or 0, dents my speeds.

jcarrz1 said:
ro.ril.hsxpa=2
ro.ril.gprsclass=12
ro.telephony.default_network = 0
I seem to get the best speeds i've seen with this config. Namely the hsxpa=2, because that one, when changed to 1 or 0, dents my speeds.
Click to expand...
Click to collapse
Thanks for reporting back. I think this shows that indeed the edge network in your location just isn't a class 32, or at least it is and is allocating more timelosts for upload than download. Here's how the classes should in theory work. Edge can alot 2-6 timeslots to transfer data. a class 10 or 12 is 5 slots data, 10 says that in theory up to 4 of those slots could be download and 2 could be upload, while 12 is up to 4 down 4 up (but only 5 max in any config). A class 32 can allocate 6 slots data, 32 also says that 5 could be download or 5 could be upload. Try setting the class at 30. This will give you a shot at 6 slots guarantee that no more than one timeslot can be set for upload (5 download 1 upload). If that doesn't work, in theory actually then moving to a class 10 setting may overall benefit you (4 download 2 upload).
hsxpa setting should technically do nothing for you on AT&T unless your phone supports HSPDA 850/1900, I set it on my magic 32B because it forces UTMS99 which is not implemented and therefore should in theory guarantee my radio never finds something to scan. I understand that turning on 2G only doesn't work in all roms, so I set that just in case.
Just so you know, the values in gprsclass can be 10,12,30,31,32,33,34.

I don´t think that ro.ril.hsxpa=0 deactivates 3G. AFAIK it just limits the phone to plain normal 3G (=UMTS) and ensures that it does not attempt to switch to 3.5G (HSDPA/HSUPA) connections.
From what I see in wikipedia, UMTS99 is nothing else than the first release of UMTS, therefore definately being supported.
Better set it to =2, just in case you travel to a country where you have 3G (and 3.5G, etc.) connectivity.

Hellek said:
I don´t think that ro.ril.hsxpa=0 deactivates 3G. AFAIK it just limits the phone to plain normal 3G (=UMTS) and ensures that it does not attempt to switch to 3.5G (HSDPA/HSUPA) connections.
From what I see in wikipedia, UMTS99 is nothing else than the first release of UMTS, therefore definately being supported.
Better set it to =2, just in case you travel to a country where you have 3G (and 3.5G, etc.) connectivity.
Click to expand...
Click to collapse
EDIT: Sorry I just looked up the specs on the phones again and I never noticed UMTS support, still in essense you still want to keep this at hsxpa=0, unless you want 3G on roaming coverage as mentioned. This article is about ATT users and more geared to only ATT bands, ATT does not offer HSDPA over the bands this phone supports so disabling it should keep it from scanning roaming networks for it. I'm removing the other ril values from the phone to keep the phone happy with the fastest edge connection it can get.

So I just tried updating the settings on Superfly TCBY Froyo 1.2. It didn't have the same exact setting lines so I just added the lines manually. All tests done on a fresh reboot, SpeedTest the only app open:
Before
Time of day: 1:10 PM
Run 1
Server: Los Angeles, CA
Latency: 829 ms
Download: 10.3 kB/s
Upload: 9.3 kB/s
Run 2
Server: Los Angeles, CA
Latency: 121 ms
Download: 14.7 kB/s
Upload: 12.1 kB/s
After (2 reboots):
Time: 1:25 PM
Run 1
Server: Los Angeles, CA
Latency: 423 ms
Download: 19.9 kB/s
Upload: 13.7 kB/s
Run 2
Server: Los Angeles, CA
Latency: 394 ms
Download: 18.3 kB/s
Upload: 14.6 kB/s
So it did improve speeds a little. How much is due to the settings is unsure. It could be related to the time of day and traffic during the time of day. I will keep the settings and see how they hold up.
I have been using the normal settings without modifications for Google Nav and it works perfectly fine. I will see how these settings hold. I'll attach my build.prop. Just remove the ".txt"

dawgpound, can you report what city you are in. I do agree that time of day and tower can play into this, this is why my before and after tests were done about 2-3 miles apart from each other. They were also done during daytime hours.
To update on my end, I'm still testing in various areas of atlanta and I'm finding that I actually connect "G" in some areas. I'm assuming UMTS99 since the phone only supports this. The download speeds were terrible, worse than edge for me though. I know this implementation is older and probably not omptimized.
Using Speedtest I'm still not getting any worse than 40k download anywhere in metro atlanta. But, one thing I've found is that in some cases I would get a upload speed greater than download, running Speedtest again even immediately after would produce much higher downlad and upload speeds and maintain these. I think this goes back to my theory that when you initiate the data transfer that it takes a while for the phone to build all the timeslots to the carrier when you enable them in some situations.

Sorry for responding so late. I'm doing the tests in LA. I went to Universal Studios the other day with the modified settings and my phone failed badly when using data. I was getting full signal on my phone with the EDGE sign but it wasn't sending or receiving data most of the day.
Unfortunately, I wasn't able to switch back and forth to see if it was just in the theme park or not. I've noticed in crowded areas, it lags pretty bad compared to the stock settings. I also was connecting to G speeds in some areas but only for a few seconds before switching back to EDGE. Right now, I'm back on stock settings to compare. I will say though, with the modified settings, download speeds increased by average 5 kB/s but upload speed was on avg 5 kB/s less than dl speeds. Stock settings, both download and upload speeds are close to each other.

Ping (Latency) highly variable on LTE?

I've noticed lately that my ping at home is significantly worse than it is at work. If I ping google from work, I get 90-110ms latency. If I ping that night from home, I will usually get double that, in the 200-220ms range. This is all on LTE, using terminal emulator to ping google (dns resolved).
What I can't seem to figure out in my own testing is whether it is the time of day or something about the tower that I am using that causes the difference. It seems that on the weekend most of the time I get the poorer ping (~200ms) , but if ping is worsened by heavy load on the network, then it is not a very good test because load should be higher on the weekend (assuming here).
So, does anyone have similar exprience? Are there any tips or tricks for lowering ping ?

i've had it be weird also... and often times in the same location. i'll be at home and try, it'll be around 80 - 90.. then like 5 minutes later i'll try again and it'll be 200... and will just go back & forth even though signal strength remains the same.
possibly due to traffic.

A) Your pinging essentially a "wireless" router.
B) "Ping" is typically set to use the lowest priority if not disabled altogether on most networks.

Also dual-core brings a humongous improvement in latency. Try Bionic at the store next to the Bolt.

[TWEAK SPARK_W] How to optimize tethering for faster speeds (3G vs 1X) EASY!

The following applies only to SparkW (HTC Trophy on Verizon Wireless)!!
GSM/Euro Spark users can ignore doing this to their own phones!
In my quest to figure out why my damn phone stayed stuck in 1X mode while tethering, I may have found a solution to keep the speeds faster (which is important to me, since my tethering is my primary internet connection).
This is also part of my quest to build/find a wireless driver that gets rid of the "random" wi-fi mac address issue while still maintaining Internet Sharing.
It has to do with the OEM package HTC_8x50_OS_WIRELESS. This is the Wi-fi driver, but it may also be a driver for the radio interface of the phone.
The differences between this file on Spark_W, and Spark GSM are minimal at best. Spark GSM adds the policy to enable the wi-fi hotspot (mxipupdate_hotspotconfig_01.provxml), meanwhile the Verizon driver has mxipcold_Wireless_Spark_W.provxml and BCM4329B1_002.002.023.0589.0608.hcd.
The package ID is the same for both GSM Spark and Spark_W, {A2A5F44F-FE02-496e-8926-6EDDC8CF9B44}.. and in my cooking experience, you can straight use the GSM driver on Spark_W with no adverse effects that I can notice.. and in my custom cooked rom, I noticed that my tethering download speeds seemed much MUCH faster using the GSM driver!
So.. I wanted to figure out WHY that is.
The .rgu file between the Spark GSM and Spark_W are IDENTICAL. There are no differences what so ever! So I got to looking at what mxipcold_Wireless_Spark_W.provxml does.
Code:
<characteristic type="HKLM\Software\Widcomm\BtConfig\Platform\RadioInit">
<parm name="BRCMConfigFile" value="\Windows\BCM4329B1_002.002.023.0589.0608.hcd" datatype="string" />
Looking at this string, this seems to assign some kind of file that may have to do with radio initialization.
This overrides the default value set by the rgu, which is:
Code:
[HKEY_LOCAL_MACHINE\Software\Widcomm\BtConfig\Platform\RadioInit]
"BRCMConfigFile"="\\Windows\\BCM4329B1_002.002.023.0436.0438.hcd"
And when using the GSM Spark driver, BCM4329B1_002.002.023.0436.0438.hcd is used and tethering speed improves!
Here comes the fun part! If you want to try this faster tethering, there is no need to flash an entire rom, you simply need to open up the registry editor, navigate to HKLM\Software\Widcomm\BtConfig\Platform\RadioInit , and change the value BRCMConfigFile to BCM4329B1_002.002.023.0436.0438.hcd (setting it to BCM4329B1_002.002.023.0589.0608.hcd will change it back)! After that, save the value, reboot the phone, and va-la, tethering speed has improved!
I haven't tested this tweak with good reception to see if I can get past the "350KB/s" cap I keep hitting with tethering in great reception areas (I have pulled 900kb/s on those same spots using my mothers Galaxy Tab 7.1), so I'm not sure if this is the "secret" to unlocking this artificial speed lock or not.. but I doubt it can hurt. I've been running this for about a month, and its not like Verizon has yet to detect my tethering yet.. so... I'd like for people to run Speakeasy Speedtest both before and after trying this registry tweak, to see if anyone else is getting a huge speed bump.
In my fringe reception area, I am going from 15KB/s on 1X to 50-80KB/s on 3G!
I don't believe this should have an adverse effect on battery life when NOT using Internet Sharing, but if you're on battery while using this, the 3G speeds may suck more juice out of your battery.
I'm always charging while tethering, so this tweak really works well for me! I hope others can test this and give me feedback to see if this really helps in higher reception areas. I live out in a very rural area with low cellular usage, so anything to get faster speed is golden!
*note* For anyone wondering, I haven't downloaded any new OEM/Spark drivers/roms to try and extract their wireless driver yet to try and fix the mac address issue... I can't simply take the newest Verizon driver and add the hotspot policy in, as IS won't start. :/

Nice. Thanks for your work and glad to see you back after a few days. I don't know if I will do this as I don't use tethering that much, but good to have the option.

Well, the thing about trying it is... you can reverse it by putting back the Verizon value. I'm stuck on tethering since my other internet option is dial up for the time being.. but really I discovered this by accident trying to fix the mac address issue for the custom rom I am working on.

[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!