Windows: PlutoSDRInputThread::run: error refilling buf. libusb version issue

[beta-tester]

hi, i need your help...

i have a strange issue on a notebook i use. SDRangel throws, after 5seconds to 10minutes, an error PlutoSDRInputThread::run: error refilling buf (1) -138 / 32768 in the log file and the spectrum and waterfall stops working. i have to reopen SDRangel to be able to use it for a next run. stopping the sdr source is not able or when i try to refresh the SDR source list, SDRangel crash/closes after some freezing time.

the error happens on the notebook only. on my desktop pc SDRangel works stable.

any idea what can be the reason? i reinstalled the PlutoSDR driver for windows already with no success. also using different USB ports won't make things better.

the hardware of the notebook: CPU i7-4510U + GPU on die, onboard nVIDIA GeForce GT 750M, Windows 10 Pro x64 (1809 fresh installation), vc 2010 redistributable (x64), vc 2013 redistributable (x64), vc 2017 redistributable (x64) are installed, PlutoSDR with firmware v0.30

tested versions of SDRAngel: v4.2.3 ... v4.4.1. all shows the issue...

sdrangel_v4.2.3.log sdrangel_v4.2.4.log sdrangelms_v4.4.1.log

[f4exb]

The interesting part:

2019-01-21 14:15:34.361 (W) PlutoSDRInputThread::run: error refilling buf (1) -5 / 32768
2019-01-21 14:15:39.591 (W) PlutoSDRInputThread::run: error refilling buf (1) -138 / 32768
2019-01-21 14:15:44.811 (W) PlutoSDRInputThread::run: error refilling buf (1) -138 / 32768
... and so on

Which comes from:

        // Refill RX buffer
        nbytes_rx = m_plutoBox->rxBufferRefill();

        if (nbytes_rx != m_blockSizeSamples*2)
        {
            qWarning("PlutoSDRInputThread::run: error refilling buf (1) %d / %d",(int) nbytes_rx, (int)  m_blockSizeSamples*2);
            usleep(200000);
            continue;
        }

rxBufferRefill calls a method of IIO library and the return value is simply passed back:

ssize_t DevicePlutoSDRBox::rxBufferRefill()
{
    if (m_rxBuf) {
        return iio_buffer_refill(m_rxBuf);
    } else {
        return 0;
    }
}

Now this value is supposed to be the number of bytes returned but since it is a negative value it seems to indicate an error code which according to libiio documentation is an errno code.

-5 (errno 5) designates an I/O error. -138 has no special meaning but since it comes after basically anything can happen.

In any case this is an error from the underlying library so there's nothing that can be done at application level.

v4.2.3 and v4.2.4 on one hand and v4.4.1 on the other hand are built entirely differently with MinGW and MSVC respectively. Experiencing the same error in both cases seem to designate a problem of communication with the Pluto rather than a library issue.

[beta-tester]

i just tested few more older SDRangel versions... v4.2.0 shows that issue as well, but v4.1.0 i run for an hour without issues...

i'll will keep it running over night to see if it will survive even longer than an hour... any idea, why that version 4.1.0 will survive and all others not?

unfortunately the version 4.1.0 doesn't have the CRC header in the recording and no proper decay 0 handling for the spectrum... otherwise i could live with that version on the notebook.

[f4exb]

I probably overlooked 4.1.0 in a cleanup operation. As a principle you should compile from source and run in Linux. Binary packages should fit many but not all configurations.

[beta-tester]

i can't use linux on that notebook... i guess the build instruction for windows isn't up to date anymote with the new MSVS2017 tool chain... isn't it?

if the compiler options/configuration isn't the reason, i only could identify two/three potentially candidates of changes between 4.1.0 (2018-09-18) and 4.2.0 (2019-10-07) that could be the cause of the issue: Removed explicit SSE2 code in GLSpectrum. Fixes issue #192, ScopeVis: corrected memory index when in trace memory mode, Windows build: upgrade to libusb 1.0.22. Modified install script for …

[f4exb]

The environment to build with MSVC is not made to be easy to work with. For Linux which is the main development platform this has been made easier and more reproducible.

So the changes...

• Cause 1: maybe an issue (performance wise) with old compilers but not with MSVC 2017 or gcc or clang. In 99% of situations It is now counter productive to code vector instructions explicitly. Compilers do this better than you do.
• Cause 2: nothing to do with Pluto nor any device
• Cause 3: (most interesting) libusb 1.0.22 ships with the archive but if for some reason another version gets used then of course this could be an issue.

[rgetz]

We have seen issues with libusb 1.0.22 on some versions of Windows with some of our other software, and needed to downgrade to 1.0.21 to make things work reliably...

https://github.com/analogdevicesinc/scopy-mingw-build-deps/commit/e1405d316cb3fe49c4ace6fdf49ad79b61d4da40

We have been digging into things, but it does seem isolated with Windows, and not anything we are doing wrong.

-Robin

[beta-tester]

thank you guys... i download and replaced the existing libusb-1.0.dll (1.0.22.11312) shipped with SDRangel 4.4.1 with the libusb-1.0.dll (1.0.21.11312) downloaded from sourceforge. fortunately that version is compatible enough to work with SDRangel 4.4.1 (as far as i could see)... at the moment everything looks very good.

passed the first hour... so long, without any issues... i'll tell you, when i hit the issue with that dll

PS.: first i tried to use the libusb-1.0.dll (1.0.20.11004) from SDangel 4.1.0, but that version wasn't compatible to work under SDRangel 4.4.1.

EDIT: just saw, also the desktop PC run into that issue after 1.5 days running non-stop with the libusb-1.0.dll shipped with SDRangel 4.4.1

[beta-tester]

at the moment i would say, with libusb 1.0.21.11312 pluto is working well. on the notebook and desktop SDRangel 4.4.1 ran 8h without hitting the issue.

@rgetz, do the develope(s) of libusb know about the problems of libusb-1.0.22 in combination with libiio and windows?

[beta-tester]

just saw, there is also a new version of libiio available (0.17) https://github.com/analogdevicesinc/libiio/releases

and SDRangel 4.4.1 uses libiio 0.15

[rgetz]

the version of libiio doesn't seem to make a difference. (we have seen the same on 0.15, 0.16, & 0.17). libusb 1.0.21.11312 seems to be more stable than 1.0.22.11312

did we report a bug? I don't think we did - the first thing for a good bug report - we would need start to bisect commits since Oct 2016 (when libusb 1.0.21 was released) and Mar 2018 (release of libusb 1.0.22) - 156 different commits (at least 8 bisects, of running things for a day to see if this is the issue or not) - and for now, it's faster to tell everyone to downgrade :( When we have time - we will send a well formatted bug report.

-Robin

[f4exb]

For libusb I can ship version 1.0.21 for the next version. Thanks for the investigation. The version of libiio is the one of Pothos from which the DLL is just copied.

[rgetz]

If you want to grab the latest (we don't push things to Pothos when we update) - we do provide a windows zip, which should include both minGW and MSVC compiled versions:

https://github.com/analogdevicesinc/libiio/releases/latest grab the windows.zip, it has minGW32, minGW64, MS32, MS64

The 0.17 link is : https://github.com/analogdevicesinc/libiio/releases/download/v0.17/libiio-0.17.g5bdc242-Windows.zip

[beta-tester]

@f4exb thank you for downgrading libusb to 1.0.21 in sdrangel v4.4.2... i teted it an it runs well. you can close that issue, if you want.

[f4exb]

Good thanks for verifying!