I developed a Frequency-Hopping Spread Spectrum (FHSS) system implemented in Python. The primary transmission hardware used was the HackRF One, though the system should be compatible with any SDR hardware capable of transmission.
My system operates by feeding a secret key combined with the current time into a SHA-256 hash function and taking a modulo of the resulting hash digest to select a frequency from a predefined list of buckets.
Initial testing involved three handheld radios tuned to three different frequencies. After configuring the FHSS transmitter script to utilize only these three buckets/frequencies, I transmitted a song that was audible on all three radios without issues. This demonstrated that without access to receivers on all three frequencies, one could not receive the entire broadcast. Furthermore, if one frequency was being jammed, approximately 2/3 of the broadcast would remain accessible.
For the next phase, rather than requiring multiple radios for each frequency bucket, I developed a receiver using an RTL-SDR dongle and a Python script that controls Gqrx to jump to the correct frequency at the appropriate time.
To test transmission and reception between separate devices, and since the only other available device was a Windows laptop, I also developed a simple SDR Sharp plugin to accomplish the same functionality.
One of the significant challenges in spread spectrum systems is synchronization. Without precise timing alignment, portions of the signal at the beginning and end of each window may be missed. This desynchronization can result from two primary factors: discrepancies between the clocks (or system times) of the transmitter and receiver, and processing delays within the radio software and hardware.
I developed a straightforward solution to address this synchronization issue. Consider a hopping time of 100 ms, indicating frequency changes every 100 milliseconds. If our frequencies are F1, F2, F3 in time slots T1, T2, and T3, respectively, then without special synchronization measures, during time slot T2, we would only be transmitting at frequency F2.
My approach for improving synchronization is as follows: During the first half (first 50 milliseconds) of time slot T2, we transmit the same signal on both F1 and F2. During the second half of time slot T2, we transmit our signal on both F2 and F3. This ensures that if our synchronization is off by less than half of the hop time, the receiver will still be able to receive the complete broadcast without missing any content.
The drawbacks of this approach include increased complexity, the requirement to transmit on multiple frequencies simultaneously (fortunately possible with the HackRF One), and essentially dividing the transmission power in half.
The latter point is particularly problematic when attempting to maximize transmission distance. If the complexity can be shifted to the receiver instead, a potentially superior approach might involve implementing something similar to a Phase Locked Loop or incorporating small, rapid “timestamp” data bursts to synchronize the receiver with the transmitter.
