CIV-SV-01 — RF and Mesh Technical Design, draft 0.1

For review. This section is written to be validated by an RF or mesh-protocol engineer. It separates three kinds of statement: assumptions (what the design currently takes as given), claims (numbers derived from datasheets, formulas or measurement), and questions (what the reviewer is asked to judge). Every number carries its source. Nothing has been measured on hardware yet.

Scope. The always-on radio domain of the device: the LoRa mesh, its traffic model and power, the other radios it has to coexist with, and the positioning-by-signal-strength tier. The mesh's application-layer behaviour (channels, beacon, ledger) is defined in the Civilization Recovery Protocol draft 0.1; this document is about whether that behaviour is physically and legally sound on the radio it specifies.

1. System context

Domain A is an ESP32-S3 with an SX1262 LoRa transceiver, a UHF voice module, a broadcast receiver, GNSS and BLE, on a 3.3 V rail from 2 × 26650 LiFePO4 (~21 Wh). Target average draw ≤ 60 mW with the mesh listening (assumption; the whole daily energy plan rests on it).
Everything private rides the LoRa mesh (encrypted). The UHF module is plain voice. The device must interoperate with Meshtastic nodes people already own (assumption, and a hard requirement from the Protocol).
The beacon of a lost device must run for ~~3 days on a 10 % reserve (~~2 Wh).

2. Radios on the device

Radio	Part class	Band	TX	Antenna	Role
LoRa mesh	Semtech SX1262	915 MHz US / 868 EU / 433 by SKU	+22 dBm max (module)	stub, top-left corner, SMA	all Protocol traffic
UHF voice	SA818/SA868-class	400–480 MHz (FRS/GMRS/70 cm)	1–2 W (+30/+33 dBm) FM	whip, top-right corner, SMA	live push-to-talk, plain voice
Broadcast RX	Si4732-A10	LW/MW/SW 150 kHz–30 MHz; FM 64–108 MHz	receive only	ferrite rod (MW/LW); wire on a receive-only SMA (FM/SW)	news, time signals (WWV/CHU)
GNSS	u-blox MAX-M10S class	L1 1575 MHz (multi-GNSS)	receive only	patch, top bezel	position while satellites last
BLE	ESP32-S3	2.4 GHz	+9 dBm class	chip antenna	pairing/provisioning only

Antennas on a 100 × 170 mm handheld: the LoRa and UHF ports are ~70 mm apart on the top edge. Assumption: separation alone does not protect the SX1262 front end from the UHF transmitter; the design relies on a SAW filter on the LoRa receive path and a firmware interlock (§8).

3. Mesh layer — what is fixed by compatibility

The Protocol requires Meshtastic-compatible modulation so off-the-shelf nodes relay its packets. That fixes the following (claims, from Meshtastic's published parameters; reviewer to confirm against the firmware version chosen):

One modem preset per mesh. All channels on a node share the same SF/BW/CR; the Protocol's four channel tiers are crypto/routing tiers, not physical ones. Choosing a preset is choosing range versus airtime for every feature at once.
Packet: 16-byte header (destination, sender, packet id, flags, channel hash, next-hop, relay) + payload ≤ 233 bytes (assumption on the exact maximum; the Protocol budgets 230).
Routing: managed flooding, default hop limit 3; nodes rebroadcast packets they cannot decrypt, which is what lets community nodes carry family traffic.
Preamble: 16 symbols. CRC on. Explicit header.
Channel utilisation: Meshtastic firmware throttles a node above ~25 % airtime utilisation and refuses at higher levels; practical meshes degrade well before that as node count grows (claim; the reviewer's field experience is worth more than the number).

Presets under consideration (SF / BW / CR): LongFast 11 / 250 kHz / 4:5 (Meshtastic's default), MediumFast 9 / 250 / 4:5, ShortFast 7 / 250 / 4:5, LongSlow 12 / 125 / 4:8.

4. Airtime and traffic model

Airtime computed from the LoRa formula (Appendix A) with a 16-byte header, 16-symbol preamble, CRC on, low-data-rate optimisation applied where symbol time exceeds 16 ms.

Preset	text 40 B	beacon ~90 B	ledger summary ~48 B	ledger record / voice fragment 230 B
LongFast SF11/250k	0.68 s	1.05 s	0.72 s	2.07 s
MediumFast SF9/250k	0.19 s	0.30 s	0.21 s	0.62 s
ShortFast SF7/250k	0.06 s	0.09 s	0.06 s	0.20 s
LongSlow SF12/125k CR4:8	4.07 s	6.69 s	4.33 s	14.03 s

Traffic per node per day (claims derived from the Protocol's schedules, LongFast):

Traffic	Schedule	Airtime/day
Beacon, day 1 of a lost device	30 s (h1) → 2 min (h2–6) → 5 min	8.5 min; first-hour duty 3.5 %
Ledger summary	every 10 min while awake (assume 16 h)	1.2 min
Ledger want/have burst	12 records	25 s per burst
Voice note, 15 s at Codec2 1200 bps	2.25 kB → 10 fragments	21 s per note (6 s on MediumFast)
Text	20 messages	14 s
Anchor/position	hourly	~0.5 min

Findings the reviewer should confirm or overturn:

The beacon schedule is legal under the EU 10 % sub-band that Meshtastic uses (869.4–869.65 MHz) and under US Part 15; it exceeds a 1 % sub-band. The Protocol must declare the schedule region-dependent, or slow the first hour to ≥ 2 min in 1 % regions.
Voice notes are the feature that decides the preset. On LongFast a note costs 21 s of airtime and a community of a dozen users sending a few notes each will saturate a channel; on MediumFast the cost is a third, the range roughly half.
The ledger burst (25 s on LongFast) needs a smaller reply budget or a lower preset for the community channel. Since presets are mesh-wide, the honest options are: fewer records per want/have exchange, or moving bulk reconciliation to the pairing cable entirely.

5. Regulatory — what is asserted, what is asked

Assumptions (not legal advice):

US: 902–928 MHz under Part 15.247. Encryption permitted. TX up to +30 dBm with antenna-gain limits.
EU: 863–870 MHz under ETSI EN 300 220. Meshtastic's EU_868 preset centres on 869.525 MHz — the g3 sub-band, 10 % duty cycle, +27 dBm ERP. The 868.0–868.6 sub-band (g1) is 1 %, +14 dBm.
Encryption is prohibited on amateur allocations (Part 97) and not permitted on FRS/GMRS (Part 95); the UHF module is plain voice.

Regulatory question 1 (the one we cannot settle ourselves): Part 15.247's digital-modulation provision requires a 6 dB bandwidth of at least 500 kHz for non-hopping operation; LoRa at 250 kHz does not meet it on its face, and LoRa devices that are FCC-certified use either 500 kHz bandwidth, frequency hopping, or operate at 15.249 power levels. Meshtastic nodes operate at 250 kHz in the US regardless. For a product, which of these the design relies on decides the preset and the certification path. This is a certification question before it is a design one.

Regulatory question 2: the UHF module transmits on FRS/GMRS/70 cm frequencies. As a homebuilt transmitter it is not FRS type-accepted; pre-collapse legal use is under a GMRS or amateur licence. Confirm that the module's spurious emissions are within Part 95/97 limits with the chosen whip, because the SAW filter protects our receiver, not the neighbours.

6. Link budget and range

Claims (SX1262 datasheet-class figures; reviewer to sanity-check):

Item	Value
TX power	+22 dBm (module max; +30 with an external PA, not planned)
LoRa stub antenna gain	−2 dBi (short helical)
Body/hand loss, handheld at chest height	−3 to −6 dB
RX sensitivity, SF11/250k	≈ −131 dBm
RX sensitivity, SF9/250k	≈ −126 dBm
RX sensitivity, SF7/250k	≈ −121 dBm
Fade margin	10 dB

Link budget at LongFast, both ends handheld: 22 − 2 − 2 (two antennas) − 6 (bodies) + 131 − 10 ≈ 133 dB usable path loss.

Free-space loss at 915 MHz: 20·log10(d) + 31.6 dB (d in m) → 133 dB at ~118 km, which is not a real number; terrain is. With a log-distance exponent n = 2.7 (suburban, near ground) the same budget gives roughly 2–4 km; n = 3.5 (dense urban, handheld to handheld) roughly 500 m–1 km; two elevated nodes in line of sight, 10–20 km. Those brackets match Meshtastic field reports and are what the spec promises. MediumFast costs ~5 dB, roughly 30–40 % of the range at n = 3.

Question 3: is a −2 dBi stub the right call, or should the kit's spare "whip" be the LoRa antenna and the stub the spare? The device carries a UHF whip already; two whips on a 100 mm top edge is the cost.

7. Power

Claims (SX1262 datasheet-class): receive 4.6–5.3 mA in DC-DC mode without boosted RX gain, ~1 mA more with boost; transmit +22 dBm ≈ 118 mA; sleep ~1 µA with retention. ESP32-S3 light sleep ~0.25 mA plus PSRAM retention; the RTC and the rest of the board a few hundred µA.

Budget, continuous-receive design:

Load	Power	Per day
SX1262 continuous RX	17.5 mW	0.42 Wh
ESP32-S3 light sleep, wake on DIO1 per packet	~2–4 mW	0.07 Wh
RTC, thermistors, LED, regulator quiescent	~3–6 mW	0.1 Wh
Mesh transmit (own traffic, a typical day)	—	0.01–0.03 Wh
Total	~25–30 mW	~0.6–0.7 Wh

That fits the 60 mW target with margin, but only if the MCU sleeps between packets and the radio receives autonomously. Meshtastic on ESP32 hardware today keeps the MCU awake and idles at several hundred milliwatts; the firmware fork has to change that, and it is the single largest power risk in Domain A.

Beacon reserve check: the lost-device schedule costs ~~55 mWh of transmit on day 1 plus continuous receive during listen windows only (~~2 s after each frame). At ~25 mW average the 2 Wh reserve lasts ~3.3 days — consistent with the spec's "about three days," and dependent on the same sleep discipline.

Question 4 — the important one: the reviewer's own mesh work uses duty-cycled receive with long preambles (or channel-activity-detection wake) to cut receive power by an order of magnitude. That is incompatible with Meshtastic's 16-symbol preamble and always-on receivers: a duty-cycled Protocol node would miss packets from stock nodes. Is there a hybrid the reviewer would endorse — e.g. always-on receive while the device has sun and a full battery, duty-cycled with a longer preamble among Protocol nodes only when the reserve is low — and is the compatibility worth the 0.4 Wh/day it costs?

8. Coexistence on one handheld

UHF transmit vs LoRa receive. +33 dBm at ~70 mm separation; coupling of −20 to −30 dB between two whips that close puts +3 to +13 dBm at the SX1262 input — above its absolute maximum. Design: a SAW filter on the LoRa receive path (915 MHz, ~2 dB insertion loss), and a firmware interlock — SX1262 to standby before the UHF module is keyed, receive restored 50 ms after PTT release; never two transmitters keyed at once. Question 5: is a SAW filter enough, or should there be a PIN/T-R switch that shorts the LoRa input during PTT?
UHF transmit vs GNSS. The third harmonic of 462 MHz is 1386 MHz, away from L1; broadband noise and desense during PTT are expected and acceptable (GNSS is off unless in Beacon/Locate).
UHF transmit vs broadcast receiver on a 10 m wire. A long wire on the BCST jack a few centimetres from the whip: a limiter (back-to-back diodes) protects the Si4732 input; audio is muted during PTT. Question 6: limiter alone, or an RF switch?
Aluminium frame. The internal frame is the antenna ground reference for all three SMA ports and must be electrically bonded to the RF grounds deliberately; the ferrite rod for MW must sit clear of it (top bezel). Question 7: will a ferrite rod work at all inside a metal-framed, solar-glass-backed handheld, or should MW go on the wire too?

9. Positioning by signal strength (Locate tier 2)

Model: log-distance path loss, RSSI = P_tx − PL(d0) − 10·n·log10(d/d0) + X, with X ~ N(0, σ) shadowing. Handheld near ground: n ≈ 2.7–3.5, σ ≈ 6–8 dB.

Claim: with σ = 6 dB and n = 3, a single RSSI reading places distance within roughly a factor of 1.6 either way (one sigma). Trilateration from three anchors with independent shadowing narrows that to on the order of 100 m at a few hundred metres range in open ground — and to nothing useful in buildings or foliage. The spec says "roughly 100 m in open ground"; the reviewer should say whether that is optimistic.

Question 8: would per-anchor calibration (each anchor records a short RSSI-vs-distance table when surveyed) or time-averaging across the beacon's repeated frames buy enough to make the tier worth its UI, or should tier 2 be dropped and the sweep tier trusted?

10. Questions for the reviewer, collected

Preset: LongFast (range) or MediumFast (airtime)? Voice notes and ledger bursts push toward MediumFast; the range promise pushes toward LongFast. Is a per-community preset choice, set at provisioning, a reasonable answer?
Beacon schedule under a 1 % sub-band — slow the first hour, or shorten the frame (drop status text, quantise position)?
Ledger sync: is a 12-record burst ever acceptable over the air, or should the air carry summaries only and the cable carry records?
Always-on receive vs duty-cycled receive: is there a hybrid you would endorse (§7)?
SAW filter vs T/R switch for the UHF–LoRa problem (§8).
Limiter vs switch for the wire antenna (§8).
Ferrite-rod MW reception inside this enclosure (§8).
RSSI positioning: worth keeping (§9)?
Part 15.247 bandwidth for a 250 kHz LoRa product (§5).
Anything in the Protocol's frame budgets (Protocol §3, §8.2) that won't survive contact with real packet overhead.

Appendices (build prompt, image prompts) are not included in the published copy.