boomerbubba

If you are running custom ROMs, as your profile indicates, I suspect an incompatibility there.

Ahh. I misread the post in haste. This was not an announcement, but rather Sprint adding Austin and other cities to its own "coverage map." We all know that this map has little credibility.

I'm surprised about the Austin announcement. There is still a big coverage hole in central Austin, including downtown, the Capitol complex and the UT campus area. In places further out, coverage is better. And in some areas, such as Pflugerville and Wells Branch, it is almost complete. Austin went on the "in progress" list a long time ago. And this is not a launch today. Just another Real Soon Now statement that adds no real news.

Have you enabled the tethering service on your Sprint account? That is the only way to do this under the standard contract terms. Tethering without enabling the billed service is not supposed to work. And BTW, I believe that discussion of how to subvert the terms of service is a violation of S4GRU's policy.

You aren't.

Have you tried the embedded Sensorly map at S4GRU?

I doubt that it is blocked, exactly. More likely many OEMs just failed to implement all the Jellybean API. I have read that implementation of the whole Android telephony API was imperfect in earlier versions, too.

The IDs that app displays are not the LTE sector IDs. They are the CDMA sector IDs, which may be referring to a completely different site. Conflating the CDMA and LTE data like this is a common failing of several such apps. Looks cool, but misinformation.

The LTE sector IDs are available in the Jellybean 4.1.1 API. But according to what the devs at Sensorly say, so far there are few devices that populate it.

I misread patrickdurhamno's comment, mistaking the comma for a decimal point. A signal strength of -105 dBM RSRP is much more consistent with a full mile, rather than a tenth of a mile.

If you were that close to that tower with a clear line of sight, your relatively weak signal of -105 dBm RSRP is a good indicator that this signal is actually coming from somewhere else. It could be miles away.

The dev team at Sensorly is reporting success using the 4.1.1 Jellybean API to harvest this information, but only on certain devices that populate it -- which does include the stock Samsung GS3. Sensorly hopes to release this in its user interface before February.

Osborne I -- 64 KB RAM, 8-bit Z80 CPU, two 95-KB 5-1/4 inch floppies, 5 " screen, luggable, CP/M operating system. For $1,800 -- a price breakthrough -- it came bundled with WordStar and a Supercalc spreadsheet program. I then acquired dBase 2, a dot-matrix printer and a Hayes 1200 baud Smartmodem, which seemed very fast compared to the 300 baud acoustic coupler I had used with my Texas Instruments terminal to dial into CompuServe and write my first Basic program. Altogether this gave me more computing power than my midsized employer had available to managers there. Entrepreneur Adam Osborne then pre-announced the Osborne II before it was ready, just as the IBM PC was introduced Sales at his single-product company dried up and the company cratered. I think this is still taught as a business school case in how not to do tech marketing.

Are we talking about the same API calls? This LteCellIdentity element is what I was referring to in 4.1.1

Using what version of the SDK? In Jellybean, I don't think you need to go around the barn with reflexion and hidden APIs. There are direct API calls to this stuff. I have no hands-on experience, just read the docs.

There are LTE sector IDs (both short integers for Physical Cell IDs and long 28-bit integers for Cell Identity) available in the expanded API for Jellybean. It would be nice to see these in Sensorly's Detail screen. The utility of all this would be multiplied if Sensorly provided the user a way to export a log of their own data points.

I don't. There may be some unexplained artifact or anomaly on the GS3 that you have experienced and I cannot replicate. But whatever that is, I do not believe it is caused by "the radio" changing the received signal strength at the antenna.

I have no informed opinion on the effects of an inbound call or any other event that occurs on the site base station radio, which is responsible for its own transmitted signal. But this is an entirely different set of facts than the OP described. His theory was that just opening a data connection on the handset would cause "the radio" to make the inbound signal stronger. Unless this involves some interaction with the base station transmitter that triggers a stronger signal there, which would affect the received signal strength on the handset, that theory makes no sense.

Sorry, but that makes no sense. The RX dBm is measured at the antenna's input to "the radio," before "the radio's" circuitry amplifies anything. The only factors affecting measured RX signal strength are the actual strength of the signal in the particular environment, and the efficiency of the antenna. BTW, I just tried to replicate this experiment on my GS3, and my results do not confirm your original claim. Changed the phone's settings to CDMA only and rebooted. Placed the phone flat and stationary on a desk. Opened the 1x Engineering Protocol screen and noted the BSID I was connected to. Opened the 1x Engineering RF screen and recorded the RSSI signal strength: -95 dBm. Opened the Google Maps app and browsed to download fresh data for map tiles. Rechecked the two engineering screens. The source BSID was the same, and so was the signal strength: -95 dBm

That would not affect the RX power, which is what you are reporting is changed. The RX signal level is supposed to be what is detected by the antenna, before any amplification.

Because Sensorly is built upon cumulative, crowdsourced data collection. And most Sensorly users are on the roads, especially arterial roads.

Do these observations refer to CDMA data connections, to LTE connections or both?

That's right. The Samsungs display only the Physical Cell ID. The EVOs display only the Cell Identity. The only device I know of that displays both in its native diagnostic screens is the iPhone 5. There also are no third-party apps that I know of that will display and log all this, along with other useful information such as the RSRP signal strength, user geographic coordinates, and timestamp. These LTE data elements were not available in the Android telephony API until Jelly Bean, which does expose them in a standard way to app developers. A logging app could be developed now for Jellybean devices, but AFAIK (as far as I know) it has not been written yet.

IIRC = "If I remember correctly" The GS3 LTE Engineering screen typically shows the last ID and signal-strength data from the prior LTE connection even after the LTE signal is lost. So you have to be careful to look for the 4G icon on the phone's top status bar to confirm that the connection is alive.

There are two IDs defined for LTE sectors and sites, and Sprint towers broadcast them both. There are no lat/lon coordinates broadcast for LTE. The Physical Cell ID, an integer between 1 and 507, is broadcast for each sector. This value is available on Samsung devices' LTE Engineering screens (labeled there as the Serving Cell) and on the Field Test screens on iPhone 5 handsets. Empirically,k we have discovered that the three sector IDs on a typical tower are offset from each other by a value of 169. (For example, 148, 317 and 486.) The Sector Cell Identity, a 28 bit integer/ This value is displayed on EVO LTE 4G handsets' LTE Engineering screen (IIRC, it is also labled Serving Cell.) The EVO displays this ID as a 8-digit hexadecimal value, but only the rightmost 7 digits after the leading zero are significant. Within those 7 digits, the first 5 digits are identical for each tower. The last 2 digits are 01, 02 and 03, representing the sector. The iPhone also displays this ID, but converts the value to an 8-digit decimal integer. The only way to relate these IDs to Sprint site IDs, and thus to geographic coordinates, is to physically survey and catalog them in the field. This is being done in Sponsor threads for certain areas, notably Austin and New Orleans.