SDR distributed direction finding

This is one of the options for the remote SDR project.

The plan is to synchronize multiple widely spaced SDR/pi combos through a central server to implement direction finding through several methods. Internet connectivity helps, but hamnet or local wifi may also work.

Target implementation language: julia

Direction finding methods

• (phase 1) range circles determined by signal strength and antenna height (simplest method)
• (phase 2) DF by time difference of arrival [1]
• other DF methods [2]

Implementation tasks

(1,2,3 indicates implementation phase, to help prioritization)

• 1 julia / rtl-sdr API code (may be expanded)
• 1 UI to inject commands (any or all of gui, cli, web)
• 1 Pi/sdr/antenna network
• 1 Network protocol
• 1 Pi client software
• 1 Server software: dispatcher
• 1 DF by proximity and coverage circles
• 1c Aprs xmitter
• 1c Map software
• 1d,2d Portable server w/WiFi
• 2 Fcc db filtered (Postgres)
• 2a Server software: frequency search and manager
• 2b broadcast beacon scan / strength detect
• 2b Server software: df by TDOA (xlate and rewrite matlab demo code to julia partly done)
• 3 Software: voice recognition and call extraction
• 3 Software: tx id fingerprinting

Network protocol features

Implementation philosophy:

• initial registration via http / https : exchange stats, negotiate ports
• retain connection via tcp (if firewall allows) or udp (with keep alive)
• if tcp connection is available, all communication except live capture is done via tcp
• new tcp conn from old client starts with id, time, hash(id+time)
• all udp packets after first start with ID+time+hash(cookie+id+time+data) (packet id is time)
• captured samples are sent via tcp or http post (except over RF?)
• all udp packets (except ack and live sample) require ack (if hash is ok) ack=id+(acktime)+hash
• report stats during capture?
• upload samples via http (requires prior registration to prevent DoS)
• Server listens on tcp/udp
• Http bridge to local server; commodity http server relays data to synchronizing server around firewall
  • use http to set up intial udp connection
  • use udp for low latency direct connect
  • use http for large posts of data (<10G?) when using udp
  • use non-http tcp (with keepalive) when possible for constant connection

Network protocol commands and data payloads:

• STAT/HELLO exchange: ID, (cookie), system stats, proto versions, location
• SETLOC set location to (gps) (server->client after calibration sample)
• SETTIME set time? / request time (against calibration sample?)
• CAP1 schedule single capture: sample ID, frequency, time, duration, trigger (immediate, time, signal strength; tx fingerprint, voice fingerprint, voice command), mode (I/Q, FMn, FMw, ??), target port
• CAP2 schedule dual capture: sample ID, freq1 freq2 time duration2(?) trigger
• CAPCAL calibration capture: sample ID, list of freqs to capture; fixed sample length for each
• LIVECAP live capture (freq, mode, duration, target port) ; repeated commands with same values extends duration, any other sample command cancels live capture, no ack expected for samples
• POSTCAP post capture sample: sample ID, length (via tcp/http only)
• BQUERY Query beacon db (client/server exchange), filter criteria (location, distance? height?), returns info about beacons from FCC database and/or local data

Phase 3

• Voice recognition to extract call signs
  • FM to text using google speech recognition libraries
  • Mozilla speech recognition
  • CMUSphinx
  • Others: [3], wikipedia:List of speech recognition software
• Tramsmitter identification
  • by power attack and decay curves
  • CTCSS fingerprinting
  • voice fingerprinting
• Advanced triggering
  • trigger on any strong signal on a frequency?
  • database of transmitters to trigger on (via identification methods)
  • voice command recognition

Security concerns

• Unauthorized clients could attempt to inject bad data
• Authorized clients could inject corrupt data
• Unauthorized clients could attempt buffer overruns
• Unauthorized clients could attempt to impersonate authorized clients
• Unauthorized clients could attempt to extract sensitive data

Results

• first attempt at data collection [4]
  • images, poor sensitivity, SNR works for broadcast anyway

Other external links and applications

• http://www.panoradio-sdr.de/tdoa-transmitter-localization-with-rtl-sdrs/
  • https://github.com/DC9ST/librtlsdr-2freq
  • https://github.com/steve-m/kalibrate-rtl
  • https://github.com/DC9ST/rtl-sdr-data-read (matlab code to read I/Q data)
  • https://github.com/DC9ST/tdoa-evaluation-rtlsdr (matlab TDoA)
• https://www.rtl-sdr.com/locating-various-hf-transmitters-and-number-stations-with-kiwisdrs/
  • update: https://www.rtl-sdr.com/kiwisdr-tdoa-direction-finding-now-freely-available-for-public-use/
• https://github.com/AD-Vega/rtl-power-fftw
• https://github.com/dressel/RTLSDR.jl replaced with local code
• lightning detection
• TXID fingerprinting
  • wikipedia:Radio fingerprinting
  • https://www.youtube.com/watch?v=_dV4gLlGbq0
  • https://ham.stackexchange.com/questions/9436/key-cw-on-zero-crossings-zero-bandwidth/9445#9445
  • https://forums.qrz.com/index.php?threads/txid-transmitter-fingerprinter.130769/
• Intro to RTL-SDR, Part II - Software