[USRP-users] USRP N310 Losing Connection Occassionally

Marcus D. Leech patchvonbraun at gmail.com
Sat Nov 23 18:28:32 EST 2019


On 11/23/2019 06:24 PM, Austin Adam wrote:
> For testing, I just put a simple signal source, added a head block, 
> and then a QT Time sink and it seems to just go for a second and 
> freeze. I am sure this is the correct way to do it. When it issues the 
> 'done' is it supposed to close? Or send a message? Or change some 
> variable that I then have to check in the code?
When a block marks "done", that propagates inwards, and it's possibly 
the case that the QT blocks don't honor that?

Try it with something like a null sink, or a file sink going to 
/dev/null, and see that it nicely terminates--configure your block for 
"no gui" and
   "exit when done".

This question is drifting more into Gnu Radio land, so if this drifts 
into straight-up Gnu Radio territory, the discussion should be held on
   the discuss-gnuradio mailing list--where there are more people who 
have opinions about GR "stuff".


>
> On Sat, Nov 23, 2019 at 3:17 PM Marcus D. Leech 
> <patchvonbraun at gmail.com <mailto:patchvonbraun at gmail.com>> wrote:
>
>     On 11/23/2019 06:06 PM, Austin Adam wrote:
>>     So I just put it in between my source and sink and when it hits
>>     lets say 1000000 samples, it will automatically terminate the
>>     script? I just tried doing it and it doesn't seem to be working,
>>     it just sort of freezes up after about a second. Maybe I am not
>>     doing it correctly..
>     You put it after your source, and the rest of the graph is the same.
>
>     If it just "freezes up", that's, I think, unexpected, and may
>     indicate some deficiencies in flowgraph shutdown on N3xx hardware.
>
>     What does you GR script look like?
>
>
>>
>>     On Sat, Nov 23, 2019 at 2:55 PM Marcus D. Leech
>>     <patchvonbraun at gmail.com <mailto:patchvonbraun at gmail.com>> wrote:
>>
>>         On 11/23/2019 05:48 PM, Austin Adam wrote:
>>>         Hey Marcus,
>>>         Thank you for the quick response! This sounds like a good
>>>         solution, could you give some insight on how to go about
>>>         doing it?
>>>
>>>         Thank you so much!
>>         The "head" block takes a number, which is the count of
>>         samples that it will allow through it before it declares
>>         "Done", and thus causes
>>           clean termination of your GR Script.
>>
>>
>>>
>>>         On Sat, Nov 23, 2019 at 2:32 PM Marcus D. Leech via
>>>         USRP-users <usrp-users at lists.ettus.com
>>>         <mailto:usrp-users at lists.ettus.com>> wrote:
>>>
>>>             On 11/23/2019 03:49 PM, Austin Adam via USRP-users wrote:
>>>>             I am trying to run a Gnu Radio python file via the
>>>>             terminal and only want to run in for a few seconds and
>>>>             then kill it. Then, wait a little bit, and rerun the
>>>>             script again. My problem is that sometimes, when I
>>>>             rerun it, I get an issue with my USRP N310 in that it
>>>>             decides to just disconnect with either a "No devices
>>>>             found for" or "Someone tried to claim this device
>>>>             again" message. I have posted the error messages below
>>>>             from two different instances.
>>>>
>>>>             When this happens, running uhd_find_devices does not
>>>>             find the N310, neither does uhd_find_devices
>>>>             --args=addr=192.168.10.2.
>>>>
>>>>             Upon restarting the N310 by manually pressing the power
>>>>             button, it is able to be found by uhd_find_devices, and
>>>>             I can continue running the script until the error
>>>>             happens, and I have to go manually restart the USRP.
>>>>
>>>>             I am trying to make an entire automated system and this
>>>>             is the one thing that requires manual effort, which is
>>>>             to get up and restart the USRP.
>>>>
>>>>             I am looking for a way to either, reboot the USRP via
>>>>             commands for when the error occurs, or a
>>>>             solution/workaround to the problem if it exists.
>>>>
>>>>             Is there any way to keep the USRP claimed and just tell
>>>>             the GNU part of the script to run each time I want to
>>>>             rerun it? Because each time I have to run the script,
>>>>             the USRP has to again be claimed and initiated. How can
>>>>             I keep it on at all times, or just skip the claiming
>>>>             step each time?
>>>>
>>>>             Thank you in advance for any help you can provide!
>>>>
>>>>             Here are the error messages:
>>>>             /[INFO] [UHD] linux; GNU C++ version 8.3.0;
>>>>             Boost_106700; UHD_3.14.0.HEAD-0-g6875d061/
>>>>             /Traceback (most recent call last):
>>>>               File
>>>>             "/home/ugikie/Desktop/PositionControl/ArrayTest2.py",
>>>>             line 296, in <module>
>>>>                 main()
>>>>               File
>>>>             "/home/ugikie/Desktop/PositionControl/ArrayTest2.py",
>>>>             line 284, in main
>>>>                 tb = top_block_cls()
>>>>               File
>>>>             "/home/ugikie/Desktop/PositionControl/ArrayTest2.py",
>>>>             line 79, in __init__
>>>>                 channels=range(4),
>>>>               File
>>>>             "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/__init__.py",
>>>>             line 122, in constructor_interceptor
>>>>                 return old_constructor(*args)
>>>>               File
>>>>             "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py",
>>>>             line 2782, in make
>>>>                 return _uhd_swig.usrp_source_make(*args)
>>>>             RuntimeError: LookupError: KeyError: No devices found
>>>>             for ----->
>>>>             Device Address:
>>>>                 addr: 192.168.10.2
>>>>                 rx_lo_source: external
>>>>                 init_cals:
>>>>             BASIC|TX_ATTENUATION_DELAY|RX_GAIN_DELAY|PATH_DELAY|TX_LO_LEAKAGE_INTERNAL|LOOPBACK_RX_LO_DELAY/
>>>>             /
>>>>             /
>>>>             *Here is the second time it happened:*
>>>>             /[INFO] [UHD] linux; GNU C++ version 8.3.0;
>>>>             Boost_106700; UHD_3.14.0.HEAD-0-g6875d061
>>>>             [INFO] [MPMD] Initializing 1 device(s) in parallel with
>>>>             args:
>>>>             mgmt_addr=192.168.10.2,type=n3xx,product=n310,serial=3177E63,claimed=True,addr=192.168.10.2,rx_lo_source=external,init_cals=BASIC|TX_ATTENUATION_DELAY|RX_GAIN_DELAY|PATH_DELAY|TX_LO_LEAKAGE_INTERNAL|LOOPBACK_RX_LO_DELAY
>>>>             [ERROR] [RPC] Someone tried to claim this device again
>>>>             (From: 192.168.10.1)
>>>>             Traceback (most recent call last):
>>>>               File
>>>>             "/home/ugikie/Desktop/PositionControl/ArrayTest2.py",
>>>>             line 296, in <module>
>>>>                 main()
>>>>               File
>>>>             "/home/ugikie/Desktop/PositionControl/ArrayTest2.py",
>>>>             line 284, in main
>>>>                 tb = top_block_cls()
>>>>               File
>>>>             "/home/ugikie/Desktop/PositionControl/ArrayTest2.py",
>>>>             line 79, in __init__
>>>>                 channels=range(4),
>>>>               File
>>>>             "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/__init__.py",
>>>>             line 122, in constructor_interceptor
>>>>                 return old_constructor(*args)
>>>>               File
>>>>             "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py",
>>>>             line 2782, in make
>>>>                 return _uhd_swig.usrp_source_make(*args)
>>>>             RuntimeError: RuntimeError: Error during RPC call to
>>>>             `claim'. Error message: Someone tried to claim this
>>>>             device again (From: 192.168.10.1)/*
>>>>             *
>>>>
>>>>             i\
>>>             Instead of interrupting the GR script, you could use the
>>>             "Head" block to have it run for a finite number of
>>>             samples, then exit gracefully.
>>>               When you interrupt it, some things are clearly not
>>>             getting cleaned up gracefully.
>>>
>>>
>>>
>>>             _______________________________________________
>>>             USRP-users mailing list
>>>             USRP-users at lists.ettus.com
>>>             <mailto:USRP-users at lists.ettus.com>
>>>             http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20191123/a586925b/attachment.html>


More information about the USRP-users mailing list