Weather Software > WeeWX Software

Some more info for your AcuRite driver

(1/8) > >>

aweatherguy:
I've noticed that wind speed decoding is not quite right for the acurite.py driver and I think I've just figured out the proper decoding. See the post below for the details:

http://www.wxforum.net/index.php?topic=27244.0

Just my way of saying thanks for helping me with my own decoding on AcuRite through all the work that folks have put into the acurite.py driver. Hope this helps!

Cheers,
            aweatherguy

aweatherguy:
P.S. If you change the return statement in decode_windspeed function to this I think you'll be good to go:

return 0.8278 * (a | b) + 1.00

mwall:
thanks for that!  the implementation we were using seemed to be off a bit, but i never would have guessed the actual function.

the change will be in the next weewx release, which will probably be 3.2.2.

m

aweatherguy:
No problem. Don't forget about treating zero special...I probably should have posted this snippet instead. Don't know if I have the Python syntax correct, but the idea's there.

if (a | b) == 0:
   return 0.0
else:
   return 0.8278 * (a | b) + 1.00

aweatherguy:
Another update on AcuRite console decoding.

First I might be on to something in terms of being able to work around all the garbage that the 02032C console generates if you enable PC connect mode 3. I'll post more on this if it pans out (odds are probably around 50/50 at this point, but I'm certainly not counting on it).


Secondly, I've figured out two of the records in input report 3 -- with ID's 3 and 5. They are both time stamps, and I think that was already known. But what might be useful is knowing that ID 3 is the last time a history record was stored, and ID 5 is when the history query was received. So far, ID 5 always seems to be later than ID 3 but never by more than 12 minutes (the history update interval).

So, why is this useful? Well, if for instance ID 3 says the last time history was updated was 9/2/2015 10:01 and ID 5 says the history request time is 9/2/2015 10:08 it means that you could have requested history 7 minutes earlier and still gotten a current update.

In summary, you can use the difference between time stamps on record IDs 3 and 5 to fine tune your timing when querying history updates. This way you can be sure to get history updates that are say less than 1 minute old instead of taking you chances and maybe winding up with an update that's 11 minutes old.

So while this may or may not end up working on 02032C consoles, if the other consoles (w/o the firmware problem) still emit record IDs 3 and 5 it would be useful in dealing with them.

Navigation

[0] Message Index

[#] Next page