As with many data analysis posts: Give me more information about the data. In this case it could be particularly interesting. You have correlation and you estimate the temperature through indirect measurements. The important word here: estimate
As with all estimates I care about the error and not much else. The only error measure provided is mean absolute error which I find a little bit unsatisfying. It gives only very little information about the behavior of the error.
The easiest is to compute the error for every sample and then show a histogram of it.
Why you might wonder? In this case we deal with varying -though often over time stabalizing- data. This means that sometimes the error is actually greater and then very little. If you take the absoluate value of it and take the average (MAE), you might underestimate (resp overestimate) the error at times. In this case I might expect a tri-modal error distribution if we consider positive & negative errors.
A histogram is much more expressive (and oh so simple to generate) than a simple MEAN, STD DEV, MAE or MSE.
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)
TL;DR: "If it’s cold outside, chances are temperature sensors sometimes outside are colder than usual."
By itself, I have to admit I don’t find this particularly surprising, especially since they both averaged over space (whole cities) as well over time: There is no data presented on how well the correlation between battery temperature and outside temperature works out within a single 24-hours-period – given that most people are asleep at 2am, this would be another factor all/most batteries have in common apart from the outside temperature.
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.
I don't think this really means anything. If you track the indoor temperature and outdoor temperature at my apartment, they correlate. But it's because I come home as it's getting cool and turn on the AC, and I leave for work before it gets too hot out. So the shape of the graph looks the same, but the relationship is that I come home from work at the same time of day when the sun sets, not that the outdoor temperature affects the indoor temperature. (Weekends are proof, it's cold all day indoors then :)
Do you think it possible to make smartphones into body temperature thermometers?
I currently have an iOS app that measures heart rate with the light/flash while you put your finger over the camera. The camera measures your pulse by reading the difference in "color" or "density" of your blood reflecting into the camera as your Harry beats.
It's not medical grade in accuracy but holds up well in comparison with the heart rate testers at the local grocery store or manual pulse counting.
My rough estimate is this method is accurate to a few percentage points of a real medical device.
For those iOS and Android developers — would it be possible to detect body temperature to accuracy levels of that of a thermometer ( +/- 0.1 degrees ) using this battery method they are using for the weather?
It would be nice to check your temperature without the need for external hardware. Though even external hardware could be a great device, checking pulse, pressure, temp, and storing all data for historical analytics. Add in that you could compare that data worldwide and flu estimations may become possible. At least outbreak areas should be able to be narrowed somewhat. There's a ton of other data that could be gathered too. Just mapping outbreaks would be interesting to see how seasonal ailments migrate. Even allergies could be mapped.
This is cool. Possible use cases for those who are not grasping it:
* Under developed countries who do not have a national weather service begin to start tracking historical temperatures.
* People at risk of heat stroke could have an app on there phones that alert them when the temperature is too high. (Most phones do not have a thermometer, and the temperature reading of a room with no A/C is different than the outside temperature)
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.
1) there is so much room for error that it makes improving it not worth it
2) there are already many other devices with better readings and already in place
I guess I'm missing something? ...or is it just a proof of concept (when it's cold things get cold)?
knowing what the change in battery level is would allow for a pretty good estimate.
They've taken a very different approach to the problem though, and are filtering heavily such that they can ignore most transient phenomena as it gets filtered away.
I'm surprised (or overlooked) there wasn't a check for clustering of data. One set should clump close (with 24/7 consistency) to normal indoor temperature, while another should clump (with greater spread and time-of-day variation) around actual outdoor temperature. Split the discernibly HVAC-skewed values out, and you'll get a better grasp on the actual outdoor temperature. You could then sub-split the latter into warm-body proximity clustering (phones in pocket vs. otherwise).
My guess is that's accounted for in each city by the m and k values. Note that these values are essentially averaging the battery-temp-affecting behavior of everybody in a given location (as well as the local temperature variations as well) and mapping them to the "official" temperature (usually measured at the airport). That makes the whole exercise rather useless in my opinion: it doesn't provide more information than a weather report, just a vague redundancy. Significantly, they will never be able to isolate all the factors so that a single phone can tell you the local air temperature.
As Dylan famously said: "You don't need a weatherman to know which way the wind blows."[1]
I started to lose respect for people commenting on this board...I don't see what is the big deal with this, and why would you even publish a paper on it.
Here is the thing: Temperature reading of battery may not even be the actual temperature value of the battery. Even the circuits itself that read temperature is sensitive to temperature (they have the same correlation with temp. as battery..Higher the temp. is, higher the leakage current, and hotter your device will be). So temperature reading itself will be combination of things, most of which have similar correlation against temperature of the environment. This is a well-known fact to all people working in semiconductor industry and we simulate things against temp. all the time.
And when you average out thousands of reading from different cell-phones, you will get rid of all those noise coming from phone-usage, whether person holds the phone or keep in in his pocket ..etc.
As a side node, if the batteries in each cell-phone made by different manufacturers, their temp. reading will also be different and will add a noise as well.
You built an app to read temp., OK fine. But, it just annoys me the fact that they talk about it as if this was a new discovery, and publish a scientific paper about it :)
> I don't see what is the big deal with this, and why would you even publish a paper on it.
The fact that we suddenly have a boatload of free weather data? Nobody installed any weather stations - this is information fallout being put to good use. That's pretty awesome.
> This is a well-known fact to all people working in semiconductor industry and we simulate things against temp. all the time.
Simulating how an electronic circuit works under different temperatures is one ting, but do you do actual measurements to see what factor the ambient temperature has on the measured temperature of a phone battery? How about having the phone touch a 37 degrees centigrade heat bath on one side (in other words: a human body) and ambient air on the other? Before this paper, could you have made any reliable prediction on how big an influence ambient temperatures were on the sensors in the battery?
Knowing how much of that temperature is body heat, ambient heat and heat produced by the phone/battery requires analysing the data - for all we know the ambient temperature could have been completely insignificant compared to body heat and heat produced by the phone. Maybe you could model it and predict it, but even then the proof of the pudding is in the eating.
You and others here can complain that it's no surprise that thermometers measure temperature, but actually analyzing the data, discovering that ambient temperature is a significant factor, and figuring out the Pearson coefficient required to put it to use is a discovery, and certainly worth publishing about.
you do actual measurements to see what factor the ambient temperature has on the measured temperature of a phone battery? How about having the phone touch a 37 degrees centigrade heat bath on one side (in other words: a human body) and ambient air on the other? Before this paper, could you have made any reliable prediction on how big an influence ambient temperatures were on the sensors in the battery?
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!
Sorry, buddy...but, this is no more than a glorified Excel sheet work, or a high school science project...and you know that.
Nonetheless, it's useful..my only objection is for them to say it as if this was unexpected, something new, a discovery...which is not. If they talked to an hardware engineer, he would probably tell them what to expect anyways.
As with all estimates I care about the error and not much else. The only error measure provided is mean absolute error which I find a little bit unsatisfying. It gives only very little information about the behavior of the error.
The easiest is to compute the error for every sample and then show a histogram of it.
Why you might wonder? In this case we deal with varying -though often over time stabalizing- data. This means that sometimes the error is actually greater and then very little. If you take the absoluate value of it and take the average (MAE), you might underestimate (resp overestimate) the error at times. In this case I might expect a tri-modal error distribution if we consider positive & negative errors.
A histogram is much more expressive (and oh so simple to generate) than a simple MEAN, STD DEV, MAE or MSE.