problems transmitting with bladerf x115

[belza]

Hi, I am new with blade boards but I have a couple of years working with USRPs
I have a bladerf x115. When the board is receiving, it seems to work properly(tested with fft app) but when the board is transmitting for example using osmocom_siggen.py, I always have only a pulse at the channel frequency independently of the type of signal trnsmitted. In the case of a sine wave transmitted, the pulse frequency does not depend on the sine frequency. It is always a pulse at the channel frequency.
Thank you for your help.

Best regards, Pablo

[bpadalino]

I am not quite sure I understand what you're describing.

What do you mean by a pulse? Can you capture a diagram or picture of what you mean?

Sorry for my confusion.

Brian

[belza]

Excuse me for my question that it was not clear enough.
I only see a peak at the channel frequency as if I were transmitting a sine with the channel frequency.

[bpadalino]

Oh, I see. You're only seeing the LO leaking and you aren't actually seeing your signal of interest being sent out.

What is the exact command you're using to invoke osmocom_siggen.py and what is the output to the console? Please add to your device string "verbosity=verbose" so we can see what is happening with the library if you don't mind.

Brian

[belza]

Hi,
I have tried running $ osmocom_siggen -v
and I get the following error:

linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.008.000-14-ga90a6af0

gr-osmosdr v0.1.4-2-g8d9e6b58 (0.1.5git) gnuradio 3.7.5.1
built-in sink types: uhd hackrf bladerf
[bladeRF sink] Using nuand LLC bladeRF #0 SN e2f3...3c99 FW v1.8.0 FPGA v0.1.1
Traceback (most recent call last):
File "/usr/local/bin/osmocom_siggen", line 492, in <module>
if __name__ == "__main__": main()
File "/usr/local/bin/osmocom_siggen", line 468, in main
tb = osmocom_siggen.top_block(options, args)
File "/usr/local/lib/python2.7/dist-packages/osmosdr/osmocom_siggen_base.py", line 141, in __init__
self._setup_osmosdr(options)
File "/usr/local/lib/python2.7/dist-packages/osmosdr/osmocom_siggen_base.py", line 204, in _setup_osmosdr
gain_names = self.src.get_gain_names()
File "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/top_block.py", line 101, in __getattr__
return getattr(self._tb, name)
AttributeError: 'top_block_sptr' object has no attribute 'src'

Moreover, and just to be precise with the problem at hand, the peak at the center frequency is only visible (from another PC which acts as a spectrum analyzer) only after siggen is running. By the way, even if I close siggen, the peak is still there, and only disappear if I unplug the bladeRF from the USB socket.
Thank you very much for your help.
Regards.

[jynik]

That AttributeError you are running into has been reported to one of the maintainers.

It appears to only occur when using the -v option. Could you try running without that option and reporting back?

UPDATE:
A fix for this has been commited to gr-osmosdr in da27f3fb0a614c2cb9f5f867be8df77f53058f28. I have confirmed that this does address the issue that you're seeing.

[belza]

Hello,
I have updated my osmocom-sdr as instructed. Here is the output:

$ osmocom_siggen -v
linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.008.000-14-ga90a6af0

gr-osmosdr v0.1.4-4-gaa4094b3 (0.1.5git) gnuradio 3.7.5.1
built-in sink types: uhd hackrf bladerf
[bladeRF sink] Using nuand LLC bladeRF #0 SN e2f3...3c99 FW v1.8.0 FPGA v0.1.1
VGA1 gain range: start -35 stop -4 step 1
VGA2 gain range: start 0 stop 25 step 1
Supported sample rates 160000-40000000 step 40000.
Using auto-calculated mid-point frequency
Set center frequency to 2050000001.0
Using frequency corrrection of 0.0
Set frequency correction to: 0.0
Set baseband modulation to: Sinusoid
Modulation frequency: 0Hz
Initial phase: 0
TX amplitude: 0.3

Thanks for your help!

[belza]

Hello, Do you have any suggestion in order to solve this problem?

regards.

[jynik]

It wasn't clear that there still was a problem after addressing the last issue.

What is the issue? Could you please provide screenshots or sample data?

[belza]

Hello,
The problem is as follows. We transmit with our bladeRF x115 and, no matter what we transmit, we always obtain a "peak" at its center frequency. I have attached a screenshot (blade.png) that shows what a USRP sees on the spectrum when we transmit a QPSK signal. Now, using the same setup (PCs, cables, antennas, etc.) except for the bladeRF which we substitute by a USRP, we get what we expect (see usrp.png).
Hope this has clarified our problem.
Thank you very much again.
Regards.

[jynik]

Any chance you could share your flowgraph or GRC file? If it's very complicated or you are unable to, could you share a simplified version that reproduces the behavior?

Perhaps I or someone else could try reviewing and/or running it to see if whether we can reproduce this.

That center spike is likely just some LO leakage, but that tells me the the bladeRF is "alive" and the transmit path is enabled. So the question at hand, is why does it seem that no data is being transmitted?

- Jon

[belza]

Hi,
Please find attached the flowgraph we've used in the test (at least a screenshot, since the forum does not allow me to attach the grc, I've copied the python code in the post). It consists of a simple DQPSK transmitter that uses a WAV file as source and the Packet Encoder for framing. It is part of our course in wireless communications. In fact, we are evaluating bladeRF as a possible substitute of our USRPs to use it in the course, which also includes several end-of-term projects.
However, it is important to note that the problem is still there when the osmocom_siggen is used (or any transmission program), so I do not think this is actually a problem of our current flowgraph.
Best

Code: Select all

#!/usr/bin/env python
##################################################
# Gnuradio Python Flow Graph
# Title: Top Block
# Generated: Wed Dec 10 08:21:02 2014
##################################################

from gnuradio import blocks
from gnuradio import digital
from gnuradio import eng_notation
from gnuradio import gr
from gnuradio.eng_option import eng_option
from gnuradio.filter import firdes
from gnuradio.filter import pfb
from grc_gnuradio import blks2 as grc_blks2
from grc_gnuradio import wxgui as grc_wxgui
from optparse import OptionParser
import osmosdr
import time
import wx

class top_block(grc_wxgui.top_block_gui):

    def __init__(self):
        grc_wxgui.top_block_gui.__init__(self, title="Top Block")
        _icon_path = "/usr/share/icons/hicolor/32x32/apps/gnuradio-grc.png"
        self.SetIcon(wx.Icon(_icon_path, wx.BITMAP_TYPE_ANY))

        ##################################################
        # Variables
        ##################################################
        self.sym_rate = sym_rate = 44.1e03*4*4*1.0625
        self.samp_per_sym = samp_per_sym = 3
        self.len_sym_srrc = len_sym_srrc = 11
        self.alfa = alfa = 0.35
        self.samp_rate = samp_rate = sym_rate*samp_per_sym
        self.pulso = pulso = firdes.root_raised_cosine(samp_per_sym,samp_per_sym,1.0,alfa,samp_per_sym*len_sym_srrc)
        self.gain = gain = 15
        self.frec = frec = 851e6
        self.bits_per_sym = bits_per_sym = 2

        ##################################################
        # Blocks
        ##################################################
        self.pfb_interpolator_ccf_0 = pfb.interpolator_ccf(
        	  samp_per_sym,
        	  (pulso),
        	  100)
        self.pfb_interpolator_ccf_0.declare_sample_delay(0)
        	
        self.osmosdr_sink_0 = osmosdr.sink( args="numchan=" + str(1) + " " + "" )
        self.osmosdr_sink_0.set_sample_rate(samp_rate)
        self.osmosdr_sink_0.set_center_freq(851e6, 0)
        self.osmosdr_sink_0.set_freq_corr(0, 0)
        self.osmosdr_sink_0.set_gain(10, 0)
        self.osmosdr_sink_0.set_if_gain(20, 0)
        self.osmosdr_sink_0.set_bb_gain(20, 0)
        self.osmosdr_sink_0.set_antenna("", 0)
        self.osmosdr_sink_0.set_bandwidth(0, 0)
          
        self.digital_diff_encoder_bb_0 = digital.diff_encoder_bb(2**bits_per_sym)
        self.digital_chunks_to_symbols_xx_0 = digital.chunks_to_symbols_bc(([-1-1j, 1-1j, 1+1j, -1+1j]), 1)
        self.blocks_wavfile_source_0 = blocks.wavfile_source("/home/flarroca/facultad/cursos/wireless/comunicaciones_inalambricas/laboratorio/lab_modulacion/circle.wav", True)
        self.blocks_packed_to_unpacked_xx_0 = blocks.packed_to_unpacked_bb(bits_per_sym, gr.GR_MSB_FIRST)
        self.blocks_multiply_const_vxx_1 = blocks.multiply_const_vcc((0.4, ))
        self.blks2_packet_encoder_0 = grc_blks2.packet_mod_f(grc_blks2.packet_encoder(
        		samples_per_symbol=samp_per_sym,
        		bits_per_symbol=bits_per_sym,
        		preamble="",
        		access_code="",
        		pad_for_usrp=True,
        	),
        	payload_length=0,
        )

        ##################################################
        # Connections
        ##################################################
        self.connect((self.digital_chunks_to_symbols_xx_0, 0), (self.pfb_interpolator_ccf_0, 0))
        self.connect((self.blocks_packed_to_unpacked_xx_0, 0), (self.digital_diff_encoder_bb_0, 0))
        self.connect((self.digital_diff_encoder_bb_0, 0), (self.digital_chunks_to_symbols_xx_0, 0))
        self.connect((self.pfb_interpolator_ccf_0, 0), (self.blocks_multiply_const_vxx_1, 0))
        self.connect((self.blocks_wavfile_source_0, 0), (self.blks2_packet_encoder_0, 0))
        self.connect((self.blks2_packet_encoder_0, 0), (self.blocks_packed_to_unpacked_xx_0, 0))
        self.connect((self.blocks_multiply_const_vxx_1, 0), (self.osmosdr_sink_0, 0))



    def get_sym_rate(self):
        return self.sym_rate

    def set_sym_rate(self, sym_rate):
        self.sym_rate = sym_rate
        self.set_samp_rate(self.sym_rate*self.samp_per_sym)

    def get_samp_per_sym(self):
        return self.samp_per_sym

    def set_samp_per_sym(self, samp_per_sym):
        self.samp_per_sym = samp_per_sym
        self.set_pulso(firdes.root_raised_cosine(self.samp_per_sym,self.samp_per_sym,1.0,self.alfa,self.samp_per_sym*self.len_sym_srrc))
        self.set_samp_rate(self.sym_rate*self.samp_per_sym)

    def get_len_sym_srrc(self):
        return self.len_sym_srrc

    def set_len_sym_srrc(self, len_sym_srrc):
        self.len_sym_srrc = len_sym_srrc
        self.set_pulso(firdes.root_raised_cosine(self.samp_per_sym,self.samp_per_sym,1.0,self.alfa,self.samp_per_sym*self.len_sym_srrc))

    def get_alfa(self):
        return self.alfa

    def set_alfa(self, alfa):
        self.alfa = alfa
        self.set_pulso(firdes.root_raised_cosine(self.samp_per_sym,self.samp_per_sym,1.0,self.alfa,self.samp_per_sym*self.len_sym_srrc))

    def get_samp_rate(self):
        return self.samp_rate

    def set_samp_rate(self, samp_rate):
        self.samp_rate = samp_rate
        self.osmosdr_sink_0.set_sample_rate(self.samp_rate)

    def get_pulso(self):
        return self.pulso

    def set_pulso(self, pulso):
        self.pulso = pulso
        self.pfb_interpolator_ccf_0.set_taps((self.pulso))

    def get_gain(self):
        return self.gain

    def set_gain(self, gain):
        self.gain = gain

    def get_frec(self):
        return self.frec

    def set_frec(self, frec):
        self.frec = frec

    def get_bits_per_sym(self):
        return self.bits_per_sym

    def set_bits_per_sym(self, bits_per_sym):
        self.bits_per_sym = bits_per_sym

if __name__ == '__main__':
    import ctypes
    import sys
    if sys.platform.startswith('linux'):
        try:
            x11 = ctypes.cdll.LoadLibrary('libX11.so')
            x11.XInitThreads()
        except:
            print "Warning: failed to XInitThreads()"
    parser = OptionParser(option_class=eng_option, usage="%prog: [options]")
    (options, args) = parser.parse_args()
    tb = top_block()
    tb.Start(True)
    tb.Wait()

[jynik]

However, it is important to note that the problem is still there when the osmocom_siggen is used (or any transmission program), so I do not think this is actually a problem of our current flowgraph.

This is a very good point. I'm sorry, I didn't realize this problem was persisting after asking for the flowgraph.

So I think from here, we should try to: (1) identify if it's a software configuration/environment problem or (2) identify if this is an issue with the hardware (in which case you'll want to pass this thread on to [email protected] once we've ruled out (1)).

So let's start by taking GNU Radio out of the mix, and just verifying things from the libbladeRF side of things.

First, could you share the libbladeRF and bladeRF-cli versions you're using?

Next, could you power cycle the device and then capture the log from running bladeRF-cli -e info?

Now we can try transmitting a tone from the bladeRF-cli. I have attached a tone.csv file that I used. The commands to repeatedly transmit the contents of this CSV file are below.

Here's what this looks like on my spectrum analyzer (span of 50 kHz):

screen1.gif

After a quick DC offset correction and manual IQ balance corrections:

screen2.gif

Code: Select all

$ bladeRF-cli -i

bladeRF> set frequency tx 851M

  Set TX frequency:  851000000Hz

bladeRF> set samplerate tx 2.2491M

  Setting TX sample rate - req:   2249100 0/1Hz, actual:   2249100 0/1Hz

bladeRF> set bandwidth tx 1.5M
  Set TX bandwidth - req:  1500000Hz actual:  1500000Hz

bladeRF> tx config file=tone.csv format=csv repeat=0
bladeRF> tx

  State: Idle
  Last error: None
  File: tone.csv
  File format: SC16 Q11, CSV
  Repetitions: infinite
  Repetition delay: none
  # Buffers: 32
  # Samples per buffer: 32768
  # Transfers: 16
  Timeout (ms): 1000

bladeRF> tx start
  Converted CSV to SC16 Q11 file and switched to converted file.

bladeRF> tx stop

So if you can reproduce this, I think it's fair to say that the libbladeRF and the CLI are OK, and that the hardware is OK.


Next, we can try to see if something configured oddly (with respect to the bladeRF) with your GNU Radio setup. Let's ensure samples are getting down to the bladeRF hardware correctly. We will use one of the LMS6002D's internal loopback modes to loop transmitted samples back to the RX path along one of the LNAs. I have a flowgraph for this posted here. Here's what you can expect to see, if things are running properly. If this works, but transmitting to the external TX port doesn't, that would indicate to me that something must be damaged on the TX front end.

psk_loopback_fft.png

psk_loopback_const.png

psk_loopback_iq.png

So give this all a shot, and we'll go from there. Please don't be tempted to skip items I've requested -- I'm asking for them specifically because they generally give me a good sense of the state of your setup.
- Jon

[belza]

Hello,
I will try to answer in order:

First, could you share the libbladeRF and bladeRF-cli versions you're using?

The last version listed in gnuradio/bladeRF/host/libraries/libbladeRF/CHANGELOG is v0.17.0
The output of $ bladeRF-cli --version is 0.12.0-git-050f2ca

Next, could you power cycle the device and then capture the log from running bladeRF-cli -e info?

$ bladeRF-cli -e info

Serial #: e2f352dff3f7d8261d0e17485fc23c99
VCTCXO DAC calibration: 0x89ec
FPGA size: 115 KLE
FPGA loaded: no
USB bus: 4
USB address: 3
USB speed: SuperSpeed
Backend: libusb
Instance: 0

Now we can try transmitting a tone from the bladeRF-cli. I have attached a tone.csv file that I used. The commands to repeatedly transmit the contents of this CSV file are below.

I have attached a screenshot of what another USRP sees (spectrum.png), and I think it's pretty much what we expect.

Next, we can try to see if something configured oddly (with respect to the bladeRF) with your GNU Radio setup. Let's ensure samples are getting down to the bladeRF hardware correctly. We will use one of the LMS6002D's internal loopback modes to loop transmitted samples back to the RX path along one of the LNAs. I have a flowgraph for this posted here. Here's what you can expect to see, if things are running properly. If this works, but transmitting to the external TX port doesn't, that would indicate to me that something must be damaged on the TX front end.

I believe we have are getting closer to the problem. See the screenshot attached (screenshot.png): I'm still getting the "peak" at reception.

Thanks!

[jynik]

Hi there.

Okay, so that PSK loopback not working may indicate that either data isn't reaching the device (USB problems?) or something in the LMS6002D's TX path is damaged.

Generally, USB problems I've seen have been problematic USB 3 controllers. To check this, retry the PSK loopback on a USB 2 port. (If you don't have any, you could plug in a USB 2.0 micro cable to the bladeRF to force this -- it fits on the left side of a USB 3.0 connector.)

Let's try using a baseband loopback mode in the LMS6002D to take some items out of the TX path out of the picture. Change the loopback option on the Osmocom source to bb_txlpf_rxvga2, as shown below.

Screenshot1.png

You'll likely need to crank up the baseband gain to see something reasonable:

Screenshot2.png

Hopefully your results from these itesm, this should really narrow down the problem scope.

- Jon