Page 1 of 1

Run rx/tx demo on bladerf board

Posted: Sun Jul 28, 2013 11:45 pm
by jacky
Today, I updated the bladerf code,and according to the instructions as follows:

Code: Select all

# ./bladeRF/linux/apps/bin/bladeRF-cli -d /dev/bladerf0 -l hostedx40.rbf -s setup.txt -b
Loading fpga...
Done.

  Set RX frequency: 1000000000Hz
  Set TX frequency: 1000000000Hz    [b][u]#Here set the center frequency of 1GHz[/u][/b]


  Setting RX sample rate - req:  10000000Hz, actual:  10000000Hz
  Setting TX sample rate - req:  10000000Hz, actual:  10000000Hz


  Set RX bandwidth - req: 28000000Hz actual: 28000000Hz
  Set TX bandwidth - req: 28000000Hz actual: 28000000Hz

  Set TXVGA1 to -14

  RX Frequency: 1228800000Hz   [b][u]#But here print center frequency is 1.228GHz  ,why?[/u][/b]
  TX Frequency: 1228800000Hz

  RX sample rate: 10000000
  TX sample rate: 10000000

  RX Bandwidth:   1500000Hz
  TX Bandwidth:   1500000Hz

   tx config file=samples.txt format=csv repeat=1 delay=0
   tx start
How do I get this file? samples.txt?

Another question:
I tried to set up a simple block diagram in gnuradio-companion using an osmocom sink block and sine source block, But there was a problem:"RuntimeError: set_sample_rate failure due to device not being open Failed to read samples: File or device I/O failure". Any idea why this would be, or are there detailed instruction on how to set up the osmocom source block to work with bladeRF?

thanks.

Re: Run rx/tx demo on bladerf board

Posted: Mon Jul 29, 2013 4:55 am
by bpadalino
If you change the 'tx to an 'rx', you will receive samples and they will be placed into a file called 'samples.txt'.

As for setting up the osmosdr blocks to work with your bladeRF, you can check their website for more information.

Hopefully this helps.

Re: Run rx/tx demo on bladerf board

Posted: Mon Jul 29, 2013 6:40 pm
by jacky
I already tried but there still have an error:

Code: Select all

bladeRF> rx config file=/tmp/some_file format=csv 
bladeRF> rx

    State: Idle
    File: /tmp/some_file
    Format: C16, CSV
    # Samples: 1024
bladeRF> rx start

Error: A fatal unknown error has occurred

Re: Run rx/tx demo on bladerf board

Posted: Tue Jul 30, 2013 10:29 am
by madengr
I'm also getting the many of the "unknown error has occurred" in the CLI when poking memory locations in the LMS. I'm attempting to run the internal LMS calibration via a script of several pokes, and it's rare I can complete all of them without errors.

Re: Run rx/tx demo on bladerf board

Posted: Tue Jul 30, 2013 5:37 pm
by bpadalino
I've seen that recently. I am hoping our kernel engineer can get to the bottom of this and why it might be happening.

Do you know if you are connected via SS or HS?

Re: Run rx/tx demo on bladerf board

Posted: Tue Jul 30, 2013 6:24 pm
by jacky
I connected via SS, This error occurs.

Re: Run rx/tx demo on bladerf board

Posted: Tue Jul 30, 2013 6:47 pm
by syntroniks
This has happened to me as well running under ubuntu 12.04 on the latest vmware player. I was connected via both 2.0 (HS) and 3.0 (SS) in software. The port was always a 3.0 port. I can not say whether the problem is with vmware player or not since I don't have a 'real' linux machine yet.

FWIW, when I flash a compiled fx3 firmware, the version is always 1.0, regardless of what I set in the source code (e.g. v0.3)

Re: Run rx/tx demo on bladerf board

Posted: Tue Jul 30, 2013 7:24 pm
by bpadalino
What git repository revision are you on?

Re: Run rx/tx demo on bladerf board

Posted: Wed Jul 31, 2013 4:52 pm
by syntroniks
The latest -- but my linux kernel and many other system components were out of date. I may be able to report back on the virtual machine once I am done testing in this installed environment.

At this point, I have not tested with gnuradio yet, but the rx/tx demo on board (as per this topic) seems to be functioning although dmesg seems to be reporting my ports as high-speed. I'll investigate that further as well.

Re: Run rx/tx demo on bladerf board

Posted: Thu Aug 01, 2013 12:02 am
by piranha32
I have similar problems with bladeRF on Fedora19. I have the most recent software from git, firmware for microcontroller was compiled from source, FPGA config was downloaded from nuand.com. I don't have USB3 ports in my computer, so I'm using USB2.0 link. Firmwares upload successfully, board responds and returns correct config info:

Code: Select all

bladeRF> probe
      Path: /dev/bladerf0
      Serial: 0x0000000000000000
      Firmware: v0.3
      FPGA: v0.0
Unfortunately saving IQ samples to file doesn't seem to work. I'm using the following sequence of commands:

Code: Select all

set  samplerate 2000000
set frequency 450000000
set bandwidth 1500000
rx config n=1000000 file=/tmp/iq.sav format=binl
rx
rx start
RX starts, seems to be working:

Code: Select all

bladeRF> rx
    State: Running
    File: /tmp/iq.sav
    Format: C16, Binary (Little Endian)
    # Samples: 1000000
However no samples are saved to the file and the process never stops (unless I send rx stop). An attempt to start rx again after stopping locks the cli app. I can kill the cli tool with ^C, start again and the rx process will start successfully, with identical results. The only sign of activity in the logs are these two lines form kernel module:

Code: Select all

Aug 01 02:51:51 localhost kernel: usb_control_msg(ptr=ffff880526f43eb8) len=4
Aug 01 02:51:51 localhost kernel: done usb_control_msg() = 4
Resetting the board, reflashing microcontroller, reprogramming the fpga, unloading and loading again the module do not help.
What is interesting, I managed to get the board to work once, the very first time I uploaded the firmware files (I checked with osmocom_fft). After reset it never worked again.

Re: Run rx/tx demo on bladerf board

Posted: Sun Aug 04, 2013 11:03 am
by madengr
madengr wrote:I'm also getting the many of the "unknown error has occurred" in the CLI when poking memory locations in the LMS. I'm attempting to run the internal LMS calibration via a script of several pokes, and it's rare I can complete all of them without errors.
The changes made to the code 3 days ago fixed this issue.