Remember when I said driver development isn't linear ?
-
Remember when I said driver development isn't linear ? Here is another chapter.
I have had a bladeRF SDR for years. Brought to Morocco, where returning defective hardware isn't really an option - you get what you get. And what I got, I thought, was a slightly defective unit. Sending it oversea cost more than just ordering another.
The DC offset calibration was always a bit off:
Calibrated @ 347500000 Hz: I= 944 (Error: 3.44), Q=1328 (Error: 3.47)
Error values around 3.4? Not great, not terrible. But not what you want from a $400 SDR. I eventually gave up, shoved it in a closet, and bought a HackRF instead. The bladeRF sat there for years, collecting dust, while Nuand dropped the price and I told myself I'd gotten a lemon from a bad batch.
Then I tested it on FreeBSD.
Calibration failed immediately. Timeout errors everywhere. But that's what led me to the bug.
libusb_handle_events_timeout() returns LIBUSB_ERROR_TIMEOUT when the timeout expires with no events. That's not an error, the function working as documented. But the bladeRF driver was treating it as unexpected:
if (status < 0 && status != LIBUSB_ERROR_INTERRUPTED) {
log_warning("unexpected value from events processing...");
status = error_conv(status);
}That error_conv() call was corrupting the event loop timing. On Linux, the calibration "completed" — but with garbage results. The bug didn't blow up. It just silently poisoned the data.
One two-line fix:
if (status < 0 && status != LIBUSB_ERROR_INTERRUPTED &&
status != LIBUSB_ERROR_TIMEOUT) {After the fix:
Calibrated @ 347500000 Hz: I= 944 (Error: 0.41), Q=1328 (Error: 0.42)
My "defective" SDR now calibrates perfectly.
The hardware was never broken. The driver bug silently corrupted calibration for years. I spent years thinking I had bad hardware because error values of 3.4 looked like "marginal hardware" rather than "broken software."
FreeBSD didn't fix my SDR but testing on FreeBSD forced me to actually debug the problem instead of living with silent corruption.
Pushed the fix upstream. If your bladeRF calibration has always been "a bit off", try this patch.
-
Remember when I said driver development isn't linear ? Here is another chapter.
I have had a bladeRF SDR for years. Brought to Morocco, where returning defective hardware isn't really an option - you get what you get. And what I got, I thought, was a slightly defective unit. Sending it oversea cost more than just ordering another.
The DC offset calibration was always a bit off:
Calibrated @ 347500000 Hz: I= 944 (Error: 3.44), Q=1328 (Error: 3.47)
Error values around 3.4? Not great, not terrible. But not what you want from a $400 SDR. I eventually gave up, shoved it in a closet, and bought a HackRF instead. The bladeRF sat there for years, collecting dust, while Nuand dropped the price and I told myself I'd gotten a lemon from a bad batch.
Then I tested it on FreeBSD.
Calibration failed immediately. Timeout errors everywhere. But that's what led me to the bug.
libusb_handle_events_timeout() returns LIBUSB_ERROR_TIMEOUT when the timeout expires with no events. That's not an error, the function working as documented. But the bladeRF driver was treating it as unexpected:
if (status < 0 && status != LIBUSB_ERROR_INTERRUPTED) {
log_warning("unexpected value from events processing...");
status = error_conv(status);
}That error_conv() call was corrupting the event loop timing. On Linux, the calibration "completed" — but with garbage results. The bug didn't blow up. It just silently poisoned the data.
One two-line fix:
if (status < 0 && status != LIBUSB_ERROR_INTERRUPTED &&
status != LIBUSB_ERROR_TIMEOUT) {After the fix:
Calibrated @ 347500000 Hz: I= 944 (Error: 0.41), Q=1328 (Error: 0.42)
My "defective" SDR now calibrates perfectly.
The hardware was never broken. The driver bug silently corrupted calibration for years. I spent years thinking I had bad hardware because error values of 3.4 looked like "marginal hardware" rather than "broken software."
FreeBSD didn't fix my SDR but testing on FreeBSD forced me to actually debug the problem instead of living with silent corruption.
Pushed the fix upstream. If your bladeRF calibration has always been "a bit off", try this patch.
PR for the curious : https://github.com/Nuand/bladeRF/pull/1052
-
undefined stefano@mastodon.bsd.cafe shared this topic