Jump to content

SignalCheck Beta Crew Forum


mikejeep

Recommended Posts

8 hours ago, mikejeep said:

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?

Everything but the icon would be great. 

8 hours ago, mikejeep said:

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.

Thank you!

  • Like 1
Link to comment
Share on other sites

8 hours ago, mikejeep said:

...The "No Signal" alert must also be enabled for the reset to be triggered.

Any other alerts used as a trigger for other behavior? I don't normally use alerts anymore and actually tend to keep sound off on my various phones so as not to distract my driving (Also for the various spam calls and texts that sneak through my preventive measures).

Link to comment
Share on other sites

10 hours ago, mikejeep said:

 

  • 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.

I am so excited about being able to map LTE and NR at the same time from the same devices with a second SIM!!!  So glad I bought a dual SIM device.

Robert

  • Love 2
Link to comment
Share on other sites

1 hour ago, dkyeager said:

Any other alerts used as a trigger for other behavior? I don't normally use alerts anymore and actually tend to keep sound off on my various phones so as not to distract my driving (Also for the various spam calls and texts that sneak through my preventive measures).

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.

  • Like 1
Link to comment
Share on other sites

Couple bugs I’ve noticed this morning:

  • Dish IDs appear to be unchanged…there are some examples of the calculation on the map in Houston, TX. 
  • After connecting to Dish SA 5G 600, AT&T NSA 5G incorrectly displays as 5G 600. ServiceMode confirms AT&T 5G is n77. 
  • 5G custom triggers don’t obey the site ID format. For example, I have my format set to decimal but this is what I see on my alerts: https://imgur.com/a/XeCVvDE
  • There seem to be a lot of 313340 entries getting identified as AT&T and a lot of 310410 entries identified as DISH…any idea what could be happening there?
Link to comment
Share on other sites

13 minutes ago, PedroDaGr8 said:

By the way Mike, I have noticed that the map and the app report different gNBs for Verizon NR. From the map, it looks like Verizon is using 22-bit gNBs while the app is using a different value. You might want to work with @RAviranito get on the same page. 

The Verizon 5G cell ID to sector/site should be remainder/division by 16384.

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

20 minutes ago, PedroDaGr8 said:

By the way Mike, I have noticed that the map and the app report different gNBs for Verizon NR. From the map, it looks like Verizon is using 22-bit gNBs while the app is using a different value. You might want to work with @RAviranito get on the same page. 

6 minutes ago, RAvirani said:

The Verizon 5G cell ID to sector/site should be remainder/division by 16384.

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!

 

18 minutes ago, RAvirani said:

Couple bugs I’ve noticed this morning:

  • Dish IDs appear to be unchanged…there are some examples of the calculation on the map in Houston, TX.

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.

 

18 minutes ago, RAvirani said:
  • After connecting to Dish SA 5G 600, AT&T NSA 5G incorrectly displays as 5G 600. ServiceMode confirms AT&T 5G is n77. 

Can you send a diagnostic report next time you see this?

 

18 minutes ago, RAvirani said:
  • 5G custom triggers don’t obey the site ID format. For example, I have my format set to decimal but this is what I see on my alerts: https://imgur.com/a/XeCVvDE

You are right, looks like the notification is hard-coded to display hex format -- I will fix that. Are the triggers themselves working properly?

 

18 minutes ago, RAvirani said:
  • There seem to be a lot of 313340 entries getting identified as AT&T and a lot of 310410 entries identified as DISH…any idea what could be happening there?

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?

Link to comment
Share on other sites

29 minutes ago, mikejeep said:

I'll change Verizon to 16384 in the next update.

Thanks!

29 minutes ago, mikejeep said:

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.

Looks like I didn’t update the hex calculation on the website, only the decimal one. Can you validate against the decimal ID until I can get that done?

29 minutes ago, mikejeep said:

Can you send a diagnostic report next time you see this?

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?

Yes—I’ll try to send both of these today. 

29 minutes ago, mikejeep said:

You are right, looks like the notification is hard-coded to display hex format -- I will fix that. Are the triggers themselves working properly?

 

 

Thank you! And yes, the triggers are functioning correctly. 

  • Thanks 1
Link to comment
Share on other sites

6 minutes ago, RAvirani said:

Looks like I didn’t update the hex calculation on the website, only the decimal one. Can you validate against the decimal ID until I can get that done?

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.

Link to comment
Share on other sites

Mike,

I'm holding off on updating per your previous suggestion about potential breakage from the dual SIM support changes.  I'm returning from my next trip out of town on Sunday and should then be home for the next two weekends, so I'll plan to upgrade my devices once I return.

Thanks so much in advance for the auto-reset functionality.  I had assumed it would only work for devices with root access, which is all but two of my regular devices as of right now. 

The issue, for what it's worth, is that I have band-locked phones on T-Mobile, and sometimes when the connection is lost on a particular band, it takes a few minutes before it comes back.  It must stop scanning to save power or something.  Resetting the connection can bring it back if the signal is present when the reset occurs.

EDIT: Separately, I just sent a donation your way.  Thanks, as always, for all you do!

- Trip

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

9 hours ago, mikejeep said:

Can you send a diagnostic report next time you see this?

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?

Sent diagnostics for both of these. 

9 hours ago, mikejeep said:

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.

I couldn’t get a diagnostic of this today, but I can confirm the app is still doing a simple remainder/division by 1024 on Dish. 

Link to comment
Share on other sites

57 minutes ago, RAvirani said:

Sent diagnostics for both of these.

Thank you!

 

57 minutes ago, RAvirani said:

I couldn’t get a diagnostic of this today, but I can confirm the app is still doing a simple remainder/division by 1024 on Dish. 

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?

Link to comment
Share on other sites

Hey Mike, another request.

Right now, the timestamp displayed at the top of the screen seems to update whenever there is a signal update. But with dual-SIM devices, it’s unclear when each SIM’s signal info was last updated. 

Could we scrap the timestamp at the top and instead add a line in the text under each connection reading something like:

”Updated: Jan 13, 2023 1:24:00 PM”

  • Like 1
Link to comment
Share on other sites

2 hours ago, RAvirani said:

Right now, the timestamp displayed at the top of the screen seems to update whenever there is a signal update. But with dual-SIM devices, it’s unclear when each SIM’s signal info was last updated. 

Could we scrap the timestamp at the top and instead add a line in the text under each connection reading something like:

”Updated: Jan 13, 2023 1:24:00 PM”

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..

  • Like 1
Link to comment
Share on other sites

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!

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

5 hours ago, mikejeep said:

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".

This please, for people who aren't using dual SIM devices.

- Trip

  • Like 1
Link to comment
Share on other sites

1 hour ago, Trip said:

This please, for people who aren't using dual SIM devices.

- Trip

If you’re only using a single SIM, it’s really just that line moving into the signal info block…although I suppose it’s easier to read when it’s at the top. 

  • Like 1
Link to comment
Share on other sites

My two cents:

The timestamp at the top fits nicely with the IP address, otherwise the location accuracy/timestamp overwrite the IP address. Maybe just have the second timestamp with the second SIM which should also make programming easier.

  • Like 2
Link to comment
Share on other sites

7 hours ago, RAvirani said:

If you’re only using a single SIM, it’s really just that line moving into the signal info block…although I suppose it’s easier to read when it’s at the top. 

It is. If I'm barrelling down the highway and glance over, I can check both timestamps at once if they're together at the top.  If they're scattered into random places along the way, not so much.

- Trip

  • Like 2
Link to comment
Share on other sites

7 hours ago, dkyeager said:

The timestamp at the top fits nicely with the IP address, otherwise the location accuracy/timestamp overwrite the IP address.

 

1 hour ago, Trip said:

If I'm barrelling down the highway and glance over, I can check both timestamps at once if they're together at the top.  If they're scattered into random places along the way, not so much.

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!

  • Thanks 1
Link to comment
Share on other sites

Testing the dual sim on a s22+ unlocked, fully patched.

Suggestion #1: instead of [2] on the right for the second sim, use 2) or #2 on the left, which should generate less confusion.  

Glitches observed:

1) Normally see n41 for T-Mobile, but rarely see n38.

2) Sometimes seeing a third line which is either my #2 Verizion repeated, or less common, my #1 sim repeated in #2 slot with the real #2 below it. Also possible this happens when the #2 sim band changes.

*** I likely captured some of the above two in a diag I sent.

3) Sitting in one spot, my Verizon band changed, yet my record count stayed at one.  Verfied by uploading which also showed only one. Should have been at least three imo: T-Mobile n41 (maybe n38), Verizon b5, Verizon b13.

Wifi shows up fine with two carriers listed.  All of this is on a phone where I have limited access. My own s21 ultra dual sim phone is held up by T-Mobile and US Mobile in terms of getting esim working. When my T-Mobile account gets migrated off Sprint billing it finally should work. :wall:

 

Link to comment
Share on other sites

I added another diag on s22+factory unlocked n38 issue. I lasts for a short period of time. Hopefully got it in this diag.

Link to comment
Share on other sites

S22+ system update applied. Sent diag for nsa not show n41.  Counter on screen was showing significantly higher number than web 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

    • Was at the Yankees vs Tigers game today and besides being a terrible day to have good seats, T-Mobile had great speeds via the stadium's DAS. I consistently saw 500-600Mbps on 5G and on LTE I got upwards of 200Mbps. I noticed that the stadiums DAS is broadcasting 140MHz n41 while macros that surround the stadium are at 80MHz.  Pics of antennas I spotted and speed tests:
    • Throwed Roll Lambert's Cafe 
    • 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.
  • Recently Browsing

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