Implementing simple frequency hopping

Discussions related to modulation techniques, filtering, error correction and detection, wireless link layer implementations, etc

Moderator: robert.ghilduta

Post Reply
itay
Posts: 2
Joined: Tue Dec 30, 2014 12:42 pm

Implementing simple frequency hopping

Post by itay » Fri Jul 03, 2015 2:15 am

Hello guys,
I'm searching for any suggestion for implementing frequncy hopping between 4-5 totally diffrent frequencies via GNU radio?

Thanks,
Itay

jynik
Posts: 455
Joined: Thu Jun 06, 2013 8:15 pm

Re: Implementing simple frequency hopping

Post by jynik » Fri Jul 03, 2015 8:03 am

Hi there,

In the release posted just a few days ago, we added libbladeRF support for scheduled retuning and a "quick retune" capability. You can find more information about this in the libbladeRF API docs..

Eventually, I'll be looking to release an FSK modem example, and follow up example that introduces simple hopping to it. However, I'm working on it as time allows on the weekends, so it might be a while (hoping for late summer, but we'll see). It's all in C with no external dependencies (aside from libbladeRF), so I hope people will find it to be a fun and interesting example. Keep an eye on the nuand-papers releases repo later this summer.

You can find some boilerplate C code for starting a simple frequency hopping implementation in our tests directory: libbladeRF_test_scheduled_retune. This is just transmitting a tone and retuning. You can specify any number of hops in a text file, with one entry (e.g., 921.45M) per line. Starting with this, you could queue up samples to/from a mod/demod implementation. If you know your future hops ahead of time, I would advise you to schedule the first N hops prior to the first hop. Then, at each successive hop, you can enqueue a single future hop. This will ensure you have some wiggle room in terms of timing.

If you're working on something simple and do not have a hard requirement for GNU Radio, you may be interested in using liquid-dsp.

However, we have not yet submitted patches to gr-osmosdr regarding the use of timestamps and the functionality that is built atop of them: burst, scheduled retune, quick retune. We'll need to better evaluate the available interface and the de facto approach to frequency hopping in GNU Radio. If someone would like to essentially document/describe how they would like this functionality to be presented (e.g., through specific stream tags), that could help speed things along. We could bounce patches back and forth until we have something sufficiently robust and generic.


With all that said, you could just hop digitally... I envision you could do that with a custom block that mixes with a different sinusoid after seeing some stream tag.

Hope that helps,
Jon

itay
Posts: 2
Joined: Tue Dec 30, 2014 12:42 pm

Re: Implementing simple frequency hopping

Post by itay » Sat Jul 04, 2015 10:37 am

Thanks Jon,
This is realy helpful info.
Any useful information about dynamicly change of varible value while running? Can it be implemnted via the standanrt GNU radio blocks?

Thanks,
Itay

jynik
Posts: 455
Joined: Thu Jun 06, 2013 8:15 pm

Re: Implementing simple frequency hopping

Post by jynik » Sun Jul 05, 2015 5:50 pm

Hi Itay,

I think you could certainly implement a crude, slow-rate hopping by just periodically changing the frequency. Without the items I discussed previously, it will be a bit tough to synchronize the retune operation with the underlying stream of samples heading to/from the hardware. However, if you're generous with the time between your samples containing data and the retune request, you probably could get away with it. (If your end goal is something beyond a temporary project or learning exercise and needs to be robust, I'd encourage you to revisit the points in my previous post.)

The gr-osmosdr source and sinks have frequency accessors functions - so yes, you could call those. If you're using Gnu Radio Companion and have the frequency parameter assigned via a variable, GUI slider, etc., the frequency
will indeed change when that variable changes.

Best regards,
Jon

Post Reply