mikejeep

Well these aren't what I wanted to wake up to.. none of my test devices are having these issues and a couple are rooted. I'll go see what I can come up with, but for now nobody else should bother updating yet. If I can't find those crash reports I'll reach out to you guys. -Mike

Just pushed out another beta, please let me know if that LTE frequency display is fixed. It was likely only observed on devices that weren't getting the EARFCN natively. Finished up a lot of other loose ends that I had been working on too. Did somebody say neighbor LTE bands... Getting very close to tackling everything I had planned for the next public update. Thanks for all of the feedback!! -Mike

Hmmm clearly I broke something with "LTE xxxxx" display. You're all still seeing band information in the provider line so it's not your device. I gutted those routines so I expected some hiccups. I overhauled a lot of code; much of this used to be hard-coded, now it's dynamic. I'll look into it tonight! -Mike

You should still see whatever you had before, except some T-Mobile users who will need EARFCN data in order to see a band. Many users will now see more info. Where is AWS missing from? Are you seeing any EARFCN stuff (guessing not, on a Samsung)? Is it showing any band info at all? -Mike

Probably not, but we do things our own way here! The site I used for my LTE-related calculations is this one: http://niviuk.free.fr/lte_band.php -Mike

The only 10x10 indicators implemented at the moment are GCI-based B25 second carrier ones. I did see the EARFCNs you have shared but I haven't gone down that road yet. -Mike

Fingers have been crossed but I haven't seen or heard anything! -Mike

This is why we beta test.. oops! That was not intentional. It was very late and I wasn't paying attention when I finished up some of the new EARFCN stuff. It will go back to 800 next round. It doesn't impact any logs, that's just a display element. -Mike

Great catch, thank you! I discovered that I didn't have the "even" third character requirement programmed correctly for the B41 Mini Macros or small cells. -Mike

The widget is doing it sometimes too. Did it start on Android 7 for you? I also noticed that my Pixel takes a long time (over a minute sometimes) to get a signal update if it's sitting still. That's not the app, that's the phone not refreshing anything (presumably because the data isn't changing significantly). -Mike

Oops, forgot I was testing that. On Android 7+, it may become a necessity if you have an Alert enabled. If no text is displayed, an exception is occurring and the Alert does not fire. Still exploring this. Are you saying the earfcn is not always accurate on these ALU sites in Samsung territory? Or in general? Are you seeing inaccuracies via the root method or the native Nougat routine? -Mike

Yes, there is a thread discussing it in the Premier Sponsor section. -Mike

I agree that it's good to know and seems to be fluid, I just need to figure out how to best display it. Going to continue my discussion further in that Premier thread lilotimz mentioned.. -Mike

First I'm hearing of it.. anyone else? I haven't touched anything in that part of the app recently.. -Mike

Ah.. but as far as SCP goes, is that something that warrants some sort of special indicator beyond "MM"? Are these sectors confirmed by anyone else out there? I haven't seen any other reports of them besides what I observed at Fenway. -Mike

What do you mean by "get the RSRP value back for known sites"? You lost me.. Got it, thanks! I'll just label them MM's for now unless there's something special about this. I see how that could be useful when looking through your logs, but I think there are more cons than pros for this one. Like Flompholph said, Google limits how many geo-queries you can do; that's one reason why SCP won't query a BSL if the app isn't in the foreground -- no need to burn up limited resources. And it triggers more data transfer than one might expect. You can use Fusion tables or scripts on the raw data for now, I agree that is a better option. Adding an address field would cause a huge increase to the database size, since every sector would get a text address. Many people have many tens of thousands of database entries. -Mike

I won't be back at my desk for a couple more days, but wanted to share this.. might be additional MM sectors I need to add, perhaps: http://s4gru.com/index.php?/topic/5454-network-vision-and-spark-earfcn-logging-thread/page-15&do=findComment&comment=509464 -Mike

Spent some quality time watching the Red Sox this weekend, took some sneak peeks at the latest SignalCheck beta and discovered 4 new sectors and EARFCNs I didn't have noted (see below). I'm guessing B41 Mini-Macros are deployed at Fenway with more sectors than usual? Or is it something else? -Mike

Already started working on something along those lines, great minds think alike! I have a busy few days coming up but I should have another update ready by mid-week. I appreciate everyone's feedback and suggestions, it is a tremendous help.. please keep it coming. EDIT: Forgot to mention, I reached out to Samsung about the EARFCN issue on Friday afternoon, and received a response fairly quickly. They are forwarding my concerns to their internal dev team and I was promised a follow-up. We'll see.. -Mike

Samsung never seems to make things simple.. if it was returning nothing, the app would recognize this and not display anything. I like your idea, but that presents more issues. Is it broken on ALL of their devices? And an API level covers multiple OS releases.. for example, API 25 covers all of Android 7.1 so far, which not only includes 7.1, 7.1.1, and 7.1.2, but a total of 25 different AOSP releases for the Pixel to date. And if I block API 24, but they push out API 25 and it's still broken, then I scramble again. Anything is possible, just need to figure out what the "best" approach is. I'd prefer to come up with a way to implement something that immediately starts showing data once Samsung fixes things on its end. I think I have an idea that will work but we'll see. -Mike

Hah! Touche, Samsung.. the app displays it because those are valid EARFCNs for LTE band 1. I could come up with an ugly hack, perhaps ignoring very low values on certain PLMNs. I hate this company.. -Mike

The API method should be noticeably faster (those of you using the root method have undoubtedly noticed that you have to wait for the first screen update after you connect to a new site to see EARFCNs) and consume less resources. You do need Android 7.0+ (and the OEM has to have it set up properly of course). I am still working on a warning notice if your device appears to be getting EARFCNs from the native API but the root method is still enabled. There is no adverse affect in the app other than wasting unnecessary system resources. I like your fallback idea, it just might take some time to implement. I am hesitant to rely on pulling band info out of the database because if a site's configuration is changed for whatever reason, that could throw things off. SCP minimizes the number of reads and writes to the database so a little more complicated than one might expect. Right now, the app tries the old-school HTC EARFCN routines first, then the root/modem method, then the new native API 24 routine. If the data is deemed to be valid, each subsequent routine overwrites anything that had been already obtained, so even if all 3 methods work on a device, the user will only see the results of the native method (theoretically the most accurate). If the root/modem method works, but the native method doesn't, the modem data is what will pass through. That is my goal.. chasing down GCI patterns might be fun for some people, but I'm tired of it! I want to iron out all of the kinks in the 3 steps noted above and make sure everyone is getting valid EARFCN data before taking the next step. I really want to make sure that source data is accurate before going too far with it. It's a pretty basic implementation right now and I'm sure it will need some tweaks. -Mike

This was a huge reason I wanted to target a newer API.. it's a fantastic feature for an app like this. Will be much easier to use multiple devices. Samsung devices being difficult?! No way, what a surprise. Ugh! As someone else already mentioned, that is on them. It's only a 7.0+ feature so it is fairly new. Well that's why we are beta testing. It shouldn't be showing you any EARFCN information if it's invalid.. what are you seeing? I don't have a Samsung on Android 7 to test myself. -Mike

Well it happened.. another update just pushed out, 3 days in a row! Still needs some polish, but the latest bugs are squashed.. and there's a couple new goodies.. -Mike

I haven't tackled that yet but it's coming shortly. I know that was the NID range for Airave 2.5; just curious, is it the same for the 3.0? I believe this has been fixed, when the next update comes out please try it on your Photon! Yeah I was able to reproduce it myself also. I knew that fix was too easy.. hopefully tonight I can get that tackled. No promises on 3 days of app updates in a row, but who knows.. -Mike