Jump to content

mikejeep

Honored Premier Sponsor
  • Posts

    3,257
  • Joined

  • Last visited

  • Days Won

    183

Everything posted by mikejeep

  1. What devices should do, and what they actually do, are two very different things! As you've probably heard me mention countless times, many of those screens get information in a proprietary manner directly from the modem; apps like SignalCheck can only get what the OS is reporting. I did find your earlier reports, and as I guessed, the OS was reporting valid signal strength. I will try to figure out a solution.
  2. Interesting, that doesn't happen on my P7. Can you send me a diagnostic report the next time you see that please? Hopefully the phone isn't actually reporting the -115, that will be tricky.
  3. TLDR: not really 😂 With dual SIM, initially I was struggling to keep the info from each SIM separate but updating properly. I figured out how to get each to update without negatively impacting the other SIM's process.. which caused those processes to run on separate threads. On some devices (notably your e5 Play), the OS doesn't like the separate threads updating the UI. But it was only a very small subset of devices. And at first, the crash reports gave the correct crash reason but it was pointing to unrelated parts of the code. Once I cleaned up some other bugs, the crash reports pointed me directly to what I needed.
  4. I like it.. I'll work on that. Hmm, thought I had squashed that one.. I will work on it.
  5. Hot on the heels of the release an hour ago, here comes another SCP beta, with another bugfix for force closes on startup.. @Trip let's see how this goes!
  6. It doesn't look like it -- however, my internal crash libraries did catch it and I have some more clarity now. Other crashes were masking the cause of yours. Now I just have to learn how to fix it..
  7. Yours was one of the ones I was hoping this release would fix.. thank you for the reports, that's the only way I can try to keep digging!
  8. A fresh SCP beta is rolling out now.. mostly bugfixes, but also includes a new option to display the cell timestamp at the top of each mobile connection "block". There may still be dual SIM logging issues and other bugs in this release, but I need to clean up the significant app instability before I can identify the causes of some of the trickier bugs. Looking forward to feedback!
  9. Yes, SCP does assume that because the reference I usually use (forgot to link in my last post) showed that. I'll make that change in the next update and let that author know, as I mentioned before that site has been reliable until now. Dual SIM is not enabled by default, when I pulled up your report I didn't check to see if it was enabled on your device just thought it might be a quick fix for you. Since it requires Android 10+ it should be grayed out.. although I wonder if there's some other version check that is being missed, and the root cause of your issue.. I will add that to the list of possibilities I'm checking.
  10. The primary reference I use shows the EARFCNs you submitted as AWS-3.. but doing more searches, I'm finding conflicting info elsewhere. This is the first time I can recall having an issue with my reference -- if you have a good source, please send me a message! It's throwing an unusual error claiming another process is trying to update the SCP screen.. which is obviously not true, but something is wrong of course. I saw that occasionally in my very early dual SIM testing, but have not been able to replicate it in quite some time. I only have that crash logged 2-3 times from devices that are not yours. I will be investigating, but it's definitely related to dual-SIM. If you try disabling that option, do the crashes stop?
  11. There is a thread about the mapping site in the sponsor section where status updates are usually posted. With this project still being very much a work in progress, it's not really intended to be completely public-facing yet.
  12. This "feature" has always been problematic and I've tweaked it with each release. There are sometimes dozens (!) of data updates included in a single screen refresh, even if the actual information does not change. It's been strangely difficult to get the app to keep an accurate count of which updates are going to result in a new datapoint being generated. My original approach kept the count accurate but it was too database-intensive and caused crashes and instability. I will continue to make adjustments to it, but in the meantime if you do a swipe-down refresh, that will always poll the database to get an accurate pending count.
  13. These are two big reasons I already had in mind when I said I'd probably keep the existing option an add an additional one. Options are great because then users can set it up however they prefer. Also, an overwhelming majority of users are single-SIM.. happy to add features for everyone and keep the user experience consistent at the same time!
  14. Another day, another SCP beta release rolling out! This is another minor "work in progress" update attempting to resolve some of the bugs that have popped up. This version includes a fix for Dish (or is it DISH? That was the issue) identification vs. AT&T, new Dish ECI formatting (for real this time, I hope), 5G-NR alert notification formatting, adding AWS-3 and AWS-4 text in the app (the icons will remain "AWS" because the font becomes unreadable when adding more characters to such a small graphic), and Verizon 5G-NR sector calculations. There are still lingering issues, but I'm trying to provide updates when I have significant fixes ready to roll out and test during this dual SIM development phase. There may be an issue with logging with dual SIM but I am still looking into it. Please keep the feedback coming, that's the only way I can successfully keep the app moving forward!
  15. I can look into implementing that, makes sense. The original intent of the timestamp and location was for screenshot purposes.. they evolved into simple diagnostic tools over time! I may leave the existing timestamp option in place, and add a new option to display the timestamp returned by cell on each "cell block". I don't mind bugs, feature requests, etc in the thread, and certainly this is the most appropriate spot for discussion. But I would like to invite/remind everyone to feel free to utilize the "Issues" tab on the app's GitHub site (https://signalcheck.app) for things like that if you're comfortable. I will often copy and paste issues from here over there to make it easier for me to keep track. Between these mega-threads, my e-mail, group chats, it's easy to inadvertently lose track of things..
  16. Thank you! Was it happening when the app saw it as Dish NR, or when you knew it was Dish but the app was showing AT&T?
  17. I think I did all my work based on the decimal IDs, because that's what I thought was on the website..? The app will convert the display to hex on the fly if that's the user's preference. I did just realize that I did not update the export routines to match what the app will display in real-time, so if you were seeing invalid data in log exports, that is an oversight I'll be working on today. It should be displaying properly in-app on the fly though.
  18. Thanks -- there was a discussion about this awhile back (probably in this thread) and I set T-Mobile to 4096, AT&T to 1024, and defaulted all other providers to 1024. In last night's update, I changed Dish to 4096. I'll change Verizon to 16384 in the next update. If anyone knows the configuration for other providers, please let me know! I was using sample data from those Houston sites to confirm my math -- do you have your cell ID preference set properly in the app? Check Preferences > Display Settings > LTE/NR Cell ID Format, I believe you will want "Decimal w/Sector" to have the app match the map.. if that doesn't work, try a different setting just in case. Shoot me a diagnostic if you're still not seeing them. Can you send a diagnostic report next time you see this? You are right, looks like the notification is hard-coded to display hex format -- I will fix that. Are the triggers themselves working properly? Hmm that is weird -- can you send me some log exports (and diagnostic reports if you see it wrong on the fly) that show that so I can try looking into it?
  19. Yes, the site notes are all stored in a sqlite database what the app refers to as the "Site Log". This database can be backed up from the app, edited externally, and then imported back into the app. There are two things you must be cautious of when doing this: The app does not do an in-depth verification of the structure of imported databases. Do not change the database structure, and I strongly advise not changing any fields in the database other than the Site Notes. When importing a database, it will overwrite the database currently on your device. So if you backup your database and then re-import it a month later, you will lose any data you recorded during that month. To backup your database, go to Logs > Backup Log Database. To import it once you are done, go to Logs > Import Log Database. Saving a backup copy of your original database before you start editing is good practice in case something goes wrong. It is easiest to browse/modify the database on a computer; the program I have found to be most useful is the free open-source DB Browser for SQLite (https://sqlitebrowser.org). There are many mobile apps available on Google Play as well. To get to the information you are looking for in the database, browse to the "sites_lte" and "sites_nr" tables, and you will be looking to modify the "user_note" field. Something to note is that the app does use logic to use site notes across multiple sectors it identifies to be at the same site. So, if there are multiple sectors recorded in your database for the same site, and you do not change all of them, the app could overwrite your new note with an older note if it connects to the sector with the older note first, depending on the sequence of events and your app settings at the time. Good practice when editing notes might be to sort by gci/nci, so you can easily see what similar sectors are already recorded. This was more challenging with Sprint sites because the app is able to link LTE sites with dissimilar GCIs in some regions, but what is left of the Sprint network is fading fast so this is less of an issue today.
  20. No.. this is an exception because the alert code already does what I'd be implementing for the reset feature that was requested.. depending on how it works out and what @Trip's needs are, I may simplify this in the future to work without the alert enabled. Wanted to get the functionality out there and see how it went before I reinvented the wheel.
  21. Another SCP beta release is rolling out right now. This version includes: Another attempt to fix web data points that are failing validation when dual SIM mode is enabled. This issue is caused when data points on both SIMs are simultaneously recorded at the same location, which is causing the mapping server to interpret them as stale. Adjusted cell ID formatting for DISH Wireless 5G-NR connections. A new option requested by @Trip to automatically reset the mobile connection when signal is lost. This utilizes the existing reset feature so root access is required for it to work. The "No Signal" alert must also be enabled for the reset to be triggered. Thanks as always for the support!
  22. Missed this earlier.. I added it to the request list. I initially kept it all "AWS" because squeezing in "AWS-3" on the status bar icon was difficult to read. Would it be sufficient to change everything but the icon, or were you hoping for the icon also?
  23. Another SCP beta is rolling out now! This includes multi-colored accent lines for some providers that utilize multiple primary colors in their branding (US Cellular, FirstNet, Freedom, Dish, Telos) as well as a fix for web data points that were unnecessarily failing validation when dual SIM mode was enabled. Wanted to get this rolled out quickly to minimize the impact on mapping efforts by the dual SIM crowd. Also clarified within the app that dual SIM mode does not support 3G connections at this time. I am uncertain if it will be supported in the future. Disabling the dual SIM option will show 3G information as before. Some users may see 3G information with dual SIM mode enabled depending on the device's configuration and connection status. Please keep the feedback coming!
  24. As dkoellerwx eloquently mentioned, a second carrier would show as DISH Wireless B30². While we are on the subject -- should DISH be capitalized, or no? Sounds like fun, I'm on it!
  25. I have the Dish info you sent me, but I haven't implemented any of it yet -- what you are seeing is the app's standard interpretation of cell information. It's on the to-do list! Not sure what you mean here..? By 'carrier' do you mean the second provider? The [2] indicates information coming from the secondary SIM. Without that indicator means the information is coming from the primary SIM. I went with that shade of red to match the Dish Wireless logo -- but I can change it easily. If we want to differentiate between the major providers, should we go with orange for the Boost connection? I could explore implementing gradients too.. then we could get real crazy.. not sure how tricky that will be, but I'll give it a shot.
×
×
  • Create New...