I/Q Data Question

Discussions related to schematic capture, PCB layout, signal integrity, and RF development

Moderator: robert.ghilduta

Post Reply
Firehawk78
Posts: 2
Joined: Mon Jul 21, 2014 9:54 am

I/Q Data Question

Post by Firehawk78 » Mon Jul 21, 2014 8:08 pm

Is the data showing changes in magnitude (or amplitude) and phase of received signals available using a bladeRF? If so, what is the best way to access it?

Thanks,
Brian

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

Re: I/Q Data Question

Post by jynik » Wed Jul 23, 2014 7:57 pm

Hi Brian,

The sample data sent to and received from the bladeRF are IQ components. There are some links to a couple good articles on the topic of quadrature signals on the wiki.

As far as the "best way" to receive and transmit samples, I'd say the answer is largely dependent on what you're ultimately looking to do and what tools and skills you have at your disposal. As it's a broad question with lots of possible answers, I'll do my best to provide a broad answer, with some hope that my thoughts here can be re-used this when writing up more documentation in the near future.

I hope you'll find something here useful. Without further ado, here's a classic "long-winded jynik answer!"

libbladeRF
The primary way to interact with the device programmatically via a host machine is through libbladeRF, which has a C API. I haven't had time to test drive it lately, but I know michelp is working on bladeRF Python bindings.

So if you want to write C code, you'll want to take a look at the libbladeRF API docs. More specifically, you'll want to look at the synchronous data transmission and reception functions.

I will be committing a better description of the "SC16Q11" format described in the aforementioned docs soon. For now, here's a quick copy/paste of the patch:

Code: Select all

/**
* Signed, Complex 16-bit Q11. This is the native format of the DAC data.
*
* Values in the range [-2048, 2048) are used to represent [-1.0, 1.0).
* Note that the lower bound here is inclusive, and the upper bound is
* exclusive. Ensure that provided samples stay within [-2048, 2047].
*
* Samples consist of interleaved IQ value pairs, with I being the first
* value in the pair. Each value in the pair is a right-aligned,
* little-endian int16_t. The FPGA ensures that these values are
* sign-extended.
*
* When using this format the minimum required buffer size, in bytes, is:
* <pre>
* buffer_size_min = [ 2 * num_samples * sizeof(int16_t) ]
* </pre>
*
* For example, to hold 2048 samples, a buffer must be at least 8192 bytes
* large.
*/

bladeRF-cli
bladeRF-cli is program built atop libbladeRF. It is primarily intended as a development and debugging tool that exposes libbladeRF functionality in a command-line interface. You can use this to configure the device, as well as transmit/receive samples to CSVs or binary files.

Generally, I use bladeRF-cli in conjunction with Octave.

For example, to receive a ~2 seconds of data to a CSV file:

Code: Select all

$ bladeRF-cli -i
bladeRF> set samplerate rx 1M

  Setting RX sample rate - req:   1000000 0/1Hz, actual:   1000000 0/1Hz

bladeRF> rx config file=~/Desktop/samples.csv format=csv n=2M
bladeRF> rx start
bladeRF> rx wait
bladeRF> quit
Then, I'll read in the samples into Octave to analyze them further. For example, he's a few commands to read in the above CSV and plot the magnitude of a signal over time.

Code: Select all

octave> samples = load('/home/jon/Desktop/samples.csv');
octave> signal = (samples(:,1) + i * samples(:,2)) ./ 2048.0;
octave> magnitude_db = 20 * log10(abs(signal));
octave> num_points = size(magnitude_db)(1);
octave> samplerate = 1e6;
octave> time = linspace(0, num_points - 1, num_points) ./ samplerate;
octave> plot(time, magnitude_db);
octave> xlabel('Time (s)')
octave> ylabel('dB')
octave> title('OOK signal from a 433MHz temperature sensor')
octave> axis([0 1.25 -30 0])
Below is a plot from some captured samples being transmitted by this wireless thermometer:
Image

FWIW, it looks more like this after a little more work in Octave (it's very zoomed in, x axis is in units of samples @ 1Msps):
Image



GNU Radio

The bladeRF interfaces with GNU Radio via gr-osmosdr. With GNU Radio, you can quickly connect and configure various modules in order to generate, transmit, receive, (de)modulate and process signals. GNU Radio Companion presents a GUI for doing this.

There's a bunch of awesome projects and example flowgraphs out there already, so I won't continue on this point. He's one example posted on this forum.



Other software
There's a bunch of other cool software that you'll see people chatting about around here. Here's just a few that provide the ability to listen to demodulated audio, among other neat features... my apologies if I've forgotten anyone's favorite program.
For more info, be sure to have a look around the bladeRF wiki and these forums.

Firehawk78
Posts: 2
Joined: Mon Jul 21, 2014 9:54 am

Re: I/Q Data Question

Post by Firehawk78 » Thu Jul 24, 2014 9:34 am

jynik,

Thank-you very much for that VERY detailed reply! I agree, it was a very open-ended question. Your response has answered my question and given me much more information to consider!

Thanks again!
Brian

User avatar
sophiekovalevsky
Posts: 1
Joined: Fri Aug 04, 2017 8:12 am

Re: I/Q Data Question

Post by sophiekovalevsky » Fri Aug 04, 2017 9:23 am

Hello everyone!

There is something that I do not still understand about the IQ samples coming off from the bladeRF. I am taking measurements with the device but I have seen in this thread and in other sources that, most of the time, what you get are normalized samples. However, this measurements are not telling you how much power you are getting, this is why:

If we have the ADC with a 12 bit resolution. We will obtain values between [-2048, 2047] this is okey. But, what is the equivalent in terms of voltage of these values? What I mean by that is that I need to have what are the voltage values that the bladeRF is receiving. This can be done if I know what is the reference voltage that the ADC is using to create the steps. I took a time to analyze the datasheet of the LMS but I am not able to find out what reference votlage they are using.

How this can be approached?

txjacob
Posts: 19
Joined: Fri Apr 14, 2017 10:12 am

Re: I/Q Data Question

Post by txjacob » Fri Aug 04, 2017 7:42 pm

sophiekovalevsky wrote:
Fri Aug 04, 2017 9:23 am
Hello everyone!

There is something that I do not still understand about the IQ samples coming off from the bladeRF. I am taking measurements with the device but I have seen in this thread and in other sources that, most of the time, what you get are normalized samples. However, this measurements are not telling you how much power you are getting, this is why:

If we have the ADC with a 12 bit resolution. We will obtain values between [-2048, 2047] this is okey. But, what is the equivalent in terms of voltage of these values? What I mean by that is that I need to have what are the voltage values that the bladeRF is receiving. This can be done if I know what is the reference voltage that the ADC is using to create the steps. I took a time to analyze the datasheet of the LMS but I am not able to find out what reference votlage they are using.

How this can be approached?
I looked at the schematic for the BladeRF and it looks like they're running it at 3.3 V for the receiver size. So it looks like 0.8 mV per bit.

Post Reply