Neil’s 2025 class reverse-engineered a Hunter ceiling-fan remote, a low-power transmitter near 350 MHz that operates under FCC Part 15. Not every cadet has that fan, so this lesson uses a Simulated fan remote of our own with five buttons: Light, Fan Off, Low, Medium, and High. Its recording, L17-fan-remote.sigmf-data, holds one press of each button, and the figure is that recording in L17-chips.grc, a GNU Radio flowgraph that reads each burst as a line of on and off chips.

The two lines of the objective from 2025 set the plan: reverse engineer a simple RF transmitter, and create a GNU Radio flowgraph that operates the fan. Lesson 11 found the bursts of a 433.92 MHz remote with an energy detector, and Lesson 12 keyed a carrier on and off. Today we read what those bursts say.

The process comes from the 2025 slides. First we find the carrier, the frequency the transmitter uses. Next we identify the modulation, what the transmitter changes to send information. Then we identify the encoding: what the commands are, how the bits group into bytes or nibbles, and the bit rate and baud rate. With those three answers we build an encoder that produces the same signal, and last we transmit it.

Steps 1 to 3 work entirely from a recording, so they need no radio. Step 5 transmits: a cadet’s transmitter goes into a cable with an attenuator, or over the air at 915 MHz at low power only if I say so, and I close the lesson by operating the real fan over the air. Every step runs in GNU Radio: a capture flowgraph finds the carrier, as in 2025, and L17-chips.grc takes the bursts apart.

In 2025 the first tool was a GNU Radio capture flowgraph: a PlutoSDR Source, a SigMF Sink (Minimal) to record, and frequency, time, and waterfall sinks. That flowgraph is L17-capture.grc, with a PlutoSDR Source. L17-sigmf-view.grc is the same flowgraph with a SigMF Source in place of the radio: the recording, a Throttle, and a Frequency Sink and Waterfall Sink centered at 350 MHz. The recording loops, so the bursts come back every 2.4 s.

Two signals appear. A narrow line near 349.945 MHz stays on the whole time. The bursts near 350.04 MHz come and go five times per loop, once for each button press, and that is the remote. A real band holds many steady carriers, such as another receiver’s oscillator or a nearby digital clock, so the waterfall is how we tell them apart: the remote’s signal starts and stops when someone presses a button. The bursts are wider on the spectrum than the steady line because switching a carrier on and off spreads it.

The Frequency Xlating FIR Filter shifts the frequency set by the Carrier offset slider down to 0 Hz and keeps \(\pm 10\) kHz around it, as in the GNU Radio wiki’s Frequency Shifting tutorial. A Complex to Mag block then gives the signal’s envelope, and the time sink triggers on a rising edge at 0.5, so it holds one frame still on screen.

At 40,000 Hz the pulses appear. In the 2025 class the next move was to fine-tune the carrier on a live spectrum; with a recording, the slider does the same thing. Move the offset 10 kHz away from 40 kHz and the pulses drop to half their height, because the signal now sits at the edge of the filter; move it 20 kHz away and they disappear. The carrier is at \(350.000 + 0.040 = 350.040\) MHz.

The recording showed one remote; the air around you holds many. L17-explore-pluto.grc is L17-capture.grc without the SigMF Sink: a PlutoSDR Source at 2 MS/s, the same spectrum, waterfall, and envelope displays, and a Center frequency control you can change while it runs. It records nothing, so the center frequency does not have to be set before it starts. It opens at 433.72 MHz, 200 kHz below 433.92 MHz, so the Pluto’s DC spike at the center stays off the devices.

Look for what Step 1 taught: a steady line is a carrier that never stops, and a remote, a doorbell, or a weather sensor paints short streaks that come and go. Weather sensors send on their own about once a minute, so wait a minute before you move on. If the whole spectrum rises when a strong signal appears, lower the RX gain. Then step the center frequency to 314.8 MHz and look again; the course Plutos are set to tune from 70 MHz to 6 GHz, so 315 MHz is in range. The Pluto only receives here.

SDR Flex is an optional quick look at the same band; nothing in this lesson needs it.

The 2025 class captured a real remote, and every step so far works the same on one. Take a key fob, a wireless doorbell, or a weather sensor that you own; in the U.S. most use 315 MHz or 433.92 MHz, FCC Part 15 frequencies. Find it first with L17-explore-pluto.grc, then run L17-capture.grc with the variable fc set about 200 kHz below the device’s frequency, so the Pluto’s DC spike stays off the signal. Set it before you start the flowgraph, because the SigMF Sink writes the center frequency into the meta file when the flowgraph starts. Press each button a few times, close the flowgraph, and rename capture.sigmf-data and .sigmf-meta for that button.

In 2025 the class fine-tuned the carrier on a live spectrum: hold a button down and read the peak off L17-explore-pluto.grc’s spectrum. Then open the recordings in L17-chips.grc as in Step 3. Receiving is always allowed, and your Pluto only receives in this step. A car key fob usually sends a rolling code, which changes with every press, so its frames will not repeat from press to press; the L17 Lab asks why.

The question for Step 2 is what the transmitter changes. The envelope plot shows the amplitude jumping between zero and one level, with nothing in between. The waterfall shows the bursts in one place; an FSK signal would show two tracks, as in Lesson 8, and a PSK signal would stay on at constant amplitude, as in Lesson 15. A carrier switched fully on and off is on-off keying (OOK), the simplest form of amplitude-shift keying (ASK). It is Lesson 12’s CW, keyed hundreds of times faster by a circuit instead of a hand.

Most simple remotes, doorbells, and weather sensors use OOK, because the transmitter is one oscillator and one switch, and the receiver needs only an envelope detector like Lesson 11’s.

The 2025 class practiced Step 2 on a set of unknown recordings, the SigID exercise: open each one in a frequency and waterfall flowgraph with a SigMF Source (Minimal) and say what it is. The three recordings here are Simulated, 0.8 s each at 100 kS/s; set rec to each file in turn. The figure shows their spectrograms, time going up.

L17-chips.grc starts as Step 1’s flowgraph: the SigMF Source, the shift to 0 Hz, and Complex to Mag for the envelope. The time sink triggers at the threshold, so it holds a frame still. The shortest pulse lasts 400 µs, and at 200 kS/s that is \(200{,}000\ \text{S/s} \times 400\ \mu\text{s} = 80\) samples. We call each 400 µs slot a chip, because the next frame shows it takes more than one chip to make a bit.

The other branch turns the envelope into chips. Add Const subtracts the threshold, so on is above zero and off below, and Binary Slicer outputs a 1 or a 0 for every sample. A Keep 1 in N with N = 80 would keep one sample per chip, but it would start counting anywhere. The Chip Reader, a short Embedded Python Block saved in the .grc file, does the same keeping, but it starts at each burst’s first rising edge and takes the sample in the middle of each chip. After 8 off chips the burst has ended; when the next burst starts, the reader prints the line in GRC’s console with the pause, the off samples between the two bursts, and shows it in the window. The SigMF Source loops the recording, so the last burst prints too. The Envelope gain slider raises a weak capture’s pulses to about 1, so the threshold stays near 0.5.

The Chip Reader prints the Light button’s frame as 46 chips: 1101001101001001101101001001001001101101101101  pause 2560 samples. Split into groups of three, it starts 110 100 110 100 100 110 110 100, and every group is 110 or 100, which is pulse-width coding: each bit starts with the carrier on, a 1 stays on for two chips and a 0 for one, and each bit ends off. The figure shows it beside two other common schemes. In pulse-distance coding every pulse is short and the length of the gap carries the bit; in Manchester coding every bit has a transition in its middle, so the chips come in pairs. The figure draws a 1 as on then off; IEEE 802.3 Ethernet uses the opposite convention, so a Manchester device can use either.

A frame of 16 bits is 48 chips, yet the Chip Reader prints 46 or 47. The last chip of every bit is off, and a frame ending in a 0 ends in two off chips; the reader ends a line at its last on chip, so it counts those chips as part of the pause. We add them back.

Reading every press the same way gives one 16-bit word per button:

The first byte is the same for every button, so it identifies the remote, the way the DIP switches inside a real fan remote pick its code. The third nibble counts up with the buttons. The last nibble is the third one with every bit flipped, so a receiver can reject a frame whose two nibbles disagree.

Raise the Noise amplitude in the explorer a step at a time, and press new noise a few times at each step. Up to about 0.4 the envelope roughens but the frame reads correctly. From about 0.45 chips start to land on the wrong side of the threshold, and most often that breaks a group, so it reads as neither 110 nor 100 and shows ?; by 0.5 almost every frame has a broken group. Now and then a flipped chip turns one bit into the other instead, and then the frame still reads as 16 bits but the Frame readout says the check fails.

The Chip Reader shows the same thing on a real recording: as the signal weakens, its lines of chips stop matching from one repeat to the next. A receiver throws away a frame it cannot read. The check catches a frame that reads but has a wrong bit in the command; a flipped address bit passes it, and the frame then reads as another remote’s. Remotes repeat each frame so that one of the six tries usually gets through.

The encoder is the 2025 hier block laid out flat. A Vector Source repeats the 16 bits of the chosen button’s word. A Map replaces each bit with a number whose binary form is its chip pattern, 0 with 4 (100) and 1 with 6 (110), and Unpack K Bits with \(K = 3\) writes those three bits out one at a time, most significant first. Repeat holds each chip for chip_len = 80 samples, 400 µs at 200 kS/s.

The Stream Mux takes \(48 \times 80 = 3840\) samples, one frame, from the encoder, then \(30 \times 80 = 2400\) samples of zero from a Constant Source, the 12 ms gap, and repeats. Float To Complex and a Multiply with a 40 kHz Signal Source put the envelope on the carrier, as Lesson 12’s keyer did. L17-encoder.grc packs the whole chain, from the Vector Source to the Multiply, into one hier block, as the 2025 class did and as the GNU Radio wiki’s Hier Blocks and Parameters tutorial describes. The Map comes before Unpack K Bits because it is the Map that turns each bit into its chip pattern.

L17-fan-tx-sim.grc runs the encoder with no radio. Its envelope plot should match the recording’s frame for the same button, pulse for pulse, and its SigMF Sink writes what it makes to my-fan-remote.sigmf-data and .sigmf-meta while it runs. Run it for a few seconds, close it, and set rec in L17-chips.grc to my-fan-remote.sigmf-data: with the same settings as for L17-fan-remote.sigmf-data, the lines of chips should be identical.

That comparison is the test of the reverse engineering. If our encoder makes chips the original receiver would accept, we have found the carrier, the modulation, the encoding, and the fields correctly. One difference remains: the encoder repeats its frame for as long as it runs, while the remote stops after six.

The last step puts the encoder on a radio. L17-fan-tx-pluto.grc is the simulation flowgraph at 1 MS/s, so chip_len is 400 samples, with a PlutoSDR Sink tuned to 915 MHz in place of the noise and the waterfall; the 40 kHz tone puts the carrier at 915.04 MHz. A signal the course makes never goes out on the real device’s frequency, so the encoder leaves the remote’s 350 MHz for 915 MHz. A short SMA cable with an inline 30 dB attenuator carries it to a second PlutoSDR running L17-capture.grc, with fc at its default of 915e6, which records what arrives at 1 MS/s as a SigMF pair. Open that recording in L17-chips.grc with samp_rate 1000000, fc 915e6, and a chip length of 400. Two Plutos’ clocks can disagree by several kilohertz at 915 MHz, so read the bursts’ offset off the capture’s spectrum and set the carrier offset to it, not to 40 kHz, and raise the Envelope gain until the pulses reach about 1: the chips should match L17-fan-remote.sigmf-data.

Cadets transmit into a cable with the 30 dB attenuator, or, if I say so, over the air at 915 MHz at low power, and only when the lesson says to. 915 MHz is in the U.S. 902 to 928 MHz ISM band; the remote’s 350 MHz is an FCC Part 15 frequency, not an ISM band. The TX attenuation slider opens at 60 dB and cannot go below 30 dB; connect an antenna to this flowgraph only when I say so.

The 2025 class ended by operating the fan, and this one does too, as a demo: I record the classroom’s Hunter fan remote, decode it with the same steps, and send its Light command from my own encoder flowgraph over the air, a few meters from the fan, at the lowest power that still works it. The fan answers a transmitter it has never seen, which is the point of the lesson: a fixed code has no way to tell the two apart. The cadet Pluto flowgraphs have been compiled but not run on a radio, so the L17 Lab is their first run on hardware.

The L17 Lab is today’s process on a device you have not seen. You get a SigMF recording of a Simulated remote with several buttons, with settings of its own, and you find its carrier, modulation, encoding, and fields, build an encoder for it from an empty canvas, check your encoder against the recording in L17-chips.grc, and then send it at 915 MHz through a PlutoSDR and a cable to a second PlutoSDR.

Lessons 18 and 19 receive aircraft and ship transponders. Their formats are public standards, so there the work is building and running the receiver rather than discovering the format.