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

[Rickard]

On 26 nov 2012, at 13:56, Rickard <address@hidden> wrote:

> 
> On 26 nov 2012, at 13:43, Josh Blum <address@hidden> wrote:
> 
>> 
>>> Even if I just run an example with UHD-->Null sink (that is without any 
>>> rendering GUI) I get the exact same problem that samples stop coming after 
>>> a short period of time. 
>>> Or if I just try to save the samples to a file it stalls/stops and I can 
>>> only save relative few samples.
>>> 
>>> I think what Patrik describes in his responses is probably a different 
>>> issue which I sometimes also have experienced, but relates to the GUI, not 
>>> necessarily the UHD communication.
>>> In my case, the samples just stops coming from the device so I believe its 
>>> UHD related. 
>>> 
>>> IMPORTANT NOTE: The green LED labeled C on the N210 goes from a steady ON 
>>> (when samples are delivered) to suddenly OFF at the instant when samples 
>>> stop coming to the host computer.
>>> Also, the large orange LED goes from a steady ON when samples are streamed 
>>> to very rapidly blinking at the instant when samples stop coming.
>>> Finally, not until I abort the stalled application the fast blinking orange 
>>> LED turns off completely again. 
>>> 
>> 
>> 
>> LED C means the DSP is in RX mode. If continuous streaming is on, 3
>> things can cause this light to shutoff:
>> 
>> 1) a stop streaming command packet (from issue stream command)
>> 2) overflow in the device. This never happens on the network devices
>> unless the sample rate is > 25e6 and the wire format is still sc16
>> 3) ICMP destination unreachable packet. This usually comes when the
>> kernel sees that a destination socket is not open.
>> 
>> I think you can eliminate 1 and 2. Can you confirm 3 with a wireshark run?
>> 
> 
> Thanks. I will try but I am not so familiar with wireshark. 
> Just briefly tried to use it but it was not trivial to set up, as I recall.
> 
> / Rickard
> 
>> -josh
> 


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.

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=192.168.10.2, recv_frame_size=3008"  -s 25e6

Does this give any clues?

/ Rickard

eth0_uhd_dump_short.txt
Description: Text document