My Journey into Reverse Engineering my Weather Stations RF Protocol

Motivation

My main motivation for the mission was:

  • Viewing the live data without the need of the console.
  • Sending the data to the universe (websites/databases/Jupiter) for research purposes.
  • Pay it forward, I paid for weather data acquisition software stack that works wonderfully but surely there must be a cheaper and more fun way...
  • Manufacturers non response to a friendly protocol request.

Devices Used

  • AWR WH2303 weather station
  • Software Defined Radios (Airspy, RTL-SDR)

Getting the Correct Centre Frequency

The first step is getting the correct centre frequency in your favourite spectrum analyzer. From here, we deducted the centre frequency is 433.92MHz.

Receiving and Decoding the Signal with rtl_433 and URH

We used rtl_433 to receive the signal and URH to process the waveforms and make sense of the parameters of the signal.

Recording the Signal

File > Record Signal. We used our RTL-SDR (RTL_433) in conjunction with an Airspy (URH) for capturing the recorded signal to have the same signal demodulated data to compare to.

Analyzing the Signal in URH

The recorded signal in URH’s Interpretation window. The signal cropped.

Modulation and Bit Length

Modulation is detected as FSK, but we change the view from Analog to demodulated. The bitrate seems incorrectly detected, so we get a bit length of 150µs long and enter it into the bit length parameter field. The output data is exactly the same as the rtl_433 output!

Identifying the Rx IC and Configuring the Packet

First step, identify the Rx IC involved by opening the weather console (receiver). Turns out to be a HopeRF RF31S (rebranded Si4330). We located the spec sheet.

Packet Configuration

We assumed packet handler was activated and proceeded to figure out which of the 5 configs it uses.

Known Properties of the Signal

  • Packet length: 25 bytes (fixed)
  • Bit Length: 150µs
  • Packet length in time: 28.32ms
  • Encoding: NRZ

We discovered an RF forum entry that specifically uses the Si4330 and its direct mode configuration. There, we found that the sync word is 2DD4 in direct mode and the preamble is AA + AA. We searched for the binary value 0010110111010100 (2DD4) in URH’s Analysis window and found it located at 42-57 (exactly 16 bits and in the same place every single time). With this discovery of the sync word, we can safely assume that the receiver is configured using direct mode (packet handler disabled), in which there is no default CRC (you’d have to set it explicitly).

Figuring Out the Preamble Length

Next step is to figure out preamble length with the help of the datasheet and URH to see which configuration preamble length uses.

First Mode

The first mode is used with a preamble length of 32 bits and a settling time of 1 byte (8bits). We can remove this bit with a cut off filter.

Decoding the Signal in URH

We then apply this decoding to the data in the analysis window to align the data to always have the same order following the 40-bit preamble and create a consistent output with packet capturing that always starts with aa aa aa…

Identifying and Decoding Weather Sensor Data

These steps involved capturing a single packet at a time and using the latest information from the meteobridge application live data tab.

Temperature and Humidity

We identified the Rx IC involved, opened the weather console (receiver), and observed that temperature is a value from -40C to 60C with a 0.1C resolution, which relates to 1000 units of change from start to finish (or a 10-bit value). We then calculated the constant 400, which is the 40°C temperature offset for temperature.

Wind Direction

We selected the bit range preceding humidity and assumed it was temperature. However, we found that it was actually wind direction. We observed that when the wind direction value in degrees goes over 255 (767 in the bit range), the significant bit switches over to 1 and the 12-bit range starts counting from 512 again but this time subtracting 256 instead of 512. We labeled these ranges to have their values visible on the message type window with other sensors.

Rain Rate

The rain has been scarce in Cape Town, but during this walkthrough, we got a wonderful thunderstorm with 11.1mm of rain for the evening. This provided us with an opportunity to watch where the rain sensor could be. We observed that there was some change in the range of 132-139 (an 8-bit value). It seems when there is no rain, like in messages 3 and 4, the value sits at 112. When there has been some rain but not enough to trigger a 0.3mm/h reading, this value sits at 136, and the preceding 8 bits shift from 8 in decimal value to 17. With the next signal back at 136 and the Rain Emptying at 8 again. We can assume 136 is our constant for when rain is active.

UV and Light

We then went back to the roof, armed with black electrical tape, and decided to interfere with the weather station's sensors a little bit. First, the UV sensor, then the light sensor, and finally removed the UV sensor and lastly the light sensor. This experiment yielded the following results.

UV Sensor

UV falls in the range 141-152, and the light sensor in the range 154-169. METEOTABLE: 3

Light Sensor

So UV with a value of 2654 falls within 2292(6) and 2734(7), giving us a UVI of 6, which also corresponds with the data in Meteotable 3. The light reading of 9644 corresponds with the 958W/qm of Meteotable 3 (the difference seems to be the chip on the console has less precision than the x64CPU on my computer).

Conclusion

I seem to have found most of what I was looking for and would still pursue the rain sensor when the occasion permits. Here is my URH project file for anyone with any Fine Offset WH2300 weather station clones that would like to contribute to figuring out the rain sensor. It would be nice for integration in rtl_433 to be able to send the weather data to any website without the need for extra hardware and software. Once I can make sense of all the data in the bitstream, I will construct a C program to work with the rtl_433 interface (this is currently in progress). I’ve finally put the full specification sheet on this article, I will see if I can still compile the rtl_433 library and read through the device template spec and see if some JSON object can be made for weather data… HuzZah