The Embedded Engineer’s Second Brain
More information is not equal to more clarity, Here I have assembled a simple guide to turning information overload into clarity using Tiago Forte’s the CODE and PARA methods.
How I stopped drowning in datasheets and started actually using my notes
1. The Problem: Information Overload
When was the last time you felt overwhelmed by your own notes, bookmarks, or saved articles?
The average person now consumes roughly 34 gigabytes of information daily (as per 2008 study by the University of California, San Diego (UCSD) titled “How Much Information? - Source). For embedded engineers this is compounded by a relentless stream of new vendor specifications, silicon errata, GitHub updates, and evolving standards. Instead of empowering you, this deluge creates Information Exhaustion — a chronic anxiety that you are about to forget a critical technical detail, it gets worst when delivery deadline is close.
In embedded development the problem has a particular shape. You are managing two very different categories of knowledge simultaneously:
- Volatile market knowledge: datasheets, hardware errata, GitHub issues, SDK changelogs, community forum workarounds — knowledge that shifts with every silicon revision and project requirement.
- Fundamental engineering knowledge: software design principles, debugging heuristics, right questions to ask clients before kick-off, architectural patterns — knowledge that compounds over a career.
Without a deliberate system, both categories pile into the same undifferentiated heap. This is the Information Paradox: more notes = less clarity.
2. Why It Happens
Information overload occurs because we act as information hoarders — saving content we do not have time to apply, driven by a scarcity mindset and FOMO. Saving a 500-page datasheet feels productive. But that comfort comes at a cost.
- The illusion of control: 200 saved datasheets feels like having options. It is really procrastination disguised as preparation.
- The emotional attachment: Some notes represent late-night debugging sessions and hard-won breakthroughs. Letting go feels like erasing part of your engineering history.
- The anxiety of letting go: What if you delete that forum thread and need it tomorrow? What if you miss the one errata that bricks a production run? This fear keeps you hoarding digital clutter.
- The scarcity mindset: In practice, most insights are rediscoverable. What matters is curating what serves your current project, not stockpiling for every possible future.
3. Collecting is Easy — Retrieval is Where Things Break Down
We confuse saving with understanding. Ask yourself honestly: how many of your saved articles, datasheets, and bookmarks do you actually use?
When you organise notes by broad academic subjects — a folder called Embedded Systems or Microcontrollers — finding information becomes a herculean endeavour as your note count grows. Without discoverability, your notes become an idea graveyard where the specific fix for an I2C clock-stretching bug is buried under a wall of generic technical content.
The fundamental mistake is organising by where information came from rather than where it is going. A note filed under “STMicroelectronics” sits in the same place whether you need it today or in three years. That is a filing cabinet, not a thinking tool.
The right question is not “What is this about?” — it is “Which active project will this serve?”
4. Seeing the Bigger Picture: Connecting Dots
Real original ideas are formed when you treat notes as knowledge building blocks — discrete units of information that can be combined and reassembled like LEGOs. By keeping diverse technical and conceptual material in one structured system, you begin to surface associations between seemingly unrelated ideas.
For an embedded engineer this is where the leverage lives. A software design pattern from a high-level enterprise library can be adapted for a resource-constrained bare-metal driver. A debugging heuristic from one vendor’s silicon can transfer directly to a competitor’s. A risk analysis technique from safety-critical automotive firmware can sharpen the design of an IoT consumer device.
This kind of cross-domain thinking only emerges when your Second Brain is organised for action and association, not for storage.
5. Too Many Apps, Too Many Approaches
The digital landscape offers no shortage of tools: Obsidian, Notion, OneNote, Evernote, Roam, Logseq, Bear. It is easy to get caught in the trap of tool perfectionism — endlessly searching for the perfect app instead of building a reliable system.
The truth is that the tool matters far less than the method. Your Second Brain needs a single, consistent neural centre — a digital workspace that is multimedia, informal, and action-oriented. Pick one and commit. Evernote maps cleanly onto the PARA system and its search is fast enough to make retrieval genuinely painless. Obsidian works if you prefer linking. OneNote works if you live in Microsoft 365. The system below is software-agnostic — run it in whatever app you will actually open every day.
6. Sticking with the Basics: CODE and PARA
These methods were developed & demostrated by author Tiago Forte in his book “Building a second brain”
Two complementary systems to do the heavy lifting with resourse organisation & retrival . Both shift your focus from where information came from to where it is going.
The CODE Method — lifecycle of every note
flowchart LR
C["C — CAPTURE\n───────────\nWeb clipper for forums\nDatasheet sections only\nGitHub errata & fixes\nClient spec snippets"]
O["O — ORGANISE\n───────────\nFile by project first\nThen Area or Resource\nTag cross-cutting themes\nArchive on close"]
D["D — DISTILL\n───────────\nBold critical constraints\nHighlight design rationale\n3-bullet summary (rare)\nRemove the noise"]
E["E — EXPRESS\n───────────\nReuse driver stubs\nShip checklists as IPs\nWrite decision records\nAssemble, don't create"]
C --> O --> D --> E
| Stage | What it means | In embedded practice |
|---|---|---|
| Capture | Save only what resonates | Clip forum workarounds, Theory of Operation sections, race condition fixes — not entire 500-page manuals |
| Organise | File by actionability (PARA) | Ask: which active project does this serve? File there first. Resources only if no current home |
| Distill | Extract the essence progressively | Bold critical constraints; highlight design rationale; write a 3-bullet summary for foundational notes |
| Express | Turn notes into output | Reuse driver stubs, checklists, architecture sketches — assemble before creating from scratch |
The PARA Structure — where notes live
flowchart LR
note(["New note captured"])
note --> q1{"Active project\ndeadline?"}
q1 -- "Yes" --> P["[P] Projects\n─────────\n[P] STM32H750B Bring-up\n[P] Debug I2C Clock-Stretch\n[P] OV7670 AI Inference"]
q1 -- "No" --> q2{"Ongoing\nresponsibility?"}
q2 -- "Yes" --> A["[A] Areas\n─────────\n[A] Firmware Coding Standards\n[A] HW Testing Procedures\n[A] Client Req. Management"]
q2 -- "No" --> q3{"Reference with\nno current project?"}
q3 -- "Yes" --> R["[R] Resources\n─────────\n[R] Vendor: STMicro\n[R] RTOS Design Patterns\n[R] BLE Protocol Stack"]
q3 -- "No" --> X["[X] Archive\n─────────\n[X] HeartRate Monitor v1\n[X] ESP32-CAM Streamer\n[X] Client A — Closed 2024"]
P -. "project closes" .-> X
When a note is captured during an active project, it goes into the [P] Project notebook directly — not Resources. Resources are only for material with no current home.
7. How CODE Fits Into Everything Else
CODE works with whatever system you are already using. It adds a knowledge layer on top of your existing task workflow.
Integrating with your task system
Your task system handles what you do. CODE handles what you know. They work better together:
- Quick tasks: use distilled notes for 2-minute reference lookups — no re-reading required.
- Scheduled work: block time to express ideas from organised notes into drivers, docs, or specs.
- Backlog research: keep captured notes in Archives for future projects — searchable, not cluttering.
Weekly review integration
I do a weekly reset. Adding CODE to it takes about 15 minutes:
- Review captured items — decide what resonates vs. what to archive immediately.
- Reorganise notes — move completed projects to
[X] Archive, promote Resource notes to active[P]notebooks if a project has started. - Distill backlog — take any notes tagged
.ToDistilland apply Layer 2 bolding. - Plan expression — schedule time to create from your knowledge base: a blog post, a driver PR, a client update.
Automating the system
Once the structure is stable, you can reduce friction significantly:
- Note templates: reuse distilled structures for repeated note types (datasheet summaries, client kickoff notes, post-mortems). The three templates at the end of this post are your starting point.
- Tag shortcuts: create saved searches in Evernote for your most common tag combos —
tag:.EdgeCase tag:.Vendor_STbecomes a one-click lookup. - Quick capture: use Evernote’s mobile clipper or a dedicated capture app so saving has zero friction. The curation happens later, not at capture time.
8. Binding It All Together: Tell Your Story
Ultimately, personal knowledge management exists to support action. Your Second Brain should function not as a warehouse but as a factory — turning raw information into tangible engineering output: a finished PCB design, a robust firmware driver, a client-ready requirements justification document.
The test of whether your system is working: when you start a new project, how long does it take to find a reusable driver stub, a past edge-case note, or a client requirements template? If the answer is more than two minutes, the system needs refining.
Case Example: Organising Engineering Notes with CODE and PARA
Problem Statement
Embedded systems development demands mastery of two parallel knowledge tracks: volatile market knowledge (datasheets, errata, GitHub issues) and fundamental engineering knowledge (design principles, debugging methods, client communication). Without a deliberate system, both collapse into an undifferentiated pile and the retrieval problem described above takes hold.
C — Capture: Use the Curator’s Perspective
Do not save entire 500-page datasheets. Apply the Curator’s Perspective: save only what is surprising, counterintuitive, or directly relevant to a current goal.
- Datasheets and reference manuals: save only the “Theory of Operation” and “Application Information” sections. These contain the API-like logic for driver development. Link to the full PDF — do not paste it.
- GitHub issues and forum threads: clip workarounds only — undocumented errata, race condition fixes, timing gotchas. Generic “how to init UART” tutorials add noise.
- Newsletters and articles: use a read-later app, highlight 2–3 insights that resonate, export only those highlights.
- Client requirement documents: extract the constraints that are surprising or non-obvious — the standard stuff goes in the template, the edge constraints get their own note.
Research like a detective, not a librarian.
Don’t read datasheets cover-to-cover. Scan for the 3–5 specs that directly impact your current requirements. Ask: “Does this help me decide yes/no on this component?” If not, skip it. Set a 30-minute timer per component research session.
O — Organise: PARA in Embedded Practice
File by actionability. The most important rule: when a note is captured during an active project, it goes into that Project notebook directly — not into a Resources folder.
Tagging: Cross-Cutting Themes PARA Folders Cannot Handle
The same silicon may appear in three different projects over two years. Tags let you surface all of it instantly regardless of which project folder it lives in.
| Tag category | Example tags | When to apply |
|---|---|---|
| Vendor | .Vendor_ST .Vendor_TI .Vendor_Nordic .Vendor_Espressif | Any note touching that vendor’s silicon, SDK, or toolchain — regardless of which project folder it lives in |
| Requirement type | .Req_Hardware .Req_Software .Req_Safety .Req_Security | Notes that document a specific requirement — lets you surface all impact when a client changes a spec |
| Edge cases | .EdgeCase .CornerCase | Undocumented errata, broken hardware behaviour, inexplicable user commands — your institutional testing memory |
| Work state | .IntermediatePacket .ToDistill .PostMortem | Tracks whether a note is a reusable asset, needs processing, or documents a past failure |
Retrieval Planning Matrix
Before starting a new project, spend 10 minutes planning how you will find information later — not just how you will store it. Poor tag planning creates organisation debt: you will spend more time searching than researching.
| When I need to… | Search tags | Folder location |
|---|---|---|
| Debug a peripheral issue | tag:.EdgeCase tag:.Vendor_XX | [P] Current Project or [X] Archive |
| Find a past driver implementation | tag:.IntermediatePacket tag:.Vendor_XX | [R] Vendor: XX |
| Review all open requirements | tag:.Req_Hardware tag:.Req_Software | [P] Current Project |
| Look up a protocol gotcha | tag:.EdgeCase tag:i2c (or spi, uart…) | Any stack — search cuts across all |
| Start a similar future project | tag:.PostMortem tag:.IntermediatePacket | [X] Archive |
Organisation Debt
Poor folder/tag planning means you will spend more time searching than engineering. Fix your structure before you start a project, not during crunch time at 2am.
D — Distill: Progressive Summarization
Apply layers incrementally — only distill notes you actually return to. The goal is rapid retrieval during a high-pressure debugging session.
- Layer 1 — Raw excerpt: the captured note as-is. Register map, timing diagram, forum post. No editing.
- Layer 2 — Bold critical constraints: bold specific numbers your future self will need fast: max SPI clock, PSRAM alignment requirement, reset vector address, required pull-up value.
- Layer 3 — Highlight design rationale: highlight the bolded points that explain why a design choice was made. The “why” is what gets lost over time.
- Layer 4 — Executive summary (rare): for foundational principles only. Three bullets at the top so context is visible before reading a single line of detail.
Example distillation — MCU comparison table (Layer 3 output):
| Criteria | STM32L476 | ESP32-S3 | Decision factor |
|---|---|---|---|
| Stop 2 current | 120 nA | 5 µA | STM32 wins for battery life |
| BLE stack | External (SoftDevice) | Built-in | ESP32 simpler if BLE is core |
| ADC resolution | 12-bit, 16 ch | 12-bit, 20 ch | Tie |
| FreeRTOS support | Yes | Yes | Tie |
| Wake latency | 5 µs (HSI16) | ~2 ms (full boot) | STM32 wins for real-time wakeup |
Apply layers incrementally, not all at once. Only distill notes you actually return to. The goal is rapid retrieval for your future self — not perfect documentation for its own sake. Distillation = decision acceleration.
E — Express: Intermediate Packets
Before writing any new code or documentation, spend 15 minutes searching your IP library first. The goal is to assemble, not to create from scratch.
| IP type | Examples | Tag to find it |
|---|---|---|
| Driver stubs | I/O map header template, SPI/I2C init scaffold, DMA Tx boilerplate | .IntermediatePacket + .Vendor_XX |
| Process checklists | Project kick-off checklist, HW bring-up sequence, code review checklist | .IntermediatePacket + [A] HW Testing |
| Architecture sketches | FreeRTOS task layout, layering diagram, context diagram | .IntermediatePacket |
| Post-mortems | Bug symptom → root cause → fix → time lost | .EdgeCase + .PostMortem |
| Logging abstraction | Interface that swaps UART / RTT / semihosting without changing call sites | .IntermediatePacket |
Design Decisions: Making Choices Justifiable
Your Second Brain should make design decisions justifiable — to yourself six months later, to teammates, and to non-technical stakeholders. Before opening any datasheet, answer these core questions first:
Don’t skip requirements capture.
Many engineers jump straight to component shopping without clarifying requirements. This leads to picking familiar parts instead of optimal ones. Spend 15 minutes answering the questions below — your future self will thank you during debugging.
Core Questions Before Opening Any Datasheet
flowchart TD
A["Core Questions\n──────────\nWhat must it do?\nFor whom? How many units?"] --> B["Requirements Capture\n──────────\nFunctional: measure, control, communicate\nPerformance: speed, accuracy, power\nInterface: how does it connect?"]
B --> C["Constraints Assessment\n──────────\nBudget & timeline\nTeam experience level\nTask parallelism needs\nEnvironmental limits"]
C --> D["Decision Categories\n──────────\nMCU selection\nCommunication protocol\nSensor / actuator choice\nPower management"]
D --> E["Success Criteria\n──────────\nMust-haves (deal-breakers)\nNice-to-haves\nRisk factors"]
Answer these before comparing chips. Otherwise you will spend three days reading datasheets before realising none of them fit your actual requirements.
Navigating Documentation with CODE
For each major decision (MCU, protocol, sensors, power), run one CODE cycle:
flowchart LR
subgraph Design["Hardware Design Flow"]
A[Requirements] --> B[MCU Selection]
B --> C[Protocols]
C --> D[Sensors]
D --> E[Power]
E --> F[Prototype]
end
subgraph CODE_cycle["CODE at each step"]
G["Capture\nresearch"] --> H["Organise\nby decision"]
H --> I["Distill\ncompare options"]
I --> J["Express\ndocument choice"]
end
B -.-> G
C -.-> G
D -.-> G
E -.-> G
The result: decisions in hours instead of days, with documented reasoning that is easy to adapt later.
1. Design Pattern Justification Notes
For each significant architectural choice, record not just what pattern was used but why it was chosen over the alternatives and what it protects you from in the future:
- Facade pattern: chosen to simplify complex library interfaces and hide hardware details from the application layer. Future-proofs against SDK version changes.
- Adapter pattern: chosen to let hardware change without rewriting upper-level software. Document the exact interface contract being stabilised and which concrete driver implements it today.
- MVP / MVC: chosen to segregate algorithms from hardware for independent host-side testing. Pair with FreeRTOS task boundaries: model in one task, display in another.
- Dependency Injection / DIP: chosen for testability — mock the HAL layer in unit tests without real hardware. Document which interfaces are injected and which are concrete.
2. Risk and Security Analysis Note
One note per project: list specific threats you are defending against, the weakest link identified, and cost-of-mitigation versus cost-of-breach. This makes security spending justifiable to non-engineers and provides an audit trail if requirements change mid-project.
Retrieval → Bigger Picture: A Worked Example
This is where the system pays off. You are mid-project — designing a low-power wearable heart-rate monitor with an STM32L476 MCU, an AFE4404 optical front-end, and a BLE link — and you need to decide whether to put the AFE in continuous-sample mode or triggered-sample mode. You open Evernote and pull four notes. Together they produce a decision you would not have reached by looking at any one note alone.
Note 1 — Datasheet snippet: AFE4404 (Texas Instruments)
Source: SBAS700B — AFE4404 Datasheet, Section 8.3 "Theory of Operation"
Tags: .Vendor_TI
Stack: [R] Vendor: TI
Raw capture (Layer 1)
AFE4404 Dynamic Power-Down mode: the device can power down all analog blocks between LED pulses. Wake-up time from DPD to first valid sample: 50 µs typical, 100 µs worst-case (−40°C). LED driver average current in continuous mode at 50 mA peak, 25% duty cycle: 12.5 mA average — dominant power term. PRF (pulse repetition frequency) range: 10 Hz to 1000 Hz.
Layer 2 bold: wake-up latency 100 µs worst-case; LED average current 12.5 mA at 25% duty; minimum PRF 10 Hz.
Note 2 — Reference manual snippet: STM32L476 (STMicroelectronics)
Source: RM0351 Rev 9, Section 5.3.7 "Low-Power Timer (LPTIM)"
Tags: .Vendor_ST
Stack: [R] Vendor: STMicro
Raw capture (Layer 1)
LPTIM can trigger an ADC conversion and wake the core from Stop 2 mode. Wakeup latency from Stop 2: approx. 5 µs with HSI16 as wakeup clock. Stop 2 current (all peripherals off, SRAM retained): 120 nA typical at 25°C. LPTIM runs on LSE (32.768 kHz) — minimum timer resolution 30.5 µs.
Layer 2 bold: Stop 2 = 120 nA; wakeup 5 µs; LPTIM resolution 30.5 µs — total wakeup chain fits inside AFE’s 100 µs worst-case window.
Note 3 — Forum edge case: I2C hang after Stop 2 wakeup
Source: ST Community forum — "I2C lockup after STM32 Stop Mode wakeup" (Jan 2023)
Tags: .Vendor_ST .EdgeCase
Stack: [P] HR Monitor Design
Edge case (Layer 2 bolded)
Multiple users report I2C bus lockup after exiting Stop mode if SCL is released while a byte transfer is in progress. The AFE4404 holds SDA low mid-byte. Workaround: issue a 9-clock pulse sequence on SCL before re-enabling the I2C peripheral after wakeup, or use bit-bang recovery. ST HAL does not handle this automatically as of HAL v1.11.
Layer 2 bold: must add I2C bus recovery after every Stop 2 exit before issuing AFE config writes.
Note 4 — Client requirements capture
Source: Client kickoff call notes — Project [P] HR Monitor Design
Tags: .Req_Hardware .Req_Software
Stack: [P] HR Monitor Design
Requirements (Layer 2 bolded)
Battery life target: 72 hours continuous monitoring on a 180 mAh LiPo. BLE advertising interval: 1 second. Heart-rate sample rate: minimum 25 Hz to meet PPG motion artifact rejection algorithm requirement. Display: none (data streamed over BLE only). Maximum average system current budget: ~2.1 mA (180 mAh ÷ 72 h × 0.85 derating).
The insight that retrieval produces
What four notes together produce that none of them states alone
Triggered-sample mode is not just preferable — it is the only option that fits the power budget. At 25 Hz PRF, continuous mode draws 12.5 mA from the LED driver alone against a 2.1 mA system budget. Triggered mode using LPTIM + Stop 2 keeps the MCU at 120 nA between samples. The AFE’s 100 µs wakeup window is comfortably cleared by the STM32’s 5 µs Stop 2 exit.
The edge-case note flags a non-obvious implementation requirement: I2C bus recovery must be added after every wakeup — something the AFE datasheet and the MCU reference manual each in isolation give no reason to expect.
The datasheet note gave you the power numbers. The reference manual note gave you the wakeup timing. The edge-case note gave you the implementation trap. The requirements note gave you the constraint that made the decision obvious. Stored separately they are raw material. Retrieved together they produce original engineering judgement.
Using Notes for Presentations and Communication
Your Second Brain is not just a personal tool — it is also the source material for everything you communicate outward. This is the Express stage applied at a team and client level.
For technical presentations
- Gather across notes: use tag searches to collect related information from multiple projects and stacks.
- Build the narrative: connect technical details with practical implications — the “why we chose this” story lives in your Design Decision Records.
- Add visuals: reference diagrams and pinouts already captured in your notes rather than recreating them.
Example: presenting a motor control solution assembled from notes
| Slide | What you pull | Source note |
|---|---|---|
| Problem statement | “Customer needs precise speed control” | [P] Motor Control — Client B kickoff notes |
| Technical approach | “TIM2 + PWM output, PID algorithm” | STM32 timer distillation note + PID IP |
| Implementation details | “TIM2 ch1–3 for 3-phase PWM; watch for timer overflow at high speeds” | Datasheet note + .EdgeCase tag |
| Results & gotchas | “±1% accuracy achieved; filter encoder noise; calibrate PID gains” | Post-mortem note from previous motor project |
For team communication
- Code reviews: reference specific datasheet sections or past implementations directly from notes rather than rewriting context from scratch.
- Design discussions: share your distilled notes instead of full manuals — a 5-bullet summary of a 200-page reference manual is more useful in a meeting.
- Client documentation: turn distilled notes into API docs, setup guides, or design rationale documents. The structure is already there.
Keep a “Communication” sub-section in each project notebook where you maintain plain-language summaries for different audiences: one for managers (what it does, what it costs), one for junior devs (how to use it), one for clients (what they asked for and what you built).
Note Templates: Fill-In Structures for Your Evernote
Copy each template into a new note at the start of a project or when you encounter new hardware. The questions are the headings — fill in the answers as you learn them, not all at once.
Template 1 — Datasheet & Reference Manual Summary
Where to file: [R] Vendor: XX initially; move to [P] Project Name when it becomes active.
Tags: .Vendor_XX .ToDistill
| Field | Value |
|---|---|
| Part number | |
| Manufacturer | |
| Document reference (title + rev) | e.g. RM0351 Rev 9 / SBAS700B |
| Relevant section(s) captured | e.g. Sec 8.3 Theory of Operation, Sec 9.2 Application Circuit |
| Link to full datasheet / PDF |
What does this device do in one sentence?
Write it in your own words, not the marketing summary.
What are the critical electrical limits I must not violate?
e.g. VDDIO max 3.6 V; SDA/SCL max clock 400 kHz in Fast-mode; Tamb max 85°C. Bold these in your answer.
What timing constraints affect my firmware?
e.g. AFE4404: 100 µs worst-case wakeup from DPD; I2S BCLK must be stable before CODEC RESET deasserted.
What are the non-obvious gotchas or errata I found?
e.g. I2C SDA held low after Stop mode exit. PLL lock time not mentioned in brief but 300 µs in RM. Tag .EdgeCase if relevant.
Which application circuit or reference schematic applies to my design?
Note figure number and page. Sketch or photograph key parts. Link to the eval board schematic if it exists.
Which driver registers or init sequence matter most for my use case?
e.g. AFE4404 CONTROL0 register bit 3 = DPD enable; must write 0x000000 to TIAGAIN before first sample.
Once you have filled in these fields, go back and bold the 3–5 numbers that your future self will need in 2 seconds. That is Layer 2 done.
Template 2 — Client Requirements Capture
Where to file: [P] Project Name immediately.
Tags: .Req_Hardware .Req_Software .Req_Safety (apply whichever are relevant)
| Field | Value |
|---|---|
| Client / project name | |
| Date of requirements capture | |
| Who provided these requirements? | e.g. John Smith, CTO — verbal in kickoff call + email thread 2024-11-14 |
| Document reference (if formal) | e.g. SRS v0.3, ClientX_PRD_2024.pdf |
| Requirements status | e.g. Draft / Under review / Signed-off |
System Overview
What problem does this device solve for the end user?
Not what it does technically — what job does the user hire it for? e.g. “Allows a nurse to monitor patient SpO2 continuously without disturbing sleep.”
Who are the users and what is their technical level?
e.g. Clinical staff — non-technical. Device must operate correctly with no configuration. Firmware updates handled by IT department only.
Functional Requirements
What must the system measure, control, or communicate?
List each function with its minimum acceptable performance. e.g. Measure HR ±2 BPM; BLE range minimum 5 m in open air; data logged at 25 Hz.
What interfaces must it expose?
e.g. USB-C for charging only (no data). BLE 5.0 for data streaming. No physical buttons — gesture or proximity sensor for wake.
Performance & Power Constraints
What are the battery life and power targets?
State the battery capacity and required operating duration. e.g. 180 mAh LiPo, 72 h continuous. Derive the average current budget and note it here.
What are the real-time constraints?
e.g. HR algorithm requires 25 Hz minimum sample rate. BLE notify latency < 1 s. Alarm must trigger within 500 ms of threshold crossing.
Environmental & Reliability Constraints
What are the operating and storage temperature ranges?
e.g. Operating: 0–50°C. Storage: −20 to 60°C. Note if medical / industrial / automotive standard applies.
What are the ingress protection, drop, or vibration requirements?
e.g. IP54 splash resistant. 1 m drop onto concrete (IEC 60068-2-31). No formal vibration spec but must survive normal handling.
Regulatory & Safety
What regulatory certifications are required?
e.g. CE marking. FCC Part 15 (BLE). IEC 60601-1 (medical electrical). ISO 13485 QMS. Note whether certification is the client’s responsibility or yours.
What are the edge cases or failure modes the client has already considered?
e.g. Device must not alarm falsely > 1×/day. Must survive sensor disconnect without firmware crash. Low battery warning at 15% SoC.
Surprises and Non-Obvious Constraints
What requirements surprised you or seem under-specified?
This is the most important field. Note constraints that are easy to miss: implicit safety assumptions, missing tolerances, conflicting specs. Tag .EdgeCase if needed.
Write a 3-bullet Layer 4 executive summary at the top of this note after your first design review. Something like:
- 72 h battery budget = 2.1 mA average — this is the single tightest constraint.
- 25 Hz minimum sample rate is a hard floor set by the algorithm, not a nice-to-have.
- No physical UI — firmware must handle all error states silently and log them over BLE.
Template 3 — Design Decision Record
Where to file: [P] Project Name. Create one note per major decision.
Tags: .Req_Hardware or .Req_Software (whichever applies) + .IntermediatePacket once the decision is final and reusable.
| Field | Value |
|---|---|
| Decision title | e.g. AFE sampling mode — triggered vs continuous |
| Project | |
| Date decided | |
| Decision made by | |
| Status | e.g. Proposed / Under review / Final / Superseded |
What decision needed to be made?
State it as a question. e.g. Should the AFE4404 run in continuous-sample mode or LPTIM-triggered DPD mode?
What were the options considered?
List each option briefly. e.g. (A) Continuous mode — constant 12.5 mA LED avg. (B) Triggered DPD mode — LED off between pulses, MCU in Stop 2.
What constraints or requirements drove the decision?
Reference your requirements note. e.g. 2.1 mA average system budget makes option A immediately non-viable. 25 Hz minimum PRF is satisfied by LPTIM at 25 Hz trigger.
What was decided, and why?
State the chosen option and the explicit reasoning. Bold the key technical justification.
What are the implementation consequences?
e.g. Must add I2C bus recovery (9-clock pulse) after every Stop 2 exit. LPTIM must be initialised before Stop 2 entry. AFE CONTROL0 bit 3 must be set in init sequence.
What was explicitly rejected and why?
Documenting rejected options prevents the same debate recurring. e.g. Continuous mode rejected: 12.5 mA LED draw alone exceeds total 2.1 mA budget by 6×.
What could invalidate this decision later?
e.g. If client increases BLE advertising rate to 100 ms, wakeup frequency may make Stop 2 overhead negligible — revisit triggered vs continuous tradeoff.
Which notes does this decision draw on?
Link or reference the source notes: datasheet note, forum edge-case note, requirements note. This is the connective tissue that makes retrieval produce insight.
A filled Design Decision Record is not just documentation — it is the Express stage of the CODE cycle. It turns the raw material in your four captured notes into an engineering judgement you can defend, share with teammates, and reuse on the next project that involves the same tradeoff.
Common Questions
“But I might need that datasheet someday!”
Archive it. [X] Archive is fully searchable but does not clutter your active workspace. Nothing is lost, just out of the way.
“This seems like extra work on top of real engineering.”
It takes less time than constantly searching through disorganised notes at 2am the night before a client review.
“What if I organise something in the wrong folder?”
Notes are digital — reorganise any time. The only wrong choice is no organisation at all.
“My brain doesn’t work in folders.”
Use tags and search instead of hierarchy. The PARA structure is a starting point, not a cage. The tag system in this post works just as well in a flat note structure as in a folder hierarchy.
“I don’t have time to distill every note.”
You don’t. Only distill notes you return to more than once. Layer 2 bolding takes 2 minutes and that is the only layer most notes ever need.
Look, it is not about having perfect notes. It is about having notes you can actually find and use under pressure. Everything else is just noise.
