Go Down

Topic: Opinions on intercepting 433MHz from Oregon Scientific WMR200 Weather Station (Read 7 times) previous topic - next topic


Newflash: Working program to decode V3.0 OS Anemometer/Temp/Rain sensors attached below.  ;)

Well it had to happen, my dear old Bios Weather Station has dropped the bearing in the Anemometer and the whole thing is due for retirement immediately.  I don't want to buy another cheapy such as the Digitor line, nor go overboard price wise with a Davis System (and for me at least, unknown protocols).  The Oregon Scientific stations seems to be a sweet spot in between.   Minimum sensors for my setup are - external temperature, wind speed, wind direction and rainfall.  The WMR200 ticks those boxes and has the advantage of solar assisted power supply to promote battery life.   Arduino suppling air pressure and humidity readings itself.

However, regardless of brand, I do want to definitely keep the strategy of my own Arduino base station intercepting the 433MHz from the OS sensors to provide the interface to my web server.  I will just put their LCD version on the kitchen bench.

So what are people's opinions of this line of Weather Station gear in terms of the value/reliability/accuracy trade off???  What is also extremely important is, how successful have been people been, especially in the Arduino community, in intercepting and decoding the Oregon Scientific protocols?  I had read some promisinghttp://wmrx00.sourceforge.net/Arduino/OregonScientific-RF-Protocols.pdf www material and https://github.com/phardy/WeatherStation, but a bit more detail about analysing the more complex sensor combinations such as the WMR200 would be appreciated.


PS is there an updated version after the WMR200 around? Is it the WMR300? Does it use the same simple keying (OOK) 433MHz/Manchester protocol? Has anyone had a crack at it? 50% more costly here in Australia and reminds me of a Davis product in style at least.
Learning Flute and C++, heading for a meltdown.


Depends a lot on what you are trying to do.
Its easy to decode the data thats transmitted from Oregon sensors so that you can receive them using an Arduino and then display them on a PC which is connected to the Arduino.
Have a look here.
The weather shield is an Arduino based program that can decode the WMR100, 200 series of sensors.

If however , you want to make your own sensors and have them displayed on a Oregon console , then thats a lot harder to do
as there is information in the data that is sent from genuine OS stations that is not fully understood as to its function.
Ive built 2 Arduino weather shield decoders and they work fine .
Ive also made some of my own sensors, mainly temp / humidity ones and they also work fine when used with the Weather shield.


Thank you Mauried for your interest in this topic. That link certainly has some very impressive data processing.  My weather site is deliberately simplified, and designed for a simple fisher like me to quickly asses the previous 12 hours of weather and make a decision whether to go out or not.  However that does not make the actual decoding of the sensors any easier.  So any assistance will be appreciated.

I bit the bullet and bought an Oregon WMR86 for about $220 (Aus) when I could not beat the price down on a WMR200 that was missing CD and Manuals and was a shop window display model.  I tried to explain I did not need that stuff but they were only prepared to knock 10% off their price of $450 (Aus). Saying that I am an Arduino programmer and that I was the ideal person to unload this gear on did not have any cred' at all.  :0 I did not need the USB+Touch screen features on the WMR200 anyway.  The Solar power was the only extra that was really attractive.

I have already reverse engineered an Arduino based Bios weather system program, using the Manchester encoding (Opposite polarity to the Oregon Scientific).  I was also able to design my transmitter to it and was much simpler than than the receiver! I am planning a similar extension to the Oregon project already, even though I have not written one line of code, to make up my own outside temperature sensor that my Arduino can detect (same as you I would guess), that also has the full Lithium/Solar rechargeable system built into it as well.  The Oregon system on the WMR200 gave me the impression it just took over from the batteries in the day time and the batteries were drained at night time, so it only extended the battery life, and not truly recharged them.  Am I correct there?

Thanks for responding, I may ask some help of you soon.  I pick up the challenge this afternoon.

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


You can cut the costs of OS sensors down by buying them directly from the US.
The prices in Australia are extremely high compared to the US prices.
I use a company called Price USA to do this , as OS in the US wont ship to Australia..
Ive managed to build a clone of a THGR810 temp / Hum sensor which does get decoded Ok on my OS weather stations
and also by a weather shield Arduino based decoder.
Ive got a WMR100 & a WMR80, but its not Arduino based.
Made it long before I learnt about Arduinos.
Its based on a Microchip 16F88 and is written in basic , not C .
Ill eventually get around to a C version.
OS do some funny things to the data that their Sensors transmit, to make it hard for people to make the sensors.
Guess they want to protect their product.


Working WMR86 433Mhz Interception with Arduino
Hi Mauried,
Sorry to be off the air for so long but the brain has tackled the WMR86 V3.0 protocol and I now have a working version.  I have used a different approach to the other programs I have seen, in that I use delays to decode the Manchester data, rather than interrupts, counts and limits.  Conceptually it is simpler programming, and seeing this is the Arduino's main task, I can keep the interrupts for alternative tasks such as a timer to output my data to my WWW Weather site every minute.  I have tried to make this version (below) just a generalised version that other people can easily adapt to the their own needs, just as I am about to do for my own project. I have been able to correct a few things and hopefully not add too many errors of my own. I certainly invite any corrections or helpful suggestions :)  For any one attempting to add extra (arduino or R-Pi etc) receivers to their OS sensors this program should be easy to adapt to their need,s and there is plenty of documentation on protocols, timings, calibrations etc.

I can now have my LCD Base station in the kitchen and the Arduino/Web server in the garage, with no need for messy USB stuff into my Python/Apache2/Ubuntu Server!!!
So it appears I have nearly replaced my old Bios WS with the much nicer kit from Oregon Scientific.  These weather stations are very well engineered for the price and I am looking forward to more accurate results.

I will be getting my air pressure and Humidity from interfaces on the Arduino shield (see Photo and schematic below).


PS Now have my OS-WS "on-air" and happily bedding it in over the Xmas/NY, I will post a listing including internal temp, air pressure and humidity, closer to NY 2014.  I was looking for a backup anemometer and noticed OS are discontinuing the WGR800.  Now is that true?  Have I chosen another endangered species???
Learning Flute and C++, heading for a meltdown.


Hi Folks,

Just an update.  I had a setback with my Oregon Scientific equipment.  I noticed the Wind Direction Vane had dropped the LSB bit and was only reporting every even number between 0-15  (N to NNW), so it was operating at half accuracy.  My wind direction maps were looking very ordinary with wind never arriving from the odd numbers (eg NNW,NNE etc)  and this was creating bands across the map.  Obvious to anyone something serious was wrong.

I did not want to take the Anemometer/Direction Vane combo down over the Xmas break (our peak tourist season) and decided to use the range of numbers reported as an average and hence interpolate the directions coming from the odd numbers.  At first I used a simple average of the last (rolling) 16 samples recorded, and took its integer value( from 0-15).  Suddenly the map was looking good again.  Then I remembered why I had not done this before, the cross over region between direction numbers 15 and 0 (ie NNW to N) do not yield good results with just a simple average.  eg 8 readings of 15 (NNW) and 8 readings of 0 (N) produces a simple average of 7.5 ie SSE, the opposite direction to what is should be  :~

With the help of my son Nicholas, we implemented a "circular average" program in Python, using Sine, Cosine and Atan2.  A demonstration Python Code and circular averaging explanation is on this page http://www.laketyersbeach.net.au/windaveraging.html and the resulting map of the wind direction (plus other weather parameters) is on this page http://www.laketyersbeach.net.au/weather.html.  So out of the difficulties comes a much better system.

Why have a wind direction map and not a circular "radar" style graphic? Read here http://www.laketyersbeach.net.au/winddirection.html.

The graphics indicates the Arduino project with the extra Humidity and Barometer features are working well.  I am waiting for rain to check my calibration figures on the rain gauge and I will establish a new thread with all the latest code added.  We are in the middle of the Australian summer and rain is a scarce commodity  :smiley-roll-sweat:.  So if you are waiting, please be patient.


PS Good news is Oregon Scientific (Australia) are replacing the Anemometer/Direction Vane with out any problems, so I bought a back up as well.  I am very happy with their support and service.

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


Nice job! For an alternative exposition on circular mean:
and for higher order directional statistics:
"It seems to run on some form of electricity"


I got  Lacrosse/TechnoLine Weather Station WS2355 and also few cheap 433Mhz receivers [1] and antennas for them [2] but I have found out that they have really small range, they work only in same room upto 3m/10ft, anything beyond that they stop receiving data when connected to arduino...

Original  WS2355 receiver works through thick indoor walls upto 30m/100ft, which is quite impressive.

This is original receiver in WS2350 weather station, thin wire is antenna:

I'm looking for good 433Mhz receivers that I can connect to Arduino and collect data from weather station, but one that has good range, because these ones I got are really bad for anything beyond few meters...

Are there shops that sell finished 433 rx modules, or some ebay shop that sells internationally? Ebay is definitely preferred because of price and also easy worldwide shipping. There are quite few US based shops that have crazy shipping prices, so rest of us outside of US can't use them :(

[1] http://www.ebay.com/itm/121117930415
[2] http://www.ebay.com/itm/371027094605


You may have conquered the challenges with the Lacrosse (I hope so) , but I would like to add some extra info that I have found out about my Arduino+433Mhz Rx intercepting an Oregon Scientific WMR98 weather station.

I had my weather station dropping out and just giving flat lines on the a graph for hours on end, ie the reception of the Wind Speed/Direction Sensor in particular was borderline reception.  However after much, much teeth gnashing I figured out that I had programmed for at least 20 header bits had to be received before being accepted as valid, and this must have been just borderline, as for many days the graphs were great and then for too many times the wind sensor would go "off line" for hours on end and then mysteriously fix itself!!!

By dropping the requirement for a valid header to 15 Bits it has improved the reliability no end.  So it would appear that my initial suspicions were right but my solutions were wrong.  I was moving the Arduino around to get better reception, and to some extent this was probably working, though only to a very small degree.  I believe the requirement of 20 header hits was just marginally inside what was required.  When the atmospheric conditions changed and the AGC on the 433Rx changed and therefore reduced the number of valid header hits that could be detected, they had dropped below the threshold, and the Wind data just appeared to drop out!!!!\

So rather than blaming the OS sensor and it RF power or the Arduino+Rx combo for not providing a good RF link, it has been the logic in the program. But the solution was as simple as changing a number from 20 to 15.  But still a major revision none the less.

So now it only requires 15 header hits rather than the borderline 20 to validate a header sequence.  Maybe only 10 would be better????

In short, from my humble experience,  "just check your code" before you blame the 433 connection.


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

Go Up