Jump to content
mikejeep

SignalCheck Beta Crew Forum

Recommended Posts

Interesting. Did you notice if the RSRP and GCI values were updating as you moved around? I'm wondering if it's actually showing 5G info or just still showing the last LTE info it had.
I was driving, so I barely had time to glance down and hit go once in a while. I wasn't paying attention to SCP when I stopped and ran a stationary test. I'll check again this weekend.
  • Like 1

Share this post


Link to post
Share on other sites
Do you need beta testers for 5G devices in launched markets? 5G shows as 2.5 LTE. I tried searching the thread, but it's quite long.


Send me a PM with your Google account email. Please send a diagnostic report when connected to 5G too. Disappointed to see it doesn't work in your screenshot, I thought I had the basics in there to at least show it as 5G up top.. hopefully I'm close!

-Mike
  • Like 1

Share this post


Link to post
Share on other sites



5G shows as 2.5 LTE.






I thought I had the basics in there to at least show it as 5G up top.. hopefully I'm close!


I'm guessing that it's using 5G as a secondary/tertiary carrier, and that LTE is PCC (so it can use it for upload).

Sent from my Pixel 3 XL using Tapatalk

  • Like 2

Share this post


Link to post
Share on other sites
4 hours ago, ingenium said:


I'm guessing that it's using 5G as a secondary/tertiary carrier, and that LTE is PCC (so it can use it for upload).

Sent from my Pixel 3 XL using Tapatalk
 

 

 

 

 

 

Agree. So SCP is half right.

  • Like 1

Share this post


Link to post
Share on other sites
4 hours ago, mikejeep said:

 


Send me a PM with your Google account email. Please send a diagnostic report when connected to 5G too. Disappointed to see it doesn't work in your screenshot, I thought I had the basics in there to at least show it as 5G up top.. hopefully I'm close!

-Mike

 

5G is an SCC, not the PCC. Unless you're able to pull Carrier Aggregation data, it may be tricky to display 5G until the ENDC config allows for NR PCCs. 

  • Like 1

Share this post


Link to post
Share on other sites


Send me a PM with your Google account email. Please send a diagnostic report when connected to 5G too. Disappointed to see it doesn't work in your screenshot, I thought I had the basics in there to at least show it as 5G up top.. hopefully I'm close!

-Mike
Did you get my PM?
  • Like 1

Share this post


Link to post
Share on other sites

Three things:

1)  I didn't even realize the TA values were off until I saw it in the change log.  I've now turned the setting on for ALL of my devices and the distances now look more reasonable.  Why couldn't I tell they were off?  Because I have a hard time eyeballing distances like that in feet.  Would it be possible to have a switch to convert those distances to miles instead?

2)  I've got an interesting new issue.  I now regularly see CDMA entries that have BID values of 0, all with garbage data, and my log now has a number of them.  I'm not sure what change triggered this, but I don't like it.  Much like how empty GCIs shouldn't be logged, can the same option be made for logging CDMA with BID values of 0?  (Interesting note, when I observe them on the device that way, I frequently see BSL data indicating it belongs to a particular site, despite the BID value being 0.)

3)  Not really a bug, but I connected to Massive MIMO site 031F4C and 031F4E at Wellington yesterday, but rather than needing a note added, those GCIs were identified as being related to the Westlawn site.  The reason for this is that 031F4C and 031F4E are off by 0x1450 from two of the the Mini Macros at the Westlawn site (030AFC and 030AFE).  As more Massive MIMO sites light up, and a second wave seems to be lighting up right now, I expect to see more of these cases.

- Trip

  • Thanks 1

Share this post


Link to post
Share on other sites
43 minutes ago, Trip said:

1)  I didn't even realize the TA values were off until I saw it in the change log.  I've now turned the setting on for ALL of my devices and the distances now look more reasonable.  Why couldn't I tell they were off?  Because I have a hard time eyeballing distances like that in feet.  Would it be possible to have a switch to convert those distances to miles instead?

I think a lot of people might not be realizing the distances are off.. I swear mine were previously correct, but since it was brought to my attention I'm starting to second guess myself as well. I'm going to keep watching responses about this to see if it turns out that everyone actually needs their values corrected. I also considered using miles, but the general standard for TA seemed to be meters or feet. I will make some changes to that, I think I'd prefer miles as well -- especially since with the 2x correction factor applied, you're losing some accuracy anyway. You'll never see an odd-numbered TA value with the correction option enabled.

 

43 minutes ago, Trip said:

2)  I've got an interesting new issue.  I now regularly see CDMA entries that have BID values of 0, all with garbage data, and my log now has a number of them.  I'm not sure what change triggered this, but I don't like it.  Much like how empty GCIs shouldn't be logged, can the same option be made for logging CDMA with BID values of 0?  (Interesting note, when I observe them on the device that way, I frequently see BSL data indicating it belongs to a particular site, despite the BID value being 0.)

Aha.. I thought there was a reason I was discarding BID 0 -- thank you for reminding me. The reason this changed in the most recent version is because the Airave 4 uses BID 0. I'll adjust it to continue discarding BID 0 except if it appears to be an Airave.

 

43 minutes ago, Trip said:

3)  Not really a bug, but I connected to Massive MIMO site 031F4C and 031F4E at Wellington yesterday, but rather than needing a note added, those GCIs were identified as being related to the Westlawn site.  The reason for this is that 031F4C and 031F4E are off by 0x1450 from two of the the Mini Macros at the Westlawn site (030AFC and 030AFE).  As more Massive MIMO sites light up, and a second wave seems to be lighting up right now, I expect to see more of these cases.

Ugh, these complications were what I was overly concerned with a few years ago when I first started linking offset GCIs. Any suggestions for how to address this?

-Mike

Share this post


Link to post
Share on other sites
3 minutes ago, mikejeep said:

I think a lot of people might not be realizing the distances are off.. I swear mine were previously correct, but since it was brought to my attention I'm starting to second guess myself as well. I'm going to keep watching responses about this to see if it turns out that everyone actually needs their values corrected. I also considered using miles, but the general standard for TA seemed to be meters or feet. I will make some changes to that, I think I'd prefer miles as well -- especially since with the 2x correction factor applied, you're losing some accuracy anyway. You'll never see an odd-numbered TA value with the correction option enabled.

I think it's harder to spot in urban areas.  I was looking for it when I was out of town over the weekend and in the rural areas, when I know the cell tower is 10 miles away, the feet number is more obviously incorrect.  Here in the city, where it's "close" but exactly how close never really enters my mind, it was easy to ignore.

5 minutes ago, mikejeep said:

Aha.. I thought there was a reason I was discarding BID 0 -- thank you for reminding me. The reason this changed in the most recent version is because the Airave 4 uses BID 0. I'll adjust it to continue discarding BID 0 except if it appears to be an Airave.

Thanks. 

5 minutes ago, mikejeep said:

Ugh, these complications were what I was overly concerned with a few years ago when I first started linking offset GCIs. Any suggestions for how to address this?

Is the link universal?  Like, does every GCI automatically jump to the one above?  So would a 30001 link to 31451, and then if a 328A1 were to appear, would that also have the same note since 31451 has it? 

- Trip

Share this post


Link to post
Share on other sites

Pixel 3a XL on Q beta 4 has been great. So nice having the bandwidth and CA values appearing on SCP. So far everything it has been reporting has checked out too. Smooth sailing. 👍

  • Like 3

Share this post


Link to post
Share on other sites
On 6/10/2019 at 1:58 PM, Trip said:

Is the link universal?  Like, does every GCI automatically jump to the one above?  So would a 30001 link to 31451, and then if a 328A1 were to appear, would that also have the same note since 31451 has it?

Oops, never replied to this.. sorry about that. If a site is identified as B25 or B26, SCP checks for a GCI 0x1450 "higher" when querying or saving site notes. If a site is identified as B41, it checks for a GCI 0x1450 "lower".

If I'm understanding everything properly, yes your scenario would be true -- but if 30001 and 328A1 were discovered first, they would have independent notes.. once 31451 was logged, that would cause it to pull one of the other notes (depending on the band it was on). Depending on which site was hit next would determine which note got pulled. It could get a bit sloppy if this starts happening.. 😕

-Mike

Share this post


Link to post
Share on other sites

So 31451 checks if there's a 30001, but doesn't check whether the 30001 in the log is from Band 25/26 or Band 41.  Maybe that would be a good way to separate it.  If it looks up the lower site but it's not Band 25/26 (or is Band 41), assume it's not connected?

- Trip

Share this post


Link to post
Share on other sites
On 6/22/2019 at 6:37 AM, Trip said:

So 31451 checks if there's a 30001, but doesn't check whether the 30001 in the log is from Band 25/26 or Band 41.  Maybe that would be a good way to separate it.  If it looks up the lower site but it's not Band 25/26 (or is Band 41), assume it's not connected?

I think that will work, I'll give that approach a try.

New beta rolling out within the hour, mostly bugfixes. No changes to the Sprint LTE offset issue mentioned above, haven't started working on that yet. Trip, it should hopefully resolve your CDMA BID 0 log entries moving forward, sorry it took awhile for that. 

  • Changed imperial LTE TA distance units to display miles instead of feet.
  • Improved in-app purchase functionality.
  • Resolved force closes related to the Location Service on some Android 8+ devices.
  • Resolved internal exception thrown on installation(???).
  • Resolved issue with invalid CDMA sites being displayed/logged.

-Mike

  • Like 5

Share this post


Link to post
Share on other sites

Was my diagnostic report helpful at all? I can't remember where I was when I sent it. If it would be helpful, I can drive to a 5G area and send one from there. Just let me know what would be the most helpful.

Share this post


Link to post
Share on other sites
On 7/3/2019 at 8:55 PM, Grabber5.0 said:

Was my diagnostic report helpful at all? I can't remember where I was when I sent it. If it would be helpful, I can drive to a 5G area and send one from there. Just let me know what would be the most helpful.

You included the location on the report (119@Blackbob). I wouldn't say it was unhelpful, but it did not contain any 5G information -- however, I have a hunch as to why. Android did not include any 5G methods for developers prior to Android Q; I am still compiling with the Android P APIs, since Q is still in beta. I hope to get a public app update out within the next day or two, and then I'll release a new beta built with the Q APIs to start testing that. Hopefully that starts giving me some data. Keep an eye on the changelog, if you see a mention of improved Q compatibility, try sending me another diagnostic report while on 5G.

Thanks!
-Mike

  • Like 2

Share this post


Link to post
Share on other sites

New SCP beta 4.54b rolling out now.. minor bugfixes behind the scenes, primarily this is to align with the public app update also going out today. Goal of the next round of testing will be to add some features for Android Q including 5G support.

Thanks for all of your support!

-Mike

  • Like 4

Share this post


Link to post
Share on other sites

Hopefully LG won't take two years to push Q to the V50, so I can actually get you some 5G data.

  • Like 1

Share this post


Link to post
Share on other sites

Hey Mike. Random thought. It has probably already come up before...

But would it be possible to add some optional left padding to the information displayed?  When I had a S10 I ran into glare issues with the stuff on the far left because of the curved display. Also now on my Pixel 3a XL I have a screen protector that distorts the edges of the screen a bit too. 

Just wondering. A rather small thing in the grand scheme of things but thought I'd ask since it *might* be a simple addition. 

  • Like 2

Share this post


Link to post
Share on other sites
21 hours ago, uecker87 said:

Hey Mike. Random thought. It has probably already come up before...

But would it be possible to add some optional left padding to the information displayed?  When I had a S10 I ran into glare issues with the stuff on the far left because of the curved display. Also now on my Pixel 3a XL I have a screen protector that distorts the edges of the screen a bit too. 

Just wondering. A rather small thing in the grand scheme of things but thought I'd ask since it *might* be a simple addition. 

Nobody has suggested it before, but it doesn't sound too crazy. I will work on creating an option to add padding around both sides of the main screen. Thanks for the idea!

-Mike

  • Like 3

Share this post


Link to post
Share on other sites
On 6/10/2019 at 12:52 PM, Trip said:

Three things:

...

3)  Not really a bug, but I connected to Massive MIMO site 031F4C and 031F4E at Wellington yesterday, but rather than needing a note added, those GCIs were identified as being related to the Westlawn site.  The reason for this is that 031F4C and 031F4E are off by 0x1450 from two of the the Mini Macros at the Westlawn site (030AFC and 030AFE).  As more Massive MIMO sites light up, and a second wave seems to be lighting up right now, I expect to see more of these cases.

- Trip

I've ran into this issue several times in my area. It looks like the Nokia 8T8Rs were the only setups to use the +1450 offset around here. The Nokia Mini Macs, Ericsson B41 8T8R, and Ericsson M-MIMO sites all use different GCIs. I've ran into several cases recently of a site pulling the wrong note for B41, and also the reverse where a previously logged B25 site pulls an incorrect note from a B41 site I logged. A lot of the B41 GCIs in Louisville are pulling notes from the Evansville IN, Owensboro KY areas. When I changed the site note for the B41 site it was also changing the notes for those B25 GCIs. Made for an interesting trip when I was out in Evansville/Owensboro for work last week. Would it be possible to put a switch in the app to turn that feature off? 

Also, I've noticed a difference in TA values at roughly the same distance while on B41 compared to B25/B26. I'm also seeing odd number TA values on B41, which i didn't think was possible with the correction factor applied. I can provide more examples of each scenario if needed. I haven't submitted a diagnostic report yet but can if you think it will be helpful.

jCWRQEfl.png

Share this post


Link to post
Share on other sites
On 8/29/2019 at 11:45 PM, mdob07 said:

I've ran into this issue several times in my area. It looks like the Nokia 8T8Rs were the only setups to use the +1450 offset around here. The Nokia Mini Macs, Ericsson B41 8T8R, and Ericsson M-MIMO sites all use different GCIs. I've ran into several cases recently of a site pulling the wrong note for B41, and also the reverse where a previously logged B25 site pulls an incorrect note from a B41 site I logged. A lot of the B41 GCIs in Louisville are pulling notes from the Evansville IN, Owensboro KY areas. When I changed the site note for the B41 site it was also changing the notes for those B25 GCIs. Made for an interesting trip when I was out in Evansville/Owensboro for work last week. Would it be possible to put a switch in the app to turn that feature off? 

I replied in the main SignalCheck thread, but wanted to reply in both places so others can be aware -- I am working on an option for users to disable the offset. It's starting to get ugly behind the scenes with all these caveats, but can't really do much about it. I'd like to ultimately allow users to use filters or manual offsets to keep things up to date, but that opens up a lot of other issues.

 

On 8/29/2019 at 11:45 PM, mdob07 said:

Also, I've noticed a difference in TA values at roughly the same distance while on B41 compared to B25/B26. I'm also seeing odd number TA values on B41, which i didn't think was possible with the correction factor applied. I can provide more examples of each scenario if needed. I haven't submitted a diagnostic report yet but can if you think it will be helpful.

The information I had to this point was that B41 didn't need a correction, so it is not applied regardless of your setting -- my uneducated guess was that it had something to do with FDD vs TDD. More and more evidence seems to point to the need for a correction factor on all connections, regardless of device or band -- but I do have some users who are insisting it is more accurate without it.

The issue is going to be when the Android devs fix this bug, everyone will suddenly have wrong readings again.. but I'm not holding my breath anyway.

-Mike

  • Like 1

Share this post


Link to post
Share on other sites
5 hours ago, mikejeep said:

I replied in the main SignalCheck thread, but wanted to reply in both places so others can be aware -- I am working on an option for users to disable the offset. It's starting to get ugly behind the scenes with all these caveats, but can't really do much about it. I'd like to ultimately allow users to use filters or manual offsets to keep things up to date, but that opens up a lot of other issues.

 

The information I had to this point was that B41 didn't need a correction, so it is not applied regardless of your setting -- my uneducated guess was that it had something to do with FDD vs TDD. More and more evidence seems to point to the need for a correction factor on all connections, regardless of device or band -- but I do have some users who are insisting it is more accurate without it.

The issue is going to be when the Android devs fix this bug, everyone will suddenly have wrong readings again.. but I'm not holding my breath anyway.

-Mike

With CDMA SCP has site hints which allows four choices.  I urge you to go beyond disabling the offset and directly support the new sequential GCI sectors as an option, but instead of calling them b41 #2 etc, call them #B etc.  I would also display the sector (A, B, Γ) for its educational and practical value.  If this could be set as the default for some Sprint markets that would be even better.

Share this post


Link to post
Share on other sites

New beta finally rolling out right now on Google Play! No dramatic changes this time:

  • Added option to add padding to the left and right borders of the main screen.
  • Improved Android 10 compatibility.
  • Resolved force closes on Samsung Android 10 devices.
  • Resolved force closes related to exiting the app.

I know there are a lot of outstanding bugs and requests; I am doing my best to prioritize my efforts on what is having the biggest impact on the largest number of users, and also squeeze in as many "quick" fixes/improvements that I can along the way. I am not dead, SignalCheck is not dead, everything is good -- just takes me awhile to piece together enough free time to produce a finished product worthy of release, even to the Beta Crew. I appreciate all of your support!

-Mike

  • Like 6
  • Thanks 2

Share this post


Link to post
Share on other sites

While the padding on the left definitely works, the right side appears to remain the same, based on connected to LTE and the IP address.

Share this post


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

    • Nice! Yes. I have no idea why they chose to decommission that site. It would fill a massive dead spot were it still online. AT&T has a site in that park's parking lot (at roughly 47.6908142, -122.1973845) which provides stellar coverage in the area. 
    • SoftBank isn't willing to do anything with Sprint. Sprint will need a different buyer. I do agree with getting Dishes spectrum. They have Nationwide AWS at 20x20 and my area the have 10x10 600. Sent from my SM-G975U1 using Tapatalk
    • I do think that the merger will be approved but just in case, here's my thoughts on what should happen if it gets rejected in order of preferred outcome: 1. T-Mobile & Sprint merge their network operations into an independent company and they both become MVNOs. Dish is left out in the cold with their spectrum unused. FCC has egg in their face. Only way Dish gets their network deployed is if Amazon and/or cable cos invest in them. it could happen...the other possibility is that Dish sells their spectrum to Verizon/AT&T/T-mobile. Sprint does pretty good but they are no longer a price leader. Their pricing is rationalized and pretty close to what the other major carriers charge. 2. Sprint gets properly funded by Softbank. They buy Dish's 600Mhz/ AWS-3. They fill out their present network but do not expand beyond their current footprint. They charge for rural roaming and they price themselves rationally. They grow slowly. 3. Sprint gets acquired by a consortium of Amazon and cable cos. They use Sprint to promote their video offerings to millennials. The resulting company expands their network to provide a really solid network in the boondocks but fall short of Verizon/AT&T which is OK. They only expand where they can make money.  4. Sprint goes on without the financial support of Softbank and limps along. They shrink their network and become an urban based network. Some smaller markets and places where it does not make financial sense to have their network are dropped. They rationalize their prices and charge for roaming. Where they do offer service their network is really solid. 
    • Thanks.    I thought the same about the appeal, but knowing this crowd... they might.  
  • Recently Browsing

    No registered users viewing this page.

×
×
  • Create New...