HelmKit Architecture

HelmKit Architecture

Audience

Difficulty	Intermediate

HelmKit Architecture specifies the hardware and firmware design of the HelmKit — a head-worn near-field psionic device. The architecture is built around a dual-MCU checker-doer pattern inherited from aerospace and industrial functional-safety standards (DO-178C DAL-A, IEC 61508 SIL-3), adapted for a consumer-grade wearable.

The central design constraint: no single software fault may cause an overexposure event. This is achieved by hardware-enforced safety oversight running on an independent MCU.

Block diagram

 ┌──────────────────────────────────────────────────┐
 │                       Battery + PMIC             │
 └──────────────────────────────────────────────────┘
      │                          │
      ▼                          ▼
 ┌──────────────┐         ┌──────────────┐
 │   MCU-A      │         │   MCU-B      │
 │  ("doer")    │         │  ("checker") │
 │              │         │              │
 │  RF gen      │         │  Sensors     │
 │  Modulation  │         │  Blacklist   │
 │  UI / BLE    │         │  Auth/cutoff │
 └──────────────┘         └──────────────┘
      │                          │
      │ RF drive                 │ Opto-isolated relay (cuts RF)
      ▼                          ▼
 ┌──────────────────────────────────────────────────┐
 │                Power Amplifier                   │
 └──────────────────────────────────────────────────┘
      │
      ▼
 ┌──────────────────────────────────────────────────┐
 │  Matching network + Caduceus_Coil / Bifilar_Coil  │
 └──────────────────────────────────────────────────┘

MCU-A ("doer")

The doer MCU is responsible for primary device functionality:

• RF signal generation — synthesises the drive waveform (CW or modulated).
• Modulation control — frequency, amplitude, phase, pulse-shape.
• User interface — buttons, display, BLE / WiFi link for telemetry.
• Mode selection — selects between operating presets stored in firmware.
• Logging — records session parameters and sensor readings.

Hardware: typical mid-range ARM Cortex-M (M4 / M7) or ESP32-class part. Standard development environment, standard firmware update mechanism.

MCU-B ("checker")

The checker MCU runs independent of MCU-A:

• Independent power supply (separate LDO from battery).
• Independent clock (separate crystal oscillator).
• Independent firmware (developed and audited separately).
• Read-only authority over RF cutoff (opto-isolated relay).

Responsibilities:

• RF power monitoring — calibrated directional coupler reads forward/reflected power.
• Coil temperature monitoring — thermistor or PT100 on coil former.
• Body-proximity sensing — capacitive sensor confirms device-on-head condition.
• Ambient field monitoring — independent E-probes verify the field amplitude vs. MCU-A's target.
• Blacklist enforcement — hardware-fuse-stored frequency/modulation prohibitions (see below).
• Watchdog — MCU-A must heartbeat MCU-B every N ms or RF is cut.

Hardware: a smaller, dedicated MCU (e.g. ARM Cortex-M0, MSP430). Simple deterministic firmware, formally audited (target: < 5 kLOC).

Safety blacklist

MCU-B holds a hardware-fuse-stored blacklist of forbidden frequency/modulation combinations. If MCU-A requests a configuration that violates the blacklist, MCU-B refuses to enable the RF power stage. The blacklist is set at factory time and is not modifiable in the field.

See Psionic_Device_Safety for the full blacklist contents. Highlights:

• Cardiac stimulation risk — DC pulses with rise time < 1 ms applied near thorax; 10-100 Hz pulse trains > 1 mA into chest area.
• Brain stimulation / seizure risk — 3-8 Hz photic-frequency RF at > 100 V/m head-field; strong 1 Hz pulse trains; modulation envelopes matching cardiac or respiratory rates at > 5% depth.
• Frey effect — pulsed RF 200-3000 MHz with peak power density > 40 mW/cm² and pulse widths < 1 ms.
• ICNIRP violations — continuous-wave near-field > 50 V/m rms at the wearer's head; peak pulsed E-field > 300 V/m.

Fail-safe state

On any MCU-B alert:

1. RF power is cut immediately via the opto-isolated relay.
2. The system enters a non-resetable lockout state.
3. Lockout requires physical key release (a manual reset switch inside the device).
4. The event is logged in tamper-evident memory.
5. User notification via display and BLE.

This eliminates the possibility of a single-software-fault causing overexposure.

RF chain

1. Crystal oscillator — provides stable RF reference (e.g. 2.45 GHz).
2. VCO + PLL (optional) — for tuneable operation.
3. Modulator — applies AM / FM / pulse modulation as commanded by MCU-A.
4. Power amplifier — Class-E for efficiency; output ≲ 1 W.
5. Directional coupler — taps a small fraction for MCU-B monitoring.
6. Matching network — impedance transform to the Caduceus_Coil / Bifilar_Coil / Double-Helix_Antenna.
7. Coil — the primary near-field emitter.

Body-aware operation

Because tissue loading detunes the coil's impedance (5-20% downward), the matching network is dynamic:

• Body-proximity sensor detects device-on-head.
• Reflectometer (the same directional coupler used for safety) measures the antenna VSWR.
• Tuneable matching network adjusts capacitor/inductor values to restore match.
• MCU-A adapts the drive frequency or matching state to keep the operating point in the desired regime.

If the body is removed mid-session, the coil's impedance jumps and the matching is lost. MCU-A detects this via reflectometry; MCU-B independently confirms via the proximity sensor.

Reference architectures

The dual-MCU pattern is inherited from:

• DO-178C — "Software Considerations in Airborne Systems and Equipment Certification" — Design Assurance Level A (DAL-A) requires independent verification of safety-critical functions.
• IEC 61508 — "Functional Safety of Electrical/Electronic/Programmable Electronic Safety-related Systems" — Safety Integrity Level 3 (SIL-3) is the target for medical-device-grade safety.
• ISO 26262 — automotive functional safety (ASIL-D) — similar dual-channel pattern.

HelmKit does not target medical-device certification (which would require clinical trials beyond the framework's current scope). But the architectural pattern is the same: safety is enforced by an independent channel, not by trust in the primary firmware.

Firmware development discipline

For MCU-B specifically:

• Formal verification of the safety logic (using e.g. Frama-C, SPARK, TLA+).
• Code review by an independent reviewer not on the MCU-A team.
• No dynamic memory allocation; static buffers only.
• No external code dependencies beyond the MCU vendor's HAL.
• Tamper-evident builds (signed firmware, hardware-fused public key).
• No remote update path — MCU-B firmware updates require physical access.

See Also

• HelmKit
• Psionic_Device_Overview
• Psionic_Device_Safety
• SAR_Calculation_for_Psionic_Devices
• Microwave_Auditory_Effect
• Near_Field_Electromagnetics
• Caduceus_Coil
• Bifilar_Coil

References

• RTCA DO-178C (2011). "Software Considerations in Airborne Systems and Equipment Certification."
• IEC 61508 (2010). "Functional Safety of Electrical/Electronic/Programmable Electronic Safety-related Systems."
• ICNIRP (2020). "Guidelines for limiting exposure to electromagnetic fields (100 kHz to 300 GHz)." Health Physics 118: 483–524.
• IEEE C95.1-2019 — IEEE Standard for Safety Levels.