What variables are currently included in the CL algorithms? I know UV and RH are included, and WF are working hard on rainfall, but what about temperature, pressure, wind etc.? Are these included, or if not are there plans to included them (or do they not need to be included at all due to the quality and stability of the factory calibration?). Not getting impatient - just looking for info
WeatherFlow is working on wind as indicated by numerous massages by David. I don’t remember reading that temperature or pressure are included at this time.
Hi @peter The Continuous Learning system will evaluate known good data sources in your immediate area and automatically tune the raw sensor data on your Smart Weather Station to ensure all data from the network is sound. Status as of 29 November 2018:
UV: in production for all stations. Explained here.
Humidity: in production for all stations
Temp: in production for all stations, values out of QC range are flagged but no dynamic tuning is currently applied, variability depends on micro-siting.
Pressure: in production for all. Explained here.
Rain: currently in development, not yet deployed.
Wind: this is a different beast as wind fields vary massively and it is quite impossible to benchmark trusted known good data sources for comparison unless co-located within a couple feet. Instead of using a CL process as noted above, WF has deployed a sophisticated algorithm that dynamically inspects and governs the wind data coming off your SKY. The algorithm looks for anomalies in the raw data and rejects suspect data points. Development of this algorithm is ongoing…making it better and better with more data collected from the field. The tuning of the sonic anemometer is actually accomplished during setup whereas your SKY will automatically time the interval of sonic signals between the 4 transducers and balance the signal setup. Once set, the sonic has proven to be highly accurate at measuring instantaneous wind.
Thanks @WFmarketing for the detailed response. Very useful information .
I have another question though. I was chatting with some Antarctic meteorologists today at work about the CL system (btw they were all very impressed!), and they were wondering how convergent the CL algorithms are? How strongly do the calibration coefficients calculated through the CL process simply push the observations from a Smart Weather Station towards the values reported by the known good data sources, ignoring any local variability due to the siting of the Smart Weather Station itself?
@WFmarketing - Can I ask a few questions about the CL process runs?
Does it run at the same time for all sensors, or different times for each?
Does the process run at a fixed UTC time, or the time at the local station’s timezone?
Is there a feature request in the queue to send (optional) notifications from the various apps whenever a CL adjustment is made?
Just asking because I’ve seen a few threads pop up lately about sudden sudden graph changes, and would like to know if they are related to CL adjustments rather than actual rapid measurement changes…
They used to have a UDP message saying ‘calibration received’ but that was taken out in v98. I posted a request to put it back in, which I think Gary seconded if memory serves. It’s always nice to know when WF is tweaking the system, for the reasons you mentioned…
Yes, unfortunately this valuable troubleshooting packet was removed.
My notification request is for the general user, not the 0.1% of us who watch the UDP packets…
You miss-typed 10%.
Hi @peter Great questions. Antarctic – burr!! The CL system is unlike traditional manual offset calibration so it’s natural there are lots of questions. We’ll try our best to explain in simple terms. There are a bunch of proprietary techniques in play here, so apologies in advance for the need to obfuscate some of the technical details to protect our intellectual property.
Preamble — remember, at heart we’re a bunch of meteorologists. We built a reputation on quality ground level weather observations and we hold that sacred. It’s especially important to QC and curate public weather networks to ensure the quality of data across the board…which is why the CL system is so critical. Operating one of the world’s largest professional-grade networks for 20+ years…we learned a thing or two about sensor drift and the need for frequent calibration. A network is infinitely more useful if all nodes are in tune.
Short answer – The goal of CL is NOT a point-by-point matching of Smart Weather obs to the nearest reference sources. Rather, the calibrations are designed to account for a more general long-term and consistent offset from the trusted reference sources. We evaluate and QC a set of reference trusted data sources in close proximity to the users’ station over the course of day(s). Both the reference data and the Smart Weather data are passed through a series of smart algorithms that identify and remove any inconsistent or outlying data points to ensure that only the most accurate and representative data is used to generate the calibration. A regression analysis is run on the comparison data set and if it meets meets a certain r-squared threshold then and only then a fit value including both slope and intercept is defined and applied. Data reported comes directly from the sensors and will reflect all the nuances of the sited environment unless otherwise noted.
Longer explanation – The CL system takes a long period of past observations and analyzes through a regression algorithm to identify and remove that general and consistent offset from the trusted reference sources. The values displayed are more accurate because of CL running and applying these occasional calibration checks. But once again, your station data is direct from your sensors. As example, we do not (and should not) look at a pressure observation in real-time and adjust it up or down based on what some reference source says at that same time. If there is some interesting mesoscale feature, say a sharp pressure bump due to a thunderstorm outflow boundary, the user will see that change in real time regardless of what the reference source says about it.
Caveat --That said, if a station is truly located in a spot that always has 5% higher humidity than the local background field due to siting, then yes the CL would catch that and remove the general 5% offset. While this could be a negative for some users, we believe it is a positive for the vast majority because it essentially means that CL is ‘fixing’ siting problems. But it is true that this makes these devices inappropriate for some use cases, like measuring humidity in a spot that you know will be consistently different from the local ambient/background humidity, or putting a bunch of AIRs around your property to analyze micro-scale humidity differences. To account for that, we do intend to offer users the ability to opt out of the CL process and apply their own calibration. Calibration is typically more complex than just a simple offset and would only be a good idea for true experts.
Superb explanation of CL @WFmarketing
Thank you so much @WFmarketing for taking the time to provide such a detailed answer . As a scientist I would love to delve deeper into your algorithm, but fully understand that this is not possible!
I like the sound of the CL system being able to ‘correct’ for siting issues, as this is certainly the biggest issue I face in my small garden that is surrounded by other houses on all sides.
That is a very interesting detailed response. I have a question: we have had a rather peculiar weather situation with relative humidity above 98 percent over about a week, perhaps with a drop to 92 to 95 percent in the early afternoon. Today, the RH has dropped to less than 80 percent on two occasions and I would guess it was at 85 percent for most of this morning and afternoon. These measurements were made on both Davis and Oregon stations.
Air seems to have ignored today’s drop and from this morning through to mid afternoon, it has displayed 99 percent RH (on the WD display, the temperature and humidity lines are practically coincident). On the graph showing air temperature on my Android phone, the temperature line is just the width of the dots higher than the dew point line.
It has struck me that the sensors in Air are almost totally enclosed except for a tiny hole in the side of the device. Could it be that the humidity has not been evacuated from the interior of Air, despite max air gust of 9.8 m/s (measured on Davis) and 5.8 m/s (measured on WF): respectively max average of 4.4 and 3.2 m/s? Or, is this a CL anomaly?
Hi @bne . Your station is located in Cyrus where our CL system does not have enough comparison ground truth data to form a baseline in-situ calibration curve. Thus the CL system has not applied a tweak to your humidity yet. However, we doubt your high humidity is related to the CL system.
Instead, we suspect it is related to a known issue with prolonged high humidity exposure. Please see this thread: Humidity Appears Incorrect (solved)
The AI must explain why humidity reporting from my new (as of 11/6) AIR is, in the last week, getting closer to what my three year old Davis Vantage Pro reports. Before Thanksgiving, in heavy fog, the Davis reported 97% while the AIR reported 78%. On 12/1, again in heavy fog, the Davis reported 96% while the AIR reported 89%.
However, rain is quite another issue. In the past three weeks, the skies have opened up and our parched California land has absorbed somewhere between 2.14" and 3.15" of rain as reported by the Davis and the SKY respectively. Here is the data:
Clearly there are huge discrepancies on 11/28, 11/29, and 12/4. All three days had some pretty strong winds. The Davis and SKY are approximately 15 feet apart and both are in clear air.
Do you think the AI will help make the two agree better? BTW, I also have an old Rainwise rain gauge that is in need of calibration but which read 0.06" today exactly matching the Davis; it usually reads about 20% higher than the Davis.
Thanks for your reply. For your info, Cyprus is an independent island
over 1000 km away from Greece. I mention this because our weather is
very different from that of southern Greece because many of the fronts
travel up the Aegean Sea towards the Bosporus, missing us all together.
Our climate is hotter and drier than that of Greece. That having been
said, Cyprus is quite mountainous and has many microclimate regions.
Where I am misses nearly all the major thunderstorms which pass mainly
to the north and south of where we are in the foothills, about 300 m up.
Just this past few days, the major cities of Nicosia, Larnaca and
Limassol have all had bad storm damage and flooding, where we have had
practically nothing. Automatic calibration or learning based on the
official weather stations in those cities would probably not be very
I went through the thread that you recommended and got totally confused
from the hundreds of posts and I missed out on those that seemed
relevant to my problem. Today, the humidity has increased again and all
three of my weather stations have the relative humidity constantly above
98 percent, with the wet bulb coincident to the temperature. I’m
therefore unable to say whether there is any improvement. I’ll have to
wait for better weather
May I respectfully recommend that you consider limiting the length of
Hi @bne Appreciate the follow up ! Cyprus sounds like a fantastically interesting place…would love to visit some day. The CL system will only evaluate trusted data sources within close proximity to your exact location. If there are no available data sources, then no corrections are approved / applied (as is the case with your station). In this case, we will be enabling a feature to allow the customer to apply a manual calibration in the future.
Yes, some of the threads are quite onerous. Tricky to strike a balance between allowing open public discussion and cutting out a bunch of the crap. Many of the core topics are distilled in our official Help FAQs. We are also considering organizing topics into sub-categories…but right now we’re spending most of our time improving the station performance.
Correct. The CL system for humidity is evaluating data from a handful of stations near your location on a continuous basis and adjusting calibration.
Yes, the CL system for rain (not deployed yet) will bring your readings into better alignment. The haptic sensor in SKY is a very sensitive device capable of much higher resolution data than the average tipping bucket. However, the tuning of the sensor is dependent on the unique mounting situation for each unit. The CL system for rain (again, not yet deployed) evaluates reference data sources for precip and will tune the calibration curve for your individual device. This is a complex process as rain is a complex beast – sometimes light, sometimes heavy, and everywhere in between, influenced by wind, etc. For that reason, it’s not a simple % offset as you have demonstrated in your comparison data.
And as I asked somewhere before might be by temperature? Did someone did investigation (either theoretically or experimentally) on that dependency?
I know for a fact when temperature drops too low no precipitation is registered.