BladeRF becomes unusable after changing sample rate #778
Comments
|
Quick question, do you know if the libbladeRF tuning mode is set to host or
FPGA?
If it's currently FPGA, please try to set it to host.
…On Sat, Apr 25, 2020 at 9:46 AM Andre Puschmann ***@***.***> wrote:
Hey,
I am using the bladeRF 2.0 and I am seeing difficulties when changing the
sample rates during operation. This happens with Rx only as well as with
Rx/Tx. I've also tried to stop the Rx streaming operation before changing
the rate but it doesn't seem to help. I remember this actually working
before so I was wondering if that might be a regression or if I am doing
something wrong here?
The issue can easily be reproduced with srsLTE and the PDSCH example where
we scan for the LTE cell at 1.92 Msamps/s before changing to the actual
cell bandwidth, 11.52 Msamps/s for example for a 10 MHz LTE cell. See log
below. If that happens, I actually need to kill -9 the application.
I've swapped the cable and also tried on two different machines, different
USB ports, etc.
Normal streaming is ok, as long as I don't change the sample rate.
Any ideas what might be causing the issue?
Thanks
Andre
$ ./lib/examples/pdsch_ue -f 816e6 -I soapy
Opening RF device with 1 RX antennas...
Soapy has found device #0: backend=libusb, device=0x02:0x1B, driver=bladerf, instance=0, label=BladeRF #0 [ab356e9a..f965f068], serial=ab356e9ac74547478d292539f965f068,
Selecting Soapy device: 0
[INFO] bladerf_open_with_devinfo()
[INFO] bladerf_get_serial() = ab356e9ac74547478d292539f965f068
[INFO] setSampleRate(Rx, 0, 4.000000 MHz), actual = 4.000000 MHz
[INFO] setSampleRate(Tx, 0, 4.000000 MHz), actual = 4.000000 MHz
Setting up Rx stream with 1 channel(s)
[INFO] numBuffs=32
[INFO] bufSize=4096
[INFO] numXfers=16
Setting up Tx stream with 1 channel(s)
[INFO] numBuffs=32
[INFO] bufSize=4096
[INFO] numXfers=16
[INFO] setSampleRate(Rx, 0, 1.920000 MHz), actual = 1.920000 MHz
[INFO] setSampleRate(Tx, 0, 1.920000 MHz), actual = 1.920000 MHz
Available device sensors:
- RFIC_TEMP
Available sensors for Rx channel 0:
- PRE_RSSI
- SYM_RSSI
State of gain elements for Rx channel 0 (AGC supported):
- full: 69.00 dB
State of gain elements for Tx channel 0 (AGC not supported):
- dsa: -10.00 dB
Rx antenna set to RX
Tx antenna set to TX
Starting AGC thread...
Tunning receiver to 816.000 MHz
Searching for cell...
[INFO] setSampleRate(Rx, 0, 1.920000 MHz), actual = 1.920000 MHz
0 Found Cell_id: 0 FDD, CP: Normal , DetectRatio= 0% PSR=0.00, Power=-inf dBm
*Found Cell_id: 190 FDD, CP: Normal , DetectRatio=100% PSR=5.65, Power=39.7 dBm
Found Cell_id: 0 FDD, CP: Normal , DetectRatio= 0% PSR=0.00, Power=-inf dBm
Decoding PBCH for cell 190 (N_id_2=1)
[INFO] setSampleRate(Rx, 0, 1.920000 MHz), actual = 1.920000 MHz
00000000000000Setting sampling rate 11.52 MHz
[ERROR @ host/libraries/libbladeRF/src/streaming/sync.c:305] wait_for_buffer: Timed out waiting for buf_ready after 400 ms
[ERROR @ host/libraries/libbladeRF/src/streaming/sync.c:305] wait_for_buffer: Timed out waiting for buf_ready after 400 ms
[ERROR @ host/libraries/libbladeRF/src/streaming/sync.c:305] wait_for_buffer: Timed out waiting for buf_ready after 400 ms
[ERROR @ host/libraries/libbladeRF/src/streaming/sync.c:305] wait_for_buffer: Timed out waiting for buf_ready after 400 ms
[ERROR @ host/libraries/libbladeRF/src/streaming/sync.c:305] wait_for_buffer: Timed out waiting for buf_ready after 400 ms
[ERROR @ host/libraries/libbladeRF/src/streaming/sync.c:305] wait_for_buffer: Timed out waiting for buf_ready after 400 ms
I am using the device through Soapy, all compiled from sources.
$ SoapySDRUtil --info
######################################################
## Soapy SDR -- the SDR abstraction library ##
######################################################
Lib Version: v0.8.0-gf722f9ce
API Version: v0.8.0
ABI Version: v0.8
Install root: /usr/local
Search path: /usr/local/lib/SoapySDR/modules0.8
Module found: /usr/local/lib/SoapySDR/modules0.8/libLMS7Support.so (20.01.0-0854a51e)
Module found: /usr/local/lib/SoapySDR/modules0.8/libbladeRFSupport.so (0.4.1-1c1e8aa)
I am also using the latest bladeRf driver and FPGA I believe.
$ bladeRF-cli -e version
[INFO @ host/libraries/libbladeRF/src/board/bladerf2/bladerf2.c:309] Waiting for device to become ready...
bladeRF-cli version: 1.8.0-git-45521019
libbladeRF version: 2.2.1-git-45521019
Firmware version: 2.3.2
FPGA version: 0.11.0 (configured from SPI flash)
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#778>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AA3RD3YXS3WYSH437ON7AP3ROMHX5ANCNFSM4MQ2GATQ>
.
|
|
Hey Robert, thanks for the hint. I didn't know about those tuning modes but it turned out that it was set to host by default even though it should be FPGA according to this with the FPGA/lib version I am using, shouldn't it? So |
|
Hey Robert, |
|
Ah, that seems able to trigger an issue which is likely either in libbladeRF or the bladeRF HDL. The first failure seems to happen just as the bladeRF's sample rate is changed from 11.52MHz to 1.92MHz. Let me try to see if I can get a better understanding of what's happening within libbladeRF. |
|
Sure, thanks for looking at this issue Robert. The |
|
Believe I'm having the same issues while trying to setup srsLTE using 2x Micro xA4. Here's a paste from the test you requested above and I'll work backwards from there. 20.04.1 `./benchmark_radio -d bladeRF -s 11.52e6 -f 801.3e6 -t 10 -x -y Warning: TX gain was not set. Using open-loop power control (not working properly) set RX frequency to 801299966 /usr/src/srsLTE/lib/src/phy/rf/rf_blade_imp.c.434: RX failed: Operation timed out; nsamples=11520; /usr/src/srsLTE/lib/src/phy/rf/rf_blade_imp.c.434: RX failed: Operation timed out; nsamples=11520; /usr/src/srsLTE/lib/src/phy/rf/rf_blade_imp.c.434: RX failed: Operation timed out; nsamples=11520; /usr/src/srsLTE/lib/src/phy/rf/rf_blade_imp.c.434: RX failed: Operation timed out; nsamples=11520; /usr/src/srsLTE/lib/src/phy/rf/rf_blade_imp.c.434: RX failed: Operation timed out; nsamples=11520; /usr/src/srsLTE/lib/src/phy/rf/rf_blade_imp.c.434: RX failed: Operation timed out; nsamples=11520; /usr/src/srsLTE/lib/src/phy/rf/rf_blade_imp.c.434: RX failed: Operation timed out; nsamples=11520; /usr/src/srsLTE/lib/src/phy/rf/rf_blade_imp.c.434: RX failed: Operation timed out; nsamples=11520; /usr/src/srsLTE/lib/src/phy/rf/rf_blade_imp.c.434: RX failed: Operation timed out; nsamples=11520; /usr/src/srsLTE/lib/src/phy/rf/rf_blade_imp.c.434: RX failed: Operation timed out; nsamples=11520;` `bladeRF-cli -e version bladeRF-cli version: 1.8.0-git-c8320f71-ppafocal Firmware version: 2.2.0-git-47f93fe1 `###################################################### Soapy SDR -- the SDR abstraction library###################################################### Lib Version: v0.7.2-1 |
|
I’m having the same issue with the bladerf A4 using master branch from bladerf and srsLTE and the newest firmware and bitstream. Is there any movement on this issue? Would be happy to try a branch. |
|
I have found further information about this issue. I set the default sample rate to 11.52MHz in It seems that the radio functions fine when switching down from 11.52Mhz to 1.92Mhz, but going the other direction it starts timing out. The version of srsLTE I am using will switch back to cell searching once the device has been in an idle state for long enough, and what's really interesting is when the radio is switched back down to 1.92MHz, it works fine and can receive again. Then when it is switched back up to 11.52MHz, it starts timing out. |
|
More interesting data; I am using radio_benchmark for troubleshooting. It seems that if the radio is told to change the sample rate to exactly the same sample rate it already has, it still encounters the error (i.e. changing from 1.92e6 to 1.92e6 triggers the bug. Same result when tuning mode is FPGA. |
|
This happens to me with bitstream v0.10.2 but not v0.9.0 (on xA4 from Nuand) |
|
Thanks for the updates. Is it possible to downgrade the bitstream when using the PPA/20.04? Still learning the ins and outs of the bladerf. I’ll do some research and see if I can find out more and try and run it again as the UE. |
|
In recent testing with libbladerf 2.4 from git, latest firmware and fpga , my xA4 and xA9 seems fine in the role of the enodeb or ue with srsLTE (can’t recall if uhd or bladerf driver arg worked better). Also works great with croc hunter when configured to use only the srsLTE bladerf driver. |
|
I can confirm that the problem disappeared after upgrading to the latest FX3 firmware (2021-01-12 - v2.4.0), FPGA (2021-01-12 - v0.12.0) and libbladeRF (git e09200c). |
Unfortunately, the problem does not disappear for me after upgrading to latest, or downgrading to each fpga from v0.12.0 to v0.8.0 |
|
Has any progress been made to this ? I have tested the most recent FPGA/Firmware/master branch combo and the benchmark still fails with gaps and overruns bladeRF-cli version: 1.8.0-git-d1c38277 Firmware version: 2.4.0-git-a3d5c55f Runnign on Ubuntu 20.04LTS // VMware with usb 3.0 DRIVERS USB Speed clocked at ~7700-8000 kb/s (with usbtop) USB Port was also compared to bare metail Ubuntu 20.04 with exact same numbers on a 1 Gig file creation: USBTOP reports ~100e3 throughput on this port during file creation sudo bash -c "export BLADERF_LOG_LEVEL=debug; export BLADERF_DEFAULT_TUNING_MODE=host; ./lib/src/radio/test/benchmark_radio -d bladerf -s 1.92e6 -f 801.3e6 -t 10 -x -y" Warning: TX gain was not set. Using open-loop power control (not working properly) set RX frequency to 801299966 |
|
My issue is gone since I'm using srsRAN, however I'm not sure with @andrepuschmann tried that or the latest updates from Nuand |
|
I have 2 BladeRF xA4 Micro's, used one as spectrum analyzer with gqrx on a cabled connection from the Radio under test(with benchmark_radio executing ) and saw no transmit. Does benchmark_radio @andrepuschmann actually transmit with -x? I tested same frequency with a simple FM modulation (same freq/ sample rate) through GRC and received a good xmit. |
|
Can you provide the versions and physical setup you are using @yesimxev? Thanks
|
|
I am having difficulty for running srsRAN application (as eNodeB) with BladeRF xA9. The COTS UE does not register although it sees the signal from the enb. So I tried the benchmark test to see if there is a problem. I am having the same problem with the benchmark_radio command below:
The logs are ending with these lines: The bladeRF software versions are as follows: Can someone provide running versions of bladeRF and srsRAN with the configuration files? @andrepuschmann @alphafox02 @yesimxev Thanks |
|
Please flash firmware v2.4.1 and load/flash fpga v0.14.0. They have several fixes, anyway I noticed you try with the latest lib. Fw and libs should always match https://www.nuand.com/fpga_images/ |
|
I have loaded v0.14.0 fpga but used the libbladeRF 2.4.1 version that was mentioned above with the latest firmware version of 2.4.0 (latest release is 2.4.0 as far as I see) according to the releases page on https://github.com/Nuand/bladeRF/releases The srsenb starting log is as follows: As a side note, when the TX port is connected to a spectrum analyzer, we see notches at the ends of the LTE signal bandwidth. (while these notches are not there with other SDR cards such as Ettus B200 mini) Any help is appreciated about the configuration of correctly working srsenb with bladeRFxA9. Thanks in advance |
|
You are right, I forgot actually the latest version is 2.4.0. Is your issue gone? As far as I remember, according to @rghilduta , the bandwitdth very end can be ignored if it doesn't affect usage. Can't remember if it can be trimmed or fine tuned |
|
UPDATE: after troubleshooting, I have it working, the issue was VMware (even though usb 3.0 was enabled). When I plugged bladeRF into usb2.0 port on a separate machine, I noticed the same errors that I saw in VMWare. Switching to a USB 3.0 port on the separate machine (with Debian on metal), and the errors seem to have gone away. Hello, experiencing the same issue as @devmuroid: VersionsCard: bladeRF 2.0 xA4 Firmware version: 2.4.0-git-a3d5c55f Benchmark log (FPGA tuning mode, device=bladeRF)Benchmark log (Host tuning mode, device=bladeRF)Benchmark log (soapy) |
|
I have tried with different computers with Ubuntu 20.04 and 21.10 with host and fpga modes but benchmark_radio still fails. |
|
Is their any update on this issue or any combination of firmware and libbladerf version that can support the srsue ? |
|
Usb3.0, latest fpga, libs and srsran did the trick for others |
Unfortunately that doesn't work for me, i am using USB3 for sure on ubuntu 22.04 with the latest fpga / bitstream firmware and libbladerf library my bladerf board is the xa4 and i am also using the latest version of srsran. The issue is exactly as described here , pdsch_ue is working fine for me but srsue is stuck once it tries to switch down to 1.92Mhz also the benchamrk test fails with all drivers (soapy,bladerf), i have tried the following so far i made changes to srsue rf_blade_impl.c to change 1.92Mhz to 11.52e6 and also set srate in ue.conf to 11.52e6 this seems to at least help the UE to proceed and attach but this doesn't work on all earfcns only on specific earfcns such as 2850 but it fails on 1350/6400 etc. Also even tho the UE seems to attach and go to RRC IDLE in the ue_mac.pcap the ue doesn't actually capture correct info since the packets in the pcap are garbage and cannot be analyzed correctly, i think the only way for srsue to actually work correctly is to actually set the 1.92Mhz rate as originally intended but this bug still seems to apply for the bladerf lib since if the rate is set from 11.52Mhz to 1.92Mhz the boards times out and is unresponsive. |
|
The one person that told me the xa4 worked as a UE also said they added this to the arguments --rf.srate=11520000 I’ll follow up and see what else they used. |
I tried this aswell and this works only for specific earfcns such as the 2850 that work with this rate but it does not work on other earfcns like the 1350/6400 etc, regardless the issue on the bladerf that causes the timeout when switched to a lower rate from a higher rate is still applicable at least for the xa4 board that i can test on |
|
Hey, I have the same issue with a bladeRF 2.0 micro xA5. I tried many of the proposed solutions above. Though it looks like downgrading the FPGA image might do the trick, I cannot do it as the xA5 and the xA4 don't share the same FPGA. See the output below. Any ideas? Thanks! Antonio |
|
Hey, I have the same issue with bladeRF 2.0 micro xA9. bladeRF-cli version: 1.8.0-git-6ad1a34f Firmware version: 2.4.0-git-a3d5c55f Is there any update? Thanks. |
|
I am facing the same issues, both in bladeRF xA9 and xA5 with the latest FPGA and Firmware images. Edit: I managed to avoid the error. There has been a new release of the bladeRF FPGA, updated, and it worked better |
|
For my srsRAN setup, I can only run my bladeRF xA5 at 15 RBs (3 MHz) at srsRAN's stock sample rate, and even that is semi-unstable. Setting my RB count to 25 (5 MHz paired spectrum) results in overruns of over 1000 when enabling the RF trace in srsRAN. Same with setting the sample rate to I'm on the latest FPGA (1.5.0) that released in Feb and it seems to make absolutely no difference to my workflow. I've had this issue since I first ordered my bladeRF and it's extremely frustrating as it means using the SDR for anything except the most boring, unperformant tests isn't possible. This wasn't what I had in mind. Overruns at 15 RBs (1TRx): |
|
Hi Robert (@robertghilduta ) and all, Below is the setup for bladerf. Firmware version: 2.4.0-git-a3d5c55f When I try to run sudo ./lib/src/radio/test/benchmark_radio -d bladerf -s 11.52e6 -f 801.3e6 -t 10 -x -y Overall , It fails anyway but many times, it gets stuck to following too: Please do provide any solution. #define STOP_STREAM_BEFORE_RATE_CHANGE 1 from #define STOP_STREAM_BEFORE_RATE_CHANGE 0 But that also does not make any difference. Please do share any workarounds or fixes for same. |
|
@andrepuschmann , |
|
It's been like this since I first received my xA5 and has never been fixed. The SDR has just been sat in a drawer being totally useless for me. |
|
Oh my god. I purchased 3 weeks back bladerf 2.0 micro XA4 and have been struggling to bring it up for srsRAN_4G. Quite a big let down..If it is indeed bladerf FPGA bit load issue or fw and there is some work around to not create the condition for bladerf, it can be attempted in srsRAN bladerf interface files. I can see that there is some macro in sdr interface code in srsRAN to stop rx stream while changing tx or rx sample rate(comments in the file give impression that it is meant for limesdr). Any clue to set sampling rates once in beginning and not touch it. It means that cell search will operate on higher rates.. srsRAN folks can advice. I will attempt to take on...
Regards Nitin
On Tuesday, 28 November, 2023 at 05:52:11 pm IST, David Wheatley ***@***.***> wrote:
It's been like this since I first received my xA5 and has never been fixed.
The SDR has just been sat in a drawer being totally useless for me.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.Message ID: ***@***.***>
|
|
@nitinvjain please use my @rghilduta Github user or ideally for faster response time please contact us by email at [email protected] . @robertghilduta is just a placeholder. The |
|
For posterity sake, please also ensure to the bladerf interface directly (and the soapy one to access the bladeRF). |
|
If it helps in the short term, slap DragonOS FocalX on a usb stick. Boot live, and pass the bladerf argument via command line with sudo srsenb. I use the bladerf as the 4g enb and the b205mini as a ue. |
|
@rghilduta When you closed this, what was the solution/fix to this problem? Maybe I'm missing a detail in the conversation. I'm having the same problem with this version: |
Hey,
I am using the bladeRF 2.0 and I am seeing difficulties when changing the sample rates during operation. This happens with Rx only as well as with Rx/Tx. I've also tried to stop the Rx streaming operation before changing the rate but it doesn't seem to help. I remember this actually working before so I was wondering if that might be a regression or if I am doing something wrong here?
The issue can easily be reproduced with srsLTE and the PDSCH example where we scan for the LTE cell at 1.92 Msamps/s before changing to the actual cell bandwidth, 11.52 Msamps/s for example for a 10 MHz LTE cell. See log below. If that happens, I actually need to
kill -9the application.I've swapped the cable and also tried on two different machines, different USB ports, etc.
Normal streaming is ok, as long as I don't change the sample rate.
Any ideas what might be causing the issue?
Thanks
Andre
I am using the device through Soapy, all compiled from sources.
I am also using the latest bladeRf driver and FPGA I believe.
The text was updated successfully, but these errors were encountered: