UHD Error: Device discovery error: input stream error

[Ioannis Kassotakis]

I get repeatedly the error shown at the subject line ( UHD Error: Device discovery error: input stream error)  at the Pothos console.

I run Pothos on win10.

The uhd_usrp_probe also returns the screen below.

The libraries that fail to load are located at those folders and have set PATH to the PothosSDR\lib at the Env_Variables.

However, USRP appears to work fine with other apps, like SDR_Console v3 and HDSDR , which I think that also use UHD driver.

Any ideas where the input stream error comes from??

[Ioannis Kassotakis]

SoapySDRUtil returns the errors below.

Is there a way to adjust down the MTU size from the Pothos Arguments?

If yes, which command?

[Josh Blum]

On 07/09/2017 06:29 AM, Ioannis Kassotakis wrote:

I get repeatedly the error shown at the subject line ( *UHD Error: Device 
discovery error: input stream error*)  at the Pothos console.
I run Pothos on win10.
The uhd_usrp_probe also returns the screen below.
The libraries that fail to load are located at those folders and have set 
PATH to the PothosSDR\lib at the Env_Variables.
However, USRP appears to work fine with other apps, like SDR_Console v3 and 
HDSDR , which I think that also use UHD driver.
Any ideas where the input stream error comes from??

<https://lh3.googleusercontent.com/-Vn4iwdV5QPQ/WWISYaEIwaI/AAAAAAAAARY/_ov1wMM9hIUGU8xiT5hKoqAMhUnA4SMwACLcBGAs/s1600/Usrp_probe.JPG>

It looks like the probe succeeded regardless of the FastSendDatagramThreshold warning on the input stream error. So perhaps its not a problem and thats why apps are generally working without issue, especially if the prints and suppressed. Since both look like network/socket related issues it could be a problem with your networking configuration. I dont know a lot about FastSendDatagramThreshold, but it looks like its a value reported by winsock, and its probably smaller here than on a typical system (just my speculation).

But just to expand on this a little, the usrp driver supports many device types and when you probe or search for them it could be trying to discover any one of those devices and failing. So it might be a harmless error printed when it tries to talk to a specific type of device. You may need to ask the usrp support list which hardware support driver produces this message. But one of the ways to narrow it down could be a process of elimination. If you uhd_usrp_probe --args="type=usrp2" (and etc with other types) Only the specified hardware support driver will be used, so you can see which one causes the error.

Do you also see the error when the usrp2 in the screenshot is completely removed from the system?

----

Secondly, to mention the LibraryLoad issue. There are some other driver support modules that can operate under uhd. Since you arent using these, the error can be ignored. But if you want to fix/investigate: Typically this can happen when a DLL is missing from the PATH in the current console. You might double check that C:/Program FilesPothosSDR/bin is in the PATH. Also, trying to open one of failed to load files in dependency walker can also clue you into which dll might be missing.

Hope that helps,
-josh

[Josh Blum]

On 07/09/2017 05:06 PM, Ioannis Kassotakis wrote:
> SoapySDRUtil returns the errors below.
> Is there a way to adjust down the MTU size from the Pothos Arguments?
> If yes, which command?
>

> <https://lh3.googleusercontent.com/-J6IjAqpT5BQ/WWKoy-W4d7I/AAAAAAAAARs/ltkINH5HMsUbCpQlveraKeS2Y2uGC408QCLcBGAs/s1600/UHD_MTU_error.JPG>

You will have to check the usrp documentation. The devices typically
have either stream arguments and/or device arguments that can adjust the
transfer size, and it may depend on the device. Most of the apps take
some kind of device arguments string or dictionary, even the command
line ones. Also the Pothos SDR source/sink blocks will also take a
separate dictionary for stream args.

Manually setting a smaller transfer size may remove the warning. But
again, I dont think the warning is necessarily a concern. It might not
cause any breakage, it just might mean that buffers in winsock are
taking are taking a different path. Like copied again, instead of using
some internal ring buffer. But thats a guess.

-josh

>
>
> On Sunday, July 9, 2017 at 1:29:35 PM UTC+2, Ioannis Kassotakis wrote:

>> I get repeatedly the error shown at the subject line ( *UHD Error: Device
>> discovery error: input stream error*) at the Pothos console.

>> I run Pothos on win10.
>> The uhd_usrp_probe also returns the screen below.
>> The libraries that fail to load are located at those folders and have set
>> PATH to the PothosSDR\lib at the Env_Variables.
>> However, USRP appears to work fine with other apps, like SDR_Console v3
>> and HDSDR , which I think that also use UHD driver.
>> Any ideas where the input stream error comes from??
>>
>>

>> <https://lh3.googleusercontent.com/-Vn4iwdV5QPQ/WWISYaEIwaI/AAAAAAAAARY/_ov1wMM9hIUGU8xiT5hKoqAMhUnA4SMwACLcBGAs/s1600/Usrp_probe.JPG>
>>
>>
>>
>>
>>

[Ioannis Kassotakis]

Josh,

I get the " UHD Error:Device discovery error-Input stream Error " even if I disconnect USRP2, but I would think that this is normal : It cannot find a device that is not there.

Regarding the library error, I set the Path to the exact folder but I still get the error message.

I think that the problem may indeed be with the MTU size and eventual buffer oveload, because I get some occasional DDDD on the terminal, which I believe means Dropped packages.

Also, some times the Uhd_Find_Devices fails to find the USRP2 or it finds it with wrong S/N (4096) and type, meaning corrupted communication.

The Pothos topologies with USRP2 and uhd appear to work, but I get on the terminal continuously the annoying error at the message window:

[Josh Blum]

On 07/10/2017 04:56 PM, Ioannis Kassotakis wrote:
> Josh,
> I get the " UHD Error:Device discovery error-Input stream Error " even if I
> disconnect USRP2, but I would think that this is normal : It cannot find a
> device that is not there.
> Regarding the library error, I set the Path to the exact folder but I still
> get the error message.
>
> I think that the problem may indeed be with the MTU size and eventual
> buffer oveload, because I get some occasional DDDD on the terminal, which I
> believe means Dropped packages.
> Also, some times the Uhd_Find_Devices fails to find the USRP2 or it finds
> it with wrong S/N (4096) and type, meaning corrupted communication.
>
> The Pothos topologies with USRP2 and uhd appear to work, but I get on the
> terminal continuously the annoying error at the message window:
>

> <https://lh3.googleusercontent.com/-Yo17aSzo41U/WWP2VwEIMMI/AAAAAAAAAR8/UL4koboJ9cgQgpnkMda9B-ay1Pxh0MSoQCLcBGAs/s1600/UHD%2BDisc%2BError.JPG>

That is annoying. We are trying to discover which devices are available
in the background. That in itself shouldnt be an issue usually...

I'm speculating that its one of the network related drivers in UHD is
printing the error (it may not be usrp2). I dont think that the
discovery API is supposed to cause prints, even when a connection fails,
so its probably a bug.

The windows installer is just packaging UHD from the maint branch which
should be the most stable; so the best I can do is upload a new
installer after bugs are fixed. You may have to let the usrp support
channel know that they have an uncaught exception (or whatever it is);
and same for the MTU issue which might be a missing socket configuration
option.

Other than that, I'm happy to put out new installers. But the hardware
guys have to fix their bugs too :-)

-josh