Implementing simple frequency hopping

Discussions related to modulation techniques, filtering, error correction and detection, wireless link layer implementations, etc
Post Reply
itay
Posts: 2
Joined: Tue Dec 30, 2014 12:42 pm

Implementing simple frequency hopping

Post by itay »

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 »

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 »

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 »

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
alexlitv
Posts: 1
Joined: Thu Aug 04, 2016 5:52 am

Re: Implementing simple frequency hopping

Post by alexlitv »

Hi !
I want to try libbladeRF_test_scheduled_retune.exe .
What meaning [device str] in command line?
device serial?
libusb instance ?


Thanks in advance
Alexander
User avatar
rtucker
Posts: 77
Joined: Sun Jan 25, 2015 10:38 am

Re: Implementing simple frequency hopping

Post by rtucker »

It's looking for a device string. If you only have one device, it may be omitted. If you have more than one connected, you may select between them using the -d parameter, e.g.:

Code: Select all

rtucker@rho:~$ bladeRF-cli -d *:instance=0 -e info

  Board:                    bladerf1
  Serial #:                 [redacted]
  VCTCXO DAC calibration:   0x9004
  FPGA size:                115 KLE
  FPGA loaded:              yes
  USB bus:                  4
  USB address:              17
  USB speed:                SuperSpeed
  Backend:                  libusb
  Instance:                 0

rtucker@rho:~$ bladeRF-cli -d *:instance=1 -e info

  Board:                    bladerf2
  Serial #:                 [redacted]
  VCTCXO DAC calibration:   0x1ffc
  FPGA size:                Unknown
  FPGA loaded:              no
  USB bus:                  4
  USB address:              16
  USB speed:                SuperSpeed
  Backend:                  libusb
  Instance:                 1
Here's the options:
The general form of the device identifier string is;

Code: Select all

<backend>:[device=<bus>:<addr>] [instance=<n>] [serial=<serial>]
An empty ("") or NULL device identifier will result in the first encountered device being opened (using the first discovered backend)

The 'backend' describes the mechanism used to communicate with the device, and may be one of the following:

*: Any available backend
libusb: libusb (See libusb changelog notes for required version, given your OS and controller)
cypress: Cypress CyUSB/CyAPI backend (Windows only)

If no arguments are provided after the backend, the first encountered device on the specified backend will be opened. Note that a backend is required, if any arguments are to be provided.

Next, any provided arguments are provide as used to find the desired device. Be sure not to over constrain the search. Generally, only one of the above is required – providing all of these may over constrain the search for the desired device (e.g., if a serial number matches, but not on the specified bus and address.)

device=<bus>:<addr>: Specifies USB bus and address. Decimal or hex prefixed by '0x' is permitted.
instance=<n>: Nth instance encountered, 0-indexed
serial=<serial>: Device's serial number.
source: bladerf_open() documentation at https://www.nuand.com/bladeRF-doc/libbl ... a59cdb6a24
Rey Tucker (she/her)
Systems Engineer, Nuand LLC
Rochester, NY, USA

#WontBeErased
Post Reply