RAvirani

2 hours ago, mdob07 said:

@mikejeepI've been noticing SCP freezing and unexpectedly closing a lot more recently since that latest beta update. It used to only do it after it had been running in the background for several hours. Now it's happening fairly frequently when I've got SCP on screen as I'm driving. Sometimes it will freeze but the system notification that it's not responding won't pop up for 15-20 minutes, or sometimes it's immediate. I have to go into settings-apps and force stop scp to get it to work again if I notice it before the system notification. 

I’m noticing the same thing…

1 hour ago, thisischuck01 said:

Not sure if there is a easy way for you to mass-delete all these on the map, @RAvirani.

I can move those sites/sectors from the AT&T map to the T-Mobile map. 

1 hour ago, thisischuck01 said:

Also, I'm still seeing SCP map T-Mobile's SA NR (primary SIM) to AT&T (secondary SIM) on my S21. In-app, SCP seems to recognize the two networks as being separate. So I'm not really sure how I can replicate this to send a diagnostic log.

@mikejeep - in the attached screenshot it looks like SCP knows that the NR connection PLMN (310260) is different than the LTE connection PLMN (310410). However, all the uploaded points are showing up with the LTE PLMN (310410) on my side. Is there a reason SCP is uploading these NR points with the LTE PLMN (310410) as opposed to the NR PLMN (310260)?

5 hours ago, mikejeep said:

SCP should record whatever NR cells it identifies with PLMN+NCI (similar to LTE, which requires PLMN+GCI). I know you're not getting TAC; are you seeing an NCI?

Right now, I’m requiring:

PLMN, tech, NCI, PCI, band, NRARFCN, RSRP, timestamp and lat/long/accuracy

…to record an NR point. What is unavailable in NSA mode? Maybe I can tweak the import algorithm to match points lacking information with an existing site?

6 hours ago, S4GRU said:

I think the issue is either my device or SCP, but it is not logging trails of NR data when connected to LTE any longer.  It only logs NR trails when there is no LTE connection at all.  I could swear it didn't use to be that way, but maybe I am mistaken.  I thought I recall that it used to log both simultaneously when connected to both, the difference being that it would not log the NR TAC at all when it was also connected to LTE.

Hm…I wonder if @mikejeep can help debug this on the app side. The website is ready to accept entries without a TAC - I actually manually tested it yesterday and ran into issues which should now be resolved. That being said, I unfortunately don’t have a 5G-capable android on T-Mobile to play with. 

6 hours ago, S4GRU said:

On another note, it looks like you made a loop around the Olympic Peninsula yesterday and picked up some fresh tracks and new sites for the map.  Looks good!  Nice to see someone over in my side of the world!  I have been doing a lot of mapping in Thurston, Mason, Kitsap and Grays Harbor in May.  I rarely get up to Sequim and PA.  Glad to see you fill in some more up there.

I did indeed! My T-Mobile device died on the southern part of the peninsula, so I missed a couple sites between New London and Oil City. I was able to map AT&T/VZW the entire way, though. 

10 hours ago, S4GRU said:

I just pulled up my trails and they all have TACs listed. So no nulls, zeroes or -1's. But there is huge swaths of trails missing. It doesn't appear to log or at least keep any NR driving data unless it is NR only. If it's mixed NR/LTE, then the only thing appearing in the trails is LTE.

I am also getting this error.  So it is seeing invalid TAC values, but then when I look at logs, it's like it's deleting them. 

Robert

Update - I figured out the issue and it should be resolved now. If you go into the Beta Crew Settings, you should be able to set your upload timestamp back and reupload the data. 

Let me know if it works for you now. 

On 5/23/2022 at 8:46 PM, S4GRU said:

Actually, I notice it says whole clusters were skipped because of invalid TAC values.  It says "File exported for inspection."  I do have Log Sites with Missing TAC checked.

Robert

Do you see the TAC displayed as -1 in the exported file or is it blank/0? I took a look at your upload on Monday at roughly 12:30 and I’m not seeing any non-valid TAC values - not even -1s, 0s or blanks…

Hey @mikejeep - I just shot you a diagnostic from my new Galaxy Flip last night. I’m not able to see Verizon n5 in-app when connected to a midband anchor. 

7 minutes ago, S4GRU said:

Actually, I notice it says whole clusters were skipped because of invalid TAC values.  It says "File exported for inspection."  I do have Log Sites with Missing TAC checked.

Robert

Let me take a look tonight. 

On 5/21/2022 at 12:11 PM, mikejeep said:

Let me know when you get your side ready, no rush. The current alpha build I'm working on is half-broken as I try to implement this new TelephonyCallback stuff I'm working on.

Support for the -1 TAC is good to go now, so I'm ready whenever you are!

On 5/20/2022 at 10:29 PM, S4GRU said:

Many of these sites I am uploading are for sites that do not exist, yet.  Although, I suppose I could go into NR only mode every time I connect to a new site, and then switch back, allowing all the TAC NR trails that occur to now have a home.

Ideally, I would love to ne able to add the TAC's myself.  I have the NR Trails CSV file downloaded, and I see all the TAC-less NR entries.  Is there any way I can edit and manually upload them myself?  Maybe create a portal for such an upload?  Or at least give me a way to create at least one manual entry for every new site?

I am still thinking about both of these.

My idea is to try to match points without a TAC to an existing site if possible. In the case an existing site can’t be found, I can list the TAC as unknown and allow the user to enter an “unconfirmed” TAC until someone maps the site correctly (with a TAC). Then the “unconfirmed” TAC will be overwritten with that TAC. 

How does that sound?

1 hour ago, thisischuck01 said:

I believe there was some conjecture regarding this antenna (FFVV-65A-R2-V1) being used on sites with a height and/or weight limitation. 

Weight limitation is a super common reason for using smaller antennas, however it doesn’t look like there is a weight limitation on this setup since it is on a rooftop. Weight limitations are much more common on utility poles, tall pipe mounts, etc.

Another possible reason for the shorter antenna is site density. Using a higher-gain antenna can cause sector overlap (i.e. degradation of SNR and increased noise floor) if neighboring sites are close by. You can usually use a combo of mech/etilt to control the range of these higher-gain antennas, but that sometimes causes problems with vertical coverage. These problems are especially bad on sites with higher RAD centers as you’re effectively pointing the already-narrow beam into the ground. We run into these issues a lot in urban RF planning…

5 hours ago, T-MoblieUser207 said:

Its also not the tall Commscope version seen on Nokia builds in Nokia markets, so I wonder why the difference. 

Lower gain figures in exchange for increased vertical beamwidth. 

1 hour ago, mikejeep said:

No problem, I hadn't looked too closely but you are right, 0 is valid (and recognized by the app as such) -- internally, I set it to -1 unless a valid value is returned anyway, so that shouldn't be too bad.

Let me know when you get your side ready, no rush. The current alpha build I'm working on is half-broken as I try to implement this new TelephonyCallback stuff I'm working on.

Awesome!

26 minutes ago, mikejeep said:

Sure.. or it can just leave it blank or zero, whatever is easiest for you.

I’d recommend against using 0 because It’s actually possible to assign a TAC of 0 (in LTE the range is 0 to 65535 and in NR the range is 0 to 16777215).

My thought process with -1 was that some sort of error could in theory cause a blank or an empty value to end up in an upload file. A -1 feels a bit more intentional. 

I’ll see if I can get the backend up and ready to go this weekend (hopefully before the app update is released). 

2 hours ago, mikejeep said:

If the TAC is missing, an entry is still recorded in the log, but it would not be included in uploads.. so you could probably manipulate a trail log export to add the data to the map if you were able to nail down the sites without the TAC.

Could we send the TAC as -1 if it’s invalid? Then, if there’s and existing site that matches the other info, I could match the web data entry up with it (despite the TAC being absent). 

On 5/8/2022 at 8:19 AM, S4GRU said:

I sent in two Diagnostic Reports from my LG V60 last night.  After an Android 12 update, it now will not show NR TAC on the screen nor in the logs for NR connections when connected to NR and LTE simultaneously.  It does show LTE TAC just fine.  Since it's not in the logs, it will not map out my NR results when missing TAC.  I missed out on hundreds of miles of NR mapping. 

@mikejeep does SCP send NR points on upload if they’re missing a TAC?

4 hours ago, S4GRU said:

OK, I think I have given up on the TAC issue on my LG V60 and just resigned to get a new device. 

If you could hold off through the weekend, I’m going to take a look at your uploads tonight. I might be able to edit the software on my side to match TACless data to an existing site with other matching attributes. 

I’m not sure how I’m going to handle sites not already in the DB if TACless data is uploaded though…

While Mike resolves the TAC logging issue, if you tell me what the TAC should be and when you uploaded the data, I can manually add your trail entries to the database. 

1 hour ago, clbowens said:

Well what's weird about that is off-loading you to a network...that you're trying to shut down.  🙂  I would think you would want to keep as many people off as possible, to help you shut it down.

The two big reasons for this are site density disparities and the complexity associated with the spectrum transition  

For example, consider a hypothetical town where Sprint has 5 sites with low RAD centers and T-Mobile has 3 sites with high RAD centers. Let’s assume neither carrier has a coverage problem (due to the difference in site placement/height), and that each T-Mobile site is broadcasting 20x20 MHz and each Sprint site is broadcasting 10x10 MHz.

Right now, your total on-air spectrum volume in the town is 3 sites x 3 sectors/site x 40 MHz (T-Mobile) + 5 sites x 3 sectors/site x 20 MHz (Sprint) = 660 MHz-sectors.

If you flip all of the spectrum over to T-Mobile today, your total on-air spectrum volume is 3 sites x 3 sectors/site x 60 MHz = 540 MHz-sectors. 

As you can see, in this example, there’s a significant capacity drop (18.18%) if you don’t offload onto Sprint sites. Plus, this example assumes that all Sprint spectrum can be flipped over to T-Mobile, which isn’t necessarily true. The 5x5 800 MHz carrier won’t be used by T-Mobile, and in areas where T-Mobile hasn’t deployed 2500 equipment, 2500 MHz spectrum can’t be moved over either. 

Going back to the earlier example, if we assume the Sprint sites are broadcasting 5x5 L1900 and 5x5 L800, only 5x5 MHz of spectrum can be moved over to T-Mobile. So, if all the traffic were pushed over T-Mobile, the on-air spectrum volume would really be 3 sites x 3 sectors/site x 50 MHz = 450 MHz-sectors. That’s a 31.81% decrease in capacity. Even worse. 

3 hours ago, clbowens said:

And a LOT of times sit on Sprint network when I have great T-Mobile signal.  I don't understand.

This is likely due to load balancing.

In certain areas, we’ll set up mobility parameters to release users to a less loaded cell, even if it’s RSRP is lower (think NR event A4). These sorts of configs can get super complex due to degradation in SNR or BER, though (especially for cells on the same channel). 

2 hours ago, S4GRU said:

I roamed on VZW LTE the other morning in my home near Olympia on my LGV60 when the local Tmo tower went down in the storm.  Never seen that before. When did Tmo and VZW have a roaming agreement?

Robert

VZW CDMA-less devices have been roaming on T-Mo WCDMA/HSPA for some time now. I suppose it’s about time T-Mo users were able to use VZW LTE. 

2 hours ago, xmx1024 said:

Happen to snag a pic?

I did not unfortunately. 

1 hour ago, xmx1024 said:

also tough to do as they support beamforming as well.

The software can and does account for antennas that support beamforming - I just don’t have the antenna files.  

On 3/23/2022 at 2:55 PM, PedroDaGr8 said:

By the way, which frequency is this calculated with? I am wondering if they are optimizing some things for n41 since that is becoming their primary data channel. 

PCS. I don’t have AAHF or AEHC radiation patterns so I can’t simulate 2500 coverage unfortunately. 

15 minutes ago, PedroDaGr8 said:

What does satellite mean in this context? Also, that is pretty bad when it comes to modulation. 

 

Just the map canvas. It’s easier to see where mall/big box stores are on a satellite map than a roadmap (at least in my opinion). 

2 hours ago, PedroDaGr8 said:

T-Mobile has already pulled the Sprint equipment from the top of the Totem Lake Motel 6. We will see soon how bad things get signal-wise in that area. 

I actually have those Commscope antennas in inventory now plus a bunch of SignalCheck drive test data in that area, so this should be pretty accurate:

https://imgur.com/a/j4959Tl

Mostly QPSK/16QAM.