I have ubuntu 12.04 and GNURadio 3.6.2.? I was trying to run some older scripts which uses the USRP.? These scripts were made with GNURadio Companion about 3 years ago, and then I added some extra menu options by manually editing the python script made by GRC.
Unfortunately when I run the scripts, I get a "can't find USRP" type error.? I understand in the newer GNURadio installations that USRP is replaced with UHD.? Does anyone know of an easy way to run older scripts that call the USRP class?? I am not experienced enough to convert all the old scripts.? I would likely have to make new ones with the newer GNURadio Companion installation and add all the extra menu features again manually. Hi Tom, It will be easier to discuss this if you post your GRC picture. Regards. --- En date de : Mer 17.10.12, discuss-gnuradio-requ...@gnu.org <discuss-gnuradio-requ...@gnu.org> a écrit : De: discuss-gnuradio-requ...@gnu.org <discuss-gnuradio-requ...@gnu.org> Objet: Discuss-gnuradio Digest, Vol 119, Issue 18 À: discuss-gnuradio@gnu.org Date: Mercredi 17 octobre 2012, 18h00 Send Discuss-gnuradio mailing list submissions to discuss-gnuradio@gnu.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.gnu.org/mailman/listinfo/discuss-gnuradio or, via email, send a message with subject or body 'help' to discuss-gnuradio-requ...@gnu.org You can reach the person managing the list at discuss-gnuradio-ow...@gnu.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Discuss-gnuradio digest..." Today's Topics: 1. Running older USRP scripts with GNURadio 3.60 (Tom Hendrick) 2. Problems passing the control between blocks - message passing (Jose Torres Diaz) 3. Re: Problems passing the control between blocks - message passing (Jose Torres Diaz) 4. GRC and gr_fft_vcc function showing different signal power in dB (Hemant Saggar) 5. Re: Running older USRP scripts with GNURadio 3.60 (Tom Rondeau) 6. Re: cannot make new signal processing block (nexy_sm) 7. Re: cannot make new signal processing block (nexy_sm) ---------------------------------------------------------------------- Message: 1 Date: Tue, 16 Oct 2012 15:34:21 -0700 (PDT) From: Tom Hendrick <sdtom...@yahoo.com> To: "Discuss-gnuradio@gnu.org" <Discuss-gnuradio@gnu.org> Subject: [Discuss-gnuradio] Running older USRP scripts with GNURadio 3.60 Message-ID: <1350426861.17298.yahoomail...@web126001.mail.ne1.yahoo.com> Content-Type: text/plain; charset="iso-8859-1" Hello, I have ubuntu 12.04 and GNURadio 3.6.2.? I was trying to run some older scripts which uses the USRP.? These scripts were made with GNURadio Companion about 3 years ago, and then I added some extra menu options by manually editing the python script made by GRC. Unfortunately when I run the scripts, I get a "can't find USRP" type error.? I understand in the newer GNURadio installations that USRP is replaced with UHD.? Does anyone know of an easy way to run older scripts that call the USRP class?? I am not experienced enough to convert all the old scripts.? I would likely have to make new ones with the newer GNURadio Companion installation and add all the extra menu features again manually. Thank you, Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20121016/ad38a926/attachment.html> ------------------------------ Message: 2 Date: Wed, 17 Oct 2012 16:48:47 +1030 From: Jose Torres Diaz <torresdiaz.j...@gmail.com> To: discuss-gnuradio@gnu.org Subject: [Discuss-gnuradio] Problems passing the control between blocks - message passing Message-ID: <CANLn+itkbk8xGyY_4cgMzjt8p+ZbO72O_Xta+jvzie=tmof...@mail.gmail.com> Content-Type: text/plain; charset="iso-8859-1" Hi All, I'm working with 2 blocks that I've created using "UHD_AMsg_Source" as a reference model. In these blocks, I am passing pmt_dict type as messages, ie: this->post_msg(0, AMSG_KEY, dictionary,_id); Where, dictionary contains data/metadata that I can read in the next block downstream. BLOCK 1 -- (pmt_dict included in the message) --> BLOCK 2 The blocks are working ok, but the problem is that when I want to generate several packets and post them downstream, BLOCK 1 runs until finishes and then BLOCK 2 takes the control until finishes. The problem is the "return" sentence in my work function. I did 2 possible ways Option 1: Using -1 work { //work here return -1 } In this way BLOCK 1 stops working after one iteration and it does not run as many times as I want. Option 1: Not using return work { //work here } In this way BLOCK 1 runs many times and posts messages downstream all those times, but it gives the control to BLOCK 2 when it finishes. Then, BLOCK 2 takes the messages from the message queue. However, this implementation is not useful for me. BLOCK 1 should post a message downstream and then, BLOCK 2 takes the message and work with the packet. Any suggestion is welcome, thanks a lot for your time, Regards, Jose -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20121017/a13df174/attachment.html> ------------------------------ Message: 3 Date: Wed, 17 Oct 2012 17:04:07 +1030 From: Jose Torres Diaz <torresdiaz.j...@gmail.com> To: John Malsbury <john.malsb...@ettus.com> Cc: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Problems passing the control between blocks - message passing Message-ID: <canln+ivrdevejbrm83r63x0qvfbze4rpehmctyz4syxff6s...@mail.gmail.com> Content-Type: text/plain; charset="iso-8859-1" Hi John, I wrote the code in C++ based on UHD_AMsg_source.cc, provided in GRExtras. In my work function, I've finished it using return -1 (ie. the block has finished processing correctly) as shown below: int work( const InputItems &, const OutputItems & ){ //work definition here (ie. generate a packet and post downstream) return -1; //done running, work done status } However, in that way the block in GNU Radio Companion runs only once. The other possibility is not to use "return" at all, but in that case what I have is: 1. BLOCK 1 generates a packet 2. BLOCK 1 post the packet downstream Step 1 and 2 repeats "N times". When finishes, it gives the control to BLOCK 2 to process the message. However, I need a sequence as follows: 1. BLOCK 1 generates a packet 2. BLOCK 1 post the packet downstream 3. BLOCK 2 process the packet 4. BLOCK 2 post the message again downstream and so on... Step 1 to 4 should repeat "N times". Thanks again for your help, Jose On Wed, Oct 17, 2012 at 4:52 PM, John Malsbury <john.malsb...@ettus.com>wrote: > Jose, > > Try a while(1) with a block and a blocking call to pop msg's off the > queue: > > self.pop_msg_queue() > > Should help you avoid the return -1 > > Or maybe I've misunderstood your problem...? > > -John > > > > On Tue, Oct 16, 2012 at 11:18 PM, Jose Torres Diaz < > torresdiaz.j...@gmail.com> wrote: > >> Hi All, >> >> I'm working with 2 blocks that I've created using "UHD_AMsg_Source" as a >> reference model. In these blocks, I am passing pmt_dict type as messages, >> ie: >> >> this->post_msg(0, AMSG_KEY, dictionary,_id); >> >> Where, dictionary contains data/metadata that I can read in the next >> block downstream. >> >> BLOCK 1 -- (pmt_dict included in the message) --> BLOCK 2 >> >> The blocks are working ok, but the problem is that when I want to >> generate several packets and post them downstream, BLOCK 1 runs until >> finishes and then BLOCK 2 takes the control until finishes. The problem is >> the "return" sentence in my work function. I did 2 possible ways >> >> Option 1: Using -1 >> >> work { >> //work here >> return -1 >> } >> >> In this way BLOCK 1 stops working after one iteration and it does not run >> as many times as I want. >> >> Option 1: Not using return >> >> work { >> //work here >> } >> >> In this way BLOCK 1 runs many times and posts messages downstream all >> those times, but it gives the control to BLOCK 2 when it finishes. Then, >> BLOCK 2 takes the messages from the message queue. However, this >> implementation is not useful for me. BLOCK 1 should post a message >> downstream and then, BLOCK 2 takes the message and work with the packet. >> >> Any suggestion is welcome, thanks a lot for your time, >> >> Regards, >> >> Jose >> >> _______________________________________________ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20121017/86e5a3bc/attachment.html> ------------------------------ Message: 4 Date: Wed, 17 Oct 2012 17:51:11 +0530 From: Hemant Saggar <hemantsagg...@gmail.com> To: discuss-gnuradio@gnu.org Subject: [Discuss-gnuradio] GRC and gr_fft_vcc function showing different signal power in dB Message-ID: <cafuryj0y0_hqyzqfgqikkljomhcvbwqhohvncoijmv3yymd...@mail.gmail.com> Content-Type: text/plain; charset="iso-8859-1" Hi all, I am new to USRP and I started by trying to calibrate the received power in USRP by giving a known sine signal. I gave a signal of *100.2 MHz at -30 dBm * to USRP which sampled it at 1MHz then passed it to a 1024 point FFT scope in Gnu Radio Companion. I saw a level of about* -52 dB at 100.2 MHz*. I also modified the *usrp_spectrum_sense.py* to find FFT of same signal using gr_fft_vcc function and then print the magnitude squared value to a csv file. When I took 10*log10(value) the plot showed me about* -30dB level at 100.2 MH*z. Following are my queries 1) Is the power level in GRC -52 dB or -52 dBm? Accordingly why is the -22 dB loss? ( My antenna and channel gain were set to 0dB) 2) Why are fft squared amplitude in dB different here and which one is correct? Regards, Hemant -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20121017/fb2d8e35/attachment.html> ------------------------------ Message: 5 Date: Wed, 17 Oct 2012 10:20:50 -0400 From: Tom Rondeau <t...@trondeau.com> To: Tom Hendrick <sdtom...@yahoo.com> Cc: "Discuss-gnuradio@gnu.org" <Discuss-gnuradio@gnu.org> Subject: Re: [Discuss-gnuradio] Running older USRP scripts with GNURadio 3.60 Message-ID: <ca+szt6htespm1wpzv98phrya+jojrhkw5ovfm_d7_2y_7oy...@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 On Tue, Oct 16, 2012 at 6:34 PM, Tom Hendrick <sdtom...@yahoo.com> wrote: > Hello, > > I have ubuntu 12.04 and GNURadio 3.6.2. I was trying to run some older > scripts which uses the USRP. These scripts were made with GNURadio > Companion about 3 years ago, and then I added some extra menu options by > manually editing the python script made by GRC. > > Unfortunately when I run the scripts, I get a "can't find USRP" type error. > I understand in the newer GNURadio installations that USRP is replaced with > UHD. Does anyone know of an easy way to run older scripts that call the > USRP class? I am not experienced enough to convert all the old scripts. I > would likely have to make new ones with the newer GNURadio Companion > installation and add all the extra menu features again manually. > > Thank you, > Tom Tom, Honestly, your best bet is to update the old scripts to use the UHD interface. It's not a very big switch between the old and new; really, it's mostly syntactic changes. Also, to be blunt, there is a way to use the old libusrp drivers, but if you aren't experienced enough to update to UHD, trying to mix and match the old libusrp with new GNU Radio is also going to be difficult. My suggestion would be to go into GRC and create just a simple UHD program. Just drop down a UHD source and drive it into a GUI sink. When you build/run this script, you can look at the build Python for the syntax you need to copy over to your old scripts. Hope that helps. Tom ------------------------------ Message: 6 Date: Wed, 17 Oct 2012 08:13:11 -0700 (PDT) From: nexy_sm <vlasi...@gmail.com> To: Discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] cannot make new signal processing block Message-ID: <1350486791351-38033.p...@n7.nabble.com> Content-Type: text/plain; charset=us-ascii Ok, I suppose the best and fastest way to learn gnuradio is by exploring simple existing blocks, like adder for example. I was first thinking about adder and the opened gr_add_cc.h. I was immediately stuck in the constructor part gr_add_cc::gr_add_cc (size_t vlen) : gr_sync_block ("add_cc", gr_make_io_signature (1, -1, sizeof (gr_complex)*vlen), gr_make_io_signature (1, 1, sizeof (gr_complex)*vlen)), d_vlen (vlen) { } I was expecting something like: gr_add_cc::gr_add_cc (size_t vlen) : gr_sync_block ("add_cc", gr_make_io_signature (1, vlen, sizeof (gr_complex)), gr_make_io_signature (1, 1, sizeof (gr_complex))), d_vlen (vlen) { } I don't really understand this line: gr_make_io_signature (1, -1, sizeof (gr_complex)*vlen) Can you just explain breafly what is idea behind, cause i was expecting something more simpler. Thanks -- View this message in context: http://gnuradio.4.n7.nabble.com/cannot-make-new-signal-processing-block-tp37924p38033.html Sent from the GnuRadio mailing list archive at Nabble.com. ------------------------------ Message: 7 Date: Wed, 17 Oct 2012 08:45:21 -0700 (PDT) From: nexy_sm <vlasi...@gmail.com> To: Discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] cannot make new signal processing block Message-ID: <1350488721114-38034.p...@n7.nabble.com> Content-Type: text/plain; charset=us-ascii Hm, I see now, and don't get, how you specifu number of inputs, and what exactly means Vec Length (vlen) and what could be wrong with implementation like this: int gr_add_cc::work (int noutput_items, gr_vector_const_void_star &input_items, gr_vector_void_star &output_items) { gr_complex *optr = (gr_complex *) output_items[0]; int ninputs = input_items.size (); for (size_t i = 0; i < noutput_items; i++){ gr_complex acc = ((gr_complex *) input_items[0])[i]; for (int j = 1; j < ninputs; j++) acc += ((gr_complex *) input_items[j])[i]; *optr++ = (gr_complex) acc; } return noutput_items; } And just one question, in the block gr_add_const_ff, you did loop unrolling by yourself, is that because you don't believe to the compiler or something else? Thanks again Nemanja -- View this message in context: http://gnuradio.4.n7.nabble.com/cannot-make-new-signal-processing-block-tp37924p38034.html Sent from the GnuRadio mailing list archive at Nabble.com. ------------------------------ _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio End of Discuss-gnuradio Digest, Vol 119, Issue 18 *************************************************
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
