Re : Discuss-gnuradio Digest, Vol 119, Issue 18

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, [email protected]
[email protected] a crit:

De: [email protected] [email protected]
Objet: Discuss-gnuradio Digest, Vol 119, Issue 18
: [email protected]
Date: Mercredi 17 octobre 2012, 18h00

Send Discuss-gnuradio mailing list submissions to
[email protected]

To subscribe or unsubscribe via the World Wide Web, visit
Discuss-gnuradio Info Page
or, via email, send a message with subject or body ‘help’ to
[email protected]

You can reach the person managing the list at
[email protected]

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 H.)
  2. Problems passing the control between blocks - message passing
    (Jose T. Diaz)
  3. Re: Problems passing the control between blocks - message
    passing (Jose T. 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 R.)
  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 H. [email protected]
To: “[email protected][email protected]
Subject: [Discuss-gnuradio] Running older USRP scripts with GNURadio
3.60
Message-ID:
[email protected]
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 T. Diaz [email protected]
To: [email protected]
Subject: [Discuss-gnuradio] Problems passing the control between
blocks - message passing
Message-ID:
CANLn+itkbk8xGyY_4cgMzjt8p+ZbO72O_Xta+jvzie=removed_email_address@domain.invalid
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 T. Diaz [email protected]
To: John M. [email protected]
Cc: [email protected]
Subject: Re: [Discuss-gnuradio] Problems passing the control between
blocks - message passing
Message-ID:
[email protected]
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 M.
[email protected]wrote:

reference model. In these blocks, I am passing pmt_dict type as messages,
generate several packets and post them downstream, BLOCK 1 runs until
In this way BLOCK 1 stops working after one iteration and it does not run
BLOCK 2 takes the messages from the message queue. However, this
Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page

-------------- 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 [email protected]
To: [email protected]
Subject: [Discuss-gnuradio] GRC and gr_fft_vcc function showing
different signal power in dB
Message-ID:
[email protected]
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 10log10(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 R. [email protected]
To: Tom H. [email protected]
Cc: “[email protected][email protected]
Subject: Re: [Discuss-gnuradio] Running older USRP scripts with
GNURadio 3.60
Message-ID:
[email protected]
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Oct 16, 2012 at 6:34 PM, Tom H. [email protected]
wrote:

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 [email protected]
To: [email protected]
Subject: Re: [Discuss-gnuradio] cannot make new signal processing
block
Message-ID: [email protected]
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 [email protected]
To: [email protected]
Subject: Re: [Discuss-gnuradio] cannot make new signal processing
block
Message-ID: [email protected]
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
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

End of Discuss-gnuradio Digest, Vol 119, Issue 18