discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] set_command_time ack timeout issue


From: Marcus Müller
Subject: Re: [Discuss-gnuradio] set_command_time ack timeout issue
Date: Wed, 04 Sep 2013 10:48:49 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130805 Thunderbird/17.0.8

Hi Steve,

Worth it to submit an additional bug noting the fifo timeout for longer 
set_command_time()?  I think that it > is merely an additional symptom of the 
issue you found.

No, actually I think your timeout after set_command_time is not /really/ a bug, 
actually.
The gr-uhd usrp_source uses uhd::multi_usrp, which your case uses 
uhd/host/lib/usrp/usrp2/usrp2_fifo_ctrl.cpp that has set_time, which gets 
called whenever you issue a timed command. This sets your UHD timeout to 
MASSIVE_TIMEOUT (same file, == 10s), so that wait_for_ack (same file) throws 
your runtime error.

So, basically, unless you don't modify your uhd sources, the wisest solution to 
your problem seems to be not letting something happen more than 10s in the 
future.

Hope that helped,
Marcus Müller
On 09/04/2013 02:59 AM, Steve Zygmunt wrote:
could you try if http://gnuradio.org/redmine/issues/584 applies to you as well? 
Thanks, Marcus Müller
I was wondering if anyone could give some insight into how the 
set_command_time() command handles the ack.  I am having an issue where the 
system/thread locks waiting for an ACK from a set_center_freq() or if the 
set_command_time is far enough in the future then the fifo ctrl times out with:

   File 
"/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/gnuradio/uhd/uhd_swig.py",
 line 2827, in set_center_freq
     return _uhd_swig.usrp_source_sptr_set_center_freq(self, *args)
RuntimeError: RuntimeError: fifo ctrl timed out looking for acks

The end goal I am trying to achieve is to tune at a specific time.  The only 
other approach to solve that I can see is to add a tune flag to the stream and 
modify the gr-uhd and uhd software to handle appropriately, which I would 
rather not open that can of worms if I don't have to.  Any advice would be 
greatly appreciated.


System:
Mac Laptop with 10.8 with USRP N210
Macports gnuradio-devel @3.7.1_20130821
Macports uhd @003_005_003



reply via email to

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