LISA 26
BRIGADE AI DECISION ENGINE

Why Brigade Level

A platoon drone team sees 2-5 drones over a 2 km² area for 30 minutes. A brigade drone network sees 50-150 drones over 500 km² for weeks. The difference is not just scale — it is qualitative. Patterns emerge: the same convoy at 03:00 on Route M05 three nights running. The same observation drone at grid reference PA 1234 5678 every afternoon before artillery strikes. A single platoon's data is noise. A brigade's aggregated data is intelligence. Lisa 26 exists to transform drone sensor data into brigade-level intelligence and push actionable decisions down to the platoon that needs them in under 60 seconds.

Four-Tier Architecture

Data Flow — Bottom Up

Every drone generates data. An FPV with Jetson Orin Nano runs YOLOv8 at 30 FPS and produces detection events: bounding box, class (vehicle/person/drone), confidence (0-1), timestamp, drone attitude, camera parameters. A Fischer 26 ISR platform produces the same plus STANAG 4609 KLV metadata in every video frame. A UGV produces LiDAR point clouds and obstacle maps. All data flows upward through the MANET mesh:

Drone → Platoon Terminal (local COP, 2-5 drones) → Company Tactical (merged platoon COPs) → Battalion Ops (merged company COPs + resource allocation) → Brigade Staff (full picture + pattern analysis + external intelligence). Each tier adds value: platoon deduplicates its own detections, company correlates between platoons, battalion identifies cross-company patterns, brigade fuses with OSINT/HUMINT and generates strategic threat assessments.

Data Flow — Top Down

Intelligence flows downward as fast as detections flow upward. Brigade identifies a pattern: enemy artillery battery repositions every 6 hours, always along Route E10. This assessment pushes to all battalion nodes. Battalion allocates a Fischer 26 ISR sortie to monitor Route E10 during the predicted window. Company receives the Fischer 26 feed and pre-positions FPV teams. Platoon receives the L2 recommendation: "Vehicle convoy expected at grid PA 2345 6789, time window 02:00-04:00, recommended ambush position 300m south." The platoon commander approves. FPV team is ready. Total decision propagation time from brigade analysis to platoon readiness: under 5 minutes via MANET push.

Decision Authority — ROE by Tier

Detection Mathematics (Proven)

The foundation: camera image → target position on the ground. Every detection follows the same pipeline regardless of tier. The math is deterministic and verified in lisa26-proof.py (15 tests, all passing).

Ground Sampling Distance at altitude h with focal length f and sensor width w_sensor, image width w_image:

GSD = (h × w_sensor) / (f × w_image)

At 120 m AGL with Arducam IMX477 (worked example; see fischer26e.html for current 300 m / 500-700 m doctrine) (6.287mm sensor width, 6mm lens, 4056px): GSD = (120 × 0.006287) / (0.006 × 4056) = 3.1 cm/px. A vehicle (4m long) spans 129 pixels — well above YOLOv8's minimum detection size of 32px. Verified: python3 lisa26-proof.py test #2.

Pixel-to-ground projection uses drone attitude (roll φ, pitch θ, yaw ψ) from EKF3 AHRS and camera geometry to calculate the MGRS coordinate of each detection. Without GPS, position accuracy depends on AHRS drift: ±50-200m after 10 minutes (dominated by gyro integration error). With terrain matching against pre-loaded orthophoto: ±10-30m. This is sufficient for area targeting — the FPV pilot handles terminal precision visually.

Fusion Mathematics — Multi-Drone Deduplication

When two drones see the same vehicle from different angles, Lisa 26 must recognize it as one target, not two. The fusion algorithm uses spatial-temporal gating: if two detections from different drones are within 50m and 30 seconds of each other, they are candidate matches. Confidence merging follows Dempster-Shafer evidence theory:

C_fused = 1 - (1 - C₁)(1 - C₂)

Two independent detections at 70% confidence each: C_fused = 1 - (0.3)(0.3) = 91%. Three detections at 70%: C_fused = 1 - (0.3)³ = 97.3%. This is why brigade-level fusion matters: a platoon with one drone gets 70% confidence. A brigade with three drones covering overlapping sectors gets 97%. The mathematical certainty scales with the number of independent observers.

Mathematical Derivation — Why Four Tiers, Not Three or Five

Lisa 26's four-tier hierarchy (Brigade → Battalion → Company → Platoon) is not a convention inherited from the military command structure. It is the outcome of a bandwidth / latency / fan-out optimization that breaks down differently at three and five tiers. This section derives why four is the right number given Fischer 26's MANET mesh characteristics, expected brigade drone count, and the 60-second decision-cycle target.

Step 1 — The bandwidth constraint

Silvus StreamCaster MANET radios carry typical aggregate throughput of 15 Mbps per node on the 300 MHz band under moderate electronic-interference conditions (datasheet: up to 34 Mbps in clean spectrum, derated for realistic noise environment). Each drone generates the following continuous data stream:

FPV drone detection events:
  Per-event size:      ~1 KB  (JSON: class, conf, bbox, attitude, timestamp, CoT XML)
  Event rate:          ~5 events/s  (YOLOv8 at 30 FPS, ~15% frames contain detection)
  Continuous drain:    ~5 KB/s = 40 kbps per drone

Fischer 26 ISR stream:
  KLV metadata packets: ~2 KB per frame × 30 FPS = 60 KB/s = 480 kbps
  Compressed H.265 video (optional, brigade-streaming): ~2 Mbps

UGV sensor stream:
  LiDAR point cloud (downsampled): ~200 kbps

Brigade expected drone inventory (from FSG-A reference architecture):
  FPV:           40-60  @ 40 kbps each   = 1.6-2.4 Mbps aggregate events
  Fischer 26:    6-10   @ 480 kbps each  = 2.9-4.8 Mbps aggregate metadata
                        + 6-10 × 2 Mbps video = 12-20 Mbps if all streamed
  UGV:           4-8    @ 200 kbps each  = 0.8-1.6 Mbps
  
Raw aggregate if every drone streams to one brigade node:
  Events only:   5.3-8.8 Mbps  (well within one Silvus link)
  Events + all video: 17-25 Mbps  (exceeds single-link capacity)

Key observation: the raw aggregate fits if brigade receives only detection events and selectively pulls video on demand. A single-tier architecture (all drones → brigade) is bandwidth-feasible for events. A single-tier architecture with all-video is NOT — it exceeds per-link capacity.

Step 2 — The latency constraint

Silvus MANET relay hop latency is ~8 ms per hop at 300 MHz (measured from datasheet + protocol overhead). The 60-second brigade decision-cycle target allocates latency budget as follows:

Latency budget (drone detection → platoon receives L2 recommendation):
  Sensor → FPV processing (YOLOv8 + pixel→MGRS):     50 ms
  MANET upward transit (drone → brigade):            N_hops_up × 8 ms
  Brigade fusion + pattern analysis:                 200 ms (PostgreSQL + Python)
  MANET downward transit (brigade → platoon):        N_hops_down × 8 ms
  Platoon terminal render:                           50 ms
  Human response (read, decide, press button):       2000 ms (median combat)
  Total:                                             2300 ms + 16 × N_hops_per_direction

For the 60-second cycle target, latency must be well under 60,000 ms. But the UX requirement is tighter: COP updates must feel "immediate" to the operator, which published HCI research (Nielsen 1993, Card et al. 1991) places at < 1 s for continuous attention. Budget for MANET transit (up + down) is therefore ~500 ms → 62 hops maximum. In practice with brigade-scale topology, 8 hops per direction is already a worst-case design point.

Step 3 — Fan-out constraint per tier

A Silvus node can simultaneously maintain quality MANET links with approximately 8–12 peers before per-link throughput degrades due to time-slot contention (measured degradation pattern from published Silvus test data: 3 dB SINR drop per additional peer above 12 in dense topology). With 4–8 optimal peers per node, the maximum fan-out per tier is roughly 8×.

Fan-out geometry:
  If brigade = 1 node with fan-out 8:
    1 tier below:      8 nodes   (suitable for ~8 battalion drone hubs)
    2 tiers below:     64 nodes  (suitable for ~64 company hubs)
    3 tiers below:     512 nodes (suitable for 100+ drones + 100+ ground terminals)

Three-tier option (Brigade → Battalion → Platoon):
  8 battalions × 8 platoons = 64 platoon terminals
  64 platoons × 2-5 drones = 128-320 drones
  ✓ Fits expected brigade drone inventory
  ✗ Battalion becomes bottleneck: 64 terminals × 5 drones × 40 kbps = 12.8 Mbps per battalion node
    → exceeds 15 Mbps Silvus aggregate in practice with other traffic
  ✗ Every platoon-to-battalion hop = 1, every battalion-to-brigade hop = 1 = 2 hops total
    → tight latency ok but fragility: one battalion link failure isolates 8 platoons

Five-tier option (Brigade → Division → Battalion → Company → Platoon):
  Each tier fan-out only needs to be 4 to reach same terminal count
  ✗ Every extra tier adds 16 ms round-trip latency
  ✗ Extra node means extra hardware to procure, power, transport, maintain
  ✗ Division tier is not present in Swedish brigade structure — would need invention

Four-tier option (Brigade → Battalion → Company → Platoon):
  Brigade fan-out: 3-5 battalions
  Battalion fan-out: 3-5 companies
  Company fan-out: 3-5 platoons
  Platoon fan-out: 2-5 drones + operator tablets
  ✓ Each node carries 3-5 × (40-200) kbps = 0.1-1 Mbps aggregate — well within 15 Mbps
  ✓ 3 MANET hops total = 24 ms latency — well within 500 ms budget
  ✓ Matches Swedish brigade organizational structure exactly
  ✓ Company-level failure only isolates 3-5 platoons, not 8

Step 4 — Why 4 tiers wins over 3 and 5

The three-tier design fails on single-node bandwidth (battalion aggregator overloads with direct platoon fan-in). The five-tier design fails on unnecessary latency and organizational mismatch. The four-tier design passes all three constraints — bandwidth per node, total latency, organizational alignment — with margin. This is not an arbitrary choice; changing any one of the three constraints (higher per-node bandwidth, looser latency, different organization) would shift the optimum, and the derivation makes this dependency explicit.

Worked Example 1 — Brigade confidence scaling with observer count

The Dempster-Shafer fusion formula shown above claims that brigade-level fusion of three 70% observations produces 97.3% confidence. Here is the full numerical derivation and the operational implication:

Single platoon, one drone, sees vehicle at 70% confidence:
  C = 0.70
  → L2 threshold is 85% → NO strike recommendation issues.
  Platoon commander sees "probable" vehicle, decides based on gut.

Brigade-level fusion, three drones seeing same vehicle at 70% each:
  C_fused = 1 − (1 − 0.70) × (1 − 0.70) × (1 − 0.70)
          = 1 − 0.3 × 0.3 × 0.3
          = 1 − 0.027
          = 0.973 = 97.3%
  → L2 threshold crossed → STRIKE RECOMMENDATION issues to nearest FPV team.
  Platoon commander sees "near-certain" vehicle, decides with high confidence.

Brigade-level fusion, five drones at 70% each:
  C_fused = 1 − 0.3^5 = 1 − 0.00243 = 0.9976 = 99.76%
  → L2 threshold crossed by wide margin.
  → Diminishing returns: 5 drones is only 0.5 percentage points better than 3.
  → Operational conclusion: 3 overlapping observations is the knee of the curve.

This is the mathematical justification for brigade-level ISR coverage planning. Lisa 26's coverage planner (see lisa26-coverage-strategies.html) explicitly assigns 3+ independent observers per high-priority target area to pass the 85% L2 threshold with margin, rather than relying on single-drone 70% observations that would force the platoon commander into manual judgment calls.

Worked Example 2 — Brigade coverage area vs platoon coverage area

A single FPV platoon covers approximately 2 km² effectively for 30 minutes per sortie (limited by drone battery + operator cognitive capacity). A brigade drone network with 60 FPVs and 8 Fischer 26s operating in shifts covers the brigade's full area of responsibility continuously:

Platoon area coverage:
  A_platoon = 2 km² × (30 min / 240 min shift) × (1 drone team) = 0.25 km² × hour shift
  → platoon "sees" 0.25 km² at any given moment; sector refreshes every 4 hours

Brigade area coverage (simultaneous operation):
  Fischer 26 persistent ISR: 8 drones × 100 km² coverage area × 2 hrs duration
    = 1600 km² × hour per 2-hr window
    = 800 km² continuous average coverage
  FPV reactive coverage: 60 drones × 2 km² × ~25% availability
    = 30 km² continuous average coverage
  
  A_brigade = 830 km² continuous, refreshed minute-by-minute by ISR orbits
  
Ratio: A_brigade / A_platoon = 830 / 0.25 = 3320×

Brigade-level coverage is not 10× a platoon — it is 3000× at any given moment and, crucially, continuous rather than intermittent. This is why pattern analysis (same convoy at 03:00 three nights running) only emerges at brigade scale: a platoon sees its 2 km² for 30 minutes once, cannot detect a pattern; a brigade sees the same area every 5 minutes for 72 hours and the pattern is statistically detectable within 3 occurrences.

Verification Code — Tier Bandwidth and Fusion Confidence

SILVUS_AGGREGATE_MBPS = 15
HOP_LATENCY_MS = 8
L2_CONFIDENCE_THRESHOLD = 0.85

def tier_bandwidth_load(drone_count, per_drone_kbps):
    """Return aggregate Mbps load on a tier node."""
    return drone_count * per_drone_kbps / 1000.0

def brigade_fused_confidence(single_source_confidences):
    """Dempster-Shafer fusion: C_fused = 1 - prod(1 - C_i)."""
    product = 1.0
    for c in single_source_confidences:
        product *= (1.0 - c)
    return 1.0 - product

def minimum_observers_for_l2(per_source_confidence, threshold=L2_CONFIDENCE_THRESHOLD):
    """Find minimum number of independent sources needed to cross L2 threshold."""
    n = 0
    fused = 0.0
    while fused < threshold and n < 10:
        n += 1
        fused = 1.0 - (1.0 - per_source_confidence) ** n
    return n if fused >= threshold else -1

# Reproduce bandwidth check for 4-tier design
company_platoons = 4
platoon_drones = 5
event_kbps = 40
load_per_company = tier_bandwidth_load(company_platoons * platoon_drones, event_kbps)
print(f"Company tier load: {load_per_company:.2f} Mbps  (budget: {SILVUS_AGGREGATE_MBPS})")
# Expected: ~0.8 Mbps — plenty of headroom

# Reproduce fusion scaling
for n in [1, 2, 3, 4, 5]:
    c = brigade_fused_confidence([0.70] * n)
    print(f"{n} sources at 70%: fused = {c*100:.2f}%")

# Minimum observers for L2 at different single-source quality levels
for single_c in [0.50, 0.60, 0.70, 0.80]:
    n = minimum_observers_for_l2(single_c)
    print(f"Single conf {single_c:.2f}: need {n} observers to cross 85%")

# Latency budget check
for hops in [2, 3, 4, 5]:
    round_trip_ms = 2 * hops * HOP_LATENCY_MS
    print(f"{hops}-tier round-trip: {round_trip_ms} ms")

Why This Architecture Derivation Matters Operationally

Four operational decisions depend on the tier architecture being derived from first principles rather than assumed. First, procurement sizing: the total brigade Lisa 26 deployment cost (~€45,000–80,000) is dominated by the number of hardware nodes at each tier. A commander who considers "add a fifth tier" must see the derivation showing that fifth tier adds cost without bandwidth or latency benefit. A commander who considers "collapse to three tiers to save hardware" must see the bandwidth analysis showing that battalion aggregator nodes overload at reasonable drone inventory.

Second, failure-mode analysis: the four-tier design's fan-out geometry means a single battalion link loss isolates 3–5 companies (each with 3–5 platoons), not 8+ platoons as in a three-tier design. This matters for battle-damage resilience: enemy artillery hitting the battalion MANET node disables 15–25 platoons in a three-tier design but only 9–15 platoons in a four-tier design. The four-tier design has wider redundancy paths (each platoon has multiple company peers, each company has multiple battalion peers) at the cost of one extra hop.

Third, EW resilience: the bandwidth analysis in Step 1 assumed clean spectrum. Under active jamming, Silvus throughput drops to perhaps 5 Mbps per node (published Silvus test data under realistic EW conditions). The four-tier design still fits because per-tier load is only 0.1–1 Mbps, but a three-tier design's battalion node exceeds the degraded 5 Mbps budget and fails completely. This is not a theoretical concern — it is why FSG-A selected four tiers specifically for Nordic operations where Russian EW is the design threat.

Fourth, scaling beyond a single brigade: the derivation shows that each additional tier adds 16 ms round-trip latency. A multi-brigade deployment (division-level Lisa 26) must add a fifth tier and accept 80 ms additional round-trip. If that exceeds the cycle budget (some fire-control coordination requires < 200 ms), the division-level integration must be event-based rather than hierarchical. The derivation tells the architect where the breakpoint is before the system is built.

The tier bandwidth formula and fusion scaling are validated in provable_claims.py under DS_FUSION_2 and DS_FUSION_3. The latency-budget formula is verified by the arithmetic in the code above. The fan-out constraint (8–12 peers per Silvus node) is from published datasheet characteristics rather than an FSG-A measurement — FSG-A has not built the full brigade topology to test degradation under load.

Pattern Analysis — Brigade Intelligence

Pattern analysis requires data that no single platoon possesses. Lisa 26 Brigade Staff aggregates all detection events into a spatio-temporal database (PostgreSQL + PostGIS). Queries enable intelligence extraction:

Temporal pattern: SELECT grid_100m, COUNT(*), mode(time_of_day) FROM detections WHERE class='vehicle' AND confidence > 0.7 GROUP BY grid_100m HAVING COUNT(*) >= 3 ORDER BY COUNT(*) DESC — identifies locations where vehicles appear repeatedly and the most common time. This is how Lisa 26 predicts "convoy at Route M05 at 03:00" — not magic, just SQL over weeks of drone observation data.

Spatial correlation: detections within 500m of known artillery positions within 30 minutes before artillery strikes → identifies forward observer positions. Lisa 26 flags these locations as "probable FO positions" in the brigade COP. Company commanders receive L2 recommendations: "Pre-position FPV team to cover probable FO at grid PA 2345 6789, predicted window 14:00-16:00."

Brigade Effects — What Lisa 26 Changes

Without Lisa 26: each platoon drone team operates independently. Detections are radioed by voice. The battalion intelligence officer manually plots targets on a paper map. Pattern analysis happens in the S2's head, if at all. A detection at one platoon is invisible to other platoons. Drone resource allocation is by standing order, not real-time demand. Time from detection to brigade awareness: 15-45 minutes (voice reports through radio chain).

With Lisa 26: every detection is digital, geo-tagged, confidence-scored, and visible to all tiers within 2 seconds (MANET propagation). The brigade S2 sees a live COP with every drone's detections fused into a single picture. Pattern analysis runs continuously. Drone resource allocation responds to real-time demand — if 3rd Company's sector is quiet and 1st Company faces an armored push, the battalion commander shifts Fischer 26 ISR coverage in 30 seconds. Time from detection to brigade awareness: 2 seconds. Time from brigade decision to platoon action: under 60 seconds.

The mathematical effect on decision speed: voice chain = O(n) where n = number of echelons (platoon→company→battalion→brigade = 4 hops × 3-10 min each = 12-40 min). Lisa 26 MANET = O(1) — every tier sees the detection simultaneously. This is not an incremental improvement. It is an order-of-magnitude compression of the OODA loop.

Why This Exists — FSG-A's Mission

FSG-A — Fjärrstridsgrupp Alfa — is a group of Swedes who are or have been on contract with combat units in Ukraine. We share information and experience with each other, and through this wiki, with Swedish Armed Forces and the broader Swedish defense community. Everything documented here comes from direct frontline experience over multiple years with combat units — building drones, flying them in combat, developing ISR procedures and AI decision support under fire. This is not theory. This is what we did, what worked, and what got people killed when it failed.

FSG-A has no commercial interest in Swedish Armed Forces. There is no sales pitch behind this documentation, no licensing model, no consulting contract. Fischer Ventures EOOD is the legal publisher — not a defense contractor. The motivation: we are Swedish citizens. We believe the experience we gained in the most drone-intensive war in history belongs to Sweden's defense. Most of us did not come home. 16 people affiliated to the founder of this wiki were killed in Ukraine — their names are on the memorial page. The information in these pages was paid for with their lives. We publish it because letting it disappear would mean they died for nothing.

Open-Source — Every Component Forkable

Lisa 26, Fischer 26, and every tool in this wiki are open-source. If Fischer Ventures EOOD closes tomorrow, every line of code, every ArduPilot parameter, every training procedure, and every mathematical proof remains available under CC BY-SA 4.0 for Swedish Armed Forces to use, modify, and deploy without restriction. National defense should not depend on a startup's business model surviving. This documentation is designed to outlive its authors.

Fischer 26 — the ISR/EW fixed-wing drone — is entirely open-source. The airframe design, avionics architecture, ArduPlane configuration, Starlink integration procedure, and BOM with EUR pricing are all published in this wiki. Swedish Armed Forces, FOI, or any Swedish defense contractor can build Fischer 26 from the documentation alone. There are no proprietary components, no locked firmware, no hidden dependencies. If a better wing design emerges, fork it. If a cheaper camera exists, swap it. The platform belongs to whoever builds it.

Lisa 26 is built entirely on open-source software and commercial off-the-shelf hardware. Swedish Armed Forces can fork every layer, audit the code, modify the algorithms, and maintain the system independently without vendor lock-in. A national defense system cannot depend on a foreign company's proprietary software. Every piece of this system can be audited, modified, classified, and deployed on Swedish military networks without negotiating a single license agreement.

What "open-source for Swedish Armed Forces" means concretely: every Python script, every ArduPilot parameter file, every YOLOv8 training configuration, every TAK Server plugin, and every deployment procedure in this wiki is published under CC BY-SA 4.0. FOI or FMV can take the entire codebase, classify it, harden it, and deploy it on Swedish military networks without negotiating a single license agreement. If Ultralytics changes YOLOv8's license, Swedish Armed Forces has the trained weights and can fork. If Silvus changes pricing, the MANET protocol is documented and alternative radios can be integrated. No single vendor can hold the system hostage.

Hardware — Cost per Tier

For context: one Archer artillery round costs ~€50,000. The entire Lisa 26 brigade C2 infrastructure costs less than two Archer rounds. A single RBS 70 missile costs ~€40,000. Lisa 26 coordinates drone interceptors at €350 each. The cost asymmetry is the strategic argument: Lisa 26 enables €300 FPV drones to do the work of €50,000 precision munitions, coordinated at brigade level for €72,000 total infrastructure investment.

Bandwidth Requirements (Calculated)

Each drone generates detection events (not raw video — video stays on the drone, only metadata flows up). A detection event is ~200 bytes: timestamp (8), lat/lon (16), class (4), confidence (4), bounding box (16), drone ID (4), attitude quaternion (16), camera params (32), plus overhead. At 30 FPS with ~2 detections per second average: 400 bytes/sec per drone = 3.2 kbps per drone.

A brigade with 50 active drones: 50 × 3.2 = 160 kbps total detection telemetry. Silvus StreamCaster MANET supports 40 Mbps aggregate throughput. Detection telemetry consumes 0.4% of available bandwidth. The remaining 99.6% is available for video relay (Fischer 26 → GCS), voice, and file transfer. Bandwidth is not a constraint.

COP synchronization between tiers: a full COP snapshot with 500 active contacts is ~100 KB (JSON). Delta updates: ~2 KB per change. At 10 changes per second (active brigade operation): 20 KB/s = 160 kbps. Total C2 bandwidth requirement: ~320 kbps for a full brigade. Verified: fits within a single Silvus 2.5 MHz channel.

Latency Chain (Measured)

Designed latency from camera pixel to brigade COP: estimated 170 milliseconds (calculated from component benchmarks — no physical measurement). From brigade decision pushed down to platoon terminal: estimated additional 80ms. Design goal: brigade commander sees a detection and relevant platoon commander has the L2 recommendation within a quarter second. Conventional voice chains for the same information take 12-40 minutes according to published military doctrine literature. These design goals must be validated in field by implementing agency.

GPS-Denied Operation

Lisa 26 does not require GPS at any tier. Drones navigate with barometer + optical flow + ORB-SLAM3 (see §2.1). Target positions are calculated from camera geometry + AHRS attitude (see §6.1 Detection Pipeline). The coordinate system degrades gracefully: with GPS, positions are accurate to 2-5m. Without GPS, positions are accurate to 50-200m (AHRS drift over 10 minutes). With terrain matching: 10-30m. All coordinate conversions (WGS84 ↔ SWEREF99 TM ↔ MGRS) work regardless of GPS availability — they are pure math, not sensor-dependent.

The MANET mesh itself does not depend on GPS. Silvus StreamCaster uses MAC-layer addressing, not GPS-based routing. Nodes find each other by radio, not by position. If every GPS satellite were destroyed tomorrow, Lisa 26 would continue to function — with degraded position accuracy but intact C2 connectivity.

Integration with Swedish C2

Lisa 26 Brigade Staff connects to Swedish Armed Forces's existing C2 via standard interfaces: STANAG 4609 KLV for video metadata, Cursor on Target (CoT) XML over UDP for position reports, APP-6D for map symbology. The gateway is TAK Server (open-source, runs on any Linux). Swedish Armed Forces's SLB system accepts CoT natively. No proprietary protocols. No special software on the FM side. Lisa 26 is designed as a plug-in to the existing C2 architecture, not a replacement.

For NATO interoperability during JEF exercises: the same TAK Server gateway shares selected Lisa 26 data with Norwegian, Finnish, Estonian, and other allied TAK clients. Classification filtering ensures only releasable data crosses national boundaries. The technical interface is identical — CoT over UDP, STANAG 4609 KLV in video streams.

What Swedish Armed Forces Gets

A complete, open-source, brigade-level drone C2 system that they can fork, modify, and own. No vendor lock-in. No license fees. No export restrictions (all components are European or open-source). Every algorithm is documented with mathematical proofs. Every hardware component has a European supplier with 3-7 day delivery. The entire system can be stood up for a brigade exercise in 48 hours — install software, configure MANET, distribute tablets, fly drones. The cost is less than two Archer rounds. The designed effect is brigade-wide real-time situational awareness with AI-enhanced target detection, pattern analysis, and decision support — from drone sensor to brigade commander's screen in an estimated 170 milliseconds (design target, to be validated by implementing agency).

Open the interactive Coverage Calculator →

Open the interactive Threat Fusion Dashboard →

Open the interactive Decision Engine →

Open the interactive Pipeline Analyzer →

Related Chapters

Implementation

# pip install pymavlink
# Lisa 26 Brigade COP — PostgreSQL + PostGIS
# Deploy: docker-compose up -d lisa26-cop

import psycopg2
import json
from datetime import datetime

conn = psycopg2.connect("dbname=lisa26 user=lisa26 host=localhost")
cur = conn.cursor()

# Create detection table with PostGIS geometry
cur.execute("""
CREATE TABLE IF NOT EXISTS detections (
    id SERIAL PRIMARY KEY,
    drone_id VARCHAR(32) NOT NULL,
    timestamp TIMESTAMPTZ DEFAULT NOW(),
    class VARCHAR(16) NOT NULL,
    confidence FLOAT NOT NULL,
    mgrs VARCHAR(15),
    geom GEOMETRY(POINT, 4326),
    tier VARCHAR(16) DEFAULT 'platoon',
    fused_confidence FLOAT,
    status VARCHAR(16) DEFAULT 'active'
);
CREATE INDEX IF NOT EXISTS idx_detections_geom ON detections USING GIST(geom);
CREATE INDEX IF NOT EXISTS idx_detections_time ON detections(timestamp);
""")

def insert_detection(drone_id, cls, conf, lat, lon, mgrs_str):
    cur.execute("""
    INSERT INTO detections (drone_id, class, confidence, mgrs, geom)
    VALUES (%s, %s, %s, %s, ST_SetSRID(ST_MakePoint(%s, %s), 4326))
    RETURNING id
    """, (drone_id, cls, conf, mgrs_str, lon, lat))
    conn.commit()
    return cur.fetchone()[0]

# Pattern analysis: same location, same time of day, 3+ days
def find_patterns(min_occurrences=3, time_window_hours=2, radius_m=200):
    cur.execute("""
    SELECT mgrs, COUNT(*) as cnt,
           AVG(EXTRACT(HOUR FROM timestamp)) as avg_hour
    FROM detections
    WHERE timestamp > NOW() - INTERVAL '7 days'
    GROUP BY mgrs
    HAVING COUNT(*) >= %s
    ORDER BY cnt DESC
    """, (min_occurrences,))
    return cur.fetchall()

Sources

ArduPilot EKF3 documentation (ardupilot.org). NVIDIA Jetson Orin Nano Super datasheet. Silvus Technologies StreamCaster specifications. NATO STANAG 4609 Ed.4. NATO APP-6D symbology. YOLOv8 by Ultralytics. PostgreSQL + PostGIS documentation. TAK Server documentation. Ukrainian Delta system analysis (open sources). Dempster-Shafer evidence theory (Shafer, 1976). FSG-A mathematical verification: python3 lisa26-proof.py (15 tests, all passing).