Jump to content

SignalCheck Beta Crew Forum


mikejeep

Recommended Posts

I have the same error on my Pixel 7 Pro.  When I first go to Upload Web Data, it gives me an error and it takes me manually sign in, which I never have to do typically. It always remember my credentials in the past.

That initial error says "Account validation error: g3.g: Abstract classes can't be i..." and the rest is truncated from there.  The error disappears really fast. 

And then I attempt to sign in as being asked and I get another quick error flash on my screen, "Login error: g3.g: Abstract classes can't be instantiated! R...".  And then I am back to my normal monitoring screen.

Robert

Screenshot_20230429-093658.png

 

Screenshot_20230429-093646.png

 

Screenshot_20230429-092934.png

Edited by S4GRU
Add images
  • Like 1
  • Thanks 1
Link to comment
Share on other sites

Same thing for me, though I might have accidentally sent you like half a dozen diagnostics by holding down for too long. 

 

Edit: I was able to get the full text of the error via Samsungs NiceCatch. All of the errors are the same, just with either Authentication Error or Login Error

 

Abstract classes can't be instantiated! Register an instance creator or a TypeAdapter for this type. ClassType: m0.f5

  • Thanks 1
Link to comment
Share on other sites

23 hours ago, mikejeep said:

Thanks all, I was able to figure out the issue, it was a compiler problem -- new beta update is rolling out now that resolves it!

Confirmed fixed for me as well.

  • Like 3
Link to comment
Share on other sites

  • 3 weeks later...
8 minutes ago, Grabber5.0 said:

Is there a known issues log or post somewhere? I don't want to report a known issue.

Edit: also I'm probably dumb for not sending a report while triaging.

The website (https://signalcheck.app) has a Known Issues page on the Wiki tab. If you want to report a bug, the Issues tab is a good place to check to see if it's already reported. If not, you can report it there. You can always just post, PM, or email too.. I get to it all eventually.

Sending diagnostic reports when you see an issue is definitely helpful. Feel free to share info even without a report, you can always send it next time you see an issue.

  • Like 1
Link to comment
Share on other sites

1 hour ago, mikejeep said:

The website (https://signalcheck.app) has a Known Issues page on the Wiki tab. If you want to report a bug, the Issues tab is a good place to check to see if it's already reported. If not, you can report it there. You can always just post, PM, or email too.. I get to it all eventually.

Sending diagnostic reports when you see an issue is definitely helpful. Feel free to share info even without a report, you can always send it next time you see an issue.

I don't see this one there, though I suppose I could be related to the one about no signal strength in the signal icons. This morning I had two signal icons, both without signal strength, and one apparently stale. I had an LTE and a 5G icon, and when I opened the app from the notification (there were two notifications, one empty and one populated - I've seen that before) it only showed LTE and WiFi. I threw away and reopened the app a couple times with no change, then used exit from the app menu and everything returned to normal when I reopened the app.

Screenshot_20230517-095801.png

Link to comment
Share on other sites

  • 2 months later...

Mike,

Got myself a Moto Edge 2022 which I am in love with for logging.  Supports every feature as far as I can tell, including band locking without any external apps!  More on that on Reddit ( https://www.reddit.com/r/Dish5G/comments/15h46le/comment/juyssk6/?utm_source=reddit&utm_medium=web2x&context=3 ) and I'm about to cross-post in the Motorola forum here.

One question, though, is whether or not it's possible to get a System Shortcut (and thus the lightning icon) to the *#*#4636*#*# menu, which is labeled "Testing," or the sub-menu that actually does the band locking.  I briefly tried to find a shortcut to it with a shortcut app and didn't immediately find it.  If there's something specific that might help in tracking it down, let me know.  (And I know it may not be possible to get a shortcut, but the Radio Info one does work, just that it's not the screen I want to be on...)

- Trip

  • Like 2
Link to comment
Share on other sites

11 hours ago, Trip said:

Mike,

Got myself a Moto Edge 2022 which I am in love with for logging.  Supports every feature as far as I can tell, including band locking without any external apps!  More on that on Reddit ( https://www.reddit.com/r/Dish5G/comments/15h46le/comment/juyssk6/?utm_source=reddit&utm_medium=web2x&context=3 ) and I'm about to cross-post in the Motorola forum here.

One question, though, is whether or not it's possible to get a System Shortcut (and thus the lightning icon) to the *#*#4636*#*# menu, which is labeled "Testing," or the sub-menu that actually does the band locking.  I briefly tried to find a shortcut to it with a shortcut app and didn't immediately find it.  If there's something specific that might help in tracking it down, let me know.  (And I know it may not be possible to get a shortcut, but the Radio Info one does work, just that it's not the screen I want to be on...)

- Trip

It would be totally awesome if we could input what we wanted the system shortcut to be which SCP would then do.

  • Like 3
Link to comment
Share on other sites

I'm not sure if I can make an option to pick any shortcut the user wants, but I will look into it. I'm happy to add anything anyone wants, but dialer codes were blocked several Android releases ago. I need the actual name of the shortcut (using one of those apps is the best way to find that).

  • Like 1
Link to comment
Share on other sites

  • 2 weeks later...

A new SCP beta is rolling out now! The most notable addition is 5G-NR Timing Advance (TA) display on compatible Android 14 devices. It is not displaying on the latest Android 14 Beta release on my Pixel 7, but when the functionality is added, the values should appear in the app. It will probably take some time before it is displayed on most devices.

Beyond that, there are many bug fixes and improvements, including ongoing dual SIM improvements (slowly getting there!) and numerous changes in preparation for the upcoming launch of Android 14. Full changelog is available here as always, or inside the app. Look forward to feedback!

  • Like 4
Link to comment
Share on other sites

Another SCP update rolling out now.. beta-only for the moment, but pending any last-minute hiccups, the same version will roll out as a public release within a day or so. The only change for beta users is a minor bugfix related to the Recent Apps screen. Appreciate all the feedback!

EDIT: Google Play pushed the public release out with the beta and there's no way for me to pause it.. hopefully all is well!

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

A SCP beta update is rolling out now.. bugfix for Android 14 devices crashing when Location permission is not granted and the background service is enabled. Will roll out to the public soon as long as it proves to be stable.

  • Like 3
Link to comment
Share on other sites

  • 2 weeks later...
14 hours ago, RAvirani said:

It looks like Dish n66 is showing up as n1. I sent a diagnostic this past weekend. 

Thanks, should be resolved in next update, which should be out today. Thankfully in July the Android development team reported that the 5G-NR band identification bug was finally resolved on Pixel devices, hopefully similar patches make it to other devices soon.

  • Like 4
Link to comment
Share on other sites

2 hours ago, mikejeep said:

Thanks, should be resolved in next update, which should be out today. Thankfully in July the Android development team reported that the 5G-NR band identification bug was finally resolved on Pixel devices, hopefully similar patches make it to other devices soon.

That's great news!

  • Like 1
Link to comment
Share on other sites

  • 2 weeks later...

Mike,

Until yesterday, I hadn't locked my newest phone, the Moto Edge 2022, to an LTE band.  I'd only ever used it on NR, where it works basically fine for logging purposes other than the modem reset issue I flagged in the thread I made on the Motorola forum, which is entirely unrelated to SCP.  (For the record, it happened once yesterday about 25 minutes into our outing, and then not again the rest of the day.)

I was out and about and had it looked to n41 and B41 for the first time, and encountered something new on it.  Sometimes, when changing sectors or going in/out of service on the LTE side, where other phones would give bad GCIs with no TAC or something, this phone apparently flashes the previously-seen GCI/TAC but with an RSRP of -44 and an RSRP of -3.  You can guess what this did to the log.  I tried to screenshot it but it was too fast to catch; here's a picture of what the log looks like sorted by last_time:

https://imgur.com/a/LBehfrW

Much as I hate to ask you for another work-around, it would be nice have an option to be able to tell SCP not to log in that circumstance, much like how it has an option to not log when the TAC is missing. 

Separately, it also has a bad TA value that the checkbox only partially fixes.  I'm going to do more investigation on that and see if I can figure out what the proper correction factor should be for this device.  It may be necessary to consider providing multiple options for adjusting the TA.  That said, I can already tell that won't completely help as it shows 0 TA a lot longer than my other devices do.  I'm almost wondering if it's off by a constant rather than a coefficient, if that makes sense; I'll follow up on this after some investigation.

- Trip

  • Sad 1
Link to comment
Share on other sites

17 minutes ago, Trip said:

Sometimes, when changing sectors or going in/out of service on the LTE side, where other phones would give bad GCIs with no TAC or something, this phone apparently flashes the previously-seen GCI/TAC but with an RSRP of -44 and an RSRP of -3.  You can guess what this did to the log.  I tried to screenshot it but it was too fast to catch; here's a picture of what the log looks like sorted by last_time:

https://imgur.com/a/LBehfrW

Much as I hate to ask you for another work-around, it would be nice have an option to be able to tell SCP not to log in that circumstance, much like how it has an option to not log when the TAC is missing.

Yuck! Obviously there's a bug with the phone itself, but I'll get on a workaround. Hopefully you can repair some of your bogus data.. that is annoying. If you haven't already, can you send a diagnostic from that phone with a reference to the bug? Doesn't have to be when it's happening, I just want to capture the device info.

 

17 minutes ago, Trip said:

Separately, it also has a bad TA value that the checkbox only partially fixes.  I'm going to do more investigation on that and see if I can figure out what the proper correction factor should be for this device.  It may be necessary to consider providing multiple options for adjusting the TA.  That said, I can already tell that won't completely help as it shows 0 TA a lot longer than my other devices do.  I'm almost wondering if it's off by a constant rather than a coefficient, if that makes sense; I'll follow up on this after some investigation.

Let me know what you find, happy to help however I can.

  • Thanks 1
Link to comment
Share on other sites

13 minutes ago, mikejeep said:

Yuck! Obviously there's a bug with the phone itself, but I'll get on a workaround. Hopefully you can repair some of your bogus data.. that is annoying. If you haven't already, can you send a diagnostic from that phone with a reference to the bug? Doesn't have to be when it's happening, I just want to capture the device info.

 

Let me know what you find, happy to help however I can.

Done.  I'll send you another later when it's actually connected.  Bonus points if I can catch it at -44.

And regarding the TA value, I will.  Not sure I'll be able to investigate more before Monday, but as soon as I can I'll try to get you some data.

- Trip

  • Thanks 1
Link to comment
Share on other sites

Mike,

We ended up going out this morning to do errands in spite of the tropical storm.  I locked the phone on LTE B41, turned off the TA correction checkbox, and watched it carefully while out and about.  I have four screenshots for you.

https://imgur.com/a/kCPTCnB

First, I happened to get a screenshot of it doing the -44 dBm thing.  I also tried to send you at least one set of diagnostics showing the -44 dBm but I don't know where precisely in the process it collects the diagnostics.  Hopefully there's something useful in them.

The rest of the screenshots are far more interesting.  All three were taken within seconds of each other in the CVS parking lot.  The phone's diagnostic screen shows a TA of 17, and oddly, the SCP diagnostics screenshot also appears to show a TA of 17.  But SCP's normal display is showing 0.  Not entirely sure what to make of that.  It looks like SCP won't show me a value other than 0 until I hit about 19 according to the phone diagnostic screen.

It also appears that when SCP is showing a TA of 1263, that's the equivalent of a null value for the TA--no TA is calculated.  The phone diagnostic screen appears to show just "12" when that's happening; the SCP diagnostic screen shows 1282 in the TA section when that happens, a difference of 19, which is highly convenient given what I noted above about the TA value.  (I can't test that the phone diagnostic screen is limited to two characters and is thus truncating 1282 to just "12" as I suspect given where I am right now.  Had I known to be looking for it, I'd have tested in the middle of nowhere yesterday.)

Anything catch your eye?  Anything I can do to help more? 

- Trip

  • Thanks 1
Link to comment
Share on other sites

4 minutes ago, Trip said:

First, I happened to get a screenshot of it doing the -44 dBm thing.  I also tried to send you at least one set of diagnostics showing the -44 dBm but I don't know where precisely in the process it collects the diagnostics.  Hopefully there's something useful in them.

I received the reports, thanks! You didn't catch it happening (it captures the diagnostics as soon as you hit send or long-click the connection banner on the main screen), and I had sent you an e-mail to clarify which value was -3.. but your screenshots confirmed my hunch that you meant RSRQ!

 

4 minutes ago, Trip said:

The phone's diagnostic screen shows a TA of 17, and oddly, the SCP diagnostics screenshot also appears to show a TA of 17.  But SCP's normal display is showing 0.  Not entirely sure what to make of that.  It looks like SCP won't show me a value other than 0 until I hit about 19 according to the phone diagnostic screen.

It also appears that when SCP is showing a TA of 1263, that's the equivalent of a null value for the TA--no TA is calculated.  The phone diagnostic screen appears to show just "12" when that's happening; the SCP diagnostic screen shows 1282 in the TA section when that happens, a difference of 19, which is highly convenient given what I noted above about the TA value.

I know exactly what is happening here. Somewhere along the way, I learned that TD-LTE bands (33-53) needed a TA correction of -19 applied, and I confirmed it on several devices. Perhaps that is no longer universally true.. but what you're seeing SCP display matches that correction. Below 19 you see nothing, at 19 you see 0, and above that you see TA-19. The upper limit is 1282, which is why you see 1263. Your phone must report 1282 when the TA is unknown, which is not technically safe but I can work around that.

Funny enough, I had a change to TA coming in the next update that had nothing to do with your issues.. TA:0 will be hidden moving forward, since several devices report 0 when it cannot be identified.

I'll have an app update out shortly that addresses all of this, let me know how it works for you and thanks for the detailed feedback!

  • Thanks 1
Link to comment
Share on other sites

4 minutes ago, mikejeep said:

I received the reports, thanks! You didn't catch it happening (it captures the diagnostics as soon as you hit send or long-click the connection banner on the main screen), and I had sent you an e-mail to clarify which value was -3.. but your screenshots confirmed my hunch that you meant RSRQ!

 

I know exactly what is happening here. Somewhere along the way, I learned that TD-LTE bands (33-53) needed a TA correction of -19 applied, and I confirmed it on several devices. Perhaps that is no longer universally true.. but what you're seeing SCP display matches that correction. Below 19 you see nothing, at 19 you see 0, and above that you see TA-19. The upper limit is 1282, which is why you see 1263. Your phone must report 1282 when the TA is unknown, which is not technically safe but I can work around that.

Funny enough, I had a change to TA coming in the next update that had nothing to do with your issues.. TA:0 will be hidden moving forward, since several devices report 0 when it cannot be identified.

I'll have an app update out shortly that addresses all of this, let me know how it works for you and thanks for the detailed feedback!

In order:

This is very helpful to know.  Thanks.

That makes a lot of sense, though it's showing me zero rather than nothing; it looks like if it's calculating a negative number, I'm seeing zero instead.  It makes me wonder how many devices you've tested against which use the MediaTek chipset.  This is only the second one I've used, and the first one was very, very old (didn't have B41), so it's possible that the MediaTek chip doesn't need the correction while others do.  Separately, I doubt that a real world case will ever see 1282, so I imagine any value above 1281 could be ignored.

I would ask you to please not hide TA values of 0, or if you hide them by default, add an option to not hide them.  I am aware that, for example, the S22 doesn't report a valid TA value and always reports zero, but zero is a legitimate value and is useful to know when trying to identify sites.

I'll look forward to your impending update, and I'm going to send along another donation if I can find the link.  Thanks so much, as always! 

- Trip

  • Like 2
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

    • I've now seen how things work in Kobe, Hiroshima, and Osaka, as well as some areas south of Osaka (e.g. Wakayama, Kinokawa), and tried three more SIMs. The two physical SIMs (different branding for each) both use IIJ, which provides a Japanese IP address/routing on NTT, aleit LTE-only, so latency is ~45ms to Tokyo. The catch with NTT is that it uses two frequency bands (B42/3500 MHz LTE, n79/4900 MHz NR) that you're not going to get on an Android sold in the US, and I'm guessing that B42 would be helpful speed-wise on that network, as it doesn't have B41. I also found one place that doesn't have cell service: a vending machine in the back of the Osaka Castle tower. Or, rather, the B8/18/19 signal is weak enough there to be unusable. Going back to 5G for a moment, I saw a fair amount of Softbank n257 in Hiroshima, as well as in some train stations between Osaka and Kobe. 4x100 MHz bandwidth, anchored by B1/3/8, with speeds sometimes exceeding 400 Mbps on the US Mobile roaming eSIM. Not quite the speeds I've seen on mmW in the States, but I've probably been on mmW for more time over the past few days than I have in the US over the past year, so I'll take it. My fastest speed test was actually on SoftBank n77 though, with 100 MHz of that plus 10x10 B8 hitting ~700 Mbps down and ~80 Mbps up with ~100ms latency...on the roaming eSIM...on the 4th floor of the hotel near Shin-Kobe station. Guessing B8 was a DAS or small cell based on signal levels, and the n77 might have been (or was just a less-used sector of the site serving the train station). I'm now 99% sure that all three providers are running DSS on band 28, and I've seen 10x10 on similar frequencies from both NTT and SoftBank IIRC, on both LTE and 5G. I also picked up one more eSIM: my1010, which is different from 1010/csl used by US Mobile's eSIM unfortunately, as it's LTE-only. On the bright side, it's cheap (10GB/7 days is like $11, and 20GB for the same period would be around $15), and can use both KDDI and SoftBank LTE. It also egresses from Taiwan (Chunghwa Telecom), though latency isn't really any better than the Singapore based eSIMs. Tomorrow will include the most rural part of our journey, so we'll see how networks hold up there, and from tomorrow night on we'll be in Tokyo, so any further reports after that will be Tokyo-centric.
    • I think the push for them is adding US Mobile as a MVNO with a priority data plan.  Ultimately, making people more aware of priority would allow them (and other carriers) to differentiate themselves from MVNOs like Consumer Cellular that advertise the same coverage. n77 has dramatically reduced the need for priority service at Verizon where the mere functioning of your phone was in jeopardy a couple of years ago if you had a low priority plan like Red Pocket. Only have heard of problems with T-Mobile in parts of Los Angeles. AT&T fell in between. All had issues at large concerts and festivals, or sporting events if your carrier has no on-site rights. Edit: Dishes native 5g network has different issues: not enough sites, limited bandwidth. Higher priority would help a few. Truth is they can push phones to AT&T or T-Mobile.
    • Tracfone AT&T sims went from QCI 8 to 9 as well a couple years ago. I'm pretty neutral towards AT&T's turbo feature here, the only bad taste left was for those who had unadvertised QCI 7 a couple months ago moved down to 8. In my eyes it would have been a lot better for AT&T to include turbo in those Premium/Elite plans for free to keep them at QCI 7, while also introducing this turbo add on option for any other plans or devices. As it stands now only a handful of plans can add it, and only if you're using a device on a random list of devices AT&T considers to be 5G smartphones.
    • My Red Pocket AT&T GSMA account was dropped to QCI 9 about a year ago.  Most recently 8 for the last few years prior.  Voice remains at 5.
  • Recently Browsing

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