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

Frank Leave a comment

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.

 

Innr SmartPlug for Philips Hue – part 2

Frank 3 Comments

Disclaimer

Do not work on the SmartPlug while powered with 230V. The author accepts no responsibility or liability for any adverse effects. This includes but is not limited to potential damage of the device itself, other equipment or personal harm, injury or dead. Working on electrical mains appliances can be dangerous. 230V is dangerous. If you decide to open such a device and work on it, never plug it into mains, until the device is closed again. If you do not feel comfortable with this, or want to experiment while powered with 230V: Do not proceed!

Wiring-up

To program the smartplug, a few wires have to be connected. Only three wires need to be soldered to the JN5168 module. GND and +5V can be taken from the main PCB. Remember the disclaimer. Never work on the smartplug when it is connected to a 230V socket! The following diagrams show how to connect a USB-serial dongle to the smartplug.

Read More

Innr SmartPlug for Philips Hue – part 1

Frank 1 Comment

Philips Hue – Great, only E27 ad GU10 lights?

Great system, but what about the E14 lights that I have around the house, and some others where the bulbs can’t be replaced with one of the Hue lights? It seems that the Osram Lightify Plug can be connected. A solution without soldering and flashing firmware would take the fun out of it. The new brand Innr offers a SmartPlug, that uses the Zigbee HA protocol. Could it also be used with the Zigbee ZLL protocol used by Hue? The answer is yes. It only requires flashing a custom firmware. Read More

RFM69 OOK – DAGC, Sensitivity Boost and Modulation index

Frank Leave a comment

As a final step in exploring the optimal settings for receiving “foreign” OOK signals with the RFM69, the settings for DAGC, Sensitivity Boost and the effect of the Modulation index are explored. The modulation index is actually a FSK aspect, and no effect should be expected for OOK. However, as it can be programmed to High or Low, it is included in the exploration.

Foreign OOK refers to signals that are not natively produced by an RFM69, but are originating form various sensors or remote controls.

From the first results, it can be concluded that Sensitivity Boost has a clear advantage, and also DAGC enabled helps in icreasing sesnitivity:
RFM69SpecialModeHisto
Read More

RFM69 – Energy Count 3000 / ELV Cost Control

Frank Leave a comment

Conrad Energy Count 3000 and ELV Cost Control are wireles 230V electricity consumption measuring plugs Thomas Schulz has cracked the RF protocol of these device back in 2011 on the JeeLabs forum. The signals are FSK encoded and use the 868Mhz band. Thomas was able to receive them with a RFM12B module. Together with a JeeLink V3, it has found popular use with the German home automation software FEHM.

In this post I describe how the RFM69 can take over a task that earlier had to be performed in software.

One of the complications of the protocol is that the preamble of a series of 0x55 is scramble (whitened), and therefore more difficult to recognize. However, after scrambling it is still identical for all packets.

raw data 25 8A F9 59 DA 02 7E 15 ED 67 13 F1 85 D3 AC D2   [payload]   13 E6 84 A8 3B 
descramb 48 BB 55 55 55 55 55 55 55 55 55 55 55 55 55 7E   [payload]   7E 55 55 55 55 
               -------------------------------------- --   ---------   -- -----------
                             preamble                 HDLC  payload  HDLC  postamble

The original Jeelib-based RFM12B programs detection of valid packets was clumsy. Read More

RFM69 OOK compare antenna’s

Frank 3 Comments

The antenna design of a module like the RFM69 is important for the sensitivity to sognal and noise. Also antenna positioning is important. Putting an Nucleo STM32 with RFM69CW very close to a PC will result in a increase of several dBm’s in noise floor.

Gain 7 dB sensitivity with JeeNodes

The basic antenna design commonly used is a quarter wavelength wire antenna with ground plane.
quarterwavelengthantenna
From this informative paper from HopeRF, the manufacturer of the RFM69. Such an antenna has a 1/4 wavelength monopole, and a ground plane that serves to reflect (mirror) the wire so that one gets a half-wavelength dipole effect.

The 86mm wire (at 868MHz) connected to small JeeNode like devices is actually not having much of a ground plane. So this can probably be improved. There are very nice commercial designs for this at 868MHz and 433MHz. A.o from Conrad. So lets putthree 1/4 wavelength antenna’s to the test. The wire is compared to a home build and a commercial 1/4-wavelength with groundplane antenna. (See picture above this article, the blue wire crossing the Nucleo is the wire-antenna). Read More

RFM69 OOK RSSI and optimal bitrate

Frank 1 Comment

RFM69 OOK RSSI and optimal bitrate settings are key for proper reception and decoding of “foreign” OOK signals for example form remote controls as FS20, or wireless sensor such as Oregon scientific whether stations. In an earlier post, already some strange behavior of RSSI has been presented. A FS20 RC signal is recorded with 3 different bitrate settings in continuous OOK mode:

At high bitrates, the RSSI signal is much noisier. At 3000bps, the RSSI signal is hardly usable, although the internal bitslicer still can decode the signal, which has bit durations of 400 and 600us. So a too high bitrate will only lead excess noise.

From the 3000bps it can be seen that the RSSI signal is sampled with about 625us intervals. According to the datasheet, the RSSI sample duration depends on the duration of a bit:

t-rssi = 2 * t-bit

So for 3000bps, t-bit=333us, so t-rssi = 666us.
For 32768bps, the t-rssi=61us. As the RSSI signal is recorded with 25us intervals, most of the time two or three adjacent samples will have the same RSSI value.

In an earlier post, it was explained that the internal bitslicer can slice at 1/25 of the bitrate. The fastest signals we want to see have bit duration (ON-time or OFF-time) of 200us (Some Oregon Scientific sensors). So then a low bitrate setting of around 1000bps will do?

From further looking into exact timings or received signals, it appears that this is not true. When looking at a histogram of FS20 signals recorded with 2000bps, it can be seen that distributions of the 400us and 600us signals start overlapping. Also, the OFF-signals can be biased to shorter or longer durations, depending on the choice of OOK-PEAK or OOK-FIXED mode. As a result, the signal cannot be reliable decoded.

FS20 histo 2000bps

Now this is a bit messy. An ideal signal has both ON and OFF pulses taking either 400 or 600us:
FS20bit
Deciding whether a bit is a zero or one, should simply testing whther the pusle duration is longer or shorter than 500us. Clearly that does not work. Also note it is an odd signal. It has many zero-bits, and only 11 one-bits.

When moving to a higher bitrate (32768bps), the variation on the bit-timing is greatly reduced, and it also appears that the timing is hardly dependent on the OOK-PEAK or OOK-FIX setting.

FS20 histo 32768bps

In conclusion, the bitrate should be high enough for reliable bit timings, but not higher then needed, as a lower bitrate means a better noise filtering.

Plugwise-2-py with reconnecting websockets

Frank 1 Comment

One of the problems with the Plugwise-2-py web application (Plugwise-2-web.py) was that when a computer running a browser with the web client fell asleep, that in the next session the page had to be manually reloaded to get the websocket stream of power readings started again.

This seemed easy to fix, with a timeout call in the javascript or something like that. But before coding this I thought of gooling it. And of course it did already exist.
https://github.com/joewalnes/reconnecting-websocket
It did not only exist, but also got it working within 30 minutes. Reliably! Read More

SSL/HTTPS – Grade A+ python SimpleHTTPServer

Frank Leave a comment

After adding SSL to my HTTPWebSocket server, I found that originally it was not so secure due to the fact the the linux distribution I used did not get essential security updates. I used Qualsys SSL Labs: https://www.ssllabs.com/ssltest/analyze.html to analyze the security level of my server. Well, it started out with ‘grade E’. Finally, I ended up with ‘grade A+’. These are the steps to follow: Read More