Jump to content

RAvirani

S4GRU Staff
  • Posts

    3,455
  • Joined

  • Last visited

  • Days Won

    159

Everything posted by RAvirani

  1. I’ll take a look when I get back to my hotel tonight. Busy at the US Open !
  2. Hey Mike, I’ve noticed a location bug several times recently—it seems like the location reported by SCP lags my actual location by several minutes. The outcome is something similar to the “stuck location” bug we used to have. Do you have any idea why this might be happening? @S4GRU and @Trip have see this recently as well, I believe.
  3. Are any SCP users heading to the Pacific Beach area any time soon? We don’t have much SCP data on site 351408/351409 (especially along 109 and Moclips highway) and I’m trying to decide whether or not to make a trip out there!
  4. Sounds like an awesome project—keep us posted on how it’s going! Also—if you’re able to figure out logging, I can work with you to get the data uploaded to SignalCheck.
  5. I’ve also noticed that when I click on the number of points to upload data, the display just sits at pending, even after the upload is completed.
  6. I’ve actually pulled two gigs on that site. 1.6 more recently. https://imgur.com/a/1t7cVVg I’ve pulled multi-gig at the site on the 148th street exit off 520 as well.
  7. 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.
  8. Do the uploaded n7 entries have the correct NR-ARFCN?
  9. 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?
  10. 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. 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
  11. Wait - to clarify are you removing the display of pending web data points? I do really like that feature… 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.
  12. Oh awesome! Is there a link you could provide so I could take a peek?
  13. SCP doesn’t appear to work with Dish service. Dish SIMs contain two virtual SIMs - SIM 1 camps on AT&T and SIM 2 connects to Dish NR when available. SCP knows the phone is connected to NR (it shows connected to NR in the top right corner), but the app only displays AT&T LTE information. Screenshots: https://imgur.com/a/48PuJ1b I send a diagnostic report - any ideas Mike?
  14. Almost the exact same thing happened on my Verizon Galaxy Flip a couple days ago.
  15. @mikejeep have you had a chance to look into this issue yet?
  16. The South Sound’s network is a lot more sparse which maker integration much simpler. I’m guessing these sites (with the exception of #1) are delayed for cluster optimization. Optimizing things like tonnage config, etilt, mobility/HO params, etc is complex in areas with a high number of neighbors. Also, if nearby new sites are slated to come online in the near future, it often makes more sense to push the new config when all eNBs are ready to go. Otherwise, you’re essentially designing the network twice for a given area. I’ll get back to you on site #1.
  17. Here’s a demo: https://imgur.com/a/F4H04XN
  18. Red is active coverage, black is currently permitting (covering imminent) and light blue is roaming.
  19. I’d recommend deleting the bad sectors. This way, next time the area is mapped, the data will look good - the sites will remain where you located them (even if you delete all the sectors) and the new sector coverage polygons will be accurate.
  20. I can try to isolate the “bad” points in each sector, although if you also uploaded a lot of good data at around the same time, that could get really time consuming. Alternatively, you can delete the bad sectors and remap them next time you’re in the area… I’d definitely leave the sites in their correct locations.
  21. That is super bizarre - definitely a @mikejeep question. If you give me a list of the AT&T sites, I can try to roll them back…
×
×
  • Create New...