Jump to content
mikejeep

SignalCheck Beta Crew Forum

Recommended Posts

The refinement of the provider in the logs has been removed.  I do not use it in my log analysis, but those reading their logs likely do.  It previously broke out Sprint B25, Sprint B252, Sprint B26, Sprint B41, Sprint B412,Sprint B413.  Also Clearwire iirc.  Now it just says Sprint.

 

Yep, that was a bug I discovered last night. One of the primary reasons I pushed out a new update early this morning.. glad to see your later post showing it was resolved!

 

 

Possible new bug in the beta, probably from fixing my last bug.  I spotted new sectors of existing sites this morning and my log did not carry the labels over to those new sectors. 

 

Doh! Let me know. I will try to do some testing also. If others could keep an eye on this, I'd appreciate it.

 

 

SCP is now blowing up on my Photon 4G (wimax) smartphone (previously worked without beta).  Likely not worth effort to debug.  I just use it for CDMA logs (which is all it is capable of). You might want to raise OS level rather than support devices this old.  Sent report.

 

My hope is that this can be the final release for pre-4.1 devices; there are many small bugfixes and a lot of nice changes, nothing that should preclude those devices from working. Where did you send a report? I don't see anything in my e-mail, diagnostics inbox, or Google reports.

 

-Mike

  • Like 1

Share this post


Link to post
Share on other sites

Yep, that was a bug I discovered last night. One of the primary reasons I pushed out a new update early this morning.. glad to see your later post showing it was resolved!

 

 

 

Doh! Let me know. I will try to do some testing also. If others could keep an eye on this, I'd appreciate it.

 

 

 

My hope is that this can be the final release for pre-4.1 devices; there are many small bugfixes and a lot of nice changes, nothing that should preclude those devices from working. Where did you send a report? I don't see anything in my e-mail, diagnostics inbox, or Google reports.

 

-Mike

 

Reinstalled, ran, and just send another.  Thanks!

Share this post


Link to post
Share on other sites

Reinstalled, ran, and just send another.  Thanks!

 

Found your reports.. ironically it's the crash monitoring library that's crashing, not the app itself. What exact version of Android are you running on that? Google reported "2.3.3 - 2.3.7".

 

-Mike

Share this post


Link to post
Share on other sites

Found your reports.. ironically it's the crash monitoring library that's crashing, not the app itself. What exact version of Android are you running on that? Google reported "2.3.3 - 2.3.7".

 

-Mike

2.3.5

 

Sent from my LG-LS980 using Tapatalk

  • Like 1

Share this post


Link to post
Share on other sites

 

Doh! Let me know. I will try to do some testing also. If others could keep an eye on this, I'd appreciate it.

 

Was just poking at my Verizon log file (took it to work today) and it's doing the same thing, two new sectors identified today, both have no notes even though other sectors on the same site have notes.

 

- Trip

  • Like 1

Share this post


Link to post
Share on other sites

Airave not reported on CDMA side.  Airaves have a unique NID of 500 to 502.  The BID sometimes get reported as a network site, but that requires local diligence to detect.

 

I haven't tackled that yet but it's coming shortly. I know that was the NID range for Airave 2.5; just curious, is it the same for the 3.0?

 

 

SCP is now blowing up on my Photon 4G (wimax) smartphone (previously worked without beta).  Likely not worth effort to debug.  I just use it for CDMA logs (which is all it is capable of). You might want to raise OS level rather than support devices this old.  Sent report.

 

I believe this has been fixed, when the next update comes out please try it on your Photon!

 

 

Was just poking at my Verizon log file (took it to work today) and it's doing the same thing, two new sectors identified today, both have no notes even though other sectors on the same site have notes.

 

Yeah I was able to reproduce it myself also. I knew that fix was too easy.. hopefully tonight I can get that tackled. No promises on 3 days of app updates in a row, but who knows..

 

-Mike

  • Like 2

Share this post


Link to post
Share on other sites

Well it happened.. another update just pushed out, 3 days in a row! Still needs some polish, but the latest bugs are squashed.. and there's a couple new goodies..

 

-Mike

  • Like 8

Share this post


Link to post
Share on other sites

Well it happened.. another update just pushed out, 3 days in a row! Still needs some polish, but the latest bugs are squashed.. and there's a couple new goodies..

 

-Mike

Yes!!! Native earfcns! This will make logging and IDing things so much better! 1000 thanks!

 

Sent from my Pixel XL using Tapatalk

  • Like 5

Share this post


Link to post
Share on other sites

As a side effect of targeting the new API level, it looks like the database is automatically backed up and restored when you switch devices! The backup is the right size anyway for the national db.Screenshot_20170609-010115.png

 

Sent from my Pixel XL using Tapatalk

  • Like 6

Share this post


Link to post
Share on other sites

Thanks for update, Samsung devices not showing earfcn so far. 3 devices on 7.0 and one on 6.0 still.

 

 

Sent from my iPhone using Tapatalk

  • Like 2

Share this post


Link to post
Share on other sites

Well it happened.. another update just pushed out, 3 days in a row! Still needs some polish, but the latest bugs are squashed.. and there's a couple new goodies..

 

-Mike

 

For some reason, the forum only allows me to click the Like button once, even though I want to hit it several dozen times.  I love the availability of EARFCN on my Sprint phone for the first time. 

 

I'm going to look into upgrading my AT&T HTC M9 to Android 7, and look forward to my Moto G4 Plays (Verizon and US Cellular) getting the update as well.  My Moto G3 (T-Mobile PCS/AWS) and BLU R1 HD (T-Mobile 700) are not receiving the update, but I can continue using the root method until I upgrade them or find a custom ROM that does the job.  Although they all (except the BLU) use the root method right now, I know the API method would be faster and more reliable.

 

The ability to get the EARFCN in this way is fantastic, because it will allow you to better identify bands, including whether a 10x10 on Sprint is second carrier or not.  If I may make a suggestion, though; if someone is using the root method, there will be a delay in showing the EARFCN.  If the EARFCN is in the database, however, it could be worthwhile to fall back on that for band ID until the EARFCN becomes available.  The final fallback would be the sector ID like you do currently.

 

- Trip

  • Like 5

Share this post


Link to post
Share on other sites

Thanks for update, Samsung devices not showing earfcn so far. 3 devices on 7.0 and one on 6.0 still.

 

Sent from my iPhone using Tapatalk

They don't show up in other apps either. So it is a Samsung issue. Even though they would be great to have.
  • Like 3

Share this post


Link to post
Share on other sites

  • Photon 4G with Android 2.35 works.
  • EARFCN displays correctly on non-rooted LG V20 using API method with very latest firmware LS997ZV7: "UL/DL EARFCN" on band 41.
  • EARFCN displays correctly on rooted LG G2s using modem method: "UL EARFCN" and line below: "DL EARFCN" on band 41.  I like a difference between the two so you will know which one it is using on a rooted Android 7.0 device (during beta, until we know which way gives the most earfcn.  Perhaps it is coded for API first then modem?  Then the modem would always backup the API on a rooted device if the API misses it).  They display the same for B25 & B26.
Edited by dkyeager
  • Like 1

Share this post


Link to post
Share on other sites

Any way to identify USCC LTE Bands now via EARFCN, so the band can be populated in all the right places? I miss band identification when I'm on USCC.

 

BTW, I love seeing EARFCN on a Nexus 6 for the first time! Awesome!

 

74c4abf23883908b4e500440331da7ee.jpg

 

Sent from my Nexus 6 using Tapatalk

  • Like 1

Share this post


Link to post
Share on other sites

So it is a Samsung issue. Even though they would be great to have.

Which still makes it a bit of an issue with how it is implemented in this latest beta. I see the option to not display the ul earfcn in the display settings, but no such option for the dl. It isn't optimal to have something enabled by default that you can't get rid of giving inaccurate information on roughly half of the devices the app is installed on.

Share this post


Link to post
Share on other sites

Download EARFCNs that indicate B25 10x10 (for starters):

 

8140, 8390, 8640.

  • Like 1

Share this post


Link to post
Share on other sites

Which still makes it a bit of an issue with how it is implemented in this latest beta. I see the option to not display the ul earfcn in the display settings, but no such option for the dl. It isn't optimal to have something enabled by default that you can't get rid of giving inaccurate information on roughly half of the devices the app is installed on.

Samsung users just need to tell Samsung that they want this EARFCN API supported so they don't have to root. Samsung does not like rooting so the choice should be obvious to them once explained in great enough numbers.

Share this post


Link to post
Share on other sites

Some USC download EARFCNs:

2425, 2585 - Band 5 (850)

5090 - Band 12 (700)

Share this post


Link to post
Share on other sites

Some USC download EARFCNs:

2425, 2585 - Band 5 (850)

5090 - Band 12 (700)

 

I think DL EARFCN corresponds directly to band across a range of values, so it's a matter of simply checking where in the range the EARFCN falls and mapping that to a band number.  (For example, Band 1 is 0-599, then Band 2 is 600-1199, etc.)  It shouldn't need individual EARFCN values mapped to numbers like that.

 

Where it gets trickier is using it to try to identify bandwidths.  For that we'll probably need to work out manual mappings.

 

- Trip

  • Like 2

Share this post


Link to post
Share on other sites

As a side effect of targeting the new API level, it looks like the database is automatically backed up and restored when you switch devices! The backup is the right size anyway for the national db.

 

This was a huge reason I wanted to target a newer API.. it's a fantastic feature for an app like this. Will be much easier to use multiple devices.

 

 

Thanks for update, Samsung devices not showing earfcn so far. 3 devices on 7.0 and one on 6.0 still.

 

Samsung devices being difficult?! No way, what a surprise. Ugh! As someone else already mentioned, that is on them. It's only a 7.0+ feature so it is fairly new.

 

 

Which still makes it a bit of an issue with how it is implemented in this latest beta. I see the option to not display the ul earfcn in the display settings, but no such option for the dl. It isn't optimal to have something enabled by default that you can't get rid of giving inaccurate information on roughly half of the devices the app is installed on.

 

Well that's why we are beta testing. It shouldn't be showing you any EARFCN information if it's invalid.. what are you seeing? I don't have a Samsung on Android 7 to test myself.

 

-Mike

Share this post


Link to post
Share on other sites

Well that's why we are beta testing. It shouldn't be showing you any EARFCN information if it's invalid.. what are you seeing? I don't have a Samsung on Android 7 to test myself.

 

-Mike

scp_zpsllvyhhhv.jpg

It will rotate between 18015/14/13 on the ul and 15/14/13 on the dl. It is calculating the frequency correctly for the displayed EARFCN, but the displayed EARFCNs are inaccurate due to Samsung's choices. I sent you diagnostic data as well.

Share this post


Link to post
Share on other sites

Samsung users just need to tell Samsung that they want this EARFCN API supported so they don't have to root. Samsung does not like rooting so the choice should be obvious to them once explained in great enough numbers.

Good luck explaining to the average Samsung customer service rep what an EARFCN is much less getting it escalated to the appropriate person or team. I personally have no problem going to the engineering screen if I need the data. It sounds like Mike was expecting invalid EARFCNs not to show up. If that is the case I'll help him try and figure out what is going on with 7.0 on a Samsung device. If it can't be fixed an option to not display EARFCNs would suffice.

  • Like 1

Share this post


Link to post
Share on other sites

I'm going to look into upgrading my AT&T HTC M9 to Android 7, and look forward to my Moto G4 Plays (Verizon and US Cellular) getting the update as well.  My Moto G3 (T-Mobile PCS/AWS) and BLU R1 HD (T-Mobile 700) are not receiving the update, but I can continue using the root method until I upgrade them or find a custom ROM that does the job.  Although they all (except the BLU) use the root method right now, I know the API method would be faster and more reliable.

 

The ability to get the EARFCN in this way is fantastic, because it will allow you to better identify bands, including whether a 10x10 on Sprint is second carrier or not.  If I may make a suggestion, though; if someone is using the root method, there will be a delay in showing the EARFCN.  If the EARFCN is in the database, however, it could be worthwhile to fall back on that for band ID until the EARFCN becomes available.  The final fallback would be the sector ID like you do currently.

 

The API method should be noticeably faster (those of you using the root method have undoubtedly noticed that you have to wait for the first screen update after you connect to a new site to see EARFCNs) and consume less resources. You do need Android 7.0+ (and the OEM has to have it set up properly of course). I am still working on a warning notice if your device appears to be getting EARFCNs from the native API but the root method is still enabled. There is no adverse affect in the app other than wasting unnecessary system resources.

 

I like your fallback idea, it just might take some time to implement. I am hesitant to rely on pulling band info out of the database because if a site's configuration is changed for whatever reason, that could throw things off. SCP minimizes the number of reads and writes to the database so a little more complicated than one might expect.

 

 

EARFCN displays correctly on rooted LG G2s using modem method: "UL EARFCN" and line below: "DL EARFCN" on band 41.  I like a difference between the two so you will know which one it is using on a rooted Android 7.0 device (during beta, until we know which way gives the most earfcn.  Perhaps it is coded for API first then modem?  Then the modem would always backup the API on a rooted device if the API misses it).  They display the same for B25 & B26.

 

Right now, the app tries the old-school HTC EARFCN routines first, then the root/modem method, then the new native API 24 routine. If the data is deemed to be valid, each subsequent routine overwrites anything that had been already obtained, so even if all 3 methods work on a device, the user will only see the results of the native method (theoretically the most accurate). If the root/modem method works, but the native method doesn't, the modem data is what will pass through.

 

 

Any way to identify USCC LTE Bands now via EARFCN, so the band can be populated in all the right places? I miss band identification when I'm on USCC.

 

That is my goal.. chasing down GCI patterns might be fun for some people, but I'm tired of it! I want to iron out all of the kinks in the 3 steps noted above and make sure everyone is getting valid EARFCN data before taking the next step. I really want to make sure that source data is accurate before going too far with it. It's a pretty basic implementation right now and I'm sure it will need some tweaks.

 

-Mike

  • Like 4

Share this post


Link to post
Share on other sites

Regarding Samsung, they specifically removed the earfcn API from their builds of 7.0. No clue why, but it's just not there and consequently no apps work with it. I actually forgot what a large segment​ of users that leaves out... Stupid Samsung. Maybe they'll see the light with 8.0?

 

Sent from my Pixel XL using Tapatalk

  • Like 1

Share this post


Link to post
Share on other sites

This was a huge reason I wanted to target a newer API.. it's a fantastic feature for an app like this. Will be much easier to use multiple devices.

 

-Mike

If only my HTC 10 was still working so I'd have a backup newer than 8/13/16

 

 

Sent from my iPhone using Tapatalk

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×