Phil, I guess its a collection of a number of things, largely I think it will be accumulated rounding errors on the data from when it comes off the hardware to when it is stored in the database. Hardware will be providing data to a couple of decimal places at best, drivers at the very least convert it to floating point numbers and probably do some arithmetic on the data eg maybe do some unit conversion. WeeWX then takes that and maybe converts it again to a different set of units depending on your database unit system. If you are using software record generation then your archive database is some sort of aggregation (eg average, sum) of your loop data over the archive interval. Sure WeeWX could truncate to x decimal places before saving to database but then that is another processing overhead/complexity for little gain. The data will still be stored in the same format field (REAL) in the database so it is not going to save any database space. The saving grace is the WeeWX formatting system where report results are displayed in a user defined format. Pretty rubbery answer I know but its a pretty rubbery issue :)
Gary On Friday, 10 August 2018 09:36:50 UTC+10, Phil Owers wrote: > > > > On Thursday, August 9, 2018 at 7:47:02 AM UTC+1, gjr80 wrote: >> >> A little clarification on the use of the special observation 'wind' may >> be warranted. >> >> As per the Wind section <http://weewx.com/docs/customizing.htm#Wind> in >> the Customization Guide WeeWX stores wind data in two distanct forms. >> Firstly windSpeed, windDir, windGust and windGustDir are stored as >> scalar values in the archive (provided your station emits them) just as any >> other observation. There are also corresponding daily summary tables that >> are used as an optimisation for long period stats such as $month, $year or >> $alltime if implemented. Again these function as per any other >> observation. Wind data is also stored in vector form but only in the ' >> wind' daily summary (ie not in the archive). This allows stats such >> 'what was the direction of the highest speed wind observed today' or this >> week, or month or year etc using a single tag. If this special vector form >> was not used then when you use something like $month.windDir.max (or >> $month.windGustDir.max) you will likely get 359 or 360 degrees, >> certainly not the direction of the wind during the 50km/hr gust that >> occurred yesterday. >> >> The upshot of this is that the special observation wind can only be used >> with the daily summaries. Many are not aware, but the daily summaries can >> only return data for a midnight-to-midnight, first ever record-to-midnight, >> midnight-to-last record or first record-to-last record periods. That is the >> daily summaries only store data as a summary for the day, they can't use >> part days unless it is the first day or last day of data stored in the >> database. $month.xxx, $year.xxx almost always use a midnight-to-mdnight >> boundary or first record or last record boundary. However, other tags such >> as $span and $trend aggregate over a period that does not fall on the >> boundaries supported by the daily summaries (well a $span over a delta >> that is a multiple of 24 hours would at midnight each day but that is not >> really usable) and in such cases the archive is used. But we don't have the >> special observation wind in the archive so hence >> $span($year_delta=5).wind.max will fail everytime except at midnight. >> >> So that is why $span.wind fails but $year.wind does not. Likewise as outTemp >> exists in the archive and the daily summaries, when you try to obtain an >> outTemp >> aggregate that does not sit on the boundaries supported by the daily >> summaries, WeeWX automatically drops back to the archive because outTemp is >> in the archive (try doing a $span on outTemp over a very long period >> that is not on a midnight boundary - the query will take some time as the >> archive is being used not the daily summary). The solution to the >> $span.wind issue is to use windSpeed, windDir etc or use $alltime. This >> means that it is not possible to display 'the direction of the highest wind >> speed seen in the last 36 hours' using a single tag, it will require some >> messy querying of the archive to find the highest wind speed seen in the >> last 36 hours and then finding the corresponding wind direction (again from >> the archive) at that time. Easily doable in a search list extension and >> could probably be done with some in-line template code but likely more than >> would be expected of a novice. >> >> Hope this goes some way to explaining why things did not work as expected. >> >> Gary >> >> > Thanks Gary for the explanation and for Pat for telling me about the > alltime. Have now successfully loaded alltime and find some strange > historical readings. > > This leads me to my next point while looking in the weexe.sdb database > notice that some readings (not historical) go to several decimal places as > an example rain could be 0.0 for several entrees then you can see > 0.00237293739 I have seen upto 15 decimal places. This has happened on > Wind, wind direction, dewpoint and rain and then they return to normal. > Just seems a bit random and odd. Is this something that could be fixed. > THanks Phil > -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
