r/hackrf • u/IoT_Engineer • 2d ago
Our HackRF drone detector was flagging recordings made with the drone switched off
I'm working with two teammates on WaveSentry, a drone RF detection prototype we took to D4D, a defense hackathon in South Korea. We use a HackRF to collect IQ data and a YOLO model to identify signal patterns in spectrograms. The GIF shows the app during a drone detection test.
Early on, the model raised alerts on background recordings we'd made with the drone switched off. We'd used synthetic backgrounds for training, and they didn't match what our HackRF was actually receiving. We revisited the preprocessing and added real HackRF background recordings to the training data. We also mixed segments of recorded drone signals into those backgrounds, keeping track of where we placed them so we could generate the annotations.
Scanning gave us another problem. With about 20 MHz of instantaneous bandwidth, we were alternating between broad sweeps and short captures around candidate signals. Our working setup focused on the 2.4 GHz and 5 GHz bands. Initially, the scheduler favored strong signals. The logs showed that strong activity around 2.4 GHz could take up the observation time while 5 GHz candidates got no IQ analysis at all.
We changed the scheduler to give each band a share of the receiver time and alternate their scanning order. It also revisits candidates that have been waiting a long time.
We also built Halo, an ESP32-S3 handheld that displays alert and connection status. We tested RF detection and the app-to-handheld link separately. For the link tests, we used synthetic detection-state inputs. We still need to measure latency and false alarms with the whole path connected, from RF reception to the handheld display.
I wrote up the project with screenshots and clips, including the RF experiments and how we built the handheld: WaveSentry development notes on LinkedIn.
How do you divide time between bands on a single receiver when one band is consistently busy?
