Jump to content

SignalCheck Beta Crew Forum


mikejeep

Recommended Posts

6 hours ago, S4GRU said:

On another note, I found a treasure trove of City of Everett archives online and added every missing Tmo site to the database from there, as well as update any missing Site numbers/names.  I have added or updated probably a 1,500 sites in the 2 months as i scour data sources as I have free time or insomnia.

Oh awesome! Is there a link you could provide so I could take a peek?

Link to comment
Share on other sites

Still working through catching up on PMs, e-mails, and posts.. but just a quick note to update 2 things:

1) If you are experiencing crashes/freezes, disable the Show Pending Web Entries setting under Preferences > Beta Crew Settings. New beta coming soon that removes that and updates some internal libraries that seems to have resolved all issues on my devices.

2) New website is coming online tonight, transitioning to GitHub to provide issue tracking and a Wiki that I will invite everyone to contribute to.

  • Like 4
Link to comment
Share on other sites

Working on crushing all of the latest bugs, but I need more data to help improve the app for Dish users. Please submit diagnostic reports when connected to Dish, especially NR. In the report, I can see what the app is displaying, but please include in your note what you think is wrong (ie should be Dish NR, etc). Thanks!

Link to comment
Share on other sites

On 7/21/2022 at 9:43 PM, mikejeep said:

New beta coming soon that removes that and updates some internal libraries that seems to have resolved all issues on my devices.

Wait - to clarify are you removing the display of pending web data points? I do really like that feature…

2 hours ago, mikejeep said:

Working on crushing all of the latest bugs, but I need more data to help improve the app for Dish users. 

You’ll have to effectively add dual SIM support to SCP to record Dish points. I played around a bit in android studio (trying to display Dish data on my Samsung 22) out of curiosity and it looks like all data is reported as coming from a secondary SIM. 

  • Like 1
Link to comment
Share on other sites

6 hours ago, RAvirani said:

Wait - to clarify are you removing the display of pending web data points? I do really like that feature…

I like it too -- but I believe that feature is contributing to the app instability that many users are experiencing. I don't intend for it to be permanent; I'm working on overhauling it with a different approach. My first few attempts have not produced a great alternative, I just don't want to hold up releasing an update just for this. If I don't have a replacement working when I'm ready to release an update, maybe I'll try to continue offering the current option with a warning about potential issues.

 

6 hours ago, RAvirani said:

You’ll have to effectively add dual SIM support to SCP to record Dish points. I played around a bit in android studio (trying to display Dish data on my Samsung 22) out of curiosity and it looks like all data is reported as coming from a secondary SIM. 

Ah, that is annoying. The only reports I found were both from you, but they were LTE-only and every cell was identifying itself as AT&T.

EDIT: I found one other Dish report from another user -- SCP was identifying it as AT&T LTE with Dish NR.. so who knows.

Link to comment
Share on other sites

I would love an n7 kludge fix to reset it as n41 done as a line in settings (we have others like this)  Why? I am locking in various Samsung phones to the current release where the Samsung band selector app still works on Verizon and AT&T. Whether you do this or not, I bought a pitcher of beer for your great work. Thanks.

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

2 hours ago, dkyeager said:

I would love an n7 kludge fix to reset it as n41 done as a line in settings (we have others like this)  Why? I am locking in various Samsung phones to the current release where the Samsung band selector app still works on Verizon and AT&T. Whether you do this or not, I bought a pitcher of beer for your great work. Thanks.

I finished testing a workaround for the n7/n38 bug a couple days ago! It'll be included in the beta I'm planning to release in the next 1-3 days.. just depends on how my final testing goes. Need to take a few drives to check out certain issues.

I greatly appreciate your generosity.. it's not necessary but it goes a long way! Thank you!!

  • Like 3
Link to comment
Share on other sites

8 hours ago, mikejeep said:

I like it too -- but I believe that feature is contributing to the app instability that many users are experiencing. I don't intend for it to be permanent; I'm working on overhauling it with a different approach. My first few attempts have not produced a great alternative, I just don't want to hold up releasing an update just for this. If I don't have a replacement working when I'm ready to release an update, maybe I'll try to continue offering the current option with a warning about potential issues.

Are you querying the SCP database every time you update the displayed number of points? If so, it might be less expensive to just store a variable and increment it every time you write a trail entry to the DB. You could sync the variable with the DB via a query every 128 points or something just in case they somehow come out of sync. 

8 hours ago, mikejeep said:

Ah, that is annoying. The only reports I found were both from you, but they were LTE-only and every cell was identifying itself as AT&T.

EDIT: I found one other Dish report from another user -- SCP was identifying it as AT&T LTE with Dish NR.. so who knows.

I have momentarily seen SCP identify Dish with AT&T LTE—see below:

https://imgur.com/a/NxWXLbD

Although 99% of the time it’s 5G on the secondary SIM. 

This might also help you to understand the setup better:

https://imgur.com/a/yK16Nmo

  • Like 1
Link to comment
Share on other sites

On 7/24/2022 at 12:25 PM, RAvirani said:

Are you querying the SCP database every time you update the displayed number of points? If so, it might be less expensive to just store a variable and increment it every time you write a trail entry to the DB. You could sync the variable with the DB via a query every 128 points or something just in case they somehow come out of sync. 

The current version does hit the database each time, because that was the only method I could get to work consistently. Started re-visiting an overhaul of it a few weeks ago when I realized it might be contributing to ANRs, it's just unfortunately not as simple as you described. The background service that does the logging is separate from the activity that displays data. Might end up settling for a "close approximation" approach, we'll see..

Link to comment
Share on other sites

1 hour ago, mikejeep said:

The current version does hit the database each time, because that was the only method I could get to work consistently. Started re-visiting an overhaul of it a few weeks ago when I realized it might be contributing to ANRs, it's just unfortunately not as simple as you described. The background service that does the logging is separate from the activity that displays data. Might end up settling for a "close approximation" approach, we'll see..

Would it be possible to store a variable accessible by the background service that can be incremented? I’d think you could even leave it on the disk (not in RAM) when the background service is running in the absence of the display being visible…then maybe pull it into RAM for quicker updates when the app is displayed?

Link to comment
Share on other sites

31 minutes ago, RAvirani said:

Would it be possible to store a variable accessible by the background service that can be incremented? I’d think you could even leave it on the disk (not in RAM) when the background service is running in the absence of the display being visible…then maybe pull it into RAM for quicker updates when the app is displayed?

It's hard to describe.. without getting into a programming discussion, I'll just say it's more complicated than that.. sent you a PM ;)

Link to comment
Share on other sites

8 hours ago, mikejeep said:

It's hard to describe.. without getting into a programming discussion, I'll just say it's more complicated than that.. sent you a PM ;)

If you hit a wall, remember that some of us have written millions of lines of code over time.

  • Like 2
Link to comment
Share on other sites

@RAvirani Do you think you could implement a filter that converts all of the T-Mobile n7 to n41 (both ready logged and incoming)? At least in the meantime, until Mike implements his fix in the app. Now that n41-SA has finally gone live across the Seattle market, not just a couple choice sites, I will be doing a lot of logging of n41.

Link to comment
Share on other sites

18 minutes ago, PedroDaGr8 said:

@RAvirani Do you think you could implement a filter that converts all of the T-Mobile n7 to n41 (both ready logged and incoming)? At least in the meantime, until Mike implements his fix in the app. Now that n41-SA has finally gone live across the Seattle market, not just a couple choice sites, I will be doing a lot of logging of n41.

Do the uploaded n7 entries have the correct NR-ARFCN?

Link to comment
Share on other sites

1 hour ago, PedroDaGr8 said:

Yes they do (527790).

 

That’s what I thought because NR-ARFCNs are absolutely unlike EARFCNs.

I can probably implement the correction on my side either tonight or tomorrow night. 

  • Like 1
Link to comment
Share on other sites

16 minutes ago, RAvirani said:

That’s what I thought because NR-ARFCNs are absolutely unlike EARFCNs.

How so? 

 

17 minutes ago, RAvirani said:

I can probably implement the correction on my side either tonight or tomorrow night. 

Thanks, that would be great!

Link to comment
Share on other sites

New SCP beta is rolling out now and should appear on Google Play shortly! This version should be more stable overall; there were some improvements to some significant Android libraries that I think ironed out a few quirks.

Samsung devices that showed n7/n38 on T-Mobile will show n41 moving forward; however, any pre-existing log entries will not be touched.

The pending web entry display has been overhauled, and should use less overhead. However, the display is more of an approximation than an exact number. It'll be exact when you resume the app from a closed state, but it may drift +/- a few entries the longer you keep it in the foreground. It does not impact the actual uploads, just the running tally on the main screen. The tally on the Statistics and Upload screens are still exact.

Please let me know if you discover any issues, this release is still a work in progress. Also, check out the new website at https://signalcheck.app and share any feedback. The 'Issues' tab is going to be my new spot to track bugs and feature requests moving forward, so feel free to open issues if needed.

  • Like 3
  • Love 1
Link to comment
Share on other sites

I've just installed the latest version on my S21FE.  I'll let you know if it's less crashy now.  Hopefully it is--it was severe enough that it was sometimes crashing and not auto-relaunching, which was problematic for obvious reasons.

I'm going to christen your new Issues system by putting my last e-mail to you into it.  Hope that's okay.

- Trip

  • Like 1
Link to comment
Share on other sites

14 minutes ago, Trip said:

I'm going to christen your new Issues system by putting my last e-mail to you into it.  Hope that's okay.

Please do! That's why it's there.. should help me keep track of things better than the mix of threads/PMs/emails/web forms/group chats I was using. Too many things fall through the cracks and it's hard to keep up.

  • Like 1
Link to comment
Share on other sites

3 hours ago, mikejeep said:

Please do! That's why it's there.. should help me keep track of things better than the mix of threads/PMs/emails/web forms/group chats I was using. Too many things fall through the cracks and it's hard to keep up.

I was actually able to send a bug report via Google a few days back. It usually would crash out before it let me do that. I don't know if it was able to send any helpful data or not. I'm not sure what I've done to my install to make it dislike me so much haha.

  • Thanks 1
Link to comment
Share on other sites

7 minutes ago, Dkoellerwx said:

I was actually able to send a bug report via Google a few days back. It usually would crash out before it let me do that. I don't know if it was able to send any helpful data or not. I'm not sure what I've done to my install to make it dislike me so much haha.

Those are helpful sometimes, but it's hit or miss -- they get aggregated together, I can't see who submitted it. A lot of the recent issues were referencing Android source files, not SCP ones, so that makes it tricky to troubleshoot. Fingers crossed this new version is much better!

  • Like 1
Link to comment
Share on other sites

I can confirm the new beta fixed the n7/n41 issue. When I went home yesterday, I noticed that the faster logging speeds of for NR of recent are back to around 1/2 the rate for LTE. That being said, my phone was crazy hot on the way home so that could have impacted things some. I will investigate more later. 

  • Like 1
Link to comment
Share on other sites

I had a weird issue on both of my phones this morning. Went to upload data after driving to the office and after tapping upload web data nothing would happen. I had to exit out and reopen SCP to get the data to upload. 

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

×
×
  • Create New...