History: Frequency Hopping Spread Spectrum Radio

Source of version: 24 (current)

After experiencing one too many days of jamming I decided to take matters into my own hands to reduce the impact of jammers by implementing a frequency hopping capability for my transceiver. Here's a screenshot of the app I wrote to solve this: {img src="tiki-download_file.php?fileId=96&display"} __You can {FILE(type="gallery",fileId="99")}download the app here{FILE}.__ It supports Yaesu CAT, ICOM CIV and Kenwood (unnamed protocol?). Three spreading sequences are implemented so far, a ramp (saw-tooth), a triangle where frequency bounces back and forth between specified limits and a hash where frequency jumps around the specified spectrum quasi-randomly. The software is an .exe file, but is written in portable .Net, and has been verified under mono for use on Linux and such. You'll need a PC with a highly synchronized clock (a few ms of error is OK). I suggest the following software: [http://www.meinberg.de/english/sw/ntp.htm#ntp_nt_stable|http://www.meinberg.de/english/sw/ntp.htm#ntp_nt_stable] On Linux/other platforms the default ntpd should work well enough. Here is a graphical representation of the Triangle sequence: {IMG(src="tiki-download_file.php?fileId=90&display")}{IMG} Here is a graphical representation of the Ramp sequence: {IMG(src="tiki-download_file.php?fileId=89&display")}{IMG} The large backwards frequency hop in the Ramp sequence can cause problems with PLL-based VFOs. DDS based VFOs are more appropriate for FHSS purposes. Here is a graphical representation of the Sequence Offset feature: {IMG(src="tiki-download_file.php?fileId=91&display")}{IMG} Here is a sample of the spectrum emitted by the software when Sequence=Hash is selected: {IMG(src="tiki-download_file.php?fileId=92&display")}{IMG} The hops are scattered according to a sequence that's 2^64 long, and modified by the Hash Key string input. Some challenges remain in operating this software. The main problem is how to accurately synchronize the stations' various time slots. The default timing (Hop Offset = 0) will bring you within overlap range so you can establish initial contact, but the fine-tuning afterwards is somewhat troublesome. The large sliders on the right hand side provide fine-grained control over time-aligning the hopping slots. If you're using a radio that has a different RX and TX delay, you may need to use a different Hop Offset value for RX and TX. This would mostly be useful in more than two-way conversations where everyone has to align to some reference. During two-way communication each party can simply leave the TX control @ 0 and adjust the RX control for best received signal of the remote station. When the software detects TX mode, it'll use the TX offset. When adjusting Hop Offset by ear it's hard to tell if the imperfect time slot overlap is at the leading or trailing edges of the slots. A possible solution might be to have a synchronization signal emitted by the software. An automated receiver might be able to auto-adjust the RX Hop Offset to center the synchronization signal within its own time slots. Sounds code-heavy though, and needs more hardware complication in the way of audio I/O. Also, .Net does not provide any audio services so this would mean a re-write in Java or something. NOTE: Yaesu CAT and Kenwood protocols have not been tested with any real radios. If you have one of these radios, please email me with your results! Correctness of PollStatus TX detection method is of particular interest. For Kenwood the reply packets will be rather large (38 bytes) so you may want to set your com link to 115.2kbps.

---