SignalCheck Beta Crew Forum

[RAvirani]

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!

[dkyeager]

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

[S4GRU]

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

[mikejeep]

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.

[PedroDaGr8]

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. 

[RAvirani]

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?

[RAvirani]

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.

[mikejeep]

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?

[RAvirani]

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. 

[mikejeep]

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.

[Trip]

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

[RAvirani]

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. 

[mikejeep]

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?

[RAvirani]

5 minutes ago, mikejeep said:

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?

The app reported it as Dish NR. The PLMN was 313340. 

[RAvirani]

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”

[mikejeep]

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

[mikejeep]

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!

[Trip]

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

[RAvirani]

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. 

[dkyeager]

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.

[Trip]

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

[mikejeep]

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!

[dkyeager]

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.

 

[dkyeager]

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

[dkyeager]

S22+ system update applied. Sent diag for nsa not show n41.  Counter on screen was showing significantly higher number than web upload.