SigDigger
SigDigger copied to clipboard
BatchDrake
BladeRF only runs for a few seconds
First of all, thank you so much for making this. I've made SDR apps in the past, but never one close to as nice as this. Excellent work.
I'm using a MacBook Pro (with M1), and version 0.3.0. I've tried with an rtl-sdr, and it seems like I can run it indefinitely. But, when I use my BladeRF, the processing seems to get stuck or stops after a given quantity of data (some multiple of a buffer?). If I run it at an 80khz sample rate, I can run it for maybe 30 seconds (a full screen of waterfall on auto). If I set it to 2.58mhz then it'll run for a few seconds (maybe 2-3), and if I set it to 10mhz it'll run for just a blip. It seems like it scales exactly inverse-linearly with the sample rate. This makes me feel like it's processing a single buffer then stopping.
Any ideas? Thanks!
Hi William, and thanks for your kind feedback.
Unfortunately, I cannot reproduce any of this. I used to have a BladeRF but it is now dead. If this is a driver problem, I'm afraid there's little I can do.
Do you happen have any GNU/Linux machine around? Maybe we can reproduce under Linux too.
Cheers,
El lun., 13 dic. 2021 19:00, William Dillon @.***> escribió:
First of all, thank you so much for making this. I've made SDR apps in the past, but never one close to as nice as this. Excellent work.
I'm using a MacBook Pro (with M1), and version 0.3.0. I've tried with an rtl-sdr, and it seems like I can run it indefinitely. But, when I use my BladeRF, the processing seems to get stuck or stops after a given quantity of data (some multiple of a buffer?). If I run it at an 80khz sample rate, I can run it for maybe 30 seconds (a full screen of waterfall on auto). If I set it to 2.58mhz then it'll run for a few seconds (maybe 2-3), and if I set it to 10mhz it'll run for just a blip. It seems like it scales exactly inverse-linearly with the sample rate. This makes me feel like it's processing a single buffer then stopping.
Any ideas? Thanks!
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/BatchDrake/SigDigger/issues/167, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEVET4DPJLVHM3TLYUNUGLUQYYD7ANCNFSM5J6Y3PMQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
I do, yah. I can try that out. The best way would be via SigDigger on linux, rather than trying something with SoapySDR?
Yep, exactly. Try the latest AppImage. If it does not hang, we can try building SigDigger locally with the latest BladeRF drivers (which are the ones included in the .dmg) and cross our fingers.
El lun., 13 dic. 2021 19:14, William Dillon @.***> escribió:
I do, yah. I can try that out. The best way would be via SigDigger on linux, rather than trying something with SoapySDR?
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/BatchDrake/SigDigger/issues/167#issuecomment-992740711, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEVET35FHCQE6NSNOXNATDUQYZXLANCNFSM5J6Y3PMQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
Ok, awesome. I've never tried an AppImage before. That's incredibly awesome.
Ok, it does still hang in linux, but it helpfully provides some logging...
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-wdillon'
Qt: XKEYBOARD extension not present on the X server.
[INFO] bladerf_open_with_devinfo()
[INFO @ host/libraries/libbladeRF/src/helpers/version.c:82] Firmware version (v2.4.0) is newer than entries in libbladeRF's compatibility table. Please update libbladeRF if problems arise.
[INFO @ host/libraries/libbladeRF/src/helpers/version.c:106] FPGA version (v0.14.0) is newer than entries in libbladeRF's compatibility table. Please update libbladeRF if problems arise.
[INFO] bladerf_get_serial() = c52117e2ff2f78588aec8dd89349e432
[INFO] setSampleRate(Rx, 0, 4.000000 MHz), actual = 4.000000 MHz
[INFO] setSampleRate(Tx, 0, 4.000000 MHz), actual = 4.000000 MHz
[INFO] setSampleRate(Rx, 0, 2.580000 MHz), actual = 2.580000 MHz
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000[ERROR @ host/libraries/libbladeRF/src/streaming/sync.c:306] wait_for_buffer: Timed out waiting for buf_ready after 100 ms
[ERROR @ host/libraries/libbladeRF/src/streaming/sync.c:306] wait_for_buffer: Timed out waiting for buf_ready after 100 ms
[ERROR @ host/libraries/libbladeRF/src/streaming/sync.c:306] wait_for_buffer: Timed out waiting for buf_ready after 100 ms
[ERROR @ host/libraries/libbladeRF/src/streaming/sync.c:306] wait_for_buffer: Timed out waiting for buf_ready after 100 ms
[ERROR @ host/libraries/libbladeRF/src/streaming/sync.c:306] wait_for_buffer: Timed out waiting for buf_ready after 100 ms
[ERROR @ host/libraries/libbladeRF/src/streaming/sync.c:306] wait_for_buffer: Timed out waiting for buf_ready after 100 ms
[ERROR @ host/libraries/libbladeRF/src/streaming/sync.c:306] wait_for_buffer: Timed out waiting for buf_ready after 100 ms
[ERROR @ host/libraries/libbladeRF/src/streaming/sync.c:306] wait_for_buffer: Timed out waiting for buf_ready after 100 ms
[ERROR @ host/libraries/libbladeRF/src/backend/usb/libusb.c:1090] Transfer timed out for buffer 0x2174a20
I'm just now seeing the version messages. I have a second BladeRF with older firmware, so I'm willing to load the exact version that libbladeRF wants, if we know what that is.
Trying my older BladeRF on linux works! It also seems to work on my mac now (It hung before, but not now 🤷). I guess I'll downgrade my firmware for now. Is there any way to know what commit of libbladerf you used to build so I can see the latest supported versions?
Thanks again!
Good question, I use whatever is in the latest Ubuntu 18.04 repos. For the macOS releases I rely on brew, and that supposedly builds everything from source. I have to look into it.
El lun., 13 dic. 2021 20:12, William Dillon @.***> escribió:
Trying my older BladeRF on linux works! It also seems to work on my mac now (It hung before, but not now 🤷). I guess I'll downgrade my firmware for now. Is there any way to know what commit of libbladerf you used to build so I can see the latest supported versions?
Thanks again!
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/BatchDrake/SigDigger/issues/167#issuecomment-992785649, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEVET4L2FWQZIYVVAWHD6LUQZAQXANCNFSM5J6Y3PMQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
Hm.. Plot thickens. It seems like Brew is very up-to-date, and is using the 2021.10 release, and is supposed to work with those firmware versions. Meanwhile ubuntu's is older (2019.07), and is expecting older versions. I'll load these versions on the "updated" blade, and see what happens...
* FPGA bitstream v0.11.0
* FX3 firmware v2.3.2
* libbladeRF v2.2.1
* bladeRF-cli v1.8.0
* MATLAB & Simulink bindings v1.0.3
* Python bindings v1.2.0
Yep! I've confirmed that there's a bug in the 2.4.x firmware for the BladeRF. I even got buffer errors sometimes in bladeRF-cli when I was trying to calibrate it. I think this can be closed.
Thanks again!