This is the second blog post of my RoadTest review of the Ettus USRP B205mini-i Software Defined Radio platform: Digilent 1x1 USB Software-Defined Radio Platform
You can find the 1st blog post here:
After successfully getting started with the Ettus USRP B205mini-i, I started looking into some experiments I could do.
I'm mainly interested in technologies usually used in IoT / DIY project, so I mainly looked at the unlicensed spectrum:
- 433 MHz Band (433.05 to 434.79 MHz) - used by Remote Controls, Wireless Sensors, LoRa (no LoraWAN), etc.
- 868 MHz Band (~ 863 to 870 MHz) - used by Remote Controls, Wireless Sensors, LoRa / LoraWAN, etc.
- 2.45 GHz Band (2.4 to 2.5 GHz) - used by WiFi, Bluetooth Low Energy (BLE), Zigbee, Remote Controls, Wireless Video Transmission, etc.
- 5 GHz Band (multiple sub-bands between 5.150 to 5.925 GHz) - used by WiFi 5GHz, Wireless Video Transmission and also 5G mobile networks
Bellow are 4 experiments I came up with. I did these both on the Ettus USRP B205mini-i and the HackRF One.
As I'm still a beginner in the SDR field, and doing SDR with GNU Radio turned up to be pretty time consuming. For I wanted to keep things simple, so tried to keep the experiments reasonably simple .
1. Inspecting WiFi Channels
The first technology I wanted to take a look into was WiFi.
WiFi works in the 2.45 GHz and 5 GHz bands. In the 2.45 GHz band there are 14 channels, each of which is 22 MHz wide:
(image source: www.extremetech.com)
I wanted to see which of these channels are used around my home. For this I used the following 2.4 / 5 GHz antenna:
Now, the 14 x WiFi Channels span in a ~95 MHz wide spectrum around 2.45 GHz. This means the neither the 56 MHz bandwidth of the USRP B205mini-i, nor the 20 MHz bandwidth of the HackRF One are enough to capture all the channels at once.
To overcome this issue Gnu Radio Companion (GRC) app that sweeps the ~100 MHz wide spectrum in multiple passes:
The pipeline has the following components:
- USRP Source (B205 mini) or Osmocom source (HackRF)
- a Python Module + Function Probe sweetening the tunning frequency between 2.4-2.5 GHz in steps of 50 MHz (B205mini) and 20 MHz (HackRF)
step = 50e6 freq_start = 2.4e9 + step / 2 freq_end = 2.5e9 f = freq_start def sweeper(prob_lvl = None): global freq_start, freq_end, freq, f if prob_lvl: f += step if f > freq_end: f = freq_start return f
- 3 components to mix the 50 / 20 MHz individual bands into a single 100 MHz
- a Rational Resampler re-samples the 50 / 20 Msps in 100 Msps
- the resulting signal is offset to the correct position by doing a Multiply with a Cos signal (offset)
- Waterfall and Frequency Sink used for visualization
Running this on the B205mini looks like this:
The two graphs shows high activity in a ~22 MHz band around 2.452 GHz. This corresponds to the WiFi Channel 9, and is also confirmed by the web interface of my home router.
Note: to generate traffic I started a Speedtest from my phone connected to my WiFi Home network.
The HackFR version similar:
Next, I did the same with the 5 GHz WiFi channels.
Things at 5 GHz are a little more complicated. There a multiple sub-bands that can be used in different countries at different power levels:
For simplicity I decided to go with the most common UNII-1, spanning from 5.150 GHz to 5.250 GHz.
The GRC app was updated to work at 5 GHz frequencies:
This is what communication at 5 GHz WiFi looks like:
Looks like the router / phone tries to use a pretty consistent portion of the spectrum.
HackRF version of the GRC app:
and its output.
I thinks this experiment was a good way to show the instantaneous bandwidth difference between the B205mini-i and the HackRF One.
2. Bluetooth Low Energy (BLE) Scanner
An another technology working in the 2.45 GHz band is the Bluetooth Low Energy (BLE).
In this experiment I wanted to try out a the ble_dump - SDR Bluetooth LE dumper project I found on Github.
The project combines a GNU Radio Companion (GRC) pipeline with a Python script to capture, demodulate and and decode BLE packets in a Pcap file.
As the project is quite old (~6 years) it needed some modification to work. Originally, it uses GNU Radio message queues to transfer packets from the pipeline to the Python script. But as this did not worked I decided to dump the packets into a file, and process it with the Python script afterwards. An another modification needed was to migrate the script from Python 2.7 to Python 3.x.
As the project was initially created for HackRF One, I started with it this time.
Next, I created a modified version of the GRC pipeline to be able to work with the B205mini-i:
The Python script was also modified to allow running with the B205mini-i.
3. Random 433 MHz Remote
In homes there are lot of devices working on 433 MHz and 868 MHz bands, including remote controls, doorbells, sensors and other.
The RF protocols / encoding used by these devices are usually simple, so I wanted to take a look on how these devices works.
After a quick search, what I found is this remote control of a retractable sun shade:
The model number on the back label is DC305A, and it says the remote works on 433 MHz
The remote is a single channel one, with 3 buttons: Open, Close, and Stop.
As I did not found any exact information about what protocol this remote uses, I decided to try to reverse engineer it.
The first I tried was to try to capture transmissions with the RTL 433 project. This works with a RTL-SDR based dongles, and is capable to decode a wide variety of communication protocols used by devices working on the 433 MHz, 868 MHz and 915 MHz bands. Unfortunately, it was not decode the signals from my remote.
The next the was to capture some transmissions in WAV files. For this I used the bellow GNU Radio pipelines:
The captured WAV files can be opened in application like Audiacity, where we can visualize the baseband signal:
On a button press the remote sends one (Stop) or two (Open, Close) message packets repeated 6 times.
When we zoom in we can see what a message looks like:
It start with a long initial transmission, and a series of 40 x short / long pulses follow. The initial transmission probably is some kind o sync symbol, while the following short / long pulses represent bits. This technique is called On–Off Keying, which is a form of Amplitude-Shift Keying.
To decode the RF signal into messages I quickly wrote a (dirty ) Python script. It outputs the decoded 40-bit message, along the frame number at which the message started:
From this we can try to figure of how the messages are structured. My guess is something like this:
Now, this format is based on samples just from a single remote, so it can be easily wrong. The actual format could easily differ from this one.
Anyways, the collected data should be enough to "clone" the remote. Such a software controlled remote could be used for different home automation tasks.
4. Full-Duplex Transmit and Receive
The HackRF One and USRP B205mini-i are capable of both receiving and transmitting RF signals.
However, from the two only the USRP B205mini-i is capable of full-duplex communication, which means it can receive and transmit at the same time,
The HackRF One can only do half-duplex, which mean for two-way communication it need to constantly switch between either the receive and transmit modes.
To demonstrate full-duplex communication I quickly created the following GRC pipeline:
What it does, it takes audio from a WAV file and transmits it on a walkies talkie frequency (446 MHz) using narrow-band FM modulation. The TX/RX antenna port of the B205mini-i is used for this.
In the same time, an antenna connected to the RX2 port picks up the signal, FM demodulation is done, and the received audio is played on an Audio Sink (speakers).
This is how it works:
The sources code above projects can be found in the following GitHub repository:
The next step is to write my final Road Test review of the Ettus USRP B205mini-i Software Defined Radio platform. In this I will try to conclude my experience with the USRP B205mini-i, and do a detailed comparison between the B205min-i and the HackRF One.