Awesome. Thank you I got it to work in gnuradio-companion however now when I try to implement it in my python project I get the error.
thread[thread-per-block[3]: <block gr uhd usrp source (1)>]: EnvironmentError: IOError: Radio ctrl (0) packet parse error - AssertionError: packet_info.packet_count == (seq_to_ack & 0xfff) in uint64_t radio_ctrl_core_3000_impl::wait_for_ack(bool) at /home/ubuntu/git/uhd/host/lib/usrp/cores/radio_ctrl_core_3000.cpp:264 where thread per block changes between 2 and 3 and the gr block changes between source and sink. Is this an error caused due to the limitations of my hardware? On Sun, Sep 13, 2015 at 6:03 PM, Marcus D. Leech <mle...@ripnet.com> wrote: > On 09/13/2015 07:02 AM, Chad R wrote: > > Hi Marcus I tried what you said and I'm still getting the overflow errors. > I've attached a link of my flowgraph if it will maybe help to solve this > issue. > http://imgur.com/yI96ZMw > > Ah. > > Bundle them into a single multi-channel USRP source/sink. > > There's no support for the two channels being spread across different UHD > multi_usrp objects. > > > > > On Sun, Sep 13, 2015 at 1:01 PM, Chad R <chadric...@gmail.com> wrote: > >> Hi Marcus I tried what you said and I'm still getting the overflow errors. >> I've attatched a link of my flowgraph if it will maybe help to solve this >> issue. >> http://imgur.com/yI96ZMw >> >> On Sat, Sep 12, 2015 at 3:26 PM, Marcus D. Leech <mle...@ripnet.com> >> wrote: >> >>> On 09/12/2015 08:30 AM, Chad R wrote: >>> >>> Thanks for the advice Marcus >>> >>> However I updated UHD to version 3.9 the latest stable release from the >>> ettus binary files and I'm still getting the error but now instead of just >>> DDDDD its randomly S's and D's. The S's is a sequence error? >>> >>> Yes, S and D are closely related. >>> >>> I think that you're running into the "symmetry required" issue. So, >>> you'll need a 2nd TX channel in your flow, with just 0s in it. >>> >>> >>> >>> >>> On Fri, Sep 11, 2015 at 4:21 PM, Marcus D. Leech <mle...@ripnet.com> >>> wrote: >>> >>>> On 09/11/2015 07:56 AM, Chad R wrote: >>>> >>>>> Good day. >>>>> >>>>> I'm wondering if you can help me. I have a B210 board connected to a >>>>> jetson tk1 and I am trying to send over one port and receive over two. The >>>>> hardware setup is the RX/TX board connected to an RF filter connected to a >>>>> splitter and the connected to the two RX2 ports. When I run one TX and one >>>>> RX I have no issues however when I run 2 RX my python application crashes. >>>>> I try run a simple 2 Rx configuration in GNU Radio with the 2 USRP sources >>>>> connected to 2 Frequency GUI. >>>>> However even running at a sampling rate of 64Kbps I am getting an >>>>> overflow error. I thought that maybe the jetson tk1 couldn't handle the >>>>> bandwidth but running it on my PC I get the same results. The output is as >>>>> follows: >>>>> >>>>> Executing: "/home/chad/Tx1_Rx2.py" >>>>> >>>>> linux; GNU C++ version 4.8.2; Boost_105400; >>>>> UHD_003.008.001-42-g8c87a524 >>>>> >>>>> -- Operating over USB 3. >>>>> -- Initialize CODEC control... >>>>> -- Initialize Radio control... >>>>> -- Performing register loopback test... pass >>>>> -- Performing register loopback test... pass >>>>> -- Performing CODEC loopback test... pass >>>>> -- Performing CODEC loopback test... pass >>>>> -- Asking for clock rate 32.000000 MHz... >>>>> -- Actually got clock rate 32.000000 MHz. >>>>> -- Performing timer loopback test... pass >>>>> -- Performing timer loopback test... pass >>>>> -- Setting master clock rate selection to 'automatic'. >>>>> -- Asking for clock rate 32.768000 MHz... >>>>> -- Actually got clock rate 32.768000 MHz. >>>>> -- Performing timer loopback test... pass >>>>> -- Performing timer loopback test... pass >>>>> -- Successfully tuned to 100.000000 MHz >>>>> -- >>>>> -- Asking for clock rate 32.768000 MHz... OK >>>>> -- Successfully tuned to 100.000000 MHz >>>>> -- >>>>> -- Asking for clock rate 32.768000 MHz... OK >>>>> -- Successfully tuned to 100.000000 MHz >>>>> -- >>>>> Using Volk machine: avx_64_mmx >>>>> -- Asking for clock rate 32.768000 MHz... OK >>>>> -- Asking for clock rate 32.768000 MHz... OK >>>>> -- Asking for clock rate 32.768000 MHz... OK >>>>> -- Asking for clock rate 32.768000 MHz... OK >>>>> -- Asking for clock rate 32.768000 MHz... OK >>>>> -- Asking for clock rate 32.768000 MHz... OK >>>>> DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDS >>>>> >>>>> Surely I shouldn't get overflow errors at such a low sampling rate? >>>>> When I run the benchmark_rate it returns no errors. Any help would be >>>>> appreciated. >>>>> >>>>> Chad >>>>> >>>>> >>>>> >>>> Update to a newer UHD (and matching firmware), and try your test >>>> again. My recollection is that there was a restriction for TX/RX >>>> applications >>>> on B210 that they had to be symmetric with respect to number of TX/RX >>>> streams. >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Discuss-gnuradio mailing list >>>> Discuss-gnuradio@gnu.org >>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>>> >>> >>> >>> >> > >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
