Hello Matthew, On Monday, March 9, 2020 at 10:26:56 AM UTC-4, mwall wrote: > > bill, > > for hardware that can be configured to send data in different unit types, > you have to either: > > a) in the driver initialization, set the hardware to the units that you > want, then hope that no one changes it while the station is running >
That's what I'm doing now except that it's not possible to configure the station via an API so the driver is just trusting the returned units are the right ones. > or: > > b) in every loop packet check the unit type for each observation, then > convert (if necessary) to the units in the usUnits system of your loop > packet > > option b requires more calculation, but it is much more robust. and > unless your hardware sends data more frequently than 10 times a second (or > even 100 times a second?) it will have no affect on performance. > Actually, since I'm writing the driver to interface with the Columbia MicroServer computer which in turn interfaces with the Pulsar 600 hardware, that computer is doing all the heavy lifting. So this driver just polls the MicroServer computer at an arbitrary interval and downloads the data. Since there's no configuration API, the driver can't easily be used to configure the MicroServer, So I'm trying to make the driver as robust as possible so no matter what units of data is thrown at it, the results will be correct and predictable. Right now I'm using a polling interval of 10 seconds to download the XML data but only with the expectation that eventually the skin I'm using will be able to display frequent updates for wind data. Since wind data is the only type that can benefit from very frequent updates, my thought at this point is to return one packet each polling interval just containing windSpeed, windDir, windGust and windGustDir and specify the units for the loop packet to whatever unit type is returned in the XML for the windSpeed. For the rest of the data, return it every 60 seconds. I have an idea on how to implement this using two packets -- one for US units and a second for metric units. The logic for this approach should be only slightly more complex than converting all the data to a common unit type. > m > Also, using your IP-100 driver as a starting point turned out to be a good decision. This driver is structurally the same as that one as I was able to make most of the changes within a few of the existing methods. The hard parts were porting it to also work with v4 and Python 3 along with updates to the exception handling as the hardware returns corrupt XML from time to time. Thank you, -Bill -- You received this message because you are subscribed to the Google Groups "weewx-development" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-development/013591bb-0ddb-4bfd-b0a3-7a34c3d87c26%40googlegroups.com.
