-
Posts
109 -
Joined
-
Last visited
-
Days Won
1
Content Type
Profiles
Blogs
Articles
Media Demo
Gallery
Downloads
Events
Forums
Posts posted by sensorly
-
-
Yup, there was a backlog of mapping according to "Sensorly" User
We'll be adding capacity to our servers in April to bring the update time down.
- 2
-
Exactly, thanks. I'll take a look
- 2
-
Quick update : all of the backlog of data is processed and drawn at least at some zoom levels. Except for 25% of the CDMA data which is 4.5 days late at most.
<table border="1" style="font-family: Times;"> <tbody> <tr> <th> Worker</th> <th> Last updated</th> <th> Highest id</th> <th> Time delta</th> </tr> <tr> </tr> <tr> <td> counters.last_reports.CDMA.COVERAGE.0</td> <td> 2013-03-27 08:22:52.0</td> <td> 54168312</td> <td> 4.48 days</td> </tr> <tr> <td> counters.last_reports.CDMA.COVERAGE.1</td> <td> 2013-03-27 08:18:08.0</td> <td> 73104784</td> <td> 2 seconds</td> </tr> <tr> <td> counters.last_reports.CDMA.COVERAGE.2</td> <td> 2013-03-27 08:18:08.0</td> <td> 73104704</td> <td> 4 seconds</td> </tr> <tr> <td> counters.last_reports.CDMA.COVERAGE.3</td> <td> 2013-03-27 08:18:07.0</td> <td> 73104759</td> <td> 2 seconds</td> </tr> <tr> <td> counters.last_reports.GSM.COVERAGE.0</td> <td> 2013-03-27 08:21:31.0</td> <td> 73112429</td> <td> 5 seconds</td> </tr> <tr> <td> counters.last_reports.GSM.COVERAGE.1</td> <td> 2013-03-27 08:21:31.0</td> <td> 73112344</td> <td> 6 seconds</td> </tr> <tr> <td> counters.last_reports.GSM.COVERAGE.2</td> <td> 2013-03-27 08:21:28.0</td> <td> 73112234</td> <td> 5 seconds</td> </tr> <tr> <td> counters.last_reports.GSM.COVERAGE.3</td> <td> 2013-03-27 08:21:31.0</td> <td> 73112334</td> <td> 6 seconds</td> </tr> <tr> <td> counters.last_reports.LTE.COVERAGE.0</td> <td> 2013-03-27 08:21:31.0</td> <td> 73112739</td> <td> 0 seconds</td> </tr> <tr> <td> counters.last_reports.LTE.COVERAGE.1</td> <td> 2013-03-27 08:22:52.0</td> <td> 70917597</td> <td> 12.31 hours</td> </tr> <tr> <td> counters.last_reports.LTE.COVERAGE.2</td> <td> 2013-03-27 08:18:17.0</td> <td> 73105057</td> <td> 3 seconds</td> </tr> <tr> <td> counters.last_reports.LTE.COVERAGE.3</td> <td> 2013-03-27 08:18:15.0</td> <td> 73104961</td> <td> 3 seconds</td> </tr> <tr> <td> counters.last_reports.WIFI.COVERAGE.0</td> <td> 2013-03-27 08:18:09.0</td> <td> 73104570</td> <td> 9 seconds</td> </tr> <tr> <td> counters.last_reports.WIFI.COVERAGE.1</td> <td> 2013-03-27 08:18:09.0</td> <td> 73104569</td> <td> 9 seconds</td> </tr> <tr> <td> counters.last_reports.WIFI.COVERAGE.2</td> <td> 2013-03-27 08:18:09.0</td> <td> 73104562</td> <td> 10 seconds</td> </tr> <tr> <td> counters.last_reports.WIFI.COVERAGE.3</td> <td> 2013-03-27 08:18:08.0</td> <td> 73104564</td> <td> 9 seconds</td> </tr> <tr> <td> counters.last_reports.WIMAX.COVERAGE.0</td> <td> 2013-03-27 08:20:21.0</td> <td> 73109445</td> <td> 0 seconds</td> </tr> <tr> <td> counters.last_reports.WIMAX.COVERAGE.1</td> <td> 2013-03-27 08:20:22.0</td> <td> 73109476</td> <td> 0 seconds</td> </tr> <tr> <td> counters.last_reports.WIMAX.COVERAGE.2</td> <td> 2013-03-27 08:20:21.0</td> <td> 73109445</td> <td> 0 seconds</td> </tr> <tr> <td> counters.last_reports.WIMAX.COVERAGE.3</td> <td> 2013-03-27 08:20:22.0</td> <td> 73109484</td> <td> 0 seconds
</td> </tr> </tbody></table>
-
There is is plenty of good info out there regarding iOS Private API Documentation that will allow you to using private iOS functions to collect signal strength and/or mobile network.
I found plenty for iOS 3 but I never found anything for iOS4 ,especially for CDMA.
Any pointers you'd like to share via PM ?
-
Was any data lost during that period?
No, it was just being added to a database until it could be processed. Once the data reaches us, it can't get lost.
- 7
-
We've had an iOS app out for a while but it can't collect signal strength or the type of mobile network, due to Apple restrictions.
- 2
-
Sensorly hasn't updated on most zoom levels in 2 days now.
It turns out half our import engines went down for 3 days and our monitoring missed it. It's catching up.
The following shows how far back in importing the data we are. Add another day or so to catch up with redrawing the maps. Bascially 25% of the CDMA data is backlogged 5 days.
<table border="1" style="font-family: Times;"> <tbody> <tr> <th> Worker</th> <th> Last updated</th> <th> Highest id</th> <th> Time delta</th> </tr> <tr> </tr> <tr> <td> counters.last_reports.CDMA.COVERAGE.0</td> <td> 2013-03-25 21:04:00.0</td> <td> 45076676</td> <td> 4.91 days</td> </tr> <tr> <td> counters.last_reports.CDMA.COVERAGE.1</td> <td> 2013-03-25 21:09:33.0</td> <td> 66539273</td> <td> 12.92 minutes</td> </tr> <tr> <td> counters.last_reports.CDMA.COVERAGE.2</td> <td> 2013-03-25 21:08:37.0</td> <td> 66564618</td> <td> 5.25 minutes</td> </tr> <tr> <td> counters.last_reports.CDMA.COVERAGE.3</td> <td> 2013-03-25 21:09:33.0</td> <td> 66538799</td> <td> 13.03 minutes</td> </tr> <tr> <td> counters.last_reports.GSM.COVERAGE.0</td> <td> 2013-03-25 21:08:37.0</td> <td> 63537224</td> <td> 15.89 hours</td> </tr> <tr> <td> counters.last_reports.GSM.COVERAGE.1</td> <td> 2013-03-25 21:05:24.0</td> <td> 66571119</td> <td> 1 seconds</td> </tr> <tr> <td> counters.last_reports.GSM.COVERAGE.2</td> <td> 2013-03-25 21:08:37.0</td> <td> 63537086</td> <td> 15.90 hours</td> </tr> <tr> <td> counters.last_reports.GSM.COVERAGE.3</td> <td> 2013-03-25 21:05:20.0</td> <td> 66570271</td> <td> 9 seconds</td> </tr> <tr> <td> counters.last_reports.LTE.COVERAGE.0</td> <td> 2013-03-25 21:06:21.0</td> <td> 66574463</td> <td> 6 seconds</td> </tr> <tr> <td> counters.last_reports.LTE.COVERAGE.1</td> <td> 2013-03-25 21:09:33.0</td> <td> 53471637</td> <td> 3.13 days</td> </tr> <tr> <td> counters.last_reports.LTE.COVERAGE.2</td> <td> 2013-03-25 21:06:29.0</td> <td> 66574895</td> <td> 6 seconds</td> </tr> <tr> <td> counters.last_reports.LTE.COVERAGE.3</td> <td> 2013-03-25 21:08:37.0</td> <td> 60067367</td> <td> 1.55 days</td> </tr> <tr> <td> counters.last_reports.WIFI.COVERAGE.0</td> <td> 2013-03-25 21:05:25.0</td> <td> 66570609</td> <td> 7 seconds</td> </tr> <tr> <td> counters.last_reports.WIFI.COVERAGE.1</td> <td> 2013-03-25 21:05:26.0</td> <td> 66570629</td> <td> 8 seconds</td> </tr> <tr> <td> counters.last_reports.WIFI.COVERAGE.2</td> <td> 2013-03-25 21:05:26.0</td> <td> 66570636</td> <td> 8 seconds</td> </tr> <tr> <td> counters.last_reports.WIFI.COVERAGE.3</td> <td> 2013-03-25 21:05:25.0</td> <td> 66570601</td> <td> 7 seconds</td> </tr> <tr> <td> counters.last_reports.WIMAX.COVERAGE.0</td> <td> 2013-03-25 21:05:34.0</td> <td> 66571789</td> <td> 0 seconds</td> </tr> <tr> <td> counters.last_reports.WIMAX.COVERAGE.1</td> <td> 2013-03-25 21:07:41.0</td> <td> 66580174</td> <td> 0 seconds</td> </tr> <tr> <td> counters.last_reports.WIMAX.COVERAGE.2</td> <td> 2013-03-25 21:07:41.0</td> <td> 66580168</td> <td> 0 seconds</td> </tr> <tr> <td> counters.last_reports.WIMAX.COVERAGE.3</td> <td> 2013-03-25 21:05:34.0</td> <td> 66571793</td> <td> 0 seconds
</td> </tr> </tbody></table>
- 1
-
What happened to Sensorly on the Apple App store?
Speedtest is broken since we changed the control server's IP. Waiting for Apple to ok the new version
- 1
-
That's the map cache getting you. I have seen two different maps on two different devices side by side. Just have to drag around and zoom in and out to get it to say loading on the tile layer.
There's no caching on the servers, there's an eternal cache on the device until you exit the app and there's a 30mn cache on devices between app runs.
-
It must be of the day, because it has gone down since it said that.
Oh how I hate that the OS shows it that way...
- 1
-
Yes, it happens regularly. I'm not sure what triggers the reset, because there doesn't seem to be a set amount of time before it resets, but I do notice that every couple of days by battery levels will crash, and it's because it has reset to Passive and is mapping in my pocket.
In fact, checking just now it has used 24% of my battery today, and is once again on Passive mode. Though I know I reset it again a couple days ago.
Is that a real 24% or is that 24% of the battery drain of the day ? The Android OS shows the latter and it's confusing to users.
Send me your anonymous id to contact@sens.... and I will investigate.
-
Every time I set to "no contribution" it resets to Passive. Not right away, sometimes its a couple days, but I will notice it running again even though I told it not to. This is on my GS3.
When you set it to "No Contribution" and start a map, there's a popup that will reset contribution to Active when you touch "Ok".
I've never ever had the case of Passive setting itself back on by itself and I've tried over multiple days too. Are you 100% sure ? Is this consistently the case ?
-
Totally gotta eat my words on this last one. It updated. Not sure why one I did a week ago didn't, but I'm happy today heh.
Sometimes it takes a while, either there's a sudden traffic spike or we may be doing a bit of maintenance.
This weekend, I re-initialized the mapping process and fixed a long standing bug that was making updates to some areas slow, so there shouldn't be any discrepancies left. Go ahead and contact us (contact@se....) if you see any.
- 2
-
Personally, I do not do significant Sensorly mapping unless I'm plugged into the charger. Which I almost always am when I am in the car.
Humm.. that's strange : if you set it to "no contribution", it should never map, even if you hit map trip. There should be a warning, isn't there one ?
-
Regarding roaming being a different color, we might be able to improve & do that later this year: we'll give it a shot.
The version has been delayed because of a bug. But we also slipped in some stuff like the LTE cell information in the details screen so you should be able to get LTE physical cell ids in a couple days (it looks like cell ids are not being reported) for the few phones that support it.
- 6
-
We fixed the cell info gathering using the new api with the help of a user (thanks Ross!).
The upcoming release will include it. We'll have the info on the details screen in the following release which we'll try to make before Feb.
Remember that only some phones seems to be reporting it (very few)
- 8
-
One thing I have noticed is Sensorly incorrectly reports roaming coverage as Sprint coverage. Not sure if this is done by design or possible limitation at the time.
Went to an area that I know is roaming and wanted to map where Sprint stopped, I left it on accidentally. And it mapped the roaming coverage. DOH! It looks like Sprint has coverage there now.
Now that I look at things with all the times I am roaming in places, really looking at the Sprint CDMA map means nothing about Sprint's service coverage area since it includes all the other CDMA services as well.
-- "Sensorly or it didn't happen!"
It's intentional : it shows where you phone will work. That's what most people are interested in.
- 2
-
Are we talking about the same API calls? This LteCellIdentity element is what I was referring to in 4.1.1
Yes, obtained from CellInfoLte.
It looks like only the Galaxy Nexus, Galaxy S3 Sprint, Galaxy S3 VZ phones provides that info right now.
If someone has one of these running JB, send me an email to contact@sensorlyDOTcom so I can send you a debug build.
If not, we'll shoot a fix on Friday and hope for the best. If that works, I'll add the info on the details screen next week.
- 3
-
I am sure there are several folks here that could test an apk for you in an LTE area.
This would be awesome if it could report the lte cell info as we are always trying to track down what site the signals came from as new ones come online.
Well, if there are any phones that do report data, we should have it on our servers (unless we're unlucky and there was a bug in the un-testable code). I'm working on importing that data right now to check.
-
Ok, thought it was still hidden. Will look into this and try to include it in the Friday release.
Looked at it and indeed the "hidden" 4.1 api was released in 4.2 but every call to getAllCellInfo() returns null on my GSM Nexus 4.
If anyone is reading this and has seen values returned by that call, let me know and we'll test together
-
Using what version of the SDK? In Jellybean, I don't think you need to go around the barn with reflexion and hidden APIs. There are direct API calls to this stuff. I have no hands-on experience, just read the docs.
Ok, thought it was still hidden. Will look into this and try to include it in the Friday release.
- 1
-
There are LTE sector IDs (both short integers for Physical Cell IDs and long 28-bit integers for Cell Identity) available in the expanded API for Jellybean. It would be nice to see these in Sensorly's Detail screen.
The utility of all this would be multiplied if Sensorly provided the user a way to export a log of their own data points.
I implemented calls to that API using reflexion but I have yet to see anything be returned. Are you aware of any phones that do ?
-
Had to roll back to a previous version of Sensorly. Got tired of looking at NYC every time I hit coverage map, no offense NYCians.
That bug will be fixed in a release at the end of the week.. it was introduced in the last version when we added URL redirection : if you click on a link to a sensorly map (from twitter, FB or email..), it will open a menu asking you whether to open in the browser or the app.
I have been doing some digging and I believe I can make a simple app that would help me identify cell sites and LTE sites. I really wish Sensorly would capture and show us more than just signal info. In NOLA we already ran into several times where we wished we knew the LTE info on the signal. By no means is it going to be a Sensorly like app or replace it. It will just feed the need for more data that us wireless geeks are vying for everyday in our LTE hunting adventures.
Going to be cool.. Sensorly mapping the trip in the background building the map and a geeky all in one debug menu. Just hope I can pull this off.
Right now, phones don't provide LTE cell information so no way to lists sites.
What functionality is missing in Sensorly for you exactly ?
- 2
-
Are these the ones, 66bobbo? I drove up there in my new truck...
Try tapping the icon at the top right : it will screenshot the map without the status bar and add a caption to the bottom.
- 1
Sprint LTE Coverage Maps via Sensorly
in Network, Network Vision/LTE Deployment
Posted
Yeah there's a lof of optimization going on to update the maps as fast as possible so zoom levels aren't updated all at the same time. There's no backlog for LTE at the moment.