CWOP expects altimeter, gets SLP

[speedycactus]

My Davis VP2 and NSLU2 transmit to WU and CWOP. In going over the QC checks on the CWOP site, I noticed what apparently is a common problem: an incorrect and seasonally drifting pressure. Apparently, CWOP is expecting altimeter, and the Davis VP2 console provides SLP (sea level pressure). The NSLU2 (ie Meteohub software) is simply forwarding the Davis-provided SLP to CWOP, as many software programs did until they were corrected in the past few years.

Any chance we can get Boris to do a "little" computation /conversion of SLP to altimeter before sending data to CWOP? Anybody else run into this problem? Anybody care???

[admin]

Regardless what station you have Meteohub reports the barometric pressure in respect to sea level to CWOP and other APRS services. The CWOP documentation does just says "The letter "b" followed by 5 numbers represents the barometric pressure in tenths of a millibar".

Where do you have the information from, that it should be reported as pressure on station altitude, which is quite unusual for a weather reporting service?

[admin]

I checked some more documents:

CWOP Guide on http://home.comcast.net/~dshelms/CWOP_Guide.pdf says...

Code: Select all

Pressure reduction format: Altimeter (QNH) Pressure - Altimeter pressure is a
corrected pressure value that includes the pressure between the station’s elevation and sea
level.
Note: Altimeter is the CWOP pressure standard because it is the simplest pressure
reduction format that most CWOP members can reliably deliver and which can be useful
by the National Meteorological Services.

So "altimeter QNH pressure" is expected. But what is QNH? Wikipedia does help: http://en.wikipedia.org/wiki/QNH

Code: Select all

QNH is a Q code. It is a pressure setting used by pilots, air traffic control (ATC), and low frequency weather beacons to refer to the barometric altimeter setting which will cause the altimeter to read altitude above mean sea level within a certain defined region. This region may be fairly widespread, or apply only to the airfield for which the QNH was given. An airfield QNH will cause the altimeter to read field elevation on landing irrespective of the temperature.

To me that sounds like sea level pressure is what QNH is about. To me that is evidence that Meteohub reporting SLP is right... but I am willing to learn

[speedycactus]

Boris,

Thanks so much for your quick response.

By way of introduction, I am a Airbus captain for US Airways and a long-time meteorology enthusiast. My understanding of altimeter is that it is simply absolute pressure corrected for elevation alone. SLP is absolute pressure corrected for elevation, temperature and humidity, and there are a number of different algorithms for computing SLP. In fact, Davis uses a slightly different algorithm for displaying SLP on the console than the National Weather Service does for airports. QNH is altimeter, not SLP.

I found the following thread useful in explaining the problems with transmitting SLP instead of altimeter to CWOP. The user "tinplate" (Steve from Softwx.com) is one of the more knowledgeable individuals on the subject.

http://www.wxforum.net/index.php?topic=1995.0

I am definitely **NOT** a computer programmer, so I have no idea how much work is involved on your end in providing altimeter (QNH) to CWOP, but if you can do it in an update, fantastic! I imagine you can simply take the Davis console absolute pressure and correct it for elevation from the "Station Altitude" entry in Meteohub. If I can assist in any manner, please let me know.

Thanks!

[admin]

My confusion is about what exactly altimeter pressure should be.

I know of the pressure that the weather station is measuring (named "local atmospheric pressure") and the one computed from that by taking the stations altitude into account, which is normally named "sea level pressure" because that is what the pressure would be for the current barometric conditions when being at zero altitude.

From the explanation of the wiki it looks to me that "altimeter pressure" has a computation included which takes the altitude of the station into account, which looks pretty like what we do to compute sea level pressure.

I did find the following more detailed explanation (http://en.wikipedia.org/wiki/Atmospheric_pressure) which tells me that altimeter pressure is something like sea level pressure but computed a bit different:

Code: Select all

The altimeter setting in aviation, set either QNH or QFE, is another atmospheric pressure reduced to sea level, but the method of making this reduction differs slightly.

QNH
    The barometric altimeter setting which will cause the altimeter to read airfield elevation when on the airfield. In ISA temperature conditions the altimeter will read altitude above mean sea level in the vicinity of the airfield
QFE
    The barometric altimeter setting which will cause an altimeter to read zero when at the reference datum of a particular airfield (generally a runway threshold). In ISA temperature conditions the altimeter will read height above the datum in the vicinity of the airfield.

QFE and QNH are arbitrary Q codes rather than abbreviations, but the mnemonics "Nautical Height" (for QNH) and "Field Elevation" (for QFE) are often used by pilots to distinguish them.

I have to omit, that I am a bit lost on all this. When someone can give me formula how to compute QNH from a station's local atmospheric pressure and altitude, then I am happy to feed CWOP with this. But from all reading I don't see any indication that sending local atmospheric pressure to CWOP instead of sea level pressure is a better approximation to expected QNH values.

[Edzo1]

Hi - just updated from version 4.7 to 4.7i and I had a couple of quick Qs on one of the changes ....,"Changes CWOP and APRS barometric reporting from sea level to altimeter" (v4.7e).

Right now, in the all-sensors.txt file, I can see the local site pressure reading "actual_thb0_press_hpa" and the sealevel pressure reading "actual_thb0_sealevel_hpa". Is there now a third pressure value somewhere for Altimeter, or is that just calculated by Meteohub behind the scenes and sent off to CWOP ...., if Meteohub does not list the Altimeter figure, how do you know what it is? ...., my pressure reading at http://www.findu.com/cgi-bin/wxpage.cgi ... all=DW2589 still looks like it's receiving the SLP.

And does WU still receive SLP or the new Altimeter reading?

Thanks,

Ed

[admin]

I had to roll back the altimeter stuff as it turns out the formula I got a grip on was incorrect. So CWOP is feeded with sealevel again.

If someone can provide a reasonable formula to convert station pressure or sea level pressur to altimeter pressure, I will give it another try.

[N5XL]

Boris,

Sorry for dragging up an old thread but is it still the case that meteohub sends CWOP SLP instead of altimeter? I would like to "turn off" meteohubs calculation of SLP (which should be easy enough by setting station altitude to 0), but then apply my own formula for altimeter.

On the Meteohub's Settings page, I see the very familiar area for "Calibration: f(x) = a*x + b" where one can correct for sensor error...Is it possible to input complex mathematical expressions in the sensor calibration fleld or is meteohub expecting to see only integers?

This is the formula I would like to use

QNH = (Pa^N′ + K′ ha)^(1/N′)

where
QNH := altimeter setting
Pa := field pressure
ha := true field elevation
N′ := 0.1903
K′ := 1.313×10−5


This formula comes from http://www.av8n.com/physics/altimetry.htm (the formula is #11) and is what CWOP is expecting to receive. Out of curiosity, is this the formula you had previously tried without success?

BR,
David

[N5XL]

I know people have way more important things to work on than this minor issue, so I spent the past few days figuring out most of this for myself.

Answering my own question, the sensor calibration routine on the Settings page isn’t the appropriate place to make these kinds of calculations to raw data…its for adjusting sensors that need minor calibration tweaking. I knew this already, so why I asked if I could make data calculations there, who knows . The better way to do data manipulation is with a virtual sensor.

To create a virtual sensor that calculates Altimeter instead of SLP, I did the following.

1. Log into the MeteoHub system.
2. Click on Weather Stations and change Station Altitude to 0…select Save.
3. Click on Sensors and enter the following information in the Virtual Sensors section.
New ID. The virtual barometric sensor should have its NewID set to a ID that is available between thb0 to thb9. On my station, my real barometric sensor is thb0, so I set my virtual barometric sensor to be thb1.
Name. The virtual sensor can have any name you choose to give it. I gave mine Vthb. You could also give it Altimeter or even QNH if you choose.
Trigger. The trigger value must be set to trigger from the real barometric sensor…in my case my real sensor is thb0, so my trigger is set to thb0.
Conversion. Copy and paste the “awk code” listed below.

awk '{ printf ''%d %d %d %d %d %d'', $3, $4, $5, ((($6/338.64)^0.1903--0.000013126*(790*3.28084))^(1/0.1903))*338.64, $7, $8 }'

The above awk code and its imbedded formula must be changed to reference the exact elevation of your station. Note the part of the awk code that contains “790*3.28084”. 790 is the elevation of my station in meters. You must change 790 to be the elevation of your station, in meters, whatever it is.

4. Once you have entered the above values into your virtual sensor, click on “Save & Restart Data Logging”
5. Wait a few moments (15-30 seconds) and hit refresh to see if your awk code is being interpreted. You can tell if the code is being interpreted by MeteoHub if the “Sensor Data” field populates with information. If you see “Never” regardless of how long you wait and hit refresh, your awk code has an error.
6. Compare the results of your virtual barometers Altimeter result to your local airport(s) reported value for Altimeter. They should be exact or very close.
7. Click on Weather Networks and then choose the appropriate sensors to be used for data upload. For Pressure, use your new virtual sensor (thb1 in my case) and not the actual pressure sensor (thb0 in my case). Enter the appropriate credentials in the CWOP field (or the APRS field if you are a ham) and click on save.

You are now configured to upload Altimeter to CWOP.



The formula I used is as follows

QNH = (Pa^N′ + K′ ha)^(1/N′)

where
QNH := altimeter setting
Pa := field pressure
ha := true field elevation
N′ := 0.1903
K′ := 1.3126×10−5

And comes from http://www.av8n.com/physics/altimetry.htm



You’ll notice a couple of things with awk translation of the above formula.

((($6/33.864)^0.1903--0.000013126*(790*3.28084))^(1/0.1903))*33.864

1. The awk code contains extra steps that take the raw pressure data ($6) and converts the pressure data to imperial pressure units (inHg). Once the raw data is in imperial units, the awk code performs the calculations necessary to standardize local pressure to altimeter (QNH). After the standardization, the awk code converts the altimeter results back into metric units. These extra conversions steps are necessary because the formula used to perform the calculations uses imperial derived constants. Without these conversions ahead of time, the formula does not generate correct altimeter values.
2. The double dash “--“ in the formula is the equivalent of “+” and is necessary because of programming limitations with Meteohub.

Hope this helps someone in the future.

Dave

[admin]

Thanks for this great work. I did get stuck into formulas when doing a first attempt on this in 2010.
I could take the formula and make it the regular pressure value reported to CWOP. That would take
the burden from the users to insert the awk snippet.

[admin]

Putting that into c code does not report meaningful numbers.

Code: Select all

actual_thb0_press_hpa 1039.0
actual_thb0_press_psi 15.07
actual_thb0_press_mmhg 779.2
actual_thb0_press_inhg 30.68
actual_thb0_sealevel_hpa 1042.2
actual_thb0_sealevel_psi 15.11
actual_thb0_sealevel_mmhg 781.6
actual_thb0_sealevel_inhg 30.78
actual_thb0_altimeter_hpa 178.0
actual_thb0_altimeter_psi 2.58
actual_thb0_altimeter_mmhg 133.5
actual_thb0_altimeter_inhg 5.25

Any clue what goes wrong? I thought it is an 1:1 adaption of your awk code...

Code: Select all

double press2alt (double press, int height)
{
  return (pow ((press / 33.864), 0.1903) + (0.000013126 * 3.28084 * height), 5.25486) * 33.864;
}

Press is given in hPa, height in meters, result is expected in hPa.

[N5XL]

Hi Boris,

I found another formula that might be easier for you to implement in Meteohub. Reference for this next formula comes from the World Meteorological Organization publication called "Instruments and Observing Methods, Report 19, 1987" I call this formula the "Smithsonian" altimeter formula because the formula is supposedly derived from pressure adjustment tables contained in the Smithsonian Meteorological Tables. The good thing with this formula is that, while a tad more complex, it appears to work equally well with inHg or mbar pressure units. The only caveat I see is that measurements of station altitude cant change and need to be in meters only (not feet) which is no problem at all really.

"Smithsonian Altimeter"=(P-0.01)*(1+(((P0^N*a)/T0)*(H/(P-0.01)^N)))^(1/N)

where:
P= console pressure (mbar or inHg)
P0= 1013.25 mbar (std sea level pressure in mbar, use 29.921 if console pressure is inHg)
a= 0.0065(K/m)
T0= 288 (K)
N= 0.190284
H= station height (meters)


gawk code for meteohub
awk '{ printf ''%d %d %d %d %d %d'', $3, $4, $5, ((($6/10-0.01)*(1--(((1013.25^0.190284*0.0065)/288)*(826/($6/10-0.01)^0.190284)))^(1/0.190284))*10), $7, $8 }'
note: Since Meteohub appears to natively store pressure in hpa, I used the mbar value for standard pressure in the formula. Within the gawk code, console pressure ($6) must be divided by 10 as meteohub stores pressure as a whole number and not a decimal … ie 9214 vs 921.4
as a result of this conversion, final results for pressure must be multiplied by 10 to be expressed correctly. Also, the "--" takes the place of the "+" due to
limitations mentioned earlier.


If you want to play around with the Excel spreadsheet I have for both formulas, feel free to download it, as well as the meteorological references from my dropbox...
https://www.dropbox.com/s/pyxfrfyq6x8gi ... 0edit.xlsx
https://www.dropbox.com/s/3qpe1aqsugyyr ... tables.pdf
https://www.dropbox.com/s/3i5stes189o6y ... ic-AWS.pdf

[admin]

thanks for doing another try. this time my implementation brings reasonable numbers (station altitude is 27 meters):

Code: Select all

actual_thb0_press_hpa 1036.0
actual_thb0_press_psi 15.03
actual_thb0_press_mmhg 777.0
actual_thb0_press_inhg 30.59
actual_thb0_sealevel_hpa 1039.2
actual_thb0_sealevel_psi 15.07
actual_thb0_sealevel_mmhg 779.4
actual_thb0_sealevel_inhg 30.69
actual_thb0_altimeter_hpa 1036.6
actual_thb0_altimeter_psi 15.03
actual_thb0_altimeter_mmhg 777.5
actual_thb0_altimeter_inhg 30.61

Code looks like:

Code: Select all

double press2alt (double press, int height)
{
  double p = press - 0.01;
  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);
}

[N5XL]

Awesome! Thanks for working on this Boris.

I'm quite positive that the CWOP community greatly appreciates the efforts of you and other weather software authors to have Altimeter as a pressure adjustment when uploading to CWOP. It might not be known outside the CWOP community, but many stations erroneously send SLP instead of Altimeter to CWOP. This particular issue causes problems for CWOP members as they can get flagged for having QC problems with their data. Its often the case when a station starts getting flagged by QC for bad data and they start digging into the issue, that SLP and Altimeter conversions often show up as a problem. For the record, this is exactly how I discovered the SLP / Altimeter issue with my pressure data. I still have other station issues to address in order to resolve my QA problems, but this is now one less problem I have to deal with...the rest of my issues have to do with sensor placement which I hope to correct very soon.

As a tangent to this, I am starting to suspect the sensors in the WH2080 are not as robust and accurate as they should be. This is unfortunate as the Fine Offset units have an attractive price point. Even more unfortunate, the only way I know to solve that problem is by station replacement.

Regardless of my other sensor issues, I hope the formulas helped out in working on the Altimeter adjustments for CWOP.

Best regards,
David (N5XL)

[N5XL]

Boris,

If I enter 27 meters for station height and a local console pressure of 1036.0 into the "Smithsonian altimeter" spreadsheet calculator, I end up with 1039.3 for an Altimeter result. This is slightly different from your posted result of 1036.6.

I wonder if there are some rounding differences between the Meteohub code and the spreadsheet code?

I'll have a look at some of the local airports and plug in some of their data into the spreadsheet to see what I come up with.