Fast sweep through libbladeRF

Discussions related to embedded firmware, driver, and user mode application software development

Moderator: robert.ghilduta

Post Reply
SamD
Posts: 6
Joined: Sun Nov 12, 2017 10:55 pm

Fast sweep through libbladeRF

Post by SamD » Wed Nov 15, 2017 4:25 am

Hi,

I'm interested in the fast sweep functionality (see https://www.nuand.com/blog/large-bandwidth/). I'm not sure how I'm supposed to do it though.

It seems with the recent libs BLADERF_TUNING_MODE_FPGA is the default mode. The comments on bladerf_sync_rx specify that the max bandwidth is 28MHz. Should I then use bladerf_schedule_retune x times, to schedule x retunes one after the other?

An example in the wiki would be greatly appreciated.

Thanks.

SamD
Posts: 6
Joined: Sun Nov 12, 2017 10:55 pm

Re: Fast sweep through libbladeRF

Post by SamD » Wed Nov 15, 2017 11:23 pm

I found an example about the quick tune in quick_tune.c but it's not directly an example about the fast sweep as it uses BLADERF_RETUNE_NOW and no receiving code is shown.

Looking at bladerf_source_c.cc in gr-osmosdr, I have a better idea of how it's supposed to be used. Indeed it calls bladerf_schedule_retune and schedules several returnes in advance (6 at first, then it adds a new one each time it processes a new batch, and resets it to 3 if the code is lagging behind compared to the current timestamp).

It's not using the quick tune parameter though (even if it creates and fills the quick_tunes array). I guess it's because of
bladerf_get_quick_tune
This allows for a faster retune, with a potential trade off of increased phase noise.
Note that these parameters are sensitive to changes in the operating environment,
and should be "refreshed" if planning to use the "quick retune" functionality over a
long period of time.
Maybe it's no big deal as we're scheduling the tunes in the future? Or should we use the quick retune parameters and refresh them from time to time (but what would be a "good" time)?

There's a few things I still don't understand. The run_quick_tune function is always called with the center frequency and num = 3 which leads to frequencies containing 3 frequencies, the center one, then one shifted 14MHz left and one 14MHz right. Then when schedule_another is called, bladerf_schedule_retune will be called with one of those 3 frequencies.

It looks to me that we end up jumping 3 frequencies, 14MHz apart. We get 32768 samples each time (NUM_SAMPLE is a constant) at 40MS/s (ioctl seems to enforce it).
  • Why 3 frequencies (and not something depending on the requested bandwidth)
  • why 14MHz apart and not 28Mhz
  • and why 32768 samples (a trade-off between speed and resolution? but shouldn't it depend on the bandwidth too?)
Some explanations on the code would be appreciated.

It also looks like 6 schedule_another are called, whether ssa_mode is true or false.

Concerning the resolution bandwidth, I guess I can control it easily by using bladerf_set_bandwidth, bladerf_common::set_sample_rate and then choosing the number of samples I want in bladerf_sync_rx.

Post Reply