Jump to content

Problems programming Android signal-strength reporting for LTE


boomerbubba

Recommended Posts

Cool. I got an email report from someone with a Samsung S3 where the v17 API doesn't seem to be reporting anything. That may have been a bug at my end; I'd be curious if it works now. I drove around a bit in some LTE areas and was able to fix a few buglets while I was out on the road (rapid application development in the car, always fun).

 

I also added a new feature (which should work on any Jelly Bean CDMA phone): a second log, "esmrcells.csv", now logs your location, SID/NID/BSID, and 1x signal strength when connected to a 224xx SID. Might help people with finding live ESMR cells. I probably can tweak the app a little to actually run OK on ICS too, for people that are interested in doing some ESMR tracking.

Link to comment
Share on other sites

I've hit a bit of a brick wall; apparently on Samsung devices the cell ID and physical cell ID are only available via an internal API that can only be called from the dialer.

 

However, I did figure out how to get the RSRP on most LTE devices, so that should now show up in the app at least. Hopefully when 4.2 hits the Samsung devices they'll implement the official APIs.

 

Edit: The last few releases were refusing to actually stop, and thus eating a lot of battery. If you downloaded in the last 48 hours or so, be sure to update to the latest apk.

Link to comment
Share on other sites

I've hit a bit of a brick wall; apparently on Samsung devices the cell ID and physical cell ID are only available via an internal API that can only be called from the dialer.

 

However, I did figure out how to get the RSRP on most LTE devices, so that should now show up in the app at least. Hopefully when 4.2 hits the Samsung devices they'll implement the official APIs.

 

The latest update does correctly show the LTE RSRP on my GS3. Thanks for all your effort.

 

Question: Is there a dialer code that allows you to see the Cell ID on the GS3? ##debug# will get me to "LTE Enginerring" (at least that's how Samsung spells it), but only the physical cell ID shows up there, and I'm having a hell of a time trying to sort through the values as I try to identify my local LTE cells, as the local offsets don't seem to be exactly 169. My understanding is that the Cell ID shows the cell in the first 5 or 6 hex digits, with the sector value in the last digit or 2. This would be much easier to track than the phys cell ID, but I can't find anywhere that it is reported in the GS3.

  • Like 1
Link to comment
Share on other sites

As far as I've heard, the iPhone 5 is the only device that shows both IDs on its debug screen. Both should be exposed by the CellIdentityLte API in Android 4.2, although that relies on the OEM's radio reporting the data.

Link to comment
Share on other sites

  • 1 month later...

Yesterday I updated my app to include an attempt at getting information from the API 17 functions as well.. if anyone wants to give it a try, the free version is "SignalCheck Lite" on Google Play. You don't need the paid version to see LTE cell info, just a device running Android 4.2 or newer.

 

lordsutch, how are your efforts panning out? I'm still running ICS on my EVO so I've never seen your app (or the LTE cell ID functions of my own app). I want to upgrade, but I prefer the Sense UI and haven't found a Jelly Bean version that doesn't feel like a downgrade.

 

I understand that LTE is the newest widespread cellular technology, but I still find it odd (and a bit frustrating) that this information is so difficult to get our hands on.. although the API 17 code is a big step in the right direction, even if it isn't widely supported yet.

 

-Mike

Link to comment
Share on other sites

For the EVO, getting the Hex Cell ID requires a call to the "HTC Telephony Manager" service. Here's a rough outline:

 

private Object mHTCManager;
/* somewhere in onCreate() */
mHTCManager = getSystemService("htctelephony");
/* when you want to get the cell ID */
String cellID = "";
if(mHTCManager != null) {
Method m = null;
try {
 m = mHTCManager.getClass().getMethod("getSectorId", int.class);
 cellID = (String) m.invoke(mHTCManager, new Object[] {Integer.valueOf(1)} );
} catch (NoSuchMethodException e) {
 // TODO Auto-generated catch block
 e.printStackTrace();
} catch (IllegalArgumentException e) {
 // TODO Auto-generated catch block
 e.printStackTrace();
} catch (IllegalAccessException e) {
 // TODO Auto-generated catch block
 e.printStackTrace();
} catch (InvocationTargetException e) {
 // TODO Auto-generated catch block
 e.printStackTrace();
}
}

 

Unlike CellIdentityLte.getCi(), this will give you a String with the hexadecimal cell ID, not an integer. So you will probably want to do use Integer.valueOf(cellID, 16) to convert to an integer (or convert getCi()'s output to hex using String.format or something) in mixed code.

 

Full working code in GitHub at https://github.com/lordsutch/Signal-Strength-Detector/blob/master/src/com/lordsutch/android/signaldetector/SignalDetectorService.java

  • Like 1
Link to comment
Share on other sites

  • 2 months later...

After watching the radio log on my EVO LTE today, it appears the Qualcomm RIL used by AOSP reports the LTE Cell Identity as if it was the UMTS CID, and it reports something else (probably the TAC/tracking area code; looking at pastebins it's too big to be the PCI/physical cell ID, alas) as if it was the UMTS LAC.

 

The bad news is that the internal telephony code in AOSP doesn't report this info via any exposed APIs. The good news is that it shouldn't be hard to hack the reporting into the existing code, although getting it accepted into CM may be a challenge.

Link to comment
Share on other sites

  • 1 year later...

I used to work for Ericsson / Ascom TEMS, devloping TEMS Pocket among other things, and my main problem with the Android cell info API:s is that there is no way to ask for the frequency (ARFCN/UARFCN/EARFCN) of cells.

 

Does anyone know why such an obvious value (to me at least) has been omitted from the API?

Link to comment
Share on other sites

I used to work for Ericsson / Ascom TEMS, devloping TEMS Pocket among other things, and my main problem with the Android cell info API:s is that there is no way to ask for the frequency (ARFCN/UARFCN/EARFCN) of cells.

 

Does anyone know why such an obvious value (to me at least) has been omitted from the API?

As a developer, it drives me nuts as well. Would love to get a standard method to obtain frequency/band information, but it just doesn't exist. There is a suggestion in to have it added, but it's never been addressed. Seems like it should be a simple addition and it would be very useful for the apps a few of us on here have created.

 

-Mike

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • large.unreadcontent.png.6ef00db54e758d06

  • gallery_1_23_9202.png

  • Posts

    • So, in summary, here are the options I tested: T-Mobile intl roaming - LTE on SoftBank, routes back to the US (~220ms to 4.2.2.4) IIJ physical SIM - LTE on NTT, local routing Airalo - LTE on SoftBank and KDDI (seems to prefer SoftBank), routed through Singapore (SingTel) Ubigi - 5G on NTT, routed through Singapore (Transatel) US Mobile East Asia roaming - 5G on SoftBank, routed through Singapore (Club SIM) Saily - 5G on NTT, routed through Hong Kong (Truphone)...seems to be poorer routing my1010 - LTE on SoftBank and KDDI (seems to prefer KDDI), routed through Taiwan (Chunghwa Telecom) I wouldn't buy up on the T-Mobile international roaming, but it's a solid fallback. If you have the US Mobile roaming eSIM that's a great option. Otherwise Ubigi, Airalo, or my1010 are all solid options, so get whatever's cheapest. I wouldn't bother trying to find a physical SIM from IIJ...the Japanese IP is nice but there's enough WiFi that you can get a Japanese IP enough for whatever you need, and eSIM flexibility is great (IIJ as eSIM but seems a bit more involved to get it to work).
    • So, the rural part of the journey still has cell service for nearly all the way, usually on B18/19/8 (depending on whether we're talking about KDDI/NTT/SoftBank). I think I saw a bit of B28 and even n28 early on in the trip, though that faded out after a bit. Once we got to where we were going though, KDDI had enough B41 to pull 150+ Mbps, while NTT and SoftBank had B1/B3 IIRC. Cell service was likewise generally fine from Kawaguchiko Station to Tokyo on the express bus to Shinjuku Station, though there were some cases where only low-band LTE was available and capacity seemed to struggle. I also figured out what I was seeing with SoftBank on 40 MHz vs. 100 MHz n77: the 40 MHz blocks are actually inside the n78 band class, but SoftBank advertises them as n77, probably to facilitate NR CA. My phone likely preferred the 40 MHz slices as they're *much* lower-frequency, ~3.4 GHz rather than ~3.9, though of course I did see the 100 MHz slice being used rather often. By contrast, when I got NR on NTT it was either n28 10x10 or, more often, 100 MHz n78. As usual, EMEA bands on my S24 don't CA, so any data speeds I saw were the result of either one LTE carrier or one LTE carrier plus one NR carrier...except for B41 LTE. KDDI seems to have more B41 bandwidth live at this point, so my1010 or Airalo works well for this, and honestly while SoftBank and NTT 5G (in descending order of availability) have 5G that's readily available it may be diminishing returns, particularly given that I still don't know how to, as someone not from Hong Kong, get an eSIM that runs on SoftBank 5G that isn't the USM "comes for free with the unlimited premium package" roaming eSIM (NTT is easy enough thanks to Ubigi). In other news, I was able to borrow someone's Rakuten eSIM and...got LTE with it. 40 Mbps down, 20 Mbps up, 40ms latency to Tokyo while in Tokyo...which isn't any worse than the Japan-based physical SIMs I had used earlier. But not getting n77 or n257 was disappointing, though I had to test the eSIM from one spot rather than bouncing around the city to find somewhere with better reception. It's currently impossible to get a SIM as a foreigner that runs on Rakuten, so that was the best I could do. Also, I know my phone doesn't have all the LTE and 5G bands needed to take full advantage of Japanese networks. My S24 is missing: B21 (1500 MHz) - NTT B11 (1500 MHz) - KDDI, SoftBank B42 (3500 MHz) - NTT, KDDI, SoftBank n79 (4900 MHz) - NTT Of the above, B42/n79 are available on the latest iPhones, though you lose n257, and I'm guessing you're not going to find B11/B21 on a phone sold outside Japan.
    • T-Mobile acquiring SoniqWave's 2.5 GHz spectrum  Another spectrum speculator down! T-Mobile is acquiring all of their licenses and their leases. Details are lacking but it looks like T-Mobile might be giving them 3.45GHz in exchange in some of the markets where they're acquiring BRS/EBS to sweeten the deal and stay below the spectrum screen. Hopefully NextWave is at the negotiating table with T-Mobile so NYC can finally get access to the full BRS/EBS band as well. 
    • Maybe. The taller buildings on one side of the street all have Fios access and the NYCHA buildings are surrounded by Verizon macros that have mmWave. I don’t think this site will add much coverage. It’d be better off inside the complex itself.
    • Looks like a great place for for FWA. Many apartment dwellers only have one overpriced choice.
  • Recently Browsing

    • No registered users viewing this page.
×
×
  • Create New...