I think maybe I may have mislead all of you with my problem. There isn't a problem, as far as I can tell, with either the driver or WeeWx conversion to US units itself. The problem comes after the conversion when say the sum function adds the converted numbers (in my case 16 significant digits numbers) then apples the standard %6.2f floating number formatting to the template output. This cause the sum to be rounded up to the second decimal place. In my case, the total RAW December rainfall is 0.32598425... which becomes 0.33 inches in the templates. None of this is technical wrong and most of the time the results come out "right".Plus there is a margin of error with the actual equipment it's self so I hesitate to calls this a bug or error because in reality it's likely not.
However, It looks weird when say looking at the NOAA summary and you were to add the daily precip together (by hand) you would get 0.32 not the reported 0.33 inches. Also if you were going to compare your local records to that sent to Wunderground the results would be different 0.32 instead of 0.33 in my case. This only happens a couple time of year at the most at least with the precip totals. The only reason this happens is that the floating number formatting causes the results to round up. So again there is nothing technically wrong with the software. I think a possible solution could be if some where within the software, where the calculations are done, that if the units are in US then the results returned should be a float with no rounding applied. Thus, 0.3259 inches would return 0.32 inches instead of 0.33 inches when using say the $month.rain.sum tag. I guess this could also be achieved too within the driver code itself but rather than updated all the drivers code it might be easier to just do it within the weewx software itself. I don't know enough about the weewx code to know which would be better. I hope this makes a little more sense. On Sunday, December 18, 2016 at 1:50:16 AM UTC-7, gjr80 wrote: > > I would hazard a guess that 0.518 came from empirical testing given the > value. However it was derived is irrelevant; that is what the driver uses > and somewhere between the input to the driver and the output to the > database something appears amiss. I would be surprised if it was anything > in the weewx conversion routines, that would show up elsewhere and I > suspect not so subtly. That leaves the driver, probably one for Matthew. > > Gary > -- 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.
