Random tech and radio stuff

Reverse engineering a weather station

Fri, 01 Mar 2024 15:31:58 +0200

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

Transmission duration overlay for OBS - Pluto F5OEO 0303 2402 Firmware

Sun, 26 Mar 2023 06:59:00 +0200

Please find the download here

Before loading this html page into OBS please change some variables for you setup.

Namely :

Pluto network address
Date formatting
Colors
Font

Then in OBS follow these steps

Add source and click on Browser

Give it a name

Load the local file from the location you downloaded it to

Once on the scene we need to crop it a bit to make resizing easier

Hold ALT and click on the middle bottom red square, dragging it up towards the clock

It would start to look like this

Do the same for the middle right side square, holding ALT still and dragging it left till just about the edge of the blue background of the clock.

It should look like this

Now you can let go of ALT and resize it normally.

Once the PTT of the Pluto is triggered the timer will start and reset once PTT goes off again

It keeps the time similarly to the Controller page on pluto

Huzzah

An antenna for a weather balloon from old antennas

Thu, 09 Sep 2021 05:55:07 +0200

In this post I will build a dipole antenna for the purpose of decoding radio signals around the 403MHz mark or just under the 70cm band.

This antenna was made from an old magnetic loop trombone style antenna.

One where you slide a U bended piece of copper inside two foil coted pvc pipes to change capacitance for the loop.

The parts that I could summaries need for the build is the following :

Approx 300mm of 15mm diameter copper tubing
1000mm of 20mm outside diameter PVC pipe
Approx 750mm of RG58U / coax of your choice
Female BNC 50Ω bulkhead
Blowtorch for pipe soldering
Soldering iron for BNC bulkhead
Solder
Flush cutters
Pipe Cutter

Prep coax

Take the piece of coax and strip about 3cm of the end, taking care not to damage the outer metal jacket.

Expose the center core of the coax and wind up the outer jacket into a wire like strand.

Take the soldering iron and tin both of these adequately.

Prepping element

The pipes where cut to about 137mm each.

They where then placed on top of our trusty gas hob.

Taking the blowtorch we then heat up the ends of the first element(pipe) for about 6-7 seconds with the tip of the blue jet stream of plasma.

Once the pipe starts smoking we firstly switch off the blowtorch, we then can proceed to carefully push our solder strand into the insides of the pipe, it will, if hot enough start pooling immediately and bonding to the copper.

When there is about a 1cm circular blob of liquid metal on the inside of the pipe start the torch back up, reheating for about 3 seconds and switching off the torch again, promptly carefully take the center part of the coax and submerge it in the pool of metal.

Take a deep breath, and start blowing...

You should see lots of flux smoke exiting the pipe which is a good sign, after blowing at it for about 3 seconds it will solidify and bond permanently.

Then patiently wait for the pipe to cool down.

After the pipe is cool enough to handle, repeat the above process for the outer metal jacket of the coax.

You should be presented with something like this.

We have successfully constructor the radiators of our antenna.

We then carefully take our coax and run it through the copper pipe connected to the outer jacket like so.

Putting everything together

NanoVNAv1 - Source code build

Sat, 07 Aug 2021 10:39:44 +0200

This will be a guide to building the NanoVNA source code from a fresh Ubuntu machine.

First off, we need git.

In a terminal window run the following:

sudo apt-get install git

Following the guide available on GitHub we generate and add an ssh key:

ssh-keygen -t rsa -b 4096 -C "your_email@domain.com"

eval "$(ssh-agent -s)"

ssh-add ~/.ssh/id_rsa

We need to copy this key to the clipboard with xclip:

sudo apt-get install xclip

xclip -sel clip < ~/.ssh/id_rsa.pub

Click the green New SSH Key button

Give it a Title and paste the copied key in this window

Once that is done we can add some prerequisites:

In a terminal window run the following:

wget https://developer.arm.com/-/media/Files/downloads/gnu-rm/8-2018q4/gcc-arm-none-eabi-8-2018-q4-major-linux.tar.bz2

sudo tar xfj gcc-arm-none-eabi-8-2018-q4-major-linux.tar.bz2 -C /usr/local

PATH=/usr/local/gcc-arm-none-eabi-8-2018-q4-major/bin:$PATH

sudo apt install -y dfu-util

Once that's dusted off we can clone the repo :

In a terminal window run the following:

git clone https://github.com/ttrftech/NanoVNA.git && cd NanoVNA

git submodule update --init --recursive

Type yes when asked

If you see something like this

Submodule path 'ChibiOS': checked out '669d4bbc8da1ee0e4ccdf93a472b06d183922320'

All is good!!!

Build the library with:

 make

That's a successful build right there!

Flash by setting the device to DFU boot, either in software or by short of pins :

Short the two pins in the red circle with the device powered off, then with the pins shorted power on the device.

This will enter DFU mode, with a blank white screen.

The device can now be flashed.

Software Reset to DFU

Then to flash:

make flash

This is what to expect when flashing the device.

Windows Flashing:

For conversion to dfuse dfu file format for Windows flashers:

In the ubuntu terminal still:

dfu-tool convert dfuse ./build/ch.hex test.dfu

Set PID, VID:

dfu-tool set-product test.dfu df11

dfu-tool set-vendor test.dfu 0483

Experimental build from a branch that enables Time Domain Stuff

Added menu items

Hopefully, this will help some folks get to building the firmware of this device.

Kind Regards

Ohan

ZS1SCI

NanoVNA Saver - Part #1

Tue, 03 Aug 2021 18:46:09 +0200

As I am naturally curious about RF Tech, I tend to collect devices that quantify certain aspects of the RF hobby.

This device is, by far been the most interesting one.

Some time ago, I wrote morfeusQt, which is still somewhat active...

So I contemplated writing a similar python application for this device.

Fortunately, I was searching GitHub for "nanovna" one night and this popped up.

It was Python, and it worked on first load and omg...

It's opensource!

It is written by Rune B. Broberg / 5Q5R.

In the following blog post will go through some vigorous screenshotting and brief texting to explain my process,

please bear with me as I run through its use cases, some of which I will cover in the next article as my understanding

on the matter deepens.

The steps that follow are:

Setup basic application
Calibrating the device
Measuring some filters
- 2.6MHz High Pass Filter
- 88-108MHz Bandstop Filter
Extend Range Firmware up to 1.5GHz

I will forego going through the software repository cloning process and jump straight to usage.

This should yield the most satisfying results from this little USB serial device.

Basic Setup

Firstly let's download the application: Please follow this link for the latest release page.

Once downloaded, let's have our nanoVNA device plugged in via the USB cable before firing up the application.

Once opened, we have a screen that looks like this.

We then click on Connect to NanoVNA to initiate our device and get the first scan.

Here we are presented with a beautiful presentation of our data.

I am going to customise this display, and I do this by clicking on Display Setup and by changing the Sweep Color.

That's a little better...

Firstly, we need to calibrate.

Short

Open

Load

Through

Isolation 2x 50Ω dummy loads

We click on calibration, and then we set our segments to 10 to have more points, after which we click sweep.

Once the sweep completes with our Short in place, we click the "short" button in the calibration screen.

We follow this process for each step (Short, Open, Load, Through and Isolation) of the calibration process. Then after the OSL calibration is complete, we can click apply and then if we'd want we can save the calibration for later loading.

We then close our calibration screen.

Filter #1

First up a 2.6MHz HPF from RTL-SDR.

We sweep from 50KHz - 30MHz with ten segments for some excellent resolution(1010 data points)

I've also added three markers to peak at values, to match the first markers in the chart below.

Markers points can be highlighted by selecting the appropriate radio box in the markers section.

It matches nicely with what s found on the RTL-SDR website

Return Loss

Next, we sweep from 50KHz-6MHz, for a closer look

It also pairs nicely with what is on RTL-SDR

Filter #2

The 88-108MHz bandstop filter

We sweep from 50KHz-300MHz

Again this matches quite nicely with what is on RTL-SDR

Mods

EDIT 17-09-2019 Here I tested a new master branch firmware update which expands the frequency range by 600MHz to 1.5GHz.

Here are some device captures with a 50Ω load

DFU can be entered via software switch

As can be seen below, the hardware limitations of the device are being met above 900MHz.

This is a sweep of the bandstop filter in place with a new calibration made for the new range in the latest firmware.

Here is the Open sweep with extended range

Here is the Short sweep with extended range

Here is the Load sweep with extended range

Here is the through sweep with extended range

Perhaps the device would need a hardware upgrade shortly?

Just for science, how would it look with 10k points?

A sweep of 10100 points with the bandstop in place

Conclusion

So for me being a radio amateur and loving building things, it's nice having a device that can quantify specific theoretical parameters.

I am also still learning a bunch, so much so that I decided to contribute to the GitHub project.

It is lovely to see the application grow with every iteration and Rune is definitely on the fast track to making

one of the most top-notch VNA applications for this device.

I would also like to thank the author of this article and Rune for pointing it out, it always great learner things from others in the same domain.

I'll get to measuring some antennas on the next Part, for now, if you'd be interested here

are some build instructions for the firmware in Ubuntu 19.04

Kind Regards

Ohan Smit

ZS1SCI

XieguG90

Tue, 03 Aug 2021 05:08:42 +0200

I recently purchased my first HF transceiver a Xiegu G90.

Since I would mostly just be interested in digital modes, Flrig seemed like the obvious choice to control the radio via CAT.

Here are my settings to get it working.

But for this post, I'm setting up OmniRig v2.1.

Categories covered here are:

Digital modes setup
WSPR
Custom Cooling
HDSDR CAT control and 192kHz Pan-Adapter
GPS, cable management and wiring diagram

Digital Modes Setup

OmniRig can be downloaded here.

So looking at the above flrig configuration, we can decern a few things.

The Xiegu Radio shares the same serial protocol as some Icom radios(IC-756-Pro and IC-7100).

We will be using the IC-7100 Rig-Type.

We fire up WSJT-X and configure our radio settings as such.

WSPR

Now we are ready to test some WSPR signals :)

As I am using an end-fed antenna, it resonates at a few frequencies, and my band hopping schedule is set up as such.

We set the power level on the radio to 2W.

Now we need to adjust the PWR in WSJT-X so that the ALC on the radio is around "098".

Here are the results from this transmission :)

Likewise, we would configure our input pwr for WSJT-X for all modes and frequencies :)

I hope this sheds some light on the usefulness of OmniRig.

No need to open anything once configured, just fire up WSJT-X and Enable Tx.

Here is an example of my performance over the past two weeks on 80-12m bands at 33dBm on WSPR.

Xiegu G90 and WSPR running 24/7.

This required some form of cooling for the radio to run this long.

I used a 120mm computer chassis fan and some butyl tape to absorb the vibrations it might create.

Custom Cooling

It is connected in parallel to the radio's DC-IN.

It's optional but seems to do the job.

Panadapter

Right now that digital modes are out of the way, how about an I/Q pan-adapter for the G90?

Want to see more than just what is on the radio screen?

This is where we fire up HDSDR and configure it:

RF Front-End Configuration

And you should be presented with a nice panoramic view of the RF spectrum, demodulation control as well as CAT Control.

Here is 192kHz of goodness with a calibrated S-Meter :D

Here I am tuned to 7.196MHz on the radio, yet I am listening and seeing the spectrum on 7.110MHz

GPS and wiring

Wiring and setup pics requested.

I keep time with a USB Serial device and GPS

The actual GPS device L76X GPS module

Xiegu G90 connections

Here is my wiring diagram

Communication is done with the Xiegu "programming" / CAT control cable that comes with the kit.

As can be seen, this radio is a competent little device, especially when properly set up.

I have a suspicion that some of these configurations should work with the Xiegu X5105 too.

Huzzah!

Kind Regards

Ohan ZS1SCI

The very first post on the new blog...

Sun, 01 Aug 2021 06:57:52 +0200

This my new blogging site, I've upgraded from MiniBlogCore to Blogifier as it seems better suited for my needs.

Which has changed quite a bit over the past few years.

Anyway cheers

Ohan