Good day Marcus I am using the most recent version of UHD. The problem I was encountering was due to the USB buffer not clearing before the next data being loaded. This was solved by adding a pause after running the GNURadio program.
This however meant I could not run my program in "real time" so I have been looking at implementing it in the GNURadio way, I have some questions that I ask you or anyone in the mailing list could help with. First what I am trying to implement is a Compressive Sensing(CS) algorithim. The block I am trying to create will take in a vector of length N, multiply it my a MxN matrix and output a vector of length M where M << N. Now for the questions. 1) Am i right in saying that with the different block types, the N and M refers to ports and not data type sizes. So in my case, one input vector and one output vector, a synchronous block will be fine? 2) The MxN matrix I'm using will be loaded from a file. I however only want to load it once instead of every time the CS block receives data. This leads me to think that I shouldn't load the matrix in the block code? However where could I load it that it will be globally accessible by the block code? Again thank you in advance for your help On Mon, Sep 14, 2015 at 4:00 PM, Marcus D. Leech <mle...@ripnet.com> wrote: > Again, could you confirm which UHD version you're using, did you upgrade > to the latest? > > Also, you're probably better-off doing things "in the Gnu Radio way", > rather than loading into a vector and doing DSPish things > "out of band". > > You might want to learn how to write Python blocks, since 64ksps is not a > very taxing rate, Python blocks should be fine. > > > https://gnuradio.org/redmine/projects/gnuradio/wiki/OutOfTreeModules#Tutorial-3-Writing-a-signal-processing-block-in-Python > > > > On 09/14/2015 09:28 AM, Chad R wrote: > > My complete code is: > > class Tx1_Rx2(gr.top_block): > def __init__(self, nsamps): > gr.top_block.__init__(self, "Tx1_Rx2") > ################################################## > # Variables > ################################################## > self.samp_rate = samp_rate = 64e3 > > ################################################## > # Blocks > ################################################## > self.source = uhd.usrp_source( > ",".join(("", "")), > uhd.stream_args( > cpu_format="fc32", > channels=range(2), > ), > ) > self.source.set_subdev_spec("A:A A:B", 0) > self.source.set_time_now(uhd.time_spec(time.time()), > uhd.ALL_MBOARDS) > self.source.set_samp_rate(samp_rate) > self.source.set_center_freq(100e6, 0) > self.source.set_gain(0, 0) > self.source.set_antenna("RX2", 0) > self.source.set_bandwidth(samp_rate, 0) > self.source.set_center_freq(100e6, 1) > self.source.set_gain(0, 1) > self.source.set_antenna("RX2", 1) > self.source.set_bandwidth(samp_rate, 1) > self.sink = uhd.usrp_sink( > ",".join(("", "")), > uhd.stream_args( > cpu_format="fc32", > channels=range(2), > ), > ) > self.sink.set_subdev_spec("A:A A:B", 0) > self.sink.set_samp_rate(samp_rate) > self.sink.set_center_freq(100e6, 0) > self.sink.set_gain(0, 0) > self.sink.set_antenna("TX/RX", 0) > self.sink.set_bandwidth(samp_rate, 0) > self.sink.set_center_freq(100e6, 1) > self.sink.set_gain(0, 1) > self.sink.set_antenna("TX/RX", 1) > self.sink.set_bandwidth(samp_rate, 1) > self.vector = blocks.vector_sink_c(1) > self.vector2 = blocks.vector_sink_c(1) > self.header = blocks.head(gr.sizeof_gr_complex*1, int(nsamps)) > self.header2 = blocks.head(gr.sizeof_gr_complex*1, int(nsamps)) > self.signal = analog.sig_source_c(samp_rate, analog.GR_COS_WAVE, > 10000, 1, 0) > self.const_signal = analog.sig_source_c(0, analog.GR_CONST_WAVE, > 0, 0, 0) > > ################################################## > # Connections > ################################################## > self.connect((self.const_signal, 0), (self.sink, 1)) > self.connect((self.signal, 0), (self.sink, 0)) > self.connect((self.header2, 0), (self.vector2, 0)) > self.connect((self.header, 0), (self.vector, 0)) > self.connect((self.source, 0), (self.header2, 0)) > self.connect((self.source, 1), (self.header, 0)) > > def get_samp_rate(self): > return self.samp_rate > > def set_samp_rate(self, samp_rate): > self.samp_rate = samp_rate > self.signal.set_sampling_freq(self.samp_rate) > self.sink.set_samp_rate(self.samp_rate) > self.sink.set_bandwidth(self.samp_rate, 0) > self.sink.set_bandwidth(self.samp_rate, 1) > self.source.set_samp_rate(self.samp_rate) > self.source.set_bandwidth(self.samp_rate, 0) > self.source.set_bandwidth(self.samp_rate, 1) > > def receive_data(self): > data = np.array(self.vector.data()) > return data > > def receive_data2(self): > data = np.array(self.vector2.data()) > return data > > > if __name__ == '__main__': > N = 1024 > M = 100*np.round(np.log10(N)) > tb = Tx1_Rx2(N) > psi = np.load("psi_mtx.npy") > phi = np.load("phi_mtx.npy") > alpha = np.dot(phi,psi) > > while 1: > tb.start() > time.sleep(0.1) > tb.stop() > time.sleep(0.1) > tb.wait() > time.sleep(0.5) > signal = tb.receive_data() > time.sleep(0.5) > signal2 = tb.receive_data2() > time.sleep(0.5) > print "Signal" > print signal > print "Signal2" > print signal2 > > I used the sample rate of 64Ksps for both cases. I'm new to both gnuradio > and python so I am aware that my code isn't well written. > > On Mon, Sep 14, 2015 at 3:21 PM, Marcus D. Leech <mle...@ripnet.com> > wrote: > >> 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> >> 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
