Go Down

Topic: Intercepting 433Mhz from an OS WMR86 Weather Station (Read 3011 times) previous topic - next topic


Mar 29, 2014, 11:50 pm Last Edit: Apr 01, 2014, 10:14 am by robwlakes Reason: 1
Hi folks,
Quite a significant  update on my progress with the Oregon Scientific weather station, and how to make further use of a good system by intercepting the signals with an Arduino Uno and a basic 433MHz Receiver. Put the LCD receiver on the kitchen bench and Arduino in the garage carrying out your ultimate instructions.

There are a few improvements (eg the checksum routine is now correct), a few discoveries (eg bit 7 on rolling code is "new device"), the timing has been double checked (how do we really know for sure though?) , some things remain problematical (ie rain calibration, not so easy), other things are still unknown (eg low battery indication, amongst others), and some things are the same (eg 433+Uno, humidity and atmospheric pressure sensors, and delays, not counting interrupts).

The format of the program has been altered considerably to gather the readings as the sensors send them, and then combine the readings into a single CSV line output every minute on the serial port.  This was how my previous Bios/Thermor unit did it, and it made logging in the www server's Python program simple but effective.

There is also plenty of comments on all things to to do with the protocol, and a few left over debugging routines, that others may find useful if adapting this code to another situation, or just useful in general, so I will leave them there for people to use as they see fit.

As I have indicated above I still have quite a few questions to answer, and even if what I reckon I know is OK, it still deserves scrutiny so please tell me gently if there are any glaring errors or suggestions for improvement, otherwise enjoy!

Latest Version:  my_Origo_24.ino
Learning Flute and C++, heading for a meltdown.


Apr 19, 2014, 01:07 pm Last Edit: Apr 19, 2014, 01:09 pm by robwlakes Reason: 1
Not sure exactly what I am doing with github, but any assistance would be appreciated if so deemed to be required.

I have published the latest version on github (on my son's advice)
And the main upgrade is very simple but hugely important.

Up until now I have programmed the Rx algorithm to find a minimum of 20 Header Hits before accepting any bit stream as legitimate.  I have since become aware that my program would "flat line" the anemometer for hours on end (when the Temperature and Rainfall which both use about 90% of the same code happily continued on, and what was different was trivial).

I believe at the moment the expectation of at least 20 clear Header Hits was too much and the 433Mhz Receiver may have been stabilizing its AGC quicker on some days than others (and therefore changed the number of header hits the Arduino saw as legit) and this lead to the headers on the Anemometer signal being accepted for days on end, but suddenly, at other times, the Anemometer was "dropping out", ie digitally filtered out!!

After a while, if the RF reception got better, the AGC settled quicker, and the anemometer header bits once again exceeded 20, all  was fine. No flat spots, "signal" back to normal.  However it would seem that expecting 20 hits all the time was just too close to the cut off point, so I have changed the 20 to 15 and so far all is looking good (25% change).  This will give a better margin for error, and maybe even a lower number such as 10 may be even better.  I would be interested to hear of your experiences in this area, as I have spent many long hours chasing this problem.  It seem so obvious now!!!!

There are a few other improvements I intend to add once this major upgrade is proven to be correct.  Stay Tuned

Cheers, Rob
Learning Flute and C++, heading for a meltdown.

Go Up