Skip to content

Zone Fingerprinting Demo

The Zone Fingerprinting Demo uses a trained ONNX model to identify which enrolled device is currently transmitting, in real time, by analysing the unique RF characteristics of each device’s signal.

Every radio transmitter has subtle hardware imperfections — slight frequency offsets, non-linearities, and noise floor signatures — that act like a fingerprint. A model trained on enough labelled captures of a device can learn to recognise it even when the modulation scheme or channel conditions change. The demo puts that capability in front of a live SDR feed and shows you detections as they happen.

Use the Zone Fingerprinting Demo when you want to:

  • Verify that a trained fingerprinting model correctly identifies known devices in a live RF environment
  • Demo authorised/unauthorised device detection in a controlled space
  • Tune detection sensitivity and test the optional protocol detector before deploying a production system
  • Monitor which enrolled devices are active and when

The demo runs in three phases:

  1. Enrol devices — define the set of known transmitters and their IDs
  2. Load and configure — select the ONNX model, configure the SDR, and optionally add a protocol detector
  3. Live inference — watch detections stream in with confidence scores, SNR, and authorisation status
  • ria-toolkit-oss — Install the Conductor backend: pip install ria-toolkit-oss
  • Trained ONNX model — A .onnx fingerprinting model stored in a RIA Hub repository (typically produced by the Training Dashboard)
  • SDR hardware — A supported device (PlutoSDR, USRP B210, or HackRF) connected to the RIA Hub server or a registered remote agent. Use mock mode to test without hardware.

Enrolled devices are the set of known transmitters your model has been trained to recognise.

Click Conductor in the top navigation, then select Zone Fingerprinting Demo.

The Enrolled Devices table on the right shows the devices currently on file for your selected repository. Each entry has:

  • Device ID — must match the IDs used during training
  • Display name — human-readable label shown in the detection log
  • Protocol — WiFi, Bluetooth, or Other

Click Manage to open the device editor. From here you can add rows, remove devices, and save the updated list back to the repository. Changes are committed to .ria/enrolled_devices.json in your repo.


Phase 2 — Load the model and configure the SDR

Section titled “Phase 2 — Load the model and configure the SDR”

By default, inference runs on the RIA Hub server itself. To run on a remote agent, select it from the Target Node dropdown. All subsequent inference requests are routed to that node.

Under Model Configuration, choose how to provide the model:

Repo picker (recommended)

  1. Search for the repository containing your .onnx file
  2. Select the file — the dashboard automatically peeks the model’s embedded metadata
  3. If the model contains an embedded label map (a mapping of device ID → class index), it is detected and applied automatically

Local path

Enter the absolute file path to an .onnx file on the controller machine. Use this when the model is pre-downloaded or stored outside of a repository.

The label map tells the inference engine which output class corresponds to which device ID. Format:

{"iphone13_wifi_001": 0, "pixel7_wifi_002": 1, "noise": 2}

If the model’s metadata contained an embedded label map, this field is pre-filled. Otherwise, enter it manually — it must match the class indices your model was trained with.

Enable the Protocol Detector toggle to add a second ONNX model that gates fingerprinting on whether a signal of the expected protocol is actually present. This reduces false positives when the band is quiet.

Configure it the same way as the fingerprinting model, then set the sensitivity threshold (0.5–0.95). A lower threshold makes the detector more aggressive — it triggers on weaker signals.

ParameterDescription
DeviceSDR model: plutosdr, usrp_b210, hackrf, or mock (software simulation)
Center frequency (Hz)RF frequency to monitor (e.g., 2450000000 for 2.45 GHz)
Sample rate (Hz)Samples per second (e.g., 10000000 for 10 MSPS)
Gain (dB)Receiver gain, 0–76 dB

Click Load & Start. The dashboard loads the model(s) onto the target node, then starts the SDR feed and inference loop. A pulsing Inference Running indicator confirms the pipeline is active.


The large status indicator shows the current detection state:

ColourMeaning
Green (pulsing)An enrolled, authorised device was detected
RedAn unrecognised transmitter detected — not in the enrolled list
GreyNo signal activity above threshold

The label below shows the detected device name and confidence percentage.

Displays the estimated SNR of the most recent detection in dB. Use this to check that the SDR is receiving a usable signal — very low SNR (below ~5 dB) suggests a gain or antenna issue.

The SDR Settings panel lets you change centre frequency, sample rate, and gain without stopping inference. Changes take effect immediately.

The Detection Sensitivity slider controls the confidence threshold above which a detection is logged to the event table. Raise it to reduce noise in the log; lower it to catch weaker detections.

Scan mode:

  • Continuous — inference runs on every incoming chunk
  • On-demand — inference is triggered manually (useful for debugging or low-power scenarios)

Every detection above the confidence threshold is appended to the events table with:

  • Timestamp
  • Device ID and display name
  • Protocol
  • Confidence percentage
  • Authorised / Unauthorised flag

The log holds the last 50 events. Click Clear to reset it.

The Enrolled Devices table updates in real time — a device row turns green when that device has been detected within the last few seconds.

Click Stop Inference to end the session. The SDR connection is released and the inference process stops. Model configuration is preserved so you can restart quickly.


  • Collect more data — Use Campaign Control to run a new capture campaign and expand the training set, then retrain via the Training Dashboard.
  • Review recordings — Inspect captured signal quality in the Library before committing them to a curation run.