Re: [weewx-user] Problem with Dewpoint and an out of calibration temp sensor

[Matthew Wall]

On 13 Sep 2013, at 18:39, Logan wrote:

> I have Weewx running on a RaspberryPi with a FineOffset weather station. The outside temp sensor is out of calibration so I added the calibration curve to weewx.conf and now my temperature data is good.
>
> I live in a area of California that gets frequent fog and found that the localhost website was reporting a dewpoint temperature higher than the ambient temperature. Can't happen. After digging around for a while, I found that for the FineOffset, the dewpoint is calculated in the fousb driver with the original, uncalibrated outside temperature. So I went into wxformulas.py and added code to do the calibration correction in the dewpointC module. This fixed the problem.

tom,

this seems to be a recurring issue. the corrections from weewx.conf are applied *after* derived variables are calculated.

should we make the corrections available to the drivers so that we don't have to define both driver-level corrections (e.g., pressure_offset in FineOffsetUSB) as well as post-loop corrections (the stuff from weewx.conf)?

or perhaps make an option in the StdCalibrate section to choose whether the calibration applies at the driver level (make this the default), or at the post-loop level?

to complicate things further, fine offset has added temperature calibration to the hardware as well in the A series starting in (at least) 2013.

m

[Andrew Milner]

For what it is worth my logical brain tells me that logically the correction facility is there to correct errors in the hardware values.  From this assertion it follows that any corrections should be applied as soon as the hardware value is received from the station and before anything else gets a chance to use what the station provided - which I guess puts it fairly and squarely as being required more within the driver's level especially if the driver is deriving some other values than anywhere else within the flows.  From that point on all derived values would/should be automagically correctly adjusted.  If one only brushes with programming and technology it is not always obvious which values are derived, on what stations etc etc - and all one can do is look at console values and calculate errors (corrections) and hope/assume all else will become magically correct!!

Guess this means that I agree with mw - but i guess it may also mean that all drivers would/should be tweaked to follow this more logical route.

[Thomas Keffer]

There's a couple of ways of doing this.

1. So far, I've avoided making the drivers into a service. They are just a bit of standalone Python code.

However, there are times when they do need access to the things a first class service offers. The Vantage driver is an example of this. I solved this by writing, as always, a standalone Python driver, then using multiple inheritance to derive from both the driver and StdService. This allowed access to the database, which I used to get the temperature 12 hours ago (needed to reverse calculate gauge pressure). It seems to be working well.

This suggests that all drivers could be derived from some StdDriver class, which would include calibration corrections. To make this work, we'd have to define a couple of new events, say RAW_LOOP and RAW_ARCHIVE that would give access to the raw, uncorrected data. StdDriver would hook into those events and apply the corrections. Then the driver is free to calculate any derived variables.

This approach would complicate writing a device driver. It would have to create the events RAW_LOOP and RAW_ARCHIVE.

2. Another approach would be to regard the driver as just a source of raw data. A follow on service would apply corrections, then an even farther downstream new service, call it StdDerived, would add any missing, derived data (if any). 

The advantage is that it basically keeps the existing architecture. It also gives the drivers one, simple chore: source raw data. 

Disadvantage is that these downstream services would have very limited context in deciding what to do. Any information about the type of instrument would have been lost by then.

I'll have to mull this over a bit. Any insights welcome!

-tk

m

--
You received this message because you are subscribed to the Google Groups "Weewx user's group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to weewx-user+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--

Tom Keffer

kef...@threefools.org
+1 541-386-8891 (h)
+1 541-490-9507 (c)

Skype: tkeffer