Receive Buienradar BR-1800 weather station on RFM69 and Lora modules

My local sailing club has a Buienradar BR-1800 weather station with its indoor unit in the start/finish venue. There it is inaccessible to the sailors. I have some past experience in weather stations. I was the first to receive FSK signals from a WH1080 weather station. Before that time OOK was the modulation of choice. As sailor I actually want to be able to read the local wind and direction, preferable also from home. So I set out to make this weather station internet connected.

I started googling on to my surprise I found only questions of people who wanted to connect this to for example Domoticz but no easy solutions that I could reuse. Later I learned that there is an implementation which is copied by one or two others. That was after the fact!. Googling on reverse engineering or rf protocol for the BR-1800 I found two useful pieces of information. The first indicated that the BR-1800 is a Fine Offset WH-2300 and it had two spreadsheets with the RF protocol (RF properties and packet format). Searching of WH-2300 did not result in more knowledge. The second interesting information was a picture of the internal PCB that showed a footprint of the radio module used. I quickly recognized that as a HopeRF RFM22.  

 

The FSK signals are compatible across a range of HopeRF radio’s. Together with the protocol spreadsheet there was enough information to get me started. I pulled a STM32-based Jeenode Zero with RFM69 radio form the box and set up a PlatformIO environment using the jeelabs/Jeeh library as a lib_deps. With reusing some code and register settings form my earlier WH1080 work I was able to quickly make a receiver implementation.

So I went to the sailing club (sailed a bit first), opened my laptop and after a few minutes I had received the raw data of several packets. Back home! After studying a bit and comparing to the expected protocol I noticed that the payload was too short and I actually recognized it. I hooked up the WH1080 packet decoder and indeed, WH1080 / WS400 signals. There is another station at the club, maybe on a boat. But I should have received Buienradar BR-1800 signals as well. Same frequency and bitrate.

The next day I went back to the club and decided to inspect the indoor unit. It had no reception of the outdoor unit. So I took a long ladder and removed the outdoor unit and brought it home. checking the batteries learned that the rechargeable NiM-hydrides were completely flat. So much for a solar recharging system. After fixing this and hooking up the Jeenode Zero again I started receiving the signals. After tweaking a bit with preamble and syncword detection settings I was receiving over 80% of the transmitted packages. Next step: Decoding.

As the format is clearly related to the WH-1080 and using the rf protocol spreadsheet it was not too difficult to write the decoding algorithm. The CRC turned out to be the same as for the WH-1080. By now I had realized that this outdoor unit “architecture” is actually better known as WH24. There are some FCC records for clearance in the USA. Searching on WH24 I finally found  source code in Benjamin Larsson repository. In this file details of the protocol and decoding can be found. I used this to “compare notes” and copied code to derive the UV-index. In the end it turns out that the BR-1800 uses a different UV-index scale. 

After hooking up the Jeenode Zero with RFM69 I started to receive some packets. With some tuning of preamble and syncword detection I receive over 80% of the transmissions. At this point in time I have a working implementation. 

RF69 #17: 24 3c ce 62 19 63 0f 03 00 02 00 00 00 00 00 a9 c9
r 116 l 2 a-1525

checksum  ok crc  ok
ID: 3C, T=13.7°C, relH=99%, Wvel=2.1m/s, Wmax=3.4m/s, Wdir=206°, Rain=0.6mm, UV=0, UVindex=0, Light=0.0, battery ok

The final goal is to connect the Buienradar BR-1800 with wifi to the internet. ESP32 is a very useful solutions. They are available with HopeRF (RFM95/RFM96) and SemTech (SX1276/SX1278) Lora modules. So would a Lora module be able to receive the FSK modulated signals. The answer is yes which I will explain in a next post.

Source code will become available on github/sevenw after finishing the project and some cleanup.

 

WH1080 protocol V2 – FSK

The Fine Offset weather station switched over to a new RF transmission protocol somewhere in 2012. While the old protocol was a On-Off-Keying (OOK) protocol, the V2 protocol used Frequency-Shift-Keying (FSK). This is natural transmision mode of the RFM02 transmitters and their RFM01 receivers. The RFM12B modules can also receive the same FSK signals. Most of the reverse engineering happened on the Raspberry Pi forum: WH1080 V2 protocol decoded

This post details on the exact transmission protocol.


Package definition:
[
preample 3 bytes 0xAA    synchron word    payload 10 bytes  postample 11bits zero
0xAA    0xAA    0xAA     0x2D    0xD4     nnnnn---nnnnnnnnn 0x00     0x0
101010101010101010101010 0010110111010100 101.............. 00000000 000
]
repeated six times (identical packages) per transmission every 48 seconds
There is no or hardly any spacing between the packages.
Spacing: to be confirmed.

When using the RFM01 or RFM12B, the preample and synchron word will not be in the received data. The preamble is intended to have the frequency synthesiser locked, while the synchron word serves as detection of the proper message.
Open issue: How can an end-of-transmission be detected? Would VDI turn into zero?
The payload contains to types of messages for FO WH1080, and relatives:

Payload definition:
Weather sensor reading Message Format:
AAAABBBBBBBBCCCCCCCCCCCCDDDDDDDDEEEEEEEEFFFFFFFFGGGGHHHHHHHHHHHHIIIIJJJJKKKKKKKK
0xA4    0xF0    0x27    0x47    0x00    0x00    0x03    0xC6    0x0C    0xFE
10100100111100000010011101000111000000000000000000000011110001100000110011111110


with:
AAAA = 1010    Message type: 0xA: sensor readings
BBBBBBBB       Station ID / rolling code: Changes with battery insertion.
CCCCCCCCCCCC   Temperature*10 in celsius. Binary format MSB is sign
DDDDDDDD       Humidity in %. Binary format 0-100. MSB (bit 7) unused.
EEEEEEEE       Windspeed
FFFFFFFF       Wind gust
GGGG           Unknown
HHHHHHHHHHHH   Rainfall cumulative. Binary format, max = 0x3FF,
IIII           Status bits: MSB b3=low batt indicator.
JJJJ           Wind direction
KKKKKKKK       CRC8 - reverse Dallas One-wire CRC

DCF Time Message Format:
AAAABBBBBBBBCCCCDDEEEEEEFFFFFFFFGGGGGGGGHHHHHHHHIIIJJJJJKKKKKKKKLMMMMMMMNNNNNNNN
Hours Minutes Seconds Year       MonthDay      ?      Checksum
0xB4    0xFA    0x59    0x06    0x42    0x13    0x43    0x02    0x45    0x74

with:
AAAA = 1011    Message type: 0xB: DCF77 time stamp
BBBBBBBB       Station ID / rolling code: Changes with battery insertion.
CCCC           Unknown
DD             Unknown
EEEEEE         Hours, BCD
FFFFFFFF       Minutes, BCD
GGGGGGGG       Seconds, BCD
HHHHHHHH       Year, last two digits, BCD
III            Unknown
JJJJJ          Month number, BCD
KKKKKKKK       Day in month, BCD
L              Unknown status bit
MMMMMMM        Unknown
NNNNNNNN       CRC8 - reverse Dallas One-wire CRC

The DCF code is transmitted five times with 48 second intervals between 3-6 minutes past a new hour. The sensor data transmission stops in the 59th minute. Then there are no transmissions for three minutes, apparently to be noise free to acquire the DCF77 signal. On similar OOK weather stations the DCF77 signal is only transmitted every two hours.

The package format was deduced using a long transmision buffer on a JeeNode with some modificaitons in the RF12 driver.
The payload definitions have been described at those pages:
WH1080 V1 OOK protocol
WH1080 V2 FSK protocol
WH1080 V1 OOK and DCF77 message format

This applies at least to the following (later) models:
Fine Offset WH1080
Alecto WS4000
National Geographic 265, at 916MHz