github.com/amitferman/FSK-Backscatter

Who should read this?

Anyone interested in radio frequency (RF) backscatter!

RF backscatter is a fast-growing field of research that enables ultra-low-power connectivity for billions of Internet of Things (IoT) devices. I thought it was really interesting, so worked onimplementing RF backscatter with a minimal hardware setup at home.

I published my work here on Medium because there are few online resources to implement backscatter. Hopefully, you will find this article helpful!

I always appreciate feedback through comments.

1. Introduction

Bluetooth Low Energy (BLE) is a power-efficient Bluetooth configuration that enables connectivity for billions of IoT devices. One mode of operation is advertising: BLE has 40 channels in the 2.4GHz band, each separated by 2MHz. In advertising mode, peripherals transmit BLE packets in one of three advertising channels. For each channel, frequency deviations must exceed ±185kHz from its center frequency to encode a logical 0 or 1 [‎1].

The BLE physical layer is relatively simple. BLE modulates bits at 1 Mbps with Gaussian Frequency-Shift Keying (FSK). Whereas FSK instantaneously shifts a signal between two discrete frequencies to encode bits, Gaussian FSK applies a Gaussian filter to FSK data pulses, causing smooth transitions between frequencies. Therefore, Gaussian FSK is continuous phase and requires more fine-grain frequency modulation.

In research by Joshua Ensworth, the University of Washington was the first to backscatter BLE in 2016. Ensworth developed a standalone BLE backscatter tag with a TI MSP430F2132 16MHz microcontroller, an analog oscillator, and an ADG918 RF switch. The analog oscillator enabled fine-grain, continuous-phase frequency modulation of the RF switch for Gaussian FSK [‎2].

This work pushes the limits of backscatter without an external oscillator. We similarly employ a 16MHz microcontroller, but ours is directly wired to the RF switch (as opposed to a frequency-select line on an external oscillator). This imposes numerous challenges on modulating the switch: First, it constrains us to pulse-width modulation (PWM), which introduces undesired frequency artifacts in the backscattered signal. Second, it limits the maximum frequency at which we can modulate the switch. Third, it limits the frequency resolution (i.e., the minimum step size between frequencies) we can achieve. Given these limitations, it’s not immediately obvious whether BLE backscatter is feasible. Therefore, we approach the problem iteratively in two stages.

In Stage One, we design and implement a transmitter, backscatter device, and L1/L2 receiver capable of backscattering a given data payload at various frequencies and baud rates. We implement a packet-based link-layer protocol that is useful for evaluation purposes, including error correction and detection. We measure performance by varying baud rates to determine the maximum data throughput we can achieve and how this compares to the ideal throughput determined by the communication rate.

In Stage Two, we analyze whether BLE backscatter is feasible with signal modeling to understand the main challenges involved. Next, we attempt a proof-of-concept with an unmodified BLE scanning app on an Apple iPhone.

2. Approach

Below, we describe the Stage One setup because the Stage Two setup is a subset of the Stage One setup. (See 4.1 Setup for more details.)

2.1 High-level Design

We designed a transmitter (TX), backscatter device (BX), and receiver (RX), as shown in Figure 1. TX radiates a single-tone sinusoid (the “carrier”) at f_c. BX backscatters the carrier by modulating an RF switch according to an input signal (the “subcarrier”) at one of two frequencies, f_sc0 and f_sc1, to encode a logical 0 or 1, respectively. By modulating the RF switch according to this subcarrier signal, BX implements a mixing operation with the carrier. Since multiplication in the time domain is convolution in the frequency domain, the backscattered signal has two frequency spikes for logical 0 and 1, whose offsets from f_c match f_sc0 and f_sc1, respectively. RX demodulates the backscattered signal into logical bits (L1) and decodes them as packets (L2).

2.2 Hardware Design

For stage one, we selected hardware for the 900MHz frequency band. As seen in Figure 2, the BX hardware includes:

• Atmel ATmega2560 microcontroller (16MHz clock)
• Analog Devices ADRF5132 RF switch
• RFMAX S9028PCRJ patch antenna (902–928 MHz, 8 dBic gain)

A PWM pin on the microcontroller is wired to VCTL on the switch. The patch antenna is connected to RFC on the switch with various adapters and wiring (not shown), whose total length is around 1m. RF1 and RF2 on the switch are connected to 0 Ohm and 50 Ohm SMA terminators, respectively. A standard battery pack powers the microcontroller.

The RX hardware includes:

• Nooelec NESDR SMArt v5 RTL-SDR
• Personal computer

The personal computer demodulates and decodes the I/Q data stream emitted by the RTL-SDR at 3.2Msps using Python.

The TX includes:

• Great Scott Gadgets HackRF One
• RFMAX S9028PCRJ patch antenna (902–928 MHz, 8 dBic gain)

2.3 Software Design

Below, we describe the software implementation for Stage One. As described earlier, see 4.1 Setup for more details on how Stage Two software differs from Stage One.

2.3.1 Transmitter: Carrier Generation

The transmitter uses SoapySDR and Python bindings to interface with the HackRF One. It transmits a single-tone sinusoid forever at the given frequency.

2.3.2 Backscatter Device: Subcarrier Generation

The backscatter device leverages native 16-bit timer peripherals on the ATmega2560 to provide precise timing for (1) PWM and (2) periodically shifting the PWM frequency. The first timer constantly modulates a pin between 0V and 5V. The second timer triggers an interrupt request every bit period to shift the frequency at which the first timer modulates the pin. Each timer is configured with Fast PWM Mode, and changes to timer frequencies are achieved by writing to timer registers.

One challenge was ensuring the computation time of the interrupt routine does not exceed its period. For example, at 1Mbps, the bit period is 1µs, whereas the ATmega2560’s clock period is 1/16µs. Therefore, the interrupt routine must never exceed 16 clock cycles. We heavily leveraged precomputation and C++ language features such as macros throughout the implementation to satisfy this requirement.

2.3.3 Receiver: Demodulation and Decoding

To demodulate the signal, the receiver applies the following operations to the given I/Q data:

1. I/Q Sampling: The RTL-SDR is configured with a center frequency of a few 100kHz below the midpoint of f_sc0 and f_sc1 to avoid obfuscating the FSK signal with DC noise.
2. Down-conversion: The I/Q signal is down-converted to center the midpoint at 0kHz by multiplying it by a complex sinusoid whose frequency is the offset from 0kHz to the midpoint of f_sc0 and f_sc1.
3. Compute instantaneous frequency: We computed the phase of the original signal and differentiated the phase stream at offsets of 0 and π/2 radians to correct phase artifacts.
4. Low-pass filter: High-frequency components of the instantaneous frequency were empirically confirmed to be noise, so we filtered them out at an empirically determined offset.
5. Match filter: We convolved the frequency with a top hat function. The justification for this is related to the prior step since a match filter is another kind of LPF filter.
6. Edge detection: To determine where to sample the resulting signal for logical 0s and 1s, we implemented basic edge detection with a moving average of N samples, which tolerates noise reasonably well. This step outputs the bit stream that is passed to the link layer in the next step.
7. Channel decoding: We implemented fuzzy preamble matching to identify packets in the bit stream (i.e., match if Hamming distance does not exceed 1). After the preamble, we then applied error-correction to the packet contents and ignored packets whose CRC-8 check bits did not match the decoded data. See the next section for more details.

2.3.4 Link Layer

Since error correction and detection are commonly used in industry-standard network protocols and backscatter communication, in particular, is prone to bit errors, we implemented a basic link layer with a best-effort datagram service model. As seen in Figure 3, the packet begins with an 8-bit preamble, followed by data bits and an 8-bit CRC. A Hamming(7, 4) code is applied to both the data bits and CRC. Each packet contains 16 data bits. The CRC provides error detection for up to 5 bits. The Hamming code provides error correction up to 1 bit. The communication rate is 0.32. We independently implemented Hamming(7, 4) codesand used an external library for CRC-8 computation.

For any data we want to transmit in our system, we first packetize it at the link layer. Next, we manually copy this bit stream into the backscatter device’s software as a byte array, compile it, and upload it to the microcontroller. Decoding is built into the receiver software.

3. Stage One: Experiment

3.1 Experimental Setup

We selected our control variables to fit our hardware implementation best. For example, the patch antennas were rated 902–928 MHz, so we transmitted in this frequency band. We also used a spectrum analyzer to understand which frequencies had the least ambient power in our testing location. Finally, other variables, such as subcarrier frequencies, were influenced by limitations stated earlier concerning the max frequency the ATmega2560 can modulate and the 16-bit timers’ frequency resolution.

The control variables are:

• f_c = 905MHz
• f_sc0 = 2.0MHz
• f_sc1 = 2.66MHz
• 0.5m between BX and TX.
• 0.25m between BX and RX.
• 0.25m between RX and TX.
• 1 second of sampling time per trial.
• 3.2 Msps sampling rate at RX.

The independent variable is:

• Baud rate: the rate of frequency shifts in the backscattered signal.

The dependent variable is:

• Throughput: the total number of payload bits per second, excluding check bits and preambles.

We perform 4 trials for each baud rate, and we evaluate the following baud rates:

3.2 Results

See Figure 4 for our results plotted against an ideal throughput (communication rate x baud rate), and see 7.1 Data for raw data.

3.3 Discussion

As shown in Figure 4, increasing the baud rate past 40,000 bps has diminishing throughput returns past roughly 5,000 bps. Experimentally, we had trouble getting non-zero throughput measurements past this baud rate.

We believe the receiver’s sampling rate limitations cause this diminishing return phenomenon. The RTL-SDR has a max sampling rate of 3.2Msps, which we used in our experiment. The key observation is that samples per bit (SPB) decrease with the inverse of the baud rate. Low SPB reduces noise tolerance and increases bit errors to the point where our channel coding cannot decode any packets.

Consider the same data plotted against the SPB in Figure 5. At a baud rate of 40,000 bps, there are 80 SPB. Already, this number is quite low. Increasing the baud rate to 80,000 bps results in 40 SPB. Experimentally, 40 SPB is insufficient for any throughput.

Another interesting observation was that some of the decoded packets contained random characters not modulated by the backscatter device. This happened when the noise in the system was so high that bit flips caused false positives when checking if the CRC-8 matched the payload to detect errors.

The software that computes throughput statistics attempts to correct for this phenomenon, but future testing may have benefited from longer CRC codes (e.g., CRC-16). However, this would come at the expense of the communication rate, which must be balanced to provide the most useful evaluation of the system.

4. Stage Two: BLE Proof-of-concept

4.1 Setup

The setup for the BLE proof-of-concept was the same as that for Stage One, but with the following differences:

• The TX and BX patch antennas were replaced with Sunhans WiFi antennas (2.4GHz, 6dBi gain).
• f_c = 2399.7MHz
• f_sc0 = 2.0MHz
• f_sc1 = 2.6MHz
• Baud rate = 1 bps
• RX was replaced with the app BLE Scanner 4.0 by Bluepixel Technologies LLC on an Apple iPhone 13 Pro Max.

We transmitted the same example BLE packet as in Ensworth to ensure that if our setup does not work, it would be explained by physical-layer demodulation issues as opposed to higher-level decoding challenges.

4.2 Signal modeling and theory

We performed signal modeling in Python to analyze the system because the available receiver hardware (i.e., the RTL-SDR) could not down-convert the 2.4GHz frequency band. The modeling is designed to precisely model how the 16-bit timers in BX implement PWM and show what the backscattered signal should look like.

As shown in Figure 6, the subcarrier shifts between 2.00MHz and 2.6MHz every 1µs (20 samples). As mentioned earlier, since the subcarrier is a square wave instead of a continuous sinusoid, there are frequency artifacts around the frequency spikes corresponding to logical 0 and 1. This comprises one of the challenges in BLE backscatter. As shown in the frequency domain representation of the backscattered signal, we have two frequency spikes for logical 0 and 1 as expected. However, there are still frequency artifacts propagated from the subcarrier that could make demodulation more difficult.

Notably, we only model FSK as opposed to Gaussian FSK. As shown by the plots, Gaussian FSK would be infeasible with bit periods as low as 1µs and subcarrier frequencies as low as 2.0MHz and 2.6MHz. In fact, this is likely why Ensworth used subcarrier frequencies as high as 11.7MHz and 12.3MHz: higher subcarrier frequencies enable more cycles per bit period, which enables more fine-grained frequency modulation. Therefore, our proof of concept only attempts to use FSK to backscatter BLE, and we will empirically determine whether an unmodified BLE receiver can receive FSK instead of Gaussian FSK in testing.

4.3 Results

The BLE scanner app did not detect our backscattered packet. We attempted multiple distances and verified that the backscatter setup was functioning correctly at lower frequencies with a Stage One receiver. Also, as mentioned earlier, we used a sample BLE packet that Ensworth has already tested with an unmodified Apple iPad. Therefore, we are convinced the failure was at the physical/demodulation layer.

4.4 Discussion

Without investigating the demodulation layer of the BLE Scanner on the iPhone, and because we didn’t have another HackRF One (which is capable of down-converting the 2.4GHz frequency band), it’s difficult to debug this failure. However, our signal modeling and intuition provide several clues as to why it failed:

• Due to hardware limitations, we could only modulate FSK instead of Gaussian FSK.
• Frequency artifacts in the subcarrier propagated to the backscattered signal.

A combination of these issues likely resulted in the iPhone app failing to decode the backscattered signal.

5. Problems

The biggest problem we encountered was acquiring the right hardware. This process took 1–2 weeks because parts had to be delivered, and we were learning.

Another problem was that we didn’t have a HackRF One to debug the BLE proof-of-concept. We likely could have acquired one if we had more time, but we tested this rather late into the project time window since it was part of Stage Two, making it infeasible given time constraints.

Beyond parts issues, the project went smoothly in areas where we otherwise expected issues. For example, we verified that backscattering a carrier with a single-tone sinusoid and plugging/unplugging the backscatter device caused sudden fluctuations on a spectrum analyzer. This allowed us to spend most of our time debugging demodulation software instead of hardware issues.

6. Future Work

Future work could retry BLE backscatter with a similar setup but use an external oscillator (or a faster microcontroller) to identify the minimum frequency at which you can modulate the subcarrier and still receive BLE packets. With our hardware, 2.0MHz and 2.66MHz was the maximum frequency pair with a high enough frequency resolution we could experiment with. However, if one had the ability to incrementally raise this with an external oscillator, it might provide more useful results. This is an interesting area of future work because lower subcarrier frequencies enable lower power consumption.

Another option is to, instead of using our custom L2 packet protocol, adapt an industry-standard L2 protocol to work with a backscatter physical layer and test achievable throughputs. This might provide a more accurate assessment of how well the backscatter setup works in an experimental setup closer to a real-world environment.

Finally, future work could focus on Stage One and use a receiver with a higher sampling rate. For example, it could use a Hack RF One in RX (in addition to TX) with a max sampling rate of 20Msps. This work could similarly measure throughput for each baud rate and the maximum achievable throughput. Based on our data, a sampling rate of 20Msps may enable baud rates of around 0.25 MHz, so it would be very interesting to see whether this hypothesis is correct!

7. Appendix

7.1 Data

7.2 Code

See github.com/amitferman/FSK-Backscatter for code and documentation.

8. Works Cited

1. Woolley, Martin, et al. “Bluetooth Low Energy — It Starts with Advertising.” Bluetooth® Technology Website, 29 Mar. 2022, www.bluetooth.com/blog/bluetooth-low-energy-it-starts-with-advertising/.

2. Ensworth, Joshua F.. “Ultra-low-power Bluetooth Low Energy (BLE) compatible backscatter communication and energy harvesting for battery-free wearable devices.” (2016).