Re: Error when using UHD, GRC

GNU Radio
1

Hi,

 OK, the uhd_find_devices --args="type=usrp1" is working, there's no

device
discovery error message, but when I tried to run the uhd_usrp_probe
–args=“type=usrp1” the uhd_usrp_probe broke down giving a nice error
message:

“uhd_usrp_probe.exe has encountered a problem and needs to close. We
are sorry
for the inconvenience.”

If I disconnect from the Internet (I have internet connection on PPPOE)
then I
don’t get any error when running uhd_find_devices.exe instead when I
run uhd_usrp_probe.exe I get the mentioned error. I even tried to
disable Local
Area Network, and VirtualBox Network, but the error is there.

I tried many packet sniffer (TCP, UDP) programs but there’s no data
transfer (I
couldn’t find any packet sent by UHD) when running uhd_usrp_probe
–args=“type=usrp1” therefore it might be some error in the test
program uhd_usrp_probe before sending out any packet.

What could be the problem?

Thank,

Best Regards,
Mark.

From: Josh B. [email protected]
To: Mark Colin [email protected]
Cc: [email protected]
Sent: Wed, April 27, 2011 3:13:39 AM
Subject: Re: Error when using UHD, GRC

On 04/26/2011 04:59 PM, Mark Colin wrote:

Hi Josh,

I have an USRP1 working on USB therefore it shouldn’t give such kind of
errors like “Error: An existing connection was forcibly closed by the remote
host”?

Sorry, I missed that it was a USB based USRP. Even though its USB, the
discovery logic still tries to send out broadcast packets to your
network interfaces. (I am assuming that this error is a network issue.)

I think if you add these arguments, the discovery logic wont attempt to
search the network.

uhd_find_devices --args=“type=usrp1”
uhd_usrp_probe --args=“type=usrp1”

It still might be worth it to fix the issue. Maybe disable a few extra
network interfaces (or virtual ones like VPN). I have no idea, so I am
curious as to what might cause this.

-josh

I assume you did do this:
http://code.ettus.com/redmine/ettus/projects/uhd/wiki#Windows-USB-driver

2

On 04/27/2011 02:34 PM, Mark Colin wrote:

Hi,

 OK, the uhd_find_devices --args="type=usrp1" is working, there's no device

discovery error message, but when I tried to run the uhd_usrp_probe
–args=“type=usrp1” the uhd_usrp_probe broke down giving a nice error message:

“uhd_usrp_probe.exe has encountered a problem and needs to close. We are sorry
for the inconvenience.”

The last time I saw this, was when I learned that the libusb callbacks
needed to be defined w/ a different calling convention. If you got UHD
from this installer then I don’t know the problem:
http://www.ettus.com/downloads/uhd_releases/003_000_001/UHD-003.000.001-win32-with-LIBUSB_CALL-fix.exe

If I disconnect from the Internet (I have internet connection on PPPOE) then I
don’t get any error when running uhd_find_devices.exe instead when I
run uhd_usrp_probe.exe I get the mentioned error. I even tried to disable Local
Area Network, and VirtualBox Network, but the error is there.

If I read your message right, then it seems that the interaction between
PPPOE and UHD may be the culprit. But it wasnt consistent between find
and probe? but I would expect them to behave identically.

I tried many packet sniffer (TCP, UDP) programs but there’s no data transfer (I
couldn’t find any packet sent by UHD) when running uhd_usrp_probe
–args=“type=usrp1” therefore it might be some error in the test
program uhd_usrp_probe before sending out any packet.

It may be the act of opening up a socket on that interface for
broadcast.

What could be the problem?

Windows is that nosey neighbor who always manages to get into your house
at those awkward moments; even though you know you locked the door.

-Josh

3

Hi Josh,

thanks for your answer. Anyway if the UHD makes trouble because of the
USRP2
than I decided to build my own UHD.dll from source code with MSVC 2008.
I set in
CMake environment that I don’t want to include USRP2 stuff into the UHD
driver
(it won’t look for USRP2 devices only for USRP1 devices on USB). I
installed
BOOST. I compiled the UHD, I got the DLL and utils files (uhd_usrp_probe
and
uhd_find_devices), I copied the DLL tolocation C:\program files
(x86)\uhd\bin
and the LIB file to location C:\program files (x86)\uhd\lib(both from
D:\uhd\host\build\lib\Release)but it’s not working, so the problem is
due to
paths. I downloaded UHD source code to D:\uhd. Maybe I set wrong some
parameters
in CMake.

Do you have any idea regarding this?

Thanks,

Mark.

From: Josh B. [email protected]
To: Mark Colin [email protected]
Cc: [email protected]
Sent: Thu, April 28, 2011 9:05:44 AM
Subject: Re: Error when using UHD, GRC

On 04/27/2011 02:34 PM, Mark Colin wrote:

The last time I saw this, was when I learned that the libusb callbacks
needed to be defined w/ a different calling convention. If you got UHD
from this installer then I don’t know the problem:
http://www.ettus.com/downloads/uhd_releases/003_000_001/UHD-003.000.001-win32-with-LIBUSB_CALL-fix.exe

If I disconnect from the Internet (I have internet connection on PPPOE) then I

don’t get any error when running uhd_find_devices.exe instead when I
run uhd_usrp_probe.exe I get the mentioned error. I even tried to disable Local

Area Network, and VirtualBox Network, but the error is there.

If I read your message right, then it seems that the interaction between
PPPOE and UHD may be the culprit. But it wasnt consistent between find
and probe? but I would expect them to behave identically.

I tried many packet sniffer (TCP, UDP) programs but there’s no data transfer (I

couldn’t find any packet sent by UHD) when running uhd_usrp_probe
–args=“type=usrp1” therefore it might be some error in the test
program uhd_usrp_probe before sending out any packet.

It may be the act of opening up a socket on that interface for
broadcast.

What could be the problem?

Windows is that nosey neighbor who always manages to get into your house
at those awkward moments; even though you know you locked the door.

-Josh