Thanks for the clarifications. Just a quick note, since it's off-topic: one can build a receiver using an arduino clone and several cheap parts under $10 total (including baro and T/H sensors for indoors) that's compatible with the driver. So SDR is more work and less functionality, even if it's very interesting. It would be even more interesting if it was capable of receiving the transmitters without hopping using a sufficiently wide band.
On Tue, Oct 4, 2016 at 2:55 AM, mwall <[email protected]> wrote: > > > On Saturday, October 1, 2016 at 10:01:37 AM UTC-4, kobuki wrote: > >> -- "... rainRate should not be in the driver at all. the hardware >> reports a value that is arbitrary, and the rainRate calculation is yet a >> different arbitrary calculation ..." - well, the rf packets provide a raw >> value, which we convert to rainfall/time period values. What do you mean by >> arbitrary here? I agree it should be done in a single unified way, though, >> to be able to provide comparable results across devices. >> > > the algorithm implemented in meteostick.py is simply: > > 3600.0 / time_between_tips * rain_per_tip > > that could be implemented generically in StdWXCalculate. however, > time_between_tips could be a problem; most hardware does not report the > time of the last bucket tip (some sensors do not tip). > > so for now leave rain_rate in meteostick.py, with the StdWXCalculate > options of hardware/software to enable/disable it. > > >> -- We only fully process the raw radio packet data. I'm still of the >> opinion that just because the machine readable values come handy sometimes, >> we shouldn't keep it. It's sparsely reporting certain values and generally >> use unknown converison algorithms (even if they are accurate and correct, >> we have no way to tell). I'd say as part of the simplification, we should >> drop it entirely from the driver. >> > > agreed - drop it at some point. > > > >> Not completely related, but is there an SDR driver with comparable >> functionality? I think it wouldn't be a bad idea to use one as the radio >> capture part and adopt the rest of the current MS driver for the decoding. >> >> > the weewx-sdr driver parses output from the rtl_433 program. however, it > looks like rtl_433 does not yet recognize output from davis sensors. > > you might want to pick up a 20$US sdr dongle then send a pr to the rtl-433 > project with the davis decodings. > > someone should make a cheap usb pressure sensor, then the pressure sensor > plus the sdr dongle would be an inexpensive replacement/backup for just > about any weather station console. > > m >
