RFUAV: a benchmark dataset and two-stage pipeline for RF drone detection and identification

What RFUAV actually provides, and who it is aimed at

RFUAV is the official repository for a paper titled RFUAV: A Benchmark Dataset for Unmanned Aerial Vehicle Detection and Identification. The README describes a dataset of recordings from 35 different types of drones captured under high signal-to-noise ratio conditions, plus the raw data used to generate the spectral information. The stated audience is researchers working with RF data for drone analysis, and the README says they can apply the provided deep learning methods or use traditional signal processing such as decoding, demodulation and FFT. That framing matters. This is not a detector you deploy at an airport perimeter. It is a labelled corpus for comparing detection and identification methods under controlled conditions, with a reference pipeline attached so that a new lab does not have to rebuild the spectrogram conversion step from scratch. The README also notes that the dataset is compatible with USRP devices and GNU Radio for signal replay, which points to a second use case: generating over-the-air test conditions rather than only training on stored files.

The two-stage detection and classification design

The repository description states that the code includes a two-stage model to achieve drone detection and classification using FFT and STFT analytical methods. The README does not spell out the boundary between the two stages in prose, but the surrounding material makes the split legible. Detection means finding a drone signal inside a wideband capture, and the dataset documentation lists per-drone physical properties that a detector would key on: Frequency Hopping Signal Bandwidth, Frequency Hopping Signal Duration Time, Video Transmitted Signal Bandwidth, Frequency Hopping Signal Duty Cycle, and Frequency Hopping Signal Pattern Period. Identification means assigning that detected segment to one of the 35 drone types. The README shows an animated example of detecting drone signals and identifying drones directly on raw IQ data. What is not documented here is the architecture of the detection stage itself, the loss functions, or how the two stages are trained jointly. Anyone evaluating the method should read the arXiv paper rather than the README, because the README gives the dataset far more space than the model.

From raw IQ to spectrograms: the RawDataProcessor API

The concrete mechanism is a class called RawDataProcessor in the graphic package. It converts binary raw frequency signal data into spectrograms, with a MATLAB equivalent in check.m. The Python surface has four entry points. ShowSpectrogram visualises one data pack and takes a oneside parameter that controls whether the half-plane or full-plane spectrogram is drawn. TransRawDataintoSpectrogram batch-converts a directory of raw data into PNG images. TransRawDataintoVideo writes the spectrogram as a video for temporal inspection. A separate function, waterfall_spectrogram, produces a waterfall video with its own parameters: fft_size, fs, location and time_scale. The example calls use sample_rate=100e6 and Middle_Frequency=2400e6, which tells you the capture regime is wideband 2.4 GHz with a 100 MHz sample rate. The STFT point count varies between examples (2048 for the single-pack visualisation, 1024 for batch conversion), and duration_time is 0.1 seconds in every example shown. Those are the knobs that decide the time-frequency resolution trade-off, and the README does not recommend values beyond the examples.

SNR estimation and adjustment, and why that matters for a benchmark

A benchmark dataset is only useful if others can reproduce the conditions it claims. RFUAV addresses this with MATLAB tooling rather than Python. The README shows a two-step pattern: positionFind returns four indices plus f1 and f2 from the IQ data, the sample rate, a bandwidth parameter and an NFFT, and those outputs feed snrEsti to produce an SNR estimate. The awgn1 function then adjusts the noise level of raw signal data based on that estimate. The README states the signal-to-noise ratio can be adjusted between -20 dB and 20 dB, with a default step size of 2 dB, and that a custom scale can be defined. This is the most operationally interesting part of the repository, because it lets you degrade a high-SNR recording into a controlled low-SNR one and measure where a detector breaks. The catch is that this tooling lives in MATLAB, so a Python-only team either ports it or loses the ability to reproduce the SNR sweep.

Getting it running, and the models you can train

Installation is a single command, pip install -r requirements.txt, and the README lists two runnable scripts: python inference.py for drone classification inference and python train.py for quick training using ResNet50 on a small dataset. Custom training is PyTorch-based, and the supported model list as printed in the README includes ViT, ResNet, MobileNet, Swin Transformer, EfficientNet, DenseNet and VGG, with the list truncated in the material available here. That breadth is a deliberate design choice: the dataset is meant to be model-agnostic, so you can hold the data fixed and vary the classifier. The MATLAB path is separate and requires no Python at all: check.m takes data_path, nfft, fs, duration_time and datatype, with datatype set to float32 in the example. Note that the README does not document command-line flags for train.py or inference.py, so configuration appears to happen by editing the scripts or the files they read.

The data release condition is the main limitation

The README states plainly that the raw data will be free to use after the paper is accepted. That single sentence governs everything. Until acceptance, the repository ships code, figures and example animations, but the recordings from 35 drone types may not be downloadable, which means the training and inference scripts cannot be exercised end to end by an outside reader. The repository description also ends with a request to star it, which is a signal about project maturity rather than a technical detail. Beyond availability, there is a scope limitation worth naming: the recordings were collected under high SNR conditions, and the README does not claim they represent congested spectrum, multipath-heavy urban deployments, or interference from other 2.4 GHz traffic. The SNR adjustment tooling exists precisely because the raw captures are clean. A team looking for a detector that survives a noisy field environment is looking at the wrong artifact; this is a controlled benchmark, and its numbers will be optimistic relative to field conditions. Finally, there are no releases retrieved for this repository, so there is no versioned artifact to pin against.

How it compares with the obvious alternative

The natural comparison is to the DroneRF and DroneRFa style datasets, which also publish RF recordings of consumer drones with labels. The difference in approach here is breadth of drone types and the pairing of raw IQ with a conversion pipeline rather than pre-rendered spectrograms. That distinction has practical consequences. If a dataset ships only spectrogram images, you inherit the STFT parameters chosen by its authors and cannot re-derive features with a different window length. RFUAV's README shows the raw binary being processed at conversion time, with stft_point and duration_time exposed to the caller, so you can regenerate the time-frequency representation to suit a different model. The cost is that you must run the conversion yourself, and the repository gives you two implementations (Python and MATLAB) that are not guaranteed to produce identical output. For a team that only wants to benchmark a CNN on fixed images, a pre-rendered dataset is less work. For a team that wants to test whether detection performance depends on time-frequency resolution, raw IQ plus an exposed STFT is the more useful shape.

Maintenance, licence and what to verify before you build on it

The licence is Apache-2.0, which permits commercial use and modification provided you retain the notices and state changes, but this is a description of the licence text and not legal advice; if you plan to ship a product derived from the code, have counsel review the NOTICE and attribution requirements. Maintenance cost is hard to assess from the material. There are no tagged releases and the last push date is recent, so the project is active but unversioned, which means a git clone today may differ from a clone next month with no changelog to explain the difference. The dependency surface is a single requirements.txt, and the README does not pin versions. The MATLAB components add a second toolchain to maintain, and they cover the SNR estimation and adjustment path that the Python side does not appear to replicate. The realistic adoption cost is therefore not the pip install; it is porting the SNR tooling if you are Python-only, and validating that the spectrogram parameters in the examples produce features your model can actually learn from.

Editorial conclusion

Adopt RFUAV if you need labelled raw IQ from many drone models and are willing to build your own detection front end or adapt the provided two-stage code. Do not adopt it if you need a production detector today, because the repository is a research artifact and the README states the raw data will only be released after the paper is accepted. Before committing, verify the raw data release status on the repository, confirm the file sizes and SNR figures in the FSM figure against your storage budget, and check that your SDR front end can match the 100e6 sample rate used throughout the examples.

Official sources

1. Issues
2. kitoweeknd/RFUAV on GitHub
3. License: Apache-2.0
4. README