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

Send Discuss-gnuradio mailing list submissions to
    address@hidden

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
    address@hidden

You can reach the person managing the list at
    address@hidden

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 <address@hidden>
To: "address@hidden" <address@hidden>
Subject: [Discuss-gnuradio] Running older USRP scripts with GNURadio
    3.60
Message-ID:
    <address@hidden>
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 <address@hidden>
To: address@hidden
Subject: [Discuss-gnuradio] Problems passing the control between
    blocks -    message passing
Message-ID:
    <CANLn+itkbk8xGyY_4cgMzjt8p+ZbO72O_Xta+jvzie=address@hidden>
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 <address@hidden>
To: John Malsbury <address@hidden>
Cc: address@hidden
Subject: Re: [Discuss-gnuradio] Problems passing the control between
    blocks - message passing
Message-ID:
    <CANLn+address@hidden>
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 <address@hidden>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 <
> address@hidden> 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
>> address@hidden
>> 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 <address@hidden>
To: address@hidden
Subject: [Discuss-gnuradio] GRC and gr_fft_vcc function showing
    different    signal power in dB
Message-ID:
    <address@hidden>
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 <address@hidden>
To: Tom Hendrick <address@hidden>
Cc: "address@hidden" <address@hidden>
Subject: Re: [Discuss-gnuradio] Running older USRP scripts with
    GNURadio 3.60
Message-ID:
    <CA+SzT6hTespm1WpzV98pHrya+address@hidden>
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Oct 16, 2012 at 6:34 PM, Tom Hendrick <address@hidden> 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 <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] cannot make new signal processing
    block
Message-ID: <address@hidden>
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 <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] cannot make new signal processing
    block
Message-ID: <address@hidden>
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
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

From:	guelord ingala
Subject:	[Discuss-gnuradio] Re : Discuss-gnuradio Digest, Vol 119, Issue 18
Date:	Thu, 18 Oct 2012 07:43:08 +0100 (BST)