Jump to content

OpenSignalMaps Founder requests feedback from S4GRU Members

bgill5

By bgill5
in General Topics

 Share

Recommended Posts

bgill5 Member Level: Smoke Signals

bgill5

Posted
Posted

Founder of OpenSignalMaps here,

 

Not sure if you have seen our app at all, but we are big fans of your site. We'd be very interested to hear if you find our app useful for tracking the 4G roll out or if not - what could we do to make it better? We're open to any constructive criticism at all & are constantly working to refine both the app and the information on the website.

 

We're currently working on an overhaul of our android application which we are pretty excited about - should be out by the end of October.

 

Brendan

  • Like 11
Link to comment
Share on other sites
boomerbubba Member Level: eHRPD

boomerbubba

Posted
Posted

Founder of OpenSignalMaps here,

 

Not sure if you have seen our app at all, but we are big fans of your site. We'd be very interested to hear if you find our app useful for tracking the 4G roll out or if not - what could we do to make it better? We're open to any constructive criticism at all & are constantly working to refine both the app and the information on the website.

 

We're currently working on an overhaul of our android application which we are pretty excited about - should be out by the end of October.

 

Brendan

 

1) I suggest that you lose the "towers" imputed mapping function, which is wildly inaccurate disinformation. We have to spend a lot of time debunking it for newbies here who see this stuff on your site and believe this is where the towers actually are.

 

2) Fix the log your app produces locally (I think it is called BSLocationLog.csv) to include useful information. Right now, its lat/lon coordinates are not current, it conflates the CDMA base station IDs with LTE signals giving the false impression that the LTE signal and the concurrent CDMA connection are coming from the same place, and garbles the signal strength data into some muddled metric that does not relate to raw data collected on the Android.

 

If you provided a log file with accurate signal strength for LTE signals (in dBm RSRP), along with accurate and timely coordinates, that would be useful information. Including an ID that actually corresponds to the the LTE radio, such as the Serving Cell information available in the LTE Engineering screen of the Galaxy S 3, would be a huge plus.

 

As it is, I tried using OpenSignalMaps for logging, and uninstalled it.

  • Like 5
Link to comment
Share on other sites
newboyx Member Level: 4G WiMax

newboyx

Posted
Posted
Founder of OpenSignalMaps here,

 

Not sure if you have seen our app at all, but we are big fans of your site. We'd be very interested to hear if you find our app useful for tracking the 4G roll out or if not - what could we do to make it better? We're open to any constructive criticism at all & are constantly working to refine both the app and the information on the website.

 

We're currently working on an overhaul of our android application which we are pretty excited about - should be out by the end of October.

 

Brendan

I would think this would make a great discussion in a separate thread. ;)

 

Sent from my still LTEless Evo 4G LTE...

Link to comment
Share on other sites
jefbal99 Member Level: LTE Advanced

jefbal99

Posted
Posted

1) I suggest that you lose the "towers" imputed mapping function, which is wildly inaccurate disinformation. We have to spend a lot of time debunking it for newbies here who see this stuff on your site and believe this is where the towers actually are.

 

2) Fix the log your app produces locally (I think it is called BSLocationLog.csv) to include useful information. Right now, its lat/lon coordinates are not current, it conflates the CDMA base station IDs with LTE signals giving the false impression that the LTE signal and the concurrent CDMA connection are coming from the same place, and garbles the signal strength data into some muddled metric that does not relate to raw data collected on the Android.

 

If you provided a log file with accurate signal strength for LTE signals (in dBm RSRP), along with accurate and timely coordinates, that would be useful information. Including an ID that actually corresponds to the the LTE radio, such as the Serving Cell information available in the LTE Engineering screen of the Galaxy S 3, would be a huge plus.

 

As it is, I tried using OpenSignalMaps for logging, and uninstalled it.

 

Great suggestion here, I'd expand to all the signals, log the 1X, 3G, and LTE separately and report on each individually.

  • Like 1
Link to comment
Share on other sites
S4GRU Member Level: LTE Advanced

S4GRU

Posted
Posted

Sad part is I spent way too long trying to find out why my moderate option wasn't available in Tapatalk before I realized that I wasn't on the forum that I moderate.

Sent from my still LTEless Evo 4G LTE...

 

HAHAHAHA! That's too funny.

 

Robert

Link to comment
Share on other sites
bgill5 Member Level: Smoke Signals

bgill5

Posted
  • Author
Posted

boomerbubba - thanks for the detailed comments. Let me address them one by one:

 

1) I understand your frustration with this. We're working on a series of accuracy improvements as we speak that will utilize a lot more accumulated information to improve the accuracy. There are a lot of challenges with this data and its a work in progress but we're working towards a longer term goal and I think its worth it. We are looking at better ways of communicating this to users, one of which is a confidence rating which takes into account the amount of data we have on a given tower and a series of different parameters.

 

2) Can you clarify what is meant by "lat/lon coordinates are not current"? You mean that the location records simply relate to older locations rather than the current? If so, would like to look into this in detail.

 

For your other comments we are very interested in getting all radio information available. As we understand it there are some difficulties though and not all handsets provide access to LTE signal strength and LTE tower information. Are you getting different results? We've found methods available on some devices but its not consistent across handsets and our users are on a lot of different models.

 

Please keep the comments coming!

Link to comment
Share on other sites
boomerbubba Member Level: eHRPD

boomerbubba

Posted
Posted

boomerbubba - thanks for the detailed comments. Let me address them one by one:

 

1) I understand your frustration with this. We're working on a series of accuracy improvements as we speak that will utilize a lot more accumulated information to improve the accuracy. There are a lot of challenges with this data and its a work in progress but we're working towards a longer term goal and I think its worth it. We are looking at better ways of communicating this to users, one of which is a confidence rating which takes into account the amount of data we have on a given tower and a series of different parameters.

 

2) Can you clarify what is meant by "lat/lon coordinates are not current"? You mean that the location records simply relate to older locations rather than the current? If so, would like to look into this in detail.

 

For your other comments we are very interested in getting all radio information available. As we understand it there are some difficulties though and not all handsets provide access to LTE signal strength and LTE tower information. Are you getting different results? We've found methods available on some devices but its not consistent across handsets and our users are on a lot of different models.

 

Please keep the comments coming!

 

As for the lat/lon coordinates, my experience was limited to one day testing. When I looked at the logs, it did not appear to me that the lat/lon coordinates were being updated for the actual location of each signal record even though I had been moving around. Identical coordinates just seemed to repeat for many records in a row. Maybe this was a bug, not bad design.

 

Going forward, tf you do separate the conflated records for different type of data connections, there certainly is a possibility that not all fields can be populated for all records. And the raw values for dBm are calculated and reported differently for different connection types (RSRP vs RSSI), etc.) So any generalized reporting would have to accommodate those and distinguish them in the logs.

 

I understand your difficulties getting the LTE signal data. AFAIK, Google's Android telephony API still does not have a neat, standardized method to expose them. So I guess until that happens, app developers have to dig into the non-standard APIs offered by different OEMs. (I have seen some callback methods to the hidden APIs described as a workaround by some app developers, but I think they are discovered more than advertised by the OEMs.)

 

I thought you must at least be doing that kind of workaround for LTE signal strength on major flagship handsets like the Samsung GS3 and transforming that value into your generalized column for signal. Because there are values for signal in those logged LTE records. Are they really just coming from the concurrent CDMA connection? That is even worse. Wrong data is not better than null data when the content is unknown.

 

I also understand that there is no standard ID value and location per base station available in the Android API for a carrier's LTE radio. These values, which are not well understood, seems to be displayed differently within the hidden menus of different OEMs' implementations.

Link to comment
Share on other sites
bgill5 Member Level: Smoke Signals

bgill5

Posted
  • Author
Posted

Thanks again.

 

We'll look into the issue with lat/lng co-ords and see what we can dig up.

 

You are right about there being no official android APIs for LTE signal/towers but we have fished up some of the unofficial methods.

 

We should mark clearly if a signal is CDMA or LTE and store it separately Initially it wasn't clear which Android was reporting but as it transgressed we realized it was CDMA and so were aware of that in our log data. However, we were guilty of thinking about it from our perspective rather than as a tool for users to log and export their own data so we need to rectify that asap.

 

There is also an ongoing issues with the standard GSM/CDMA signal strength on a lot of the flagship Galaxy devices which you are all probably aware of. We've lobbied hard with contacts at Google/Samsung to fix but its taking time. We would appreciate any interested parties to weigh in here: http://code.google.com/p/android/issues/detail?id=18336

 

Let us know if there is any more feedback.

 

Brendan

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

×
 Share
Go to topic listing

  • large.unreadcontent.png.6ef00db54e758d06

  • gallery_1_23_9202.png

  • Posts

    • Trip
      SignalCheck Beta Crew Forum

      By Trip · Posted

      Just installed the update, and it's good!  As you recommended, I turned off both TA adjustments, and turned on displaying it when it's zero.  The value is basically spot-on.  It's bouncing between 18 and 19 for the Cameron Valley site, and it is in fact between 0.87 and 0.92 miles, as displayed in the app.  This is probably a better estimate of the TA values than any other device I own provides. As far as the -44 goes, I'll have to take it out and verify that it no longer records those cases. If this device didn't have that annoying reset problem, and got the Android 14 update (and in so doing supported TA on NR and continued to allow band locking), it would easily be the best device I own.  Easily.  And would be the device I standardize on for the 5G era.  I'll probably have to wait for a future device to come out with Android 14 and then see what happens. And I know I didn't have to, but I love SCP.  It is my primary tool for tracking the goings-on of the various networks and is very easy to use and work with across my 10 phones.  I am very happy to send a token of my appreciation your way now and then.  Thanks again! - Trip
    • mikejeep
      SignalCheck Beta Crew Forum

      By mikejeep · Posted

      Sorry, I misread your message -- yes, the app would show 0 if an invalid value was being reported. I don't think I had any MediaTek devices myself, but the beta testers have had a decent variety of devices over the years.   Sorry, I didn't word that very well in my last post -- I added an option to control display of LTE TA when it is 0. By default it will now be hidden (sadly a lot of devices do not show it) but anyone who wants to display it can adjust accordingly. There will be 3 user-selectable options related to LTE TA now -- the existing correction option, correction on LTE-TDD (which is independent/in addition to the existing correction option), and TA:0 display. In your case, I'd disable the TDD option and enable the TA:0 option; the defaults will be the opposite of what I think you need.   You did not have to do that, but I sincerely appreciate it, thank you! Beta update is rolling out now, let me know how it goes.
    • Trip
      SignalCheck Beta Crew Forum

      By Trip · Posted

      In order: This is very helpful to know.  Thanks. That makes a lot of sense, though it's showing me zero rather than nothing; it looks like if it's calculating a negative number, I'm seeing zero instead.  It makes me wonder how many devices you've tested against which use the MediaTek chipset.  This is only the second one I've used, and the first one was very, very old (didn't have B41), so it's possible that the MediaTek chip doesn't need the correction while others do.  Separately, I doubt that a real world case will ever see 1282, so I imagine any value above 1281 could be ignored. I would ask you to please not hide TA values of 0, or if you hide them by default, add an option to not hide them.  I am aware that, for example, the S22 doesn't report a valid TA value and always reports zero, but zero is a legitimate value and is useful to know when trying to identify sites. I'll look forward to your impending update, and I'm going to send along another donation if I can find the link.  Thanks so much, as always!  - Trip
    • mikejeep
      SignalCheck Beta Crew Forum

      By mikejeep · Posted

      I received the reports, thanks! You didn't catch it happening (it captures the diagnostics as soon as you hit send or long-click the connection banner on the main screen), and I had sent you an e-mail to clarify which value was -3.. but your screenshots confirmed my hunch that you meant RSRQ!   I know exactly what is happening here. Somewhere along the way, I learned that TD-LTE bands (33-53) needed a TA correction of -19 applied, and I confirmed it on several devices. Perhaps that is no longer universally true.. but what you're seeing SCP display matches that correction. Below 19 you see nothing, at 19 you see 0, and above that you see TA-19. The upper limit is 1282, which is why you see 1263. Your phone must report 1282 when the TA is unknown, which is not technically safe but I can work around that. Funny enough, I had a change to TA coming in the next update that had nothing to do with your issues.. TA:0 will be hidden moving forward, since several devices report 0 when it cannot be identified. I'll have an app update out shortly that addresses all of this, let me know how it works for you and thanks for the detailed feedback!
    • Trip
      SignalCheck Beta Crew Forum

      By Trip · Posted

      Mike, We ended up going out this morning to do errands in spite of the tropical storm.  I locked the phone on LTE B41, turned off the TA correction checkbox, and watched it carefully while out and about.  I have four screenshots for you. https://imgur.com/a/kCPTCnB First, I happened to get a screenshot of it doing the -44 dBm thing.  I also tried to send you at least one set of diagnostics showing the -44 dBm but I don't know where precisely in the process it collects the diagnostics.  Hopefully there's something useful in them. The rest of the screenshots are far more interesting.  All three were taken within seconds of each other in the CVS parking lot.  The phone's diagnostic screen shows a TA of 17, and oddly, the SCP diagnostics screenshot also appears to show a TA of 17.  But SCP's normal display is showing 0.  Not entirely sure what to make of that.  It looks like SCP won't show me a value other than 0 until I hit about 19 according to the phone diagnostic screen. It also appears that when SCP is showing a TA of 1263, that's the equivalent of a null value for the TA--no TA is calculated.  The phone diagnostic screen appears to show just "12" when that's happening; the SCP diagnostic screen shows 1282 in the TA section when that happens, a difference of 19, which is highly convenient given what I noted above about the TA value.  (I can't test that the phone diagnostic screen is limited to two characters and is thus truncating 1282 to just "12" as I suspect given where I am right now.  Had I known to be looking for it, I'd have tested in the middle of nowhere yesterday.) Anything catch your eye?  Anything I can do to help more?  - Trip

  • Recently Browsing

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