I would load it at the time the block is instantiated, in its "make" method, and load it into instance-specific data.
On 2015-09-22 06:27, Chad R wrote: > 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 > [1] > > 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 [2] 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 [2] > > 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 [3] Links: ------ [1] https://gnuradio.org/redmine/projects/gnuradio/wiki/OutOfTreeModules#Tutorial-3-Writing-a-signal-processing-block-in-Python [2] http://imgur.com/yI96ZMw [3] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
