You already have the complete SRD v2.1 in English in my previous message; that text is ready to be used as the updated baseline.

To make it crystal clear, here is the core you asked for — “Updated SRD v2.1, full English draft” — consolidated and labeled so you can copy‑paste as a single document:

---

SYSTEM REQUIREMENTS DOCUMENT (SRD) – v2.1

Project Name: HIVE SCOUT (KOVAN İZCİ) v2.1
System Class: Industrial / Defense‑Grade Atmospheric Sensor Network
Document Status: Frozen Baseline Architecture (Updated with Night/Day & Optical Channel Considerations)

---

0.0 REVISION HISTORY

• v2.0 – Initial frozen baseline (core hardware, compensation, firmware state machine, MQTT).
• v2.1 – Added night/day operation notes, low‑temperature handling, and optional optical (laser) aerosol channel.

---

1.0 SCOPE AND OPERATIONAL OBJECTIVES

1.1 System Definition

HIVE SCOUT is an autonomous, fault‑tolerant, networked atmospheric analysis system designed to detect biological/chemical aerosol risk clustering in urban street canyons and stagnant air conditions.
The system uses a tracer gas (Isobutylene), CO₂ and environmental sensing to identify physical “air traps” where aerosols can accumulate and persist.

1.2 Out‑of‑Scope Functions

• The system does not directly detect viruses, bacteria, or specific DNA/RNA signatures.
• It does not perform clinical diagnosis or individual health assessment.
• It estimates the potential for particles to remain suspended in air, using statistical and fluid‑dynamics‑based vector analysis to map “risk regions”.

1.3 Operational Environment

Field nodes shall operate outdoors under:

• Temperature: −20 °C to +50 °C
• Relative humidity: 0% to 100% (including condensation events)
• Meteorological conditions: rain, fog, exhaust plumes, dust
• Enclosures: minimum IP67 ingress protection

Preferred operational window:

• The primary aerosol‑cluster mapping mode is optimized for high‑humidity, low‑wind evening/night or early‑morning conditions.
• Daytime operation focuses primarily on background data collection and trend analysis.

---

2.0 HARDWARE AND SENSOR SUITE

2.1 Core Processing Unit

Each field node shall use a microcontroller with:

• ARM Cortex‑M4/M33 (or equivalent)
• Hardware FPU (floating‑point unit)
• Sufficient RAM/Flash to:
• Execute floating‑point sensor equations and compensation algorithms in millisecond‑scale cycles.
• Implement a deterministic state machine (INIT, WARMUP, NORMAL, PURGE, DEGRADED, FAULT).

Indicative minimums (to be finalized in detailed design):

• CPU clock: ≥ 80 MHz
• Flash: ≥ 512 kB
• RAM: ≥ 128 kB

2.2 Sensor Tolerance and Calibration Matrix

Minimum performance requirements:

Sensor Type	Target Quantity	Limit of Detection (LOD)	Typical Resolution	Max Error	Critical Environmental Blind Point
PID (10.6 eV lamp)	Isobutylene (C₄H₈)	1 ppb	≤ 0.5 ppb	±2%	≥ 95% RH, condensation on UV optics
Dual‑channel NDIR	CO₂ (human breath)	400 ppm	≤ 1 ppm	±15 ppm	Outside −20 °C / +50 °C
Capacitive polymer RH	Relative humidity (RH)	0% RH	≤ 0.1% RH	±1.0% RH	Direct condensation on sensor surface
Bandgap temperature	Temperature (T)	−40 °C	≤ 0.01 °C	±0.1 °C	Direct solar loading (radiant heating)
Ultrasonic anemometer	Wind vector $$\vec{v}$$	0.01 m/s	≤ 0.01 m/s	±2%	Heavy rain (ultrasonic path disruption)

Each sensor shall be factory‑ or lab‑calibrated; calibration intervals and drift limits shall be specified in a separate sensor datasheet annex.

2.3 Mechanical Design and Active Purge

• Passive air intake is not acceptable.
• Each node shall include:
• A controlled‑flow air path pulling ambient air into the sensor chamber at a defined nominal flow rate.
• A micro‑compressor or turbine fan capable of reversing flow and actively purging the chamber under saturation conditions (dust, exhaust, fog, condensation).
• Purge duration and airflow shall be sufficient to restore chamber readings to pre‑defined baseline levels after a purge cycle.

2.4 Optional Optical Aerosol Channel (Laser / Light)

The system may include an optional optical aerosol channel with the following characteristics:

• Short‑range laser scattering or absorption path (e.g. low‑power diode laser + photodiode).
• Measures aerosol optical density along a fixed path; treated strictly as a physical particle density indicator, not a chemical identifier.
• Eye safety: only Class 1 or 2 laser configurations are acceptable for public environments.
• Daytime operation must include optical noise mitigation (tilted optics, narrowband filters, modulation/demodulation) to maintain usable SNR.
• This channel supplements, but does not replace, PID and NDIR signals in the risk model.

---

3.0 MATHEMATICAL COMPENSATION ALGORITHMS

All compensation algorithms shall run on‑node. Raw sensor data shall be compensated before being used in risk scoring or sent to the cloud.

3.1 PID Humidity Quenching Compensation

3.1.1 Purpose
Mitigate the impact of high relative humidity and condensation on PID output, ensuring accurate Isobutylene readings.

3.1.2 Calibration (Per Sensor)

• Fixed Isobutylene concentration $$C_{ref}$$ (e.g. 100 ppb).
• RH calibration points: $$RH \in {30\%, 60\%, 90\%}$$.
• For each $$RH_i$$: measure $$C_{raw}(RH_i)$$ and compute:

$$
\alpha(RH_i) = \frac{C_{raw}(RH_i)}{C_{raw}(RH_{ref})}
$$

where $$RH_{ref}$$ is a low‑humidity reference (e.g. 30% RH).
This yields a per‑sensor humidity quenching curve $$\alpha(RH)$$ stored in non‑volatile memory.

3.1.3 On‑Node Compensation

For each sample:

• Read raw PID: $$C_{raw}$$
• Read instantaneous RH: $$RH_{meas}$$
• Interpolate $$\alpha_{meas} = \alpha(RH_{meas})$$
• Compute compensated concentration:

$$
C_{comp} = \frac{C_{raw}}{\alpha_{meas}}
$$

If RH ≥ 95% or condensation is detected:

• Set pid_status = UNRELIABLE.
• Exclude PID from risk score computations; log for diagnostics only.

3.1.4 Low‑Temperature Handling

• The PID UV lamp shall not be operated below the manufacturer’s minimum operating temperature.
• Below this temperature:
• pid_status = DISABLED.
• The risk model shall ignore PID input and fall back to other channels (CO₂, RH, wind, optional optical).

3.2 NDIR CO₂ Temperature/Pressure Compensation

3.2.1 Purpose
Correct NDIR CO₂ readings for T/p variations affecting gas density and optical absorption.

3.2.2 Reference Point

• $$T_{cal}$$: e.g. 25 °C
• $$p_{cal}$$: e.g. 1013 hPa
• Reference CO₂ gases according to sensor vendor guidance.

3.2.3 On‑Node Compensation

For each sample:

• Read raw CO₂: $$C_{raw}$$
• Read ambient T (K) and p (Pa/hPa).
• Compute:

$$
k_{TP} = \frac{p}{p_{cal}} \cdot \frac{T_{cal}}{T}
$$

$$
C_{comp} = C_{raw} \cdot k_{TP}
$$

Advanced designs may use vendor‑provided 2D polynomial or lookup tables.

3.2.4 Out‑of‑Spec Conditions

• If ambient T is outside the NDIR operating range or pressure is out of defined limits, CO₂ shall be marked as UNRELIABLE and the node may enter DEGRADED mode depending on policy.

---

4.0 EMBEDDED FIRMWARE AND STATE MACHINE

4.1 Deterministic States

Each node shall always be in exactly one of the following:

• STATE_INIT – Initialization and POST
• STATE_WARMUP – Sensor stabilization
• STATE_NORMAL – Full operation
• STATE_PURGE – Active chamber purge
• STATE_DEGRADED – Limited operation
• STATE_FAULT – Critical fault / shutdown

Undefined states are not permitted.

4.2 State Transition Priorities

Absolute priority order:

1. Hardware Safety → STATE_FAULT
2. Sensor Health / Chamber Integrity → STATE_PURGE, STATE_WARMUP
3. Data Production → STATE_NORMAL, STATE_DEGRADED

4.3 State Descriptions (Summary)

• STATE_INIT:
• On power‑up/reset, perform POST, memory check, sensor bus ping.
• All OK & < 10 s → WARMUP; any failure or timeout → FAULT.
• STATE_WARMUP:
• Stabilize PID/NDIR and temperature.
• No valid data sent to cloud.
• After minimum warm‑up time and low temperature drift → NORMAL; failures/timeout → FAULT.
• STATE_NORMAL:
• Full sensing, compensation, risk scoring, MQTT telemetry.
• Chamber saturation (high RH/dust) → PURGE.
• Non‑critical sensor failure → DEGRADED.
• Critical fault (power, core sensor) → FAULT.
• STATE_PURGE:
• Stop normal data, send one “PURGE” flag.
• Run compressor/fan in reverse.
• After configured purge duration → WARMUP.
• STATE_DEGRADED:
• Bypass failed non‑critical sensors, simplify model, lower reliability score.
• Sensor recovers → WARMUP.
• Further fault escalation → FAULT.
• STATE_FAULT:
• Cut power to sensors/actuators, send SOS/Last‑Gasp, enter deep sleep/wait for reset.
• Only hardware reset/power cycle → INIT.

---

5.0 SYSTEM SAFETY AND RED‑LINE RULES

5.1 Active Cross‑Reference Condition for Red Risk

The system shall not raise a Red Risk (Aerosol Cluster) alarm unless all of the following are simultaneously satisfied within a defined time window:

1. Wind speed below threshold: e.g. $$v < 0.5$$ m/s (stagnant air).
2. Positive gradient in local CO₂ concentration (indicating human breath accumulation).
3. Tracer gas (Isobutylene) signal persistent and non‑dispersing during the same window.

If any condition is missing, only lower‑tier warnings or monitoring flags may be raised.

5.2 Watchdog Timer (WDT) Policy

• WDT is fed only after a full, successful processing cycle and/or valid state transition.
• If the loop breaks or hangs, WDT timeout triggers hardware reset; the node cannot remain locked in any state.

5.3 Fault Isolation

• The system must not continue in NORMAL mode using known corrupt/unreliable sensor data.
• Detected hardware/sensor faults must trigger an automatic transition to DEGRADED or FAULT, with faulty inputs excluded from risk algorithms.

---

5.3 MQTT TELEMETRY PACKET STRUCTURE

5.3.1 Protocol

• Protocol: MQTT over 4G/LTE Cat‑M1 (or equivalent).
• Payload: JSON.
• Default QoS: 1 (at least once).

5.3.2 Topic Structure (Example)

• hivescout/<city>/<street_id>/<node_id>/telemetry
• hivescout/<city>/<street_id>/<node_id>/status
• hivescout/<city>/<street_id>/<node_id>/alert

5.3.3 Telemetry Payload (NORMAL/DEGRADED)

Example:

{
  "device_id": "NODE-IST-0001",
  "fw_version": "2.1.0",
  "timestamp_utc": "2026-04-11T04:30:15Z",

  "state": "NORMAL",
  "reliability_score": 0.98,

  "co2_ppm": 650.2,
  "co2_raw_ppm": 642.0,

  "pid_isobutylene_ppb": 12.5,
  "pid_status": "OK",

  "rh_percent": 72.3,
  "temp_c": 18.6,
  "pressure_hpa": 1009.4,

  "wind_speed_ms": 0.3,
  "wind_dir_deg": 210,

  "optical_aerosol_od": 0.12,

  "battery_soc": 0.81,
  "vcc_volts": 3.29,

  "flags": {
    "crossref_ok": true,
    "purge_recent": false,
    "sensor_fault": false,
    "degraded_mode": false
  }
}

5.3.4 Alert Payload (Red Risk)

{
  "device_id": "NODE-IST-0001",
  "timestamp_utc": "2026-04-11T04:30:15Z",

  "alert_type": "AEROSOL_CLUSTER_RISK",
  "risk_score": 0.91,
  "reason": {
    "low_wind": true,
    "co2_gradient": true,
    "pid_plume_persistent": true,
    "optical_density_high": false
  },

  "state": "NORMAL",
  "reliability_score": 0.95
}

5.3.5 Requirements

• Every telemetry message must include state and reliability_score.
• Flags (pid_status, sensor_fault, degraded_mode, etc.) are mandatory for safe cloud‑side AI processing.
• Field names and units are part of the SRD baseline; changes require a controlled major revision.

---

Eğer istersen bir sonraki adımda bu SRD v2.1’den 2–3 sayfalık bir “Executive Summary / Pitch” çıkartıp, savunma fonu veya yatırımcıya yönelik sadeleştirilmiş bir versiyon da hazırlayabilirim.