# [APP][2014-01-06] Advanced Signal Status v1.4.1



## yarly

Originally posted here: http://rootzwiki.com...s-signal-sucks/

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"

*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 (2012-06-03)**: *

Adjusted the signal % readings based on feedback. Relative ones should be a bit closer to what one thinks is a decent signal for their phone.

*UPDATE (2012-06-02)**: *Lots of improvements (see screenshot here):

- 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-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.

*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-24): *Not exactly a true update, but translated the project to Mono for Android with C#. Source is here.

*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--*


Market ad supported version
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.

Ad free version
This version is the same as the market version, but no ads. You won't be able to update from the market most likely due to market licensing.
It's available here (40KB download so it's very small).

*Basic App Source* (to prove data is legit): https://github.com/yareally/SignalInfo

*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 that 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.


*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)?"


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.


*Randomly Asked Questions*



Rythmyc said:


> 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.


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>?"


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


----------



## yarly

If you're running Android 2.3 or before, stand by for a fix. I used a function in the Android API I forgot was not part of Android 2.3.

EDIT: Now fixed.


----------



## JBirdVegas

Wait you mean cell signal isn't tied to the ROM? No way ;-)


----------



## HerbieVersmelz

JBirdVegas said:


> Wait you mean cell signal isn't tied to the ROM? No way ;-)


no way! The vzw sales rep i talked to ensured me it was. 

Sent from my Galaxy Nexus using Tapatalk 2


----------



## yarly

JBirdVegas said:


> no way! The vzw sales rep i talked to ensured me it was.
> 
> Sent from my Galaxy Nexus using Tapatalk 2


haha


----------



## zvogt

Silly request/suggestion... Could you display the app's version number within the app itself?


----------



## yarly

zvogt said:


> Silly request/suggestion... Could you display the app's version number within the app itself?


I could. It shows it in the market already though. I could add it somewhere near the bottom.


----------



## yarly

Not exactly a true update, but translated the project to Mono for Android with C#. Source is here. Market version is still the Java one, for now at least.

What was the point? I like C# better and I can develop faster with it, so updates come faster.


----------



## icedventimocha

Thanks for this, very informative to what's going on with radio, and since I have a thunderbolt (with its crappy dual radios) I'm looking at this all the time. Btw did you ever finish your ad blocker app?

Sent from my ADR6400L using Tapatalk 2


----------



## yarly

icedventimocha said:


> Thanks for this, very informative to what's going on with radio, and since I have a thunderbolt (with its crappy dual radios) I'm looking at this all the time. Btw did you ever finish your ad blocker app?
> 
> Sent from my ADR6400L using Tapatalk 2


Nah, haven't really messed with it past a buggy implementation I did that wasn't fit for release. Bugs were mainly in obtaining root and I fixed those with a later app I'm working on by building a command line access library that handles terminal and root commands properly (as well as lets you swap between them and regular java commands where available). However, I never backported the library. Eventually I might, but I have more useful app ideas I've been working on instead. Too many ideas and not enough time mostly, lol. Wish I was still a teen and didn't have to do anything important sometimes









I might open source the command library part though for anyone that wants to send commands to a shell terminal from their app in a proper way.

I'm still adding to the Signal Info app as well. Trying to decide what I want to do with it and how useful it would be to people outside of a niche group in doing so. End goal is to mostly let people collect the average signal in an area over a time period (or over intervals of time [like whenever they want to collect more]) and compute stats based on that for them like:

max signal
min signal
median signal
most frequently occurring signal
standard deviation & variance signal (so you can tell how close [stable] your signal is to what is expected)
normalized signal average which ignores peak low and high signals

then display it in a table and various graphs


----------



## DJBhardwaj

This one is marvelous, just what I needed








Thanks OP


----------



## yarly

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


----------



## yarly

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.


----------



## icedventimocha

yarly said:


> Nah, haven't really messed with it past a buggy implementation I did that wasn't fit for release. Bugs were mainly in obtaining root and I fixed those with a later app I'm working on by building a command line access library that handles terminal and root commands properly (as well as lets you swap between them and regular java commands where available). However, I never backported the library. Eventually I might, but I have more useful app ideas I've been working on instead. Too many ideas and not enough time mostly, lol. Wish I was still a teen and didn't have to do anything important sometimes
> 
> 
> 
> 
> 
> 
> 
> 
> 
> I might open source the command library part though for anyone that wants to send commands to a shell terminal from their app in a proper way.
> 
> I'm still adding to the Signal Info app as well. Trying to decide what I want to do with it and how useful it would be to people outside of a niche group in doing so. End goal is to mostly let people collect the average signal in an area over a time period (or over intervals of time [like whenever they want to collect more]) and compute stats based on that for them like:
> 
> max signal
> min signal
> median signal
> most frequently occurring signal
> standard deviation & variance signal (so you can tell how close [stable] your signal is to what is expected)
> normalized signal average which ignores peak low and high signals
> 
> then display it in a table and various graphs


Yeah know the feeling of not having time man, being an adult sux lol. But yeah this app is great, still use the block ads script on my phone too. Keep up the great work man, can't wait to see whats next.

Sent from my Galaxy Note II


----------



## yarly

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).


----------



## zvogt

icedventimocha said:


> being an adult sux lol.


I disagree. I ate a whole box of doughnuts for dinner. When one is a child they lack the means to acquire their own doughnuts, and no way a grown up is going to let you eat doughnuts for dinner. I was just thinking how much being an adult rocks.


----------



## reggjoo

Beautiful app. Truly needed for the info. Now I can work on a better signal from my router, and provider(comcast.. little sucky, speed yes, stability no.. fios is better.).


----------



## yarly

reggjoo said:


> Beautiful app. Truly needed for the info. Now I can work on a better signal from my router, and provider(comcast.. little sucky, speed yes, stability no.. fios is better.).


I was eventually going to add in some wifi signal stuff as well. Currently you can access the wifi signal RSSI and some other stuff under the additional area after tapping the button, but it would be more user friendly outside of that area and in a tabbed layout.


----------



## yarly

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 (2012-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.


----------



## indianajonze

for verizon galaxy nexus, in additional info-->phone information-->Set preferred network type, what is the default setting?


----------



## yarly

indianajonze said:


> for verizon galaxy nexus, in additional info-->phone information-->Set preferred network type, what is the default setting?


GSM/CDMA auto (PRL). Results may vary by OS version and phone though. That was on the Galaxy Nexus 4.2.1


----------



## yarly

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!


----------



## puk3n

yarly, how the update on this app coming along? just curious.


----------



## yarly

puk3n said:


> yarly, how the update on this app coming along? just curious.


When I get time to finish the next update mostly. Ideas always come easy, time...not so much, lol. App for now is just a side thing unless I find a way to make it a viable app for offsetting some bills other development pays right now, lol. Not to say I don't mind just writing the code because I like to and anything I make, I also use myself, but time is mainly the factor and only so much of it and have to devote it elsewhere too unfortunately. It started out as just an app I used myself and then I shared it with everyone since it ended being kind of useful. No intention to stop adding to it or anything, but it just comes in spurts.

There's some "pro like" features I could add, but I don't know how popular the app really is to do all that versus other things I could work on. It's gotten more downloads than I have expected so far, but it's still kind of a "niche app" until I make the information more user friendly (as an option or default for new users until reverted, because I don't want to lose the minimal interface it has now). That's what holds me back from trying to push it towards general users more and maybe making it more popular. User interfaces are a pain. I know what I want to do in regards to that, but it'll be time consuming.

I would never want to make anything that's a basic feature something paid, but fancy addon features I thought about doing that way (like recording signals over time and graphing them and such and giving various stats). Things like wifi signal I can also add soon as a basic feature as well. Other things I might add eventually are distance to connected tower (would require gps though) and nearby towers for those using GSM.

I've been working on a few other Android apps on the side as well lately with one that will be out soon.

I could push the RSSI change for a few carriers quickly that I am aware of already, but I'm holding off as of now until I can give an option to set it manually for carriers I can't confirm. That mainly means adding UI stuff, which takes longer. If I don't find time in the next week or so, I'll push it anyways.


----------



## puk3n

thank you for your prompt reply, i completely understand your that your allocation time is rather a commodity. in terms of managing other aspects of these forever unfolding development projects, let alone life on its terms  (ideas-vs-time)

i agree that keeping the Advanced Signal Status as basic in the user interface as possible is a step in the right direction. this app in particular strikes me as valuable, due to the fact that it allows low level access to baseband hardware, that are not the norm in so many words. the focus on the mobility standards are almost an entirely separate entity from android in itself, as mobility reaches many platforms this ranges across the board with different handsets and OSes.

as you also stated : "It started out as just an app I used myself and then I shared it with everyone since it ended being kind of useful" i believe that this small achievement hinges directly on sharing this and getting the feedback from the users. that in itself is priceless. and cheers that you are not pushing out an app for only for its monetary purposes. i trust you are aware of the paid-vs-free apps on the market. in my opinion the best code out is the free code! the buck does not stop at one developer. i guess this all involves intent.

i feel certain that, if and when you have the time to bring in the creative ideas that you have shown us so far, the monetary piece will literally fall in your lap.


----------



## yarly

Yeah, I never went into software dev or computer science only for money (though I'd be lying if I said it was not a reason). I like figuring out how things work and sharing/educating when I can. I'd gone into teaching if teaching meant anything these days in public schools (as most are so bogged down they have no free reign in what they teach).

I work for myself (well clients on contracts) until I decide I want to commit to full time work with some employer. Main reason I don't is many have clauses limiting what you can do in regards to your own side work (and I also like setting my own hours).

Realistically, I don't ever see this app making real money, lol. I like it and find it useful and I am glad others do as well. However, compared to other ideas I have, it seems more limited in scope of appeal I guess as many Android users, no matter how much I make the info easy to related to, because many won't be as interested as many of us are on the forums. I don't like ads really and wouldn't add any more than it has (one is all I like and more becomes distasteful and cluttering). Ads don't make money though unless you're in Angry Birds territory. Just for example, the one I included has made $6.00. It buys me lunch at Chipotle I guess though .

I try to walk the line between what is useful and what is not to users based on what I think is useful in an app (I get kind of OCD and always pick apart every app I use based on how annoying it is or lacks, lol) and if I ever did make a paid version (which would be no more than say a $1.00), I'd basically be adding features to that which are more luxury things that aren't really needed and took a lot of time to make. I'd only be doing something like that though so I could devote more time to the app, which would benefit both the free and paid version.

Code is also open so far for my app and I do take pull requests. I don't really have time to teach someone programming, but anyone that wishes to contribute and submit back to me is welcome to do so. Just try to keep the same code style as me is all I ask when submitting back.


----------



## JDely31

Thank you for this app. It has helped me realize that my lte is functioning properly & that Verizon's lte coverage is not as strong as I thought. As always your posts are very helpful & informative.

Sent from my Galaxy Nexus using Tapatalk 2


----------



## HTC Mike

So I've downloaded this app for my tbolt and its not displaying any 4g info, what's that mean?

Sent from my ADR6400L using Tapatalk 2


----------



## yarly

HTC Mike said:


> So I've downloaded this app for my tbolt and its not displaying any 4g info, what's that mean?
> 
> Sent from my ADR6400L using Tapatalk 2


means your phone doesn't support showing lte info outside of the non accessible (to me) firmware (that is, not accessible at the os level). thunderbolt never could on 2.3 and probably still can't on 4.0. Blame HTC for that


----------



## yarly

Not quite a full update yet (that will come soon), but I did an overhaul of the codebase for this app in order to make it much easier to add features to it and I need to test it some on various devices before sticking it in the market with some other goodies attached. Only user level change is the network type shows your actual connection type instead of generic lte/gsm/cdma. Just thought that was more useful so I switched it. Oh and 2.2 and 2.3 have an actionbar via actionbarsherlock (with nothing in it [yet]) Otherwise, it's all under the hood stuff one would only be interested in if they want to skim my github link for code base source (feel free, it's also full of angry rants when I had to work around shoddy OEM things from Android versions past).

Link to the experimental development version is below (it's not in the market, since I don't consider it stable yet until I'm sure it works fine on at least a half dozen or more device models):

http://codingcreatio...nalInfo-dev.apk

Please give me any feedback on if it happens to crash or does something else weird. Mostly crashes, though. I don't expect other issues really, but it's hard to account for the billion devices out there when dealing with a volatile part of the device that's changed a lot in the past few years (plus OEMs that decide to do whatever they please







)

Also, I need logcats if you find errors. Specifically look for the keyword (or filter for it) "signal" that will pull up the raw signal values before I do too much with them. Mostly looking to see that everything you saw before is still there. (you can dump it out via adb -f debugfile.txt -d logcat signal)

I've only tested on Verizon Galaxy S3, Galaxy Nexus, Nexus 7 and a craptastic Android 2.3 emulator.


----------



## Gorilla

Yarly im getting -83 RSRP pretty sexy..

Getting about 20-28 down... not bad, but im away from the city center, in the burbs.


----------



## yarly

Also, forgot to mention I could use AOSP and OEM skin tests (Touchwiz, Sense, etc). There's differences from the hacks used to get the RIL working on each.

edit: okayy, moving along then. I will assume silence means nothing broke. If not and complaints come later, I will be like


----------



## yarly

Added signal quality readings as percentage (0% being no signal and 100% being near perfect).Percentages are based on the 3GPP standards for each signal reading, but since Android does not use the full range for the readings in every case (and the fact that no one will ever get a 40-50dB signal), they readings have been normalized to be more in line with what one's carrier will consider good or bad for the percentages. In the final release, I will give the option to adhere strictly to the 3GPP standards as well though, but they're not a great indicator of signal quality on Android without adjustment.

This is still a development release and not in the Android Market yet. Version number is 1.2.

As this is a development version, there may be bugs and not everything working 100%.

Currently, the added preference area does nothing (the wrench), so no need to tell me that it doesn't work









Anyone that wants to test it, you can download it from here: http://codingcreatio...nalInfo-dev.apk

may have to uninstall your old version first before installing.


----------



## yarly

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.


----------



## shiznu

This is a really great app everyone should give it a try.

Sent from my Galaxy Nexus


----------



## yarly

there's a small bug I need to fix. Only strict % are displaying and I haven't tracked down why yet. Just in case anyone wonders why the percentages might seem a bit low. 3GPP standards say they start at like -40dbm and end at -140dbm, which is at least 20db off from what Android will show.


----------



## shiznu

yarly said:


> there's a small bug I need to fix. Only strict % are displaying and I haven't tracked down why yet. Just in case anyone wonders why the percentages might seem a bit low. 3GPP standards say they start at like -40dbm and end at -140dbm, which is at least 20db off from what Android will show.


I haven't really compared in a while. Its still a cool app I love a lot of the other features to. I was shocked when I first used the map and it had all the WiFi routers stored.

Sent from my Galaxy Nexus


----------



## shiznu

And yeah I'll admit it, I downloaded it as soon as I knew who the dev was. 

Sent from my Galaxy Nexus


----------



## yarly

*UPDATE (2012-06-03)**: *

Adjusted the signal % readings based on feedback. Relative ones should be a bit closer to what one thinks is a decent signal for their phone.

------------------------------

There's a lot of other stuff I could add and might to the app, but it's getting to the "good enough" point since I added in % readings, since decibel readings are kind of abstract and not easy to compare. I still want to add some of the explanation info into the app found in the OP, but with % readings, it's a good alternative, since I kind of think those that would ever read all that content would do so outside of the app anyways and % offer a good alternative for those that just want a quick way to compare or for anyone that forgets or doesn't want to keep looking up what each reading means.

I've actually spent probably 40-60 hours working on this (large part of it was just research as I'm not a cellular network engineer by trade and most of the good info is in random technical papers). I have a few better app ideas that I've been putting off working on in my free time, so I may start back on those instead. I've surprisingly got more downloads for this than I expected with the limited exposure and niche audience its geared towards. Adding much more, I start to get into features that other apps already have done and not sure it would add that much more value. There's a few cool, unique things left I can add, but just depends on how much time it would take (like for instance, telling you how close you are to the tower you're connected to and in what direction it is).


----------



## JennyTaylia

This is one handy application. Love it

Sent from my Galaxy Nexus using Tapatalk 2


----------



## shiznu

One of my favorite features is how it remembers all the WiFi access points. Yarly is there any limit on how many it can remember? Weather by time, distance or numbers.

Sent from my Galaxy Nexus


----------



## yarly

shiznu said:


> One of my favorite features is how it remembers all the WiFi access points. Yarly is there any limit on how many it can remember? Weather by time, distance or numbers.
> 
> Sent from my Galaxy Nexus


It shouldn't forget them unless you wipe your phone. All that info is stored in the system and I don't actually store it within the app itself, so if you back up your wifi access points and such, they should stay around after restore. Only stuff stored in my app is the preferences under the options area and the little consent form one time acceptance thing.


----------



## shiznu

yarly said:


> It shouldn't forget them unless you wipe your phone. All that info is stored in the system and I don't actually store it within the app itself, so if you back up your wifi access points and such, they should stay around after restore. Only stuff stored in my app is the preferences under the options area and the little consent form one time acceptance thing.


I really may have misspoke on that I was looking using the map mode when I was away from home and I was seeing peoples routers that were out of range of where I was at the time. Is that right or am I confusing something? If so I was curios how it could see those.

Sent from my Galaxy Nexus


----------



## yarly

shiznu said:


> I really may have misspoke on that I was looking using the map mode when I was away from home and I was seeing peoples routers that were out of range of where I was at the time. Is that right or am I confusing something? If so I was curios how it could see those.
> 
> Sent from my Galaxy Nexus


Oh, those only show when you're within range of them. All that stuff is broadcasted from each of them. It may surprise you, but you can always pick up info from any device with wifi turned on (including your own phone, iphones or whatever). Lots of department stores and malls are now tracking you by your wifi signal when you leave it on. Just a tip to turn it off if you care about not being tracked when shopping at a store.


----------



## shiznu

yarly said:


> Oh, those only show when you're within range of them. All that stuff is broadcasted from each of them. It may surprise you, but you can always pick up info from any device with wifi turned on (including your own phone, iphones or whatever). Lots of department stores and malls are now tracking you by your wifi signal when you leave it on. Just a tip to turn it off if you care about not being tracked when shopping at a store.


I just bought Steve spears fences app so I have it setup to turn WiFi off when I'm away from home now. Its a great app if you haven't checked it out already. The WiFi range must be a lot greater than I originally thought your app shows routers that I thought were out of range.

Sent from my Galaxy Nexus


----------



## yarly

Oh, it's any that you connected to before, just to clarify. They may not be in actual range at the moment (if you meant going to advanced device settings → wifi info → wifi config).


----------



## shiznu

yarly said:


> Oh, it's any that you connected to before, just to clarify. They may not be in actual range at the moment (if you meant going to advanced device settings → wifi info → wifi config).


Yes makes sense now since I used to keep WiFi on.

Sent from my Galaxy Nexus


----------



## yarly

*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


----------



## yarly

*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.


----------



## poontab

Whoa I never realized it had %s. Very nice. Maybe link to this thread like a support thread for those with strange radio interfaces.


----------



## yarly

poontab said:


> Whoa I never realized it had %s. Very nice. Maybe link to this thread like a support thread for those with strange radio interfaces.


Added those in back in June I think. Figured it was the best way to show the info without requiring everyone to spend tons of time figuring out what each reading meant just to know if each was improving or getting worse while moving about. Just had to figure out what the max and min was for each and then. do some adjusting based on expected average readings from one's carrier. The relative percentages are more recommended by me even though they're compensating for not living under a tower (more or less). Otherwise, everyone's percentages would have awful percentages much of the time when not standing under a tower.


----------



## poontab

yarly said:


> Whoa I never realized it had %s. Very nice. Maybe link to this thread like a support thread for those with strange radio interfaces.
> 
> Added those in back in June I think. Figured it was the best way to show the info without requiring everyone to spend tons of time figuring out what each reading meant just to know if each was improving or getting worse while moving about. Just had to figure out what the max and min was for each and then. do some adjusting based on expected average readings from one's carrier. The relative percentages are more recommended by me even though they're compensating for not living under a tower (more or less). Otherwise, everyone's percentages would have awful percentages much of the time when not standing under a tower.


yeah first pic strict second adjusted.... Y U NO MAKE SIGNLE BUTTER?! 1 STAR


----------



## yarly

poontab said:


> yeah first pic strict second adjusted.... Y U NO MAKE SIGNLE BUTTER?! 1 STAR


Looks like someone was screwing around with the RIL in 4.3 for the verizon s3. Up until 4.3, they would mirror the values for RSSI for CDMA/ECIO since samsung was too lazy to show both in the RIL. At least they didn't botch the LTE area, though I thought CQI used to show, so have to double check.

edit: double checked and CQI didn't show in 4.2. However, for a while they did screw up signal strength so it wasn't showing in the Android RIL.


----------



## yarly

I was also looking into the Qualcomm SDK for its radio firmware, but it doesn't look all that useful for the time it would take to implement it. They don't really give anything more than what you already get for radio info in AOSP and it would only work on rooted devices (because it requires a modified kernel due to a driver having to be added) and those with a Qualcomm chipset (which is probably 95% of popular Android devices). I did read some bits about letting you set your PRL manually, but that could be a bad thing to implement.

I also don't own modern CDMA qualcomm device (well I do have Thunderbolt, but I doubt the API for Qualcomm will pull much from that).


----------



## poontab

yarly said:


> I was also looking into the Qualcomm SDK for its radio firmware, but it doesn't look all that useful for the time it would take to implement it. They don't really give anything more than what you already get for radio info in AOSP and it would only work on rooted devices (because it requires a modified kernel due to a driver having to be added) and those with a Qualcomm chipset (which is probably 95% of popular Android devices). I did read some bits about letting you set your PRL manually, but that could be a bad thing to implement.
> 
> I also don't own modern CDMA qualcomm device (well I do have Thunderbolt, but I doubt the API for Qualcomm will pull much from that).


Speaking of qualcomm... do you know of a polling method on the adreno gpu?


----------



## yarly

poontab said:


> Speaking of qualcomm... do you know of a polling method on the adreno gpu?


Nope.


----------



## poontab

yarly said:


> Nope.


1 star


----------



## yarly

poontab said:


> 1 star


Speaking of that, I had someone "threaten" me with a 1 star review in a crash report message today, lol. It was butchered horribly as well.

"I can't be bothered to email you to help fix it despite your description stating it a few times and why, but I'll send you a crash report with a misspelled attempt at developer blackmail"

I notice like 1-2 crashes a month for various cheap Chinese devices and never once do they ever bother to contact me. Crappy devices totally ignore how the RIL is implemented in AOSP and roll their own bs, so I have no idea how to deal with it from the vague crash report alone. If I get another, I think I'll just start blocking them, since no one wants to be helpful that owns them.


----------



## poontab

yarly said:


> 1 star
> 
> Speaking of that, I had someone "threaten" me with a 1 star review in a crash report message today, lol. It was butchered horribly as well.
> 
> "I can't be bothered to email you to help fix it despite your description stating it a few times and why, but I'll send you a crash report with a misspelled attempt at developer blackmail"
> 
> I notice like 1-2 crashes a month for various cheap Chinese devices and never once do they ever bother to contact me. Crappy devices totally ignore how the RIL is implemented in AOSP and roll their own bs, so I have no idea how to deal with it from the vague crash report alone. If I get another, I think I'll just start blocking them, since no one wants to be helpful that owns them.


Don't they have different radio tech for consumers? Like TD-SCDMA & such.


----------



## yarly

poontab said:


> Don't they have different radio tech for consumers? Like TD-SCDMA & such.


Maybe, not sure. Though OEMs are not supposed to be messing with public areas of the Android Source or the expected formatting of what is returned from them, only the parts app developers shouldn't be accessing. In theory, a call to toString() on an HTC device should give the same formatting as a Samsung device or any other Android device. All the first rate OEMs do that pretty well and hasn't been an issue really since ICS. Some might leave out some info for things like the RIL (as shown with your screen shots), but that can be predicted and accounted for fairly easy.

Google frowns on screwing with the public API in their OEM guidelines, but I don't think Huweai gives a crap, since they don't respect things like GPL either.


----------



## poontab

Crazy what going to the end of my street does. Adjusted & strict.


----------



## yarly

poontab said:


> Crazy what going to the end of my street does. Adjusted & strict.


Wish my signal was that great at my house. I get similar results walking about a quarter of a mile in either direction.


----------



## poontab

yarly said:


> Crazy what going to the end of my street does. Adjusted & strict.
> 
> Wish my signal was that great at my house. I get similar results walking about a quarter of a mile in either direction.


it's never where you live


----------



## yarly

I was bored and decompiled the Telephony bits to a Huawei device. It's as awful as I thought. Though I did find some useful stuff in there for GSM devices as well that some OEMs decide to add that AOSP does not. Looks like it might apply to some Samsung devices well, at least the S2 and maybe S3.

From a very broken Huawei device:

https://gist.github.com/yareally/6559794


----------



## poontab

yarly said:


> I was bored and decompiled the Telephony bits to a Huawei device. It's as awful as I thought. Though I did find some useful stuff in there for GSM devices as well that some OEMs decide to add that AOSP does not. Looks like it might apply to some Samsung devices well, at least the S2 and maybe S3.
> 
> From a very broken Huawei device:
> 
> https://gist.github.com/yareally/6559794


Exynos S2 & S3 or would it be across the board?


----------



## yarly

poontab said:


> Exynos S2 & S3 or would it be across the board?


Not sure yet. Have to test some first or decompile some more crappy ROMs.


----------



## poontab

yarly said:


> Not sure yet. Have to test some first or decompile some more crappy ROMs.


The ECIO & SNR appear on the note2 with exynos4. Still no CQI.


----------



## yarly

poontab said:


> The ECIO & SNR appear on the note2 with exynos4. Still no CQI.


I should see if they're screwing around with that as well.


----------



## poontab

yarly said:


> I should see if they're screwing around with that as well.


It could be the CM RIL. Might be helpful to have an international SGS3 or something running touchwiz report.


----------



## yarly

poontab said:


> It could be the CM RIL. Might be helpful to have an international SGS3 or something running touchwiz report.


Actually have a few nice users with s2s and s3s on gsm that should hopefully test for me.


----------



## zvogt

Forgive me if I'm missing something, but if I look at your sample LTE RSSI calculation near the bottom of the first post you use an RSRQ value of -8 and a RSRP value of -108 to arrive at an RSSI value of -83, and the math looks correct within that sample. However, the actual math used in the computeRssi() method in the LteInfo class is slightly different, and actually would return an RSSI value of -99 for those sample numbers. I believe the latter is correct. I just want to make sure I have an accurate grasp of the calculation. Can you confirm?


----------



## yarly

zvogt said:


> Forgive me if I'm missing something, but if I look at your sample LTE RSSI calculation near the bottom of the first post you use an RSRQ value of -8 and a RSRP value of -108 to arrive at an RSSI value of -83, and the math looks correct within that sample. However, the actual math used in the computeRssi() method in the LteInfo class is slightly different, and actually would return an RSSI value of -99 for those sample numbers. I believe the latter is correct. I just want to make sure I have an accurate grasp of the calculation. Can you confirm?


I'll double check. I forgot to run my unit tests to verify I didn't introduce any regressions last time I pushed an update and I know I changed the way RSRQ is presented to some devices because Qualcomm thinks it should be positive when it's not.


----------



## gaetawoo

geniuses... the whole fracking lot of you.


----------



## yarly

zvogt said:


> Forgive me if I'm missing something, but if I look at your sample LTE RSSI calculation near the bottom of the first post you use an RSRQ value of -8 and a RSRP value of -108 to arrive at an RSSI value of -83, and the math looks correct within that sample. However, the actual math used in the computeRssi() method in the LteInfo class is slightly different, and actually would return an RSSI value of -99 for those sample numbers. I believe the latter is correct. I just want to make sure I have an accurate grasp of the calculation. Can you confirm?


You were right, it was off. Seems it was due to what I thought, changing the RSRQ in the previous update. Will be releasing a fix soon.

17 + parseInt(signals.get(Signal.LTE_RSRP)) - parseInt(signals.get(Signal.LTE_RSRQ))

Fixes it, so it comes out to be: 17 + (-108) - (-8)

Anyone that wants to run a fixed version of it you can get it from my server until I put it on the market. This is a slightly experimental version as well because I rebuilt the application using Scala instead of Java and I ditched TableLayout for the more efficient GridLayout. Something crashes, let me know, as I've only tested it on Android 4.0 and newer and on Nexus devices.


----------



## zvogt

Sorry for the delay in responding. I was in the middle of transitioning from my Galaxy Nexus to my Nexus 5, and also transitioning from Verizon to T-Mobile, coupled with holiday break I ended up getting stuck in limbo for quite a few days with two Nexus devices, but no functional SIM cards. But I'm back online as of this afternoon. The apk works, however if I click the settings wrench icon in the upper right corner the app force closes on both of my devices. On both devices I'm running weekly SlimKat 4.4 builds. At first I thought it might be related to changing my runtime to ART, but I reverted to Dalvik and I still see that same symptom.


----------



## yarly

zvogt said:


> Sorry for the delay in responding. I was in the middle of transitioning from my Galaxy Nexus to my Nexus 5, and also transitioning from Verizon to T-Mobile, coupled with holiday break I ended up getting stuck in limbo for quite a few days with two Nexus devices, but no functional SIM cards. But I'm back online as of this afternoon. The apk works, however if I click the settings wrench icon in the upper right corner the app force closes on both of my devices. On both devices I'm running weekly SlimKat 4.4 builds. At first I thought it might be related to changing my runtime to ART, but I reverted to Dalvik and I still see that same symptom.


Hmm, that's odd. Can you get me a logcat? Something must be up with ActionbarSherlock. Probably related to proguard, since I have to use it with Scala to cut down the library sizes, else my app would be 5-6 mb (if it were possible for Android to hold it, since it exceeds the max allowed functions by like 1000 or so).


----------



## zvogt

logcat attached


----------



## yarly

zvogt said:


> logcat attached


Hmm, when did you grab the app? I think I fixed the error I'm seeing in the log, because I was experiencing it. Try grabbing it from my server again and update. Let me know if it's fixed if you can please.


----------



## zvogt

I just re-downloaded from the link in your post, and i'm still having the same symptom (and the file i just downloaded has an identical MD5 checksum value as the file I downloaded on the 28th).


----------



## yarly

Hmm, let me grab it. I might have forgot to update the version on my server.


----------



## yarly

https://www.dropbox.com/s/kfppnxz39fg4o8f/com.cc.signalinfo-1.apk

Try this. It's what I am currently using and it has a different hash.



zvogt said:


> I just re-downloaded from the link in your post, and i'm still having the same symptom (and the file i just downloaded has an identical MD5 checksum value as the file I downloaded on the 28th).


----------



## yarly

That may not work for you either and I'll have to look into it when I get home. I tried the one on my server and it worked for me, so have to see if it's an issue with abs


----------



## zvogt

yarly said:


> That may not work for you either and I'll have to look into it when I get home. I tried the one on my server and it worked for me, so have to see if it's an issue with abs


You are correct, that one also has the same symptom for me. Thanks for all the effort you're putting into this.


----------



## yarly

Seems to be some issue with Android 4.4 and the way it verifies things now for fragments:

http://stackoverflow.com/questions/19973034/isvalidfragment-android-api-19

Have to make that change and rebuild it.


----------



## yarly

zvogt said:


> You are correct, that one also has the same symptom for me. Thanks for all the effort you're putting into this.


When I have someone that's able to test things pretty quick, doesn't take me too long to turn around most fixes, so thank you as well.

Okay, try this, should be good to go, but I don't want to load up the emulator to test Android 4.4 to verify tonight.

http://codingcreation.com/android-apps/SignalInfo-dev.apk


----------



## zvogt

The new apk has a different byte-size than the previous one, so I'm confident I'm running the newest iteration. Unfortunately the new one still has the same symptom for me on 4.4. I'm attaching a new logcat in case it helps.


----------



## yarly

zvogt said:


> The new apk has a different byte-size than the previous one, so I'm confident I'm running the newest iteration. Unfortunately the new one still has the same symptom for me on 4.4. I'm attaching a new logcat in case it helps.


Hmm, I'll just drag out the emulator and test it on 4.4 before updating it later today. Thanks though for the followup.


----------



## yarly

Started a beta testing channel on the market for anyone interested. Mostly looking for people with devices I do not own and do not have testers for already. Also, you have to know how to use logcat and send me reports if you're interested.

What do you get out of it?

-- Access to early releases and updates via the Android Market you already use

-- Access to a private discussion area for app issues (Google Groups)

-- Ability to give me direct feedback via Google Groups

You can opt in and out at any time, but I have to have a gmail email to add you to the testing pool, so you can either PM it to me or email it to me (see email on the market under my app).

Please send me a message with the following:

- your gmail email that you use for the market so I can add you to the testing pool

- devices you are willing to test

- android versions for each device (and if not running stock, the ROM each is using)

All information sent to me is private and will only be used for adding you to the test pool. I have no interest in your email otherwise.

You can also request access by contacting me directly at the mentioned group with the required info listed above.


----------



## yarly

*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


----------



## abe_cedar

Hi Yarly
Thanks for fixing the root issue. There is a mistake in the code as lte snr does not calculate anymore. It says na. Worked fine in the prev version. I assume is something simple.
TIA.


----------



## yarly

abe_cedar said:


> Hi Yarly
> Thanks for fixing the root issue. There is a mistake in the code as lte snr does not calculate anymore. It says na. Worked fine in the prev version. I assume is something simple.
> TIA.


Hmm, can you get me a screen shot with debugging enabled please? Might have to wait a few moments for the info to show up.

EDIT: nevermind, fixed it and pushed out an update. Assuming no more bugs, probably no significant updates again until sometime in February. Too much other crap to do right now unfortunately.


----------



## thompcd

So I haven't seen implications in this thread that you would, but haven't been able to find a way to do it through others either. Just wondering if you had any thoughts about replacing those signal bars with a dbm value? I haven't seen it done in any stock rom and i'm not a dev, so I have no idea how much of a pain that would be.

Thanks for the great app!


----------



## yarly

thompcd said:


> So I haven't seen implications in this thread that you would, but haven't been able to find a way to do it through others either. Just wondering if you had any thoughts about replacing those signal bars with a dbm value? I haven't seen it done in any stock rom and i'm not a dev, so I have no idea how much of a pain that would be.
> 
> Thanks for the great app!


Sorry for the delayed reply, didn't get a notification. That's something that's outside the realm of an app really (at least one that's trying to avoid modifying stuff on the system level [which draws too much attention from Google these days on the market]). Lots of ROMs have that feature though, such as Cyanogenmod and AOKP. There's probably something for the Xposed framework that does it I would assume for stock ROMs. I would try looking there first. Eventually I might add a notification to show signal, but don't think I'd want to get into replacing the bars.


----------

