On 09/14/2015 07:03 AM, Chad R wrote:
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?
Are you using different sample rates in the two scenarios?
That assertion indicates that there are seriously-bad things happening
to USB packets across the USB bus.
On Sun, Sep 13, 2015 at 6:03 PM, Marcus D. Leech <mle...@ripnet.com
<mailto: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
<mailto: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 <mailto: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 <mailto: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
<mailto: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
