Thirteen parts. Thirteen layers of signal theory, hardware configuration, protocol dissection, and field methodology. If you've followed this series from the beginning, you've covered more ground than most wireless professionals touch in their first year of serious study. That's not flattery. That's just what the material adds up to.
Most people who start a technical series like this one bail somewhere around Part 4. The concepts get abstract, the hardware gets finicky, and the gap between "I read about this" and "I actually understand it" starts to feel insurmountable. You didn't stop. You worked through Sub-GHz capture, BLE enumeration, NRF24 reconnaissance, and the documentation frameworks that make all of it mean something. Part 12 pushed into advanced capture techniques and the professional edge of what a Flipper Zero with an AIO Board can actually do in a real environment. That was the technical summit.
This is the descent. The part where everything gets organized, labeled, and made repeatable.
What Part 13 Covers: Closing the Grimoire
Why a Final Synthesis Article Exists
A capstone article in a 13-part technical series exists for one reason: because knowledge without a system is just trivia. You can understand signal theory, operate a Flipper Zero with confidence, capture Sub-GHz traffic, enumerate BLE devices, and still walk away from a session with nothing defensible, nothing reproducible, and nothing that would hold up in an incident conversation with a network administrator or a security team. The grimoire methodology closes that gap.
This part doesn't introduce a new technique. It introduces a system for applying every prior technique repeatably, with consistent documentation, consistent hardware configuration, and consistent output that means something six months after you generated it.
That's the series tagline, and it's also the thesis. The grimoire isn't a toolkit for offense. It's a framework for situational awareness.
How This Part Fits the Series Arc
The series opened with signal theory because none of the hardware makes sense without it. It moved through protocol layers, capture methods, and hardware expansion because theory without practice is just vocabulary. It closed, in Part 12, with the kind of advanced work that requires everything that came before it. This final article delivers five concrete things: a kit list, a folder structure, an operating procedure, a defensive checklist, and a closing thesis.
"The difference between a hobbyist and a defender is not the hardware. It's whether the captures survive the session."
Two audiences have been reading this series from the start. Hobbyists building confidence in their own wireless environment. Defenders building evidence they can actually use. Both groups need what this part delivers.
Why It Matters Defensively: The Cost of Undocumented Research
When Curiosity Without Records Becomes Liability
Here's the scenario. You notice something strange on your network. A device you don't recognize. A signal on a frequency you didn't configure. You've been scanning your environment with a Flipper Zero for months, and you have a strong intuition that something is wrong. But when someone asks you to prove it, you have nothing. No timestamps. No baseline comparison. No capture files. Just a feeling.
That feeling is worth exactly nothing in an incident response context.
The credibility gap between "I think I saw something weird" and "here is timestamped evidence with a baseline comparison from three weeks ago" is not a small gap. It's the difference between being taken seriously and being dismissed. Security teams, network administrators, and even your own memory six months from now require documentation that stands on its own.
The realistic threat isn't sophisticated attackers deploying novel exploits. It's the fact that most home and small-business wireless environments have never been inventoried. Nobody knows what's on the network. Nobody has a baseline. When something changes, there's no reference point to compare it against.
The Actual Security Multiplier
Discipline closes the loop between observation and defensible action. Not hardware. You can own every piece of gear in this series and produce nothing useful if you don't document consistently. The grimoire methodology exists to make documentation the default, not the afterthought.
Documentation as the Difference Between Research and Paranoia
Undocumented wireless research is a loop that goes nowhere. You scan, you notice something, you worry, you scan again. Without records, each session is disconnected from every other session. You can't tell whether the unknown device you're seeing today was there last week or appeared overnight. You can't tell whether your signal environment is stable or actively changing.
The grimoire methodology closes the loop. Observation becomes a log entry. A log entry becomes part of a baseline. A baseline makes the next observation meaningful. That's not paranoia. That's operational awareness with receipts.
Theory: The RF Field Notebook as a Living Document
What a Field Notebook Is and Is Not
An RF field notebook is not a folder full of capture files. It's a structured, versioned record of your signal environment over time. The distinction matters. A folder full of captures is an archive. A field notebook is a timeline with context, and timelines are the only thing that makes anomalies visible.
Ad-hoc scanning produces snapshots. One scan tells you what's present at one moment. That's useful the way a single photograph is useful. But it doesn't tell you what changed, what appeared, or what disappeared. A notebook produces a timeline, and a timeline is where the actual intelligence lives.
The field notebook contains four categories of content: raw capture files, session logs with timestamps and environmental notes, device profiles for every identified signal source, and weekly baseline summaries that serve as the temporal anchor for all comparisons.
The Seven-Word Operating Loop Explained
The operating loop for this entire methodology fits in seven words: Scan. Log. Label. Compare. Repeat. Verify. Defend.
Each word is a phase with a discrete output.
Scan produces raw captures. Log produces a session record with timestamps, location, hardware configuration, and environmental notes. Label produces named, organized files and device profiles. Compare produces a delta: what changed since the last baseline. Repeat produces the next scan, which feeds the next log. Verify produces confirmation using a secondary tool, typically an SDR or spectrum analyzer, before acting on an anomaly. Defend produces an action: a network change, a device removal, a configuration update, or a report.
That feedback structure is what makes the field notebook a living document rather than a static archive. The environment changes. The notebook changes with it.
There's an eighth step implied by the loop, and it's the most important one professionally and legally: Escalate only with evidence. Acting on an anomaly without documented evidence puts you in a difficult position. Presenting timestamped captures, baseline comparisons, and a clear chain of observations puts you in a credible one. The seventh step, Defend, should never precede the sixth step, Verify. And escalation should never precede documentation.
The weekly baseline is the temporal anchor that makes all of this function. Without a consistent reference point, Compare produces nothing useful. With one, every session has something to measure against.
Board Components Involved: The Final Kit Assembly
Core Hardware: Flipper Zero and AIO Board V1.4
The Flipper Zero is the primary capture and interaction device for this entire series. It handles Sub-GHz capture and transmission, NFC and RFID operations, infrared, and, with the right apps, BLE enumeration. It's the instrument. Everything else in the kit supports it or extends it.
The AIO Board V1.4 is the expansion layer that turns the Flipper from a capable device into a complete wireless reconnaissance platform. It adds NRF24 coverage for 2.4 GHz devices, dedicated WiFi scanning via an ESP-based module, extended BLE functionality, and additional Sub-GHz antenna options. Without it, significant portions of this series's methodology are inaccessible.
Supporting Gear: Antennas, Storage, Power, and Verification Tools
Labeled antennas matter more than most beginners expect. In the field, an unlabeled antenna collection is a liability. Cross-contaminating a Sub-GHz capture with the wrong antenna introduces errors that are nearly impossible to diagnose after the fact. Label every antenna with its frequency range and connector type before it goes in the bag.
Spare SD cards serve two functions: clean baseline archives and forensic integrity. Rotate cards between sessions so that each baseline lives on its own card, unmodified after capture. A data-capable USB cable is non-negotiable. Charge-only cables will not transfer capture files, and discovering this mid-session is a specific kind of frustration.
Power bank capacity directly affects session completeness. A session that dies at 60% because the battery ran out produces an incomplete capture file that may be worse than no capture at all. Carry at least 10,000 mAh for a full field session.
Documentation Layer: Analog or Digital
A physical notebook or an Obsidian vault both work. What matters is consistency. Pick one and use it every session. The format is less important than the habit.
A phone camera documents physical device placement and antenna configuration. These photos belong in the session log, not in a separate camera roll that gets forgotten.
The optional SDR (Software Defined Radio) is the verification layer for signals the Flipper captures but cannot decode. The optional spectrum analyzer is for professional or serious work requiring frequency domain visualization beyond what software SDR tools provide.
Total kit weight with all components runs approximately 600 to 800 grams depending on power bank size. That's a kit that fits in a small daypack without drama.
Momentum Tools Used: Software, Vaults, and Version Control
Obsidian Vault Setup for RF Notes
Obsidian is the recommended digital notebook for this methodology. The reason isn't features. It's structure. Obsidian's linking model lets you connect a signal observation note directly to the device profile it relates to, which connects to the weekly baseline where it first appeared, which connects to the session log where the capture was made. That web of connections is what makes a folder of notes into an actual knowledge base.
For those who prefer alternatives: plain markdown folders work. Notion works. A physical field notebook works. The methodology doesn't require Obsidian specifically. It requires consistency and a format you'll actually use under field conditions.
Git or cloud sync handles version control. The rule is simple: raw capture files are immutable once saved. Notes can be revised, but every revision gets a timestamp. Captures are evidence. Evidence doesn't get edited.
Phone camera photos integrate directly into Obsidian notes using relative file paths. Drop the photo into the vault's assets folder, reference it with a relative path in the note, and the image appears inline. That keeps the documentation self-contained and portable.
File Naming Conventions That Survive Time
The file naming convention for this methodology is: YYYY-MM-DD_Protocol_Location_Description. An example looks like this: 2026-05-10_SubGHz_Garage_UnknownRepeater.
ISO date format in filenames means every file system sorts your captures chronologically without any additional organization effort. This is not a minor convenience. Across hundreds of captures over months of sessions, automatic chronological sorting is what keeps the timeline readable.
The signal fingerprint card is the final documentation concept in this section. It's a one-page summary per identified device: frequency, protocol, capture date, device type if known, and any behavioral notes. It's the index card version of a full device profile, designed to be scannable in thirty seconds. Build one for every device you identify and keep them in a dedicated folder inside the vault.
Settings to Check: Final Configuration Audit Before Any Session
Flipper Zero Pre-Session Checklist
The pre-session audit is not optional. A misconfigured session produces data that's either wrong or unverifiable, and unverifiable data is worse than no data because it takes time to discover the problem.
Confirm that Flipper Zero firmware is current before every session. Outdated firmware introduces known bugs into capture behavior, and some apps won't function correctly on older builds. Confirm the SD card is mounted and readable from the Flipper's file manager before leaving the house. A card that mounts at home but fails in the field is a known failure mode.
Clock Accuracy Is Not Optional
Set the Flipper's system clock accurately before every session. Timestamps in capture files are only useful if the clock is correct. A capture file with a timestamp that's off by an hour is a documentation liability, not an asset. Cross-reference with your phone's time before starting.
Clear or archive the previous session's raw captures before starting a new one. Mixing captures from different sessions in the same working directory creates confusion that compounds over time. Each session gets its own folder, named with the session date.
Confirm that logging is enabled in the relevant Flipper app before the scan begins. Some apps default to capture-without-logging modes that produce no saved output. Check this before you walk out the door, not after you've spent an hour in the field.
AIO Board and Antenna Verification
Confirm the AIO Board V1.4 is seated correctly and recognized by the Flipper apps that depend on it. A board that's slightly misaligned will appear to function but produce degraded or absent output on specific modules. Verify recognition in the app interface before assuming it's working.
Confirm the correct antenna is attached for the target protocol before scanning. This is the physical equivalent of selecting the right tool. A Sub-GHz session with a BLE antenna produces poor results and no error message to explain why.
If using an SDR for verification, confirm sample rate and gain settings match the target frequency band. Default settings are rarely optimal for any specific target. Check power bank charge level before every session. A battery that dies mid-capture produces an incomplete file that may not be recoverable, and incomplete evidence is often more confusing than no evidence at all. Note the location and environmental conditions in the first log entry of every session, before the first scan runs. That note is the context that makes every subsequent entry in the session meaningful.
Closing the Grimoire
Twelve parts of signal theory, hardware configuration, protocol work, and field methodology led here. Not to a more advanced technique, but to a system.
The grimoire metaphor has held throughout this series because it's accurate. A grimoire isn't a manual. It's a practitioner's accumulated record of what works, what doesn't, and what the environment looks like when you pay attention to it. That's exactly what this methodology produces: a structured, versioned, timestamped record of your signal environment that grows more valuable the longer you maintain it.
The tagline has been the same since Part 1. Not hacking the world. Understanding your own signal environment before someone else does. That's the thesis, and it's also the practice. The kit list, the folder structure, the operating procedure, the defensive checklist, all of it exists to make that understanding systematic rather than occasional.
Hobbyists finish this series with a methodology they can run in their own home. Defenders finish it with an evidence framework they can take into a real incident conversation. Both outcomes are legitimate. Both require the same discipline.
The grimoire is
Step-by-Step Lab: Building and Populating Your Final Folder Structure
Creating the RF_Field_Notes Directory Tree
The folder structure isn't bureaucracy. It's the difference between a field notebook and a pile of files with names like scan1.sub that mean nothing six weeks later.
Start on your Flipper's SD card. Create the top-level directory first.
/RF_Field_Notes/Mirror this exact structure on your laptop immediately. Not later. Now. The SD card is a capture device, not an archive. Cards fail, get lost, and get corrupted. Your laptop copy is the record.
Inside /RF_Field_Notes/, build the following subdirectories:
1/RF_Field_Notes/
2 /SubGHz/
3 /NRF24/
4 /WiFi_BLE/
5 /Unknown_Signals/
6 /Screenshots/
7 /Raw_Captures/
8 /Weekly_Baselines/Each folder has a specific job. /SubGHz/ holds every Sub-GHz capture: garage door signals, weather sensors, mystery repeaters, all of it. /NRF24/ is dedicated to Nordic Semiconductor protocol captures from your AIO board, kept separate because the tooling and analysis workflow differ. /WiFi_BLE/ gets your WiFi probe request logs and BLE advertisement captures. /Unknown_Signals/ is not a shame folder. It's where things go when they don't immediately resolve to a known protocol, and it deserves the same discipline as every other directory.
/Screenshots/ holds Flipper screen captures and phone photos taken during sessions. /Raw_Captures/ stores unprocessed .sub and .bin files before you've run any analysis on them. Don't skip this one. You want the original, untouched file preserved separately from anything you've opened and potentially modified.
Populating Your First Weekly Baseline
The /Weekly_Baselines/ directory uses ISO week numbers. Every baseline folder follows this convention: Baseline_YYYY-WW. Your first session in the second week of any given year becomes Baseline_2026-02. This format sorts chronologically without any additional effort and makes the comparison workflow obvious at a glance.
Your first baseline session has a fixed sequence. Scan Sub-GHz first, log every detected device with protocol, frequency, RSSI, and a short identifier. Save the raw captures into /Raw_Captures/, then move copies into the relevant protocol folder. Do the same for NRF24, then WiFi and BLE. Anything that doesn't resolve goes into /Unknown_Signals/ with a note describing what you observed and when.
After scanning, write a summary note inside the baseline folder. One text file. Date, location, weather, what you found, what you didn't expect. It takes five minutes and it's the most valuable five minutes in the whole workflow.
Archiving and Rotating Old Sessions
Keep the last 12 weeks of baselines active in /Weekly_Baselines/. Sessions older than 90 days move to cold storage, whether that's an external drive, a dedicated archive folder, or a compressed backup. Don't delete them. You may need a baseline from four months ago if something unusual surfaces and you want to trace when it first appeared.
The rotation isn't about saving space. It's about keeping your active working set manageable so comparisons stay fast and the folder doesn't become a graveyard you stop looking at.
What Results Should Look Like: Reading a Mature Field Notebook
A Sample Weekly Baseline Entry
A well-structured baseline entry isn't long. It's complete. Every entry opens with a header block: date, location, weather conditions, and operator name or initials. Weather matters more than most people expect. Atmospheric conditions affect signal propagation, and a device that reads differently on a humid day versus a dry one isn't necessarily malfunctioning.
Below the header sits the device table. Five columns minimum: Protocol, Frequency or Channel, RSSI, Identifier (MAC address, UID, or a consistent hash if you're anonymizing), and Status. The Status column carries one of five values: Known-Verified, Known-Unverified, New-Investigating, Removed, or Unknown. Known-Verified means you've physically confirmed what the device is. Known-Unverified means you've seen it before but haven't confirmed its physical source. The distinction matters when you're trying to explain your findings to someone who wasn't there.
After the device table, write an anomaly notes block. Even if there are no anomalies, write "No anomalies detected this session." The absence of a note is ambiguous. The presence of a note saying nothing unusual occurred is data.
Identifying Signal Drift and New Devices Over Time
A device appearing in Week 4 that was absent in Weeks 1 through 3 triggers an investigation. Not an alarm. An investigation. The correct response is to move it to New-Investigating status, attempt to identify its source, and document what you find. Most of the time, it's a neighbor's new device or a recently activated sensor. Sometimes it's something worth understanding more carefully. Either way, the baseline is what makes the question answerable.
Photo evidence anchors physical location to signal data in a way that coordinates alone don't. A photo of the corner where you stood during a capture, timestamped and filed in /Screenshots/, gives a future reader enough context to replicate your position.
After 12 weeks of consistent baselines, you have enough data to detect most meaningful changes with genuine confidence. That's not a guess. Twelve data points across a stable environment establish a pattern that makes outliers visible.
Common Mistakes: What Breaks the Grimoire Workflow
Documentation Failures That Undermine Credibility
The most common mistake in this workflow isn't technical. It's procedural. People skip the baseline entirely, start scanning reactively after a suspected incident, and then wonder why they can't compare what they're seeing now to what existed before. You can't compare against nothing. The baseline is the whole foundation.
Inconsistent file naming destroys forensic value faster than almost anything else. A folder containing scan1.sub, test_final_REAL.sub, and garage_thing_v3_USE_THIS.sub is not a field notebook. It's a junk drawer. Every file gets a name that includes the date, protocol, and a brief descriptor. Every time. No exceptions.
Timestamp Failures Are Silent Killers
A capture with the wrong timestamp cannot be correlated to any real-world event. Set your Flipper's clock at the start of every session. If the clock drifted, note the offset in your session header. An uncorrected timestamp makes your evidence timeline unreliable.
Treating every unknown signal as a threat is the mistake that turns research into paranoia. Unknown means uninvestigated. It does not mean malicious. The correct response to an unknown signal is to investigate it, document what you find, and update its status. Nothing more.
Publishing raw captures publicly without redacting identifiers exposes your environment to third parties. Your captures may contain MAC addresses, UIDs, and signal timing data that reveal the physical layout of your space. Redact before sharing.
Hardware Errors That Corrupt Captures
Removing the SD card mid-capture is the fastest way to corrupt a file and potentially damage the FAT table. If the table corrupts, every file on the card becomes suspect. Wait for the capture to complete and the Flipper to finish writing before touching the card.
Mixing antennas without logging which antenna was used for which capture makes RSSI comparisons meaningless. A reading taken with a high-gain antenna is not comparable to one taken with the stock antenna. Log the antenna. Every session.
The AIO board expands what you can see. It does not replace understanding what you're looking at. Hardware is a sensor. You're the analyst.
Defensive Takeaway: The Final Eight-Point Checklist
From Observation to Action
The scan loop produces data. This checklist turns data into decisions. Work through it in order, once per quarter at minimum.
When to Escalate and How to Do It Credibly
Escalation is a serious step. It changes relationships, triggers investigations, and carries real consequences if your documentation doesn't hold up.
"Suspicion is not a finding. A timestamped, baselined, compared, and verified anomaly is a finding."
The difference between those two things is every part of this series. Before you escalate anything, verify that the anomaly appears consistently across multiple sessions, that you've ruled out benign explanations, and that your documentation is complete enough for a non-technical reader to follow the chain of evidence.
If you reach that threshold and the anomaly remains unexplained, document your investigation steps, export your evidence in a clean format, and escalate with the record in hand. Not before.
Evidence Log Template: Your Reusable Session Record
Session Header Fields
Every session starts with the same header. No exceptions, no shortcuts.
1Session Date:
2Start Time:
3End Time:
4Location (description + coordinates if available):
5Operator:
6Weather / Environmental Notes:
7Flipper Zero Firmware Version:
8AIO Board Version:
9SD Card Label:
10Antennas Used (list each, note which was used for which protocol):
11Schema Version: 1.0The schema version field is easy to skip and important to keep. If you revise this template six months from now, old sessions stay in their original format and the version number tells you which schema applies to which records.
Device Table Structure
1| Row ID | Protocol | Freq/Channel | Identifier | RSSI | Status | File Ref | Notes |
2|--------|----------|-------------|------------|------|--------|----------|-------|
3| 001 | | | | | | | |
Status values are fixed: Known-Verified, Known-Unverified, New-Investigating, Removed, Unknown. Don't invent new ones. Consistency across sessions is what makes the comparison workflow function.
Anomaly and Action Item Blocks
1## Anomaly Block
2Anomaly Description:
3Evidence File:
4Baseline It Deviates From:
5Investigation Steps Taken:
6Current Status:
7
8## Action Items
9| Item | Owner | Due Date | Status |
10|------|-------|----------|--------|
11| | | | |Action Items Must Be Specific
"Replace garage remote by 2026-08-01" is an action item. "Fix the garage thing" is a wish. Every item needs an owner, a due date, and a status field that gets updated when the work is done.
Paste the full template into Obsidian as a note template. Link it to your /Weekly_Baselines/ folder. The friction of starting a new session should be as close to zero as possible, because friction is what makes people skip sessions, and skipped sessions are gaps in your baseline.
Series Closing Thesis and Reader Action Plan
What Thirteen Parts Actually Taught
This series started with signal theory and the basics of what the Flipper Zero actually is. It moved through Sub-GHz capture and replay, NRF24 protocol analysis with the AIO board, WiFi probe request logging, BLE advertisement mapping, replay attack mechanics, and the legal and ethical framework that makes all of it responsible work. Part 12 pulled those threads together into a coherent defensive methodology. This part gave you the system to sustain it.
That's not a small arc. Most people who pick up a Flipper run a few scans, replay a garage door to impress someone, and put it in a drawer. You went further. You learned what you were seeing, why it mattered, and how to document it in a way that holds up.
The Closing Thesis: Hardware, Knowledge, Documentation, Discipline
The board doesn't make you safe. That's the thesis, stated plainly. The AIO board expands what you can detect, but detection without understanding is just noise with better equipment. Knowledge is the irreplaceable layer. Understanding what a rolling code system does, why NRF24 is still everywhere in consumer hardware, what a BLE advertisement actually contains: that understanding is what separates a researcher from someone who got lucky.
Documentation makes you credible. Discipline keeps the whole system running. The loop is Scan, Log, Label, Compare, Repeat, Verify, Defend. That loop, run consistently over 12 weeks, produces something genuinely useful: a characterized picture of your wireless environment that can detect change, support escalation, and inform real defensive decisions.
Your Action Plan: Start the Loop This Week
Don't wait for the perfect setup. Build the folder structure today. Run your first baseline this week. Commit to 12 sessions.
- Create
/RF_Field_Notes/on your SD card and laptop mirror today. - Run Session 1 of your weekly baseline before the end of this week.
- Log every detected device with protocol, RSSI, identifier, and status.
- Write your summary note before closing the folder.
- Schedule Session 2 for exactly seven days from now.
If you've built something useful from this series, share your field notebook template with the community. Share the structure, not the captures. Responsible sharing means redacting identifiers, keeping your environment's specifics private, and being clear about the scope of your work.
That scope is worth restating one final time. This work is scoped to your own environment, or to environments where you hold explicit written permission to conduct wireless assessment. Everything in this series was built on that boundary. Stay inside it.
The electromagnetic grimoire is yours now. Fill it carefully.
