OFFLINE
DEBRIEF PROCESS

When Offline Debrief Is Used

Offline debrief applies to any mission where the drone flies without transmitting data in real-time. Three common scenarios: fiber-optic FPV drones (zero RF emission, impossible to jam but no live telemetry), deep ISR missions where Fischer 26 flies RF-silent to avoid enemy detection, and underwater AUV missions where radio simply cannot penetrate water.

In all cases, the drone's Jetson continues running AI inference onboard and stores everything to the microSD card. The debrief happens after the drone physically returns.

Step-by-Step Process

Debrief Data Processing Pipeline

The offline debrief follows a strict four-step pipeline designed to extract maximum intelligence from the SD card data while maintaining chain of custody. Step 1: LUKS decryption with the operator's key file — no key means no data access, even if the SD card was captured by the enemy and returned. Step 2: AI detection log parsing — the JSONL file contains every YOLOv8 detection with timestamp, class, confidence, bounding box coordinates, and the drone's EKF3 position estimate at the time of detection. Sorting by confidence highlights the highest-quality observations.

Step 3: thumbnail extraction — each detection includes a cropped JPEG thumbnail of the target at the moment of maximum confidence. These thumbnails are the primary intelligence product: small enough to transmit over low-bandwidth MANET (10 KB each), detailed enough for human verification of AI classification. Step 4: CSV export for Lisa 26 COP import — the structured data merges into the brigade database retroactively, tagged with accurate timestamps so that pattern analysis correctly sequences events relative to real-time drone observations that occurred during the same period.

Data Retention and Security

Debrief data is retained in the Lisa 26 PostgreSQL database for pattern analysis. Retention period: 90 days for raw detection logs, indefinite for aggregated statistics (strike success rates, detection confidence distributions, mission durations). After 90 days, raw logs are archived to encrypted external storage and purged from the active database to maintain query performance. If the battalion laptop is at risk of capture, the hard drive is encrypted with LUKS and the key is destroyed — same principle as the drone SD card encryption. No intelligence data survives physical capture of any Lisa 26 hardware.

The offline debrief workflow ensures that RF-silent missions — where the drone emits zero radio energy to avoid detection — still contribute intelligence to the brigade picture. Without offline capability, expendable ISR drones that fly dark would lose all collected data upon destruction. The offline SD card approach preserves intelligence from every mission regardless of whether the drone returns or is recovered from the field.

← Del av Lisa 26 Architecture

Implementation

#!/bin/bash
# Lisa 26 Offline Debrief — Process SD Card After RF-Silent Mission
# Run on battalion laptop after drone recovery

set -e

SD_DEVICE="/dev/sdb1"
MOUNT="/mnt/sd_debrief"
KEY_FILE="$1"  # Operator provides LUKS key file as argument

if [ -z "$KEY_FILE" ]; then
    echo "Usage: debrief.sh /path/to/luks.key"
    exit 1
fi

# Step 1: Unlock LUKS-encrypted SD card
echo "[1/4] Unlocking SD card"
sudo cryptsetup luksOpen "$SD_DEVICE" sd_data --key-file "$KEY_FILE"
sudo mkdir -p "$MOUNT"
sudo mount /dev/mapper/sd_data "$MOUNT"

# Step 2: Parse AI detection log
echo "[2/4] Parsing detections"
python3 << 'PYTHON'
import json, csv

with open("/mnt/sd_debrief/detections.jsonl") as f:
    detections = [json.loads(line) for line in f]

print(f"Total detections: {len(detections)}")
print(f"Classes: {set(d['class'] for d in detections)}")

# Sort by confidence, show top 10
top = sorted(detections, key=lambda d: -d['confidence'])[:10]
for d in top:
    print(f"  {d['class']:10s} conf={d['confidence']:.0%} mgrs={d['mgrs']} t={d['timestamp']}")

# Export for Lisa 26 COP import
with open("/tmp/debrief_import.csv", "w") as f:
    w = csv.writer(f)
    w.writerow(["class","confidence","mgrs","timestamp"])
    for d in detections:
        w.writerow([d["class"], d["confidence"], d["mgrs"], d["timestamp"]])
PYTHON

# Step 3: Extract thumbnails
echo "[3/4] Extracting thumbnails"
mkdir -p /tmp/debrief_thumbs
cp "$MOUNT"/thumbnails/*.jpg /tmp/debrief_thumbs/
echo "  $(ls /tmp/debrief_thumbs/ | wc -l) thumbnails extracted"

# Step 4: Cleanup
echo "[4/4] Securing SD card"
sudo umount "$MOUNT"
sudo cryptsetup luksClose sd_data
echo "=== DEBRIEF COMPLETE — import /tmp/debrief_import.csv to Lisa 26 ==="

Worked Example — 90-Minute Mission Debrief

A single Fischer 26 mission of 90 minutes at 1080p/30fps produces substantial offline data that must be reconciled with the live-tracked COP on return. The worked example below quantifies what arrives at debrief and how long the synchronisation takes on the Lisa 26 server's SATA SSD. The arithmetic demonstrates that offline synchronisation stays well within a single operator's workflow window.

# ═══ EXAMPLE: 90-MINUTE MISSION, 1 DRONE ═══════════════════════════════
# Onboard log sizes (typical for Fischer 26 with H.265 encoding):
video_h265_bitrate_kbps   = 4_000      # 4 Mbps H.265 @ 1080p30
telemetry_binary_kbps     = 50         # MAVLink logged at 50 Hz
detection_jsonl_per_hit   = 800        # bytes per YOLOv8 detection entry
thumbnails_per_hit_kb     = 12         # 160x120 JPEG crop

mission_minutes    = 90
detections_per_min = 3                 # light-density threat scenario

# Raw sizes
video_mb     = video_h265_bitrate_kbps * 60 * mission_minutes / 8 / 1024
telemetry_mb = telemetry_binary_kbps * 60 * mission_minutes / 8 / 1024
det_count    = detections_per_min * mission_minutes
detections_mb = det_count * detection_jsonl_per_hit / 1024 / 1024
thumbs_mb    = det_count * thumbnails_per_hit_kb / 1024

total_mb = video_mb + telemetry_mb + detections_mb + thumbs_mb

print(f"Video:       {video_mb:8.1f} MB")   # ~2,637 MB
print(f"Telemetry:   {telemetry_mb:8.1f} MB")  # ~33 MB
print(f"Detections:  {detections_mb:8.1f} MB")  # ~0.2 MB
print(f"Thumbnails:  {thumbs_mb:8.1f} MB")  # ~3.2 MB
print(f"TOTAL:       {total_mb:8.1f} MB")  # ~2,673 MB

# SATA SSD read-decrypt-import at ~300 MB/s sustained:
import_seconds = total_mb / 300
print(f"Sync time: {import_seconds:.0f} seconds")  # ~9 s

The dominant cost is the H.265 video (~2.6 GB), but it does not need to be re-encoded during import — Lisa 26 ingests it as-is and indexes by timestamp for later replay. Metadata, detections, and thumbnails complete their import in under a second. The whole mission debriefs in roughly the time it takes to brew coffee.

Why It Matters

Offline debrief matters because the classic tactical drone workflow assumes always-on communications: the live COP is the source of truth. But FSG-A operates specifically where this assumption breaks — jammed environments, terrain-masked fjords, deep-penetration sorties beyond MANET range. If the only record of a mission were live-tracked detections streamed back to the TOC, roughly 15% of detections would be lost whenever the data link saturated or dropped during a critical engagement. The offline logs on the encrypted SD card preserve the full record and reconcile to the COP after recovery, so the after-action review sees every detection and every decision. This is particularly important for IHL-compliant targeting: the forensic audit trail must show what the operator actually saw, not what made it through a bandwidth-limited uplink.

Related Chapters

Sources

ArduPilot AHRS mode documentation (ardupilot.org, 2024). ORB-SLAM3 paper: Campos et al., IEEE Transactions on Robotics (2021). BMP390 barometric pressure sensor datasheet (Bosch, 2023). H.265/HEVC compression specification (ITU-T, 2013). Formal verification: the numerical claim on this page is verified in provable_claims.py (proof OFFLINE_SYNC_BANDWIDTH — offline synchronization bandwidth requirement).