Menu
Weather Stations Arduino Uno, 433MhzRx and Oregon Scientific WMR86 Weather StationThis project allows the 433MHz signals from an Oregon Scientific WMR86 weather station to be intercepted and decoded into simple decimal values using an Arduino Uno. The values for Wind Direction, Wind Speed, Temperature, Humidity, UV Light and Rainfall are then sent via the USB/Serial port on the Arduino to the host computer. In my case I use a Python program to interpret this CSV formatted string of characters and plot the above parameters for display on my website (Please note the DHT22 Humidity/Temperature sensor on the Arduino shield is not used in the my final data stream, but is decoded in the software, and so is the temperature read from the BMP05 air pressure detector. The externally mounted OS Temperature/Humidity sensor is used in my final data string. This can be modified to suit your own purposes).
The hardwareThe Arduino listens continually for the three WMR86 sensor's broadcasts (the UV Light sensor must be purchased seperately) and merges them every minute for an output of a CSV string. There are three transmitters in the WMR86 package, Wind Direction+Wind Speed (average and gusts), Temperature+Humidity, and Rainfall (cumulative total and rate).
WM-918/WX200 Weather Station Software. WeatherUpdate (FREE) - WeatherUpdate is intended to be used with Davis Monitor II, Oregon Scientific WM-918, and WMR-968. It manages all the communication to and from the weather station hardware and exports the current conditions to a varity of services and software. XASTIR (FREE) - is an APRS. Product Description. The Oregon Scientific WMR89 is a full weather station with USB and 7 day data-logger. Improving on the best-selling WMR88, the WMR89 wireless weather station represents great value and style.
They each have different periods between transmission eg Wind every 14 Seconds, Temp/Hum and Rainfall at longer periods. This does cause overlap of sensor transmissions and inevitable corruption of some packets, however the protocol does have a simple arithmetic checksum based on nybbles that helps eliminate most bad data. Admittedly the chance of substitution errors causing bad data to go un-detected is much higher than if a higher bit CRC based on a polynomial process was used. Range validation would be necessary (in the Python or Arduino) to check if the resulting readings were sensible to improve reliability. This program reports every minute for all three sensors whether a good packet has been received within that minute or not, so the Python program can sum the good and bad packets each minute and report the relative numbers each week in an email.The Wiring: A generic prototyping shield was used.Manchester ProtocolThe Ardunio algorithm to decode the Manchester protocol uses timed delays to sample the waveform from the 433MHz Rx and not interrupts and direct measurement of waveform transitions. This has a number of implications.
The main one is that Arduino is continually sampling and analysing the incoming waveform. As it is a dedicated processor in this application and has no other function, this is not a problem.
The benefit is that it does simplify the reception and analysis of the waveforms. The simple decoding strategy should also be worth studying by anyone else attempting to leverage other systems that use Manchester encoding. To that end a fairly lengthy explanation is offered below.The Manchester protocol is a bias neutral protocol where each bit is composed of a high and low signal of equal length (or close to it).
This means that a transmitter can be totally keyed off and on (ie the 433MHz signal is not partially modulated, but is either fully transmitting or 'silent')and no matter what sequences of data, 1's and 0's, are transmitted, on average the Tx signal will consequently be on for the same time as it is off. This means the switching point, or bias level, for the receiver amplifier remains steady. A data bit in a Manchester waveform always has a high and low signal component for encoding both 1's and 0's. So a Bit Waveform for a Data 1 is a high signal followed by a low signal (hi-lo), and a Bit Waveform for a Data 0 is a low signal followed by a high signal (lo-hi). For the OS Weather station each high and low signal duration are both about 430uS. So a full Bit Waveform will last about 860uS.
(As will be seen later, the tolerance for decoding these timings is quite wide).The cheap 433MHz Rx's available have a simple Automatic Gain Control and Bias Detection built in. The AGC allows the sensitivity to be maximised with low signals, and adjusted back when a stronger 433MHz signal is received. The Bias Detection allows the average of the output signal voltage to be determined and applied to one half of a comparator, the other comparator input has the received signal. With Manchester protocol the on/off ratio is equal, so the Bias Detection will be at the average voltage, ie approximately half way, consequently the transitions of the signal from on to off and back again, can produce quite clean, symmetrical logic signals with simple circuitry.
This Manchester decoding program relies on the timing of transitions, rather than the exact shape of the waveform (ie again it does not have to be a very clean square wave shape to work, as long as the transitions are accurate).In other words, the decoding program needs to be able to determine whether it has seen a 430uS 'no signal' followed by a 430uS 'on signal' and so has received a 0, OR has received a 430uS 'on signal' followed by a 430uS 'no signal' and so received a 1. 'on signal' makes the Rx amplifier output go 'hi' and 'no signal' makes the Rx output go 'lo'. How is this decoded?The first very important prior knowledge to have is which of the two polarity conventions for Manchester encoding this system uses. Arguments are put forward for both possibilities as being correct, but either polarity works as good as the other, and with a simple audio sampler, such as Audacity, is simple to work out. The transition polarity used by OS is that a Data 1 is hi-lo and Data 0 is lo-hi.However any hi-lo transition could be either the middle of a Data 1 Bit Waveform and mean a 1 has been sent, or possibly just the hi-lo transition between two Bit Waveforms, and as such not indicate anything. Similarly any lo-hi could indicate the middle of a Data 0 Bit, or again just a meaningless transition between two Bit Waveforms.
The following diagram illustrates the two Bit Waveforms. When these are connected up into a bit stream, then the red dots may or may not require transitions to connect them for the Bit Waveforms to reflect the data bits.
A simple example is provided underneath with the 4 possible bit sequences (10,00,01,11) shown and the incidental transitions marked in blue. If you are writing a Manchester Encoded transmitter then this is all you need to know to get started.Diag 1Curiously a long string of Data 1's will have the same looking waveform as a long string of Data 0's. Whether they are 1's or 0's depends on where we begin to analyse, we would need some sort of marker, or unambiguous beginning point.
And also surprising to begin with, is the sequences of data bits 1 to 0, and 0 to 1, do not have any signal change between Bit Waveforms. More information on that later.Critically the only guaranteed meaningful regular transition of states occurs in the middle of the Bit Waveform. Consequently is essential to concentrate the decoding algorithm around the center of the Bit Waveform to keep it properly synchronised. RF practicalities.Part of the practical application of the Manchester protocol combined with simple 433MHz Tx/Rx combo's is to use a header sequence of bits, usually 30 or so 1's. This quickly stablizes the Rx AGC and establishes the Bias Detection point so the simple 433MHz Rx has a good chance of settling down and producing a clean logic waveform after say 10 on/off transmissions. The decoding program can then sample the Bit Waveform by synchronising (ie looping and waiting) the program to an hi-lo transition, which is the midway point of a Bit Waveform for a 1.
This polarity is how it works for the OS protocol, hi-lo1, lo-hi0 (Wikipedia says the opposite polarity convention is also used by other systems, and both are just as valid).Graphic 1: The AGC is stabilising fairly quickly here. (Audacity Sample)This Diagram 2 below is showing a stream on 1's as the header. The algorithm is expecting a stream of Data 1's and to begin with, and is looking for any hi to lo transition on the Rx and assuming it is the middle of a Data 1 bit Waveform.
After detecting any hi-lo transition it begins to check the subsequent waveform. Graphic 1 is sections A,B&C in Diagram 2.Diag 2Diagram 2 illustrates the process of detecting a signal and locking into the data in the packet. From the lefthand side, A is showing static, or noise, and when a signal begins in B the AGC on the 433MHz receiver is stabilizing. Note that early on the program will try to lock onto the negative going edge as shown with the downward black arrow at the start of Phase C.
Phase C is the stream of 1's known as the header. Here I have illustrated that receiving fifteen 1's will indicate we have a valid header. Phase D indicates that we have more header bits than we need (this allows for some drift about the AGC starting point). So any excess 1's are then dumped until the bit pattern changes, when at Phase E the bit pattern for 0 arrives. From then on, Phase F (the remainder of the packet, NB not all shown) any number of data bits, 1&0's, can be received. Sometimes the E&F Phase are within the Byte pattern, and sometimes the start bit, E is excluded and it just flags the start, and the bytes begin at Phase F.
Extracting data from the bit streamHow does it know they are properly formed and timed Bit Waveforms? (Please refer to diagram 3 below, NB 7 Bit Waveforms are shown, only alternative ones are labelled).
To filter out noise, the input is sampled until a hi-lo event is detected eg at (B) and then again the program re-samples the Rx output about a 1/4 of a Bit Waveform later at (E), to see if it is still lo. If is lo (as the diagram shows) then it is possibly a genuine middle of a 1 Bit Waveform, however if it is not a lo then it was not a genuine hi-lo middle of a 1 Bit Waveform, and the algorithm begins the search for another hi-lo transition all over again. However if this preliminary test is true, it has possibly sampled a midpoint of a 1, so it waits for another half a Bit Waveform (F).
This timing is actually 1/4 of the way into the next Bit Waveform, and because we know we are looking for another 1, then the signal should have gone hi by then. If is not hi, then the original sample, that was possibly the mid point of a 1 Bit Waveform is rejected, as overall, it has not followed the 'Bit Waveform rules', and the search (looping) for then next hi-lo transition begins at the start, all over again. Here is a diagram to highlight the previous ideas.Diag 3The pink lines are the signal arriving from the 433MHzRx. The long vertical blue lines (eg at A & C) are indicating the start and end of some Bit Waveforms. These are partially covered by the pink signal trace if they coincide.
This diagram show 7 bit patterns. B is positioned at the middle of a Bit Waveform, and these are also indicated by the M's.