discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] Multiple USRP N210s: LEDs and Ethernet lights on


From: Josh Blum
Subject: Re: [Discuss-gnuradio] Multiple USRP N210s: LEDs and Ethernet lights on after program termination
Date: Thu, 31 May 2012 11:41:31 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1


On 05/30/2012 08:52 AM, Ryan Wolfarth wrote:
> Problem solved!  rx_samples_to_file doesn't include a stream_cmd_stop!
> Here's our fix:
> 
> Add the following after line 93 (outfile.close()):
> 
> if(!num_requested_samples){
> uhd::stream_cmd_t
> stream_cmd_stop(uhd::stream_cmd_t::STREAM_MODE_STOP_CONTINUOUS);
> usrp->issue_stream_cmd(stream_cmd_stop);
> }
> 
> This seems to do the trick.  The C debug light is off as is the Ethernet
> link activity light!
> 

Ah, that makes sense. Thanks for the patch.

I wonder a little bit what happens with this supposed ICMP packet I
mentioned. But its just kind of a handy nicety, so I wouldn't worry
about it.

-Josh

> -Ryan
> 
> On Wed, May 30, 2012 at 11:35 AM, Darren Long <address@hidden> wrote:
> 
>> I've noticed that when stopping a GRC sketch and starting another, I get
>> unknown stream ID reports from my B100, requiring a restart of the USRP to
>> recover. This used to happen a while back, but was fixed. Perhaps the fix
>> has been broken or the issue is similar.
>>
>> Darren
>>
>> Sent from my iPhone
>>
>> On 30 May 2012, at 16:23, Ryan Wolfarth <address@hidden> wrote:
>>
>> Hi Josh,
>>
>> Thanks for your quick reply!  We are actually using rx_samples_to_file as
>> a first attempt at benchmarking the systems data transfer speed.  We give a
>> proper crtl+c whenever we terminate the program, but the problem persists.
>> We tried rx_timed_samples per your recommendation and found that the port
>> and USRP terminated properly.  The program doesn't seem to be modified from
>> previous releases, so my first blind guess is that there could be an issue
>> with the interface on one side of our network card (Intel 82576 Gigabit
>> controller).
>>
>> Due to the simplicity of our data collection scheme, we will probably
>> modify rx_samples_to_file to respond to an external trigger.  So if we
>> could get the example working properly that would be a great starting
>> point.  Do you have any more ideas?
>>
>> Thanks again,
>> Ryan
>>
>> On Tue, May 29, 2012 at 11:09 PM, Josh Blum <address@hidden> wrote:
>>
>>>
>>>
>>> On 05/29/2012 05:36 PM, Ryan Wolfarth wrote:
>>>> Hi list,
>>>>
>>>> We've setup 4 USRP N210 rev4s with a Dell PowerEdge R510 server to
>>> collect
>>>> RF data for GPS related experiments.  The server works great and we
>>> seem to
>>>> be able to write 20 Msps from each device simultaneously to a RAID array
>>>> with no overflows.  However, after each collection program is
>>> terminated,
>>>> the Ethernet and debugging LEDs (C, D, blinking E, and F) remain on.  We
>>>> tested this with a single device with the same result.  Does anybody
>>> know
>>>> the cause of this and if we should be worried?  We're running UHD 3.4.2
>>>> (downloaded 2 days ago).  All N210s were updated with the firmware/image
>>>> downloaded from the same version and compiled from source using GNU ZPU
>>>> Tools and Xilinx ISE 13.1 respectively.  The server is running 64-bit
>>>> Ubuntu 12.04.  Any help is appreciated!
>>>>
>>>
>>> http://files.ettus.com/uhd_docs/manual/html/usrp2.html#front-panel-leds
>>>
>>> I would only really be worried about C which means the device is still
>>> sending samples out of the ethernet port. This can happen if the
>>> streaming isnt properly shutoff like ctrl+c or destructors not being
>>> called.
>>>
>>> Additionally, (if it is still streaming) the USRP isnt getting an ICMP
>>> destination unreachable from the host when the socket on the host
>>> closes. Its possible that due to your network setup that this packet
>>> doesnt get generated and/or delivered.
>>>
>>> If it is the deconstructor issue, sometimes its useful in gr python apps
>>> to set the top block object to None to help python garbage collect it.
>>>
>>> tb.stop()
>>> tb = None
>>>
>>> I would also see if things shutoff as expected when your run one of the
>>> included examples such as rx_timed_samples
>>>
>>> Hope that helps!
>>> -josh
>>>
>>> _______________________________________________
>>> Discuss-gnuradio mailing list
>>> address@hidden
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
> 



reply via email to

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