Makes sense. I am well aware that this Acurite is low end hardware, and honestly, I am pleasantly surprised how well it has worked over the past year with Weewx. I figured I would have more issues than this. I guess it is great software development and community involvement ... :) I have some torrids laying in a junk box somewhere that I could use to lessen the chances of RFI on my USB cable. When I'm down in my basement, maybe I'll poke around for them. But, it is probably just the Acurite console spitting out some bogus values every once in a while. I would like to see if it is random bogeys or some repeatable pattern.
If you would like for me to capture raw data to try to see if there is a spurious pattern, I'd be glad to do so to further help the Weewx project. I've applied debug logging along with [Acurite].debug_raw=1 and if it pops up again (two weeks?) we'll go from there. Now, to monitor logs today and adjust my logrotate just in case my logs fill up with extra logging turned on. Let me know if there is something else you would like me to do. Thanks. On Friday, December 2, 2016 at 6:24:39 PM UTC-6, mwall wrote: > > chris, > > each 'rain counter decrement ignored' is a spurious value for rain. the > acurite console sends a value that looks like a counter wraparound. the > next value ends up looking like rainfall. > > it is not clear whether the root cause is a bogus 5n1 unit sending the > wrong value, the console borking a value it gets from the 5n1, or something > else. it could even be interference in the RF or USB comms. > > this is not uncommon on low-end hardware like acurite. > > there is no fix for this - the acurite firmware cannot be updated. but > here are some workarounds: > > 1) use MinMax in StdQC to eliminate large values. unfortunately, this > will not eliminate spurious small values, as you have seen. and we have > existence proof that the spurious values are not only large. > > 2) figure out whether the decrement is a real decrement (wraparound) or a > spurious value. you could set debug=1 and [Acurite].debug_raw=1 to capture > all of the raw data. when this happens, record the raw R1 packets. > capture a bunch of them then see if there is a pattern to the spurious data > that we could recognize. > > 3) if we see a counter decrement, retain the value of the decrement. at > the next rain increment, ignore the next rain increment if it is equal to > the decrement. this approach could work, as long as the bogus values are > consistent, i.e., each spurious decrement is followed at some point by a > spurious increment of the same value. to verify that this approach would > work, we need a list of the 'rain counter decrement' log entries, plus the > actual values for 'rain' in the database for the same time period. > > unfortunately, (or perhaps fortunately?) the acurite station i have for > testing (a 01036) has only ever produced spurious rain values when i've > been abusing its usb interface, and that is far from repeatable. so any > log/database correlations that you or anyone else seeing spurious rain on > acurite hardware can collect would help. > > if we can verify that any spurious decrement is followed by a spurious > increment of the same size, then we can fix the driver to recognize that > pattern. > > m > -- 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.
