[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] [USRP-users] Gnu Radio apps freezes (locks up)

From: Nazmul Islam
Subject: Re: [Discuss-gnuradio] [USRP-users] Gnu Radio apps freezes (locks up)
Date: Tue, 27 Nov 2012 10:08:50 -0500

<<Another question, what the app locks up, what makes it recover? Reload
app, power cycle user, replug eth cable, re ifconfig, restart PC?>>

In my case, I had to press ctrl+C and then restart the code to make it work.



On Tue, Nov 27, 2012 at 1:13 AM, Josh Blum <address@hidden> wrote:

> I have now played with the wireshark.
> I do not get what you suggest "ICMP destination unreachable packet"
> or something similar. The only "ICMP" protocol related is when I
> connect the device and setting up the ip address, but no "unreachable
> packets" or similar during the uhd run. When running there are only
> UDP frames/protocol.
> Instead, however, I discovered some really suspect behavior with the
> ports changing wildly back and forth on both the device and host, and
> UDP packet/frame size then change much too. This happens both in the
> beginning of the streaming (see attached packets 241--287), then
> after a while it settles to the requested (constant) packet size
> (3050 bytes, close to the requested 3008 bytes) and the ports becomes
> fixed (see packets 1271-1277) .
> But then in the end, when it all fails, the ports on the device and
> host suddenly change again and the packets becomes very small, like
> 58 or 60 bytes only (see packets 211078 --). The little actual data
> in those failing packets seem quite odd too.

The packets in the dump all look quite normal. If it helps, here is the
mapping for the ports from fw_common.h

#define USRP2_UDP_CTRL_PORT 49152
//#define USRP2_UDP_UPDATE_PORT 49154
#define USRP2_UDP_RX_DSP0_PORT 49156
#define USRP2_UDP_TX_DSP0_PORT 49157
#define USRP2_UDP_RX_DSP1_PORT 49158
#define USRP2_UDP_FIFO_CRTL_PORT 49159
#define USRP2_UDP_UART_BASE_PORT 49170
#define USRP2_UDP_UART_GPS_PORT 49172

> Please find the transcript of the mentioned and seemingly crucial
> packages from the beginning and the end when the UHD communication
> fails. Note the selected packets' numbering. The wireshark captured
> the command: uhd_fft -a "addr=, recv_frame_size=3008"  -s
> 25e6

Is the behavior any different when the recv_frame_size is
unspecified/aka left default MTU?

Another question, what the app locks up, what makes it recover? Reload
app, power cycle user, replug eth cable, re ifconfig, restart PC?


USRP-users mailing list

Muhammad Nazmul Islam

Graduate Student
Electrical & Computer Engineering
Wireless Information & Networking Laboratory
Rutgers, USA.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]