Go Down

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


Dec 08, 2013, 05:11 am Last Edit: Oct 30, 2017, 11:20 pm by robwlakes Reason: Updated software and hardware information now on GITHub.

Update Update Update: For the latest version of this project please use my GITHub site:

ArduinoWeatherOS for software and hardware updates. eg RGB LED status indicator and design your own sensors.

Historical and Archival relevance follows:

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:


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.


However I recently added a UV detector from OS and found its RF connection was decidely flakey.  It is a well built device and taking it apart was somewhat difficult, but I managed it.  After numerous checks and trials of the internals over a number of weeks I concluded the spring wound internal antenna in the sensor housing was made of very stiff wire and had very little give in it. Once I had removed it and replaced it with a 170mm length of hookup wire that exited out of the lower side of the housing, the connection was perfect and quite robust.

The antenna was glued to the body of the sensor and the RF board inside the sensor was screwed to a pannel held in by more screws.  My guess is the antenna's conection to the PCB was too rigid had broken the copper track off.  As a result it had become an intermittent connection.  That is, worked when I had played with it, and gone bad with the hot and cold of outside temperatures.

So just to contradict myself above, sometimes it is the 433MHz connection that needs to be investigated.

Also look up my GitHUB Site for more infor on how to design your own sensors, and add an RGB LED for a status indicator.  Very handy for debugging any connection problems, hardware or software.

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


Hi !

My WMR80 is dead today :(

Your arduinoWeatherOS is well working but... I have 2 extra THGR810 (thermo/hydro) that are not detected by the software.
Can you help me to modify it ?


I should read before to post !!

Modifying the header hits len parameter, TGHR810 is well detected...
Now I have to decode channel to differentiate the probes

Thanks for your work


You are most welcome. It is a pleasure to share. This is one of my most personally rewarding  projects.
This another one, a print your own weather station https://www.thingiverse.com/thing:2849562
Cheers, Rob
Learning Flute and C++, heading for a meltdown.


Hello Rob,

First, thank you for your great contribution! I'd love to use your code to read wind, temp and RH from a OS WTGR800. I built my hardware using a 433Mhz receiver like this one:


Put the batteries on my WTGR800, and start monitoring the outputs, and while debugging:

while (digitalRead(RxPin) != tempBit) {
    if (digitalRead(RxPin) != tempBit) {
      noErrors = false;
    else {
      byte bitState = tempBit ^ polarity;
      if (digitalRead(RxPin) == tempBit) {
        tempBit = tempBit ^ 1;
      if (bitState == 1) {
        if (!firstZero) {
          if (headerHits == headerBits) {
        else {
      else {
        if (headerHits < headerBits) {
          noErrors = false;
        else {
          if ((!firstZero) && (headerHits >= headerBits)) {
            firstZero = true;

          Serial.println("Al ADD");

I get to the points 1,2 and 3, but I'm not able to get to 4 and 5, shall I try changing any of the Variables for Manchester Receiver Logic?

Any help will be very much appreciatted!
Stay safe!


Hi Disco,

If your code is executing up to 3 but not what is after then it is detecting transitions on the input form the 433Rx, but the transitions are not following the Manchester wavefor protocol and getting rejected. This could mean your signal is non existent and you are listening to noise or maybe the protocol is not compatible. I rigged up a piezo transducer (not a buzzer) across my 433MHzRx first off and listened to the buzzes made by the signal. I could hear the buzz and look for activity on my sensing software to see if it synchronised (and I was making progress).

It your code is completing and stopping at 4 then it is responding to Manchester looking level codes to some degree.

I have looked up another project on the web and it says that your system is Protocol V3


So it should be possible to test it with code/project that I have at:


It has the full OS V3.0 decoding (as best as I knew at the time) so should give you a leg into solving this problem. However when you use it you will need to defeat this "IF" block

Line 641   if ((scan&7)==7) {   

Just change it to  if (true) {    so that the test no longer matters.

This test was added so that the Arduino would not report back any readings until it had logged all of the sensors (it is waiting for three sensors here bit mapped flags ie temp/Hum, Wind Speed/Direction and rainfall). This delayed startup for a maximum of 45 seconds as the rainfall sensor had the longest delay between transmissions. It meant when the Arduino sent off a CSV string back through the USB/Serial connection to the Raspberry Pi, all the signals that were graphed by the RPi were valid and I did not suddenly get readings of zero air pressure for example (not so good!!)

I have not known of the existence of this wtgr800 system. It looks very compact and well designed. If you use this code it provides the mathematical calculations for the different sensors as well. OS Sell their rain gauge on its own so you could add that for a full system.

I have since worked out a better algorithm that is based on a module for getting bits and the calling module for assembling them into bytes (this is the one you are looking at with "addbitstate()" in it). It makes the Manchester idea so much easier to follow. I should really update all of them, but I find Git-Hub a real pain to do anything confidently with. So the one I have recommended above to try and at least use it for the OS protocol and structure of the data packets to help you unravel your particular model.

My system has three separate sensors Temp/Hum, Wind Direction/Speed and Rainfall (plus now UV) so involves a seperate 433Tx in each and each has its own protocol, byte/bit length etc. So the Arduino+433Rx listens and decodes all of them. If they collide it just sees an error and waits for another try. They have different durations between their transmissions, so they only collide very now and then and within the next minute it should be ok. Seeing your system combines Temp/Hum/Wind Speed/Direction, it may have its own protocol, ie put it all into one packet?? You may have tinker with it considerably to get it right.

Things to to try once you are sure you are getting a header and the first start bit is to defeat the error checking and extend the number of bits to see what data you are collecting. Use HexBinDump to printout the contents of the receive buffer (which you have to enlarge) to see if you can find data patterns that change when you change the sensors, eg spin the anemometer by hand, or choose another direction.

Sleuthing these things can be great fun (beats Crosswords and Sudoku hands down each time, it actually does something!!!) and will be very keen to see you get it working and maybe share the results of your findings with me. I am very curious about your sensors!!!

Cheers, Rob

PS Your receiver is a regenerative receiver, a super regenerative receiver is better as it gives greater sensitivity and better noise reduction. But if you are using yours at close range at the moment for testing purposes it should be fine. I did all my preliminary testing with one.
Where the Tx and Rx have crystals on the board rather than manually tuned coils are better.

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

Go Up