boomerbubba

I use Sensorly all the time, but every time I try to report my results it throws and error code and crashes. I have not seen any 4G yet. I mostly travel around SDSU area and up into the Clairemont area.

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.

Thanks!! Glad we are in the sponsor's forum.

You aren't.

Have you tried the embedded Sensorly map at S4GRU?

Then it sounds like it was blocked in the programming on many devices.

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.

I've also been using this app along with Sensorly to map out LTE. The app is MyMobileCoverage in the playstore.

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 sector info is there but not by a normal api. You have to request it from the baseband then parse it out.

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.

From the poland ave tower , 1 mile north west of it.

484 is indeed the Japonica St. At Marais site though.

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.

From the poland ave tower , 1 mile north west of it.

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.

After a bit more poking around in the code Google has thrown over the wall, here's what I can say about the getAllCellInfo() API in Android 4.2 (specifically in the *ServiceStateTracker classes of the Telephony API):

 

- It just returns null on GSM phones, with or without LTE (not implemented at all, so base ServiceStateTracker does it).

- It just returns null on CDMA-only phones (subclass returns null).

- It works on an CDMA+LTE phone, but only returns LTE data.

 

So if you're a brave soul running a Sprint LTE phone with a 4.2 ROM (either official or a mod) it may work. But I wouldn't hold your breath on any other devices.

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.

Looked at it and indeed the "hidden" 4.1 api was released in 4.2 but every call to getAllCellInfo() returns null on my GSM Nexus 4.

If anyone is reading this and has seen values returned by that call, let me know and we'll test together

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

I implemented calls to that API using reflexion but I have yet to see anything be returned. Are you aware of any phones that do ?

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.

Right now, phones don't provide LTE cell information so no way to lists sites.

What functionality is missing in Sensorly for you exactly ?

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.

Then how would you explain that other Devices such as the new EVO LTE does not experience this problem only the Galaxy S3

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.

Still though the Transmit power from the tower is the same its just the radio underpowering itself when idle/not used.

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
  

It's not based on the equipment on the cell site to control the power I suspect it's the chip controlling the TX power

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.

How come http://www.sensorly....t/lte_310sprint only shows the lte on the roads and not everywhere it actually is??

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

For those who are whining that they are getting poor reception from it its because the Radio is under powered when not using data and when idle thats battery conservation at work

 

Once you start using data it revs up the Radio power

just like the processor when its not in use it drops to a lower clock speed when its inuse it revs up to the clockspeed that its made to go.

 

you can see this go to about phone then look at the signal dbm

then download something from the Play store over cellular then head back to the signal dbm

you will see a change in signal strength.

Correct. And the difference is dramatic. My Galaxy S3 will idle with a 98 receive level. This allows it to stay connected and be ready for an incoming call. As soon as the phone detects any incoming activity (Or any outgoing activity), it suddenly shows the receive level going 5-7 db higher. Happens every time. I have seen this for several months and at first did not believe what I saw. Not sure how it does this, but it works well. It may differ if you are much closer to the cell site than I am.

I suspect it must talk to the cell site and agree on power levels or something. I do not understand how it is done.

I have a second Galaxy S3 and it does the same thing. I am connected to a upgraded NV Cell site.

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

Too many acronyms.

 

Does the Sector Cell ID show up anywhere on the GS3 engineering screens? The GS3 Serving Cell appears to be the Physical Cell ID, not the Sector Cell ID.

 

Later: Actually you answered this on Dec. 20 in another thread: No. Oh, well.

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.

Boomerbubba: Thanks for your reply, it seriously helps my understanding. I should have been clearer in my post that I knew that BSLAT & BSLON were for the 1X transmitter, not LTE.

 

2 follow-on questions: 1. Does the IIRC show up anywhere on the GS3 engineering screens? It seems like this field is the only way to actually pin down the LTE cell ID, and I can't find it on my GS3.

IIRC = "If I remember correctly"

2. Does the GS3 LTE Engineering Screen show LTE parameters even when the LTE signal is so weak that the phone is locked to CDMA? When I looked at the screen while in my house, it was showing an RSRP of -119, I believe from a transmitter about 3 miles south of me, which I know has LTE, while CDMA Field Test app was showing CDMA and Evdo RSSI's in the 90's, I think from a tower about 1.5 miles northeast which doesn't have LTE yet.

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.

Which leads me to an LTE question: I know that the engineering screens, the CDMA Field Test app, Netmonitor, etc., get and report the sector ID, and that it is the 1X ID, and they also get and report the BSLAT and BSLON, thus pinpointing the sector logical location (and the tower physical location in some places, including northern Illinois). LTE must generate some sort of ID field, in order for the phone to know what antenna it is connected to. Is there any way to find that LTE identification (if it exists), so that you can determine what different LTE antennas are seen by the phone, even if you can't directly see their locations? At least you'd know if you were seeing the same antennas, different antennas, new ones, etc., etc.

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.