RF-201 Capstone: End-to-End RF Protocol RE

Mission

You have characterised modulations. You have demodulated LoRa, OOK, GFSK, and BPSK from IQ streams. You have enumerated BLE GATT hierarchies, decoded ZigBee mesh traffic, and applied the URH workflow to an unknown protocol. The capstone unifies all of that in a single end-to-end project: select a real-world wireless target, reverse-engineer its RF protocol from captured IQ, implement a working GNU Radio demodulator, write a protocol specification a successor engineer can read, and package it so the work is reproducible.

Target Requirements

The capstone target must satisfy all four criteria:

Acceptable targets:

• Personal weather station wireless sensor unit (OOK or FSK)
• Sub-GHz home alarm keyfob (transmit-on-press)
• Smart plug with RF remote pairing mode (433 MHz)
• Custom ESP32 wireless sensor built in HW-101 without pre-specified encoding
• Instructor-provided sandboxed ISM device
• Any ISM-band device you personally own with authority to receive

Unacceptable targets:

• Protocols with complete open specifications (LoRa PHY: fully specified in Semtech docs; do not use)
• Any device you do not personally own or have explicit written authority to observe
• Any device that requires transmitting to trigger responses (if you lack an RF-shielded enclosure)
• Your neighbor's or a third party's wireless infrastructure

Required Deliverables

1. Captured IQ Archive

Format: complex64 .iq (GNU Radio default) or .sigmf (preferred; includes metadata) Minimum: 10 complete frame captures across at least 3 separate sessions Size: as large as needed; document the IQ archive in your report

2. URH Protocol Analysis

File: capstone-urh-analysis.urp (URH project file) Content: labelled field boundaries, message type clustering, CRC polynomial, encoding identified

3. GNU Radio Demodulator Flowgraph

File: capstone-demodulator.grc Requirement: processes the IQ archive and produces the same symbol stream as URH, byte-for-byte

4. Written Protocol Specification

File: capstone-protocol-spec.md Sections: physical layer, link layer, application layer (if recoverable), limit-of-confidence statement

5. Reproducibility Package

Files: Makefile with at minimum:

make capture   # documents the capture command; notes if live hardware is needed
make demod     # runs the GNU Radio flowgraph against the IQ archive and prints decoded frames

6. Capstone Report

File: rf201-capstone-[LASTNAME].md or .pdf Length: 15-25 pages Sections: see Week 14 report outline template

Report Section Requirement

Two-Tier Grading Rubric

Tier 1: Does It Work? (Pass/Fail gate)

The capstone must pass all four Tier 1 gates before Tier 2 scoring applies:

Projects that do not pass all four Tier 1 gates receive Incomplete and must resubmit.

Tier 2: Scored Dimensions

Minimum for certificate: B- (≥80%) on Tier 2 after passing all Tier 1 gates.

Limit-of-Confidence Statement Requirements

Every protocol specification must include a Limit-of-Confidence statement. This is not optional.

A complete limit-of-confidence statement answers:

1. Which field interpretations are confirmed byte-for-byte from observed data vs. inferred from behavior?
2. What aspects of the protocol remain unknown (e.g., "the purpose of bits 4-7 of byte 3 could not be determined from the captured frames")?
3. What additional captures or tests would resolve the remaining uncertainties?

Example of a strong limit-of-confidence statement:

"Physical layer (modulation: GFSK, bit rate: 4800 bps, deviation: ±25 kHz) is confirmed with high confidence from both URH auto-detection and manual instantaneous-frequency analysis. The 8-byte address field is confirmed as fixed per device (high confidence; same in 43 captures across 3 sessions). The 1-byte command field is confirmed to encode {0x01: On, 0x00: Off} from observed device behavior (medium confidence; two values seen; existence of other command values not excluded). The 1-byte checksum is confirmed as CRC-8 CCITT with initial value 0xFF (high confidence; verified on all 43 frames). The 4-bit field at bits 12-15 of byte 3 purpose is unknown (low confidence hypothesis: rolling counter; value increments by 1 in most consecutive captures but occasional skips observed)."

Example of an insufficient limit-of-confidence statement:

"I believe the protocol uses OOK and the frame is probably 32 bits with some address and command bytes."

Common Failure Modes

The demodulator produces different output than URH: Usually a clock-recovery alignment issue. The Moving Average or clock recovery block in GNU Radio may have a different timing offset than URH's manual demodulation. Fix by checking that samples_per_symbol matches exactly between URH's bit-rate setting and your GRC flowgraph's symbol rate.

The CRC does not match: Broaden the search (initial values, XOR masks, big-endian vs. little-endian byte order, the data range covered by the CRC). If after exhaustive search the CRC remains unidentified, document the failure explicitly in the limit-of-confidence statement.

The limit-of-confidence statement is incomplete: Common error: claiming a field is an "address" without evidence that it is stable per device. Evidence standard: the field must be the same in all captures from one device and different in captures from a second device (if a second device is accessible).

The report is under 15 pages: Protocols are more complex than they look. If your analysis is thorough, 15 pages is a minimum, not a target. Short reports usually indicate insufficient depth in the frame structure RE, protocol spec, or security observations sections.

Capstone Presentations

Week 14 workshop presentations: 10 minutes per student.

Required content:

• Target description (1 slide or whiteboard section)
• The most interesting or surprising finding (not just "I found OOK")
• The limit-of-confidence statement for the most uncertain aspect
• One security observation

The 10-minute format is strict. Students who go over will be cut off at 10 minutes, which mirrors real-world security review board presentation constraints.