JamesCRR's comments

Hi this is James from OpenSignal.

By "proprietary" we basically mean "here's a cool new metric (ps we invented it)" not "here's a cool new metric (ps we're not gonna tell you how it works)". That said the link to the methodology is a little buried, but you can find the details here: http://opensignal.com/methodology/time_coverage/

One thing to note is that it's possible that if you only launched LTE in urban areas and the LET users stay within those urban areas, then the time-coverage can be great, even if if the geographic coverage is poor and a low percentage of the population has access to LTE overall. Nonetheless, it is a measurement of the experience that those users that have LTE are getting.

Given this, we do have to be wary about markets where LTE is not mature yet.

Good point re. unlimited vs limited data plans and how the latter can make it easier for an operator to provide good throughput (but overall you might get less volume). This is illustrative of a bigger challenge - there's no single metric that can tell you: "this is the best operator in the world". We're never going to claim that. But our crowdsourced data can offer a global, impartial view that I think has been missing.

(This is James from OpenSignal)

I agree time coverage needs to be carefully interpreted - particularly when an deployment is focussed just in a city, a high time coverage percentage shouldn't be taken as meaning there is a strong nationwide deployment. But it does show the experience of the users who do have LTE.

For markets that have had LTE for longer, and with high LTE penetration (i.e. large percentage of subscribers using LTE), time coverage does show how effective the rollout as been.

Two more notes on why we've chosen to do this:

- Firstly geographical coverage is a little shaky - there are questions over how to factor in indoors/outdoors/under a bridge, cell breathing and other temporal fluctuations should be taken into account. The time coverage we use is unambiguous: we look at the proportion of time users have access to the LTE metric.

- Secondly: our crowdsourced methodology is focussed on measurement, not modelling. There are often very sparsely readings where we simply don't have LTE readings, we can't conclude unequivocally that there is no LTE there, or just no users. There are some ways we can get round this we can look into on (extrapolating from our cell maps), but for the moment we're much more confident in the time coverage (though caveats are required!)

Sure, I'm on a super hectic schedule, so it may just be a drink and some empanadas, but let's set something up.

+1 Funnily enough, I'm in Argentina right now working on the Android version of WifiMapper as we speak.

Would be interested to know the R-squared on the room-price correlation.

Conflicting information, I just talked with someone from Sensirion who was quite central to the the SHTC1 project, he confirmed it was NOT the waterproofing that was the issue and pointed out there are Japanese devices with the same chip that are waterproof, even to IP68 (2m depth).

WeatherSignal is a slightly different project to OpenSignal (but it's by the same people) - we're sharing data with several academic institutions and independent researchers, and will make the feed fully open. Also NB, PressureNet is a great project, WeatherSignal also collects pressure data but I think other sensors are relevant.

We have an algorithm in WeatherSignal that tries to determine whether users are indoors or outdoors - there's a roof icon that appears or disappears, try it, it's pretty accurate during the day time.

WeatherSignal project is basically funded by OpenSignal sales, we sell to carriers and regulators -- who can act on the data to improve service.

(I'm James Robinson, a co-founder of OpenSignal/WeatherSignal)

Macbook Wheel is much easier to use. http://www.theonion.com/video/apple-introduces-revolutionary...

"if 20% time has been abandoned at Google, are other companies, which reportedly include Apple, LinkedIn, 3M and a host of others, wise to continue trying to copy it?"

That's incorrect, AFAIK 3M were the first company to pioneer this approach (with 15% of time spent on self-directed projects).

For example see: http://www.fastcodesign.com/1663137/how-3m-gave-everyone-day...

Talking to a friend at 3M (who has been there 20+ years, an engineer with dozens of patents) I am told that while 15% officially still exists, for a long time it's effectively meant working 115% of hours.

Nonetheless the tradition allowing self-directed research continues at 3M - and this might mean using lab resources, or creating prototypes without getting approval.

Gets interesting at "My trip report" - the unedited notes produced at the time (i.e. no hindsight)

Nice example of someone adding a leap motion controller to their site, GoSquared: https://www.gosquared.com/blog/playing-around-with-the-new-l... I'm not going to argue this demonstrates utility, but it does show some good recognition of smaller gestures.

Even under lab conditions, I doubt you'd get a good correlation between battery temperature and lab temperature if the phone were being used. Across an ensemble of phones and aggregating battery temperatures, you might expect to do better, but that would only prove this works in lab conditions.

These phones were sometimes indoors, sometimes outdoors, sometimes in bags, in conditions that are hard to replicate unless you have a very good model of average user behaviour.

We're working on ways to better detect the situation of the phone at the point of a reading, but even then it takes about 30minutes for battery temperature changes to take effect. If a phone was outside 15 minutes a go, the outdoors temperature will still have a large impact.

Modelling this or testing in lab conditions is not trivial!

It's something we will look at for sure. In general, it's slightly harder to get good results from looking at energy drain (as obviously a single reading means nothing, only pairs of readings from the same device)

As an aside, I used to live on a boat, installed a quarter tonne of batteries and got rather obsessed with making the energy last.

We actually used R, but this looks very neat, thanks for sharing!

Nice points,

We were told the paper would be published (and open access today) but doesn't quite seem to be up yet: http://onlinelibrary.wiley.com/doi/10.1002/grl.50786/abstrac...

The paper does have more detail, and I believe supporting materials will be released. You can also download the data and do some of your own digging (either from the big file at the bottom, or just view source and grab the js values that feed the graphs)

For some of the cities in the study we had only about 600 readings from 300 users per day. At this level of data the averages work well across 24 hours, but are messy when you start trying to get hourly figures. Even a couple of thousand users does not give great hourly correlations.

However OpenSignal was not built for weather crowdsourcing, and battery temperature readings are only taken when the phone is plugged in, unplugged, turned on, or turned off (since we wanted to calculate average battery drain). So clearly we could more regularly poll the battery temperature. This is what WeatherSignal does.

In this case we would get better spatial and temporal resolution.

It's also well worth pointing out that we tested this in cities where there were already trusted, online data sources (i.e. weather stations), there are population centres where this won't be the case, or where the data is not shared.

Also the case is that for dispersed populations (e.g. North of Sweden or Siberia) while we might not manage to resolve temperature to city level (until we have many more users) we could get temperature estimates across larger ares.

So I guess what I'm saying is: this is the start of the story, already we're getting data that is good, more filters could make it better, but more users and faster polling is the real key.

We use Mailchimp and find it works well.

I'm alive, or am I?

OpenSignal - London, full time

We're the largest independent data source on cellular and WiFi networks. We're looking for people to help developing our crowdsourcing apps and interpret the data. Our team is small and we have a great time working together - lots of BBQs in the roof garden in the current weather.

We're looking for:

- iOS developer, iOS7 has opened up some great new APIs and we're looking to bolster our app out there, making it as popular as our Android app (currently clocking 15k downloads per day)

- Back end developer with a passion for data. We use R, Hadoop, SQL, PostGres and more, and we love dataviz.

- Telecoms expert, someone who likes a startup environment but has detailed understanding of how cellular networks work and experience within the industry

join @ opensignal.com http://opensignal.com/jobs/

I think in QA terms it is certainly harder to build apps for Android, that said I'm not sure whether moving from 4000 distinct devices to 12000 distinct devices makes much difference, either way you're just going to pick some representative ones for testing. What is interesting is just how diverse the smartphone market has become, that is arguably a strength not a weakness of Android.