Full Duplex in BladeRF

[2011EE10487]

Does BladeRF support full duplex mode? I want to create a FM transmitter and receiver on a BladeRF a device. So can I receive and transmit from the same BladeRF device. Can someone post a sample flowgraph for full duplex application.

Thanks

[drmpeg]

Full duplex is supported, and there's also an internal loopback (so you don't have to externally connect TX to RX).

http://www.w6rz.net/loopback.grc



Ron

[2011EE10487]

I used your example but the output was not as I had expected. I'm attaching a video on the google link showing the output.
https://docs.google.com/file/d/0B5ZnEve ... 0xa0U/edit
I don't get what is wrong with it so if anyone can help me out with it.
Thanks

[drmpeg]

Should look something like this.



Make sure your bladeRF library and gr-osmocom are up to date. Loopback was added around 2/16/14.

Ron

[2011EE10487]

Seeing your plot I am confused why there is a peak at 429MHz. Could the problem in my case be because of high CPU usage? As I have the latest grosmosdr blocks.

Thanks

[drmpeg]

The spike in the middle is just the DC offset. You can mostly tune that out by adjusting the levels of the I and Q signals (so that they're centered on 0 in the scope plot).

http://www.w6rz.net/loopbackdc.grc





I've also reduced the sampling rate in case you're having performance issues.

Ron

[blagoja]

Hi Ron,

I have the following errors in osmocom Source block of yours loopbackdc.grc file. I'm using GNU Radio Companion 3.7.3.

Param - Ch0: Gain Mode(gain_mode0):
Expression "0" is invalid for type bool.

Param - Ch1: Gain Mode(gain_mode1):
Expression "0" is invalid for type bool.

Param - Ch2: Gain Mode(gain_mode2):
Expression "0" is invalid for type bool.

Param - Ch3: Gain Mode(gain_mode3):
Expression "0" is invalid for type bool.

Param - Ch4: Gain Mode(gain_mode4):
Expression "0" is invalid for type bool.

I noticed that you use GNU Radio Companion 3.7.4. Could this be the reason for the errors?

Thanks.

BR,
Blagoja

[jynik]

This same exact thing happened to me the other day, with flow graphs that had been behaving perfectly fine before. I'm not sure if it was the result of a GNU Radio upgrade or what.

At any rate the workaround for me was the following:

• Open the block properties
• In the pulldown for the number of channels, select the count of complaining channels (5 in your case)
• Scroll down through all the properties, and everywhere you see a "ChX Gain mode" (I think they'll be red to denote an errror) set to 0, click on the drop down and change it back to "Manual"
• After you've done this for all of the complaining channels, set the chanel count (from the second step) back to 1
• Click apply

Update: Ignore this...Olaf's suggestion is far better

[Olaf]

Delete osmocom source from Ron's flowgraph and drag a new one from Gnuradio menu...that solved the error in my case

[drmpeg]

I believe it's due to this fairly recent commit to gr-osmosdr.

http://cgit.osmocom.org/gr-osmosdr/comm ... 7d4202ab24

I had built the graphs with a version of gr-osmosdr before that commit.

Ron

[spyhound]

Is there a way to extract s-parameters?

[bpadalino]

Right now I can't think of a way to get the reflected power from the port.

I believe we could extract only the forward parameter, but not the rest of them.

I will keep thinking about it, though. Maybe with some external hardware, something can be figured out.

Brian

[spyhound]

Can someone produce a working example of measuring the amplitude and phase of a connected coax between Tx and Rx ports?

If it's possible, we could then attach a wideband directional coupler and calibrate to measure simple parameters like a connected antenna's reflection characteristics.