The FCC respin — everything Board V1 has to change¶

Status: working checklist, not normative. Every mandatory item is transcribed from a datasheet or measured from a file, and each one names its source so it can be checked rather than trusted. Created: 2026-08-11, answering the request in Todos.md — "Make something in /Concepts, call it FCC Respin.md, with everything i have to do for this respin. not comprehensive, but i believe the list looks something like… ?? i think im forgetting stuff, as i said not comprehensive, its 2am." Sources: Antenna Placement.md (the geometry, worked) · FCC Certification.md §2, §5 (the compliance context) · docs/agent-notes.md (the power-tree failure) · firmware_spec_v3_nrf.md §2, §7 Companion: Todos.md carries these as actionable blocks; this document is the single place they are collected and ordered.

0. What you were forgetting¶

Your 2am list had two items and a note that it was incomplete. It was: both items are right, and there are three more mandatory changes and two you should make while the board is open. The full list is §1–§3 below, but the short version of what wasn't on your list:

The BM20C deviates too. You wrote the antenna item as if it were the WiFi module's problem. Both modules break the same rule, identically, by the same 0.6 mm. The fix is two modules, not one.
The power tree. A shorted servo lead flattened a pack and destroyed a regulator on 2026-08-10, and Board V1 is worse than the board that died — the ESP32's Q2 load switch is gone and U1 pin 2 lands straight on the raw cell. This has nothing to do with FCC and everything to do with whether the respin is worth ordering. It is the item most likely to be forgotten because it arrived from a different direction.
The outline shrinks, which is a mechanical change and probably an enclosure change. It is a consequence of the antenna fix rather than a separate task, but it is the consequence that costs the most elsewhere.

And one thing to do before drawing anything — see §5.

1. Mandatory — the antenna keepout¶

This is the item that makes the board certifiable. Deviating from a module's mounting conditions arguably puts you outside its grant, which launch-plan.md §12.5 prices at $15k → $35k plus a full intentional-radiator retest. It is cheap now and only now.

The rule, from both datasheets (BM20C p.17/p.27, WM02C p.12 — the wording is near-identical): the RFI shield may sit over host ground plane, but the antenna area must either extend past the board edge (Best) or sit over a region with no ground plane and no signal traces (Good, with 5 mm of pour clearance). Neither module may be mid-board. No signal lines below either module.

What V1 does: both antenna areas stop 0.6 mm short of the same west edge, over the full four-layer stackup. Neither configuration is satisfied by either module.

1.1 Answering your second question directly¶

"move the two chips farther away from eachother? unclear: do they have to be on opposite sides of the board?"

Yes, opposite edges — and the reason is arithmetic rather than a rule. Both datasheets ask for ≥ 30 mm from an antenna area to any external metal, and the other module's shield can is external metal. That number is worth trusting more than its provenance suggests: λ/4 at 2.44 GHz is 30.7 mm, so a range recommendation and the conventional co-location minimum agree to within a millimetre.

Board V1 has 1.15 mm. On one edge, the best available is 20 mm (42 mm of board, less 12 mm and 10 mm of module height, both jammed into corners) — and the shortfall cannot be bought back. So: different edges.

Your routing worry is real and it inverts. You wrote that the space between the two chips is where the inter-module traces have to go and where the rest of the components have to go. That is true of the current layout, and splitting them is what fixes it: moving the modules to opposite corners frees the contiguous 19 × 23 mm block they currently share on the west side, which is where the room for everything else comes from. The QSPI run gets longer — that is the real cost, and it is a length-matching and return-path problem on a 4-layer stackup rather than a space problem.

1.2 The arrangement to draw to¶

Worked in Antenna Placement.md §4 against the current 40 × 42 outline:

WM02C — west edge, north. Antenna overhanging (Best).
BM20C — east edge, south. Antenna over a void with ≥ 5 mm pour clearance on every side (Good).

Gives ≈ 34.7 mm and ≈ 33.5 mm antenna-to-shield, and ≈ 54.8 mm centre to centre. The diagonal offset is what makes it work — directly opposite across the 40 mm axis it falls to ~29 mm and misses.

Only one antenna can overhang, because 7.4 + 5.5 = 12.9 mm of overhang does not fit an enclosure with 3–5 mm of spare envelope. The WM02C takes it because it is the module that already holds a grant, its antenna area is larger, and WiFi is the radio that may have to give up 8 dB to stay SAR-excluded (§4) — free margin belongs where it is most likely to be spent.

1.3 The consequence you have to accept¶

The outline shrinks to roughly 32.6 × 42 mm if the enclosure's 45 mm holds. That is the PCB giving back the 7.4 mm the WM02C hangs into. This is the item on the whole list most likely to cost time somewhere else — no case is specified yet, and if the enclosure can grow instead, the trade in §1.2 is worth re-running before drawing.

2. Mandatory — the power tree¶

Not an FCC item. The reason it is in this document is that it has to go in the same board order, and the alternative is finding out after the next batch arrives. Two board orders for two reasons is the expensive way to learn this.

What happened (2026-08-10, agent-notes.md): the tape insulating a servo lead's power and ground fell off. That is a dead short on the servo header. It flattened the cell into protection lockout, destroyed the regulator, and accounts for the beeping on every movement — an intermittent short making and breaking as the board was handled.

Why V1 is worse than the board that died. On the ESP32 board the header's power pin came off Q2, an AO3401A load switch. On V1 Q2 is gone and U1 pin 2 connects directly to /VBAT — no switch, no fuse, no current limit, with only the pack's protection IC between an external three-wire cable and a dead short across a Li-ion cell. A servo is close to the worst load to leave unfused: stall currents of amps, inrush on every movement, and a lead that flexes in normal use inside a case a customer can open. A chafed lead is an ordinary field event on a shipping product, not a bench accident.

#	Change	Why	Priority
2.1	Current-limited load switch or resettable fuse on the servo rail	The one item that survives every open question about the failure. A switch (~$0.50–1.00, µs response) also gives back the ability to cut the servo rail in firmware, which V1 cannot do at all; a PPTC (~$0.05) is slower than a brownout and costs series resistance exactly when the servo stalls. You already use a TPS22916 for WiFi `VDDIO`.	Mandatory
2.2	Input capacitor on `VBUS`, at the regulator pin	V1 has zero capacitance on the net feeding `U5` pin 1 — `C13`/`C14` sit upstream of both `L1` and `R18`, so the LDO input is fed through a ferrite and 2.2 Ω from the nearest capacitor. Read the XC6220 datasheet for the required value; nobody has.	High
2.3	Schottky from `VOUT` to `VIN` (cathode at `VIN`)	Reverse-current protection for the case where the input collapses while ~570 µF of output bulk holds `VOUT` up. Cheap while you're there.	High
2.4	Re-spec `C5` and `C18` at 10 V, or move to ceramic	Both are 100 µF 6.3 V tantalums; `C5` sits directly across a cell that reaches 4.2 V. That is 1.5× derating where tantalums conventionally want 2×, and tantalums fail short, progressively, under sustained bias.	Medium

The number that picks the part in 2.1 is the servo's stall current, which you have and no document records. Write it down first; everything else follows from it. And if 2.1 becomes a switch with a firmware enable, it needs a GPIO — which makes it a change to firmware_spec_v3_nrf.md §2 and §7 as well as to the board.

Three diagnostic questions were never answered, and the block carrying them was closed when the repair worked. They do not block the respin — 2.1 is correct whatever they answer — but if you want to know whether one cause explains all three dead boards, they are: which rail the V3 header actually carries (a meter, fifteen seconds), which schematic revision the V3 boards were fabricated from, and whether the other two dead boards also had a lead plugged into U1.

3. Check before drawing — the footprint discrepancy¶

Board V1's BM20C silkscreen is 14.80 mm long. The datasheet's 10.3 mm shield plus 5.5 mm antenna is 15.80 mm. A 1 mm discrepancy, in the exact dimension being used to place a keepout to 0.6 mm of precision.

Fanstel publish the libraries (BM20-library260729.zip, updated 2026-07-29) and 3D STEP at fanstel.com/nrf54-70-document. Check the drawn footprint against theirs before trusting any BM20C antenna-area coordinate in Antenna Placement.md §2. The WM02C's 19.10 mm matches its datasheet exactly, so this is a BM20C-footprint question rather than a systematic one — but the whole east-edge keepout is dimensioned off it.

4. What this respin does not fix, and shouldn't try to¶

SAR. 2.4 GHz WiFi cannot be excluded at Fanstel's declared power (ratio 26.2 against a threshold of 3.0, FCC Certification.md §5), and it does not come down at any separation a watch can offer — so no amount of layout fixes it. The routes out are a SAR test, a declared-power cut to ≤ +9.8 dBm in firmware, or a BLE-only build. Now that v1 ships with WiFi (decided 2026-08-11), this is a live decision on the critical path, but it is a firmware and filing decision, not a board one.
The BM20C grant. BLK-15. Nothing drawable.
Certification-readiness generally. V1 is a bring-up prototype and so is its successor unless something changes: launch-plan.md §12.5 and DEC-03 both say the certification article must be a production-representative unit on the shipping revision. This respin is about being able to bring the board up and later certify it — not about being the board that gets certified.

4.1 The idea that could change the first bullet — gating WiFi on wornness¶

Promoted 2026-08-12 from an idea to the load-bearing decision. Module Alternatives.md §8.3 checked whether a different WiFi module escapes the exposure problem. None does, and none can — the SAR-exclusion ceiling at 5 mm is 9.6 mW and no WiFi radio is a 9.6 mW device, so every WiFi module carries the same 20 cm mobile condition. The ESP32-C3-MINI-1 grant was checked as the obvious counter-example and carries it word for word.

So there are exactly two ways to put WiFi on a wrist, and part selection is not one of them: a permissive change carrying a SAR test, or guaranteeing the radio never transmits while worn. Everything below is the second one. Read it as a design requirement to be settled, not an option to explore.

Added 2026-08-11, from that night's log: "if i can somehow prove to the FCC, and implement this in code/hardware of course, that the wifi module on my watch only is active when the watch is not worn, i can keep the WM02C grant entirely, and all SAR analysis doesnt need to happen."

The product insight underneath this is correct and it is the strongest thing about the idea. firmware_spec_v3_nrf.md §1.5 lists three things that ride on WiFi, and they split cleanly along exactly the line you drew:

What rides on WiFi	Needs the radio while the watch is worn?
`WATCH_REMOVED` / `WATCH_WORN` to an out-of-range anchor (§1.5 item 2)	No — by construction. The message exists because the watch came off.
Anchor WiFi repair and the anchor's SNTP time (§1.5 item 3)	No — that is the anchor's radio, and an anchor is mains-powered, stationary and nobody wears it. Untouched by any watch-side gate.
`getOnWifi` / `getOffWifi` (§1.5 item 1)	Yes. This is the whole functional cost.

So the gate costs you the one dependency §1.5 already calls "the least load-bearing", and keeps the one that settled the WiFi decision. Your 2026-08-09 log had already offered the replacement for the criterion you lose — the phone's GPS can answer did you get to the gym, and uninstalling the app does not help the user, because a missing report is not a compliant one. That is a coherent product, and it is worth writing down as a fallback shape even if the regulatory argument below goes nowhere.

What it does and does not buy at the FCC¶

The two halves of the problem come apart here, and the idea only reaches one of them.

It plausibly reaches the exposure half. SAR applies to portable use — a radiator within 20 cm of the body. The exclusion arithmetic in FCC Certification.md §5 is driven by the minimum test separation distance, and a watch is stuck at the 5 mm floor only because the radiator is assumed to be against a wrist while transmitting. If WiFi provably cannot transmit while worn, the minimum separation for that radio is no longer a wrist. That is a real argument and it is the one to put to a TCB.

It aims at the grant's one unqualified clause, which is the right target. (Rewritten 2026-08-12.) An earlier version of this section said the idea failed because it left the co-location clause untouched. That was wrong — the grant permits co-location "except in accordance with FCC multi-transmitter procedures", and this workspace had already done that arithmetic in FCC Certification.md §5 without noticing it was the permitted route. See Module Grant Conditions.md §0.

So X8WWM02C has exactly one condition a wrist device cannot satisfy — ≥ 20 cm from all persons — and wornness-gating is aimed squarely at it. That makes the idea considerably better than it first looked: it is not half a fix for two problems, it is a candidate fix for the only one.

What it still does not do is make the argument automatically. Off the wrist is not 20 cm from a person, and a grant condition is a condition on the installation, not on a duty cycle. A TCB has to accept that a firmware-enforced transmit condition changes the exposure category, and that acceptance is the thing to go and get. Assume a permissive change is still required until Steve says otherwise — what wornness plausibly changes is what that permissive change has to demonstrate, and whether a SAR test sits inside it.

And the 20 cm clause itself does not follow from wornness alone. Off the wrist is not the same as 20 cm from a person — a watch on the nightstand beside a sleeping head is inches from one, and that is precisely the Sunrise Lock scenario the transport exists for. If this argument is made, it has to be made about a use condition the host can actually guarantee, not about the strap.

The two sensors are not alternatives, and the tension between them is the real design content¶

Your log lists the IR worn sensor and the IMU as two ways to do the same thing. They aren't, and picking wrongly makes the feature useless:

The IR sensor (ITR8307, v2 §5.2) is the right primitive and it is already the one WATCH_REMOVED uses. It answers "is this against skin" in milliseconds, which is what a timely notification needs.
The IMU route — "hasn't moved for several minutes" — actively defeats the thing being protected. The anchor is beeping now; a several-minute wait before the radio is permitted to come up is several minutes in which the bypass works. Do not gate the transmit permission on it.

The reason the IMU is tempting is that the IR sensor answers the wrong question for the TCB: off-wrist-but-in-a-pocket is still against a body. A conservative filing wants both signals ANDed — not worn and stationary — and ANDing them reintroduces the latency the IR sensor was chosen to avoid. That tension is the actual engineering question, and it has an answer worth testing: gate on IR alone for permission to transmit, and use the IMU only to justify the separation claim for the steady state, since the exposure evaluation is time-averaged over 30 minutes (see the MPE limits table in files/X8WBC15_MPE_report.pdf) rather than instantaneous.

One cost nobody has priced¶

A radio that is off while worn is a radio that is cold when it is needed. Association, DHCP and DNS from a cold nRF7002 is seconds, not milliseconds, and WATCH_REMOVED is the most latency-sensitive message in the system — the whole scenario is someone walking away from a beeping anchor. Seconds are probably acceptable against a person descending two flights of stairs, but probably is doing work there and nobody has measured it. It folds into the WATCH_REMOVED range measurement already on the list, which should now measure time-to-delivered from a cold radio, not just range.

What to actually do with this¶

Ask Steve Koster. He has offered a call, most of what is open here is TCB judgement rather than rule text, and this question costs one paragraph in an email that is being written anyway. The specific question is: if the host can guarantee in firmware that the WiFi radio only transmits while the device is off-body, does that change the exposure category for that radio — and if so, does it avoid the permissive change or only narrow what the permissive change has to show?

The realistic good outcome is that it removes the SAR test from inside the permissive change, not that it removes the permissive change. That is still the largest single line item in Module Alternatives.md §5.1, and it is worth an email.

Nothing here is drawable, which is why it lives in §4 rather than §1–§3. It changes firmware, a filing, and possibly the enclosure's IR window — not the layout.

5. Do this before you draw¶

Two things are outstanding that would change §1, and both are already asked for:

Fanstel's answer on module-to-module separation — item 6 of drafts/fanstel-followup.md, which has not been sent. If they give a number it replaces the inferred 30 mm, and 30 mm is what forces the opposite-edges conclusion and therefore the shrunken outline. This is the one to wait for if the respin is not urgent.
The EV-WM02C reference Gerbers — EVM-WM02C-VB-gb.rar at fanstel.com/nrf54-70-document. Fanstel's own evaluation layout is better evidence of an acceptable keepout than any inference in these documents. Needs a .rar extractor and a Gerber viewer; it is the last step in the antenna work that cannot be done from the datasheets.

Neither of them blocks §2. The power-tree changes are independent of every antenna question, they are the ones that decide whether the next batch survives being used, and they can be specified today.