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 <patchvonbr...@gmail.com <mailto:patchvonbr...@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@lists.ettus.com <mailto:usrp-users@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@lists.ettus.com <mailto:USRP-users@lists.ettus.com>
        http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com



_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Reply via email to