meteohub.de

Hooked up MeteoBridge to my ObserverIP (hooked up as part of Ambient WS-1400-IP). Noticed in WUnderground tables that all wind speeds, regular, and gusts alike are (close to) multiples of 2.5 mph.

I investigated using the Live Data page on the ObserverIP and noticed that wind gusts are always coming from the ObserverIP as these same numbers, but wind is reported with all kinds of values with one decimal. I also sniffed network traffic and was able to observe the MeteoBridge calling on the livedata.htm web page of the ObserverIP to get its values. I know that it parses this data correctly, because comparing the same values with the live data page from the MB software shows the same values as obtained from the ObserverIP.

I do note, however, that what MB reports as wind speed (the first number), is actually the number reported by ObserverIP as the gust speed and what MB reports as the average speed (between parentheses) is what the ObserverIP sends as "wind speed".

I also observed that the MB uploads data to WU where the first number (windspeed from ObserverIP) is sent as windgustmph variable, but the second number (average) is not sent as the windspeedmph, but rather what seems to be a previous wind gust value is sent instead. This, of course, is not the desired outcome.

I also have my MB sending data to CWOP and comparing the data there I see that the values there are different from what goes to WU. Now data to CWOP is being accumulated for 5 minute intervals, so I would not expect exactly the same values. What I see for both gust and speed are values that are always ending in .0 (seems consistent with APRS format not allowing anything but integral MPH values). But I do see gust values that are, essentially, rounded versions of typical gust values like 2.5, or 4.9. These values are explained if we accept that (for whatever reason) the Ambient sensors produce this speed in multiples of 1.1 m/s which, when converted to MPH, correspond as follows:
The rounded values in the table are exactly the values the ObserverIP produces for wind gusts. It would also indicate that (if my analysis is correct), it would be better to send values read out as 2.5 to APRS as 002 rather than a rounded value of 003 because the true underlying value was 2.461 which would be more correctly rounded to 2. While marginal, this would on average result in slightly better data on CWOP. This problem would also show up for a reported speed of 56.1 m/s (125.5 mph) and some even higher values, so all cases but the first can safely be ignored.

Looking at values received by meteoplug.com I see values such as 1.1 m/s which corresponds directly with the 2.5 mph measurement for the first value (assumed to be gusts) and 2.2 (the multiple) and values like (for example) 0.1, 0.2, 0.5 and 0.6 m/s for the second value. These correspond to 0.224 = 0.2 mph, 0.447 = 0.4 mph, 0.536 = 1.5 mph and 0.626 = 1.4 mph. These values are values the ObserverIP is capable of producing for the wind (not gust) speed.

So, I it seems that MB internally has the correct values (I am using Meteobridge 2.5 (Apr 14 2015, build 6256), FW 1.4 on a TP-LINK TL-MR3020) but is not sending the correct value(s) to WU.

Attached are some screen shots from my Live Data page for reference and one from meteoplug wind values.

I would love an update that fixes this.

Quick follow up:

Ambient has confirmed that the wind speed sensor is sampled a number of times during the basic reporting interval. The maximum read out value is reported as the gust speed and comes in multiples of 1.1 m/s. I have no idea why the resolution of this reading is so low, but we'll accept it as fact for the purpose here. The reported wind speed is computed as the average of a number of these "gust" observations.

Since we can see the wind speed indication come in as low as 0.1 m/s that means that over the averaging interval, at least 10 or so samples must be taken because at minimum gust speed of 1.1 m/s observed once during the interval, and zero for all other samples, the average would come to about 0.1 m/s. It was not said whether or not the average sampling interval is equal to the sensor reporting interval, or larger, so we cannot exclude that possibility. I asked for this information twice and the question was ignored.

Another issue observed is that MB "scrapes" the values from the live data page from the ObserverIP. That page reports wind speeds in MPH with only once decimal. Internal measurements are in m/s with one decimal and that means conversion to mph should really produce at least two decimals. It actually does so when reporting to WU (observed sniffing network traffic). I have seen the ObserverIP live data page report 2.5 when 2.46 was sent to WU by the ObserverIP. For that same data the MB would receive 2.5 from the ObserverIP so that would be relayed to WU.

I asked them (Ambient) to fix this in the live data page, and also asked them to include seconds in the data time stamp (both of which may aid MB). Their response was first one of blaming WU for the rounding, but on reconsideration, they accepted my observations, but said they would only consider "fixing" it if they received "more complaints". I did not consider my email a complaint, and it seem that when an actual error (of omission) is reported, you do not need lots of complaints to fix it. Since they asked, however, please write to Ambient Customer Care at "support@ambientweather.com" to complain and request it be fixed. It would be even better, of course, if the content of all pages could also be requested in JSON format, which would be a lot safer to parse than scraping HTML.

So it seems that what remains is for MB to properly pass on this value for average speed to WU.

Newest version of Meteobridge can read data from observer-ip in any measurement unit.
May be you switch to a unit with better resolution. Meteopbridge should be able to convert correctly.

I did switch to m/s, but MB is still only reporting one decimal in windspeed (gust) in mph as uploaded to WU (which is just an interesting difference with direct submissions from ObserverIP, but does not make any material difference as WU seems to round the data).

The more pressing issue (to me) is that wind speed info uploaded to WU seems wrong, as described. The gust data is consistent with ObserverIP, the windspeed data is not. I never see uploaded wind speed values differ from the multiples of 1.1 m/s even though MB's live data page (avg) shows other values.

Hi just to add my observations with WU and the rounding.

I have a MB and an Acurite 5in1 sensor. For the last week myself and others with the same setup have noticed that WU is rounding off data in their "summary" section. If one looks at the graph of the data for any day however it does seem that the tenths data is being sent to WU. "We" suspected that the new WU site is rounding this off. So far I have not "complained" to WU about this but maybe we should?

Yes, there are multiple issues with WU itself, but in this thread I am only trying to get MeteoBridge changed to send the wind average as from its live data page to WU as opposed to what it is sending now. What it is sending now seems to be some past or current version of the gust value as it is always 0, 2.5, 4.9, 6.8 etc.

I'd be happy to try a beta.

Meteobridge does send current non averaged wind speed as "windgustmph" and maximum no averaged wind speed of last 10 minutes as "windgustmph_10m".
I don't know to which value your WU observation is related to, but it might explain that you don't see on WU what your observerIP is showing on its web page.

Clearly I am not communicating well. So let me try again in a different manner.

If you look at the attached screenshot from MB live data page, you will see reported that the reported "Wind avgwind" is 0.2mph and "Wind wind" is 2.5 mph. This may be coincidence, but the screenshot taken from the ObserverIP at the exact same time show "Wind Speed 0.2", "Wind Gust 2.5" (everything set to mph).

I am assuming (perhaps incorrectly so) that when MB reads the page from ObserverIP (that is how it gets the data, is it not?) and scrapes it, it finds these same two values. The value the ObserverIP reports as "Wind Speed" is averaged from its sensor over its reporting interval (about 8-14 seconds, not sure exactly).

Also, sniffed from the network, when MB is sending data to Underground I see the following parameters in the URL (only showing wind related here). Also, at this time the record uploaded to meteoplug was: These values correspond to 2.5mph, respectively 0.2mph.

From this I conclude that MB decides that the value it sends as "windspeed" is not taken from the field that the ObserverIP calls "Wind Speed" and that comes from the "wind0" sensor. This would seem to be, however, the logical choice and that is what I am asking to be changed. It would seem reasonable that WUnderground receives the same value for what is the same logical variable as does, for example, MeteoHub.

As is, data on, for example, meteohub simply does not correspond to what one would think is the same data on WUnderground (or inside MB). It has a weird side effect in that if one looks at the wind speed/gust graph on WUnderground, one can see that wind speeds are quantized to the aforementioned multiples (I cannot attach this as a fourth attachment so I will attached it in the following post). If one has the ObserverIP upload instead, this is not the case an we see all kinds of in-between values like 0.2, 3.6, etc. This (using ObserverIP instead of MB) is obviously not the solution I am looking for, given that I have invested in MB hardware and a software license for it.

So hopefully, you understand better what I mean now.

Here is the screenshot of the quantized WU wind data from the same period. I have highlighted (vertical line) the specific timeslot in question. Blue is what WU received as "windspeed" and orange is "windgust".

On the line we see a case where the uploaded gust was 2.5, but the uploaded speed was 0. There is, unfortunately not an exact capture of that dataset show in the previous post, but I have looked at many intercepted posts to Underground and windspeed is always one of the multiple values. See this table attached as well (the columns are: temp, deep, pressure, wind, wind speed, wind gust, humidity, rainfall hourly).

Please adapt screen dumps to a useful size. This retina dumps blow up readability of the whole thread.
Apart from what you think values should be, reality is as follows:

ObserverIP:
- "wind speed" is averaged wind speed over 15 second interval
- "wind gust" is the maximum wind speed measured in the same 15 second interval

Meteobridge Dashboard:
reports average wind speed (here: "wind speed" from ObserserIP) in brackets and current wind speed in front of the brackets (which is here "gust speed" as the ObserverIP does not provide current wind speeds caused by a too slow wind update interval that renders picking up current speeds useless).

Meteobridge Variables:
-"wind0wind" are the ObserverIPs "wind gust" values (as current wind speeds not avail)
-"wind0avgwind" are the OberserverIPs averaged "wind speed" values

WU gets:
- "windgustmph" which is the 120 second maximum of MB "wind0wind" values
- "windgustmph_10m" which is the 600 second maximum of MB "wind0wind" values
- "windspdmph_avg2m" which is the current MB "wind0avgwind" value
- "windspeed" which is meant to be the instantaneous wind speed, which the ObserverIP does not provide, so it gets current "wind0wind".

It is a matter of taste if you report averaged wind speed or wind gust (of a 15 second period) as instantaneous wind speed.
Both is strictly speaking wrong. As "wind0wind" is used in Meteobridge with other weather stations for instantaneous wind speed,
ObserverIP is handled the same. I don't like the idea to make a special case for the ObserverIP to make an obvious deficiency it has
looking a bit nicer. If the MB ObserverIP community asks for having that value cheated that way, I can insert some if-the-else clauses...

In general I cannot solve the issues WU has with displaying wind data or that the ObserverIP does not provide wind data in better resolution or higher frequency.

I have reduced the image sizes, as requested.

Since you write that it is a "matter of taste" and "both would be wrong" (my position on that would be neutral) I would appreciate it if the choice in taste can be left to the user and you could change MB to provide that choice somewhere in the setup.

As a practical observation, even other stations do not, and cannot, deliver a true instantaneous wind speed (except perhaps the sonic based ones). Virtually all anemometers will count pulses generated through magnets around the rotating shaft. Generally 2 or 3 magnets per rotation means at least several seconds of pulse counting would be necessary to get some accuracy (in particular at lower wind speeds), but the length of the interval, the longer it gets, makes it more of an average speed rather than an instantaneous value. In case of Ambient it might be 15 seconds, it seems to be 5 for Davis Instruments (I have not found precise descriptions for either company's product in terms of how values are determined; only what the reporting interval is).

The differences becomes more pronounced when wind speed behavior is very variable (highly variable acceleration of the anemometer). Such conditions would also be influenced by inherent mass based momentum and low friction for the anemometer which itself will introduce an averaging affect. Sustained winds would give similar readings for both methods on a 15 second interval so the "choice" would mostly matter in these highly variable conditions.