scan multiple channels

Discussions related to embedded firmware, driver, and user mode application software development
Post Reply
podreber
Posts: 1
Joined: Fri Jul 03, 2015 9:41 am

scan multiple channels

Post by podreber »

I am new to bladeRF and want to use it to achieve a higher receive bandwidth than 28MHz.
My setup is on Ubuntu 14.04.02 LTS using GR/GRC tools.
I looked at osmosdr source block but it only supports one channel at upto 28MHz.

I propose to write a source block in GRC to support 4 channels at 25Mhz each. The four outputs of this block will each have FFT block and combiner block to show 100MHz spectral analysis graph.

I propose to sequence these API calls:
1) set bw and set freq
2) enable module (TRUE for rx path)
3) sync_config
4) sync_rx
5) enable module (FALSE)
6) repeat from step 1 for remaining channels.
7) repeat from step 1 forever.

Questions are:
- will this work?
- What is estimated time to re-configure and get valid samples for next channel?
- How to know, deterministically, that freq/bw have been locked and valid samples are being provided?
- Can above sequence be simplified by leaving rx path enabled and just re-configuring bw/freq? Then how would I know when samples are invalid and should be discarded?

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

Re: scan multiple channels

Post by jynik »

Hi Sylvester,

I think my comments regarding the new scheduled retuning features in this thread are quite relevant to your questions. In particular, the tuning page in the API docs should provide you with some ideas.

As noted in that aforementioned thread -- the functionality is now present in the API to achieve this. However, mapping that functionality into the gr-osmosdr interface will be an additional set of tasks that haven't been started yet. (Patches and suggestions welcome!)

With respect to your proposed sequence and questions:

Will this work?

Yes, but probably with your desired performance. If your bandwidth is fixed for all the same frequencies, you don't need to keep setting it.

By setting up and tearing down the stream, you do help avoid getting "stale" samples from a previous frequency. However, you don't need to tear down the stream, as I'll touch in the following answers.

What is estimated time to re-configure and get valid samples for next channel?

This will ultimately depend upon how far your retunes are, and you now have a couple options, as described in the API docs. If you want more accurate tuning with less phase noise, may be you could go for the normal "scheduled retune" option. If not, you could evaluate how well the "quick_retune" functionality suits your needs.

In addition to that API docs page, I would highly encourage you to look at and experiment with (e.g., modify for your desired frequencies) the following test programs:
How to know, deterministically, that freq/bw have been locked and valid samples are being provided?
Can above sequence be simplified by leaving rx path enabled and just re-configuring bw/freq? Then how would I know when samples are invalid and should be discarded?


Unfortunately, we don't have a "locked at time T!" mechanism that can be sent back in metadata. However, what you're looking to do should still be very do-able. I think it all comes down to how quickly you want to retune and how much "wiggle room" you'll allow to ensure you have valid data.

First, you could determine your current timestamp by...
  • Using the API function to read the current RX timestamp
  • Guessing "worst case" current timestamp, given the timestamp you just RX'd from the sample metadata, and assume you have your maximum number of buffers already containing samples.
Based upon the test experiments I suggested above, you can get a pretty good idea of the upper bound on the retune time. Bear in mind that those test do include USB overhead, so I'd expect those should provide ample "wiggle room."

Knowing these values, you can schedule a retune in the future via the bladerf_schedule_retune() call. Given what you know to be an upper bound on the retune times, you can then schedule an RX to be N samples after that retune request. This will inherently throw away samples before the specified timestamp.

Hope that helps,
Jon
Post Reply