BladeRF unusable due to "wait_for_buffer: Timed out waiting for buf_ready" errors #849
Comments
|
Hello, I was able to resolve my problem of usb transfer time-outs. Here is the workaround: and then the errors disappeared... I am under Debian bookworm with libbladerf 0.2021.10-2 (I was planning to downgrade this as well to 0.2019.07-7 but finally it was not necessary). I hope this can be helpful because I chased my tail around for a while with this one. cheers, |
|
I think that I have similar issues on bladeRF x40 (host libraries & bladeRF-cli built from sources, latest FX3 and FPGA images downloaded from Nuand resources). I haven't managed to calibrate the device. Also tried to change USB ports on my host and had different messages depending on whether I used Hi-Speed or SuperSpeed, so at first I thought it was host-side issue somehow related to USB backend only. Here's the verbose And here's the verbose Part of the Subsequent downgrade of the FPGA image only to the |
|
I am experiencing the same issue. Downgrading cannot be a solution on the long run. |
|
Let me show you a simple example of a transmission, running on Windows and Linux: Example Code in Rust: File main.rs: use futuresdr::blocks::{Apply, SoapySinkBuilder};
use futuresdr::runtime::Flowgraph;
use futuresdr::anyhow::Result;
use futuresdr::blocks::audio::Oscillator;
use futuresdr::num_complex::{Complex32};
use futuresdr::runtime::buffer::slab::Slab;
use futuresdr::runtime::Runtime;
const SAMPLE_RATE: f64 = 3_072_000.0;
const FREQUENCY: f64 = 330e6;
fn main() -> Result<()> {
let mut fg = Flowgraph::new();
let src = fg.add_block(Oscillator::new(440.0, 1., SAMPLE_RATE as f32));
let modulator = fg.add_block(Apply::new(move |v: &f32| -> Complex32 {
Complex32::new(*v, *v)
}));
let soapy_snk = fg.add_block(SoapySinkBuilder::new().freq(FREQUENCY).sample_rate(SAMPLE_RATE).gain(0.0).filter("driver=bladerf").build());
fg.connect_stream_with_type(src, "out", modulator, "in", Slab::with_size(4096))?;
fg.connect_stream_with_type(modulator, "out", soapy_snk, "in", Slab::with_size(4096))?;
let runtime = Runtime::new();
runtime.run(fg)?;
Ok(())
}File Cargo.toml: [package]
name = "morse_code"
version = "0.1.0"
edition = "2021"
# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html
[dependencies]
futuresdr = { version = "*", features = [ "soapy" ]}Dependencies required to compile and reproduce on Ubuntu 20.04: sudo add-apt-repository ppa:nuandllc/bladerf
sudo apt update
sudo apt install bladerf clang, llvm, libsoapysdr-dev
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | shBuild:
When running this program, we get teh following results and transmittion of the carrier at 330MHz stops after few seconds: The same behaviour can be witnessed on Windows and on a different machine too: Note, that the errors did not appear before v0.12.0. So what is the issue here? I am curious, if the bladeRF repository is still maintained, as i can encounter a lot of unsolved issues without comments here on Github. Is the bladeRF still supported, or do we have to search for another platform? |
|
Hello all, just got across this posts searching for answers as i updated firmware and fpga in my bladerf x40 but i'm getting timeout erros like the ones described here and cannot properly calibrate the device. Sometimes doing cal lms just exits bladeRF-cli completely. Any help or ideas will be very much appreciated as i want to get the device up and running again. |
|
Good day, I am also facing the same issue: The timeout occurs on Tx transfers with the FPGA on the latest version, and no issue on v0.12.0 or less. |
|
Hi @rghilduta, upon further investigation, I found that reverting commit 2a8774d solved the issue of time-outs. I can't see any adverse effects by doing this, but let me know if I might have missed something. Hopefully, that narrows it down a bit. Regards, |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hello
I try to test BladeRF under Pothos (built from source) and I get strange errors when using the bladerf soapy sink
[22:22:54.214000] SoapySDR: bladerf_open_with_devinfo()
[22:22:54.394000] SoapySDR: bladerf_get_serial() = 1d62a870f59e65fdd231ced37787b03a
[22:22:54.401000] SoapySDR: setSampleRate(Rx, 0, 4.000000 MHz), actual = 4.000000 MHz
[22:22:54.409000] SoapySDR: setSampleRate(Tx, 0, 4.000000 MHz), actual = 4.000000 MHz
[22:22:54.417000] SoapySDR: setSampleRate(Rx, 0, 4.800000 MHz), actual = 4.800000 MHz
[22:22:54.421000] ::1: [INFO @ fpga_common/src/lms.c:2258] Clamping frequency to 237500000Hz
[22:23:04.972000] ::1: [INFO @ fpga_common/src/lms.c:2258] Clamping frequency to 237500000Hz
[22:23:05.017000] : 0
[22:23:05.248000] ::1: [ERROR @ host/libraries/libbladeRF/src/streaming/sync.c:336] wait_for_buffer: Timed out waiting for buf_ready after 1 ms
[22:23:05.249000] ::1: [ERROR @ host/libraries/libbladeRF/src/streaming/sync.c:336] wait_for_buffer: Timed out waiting for buf_ready after 1 ms
[22:23:05.250000] ::1: [ERROR @ host/libraries/libbladeRF/src/streaming/sync.c:336] wait_for_buffer: Timed out waiting for buf_ready after 1 ms
[22:23:05.348000] ::1: [ERROR @ host/libraries/libbladeRF/src/streaming/sync.c:336] wait_for_buffer: Timed out waiting for buf_ready after 1 ms
[22:23:05.349000] ::1: [ERROR @ host/libraries/libbladeRF/src/streaming/sync.c:336] wait_for_buffer: Timed out waiting for buf_ready after 1 ms
[22:23:05.350000] ::1: [ERROR @ host/libraries/libbladeRF/src/streaming/sync.c:336] wait_for_buffer: Timed out waiting for buf_ready after 1 ms
[22:23:05.447000] ::1: [ERROR @ host/libraries/libbladeRF/src/streaming/sync.c:336] wait_for_buffer: Timed out waiting for buf_ready after 1 ms
[22:23:05.448000] ::1: [ERROR @ host/libraries/libbladeRF/src/streaming/sync.c:336] wait_for_buffer: Timed out waiting for buf_ready after 1 ms
[22:23:05.449000] ::1: [ERROR @ host/libraries/libbladeRF/src/streaming/sync.c:336] wait_for_buffer: Timed out waiting for buf_ready after 1 ms
[22:23:05.547000] ::1: [ERROR @ host/libraries/libbladeRF/src/streaming/sync.c:336] wait_for_buffer: Timed out waiting for buf_ready after 1 ms
.....
the flowgraph is stuck and does not do anything. In gnuradio-companion the BladeRF source behaves similarly but curiously when gr-osmosdr source everything works nicely.
If somebody can help I'd greatly appreciate because I am completely stuck with this.
best regards
aK
The text was updated successfully, but these errors were encountered: