[Discuss-gnuradio] Re : Discuss-gnuradio Digest, Vol 119, Issue 18
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
To: John Malsbury
Cc: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Problems passing the control between
blocks - message passing
Message-ID:
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 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
To: discuss-gnuradio@gnu.org
Subject: [Discuss-gnuradio] GRC and gr_fft_vcc function showing
different signal power in dB
Message-ID:
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
Re: [Discuss-gnuradio] Problems passing the control between blocks - message passing
Can you send me the files?
-John
On Wed, Oct 17, 2012 at 4:16 PM, Jose Torres Diaz wrote:
> Hi John,
>
> Yes, I also checked the examples in your branch. In regards to your
> questions.
>
> *1.* BLOCK 2 is processing the data from BLOCK 1, but only when BLOCK 1
> has finished the routine "N times". Let me post a piece of code from BLOCK
> 1:
>
>
>
> int work(
> const InputItems &,
> const OutputItems &
> ){
>
>
> for (int i = 0; i < d_pkt_len; i++) {
>if (d_mode == 2)
> { elements[i] = ((i % d_pkt_len) + d_num_pkts_output) & 0xff;
> }
> else if (d_mode == 0)
> {elements[i]=0;
> }
> else // ones
> {elements[i]=0xFF;
> }
> num_output++;
> } //End of for
> d_num_pkts_output++;
>
> //(4.1) adding data into the dictionary
> dictionary = pmt::pmt_dict_add(dictionary, data_key, vector_data);
> std::cout << std::endl << "(4) Now, the dictionary is" << dictionary
> <
>
> //Posting a message downstream
> this->post_msg(0, AMSG_KEY, dictionary, _d_my_unique_id);
> std::cout << std::endl << "posting the message downstream "
> <
> return -1; // <--The problem seems to be here
>
>}
>
>
> *2.* N is the number of packet that I want to transmit from BLOCK 1. In
> my code, I'm using the variable d_max_pkts. So, when d_num_pkts_output >=
> d_max_pkts, the program stops:
>
> if (d_num_pkts_output >= d_max_pkts)
> return 0;
>
> 3. Yes, my BLOCK 1 is as follows:
>
> block(
> //"gr uhd amsg source",
> "BLOCK 1",
> gr_make_io_signature(0, 0, 0),
> gr_make_io_signature(0, 0, 0),
> msg_signature(false, 1)
>
>
> Thanks again for your advice,
>
> Regards,
>
> Jose
>
>
> On Wed, Oct 17, 2012 at 5:14 PM, John Malsbury wrote:
>
>> So, block 2 is never processing the data? What are you using to set the
>> "N"? Does the uhd_amsg_source have the same i/o as the original block - no
>> inputs, one msg output?
>>
>> If you're looking to something to generate periodic msg's with arbirtrary
>> key and value, the heart_beat block in my pre-cog branch might help...
>>
>> -John
>>
>>
>>
>>
>>
>> On Tue, Oct 16, 2012 at 11:34 PM, Jose Torres Diaz <
>> torresdiaz.j...@gmail.com> wrote:
>>
>>> 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
>>> 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 r
Re: [Discuss-gnuradio] Problems passing the control between blocks - message passing
Hi John,
Yes, I also checked the examples in your branch. In regards to your
questions.
*1.* BLOCK 2 is processing the data from BLOCK 1, but only when BLOCK 1 has
finished the routine "N times". Let me post a piece of code from BLOCK 1:
int work(
const InputItems &,
const OutputItems &
){
for (int i = 0; i < d_pkt_len; i++) {
if (d_mode == 2)
{ elements[i] = ((i % d_pkt_len) + d_num_pkts_output) & 0xff;
}
else if (d_mode == 0)
{elements[i]=0;
}
else // ones
{elements[i]=0xFF;
}
num_output++;
} //End of for
d_num_pkts_output++;
//(4.1) adding data into the dictionary
dictionary = pmt::pmt_dict_add(dictionary, data_key, vector_data);
std::cout << std::endl << "(4) Now, the dictionary is" << dictionary
= d_max_pkts)
return 0;
3. Yes, my BLOCK 1 is as follows:
block(
//"gr uhd amsg source",
"BLOCK 1",
gr_make_io_signature(0, 0, 0),
gr_make_io_signature(0, 0, 0),
msg_signature(false, 1)
Thanks again for your advice,
Regards,
Jose
On Wed, Oct 17, 2012 at 5:14 PM, John Malsbury wrote:
> So, block 2 is never processing the data? What are you using to set the
> "N"? Does the uhd_amsg_source have the same i/o as the original block - no
> inputs, one msg output?
>
> If you're looking to something to generate periodic msg's with arbirtrary
> key and value, the heart_beat block in my pre-cog branch might help...
>
> -John
>
>
>
>
>
> On Tue, Oct 16, 2012 at 11:34 PM, Jose Torres Diaz <
> torresdiaz.j...@gmail.com> wrote:
>
>> 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
>> 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.gn
[Discuss-gnuradio] Reg : ofdm_bpsk_mapper & ofdm_mapper_bcv
I have gnuradio version 3.6.2-13-g65ea256f Q1 : In the directory */usr/local/share/gnuradio/examples/digital/ofdm* I tried to run ofdm_mod_demod_test.py but it threw the error * 'module' object has no attribute 'ofdm_bpsk_mapper'* I tried to locate ofdm_bpsk_mapper but couldn't find it in my system I remember it was running last year Rest of all the files are running fine i.e. benchmark_tx.py, rx.py etc Q2 : I was running the *uhd_tx_ofdm.grc* example from the gr_apps https://github.com/trondeau/gr_apps When I run it , I get the error *'module' object has no attribute 'ofdm_mapper_bcv'* *File "/usr/local/lib/python2.6/dist-packages/gnuradio/blks2impl/ofdm.py", line 97, in __init__ self._pkt_input = gr.ofdm_mapper_bcv(rotated_const, msgq_limit, AttributeError: 'module' object has no attribute 'ofdm_mapper_bcv'* I tried to locate ofdm_mapper_bcv and got it in the include path */usr/local/include/gnuradio/digital_ofdm_mapper_bcv.h /usr/local/include/gnuradio/gr_ofdm_mapper_bcv.h /usr/local/include/gnuradio/swig/digital_ofdm_mapper_bcv.i /usr/local/include/gnuradio/swig/gr_ofdm_mapper_bcv.i* Q3 : There is another folder of ofdm inside *gnuradio/examples/ofdm* apart from *gnuradio/examples/digital/ofdm* There also I am facing errors like : *ofdm_mod_demod_test.py 'module' object has no attribute 'ofdm_bpsk_mapper' benchmark_ofdm.py 'module' object has no attribute 'ofdm_mapper_bcv' benchmark_tx.py 'module' object has no attribute 'ofdm_mapper_bcv'* Is it my improper installation or some files/modules have been depreciated in the new version !! -- View this message in context: http://gnuradio.4.n7.nabble.com/Reg-ofdm-bpsk-mapper-ofdm-mapper-bcv-tp38048.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
Re: [Discuss-gnuradio] Quick & Dirty for Beginners
Thanks for the appreciation Tom !! Will keep these basic things posting... btw whom shall I contact so that these links get included on gnuradio.org ... -- View this message in context: http://gnuradio.4.n7.nabble.com/Quick-Dirty-for-Beginners-tp38039p38047.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
[Discuss-gnuradio] USRP1 (USB2) with Basic TX and Basic RX For Sale
Let me know if you're interested... ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Blocks missing from GRC after pre-cog installation
On Wed, Oct 17, 2012 at 2:30 PM, Sakib Chowdhury wrote: > I noticed that actually all block files (xml) are still there > in /usr/local/share/gnuradio/grc/blocks/ . What GRC is not displaying are > the blocks whose names start with gr_*.xml . I'll try to reinstall. > This was a recently fixed bug on GNU Radio master branch, related to the gr-blocks work Josh mentioned. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Blocks missing from GRC after pre-cog installation
Hi Josh, I noticed that actually all block files (xml) are still there in /usr/local/share/gnuradio/grc/blocks/ . What GRC is not displaying are the blocks whose names start with gr_*.xml . I'll try to reinstall. Thanks. On Wed, Oct 17, 2012 at 5:17 PM, Josh Blum wrote: > > > On 10/17/2012 01:13 PM, Sakib Chowdhury wrote: > > Hi, > > > > I installed pre-cog following the last section of > > https://github.com/buoyboy/pre-cog/wiki/Installation only. I already had > > working GNUradio with grextras installed, which I did by simply running > the > > installation script http://www.sbrac.org/files/build-gnuradio . Now > > strangely I see that many blocks from GRC are missing, though new blocks > > from pre-cog are there. I don't see blocks such as throttle. Can anyone > > suggest how to fix this? I am not super expert on linux, by the way, just > > learning as required. > > > > More information: > > OS: Ubuntu 12.04 > > Installation dirs: ~/Downloads/gnuradio, ~/Downloads/grextras, > > ~/Downloads/pre-cog and other folders similarly such as 'uhd', 'gr-baz' > > etc. > > > > I saw this too. I thought it had something to do with the gr-blocks work > that was merged into master. Not sure. What I did to fix it was: > > 1) remove /usr/local/share/gnuradio/grc/blocks > 2) reinstall gnuradio, extras, precog > 3) then it was all there again in my GRC window > > -josh > > ___ > 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
Re: [Discuss-gnuradio] Blocks missing from GRC after pre-cog installation
On 10/17/2012 01:13 PM, Sakib Chowdhury wrote: > Hi, > > I installed pre-cog following the last section of > https://github.com/buoyboy/pre-cog/wiki/Installation only. I already had > working GNUradio with grextras installed, which I did by simply running the > installation script http://www.sbrac.org/files/build-gnuradio . Now > strangely I see that many blocks from GRC are missing, though new blocks > from pre-cog are there. I don't see blocks such as throttle. Can anyone > suggest how to fix this? I am not super expert on linux, by the way, just > learning as required. > > More information: > OS: Ubuntu 12.04 > Installation dirs: ~/Downloads/gnuradio, ~/Downloads/grextras, > ~/Downloads/pre-cog and other folders similarly such as 'uhd', 'gr-baz' > etc. > I saw this too. I thought it had something to do with the gr-blocks work that was merged into master. Not sure. What I did to fix it was: 1) remove /usr/local/share/gnuradio/grc/blocks 2) reinstall gnuradio, extras, precog 3) then it was all there again in my GRC window -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Quick & Dirty for Beginners
On Wed, Oct 17, 2012 at 2:21 PM, sumitstop wrote: > Hi Community, > Just tried to write a couple of scripts for the new comers on GNU Radio and > USRP. I have given detailed explanation step by step on how to quickly get > data from USRP by writing your own program , without any knowledge of python > or C++ > > I have posted them on my blog, here are the links : > http://sumitgnuradio.blogspot.in/2012/10/quick-dirty-getting-data-from-usrp.html > --Getting data from usrp > http://sumitgnuradio.blogspot.in/2012/10/quick-dirty-part-2-data-dumping-into.html > -- Getting data from usrp and dumping them in two files simultaneously > http://sumitgnuradio.blogspot.in/2012/10/quick-dirty-part-3-getting-data-from.html > -- Getting data from two usrp simultaneously > http://sumitgnuradio.blogspot.in/2012/10/quick-dirty-running-two-classes-one-by.html > -- Running two classes one by one. > > ** This post is not for advanced users its for beginners like me Sumit, I hope I've said this before, but just to reiterate (or say it again for the first time), thank you so much for putting this kind of tutorial material together. I'm sure it's hugely helpful to users, especially the new ones. Please feel free to update gnuradio.org with these links to make sure they are easily findable by everyone. Great job! Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] cannot make new signal processing block
Ok, thanks for the explanation and link with more information. Is there any benefit of using for example adder block which calculates output using input vectors, then using single flat or whatever. I expect that for calculating for example FFT one usually need packets of 512 or 256, etc samples, and then you have to provide precise number of samples at the input. I have to take another look on adder block tomorrow, but I couldn't find today, how is specified number of inputs. Since u can input any number of inputs in GRC for that block, I would expect that value specified inside of constructor. Thanks Regards Nemanja -- View this message in context: http://gnuradio.4.n7.nabble.com/cannot-make-new-signal-processing-block-tp37924p38041.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
[Discuss-gnuradio] Blocks missing from GRC after pre-cog installation
Hi, I installed pre-cog following the last section of https://github.com/buoyboy/pre-cog/wiki/Installation only. I already had working GNUradio with grextras installed, which I did by simply running the installation script http://www.sbrac.org/files/build-gnuradio . Now strangely I see that many blocks from GRC are missing, though new blocks from pre-cog are there. I don't see blocks such as throttle. Can anyone suggest how to fix this? I am not super expert on linux, by the way, just learning as required. More information: OS: Ubuntu 12.04 Installation dirs: ~/Downloads/gnuradio, ~/Downloads/grextras, ~/Downloads/pre-cog and other folders similarly such as 'uhd', 'gr-baz' etc. Thanks. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Quick & Dirty for Beginners
Hi Community, Just tried to write a couple of scripts for the new comers on GNU Radio and USRP. I have given detailed explanation step by step on how to quickly get data from USRP by writing your own program , without any knowledge of python or C++ I have posted them on my blog, here are the links : http://sumitgnuradio.blogspot.in/2012/10/quick-dirty-getting-data-from-usrp.html --Getting data from usrp http://sumitgnuradio.blogspot.in/2012/10/quick-dirty-part-2-data-dumping-into.html -- Getting data from usrp and dumping them in two files simultaneously http://sumitgnuradio.blogspot.in/2012/10/quick-dirty-part-3-getting-data-from.html -- Getting data from two usrp simultaneously http://sumitgnuradio.blogspot.in/2012/10/quick-dirty-running-two-classes-one-by.html -- Running two classes one by one. ** This post is not for advanced users its for beginners like me -- View this message in context: http://gnuradio.4.n7.nabble.com/Quick-Dirty-for-Beginners-tp38039.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
[Discuss-gnuradio] pyserial Wrapper
Hello list, Just shooting out a quick update. I wrote a simple wrapper for pyserial to provide a serial port block for use with GNU Radio/GRC. The objective here was to support a legacy command generation program that would typically output to an external, hardware-based transmitter via RS-232. The user wanted to move the radio functionality into GNU Radio/USRP, but re-use the legacy application and interface to save a little work. This block, combined with a socat generated virtual serial port permitted this migration of functionality. This block uses grextras and message passing: https://github.com/buoyboy/gr-pyserial/ Some possible use cases for this block: 1. Interfacing to legacy programs. For example, you could use this block to interface with older amateur radio programs that talked to external TNCs on a serial port. You can also connect to AX25-tools with this block [may require a KISS emulator block]. May be a way to engage the amateur radio community in PHY evolution while keeping them in touch with familiar portions of their typical radio chain. 2. Outputting USRP GPSDO sensor data to mapping applications that typically use a serial port. This would require some manipulation to generate standard NMEA commands - I plan on doing this here soon. 3. Deploying novel modems (i.e. in place of something like a MaxStream 900 MHz or xBee) with an RS-232 interface to other devices like Arduino's, etc. - - perhaps with the E100? I'm on the road and do not have hardware to test it thoroughly. I've only done some cursory testing with virtual ports created with socat. Cheers, John Malsbury ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GRC and gr_fft_vcc function showing different signal power in dB
On 10/17/2012 05:21 AM, Hemant Saggar wrote: > 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) > The WX gui FFT plotter is scaled for dBfs. 0 dBfs is equivalent 1.0 sample counts, which is fullscale. > 2) Why are fft squared amplitude in dB different here and which one is > correct? > See ./gr-blocks/lib/nlog10_ff_impl.cc This uses the gr_fft_vcc and does various scaling compensation -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] cannot make new signal processing block
On Wed, Oct 17, 2012 at 11:13 AM, nexy_sm wrote:
> 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
It is actually quite simple, you just have a misunderstanding of what
it's supposed to be doing.
The first call is to set the input signature:
gr_make_io_signature(min inputs, max inputs, input item size)
The second one is for the output signature:
gr_make_io_signature(min outputs, max outputs, output item size)
The min value specifies how many inputs MUST be connected. The max
value says how many CAN be connected. A value of -1 means it's
undefined and any number can be connected.
The item size is the size in bytes of each item. So for floats, this
is sizeof(float). If you want to handle vectors, you treat the vector
as an item. So a vector of vlen floats has a size
'sizeof(float)*vlen'.
Tom
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] cannot make new signal processing block
On Wed, Oct 17, 2012 at 08:45:21AM -0700, nexy_sm wrote: > Hm, I see now, and don't get, how you specifu number of inputs, and what > exactly means Vec Length (vlen) Read this: http://gnuradio.org/redmine/projects/gnuradio/wiki/TutorialsCoreConcepts > and what could be wrong with implementation like this: > [garbled code] It doesn't specify the vlen (that's what's wrong). > 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? gr_add_const_ff is pretty old, you should check out gr-blocks/lib/add_const_vXX_impl.cc.t. And yes, there's a lot of hand-optimized code. MB -- Karlsruhe Institute of Technology (KIT) Communications Engineering Lab (CEL) Dipl.-Ing. Martin Braun Research Associate Kaiserstraße 12 Building 05.01 76131 Karlsruhe Phone: +49 721 608-43790 Fax: +49 721 608-46071 www.cel.kit.edu KIT -- University of the State of Baden-Württemberg and National Laboratory of the Helmholtz Association pgpKzs5MdxTNr.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] cannot make new signal processing block
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
Re: [Discuss-gnuradio] cannot make new signal processing block
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.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Running older USRP scripts with GNURadio 3.60
On Tue, Oct 16, 2012 at 6:34 PM, Tom Hendrick 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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] GRC and gr_fft_vcc function showing different signal power in dB
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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
