Topic: Barometric pressure not reported correctly to CWOP - Davis VPRO2- Meteohub

[dattilo0691]

I was told that CWOP expects altimeter pressure which is a variant of sea level pressure, but differently computated.
Sending station pressure or sea level pressure to CWOP will result in inconsitencies to what CWOP expects. In low altitude
regions the difference of altimeter and sea level is not relevant, but it will make a difference in the mountains.

What I tried to explain is that Meteohub applies a formula to compute altimeter pressure from station pressure. All stations I know do report station pressure, only Vantage does not unless you make use of the LOOP2 packets which have been invented by Davis for some newer firmware releases. So the Davis station might be seen as "broken", as it does not deliver basic data. 

However, Meteohub can now handle the LOOP2 (automatically detects if it is provided by the Vantage FW-Version at hand) and the Davis is no longer has this unpleasant handicap.

As the Meteohub altimeter pressure computation is unlikely to be 100% identical to the one hidden in the Vantages I would expect very minor differences between what Meteohub computes as altimeter pressure compared to what the Davis station shows on the console when configured accordingly. Hard to say which formula is "more right". When Meteohub altimeter pressure values look strange, I am willing to look into this.

Using a not documented Vantage value for Vantages and computing another value for all the other stations does not make sense to me, that is the point I intended to explain. I prefer to get it right in general and not to stick too much to one of the manufacturers. Inventing false numbers to be randomly inserted into the mearurements is something I don't plan for future relases, unless you force me with money 

So... I have everything configured as you have suggested with the latest meteohub update installed and still I see this (look at the top graph):

  http://weather.gladstonefamily.net/site/E2013

Any idea what is going on here? These values are generally off by 12mb or so which is certainly statistically significant and probably not explainable by some issue with a formula... Should I reload the meteohub software from scratch? Any other ideas?

Thanks again,
Garth

[LABob]

I was told that CWOP expects altimeter pressure which is a variant of sea level pressure, but differently computated.

That is my understanding as well. I misunderstood what you were saying. I thought you were saying that MeteoHub/Bridge were fudging the raw pressure and then calculating altimeter pressure.

[LABob]

Any idea what is going on here? These values are generally off by 12mb or so which is certainly statistically significant and probably not explainable by some issue with a formula... Should I reload the meteohub software from scratch? Any other ideas?

I only offer this as a data point, but I am using MeteoBridge (I believe the pressure calculations are the same as MeteoHub) to report to CWOP and I don't see that error. Perhaps 1250 feet isn't enough for it to manifest? I would think I would see something suspect though.

http://weather.gladstonefamily.net/site/E2607

[docbee]

@LABob: so you are fine now, right?

@Garth: Could you please give me access on ports 22 and 7777 of your meteohub? My mail is "info(at)meteohub.de".

[LABob]

@LABob: so you are fine now, right?

Yes sir. Sorry about any confusion.

[docbee]

I double checked and Meteohub (v4.9u) as well as Meteobridge (1.4) do now report altimeter values to CWOP according to NOAA calculation.
Nevertheless, this results in deviations compared to neighbouring stations as most of those seem to report SLP. So the ones providing true altimeter pressure are marked as false, as they are minority.   
At least this is what it looks like to me. Effect is only relevant for significant altitudes...

@Old Tele Man: Looks like this is what you experienced as well.

[LABob]

I double checked and Meteohub (v4.9u) as well as Meteobridge (1.4) do now report altimeter values to CWOP according to NOAA calculation.
Nevertheless, this results in deviations compared to neighbouring stations as most of those seem to report SLP. So the ones providing true altimeter pressure are marked as false, as they are minority.   
At least this is what it looks like to me. Effect is only relevant for significant altitudes...

@Old Tele Man: Looks like this is what you experienced as well.

How is altimeter pressure calculated for Meteohub and Meteobridge? The pressure reported to CWOP seems to fall in between the values given by the NOAA and Davis formulas. For example, my current raw station pressure is 968.8mb, and my elevation is 380 meters. The NOAA altimeter formula gives me 1013.3mb and the Davis formula gives me 1013.6mb, however MeteoBridge reports 1013.5mb to CWOP.

I'm not really worried about 0.1mb either direction, but it piques my curiosity about how MeteoBridge works. The difference is small enough to be a rounding error, but since the Davis and NOAA formulas are so close I can't tell which is being used.

If anyone is interested, I created a Google spreadsheet to calculate NOAA and Davis altimeter pressure from raw station pressure and elevation.

[Weather Display]

the differences might come about from how the 12 hour temperature average is used

[Old Tele man]

the differences might come about from how the 12 hour temperature average is used

Exactly, because a two-point spot mean (ie: 74 = (72+76)/2) is almost *guaranteed* to be somewhat different from a multi-point, running mean.

Anybody know which one that NOAA / NWS actually uses?

[LABob]

I don't think temperature is used in calculating altimeter pressure, only sea level pressure.

[docbee]

To give you some insight, this is the NOAA compatible computation meteohub/meteobridge does use for altimeter pressure.

Code: [Select]

double press2alt (double press, int height)
{
  double p = press - 0.3;
  double p0 = 1013.25;
  double t0 = 288.0;
  double n = 0.190284;
  double a = 0.0065;
  double x;

  x = ((pow (p0, n) * a) / t0) * (height / pow (p, n));
  return p * pow (1.0 + x, 1.0 / n);
}


[Old Tele man]

The "pressure - 0.3 mb" is the pressure-offset used to replicate the roughly 10-feet height of aircraft cockpits above airfield elevations, and only ALT (QFE) pressure calculations incorporate this offset, that I know of.

[LABob]

The "-0.3" is the pressure-offset used to replicate the roughly 10-feet height of aircraft cockpits above airfield elevations. Only ALT (QFE) pressure equations incorporate this offset.

The NOAA gives the formula as such here. Anyway, that's the same formula I was using. When I use docbee's code I get 1013.3mb. I can't figure out how that ends up as 1013.5mb in CWOP. Maybe it gets messed up on the CWOP end somehow.

[docbee]

I'm not really worried about 0.1mb either direction, but it piques my curiosity about how MeteoBridge works. The difference is small enough to be a rounding error, but since the Davis and NOAA formulas are so close I can't tell which is being used.

Remember LUBARSKY'S LAW OF CYBERNETIC ENTOMOLOGY: "There is always one more bug. 

At least I found one in the Meteobridge CWOP code that seems to grab good old SLP instead of altimeter pressure. 
Please power cycle meteobridge to get the new version without this bug loaded.

Meteohubs are not affected, there altimeter should work fine with newest 4.9u.

[Old Tele man]

"...a BUG a DAY, keeps the entomologists away..." (ha,ha)


docbee -- Curious question: what equation do you use to calculate SLP pressure from SP pressure? What temp and RH enhancements do you use?

[docbee]

meteohub provides three alternatives:
1) take the one the station delivers (if it does)
2) only use altitude with the simple "slp = press + (height / 8.5)" with height in meters
3) make use of an outdoor temp sensor by calculation below:

Code: [Select]

double P2Stemp (double p, int height, double temp)
{
  if (height > 0)
    return p * exp ((0.034178 * height) / (temp + 273.15 + (0.00325 * height)));
  else
    return p;
}


[Old Tele man]

Okay, so it's approximated using whatever data is available and not directly calculated using temp or humidity, thanks.

[docbee]

the user selects which of the three alternatives to use.