boomerbubba

Nice work, troy96. Now we just need some brave souls in an LTE market to follow through: Document the menu choices and default values, tweak a setting if you understand it and think it would help, then test that hypothesis in an area with known live LTE towers. Hopefully you pilgrims will sort this out before I have to pull the trigger and buy that SG3.

Yes, eHRPD will substitute for EVDO to facilitate handoffs from LTE connections. Non-LTE phones would probably just see EVDO. You might try CDMA Field Test instead, which actually captures the connection type in its log. FWIW, I don't like Netmonitor anyway for privacy reasons.

Its possible, and I had not considered that. And that would do it. But if so, its not a good move, IMO. They need to adjust it down some more. Especially if they are going to claim the coverage areas that they are. Robert via CM9 Kindle Fire using Forum Runner If this threshold was set deliberately by Sprint marketers rather than engineers, they deserve to eat their own dogfood because this rollout has generated some bad PR.

Robert and several others have noted that the various third-party Android apps that purport to report signal strength for LTE connections get it wrong. I have been researching this, and it seems that the underlying Android API is pretty messy in the way this information is made available to calling apps. In the first place, the standard Android telephony API does not yet define a consistent method for providing this data, like it does for GSM and CDMA phones. (It also does not provide for Wimax.) There is an outstanding feature request at Google to expand that standard, but no action yet. One comment under that outstanding issue documents a workaround, but it was not documented until about three weeks ago. This does not excuse the third-party developers for reporting the wrong values, but it does help explain how they came to do so. The lack of a standard Android programming interface also means that the OEMs (manufacturers building phones to carriers' specs) writing firmware on various devices have been on their own, probably pulling this data from lower-level drivers or hidden APIs. I certainly hope this is not the root cause of the apparent problems setting the thresholds levels at which Sprint handsets fall back to EVDO from LTE connections. Getting the actual LTE signal strength right is obviously critical to that. (I also found that one app developer, frustrated with inconsistent practices by OEMs who even mess up some of the Android API calls that are standard, has built a diagnostic app to discover and catalog what different devices actually do at the API level.)

Excellent summary of all the anecdotal test results. The only other factor I would add is that we know that the initial rollout of LTE towers in the first markets is pretty thin as a percent of eventual coverage. Those who read this forum closely understand that, but many end users do not. This thin coverage factor obviously would multiply the damage of the high LTE/EVDO fallback threshhold programmed into the handsets.

You cannot trust the "tower" locations in Open Signal maps. They are just guestimates based on crowdsourced signal-strength triangulations, which can be wildly inaccurate. Even the Open Signal developers warn of inaccuracy.

Maybe. CDMA FT does only map one site at at time, just passing the coordinates. And Nemonitor's map display is certainly handy. (I still prefer to export the data and map it myself anyway.) The developer never mentioned that functionality in our email conversation. He indicated the Internet access is required for whatever method the app uses to try finding GSM locations. There is an Android mapping API that does not require setting up a generalized Internet socket, which is what Netmonitor does. That same socket could also be used for any purpose, and the user would really have no way to know for sure. Unfortunately, Google sometimes bundles Android permissions a little too broadly. For example, an audio app might have a legitimate need to detect that there is an incoming phone call to suppress music output. But giving it permission to do that also gives permission to know my phone number and the number I am connected to. The way the Android ecosystem works, all end users are responsible for their own safe computing after being notified of permissions, which 99 percent of users don't understand. Heck, I consider myself pretty knowledgeable, but I know I have tapped through those permissions when installing apps lots of times. I had to go research this stuff to find out what the permissions meant. The net effect of generalized permissions and fallible human users is that there are some very questionable apps being installed out there. And it is easy to forget that when granting permissions, we users are not granting them just to Google -- or Microsoft, Apple, Facebook, etc. -- corporations with a domestic address and a published privacy policy, but to developers who for all practical purposes are anonymous and beyond legal recourse. A particular developer, known only through his Gmail persona, may be quite benign. But he may also be harvesting private information (phone call records, IMEIs, locations, etc.) for scummy marketers, stalkers, hackers etc. just through social engineering. More egregiously and obviously, right now you can find half a dozen apps on the Google Play market that purport to "boost" the user's cell connection by "optimizing" it or some similar snake oil. I think that advertised functionality is mostly a phony placebo, just resetting the phone or something similar by toggling settings. But if you look at the permissions granted to those apps (which overlap with much of Netmonitor's permissions, including Internet access) they seem to be poised to rape the user's privacy in the background. These apps have tens of thousands of downloads. So I just get suspicious in the presence of three things: Developer is basically an anonymous stranger. App has permissions to read a lot of private data. App has full Internet permissions.

Again for the record, I received an email from the Netmonitor developer, who says that one recently added feature as been removed in a new version: I checked Google Play, and the specific permission for Netmonitor to "read sensitive log data" is no longer there. This effectively backs out the expanded perimission that the most recent prior version had requested. All the other permissions remain, notably including full Internet access, and there is no feature of Netmonitor I use that requires that. I still can get what I need from CDMA Field Test, which has less intrusive permissions and no Internet access. So a decision to install Netmonitor comes down to how much one trusts the developer.

Apps such as CDMA Field Test will accurately capture the Network IDs and Base Station IDS broadcast by the tower radios you connect to, along with a lat/lon coordinate for each sector BSID. The Sponsor-accessible maps at S4GRU accurately map the towers themselves. Correlating the coordinates to actual tower sites depends on the configuration of each tower, which fits one of two cases: Some BSID coordinates for all three sectors per tower closely match the coordinates on their tower. Other towers are configured such that each sector squawks coordinates offset some distance from the tower, the three forming a triangle. So correlating the BSIDs to towers is a bit of a trial-and-error art, but it is quite possible once you get the hang of it. You will need to figure out which of these configurations fits your tower. You might need to travel around the tower to log all three sector BSIDs.

Inquire to whom? Frontline Sprint reps? They may not know much anyway, and are good at playing dumb if they do know stuff. The identifiers picked up by apps such as CDMA Field Test, etc., are network IDs that fit the CDMA standard and are broadcast. There is a hierarchical set of codes that identify, system, operator, network and base station. Each base station represents a sector, and there are typically three sectors per tower. There is no ID in this hierarchy that corresponds one-to-one to a tower, although Sprint's practice seems to be to assign sequential BSIDs to the sectors of each tower. These sector base stations also broadcast lat/lon coordinates, which might all coincide exactly with the tower location. However, some of those BSID sector coordinates are not the actual tower locations but rather are offset in a triad pattern. We don't know why. If you become a sponsor here and see the project maps, they are tower-oriented. There is an identifier, apparently assigned by Sprint, visible per tower on the S4GRU maps. The coordinates of the towers are accurate. There is no easy way here to correlate the tower IDs to the CDMA network IDs in a table. Such tables surely exist somewhere within Sprint, but we still don't have them.

But we should understand that the S4GRU tower maps do not purport to be coverage maps, like Sprint's own maps do. To compute geographical signal coverage for the towers, it would be necessary to use software that includes lots of other inputs, such as azimuths and downtilt angles for each sector on a tower, along with physical and man-made topography. I think there once was an ambitious goal in these parts to built such theoretical coverage maps using the resources at CloudRF.com, but that apparently was not feasible. So we just have to tower points which are way better than nothing. And since Sprints coverage maps seem to be, uh, optimistic, having the actual tower sites is a good reality check.

Open Signal's "tower" locations are just guesses based on crowdsourced signal-receptions data. They are notoriously inaccurate. Even Open Signal's page on the Google Play market site warns about inaccuracies. There are other apps, such as CDMA Field Test, that report lat/lon coordinates broadcast by the sector base stations themselves. In some cases, those sector coordinates match the actual tower location. But in others, each sector's base station on a given tower reports different coordinates offset by some distance, possibly miles away in large cells. We don't know why this is.

Duplicate post.

Try CDMA Field Test. Open SIgnal's tower locations are inaccurate guesswork based on crowdsourcing. One caveat: The tower coordinates captured by CDMA Field Test and similar apps will be the lat/lon broadcast by the sector base stations and captured by the Android device. But there seem to be two distinct situations: On some towers, all sector base stations will squawk the actual coordinates of the tower; on others, each sector will squawk different coordinates that are offest some distance away from the tower.

I wondered the same thing. My surmise is that this is mostly just a reporting lag within S4GRU, although it was understood that there would be something less than 50 percent at the official launch.

I doubt that zoning and permits have much to do with this, since the NV sites in almost all cases are using the legacy towers.

For the record, I have received another email from the Netmonitor developer: I am unpersuaded, except for the suggestion that I just don't use the app. But I may be wrong about the capabilities of CDMA Field Test. It does not seem to capture coordinates in its log, even though there are values displayed in the app' s main screen for one BSID at a time. (I saw another user here in another thread say he logged coordinates with this app, so I am confused.) Edit: Thanks to tutoring from nseabrook, I now see that CDMA Field Test's logging of both coordinates and signal strength works after all. The trick is that the user must tap the button to email the logs, not just view them onscreen. That includes both a kml file and a csv file. I can work with that just fine. Netmonitor still leaves me queasy. I prefer not to use it.

But that still captures only WiFi. I don't know of any way to sniff Internet traffic over the air via Sprint. Sent from my SPH-D700 using Tapatalk 2

Wireshark could be set up to sniff your own WiFi traffic, I think, but not OTA data.

Unfortunately I lack the hands-on Java and Android programming skills, although I have enough knowledge as an analyst to read the docs and know generally what is possible. For the time being, I will use CDMA Field Test intractively and view its simpl e maps. For more complex multisite maps, it is easy to export. Edit: Now I am no longer sure CDMA Field Test can log coordinates, even though it captures them interactively. Still exploring that.

Like many here, I have used Netmonitor as a tool to try mapping local Sprint towers. But recently I have investigated its privacy settings, and decided to uninstall the app. I wish I had never installed it. Basically, the Android permissions granted to this app would allow it to harvest my phone number and those I contact, the unique IMEI of my device, my location, my WiFi settings, and other detailed data on my Android phone. Plus, it has unlimited Internet access so any harvested information could be sent to any server anywhere without my knowledge. The most recent version asks to expand the privileges even further to read sensitive log data. I can't know that the app is actually doing anything I wouldn't like with my private information, but anyone installing it has to trust the developer not to do so, having granted the Android app permissions. But who is that developer? He has no published identity beyond an Gmail address, and no published privacy policy. I don't even know where he is, but the app's example screenshots on the Google Play site show locations in Belarus. The developer has responded to email questions, but I find the responses very unsatisfactory. According to Google's Play market site, here are the sweeping permissions that Netmonitor is granted when installed: I emailed the developer, asking why all these permissions are justified. I also asked who he is and where is a published privacy policy. The answer I got seemed like incomplete doubletalk to me: In fact, the cell location does not come from Google on the Internet, but rather gets them directly from the Android's own API, which gets the coordinates over the air from the cell towers themselves. Several other apps, such as CDMA Field Test, do this without any Internet access at all. (The app's help screen does include another possibility for cell site location, which I have never seen in practice. That other possibility is referred to as "coordinates came from Gears Geolocation API." But Google says the Gears API is deprecated and is no longer available. Even when it did exist, Gears geolocation did not provide a tower location, but the phone's own estimated location. And location is available to an Android app directly from the Android API by the Location permissions alone.) Although CDMA Field Test is not quite as handy, I think it does basically what Netmonitor does for me, but without the privacy concerns and without all the intrusive permissions. In fact, it has no Internet permissions. So I am uninstalling Netmonitor.

I see. Do be advised that the sites mapped by Netmonitor here, at least in the screenshot that maps the two sites labeled 03809 and 03795, are not actual Sprint tower locations. (Sponsor-level members here can see maps of the actual towers.) Netmonitor is plotting the coordinates broadcast by these two base station radios, but these coordinates apparently are offset some distance from their towers' actual sites. This phenomenon occurs on many Sprint towers, although many others broadcast their actual locations. So the LTE base station you logged (12706) may not be where your map shows it, either.

Your first Netmonitor screenshot does indeed show an LTE connection, but it is not the same base station mapped in the other screenshot. Between those snapshots, your connection must have changed. Or something else is awry.

Didnt know about this app. Comment say this thing is running in the background? Not good. Open Signal is primarily an online app that crowdsources coverage areas and guesses at tower sites from that data. The tower guesses are not very accurate. I think it does run in the background if you give it permission to collect and post your logged signal strength data to their website.

I don't know who the manufacturer of your repeater product is, so the question needs to be posed to them. I wondered the same thing generally, so I made an inquiry recently to Wilson Electronics, which seems to be a market leader in repeater products for both vehicles and buildings. The response, in another thread, indicated that their frequency coverage will have to be tweaked to handle Sprint's LTE channels. Their response said it was just a problem of frequency bands, not LTE technology itself. But sInce I made that post, I have wondered further about how MIMO (dual antennas) in LTE might be affected, since the repeaters are built around a single antenna. I don't have an urgent need in this regard, but I am interested to see what happens.