Jump to content

SignalCheck Beta Crew Forum


mikejeep

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
Link to comment
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!

Link to comment
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

Link to comment
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
Link to comment
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
Link to comment
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
Link to comment
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
Link to comment
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
Link to comment
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
Link to comment
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
Link to comment
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
Link to comment
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
Link to comment
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.

Link to comment
Share on other sites

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

 

8140, 8390, 8640.

  • Like 1
Link to comment
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.

Link to comment
Share on other sites

Some USC download EARFCNs:

2425, 2585 - Band 5 (850)

5090 - Band 12 (700)

Link to comment
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
Link to comment
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

Link to comment
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.

Link to comment
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
Link to comment
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
Link to comment
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
Link to comment
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

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

  • Similar Content

  • Posts

    • Since this is kind of the general chat thread, I have to share this humorous story (at least it is to me): Since around February/March of this year, my S22U has been an absolute pain to charge. USB-C cables would immediately fall out and it progressively got worse and worse until it often took me a number of minutes to get the angle of the cable juuuussst right to get charging to occur at all (not exaggerating). The connection was so weak that even walking heavily could cause the cable to disconnect. I tried cleaning out the port with a stable, a paperclip, etc. Some dust/lint/dirt came out but the connection didn't improve one bit. Needless to say, this was a MONSTER headache and had me hating this phone. I just didn't have the finances right now for a replacement.  Which brings us to the night before last. I am angry as hell because I had spent five minutes trying to get this phone to charge and failed. I am looking in the port and I notice it doesn't look right. The walls look rough and, using a staple, the back and walls feel REALLY rough and very hard. I get some lint/dust out with the staple and it improves charging in the sense I can get it to charge but it doesn't remove any of the hard stuff. It's late and it's charging, so that's enough for now. I decide it's time to see if that hard stuff is part of the connector or not. More aggressive methods are needed! I work in a biochem lab and we have a lot of different sizes of disposable needles available. So, yesterday morning, while in the lab I grab a few different sizes of needles between 26AWG and 31 AWG. When I got home, I got to work and start probing the connector with the 26 AWG and 31 AWG needle. The stuff feels extremely hard, almost like it was part of the connector, but a bit does break off. Under examination of the bit, it's almost sandy with dust/lint embedded in it. It's not part of the connector but instead some sort of rock-hard crap! That's when I remember that I had done some rock hounding at the end of last year and in January. This involved lots of digging in very sandy/dusty soils; soils which bare more than a passing resemblance to the crap in the connector. We have our answer, this debris is basically compacted/cemented rock dust. Over time, moisture in the area combined with the compression from inserting the USB-C connector had turned it into cement. I start going nuts chiseling away at it with the 26 AWG needle. After about 5-10 minutes of constant chiseling and scraping with the 26AWG and 31AWG needles, I see the first signs of metal at the back of the connector. So it is metal around the outsides! Another 5 minutes of work and I have scraped away pretty much all of the crap in the connector. A few finishing passes with the 31AWG needle, a blast of compressed air, and it is time to see if this helped any. I plug my regular USB-C cable and holy crap it clicks into place; it hasn't done that since February! I pick up the phone and the cable has actually latched! The connector works pretty much like it did over a year ago, it's almost like having a brand new phone!
    • That's odd, they are usually almost lock step with TMO. I forgot to mention this also includes the September Security Update.
    • 417.55 MB September security update just downloaded here for S24+ unlocked   Edit:  after Sept security update install, checked and found a 13MB GP System update as well.  Still showing August 1st there however. 
    • T-Mobile is selling the rest of the 3.45GHz spectrum to Columbia Capital.  
    • Still nothing for my AT&T and Visible phones.
  • Recently Browsing

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