Levandor

Runbook: KrakenSDR direction-finding problems

5 min read

Access

Pi = 192.168.1.200 (ssh levander@raspi.local), tailnet node kraken-rig. Web UI: http://kraken-rig.taild4189d.ts.net:8080/doa (or kraken.telep.lan on-site) — the :8080 is REQUIRED. Autostart: krakensdr.service; switch modes with /usr/local/bin/kraken-mode {doa|pr|off}.

Symptoms — pick the one that matches

  • (a) “Power Level: Overdrive” / “Sample/IQ Sync: LOSS” / smeared or clipped signal.
  • (b) No signal at all.
  • (c) Wrong / ghost / mirrored bearings.
  • (d) Web UI won’t load, or app.py crashes on start.
  • (e) Pi randomly reboots / resets under load (looks like OOM).
  • (f) Kraken Pro app won’t connect in the field.

Diagnose → Fix by symptom

(a) Overdrive / sync loss / smeared signal → RF over-gain

"Overdrive" = ADC clipping from too much RF gain — NOT a weak PSU

Lower the RF gain in the DAQ config. A genuinely weak PSU shows up completely differently — as USB dropouts / tuner disconnects in dmesg, not overdrive. Don’t chase the power supply for this.

(b) No signal

  1. Check all 5 antennas are connected and the RF gain isn’t so low there’s nothing.
  2. Ignore the DC spike at the exact center frequency — RTL-SDR always shows a fake spike there. Offset-tune to tell a real signal from the artifact.
  3. If the target is 380–385 MHz (TETRA): it’s bursty uplink — dead air until a handset keys up. Not a fault. 🚫 Do not transmit on 380–385 MHz to test (emergency-services band) — test on a legal freq below the ambiguity ceiling and retune the Kraken to it.

(c) Wrong / ghost / mirrored bearings

  • The software array config must match the physical array (ant_spacing_meters), or bearings are meaningless. Current live rig: UCA, radius 0.20 m (200 mm template hole), MUSIC.
  • Spacing must be ≤ 0.5 λ. The current 200 mm radius (spacing 1.176 × 0.2 = 23.5 cm) is unambiguous across 382–434 MHz (KrakenSDR default s ≈ 0.33). The old 0.30 m geometry had a ~428 MHz ambiguity ceiling (35 cm spacing) — that ceiling is a fact about the old array; the fix was the 200 mm template hole, not a 25 cm rebuild. See 2026-08-26-raspi-oom-zram-hunter-ap-433-retune.
  • Bearings are relative to element #0 until Array Offset is calibrated against a known-direction source.

(d) UI won’t load / crash on start

  1. Confirm only one stack is running — DoA and PR both bind :8080; never both: 
    /usr/local/bin/kraken-mode doa      # stops the other stack, starts DoA
curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8080/
  2. ModuleNotFoundError: No module named 'dash_devices' = the conda env didn’t activate (silent over SSH/systemd). Source conda before the start script: 
    source /home/levander/miniforge3/etc/profile.d/conda.sh && conda activate kraken
  3. DAQ won’t sync (“Shared memory not exist” loop) = stale /dev/shm buffers from a prior broken start: 
    rm -f /dev/shm/decimator_in* /dev/shm/decimator_out* /dev/shm/delay_sync_*
  4. kraken.telep.lan 502 from another machine just means the Pi is offline — see host-offline. If the Pi crashed / won’t boot: it’s a 2 GB Pi 5 and the DAQ is memory-heavy → OOM crashes (mitigated by zram swap since 2026-08-26). A headless Pi that won’t boot is often just the SD card unseated — reseat it before assuming corruption. See 2026-08-26-raspi-oom-zram-hunter-ap-433-retune.

(e) Random reboots / resets under load → power brownout (NOT OOM)

The Pi 5 + KrakenSDR DAQ browns out on 5V/3A

A generic PD-30W supply does NOT help — the Pi only draws 5V, so PD-30W still delivers 5V/3A. Use a real 5V/5A source. Verify stable: vcgencmd get_throttled should read throttled=0x0 under load (and usb_max_current_enable auto-flips to 1). Most of the earlier “OOM crashes” were actually these brownouts. Car: 12V→5V/5A buck + usb_max_current_enable=1; give the Kraken and phone their OWN feeds (Kraken is self-powered via its own USB-C). See 2026-08-26-krakensdr-field-test-milestone.

(f) Kraken Pro app won’t connect in the field

  1. iPhone must be on the Pi’s AP: SSID hunter-ap / pass huntme123 (Pi = 10.42.0.1). The Kraken Pro app HAS an iOS build; run it in LOCAL mode with server IP 10.42.0.1.
  2. Test the network path first: from iPhone Safari load http://10.42.0.1:8080/doa. If the DoA UI renders, the AP + server are fine — the fault is in the app config, not the network.
  3. Config must have doa_data_format = "Kraken App" (and the krakenpro_key set). The app uses the phone’s own GPS — no gpsd/puck/tether needed for the map.

Deeper causes / links

  • Full rig reference (hardware quirks, from-source install, dependency pins, autostart, array recipe, verified end-to-end run): 2026-08-12-krakensdr-doa-rig.
  • The Kraken is 5× RTL2838 behind an internal USB hub — no serial/CH340; noise-source cal runs over tuner GPIO via the krakenrf librtlsdr fork. Don’t go hunting for a serial port.
  • Same Pi runs wifi-hunter (the wlan0 “Hotspot” AP is its, not a firewall bug).

Graph View

Backlinks