Question on Weewx, Vantage Vue, and CWOP

[Brent Dowell]

I've been chasing my tail a bit trying to get my data that I upload to CWOP to pass the madis checks, which, from what I've read is a bit problematic.

My question though is what should I have my console set as far as altitude and barometer reduction. Right now I have it set for my correct altitude and am using the altimeter setting. My readings are consistently 'low' compared to the madis QC Check.

It looks like to me that the values being uploaded are in fact low  (raw aprs data) and do not match whats on my console.  So it appears that weewx must be doing some altimeter calculation on my data and is sending that on to cwop? I'm wondering if I'm missing a setting somewhere in my weewx config to accout for that?

Some of the research I've done on the issue talks about davis being a bit of a pain because they out put the altimeter corrected data already and that setting altitude to 0 and using the altimeter reduction fixes it?

Sorry about dredging up an old issue, but I couldn't find much recent information on this.

Thanks in advance for any help.

[Tom Keffer]

I'm assuming:

1. That you have a Vantage console;

2. That you are using regular LOOP packets, not the newer LOOP2 packets;

3. That you are using hardware record generation.

If all this is true, then what's happening is that WeeWX is downloading altitude and temperature corrected barometric data (what pilots call QFF) from the console. However, CWOP wants pressure corrected only for altitude (not temperature; pilots call this QNH). So, WeeWX uses an algorithm to calculate that. This is then what is uploaded.

First thing is to make sure you have the correct altitude entered in your console. You will also want to know whether the console is applying any barometric corrections. Both can be checked using the utility wee_device, with the --info command.

wee_device --info

This will tell you what altitude your console thinks it's at, as well as any barometric calibration data.

-tk

--
You received this message because you are subscribed to the Google Groups "weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to weewx-user+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/d425ef32-4da0-49e1-b2d4-fd21dffdfbaen%40googlegroups.com.

[Brent Dowell]

Correct Altitude is entered.  

I'm getting an average error of 3.5 millibars.

My altitude is pretty close to the local airport, and I used a fairly calm day to adjust my barometer to match that.  Our altitude is also relatively close, i.e. the airport is 4403ft and I'm at 4410.  Althought that 4410 could be off, I had used that for my altitude for years.

Took another reading via gps today and have adjusted that to 4293, which seems like it could be a significant differences.

Thanks so much for your help in getting me to understand it.  I've managed to learn to ignore the wind errors, as I live on a hillside and don't see anyway my wind data will ever match.  if I need to do that for barometer, I'll work on it. lol.

Would just like to figure out what I'm doing wrong.

1. That you have a Vantage console;

     Vantage Vue Console

2. That you are using regular LOOP packets, not the newer LOOP2 packets;

     loop_request = 1

3. That you are using hardware record generation.

     prefer_hardware

From the wee_device command.

    BAROMETER CALIBRATION DATA:

      Current barometer reading:    30.222 inHg

      Altitude:                     4293 feet

      Dew point:                    24 F

      Virtual temperature:          32 F

      Humidity correction factor:   1.1

      Correction ratio:             1.175

      Correction constant:          +0.000 inHg

      Gain:                         0.000

      Offset:                       -16.000

   

[Tom Keffer]

The note Derived variables from Davis has a pretty good discussion of this.

To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/49100cc7-7e2f-478f-9065-f0f42a92db3bn%40googlegroups.com.

[Brent Dowell]

Thanks again!

[Garry A Lockyer]

And this document explains why GPS altitude sucks (to be polite!):

http://www.montereysar.org/SARMembersDocs/UsingaGarminGPSwithPaperLandMaps_Manual.pdf

Regards,

Garry Lockyer

C: +1.250.689.0686

E: Ga...@Lockyer.ca

On Jan 10, 2021, at 18:05, Brent Dowell <brent...@gmail.com> wrote:



To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/9c6cfc66-af04-4813-83cc-8fc021e39074n%40googlegroups.com.

[Brent Dowell]

Yeah, The first time I got the altitude I used a garmin gps and left it running to average the altitude For a while.

Guess I'm just going to learn to deal with it.

[Garry A Lockyer]

All that will get you is an average of crap altitude!  😀

Any agreement between GPS altitude and true elevation is merely a coincidence.

Regards,

Garry Lockyer

C: +1.250.689.0686

E: Ga...@Lockyer.ca

On Jan 10, 2021, at 18:33, Brent Dowell <brent...@gmail.com> wrote:

Yeah, The first time I got the altitude I used a garmin gps and left it running to average the altitude For a while.

To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/d4d43848-17c1-430e-9be1-665cdd974d58n%40googlegroups.com.

[Nate Bargmann]

* On 2021 10 Jan 20:02 -0600, Tom Keffer wrote:
> The note *Derived variables
> <https://www.davisinstruments.com/product_documents/weather/app_notes/AN_28-derived-weather-variables.pdf>*

> from
> Davis has a pretty good discussion of this.

Thanks, Tom.

I have a Vantage Pro2 and I see this:

$ sudo wee_device --info
Using configuration file /etc/weewx/weewx.conf
Using Vantage driver version 3.2.1 (weewx.drivers.vantage)
Querying...
Davis Vantage EEPROM settings:

CONSOLE TYPE: Vantage Pro2

CONSOLE FIRMWARE:
Date: Jun 3 2013
Version: 3.15

CONSOLE SETTINGS:
Archive interval: 300 (seconds)
Altitude: 1327 (foot)
Wind cup type: large
Rain bucket type: 0.01 inches
Rain year start: 1
Onboard time: 2021-01-11 04:37:42

CONSOLE DISPLAY UNITS:
Barometer: inHg
Temperature: degree_F
Rain: inch
Wind: mile_per_hour

CONSOLE STATION INFO:
Latitude (onboard): +39.9
Longitude (onboard): -96.8
Use manual or auto DST? AUTO
DST setting: N/A
Use GMT offset or zone code? ZONE_CODE
Time zone code: 6
GMT offset: N/A
Temperature logging: LAST
Retransmit channel: OFF (0)

TRANSMITTERS:
Channel Receive Repeater Type
1 active none iss
2 active none temp (as extra temperature 1)
3 active none (N/A)
4 active none (N/A)
5 active none (N/A)
6 active none (N/A)
7 active none (N/A)
8 active none (N/A)

RECEPTION STATS:
Total packets received: 6411
Total packets missed: 90
Number of resynchronizations: 0
Longest good stretch: 751
Number of CRC errors: 12

BAROMETER CALIBRATION DATA:
Current barometer reading: 30.344 inHg
Altitude: 1327 feet
Dew point: 23 F
Virtual temperature: 29 F
Humidity correction factor: 0.7
Correction ratio: 1.052
Correction constant: -0.024 inHg
Gain: 0.000
Offset: -24.000

OFFSETS:
Wind direction: +0 deg
Inside Temperature: +0.0 F
Inside Humidity: +0 %
Outside Temperature: +0.0 F
Outside Humidity: +0 %
Extra Temperature 1: +0.0 F


In this case, 1327 feet is the height of the console including its
height above ground level which is stated to be 1318 feet by Google
Earth and topographical map estimation.

The closest airport with a reporting station is about eight miles
east/southeast from here and I have the console set to match its
pressure reading as shown on its NWS page. Its elevation is stated to
be 1283 feet, so 44 feet lower than my console.

I've never been exactly clear from the Davis documentation just who I
should be doing. My guess is that the 44 feet and eight mile difference
is probably inconsequential on a clear sunny day like this. The
difference likely is greater under more localized conditions such as
when a squall line moves through.

My goal is to "color" my data as little as possible and my station does
report to CWOP and seems to get satisfactory marks from MADIS.

- Nate

--

"The optimist proclaims that we live in the best of all
possible worlds. The pessimist fears this is true."

Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819

[Tom Keffer]

If you're concerned about the distance to the airport, you can take your console to the airport --- it's battery powered.

In addition to my Vantage, I have a precision barometer that I use for sailing (±0.25 hPa precision). I've calibrated it against the Portland airport, which is very close to sea level, then brought it home, and calibrated my Davis consoles.

The onboard barometer of an iPhone is also surprisingly accurate. Use the Starpath app to calibrate it near an airport, then bring it home. 

There are lots of approaches. Best to do all of the above, then triangulate the results.

-tk

--
You received this message because you are subscribed to the Google Groups "weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to weewx-user+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/20210111202418.nefk6sla3prmrovx%40n0nb.us.

[Nate Bargmann]

* On 2021 11 Jan 16:09 -0600, Tom Keffer wrote:
> If you're concerned about the distance to the airport, you can take your
> console to the airport --- it's battery powered.

Well, that seems like a novel idea! :-)

Wouldn't doing so take a few hours? The Davis literature appears to
suggest so.

> In addition to my Vantage, I have a precision barometer that I use for
> sailing (±0.25 hPa precision). I've calibrated it against the Portland
> airport, which is very close to sea level, then brought it home, and
> calibrated my Davis consoles.

My guess is that's not cheap. Funny how these rabbit holes seem to
swallow excess cash!

> The onboard barometer of an iPhone is also surprisingly accurate. Use
> the Starpath

> app <https://www.starpath.com/marinebarometer/about.htm> to calibrate it

> near an airport, then bring it home.

No iPhone, but I have a couple of Android 10 phones.

> There are lots of approaches. Best to do all of the above, then
> triangulate the results.

Interesting thoughts, Tom.

[galfert]

Stop saying that the airport is at the same elevation or at different elevation from you. That is extraneous and irrelevant information.

Use this sight to find out your elevation:

https://www.freemaptools.com/elevation-finder.htm

If you don't have the latest firmware then you may not have Loop2 data. Not having Loop2 data will inhibit greater Altimeter calculation by WeeWX because station pressure will be missing and it will have to work backwards and that is less accurate. Better to send the software station pressure which is done by having Loop2 data.

Do not attempt to constantly calibrate your station with the airport. It is perfectly normal for there to be times when your pressure and the airport are experiencing different pressures, meaning you'd both be right by each showing what is occurring at each location. If you want to know why then study isobars. I wrote this little piece which might introduce the subject, but I think you should read more about it to fully grasp the concepts.

https://www.wxforum.net/index.php?topic=36579.0

There are also other reasons than isobars when the pressure could be different between your location and the airport and that has to do with differences in equipment and how pressure is calculated internally by the hardware. Different times of the year when the average temperature is at extremes will also cause for more discrepancies. Therefore the best time to calibrate your barometer is when:

• when the METAR indicates the pressure is very near 1013.25 hPa
• at the top of the hour when METAR data is most current
• when the pressure is steady
• when it is midday
• when it is good weather
• when the temperature outside is close to 15°C (least critical)

[Nate Bargmann]

* On 2021 12 Jan 13:40 -0600, galfert wrote:
> Stop saying that the airport is at the same elevation or at different
> elevation from you. That is extraneous and irrelevant information.

I am merely attempting to be factual as I'll admit to being still a bit
confused as to what unit the METAR from my airport shows, whether
barometer or altimeter. No matter, I shall not concern myself with that
any longer.

> Use this sight to find out your elevation:
> https://www.freemaptools.com/elevation-finder.htm

I think Google Earth is better for this purpose as the satellite view
lets me pinpoint my house exactly. This site has not such view that
I've seen and there is a hill side from the west around to the east and
even being 100 yards off can mean a difference of 20 to 40 feet, maybe
more, of elevation.

> If you don't have the latest firmware then you may not have Loop2 data. Not
> having Loop2 data will inhibit greater Altimeter calculation by WeeWX
> because station pressure will be missing and it will have to work backwards
> and that is less accurate. Better to send the software station pressure
> which is done by having Loop2 data.

According to the Davis site the latest firmward for the Vantage Pro2 is
3.15 and wee_device reports my console is at 3.15. I have not specified
which LOOP data WeeWX is to use as I assume it is coded to use the best
available format.

> Do not attempt to constantly calibrate your station with the airport. It is
> perfectly normal for there to be times when your pressure and the airport
> are experiencing different pressures, meaning you'd both be right by each
> showing what is occurring at each location. If you want to know why then
> study isobars. I wrote this little piece which might introduce the subject,
> but I think you should read more about it to fully grasp the concepts.
> https://www.wxforum.net/index.php?topic=36579.0

I set the Correction Constant to 0 last night with wee_device and right
now the airport shows 30.08 and my station is at 30.09. However, there
is a falling tendency right now. I plan to leave things as they are and
let it run for some time with no correction.

> There are also other reasons than isobars when the pressure could be
> different between your location and the airport and that has to do with
> differences in equipment and how pressure is calculated internally by the
> hardware. Different times of the year when the average temperature is at
> extremes will also cause for more discrepancies. Therefore the best time to
> calibrate your barometer is when:
>
>

> - when the METAR indicates the pressure is very near 1013.25 hPa
> - at the top of the hour when METAR data is most current
> - when the pressure is steady
> - when it is midday
> - when it is good weather
> - when the temperature *outside* is close to 15°C (least critical)

Thanks.

[galfert]

If you want better calibration precision than the 0.01 inHg you are getting now then switch to hPa (which are the same as millibar). When you calibrate using hPa you can be more precise. But you don't have to permanently switch to seeing hPa, rather this is just an exercise during calibration of the console. Then when it is dialed in you can then switch the console to showing you inHg if that is what you prefer and the calibrations done while under hPa are still realized.

Use this site to convert units while calibrating.

https://www.convertunits.com/from/hpa/to/inhg

Although you probably won't need to convert pressure units if you use a METAR data website like NOAA Aviation Center because that should show both units.

https://aviationweather.gov/metar/

Do know that for locations with elevation higher than 3,000 feet that barometric calibration is a bit more of a challenge.

[gjr80]

Assuming can be a dangerous business! If you have not specified anything for loop_request then you will be using LOOP1 only (the default), whether that is the ‘best available format’ depends on your circumstances I guess. Should you happen to specify loop_request = 3 in order to get the best of both worlds (by alternating between LOOP1 and LOOP2 packets) be aware that this can cause WeeWX loop packets to alternate between hardware provided and software calculated values for station pressure and altimeter (and archive records will then have a blend of both). If you do use loop_request I suggest you carefully read the loop_request stanza in the User’s Guide.

Gary

[galfert]

Gary,

That is very interesting and possibly important information. Is what you mention dependent on the type of logger used? Meaning is the data switching (LOOP1 / LOOP2) still an issue with the WLL?

[gjr80]

I have no WLL experience so short answer is I don’t know. 

But the loop_request setting is a vantage driver setting, as far as I know you need to use a different driver for WLL. Also, there are a number of WLL drivers; looking at one just now I see it appears to emit pressure and altimeter, though as I said I don’t know enough about WLL to draw any conclusions.

Gary

[galfert]

Well then this seems to be a big limitation for any Davis station that is not using a WLL!  Seems like the WLL is a better solution than other loggers and then ending up with a mess of combined calculated and received values for barometric pressure. Unless it is possible to set things so that Altimeter is only calculated during LOOP2 reads, and to only accept sea level during LOOP1. I'm not sure if that makes sense or if it is even possible, nor what ramifications messing with all this entails nor what the other undesired results may be.

Bottom line....seems like WLL is a better way to get complete live data from the station.

[galfert]

For anyone confused or not able to follow along....here is the premise of what Gary and I are discussing.

Davis LOOP1 data in terms of barometric pressure only sends corrected sea level pressure.

Davis LOOP2 data in terms of barometric pressure only sends station pressure (atmospheric pressure).

CWOP requires Altimeter pressure which needs to be calculated. The best way to calculate Altimeter is to have station pressure (atmospheric) that you only get from LOOP2. If LOOP2 is not available (not turn on or using old firmware) then the station will only send sea level pressure to WeeWX. This will then require WeeWX to back track and try and figure out what station pressure is ...and then use that value to then calculate Altimeter and that is not very accurate of a process. You can't send LOOP1 sea level to CWOP...not the same.

[vince]

Thanks for the summary (it helps), but I'm missing what actual problem this thread is trying to solve.

I've had my VP2 since jan'2009 and have ancient firmware on it. I've run weewx for many years with the Vantage driver, doing nothing special to tweak what it generates nor how.   I've fed CWOP equally for many years 'with' that data.  CWOP has always been happy with the data as far as I know.

If I look at my data from CWOP online (https://mesowest.utah.edu/cgi-bin/droman/meso_base.cgi?stn=C6881) it looks like they have my actual and corrected pressures there.   So is there a problem ?

[galfert]

It is probably not much of an issue for you at 364 ft of elevation. But stations at greater elevation like the OP at 4400 ft, that do not receive station pressure data from the console will have a more difficult time properly calculating Altimeter pressure since their consoles only provide sea level pressure. Calculating Altimeter by way of Sea Level pressure is convoluted and adds yet another factor of data accuracy problem. Calculating Altimeter pressure is enough of a issue already for stations at high elevation to then also need to contend with figuring out what station pressure is if it is not provided....that is two strikes against the best data possible. You can't do anything about your high elevation but if you could actually have the most precise station pressure it would help.

[gjr80]

Not at all. If you blindly set loop_request = 3 then yes your archive record pressure values (as well as some other obs) may end up being a combined hardware/software value. If you read the loop_request stanza it warns you of this and points out the solution.

Gary

[gjr80]

Just to clarify, the LOOP2 packet actually includes all three pressures. So if using loop_request = 2 you will get all three pressures from the console in both loop packets and archive records. Nothing will be calculated. The combined hardware/software archive record issue occurs when using loop_request = 3 and the stream of loop packets emitted by the driver then consists of an alternating mix of barometer only packets and barometer, pressure and altimeter packets.

Gary

[Brent Dowell]

This Loop2 packet disc has, I believed solved my issue. I was using the loop1 packet, even though my console and it's firmware version does support it.

I had been using a VERY old version of weewx up until a couple of months ago when I upgraded and put it on a raspberry pi.

So far so good, setting it to use the  loop_request = 2   seems to be working

Thanks!  Now I can deal with fine tuning my altitude and calibration.

This thread has been a big help!

[galfert]

Okay thank you for the correction on LOOP2 and what it includes. But do see now from the link referenced that LOOP2 is missing some optional sensors that some users may have. 

Seems like WLL is still a better way to go. But I realize that is not the subject matter of this thread.

[galfert]

Excellent, glad things are looking better. Good luck.

[Les Niles]

On 12 Jan 2021, at 12:12, Nate Bargmann <n0...@n0nb.us> wrote:

* On 2021 12 Jan 13:40 -0600, galfert wrote:

Stop saying that the airport is at the same elevation or at different
elevation from you. That is extraneous and irrelevant information.

I am merely attempting to be factual as I'll admit to being still a bit
confused as to what unit the METAR from my airport shows, whether
barometer or altimeter.  No matter, I shall not concern myself with that
any longer.

METARs from an airport will always have the altimeter setting, because that’s what pilots care about.  At least in the US it is given in hundredths of an inch, prefixed with “A”.  For example

KWVI 130053Z AUTO 00000KT 10SM CLR 13/07 A3031 RMK AO2 SLP263 T01280072

the altimeter setting is 30.31”.  METARs usually also contain the pressure corrected to sea level; that’s the string that begins with “SLP” and gives the pressure in tenths of a millibar, without the hundreds and thousands digits.  “SLP263” = 1026.3 millibar.  (Note that the 30.31 altimeter setting in that METAR corresponds to 1026.5 mb, so they really are different values.)

  -Les

[Greg Troxel]

gjr80 <gjrod...@gmail.com> writes:

> Not at all. If you blindly set loop_request = 3 then yes your archive
> record pressure values (as well as some other obs) may end up being a
> combined hardware/software value. If you read the loop_request stanza it
> warns you of this and points out the solution.

It strikes me as at least suboptimal that an alternating stream of
LOOP1/LOOP2 packets leads to calculating values from LOOP1 when those
values are present in LOOP2. Stepping back, I would view LOOP1/LOOP2 as
a data transport protocol and view the most recent report of a value
received as valid for some short interval, perhaps 5 nominal LOOP times.
Basically, if something is in LOOP2 and that is received as often or
almost as often as it should be, don't try to use a computation from
LOOP1.

Note that this comment is from looking from away, disregarding how the
software works now. And I realize ENOPATCH :-)

[Tom Keffer]

If you look in the documentation, you'll see that it suggests using hardware settings for pressure, altimeter, and barometer. That way, there will not be a problem of alternating between hardware and software computed values.

--
You received this message because you are subscribed to the Google Groups "weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to weewx-user+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/rmiczy8oqet.fsf%40s1.lexort.com.