Set_command_time ack timeout issue

GNU Radio
1

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

2

Ah ok, it is a misunderstanding of mine of how the set_command_time()
works then. I was under the impression that the command will still
return immediately but instead, any command given after the
set_command_time will then hang until the ACK is passed back after the
command executes. Will have to experiment some more to find a solution
that works. Thanks for the info.

3

On 09/04/2013 11:19 AM, Steve Zygmunt wrote:

Ah ok, it is a misunderstanding of mine of how the set_command_time() works
then. I was under the impression that the command will still return immediately
but instead, any command given after the set_command_time will then hang until the
ACK is passed back after the command executes. Will have to experiment some more
to find a solution that works. Thanks for the info.

If that’s the case, put those commands in a separate thread that’s OK to
block.

–
Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium

4

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.