WMR180 Weather Station Protocol and Data Format

See the main page for the WxTools overview

The following information is neither authoritative nor based on an official specification. No guarantee is given as to its accuracy.

Overview

This page describes the format of protocol messages used with the Oregon Scientific WMR180 Professional Weather Station. In terms of interface, the WMR180 appears to be compatible with the WMR100 (and probably also the WMR88).

Data is sent to/from the weather station via a USB interface that links wirelessly to the WMR180 base station. The USB interface appears to the operating system as an HID (Human Interface Device, normally something like a joystick).

Although there is little original work in the following, it is provided because specific information about the WMR180 is currently scarce. It aims to present in a readable way the results found by other people for the WMR100 weather station. Sources of the information here were:

WMR100 and WMR200 Protocol Decoder (an extremely useful Excel spreadsheet, though it does not always agree with the WMR180 due to differences between models or perhaps errors in the spreadsheet)
a description of the WMR100 Protocol from www.dg1sfj.de
Weather Station Data Logger (the WMR100 code was helpful in working out certain aspects of the protocol)

Although not used in this work, the following is also relevant:

Oregon Scientific RF Protocol Description

Values

In the frame descriptions that follow, numeric values are in hexadecimal. '?' denotes a value with an unknown purpose. A whole byte is given a symbolic name like B1, with bit 7 as the most significant and bit 0 as the least significant. The quartets in a byte are given symbolic names like Q1Q2, with Q1 as bits 7-4 and Q2 as bits 3-0. Pairs of bits in a byte are given symbolic names like ABCD, with A as bits 7-6, B as bits 5-4, C as bits 4-3, and D as bits 1-0.

Measurements are reported in the following units, irrespective of the actual console display units.

Battery Level: 0 OK, non-0 low
Direction: 0 N, 1 NNE, ..., 14 NW, 15 NNW (wind)
Pressure: mb (absolute, relative)
Rainfall: mm (rainfall), mm/h (rainfall rate)
Relative Humidity: %
Sensor Index: 0 indoor, 1 outdoor, else other sensor
Sign: 0 positive, non-0 negative (dewpoint, temperature, wind chill)
Trend: 0 steady, 1 rising, 2 falling (humidity, temperature)
Temperature: Celsius (dewpoint, heat index?, regular, wind chill)
UV Index: 0-2 (Low), 3-5 (Medium), 6-7 (High), etc.
Weather: 0 partly cloudy, 1 rainy, 2 cloudy, 3 sunny, 4 ?, 5 snowy (forecast, previously)
Wind Speed: m/s

Commands

USB data is sent in blocks that have a command code byte and relevant parameters, padded out to 8 bytes. Depending on the USB interface software, this may be preceded by a report code byte (normally zero). Relevant commands are as follows. If no sensor data is received for some minutes, the following pair of commands should be reissued to keep sensor data flowing from the weather station.

Initialise Request: 20 00 08 01
initialise the weather station
Data Request: 01 D0 08 01
request the weather station to send live data as it becomes available

Responses

USB data is received in blocks that have a byte count and relevant data, padded out to 8 bytes. Depending on the USB interface software, this may be preceded by a report code byte (normally zero). The byte count indicates how many of the following bytes should be used as data (e.g. a count of 2 means that only the following 2 bytes should be used). Input data from the weather station arrives in bursts roughly every minute, using data it has previously accumulated.

The data from these USB blocks needs to be concatenated into one input stream. Input frames are extracted from this stream. The frame structure is as follows, the length being implied by the response code:

FD FD ST RC D1 ... C1 C2

FD (frame delimiter): FF
Two of these delimiters start each frame.
ST (status): 00-FF
Identifies the battery level, for example.
RC (response code): 00-FF
Identifies the type of sensor.
D1 ... (data): 00-FF
Sensor data.
C1 C2 (checksum bytes): Add all frame bytes as unsigned integers, excluding the delimiter and checksum bytes. For a valid frame, this sum must equal C1+256*C2. Since this is quite a weak checksum, it is also advisable to check that a frame has the length implied the response code.

The actual frame data depends on the type of sensor. The frames and lengths below exclude the frame delimiter and checksum bytes. The parameters shown are most, but not all, of those found by others.

Anemometer (9 bytes): B??? 48 ??D1 ?? G1 A1G2 A2 C1 CSC2
Battery Level B, Wind Direction D1, Wind Speed Gust (G1+256*G2)/10, Wind Speed Average (A1+16*A2)/10, Wind Chill C1+256*C2 with sign given by CS
Barometer (6 bytes): ?? 46 ??A1 FCA2 R1 PRR2
Absolute Pressure A1+256*A2, Relative Pressure R1+256*R2, Weather Forecast FC, Weather Previously PR
Clock (10 bytes): ?? 60 ?? ?? MN HR DY MO YR ??
Time HR:MN, Date DY/MO/YR
Rain Gauge (15 bytes): B??? 60 R1 R2 H1 H2 D1 D2 C1 C2 MN HR DY MO YR
Battery Level B, Rainfall Rate R1+256*R2, Rainfall Recently (cleared at half past the hour) H1+256*H2, Rainfall for Past Day (i.e. 24 hours) D1+256*D2, Rainfall since Last Clear C1+256*C2, Time of Last Clear HR:MN, Date of Last Clear DY/MO/YR
Thermo-Hygrometer (10 bytes): BT?? 42 ?HSS T1 TST2 HM D1 DSD2 I1 ?VI2
Battery Level B, Temperature Trend T, Relative Humidity Trend H, Temperature (T1+256*T2)/10 with sign given by TS, Relative Humidity HM, Dewpoint (D1+256*D2)/10) with sign given by DS, Heat Index (I1+256*I2)/10 with validity given by V (bit 5 as 0 valid, 1 invalid)
UV (4 bytes): B??? 47 ?? UV
Battery B, UV Index UV