Operator Manual

Power-On Sequence

1. Apply power to the sensor unit. Wait for the status LED to show solid amber (boot in progress).
2. After 30-60 seconds the LED transitions to solid green, indicating the OS has loaded and Varta services are initializing.
3. On units with an OLED display, the boot summary screen appears once all services report healthy.

Service Verification

Confirm all core services are running before beginning operations:

sudo systemctl status varta-sensor
sudo systemctl status varta-mqtt
sudo systemctl status varta-watchdog

All three services must report active (running). If any service shows failed or inactive, consult the Troubleshooting Guide.

Sensor Health Check

Run the built-in self-test to verify hardware connectivity and baseline calibration:

varta-cli self-test --verbose

• SDR connection: Confirms USB device enumeration and sample rate negotiation.
• Noise floor baseline: Measures ambient RF level across monitored bands. Flags if noise floor exceeds expected thresholds.
• GPS lock (if equipped): Reports fix quality, satellite count, and positional accuracy.
• MQTT broker reachability: Tests TLS handshake and authentication against the configured broker endpoint.

Threat Levels

Varta uses a five-level threat classification. Each level maps to a specific response posture:

Alert Response Procedures

1. Acknowledge the alert within 30 seconds via the dashboard or OLED confirm button.
2. Assess the detection: review confidence score, signal provenance, frequency band, and sensor source.
3. Verify using an independent method (second sensor, visual/optical, RemoteID lookup) when threat level is 3 or above.
4. Classify the alert as confirmed threat, false positive, or inconclusive. Log the classification with operator notes.
5. Escalate if the threat level warrants it per the escalation matrix below.

Escalation Matrix

• Level 1-2: Operator handles autonomously. Review at shift debrief.
• Level 3: Notify shift supervisor within 5 minutes. Supervisor decides escalation.
• Level 4: Immediate supervisor notification. Activate site response team standby.
• Level 5: Immediate notification to site commander and response team. Countermeasure authorization requested per standing rules of engagement.

Confirming Detections

Every detection above threat level 2 should be verified before escalation. Verification methods in order of preference:

1. Multi-sensor corroboration: Check whether two or more sensors detected the same event within a 5-second window. Cross-sensor hits significantly increase confidence.
2. DF/TDOA fix: If three or more sensors have bearings, the fused track provides a geolocation. Verify the position makes physical sense (altitude, speed, trajectory).
3. Visual or optical confirmation: If the site has cameras or line-of-sight, attempt visual acquisition on the reported bearing.
4. RemoteID lookup: Query the RemoteID feed for matching UAS serial or session ID.

Interpreting Confidence Scores

• 90-100: High confidence. Strong protocol match with clean I/Q classification. Treat as confirmed unless contradicted by visual evidence.
• 70-89: Moderate confidence. Good signal match but some ambiguity (partial protocol decode, moderate SNR). Verification recommended.
• 50-69: Low-moderate confidence. Pattern is suggestive but not conclusive. May be interference or non-drone emitter. Require independent verification before escalation.
• Below 50: Low confidence. Logged for analysis but not actionable without corroboration. Review during shift debrief.

Reviewing Provenance

Each detection carries a provenance chain showing which processing stages contributed to the final classification:

{
  "provenance": [
    {"stage": "sweep",    "result": "hit",  "band": "2.4GHz", "power_dbm": -42},
    {"stage": "iq_capture","result": "pass", "snr_db": 18.3,  "duration_ms": 200},
    {"stage": "ml_classify","result": "DJI_Mavic3", "confidence": 0.87},
    {"stage": "protocol_decode","result": "partial", "fields_decoded": 6}
  ]
}

A detection that passes all four stages is significantly more reliable than one that skipped I/Q capture or had a partial protocol decode. Use the provenance to gauge how much weight to give the detection.

Site Survey

Before deploying sensors, conduct a site survey to assess RF environment and physical layout:

1. RF background scan: Run a 15-minute spectrum sweep at each candidate sensor position using varta-cli survey --duration 900. Record the noise floor per band.
2. Line of sight: Map obstructions (buildings, terrain, vegetation) that could shadow RF detection or block DF bearings.
3. Infrastructure check: Confirm power availability, network connectivity (wired or wireless), and physical mounting options at each position.
4. Threat axis assessment: Identify the most likely approach corridors for UAS threats and orient sensor coverage accordingly.

Sensor Placement

• Spacing: For DF/TDOA triangulation, sensors should be spaced 200-500 meters apart with overlapping coverage.
• Height: Mount sensors at 3-10 meters elevation with clear horizon. Higher is generally better for detection range but may increase wind exposure.
• Orientation: Ensure antenna boresight covers the primary threat axis. For omnidirectional antennas, placement symmetry is more important than orientation.
• Avoid co-location with high-power emitters (cellular towers, radar installations, industrial RF sources) which will degrade sensitivity.

Baseline Calibration

After physical installation, run the baseline calibration procedure:

varta-cli calibrate --baseline --duration 1800
# 30-minute observation window, no known drones in area
# Captures ambient RF profile for false-positive suppression

• Calibration must be performed during normal site activity (not during quiet hours) to capture representative interference.
• Repeat calibration if the RF environment changes significantly (new equipment installed, seasonal foliage changes, construction activity).
• Calibration data is stored at /var/lib/varta/baseline/ and versioned by timestamp.

Sensor Failure

If a sensor stops reporting or enters a fault state:

1. Check the Sensor Status Panel for diagnostic information (last heartbeat, error code).
2. Attempt a remote restart via the command node:

   varta-cli restart --sensor <sensor-id> --remote

3. If remote restart fails, dispatch field technician for physical inspection. Common causes: SD card corruption, power supply fault, SDR USB disconnect.
4. Assess coverage gap. If the failed sensor covers a critical threat axis, consider repositioning an adjacent sensor or deploying a spare unit.
5. Log the failure event, cause (if determined), and resolution in the maintenance record.

Communications Loss

If the MQTT broker becomes unreachable or network connectivity is lost:

1. Sensors automatically fall back to standalone mode. Local detection and alerting continue via GPIO and OLED.
2. Check network infrastructure: switches, routers, access points, cable integrity.
3. Verify broker status on the command node:

   sudo systemctl status mosquitto
   mosquitto_sub -h localhost -t '$SYS/broker/uptime' -C 1

4. If broker is down, restart:

   sudo systemctl restart mosquitto
   # Wait 15 seconds, then verify sensors reconnect
   varta-cli fleet-status

5. During comms loss, operators at remote sensor locations must follow standalone alert procedures and record detections manually.

High-Threat Response

When a threat level 5 detection is confirmed:

1. Immediate actions (0-60 seconds):
   • Acknowledge the alert on the dashboard.
   • Verbally notify the site commander or duty officer.
   • Activate the site alarm if authorized per standing orders.
2. Assessment (1-3 minutes):
   • Confirm multi-sensor corroboration. Check DF/TDOA track for position, heading, speed.
   • Attempt visual acquisition. Task cameras if available.
   • Query RemoteID for UAS identification.
3. Response (per ROE):
   • Request countermeasure authorization through the chain of command.
   • Maintain continuous tracking and update the tactical picture.
   • Log all actions, decisions, and communications with timestamps.
4. Post-incident:
   • Preserve all detection data, logs, and recordings.
   • Complete incident report within 4 hours.
   • Conduct after-action review within 24 hours.