From: "address@hidden" <address@hidden>
To: address@hidden
Sent: Monday, October 15, 2012 9:00 PM
Subject: Discuss-gnuradio Digest, Vol 119, Issue 15
Send Discuss-gnuradio mailing list submissions to
address@hiddenTo subscribe or unsubscribe via the World Wide Web, visit
https://lists.gnu.org/mailman/listinfo/discuss-gnuradioor, via email, send a message with subject or body 'help' to
address@hiddenYou can reach the person managing the list at
address@hiddenWhen replying, please edit your Subject line so it is more specific
than "Re: Contents of Discuss-gnuradio digest..."
Today's Topics:
1. Re: problem with 3.6.2 (Josh Blum)
2. Re: problem with 3.6.2 (Stephen)
3. Help to understand "UHD AMsg Source" (Jose Torres Diaz)
4. Re: Error using block UHD AMsg Source (Jose Torres Diaz)
5. Re: Error using block UHD AMsg Source (Jose Torres Diaz)
6. Re: cannot make new signal processing block (nexy_sm)
7. Re: 4. Re: usrp_nbfm_ptt.py in Gnu Radio Companion.
(Martin
Braun (CEL)) Discuss-gnuradio Digest, Vol 119, Issue 13
(Sajjad Safdar)
8. Re: cannot make new signal processing block (Tom Rondeau)
9. Re: Reg : difference between gr.file_descriptor_source/sink
and gr.file_source/sink (Tom Rondeau)
10. Re: OOK Modulation (Tom Rondeau)
11. Re: Can the io signatur of the gnuradio blocks be dynamically
updated? (Tom Rondeau)
12. How to report to gnuradio.org (Pol Henarejos)
13. Re: How to report to gnuradio.org (Tom Rondeau)
14. Re: cannot make new signal processing block (nexy_sm)
----------------------------------------------------------------------
Message: 1
Date: Sun, 14 Oct 2012 10:06:43 -0700
From: Josh Blum <
address@hidden>
To:
address@hiddenSubject: Re: [Discuss-gnuradio] problem with 3.6.2
Message-ID: <
address@hidden>
Content-Type: text/plain; charset=ISO-8859-1
On 10/13/2012 11:36 AM, Stephen wrote:
>
> Hi,
>
> I was using 3.6 with no issues. Today I updated to 3.6.3 and get the
> following error when I try to start the flowgraph. I did rebuild all
> parts of my application.
>
> terminate called after throwing an instance of 'Using Volk machine:
> sse4_1_64_orc
> std::invalid_argument'
> what(): gr_buffer_add_reader: nzero_preload must be >= 0
> The program has unexpectedly finished.
>
> Does anyone have any idea where I could start looking?
set_history needs to be at least 1.
(because this actually means a history of user_history_setting-1 is
prepended to the start of the buffer)
-josh
>
> thanks,
> steve
>
> _______________________________________________
> Discuss-gnuradio mailing list
>
address@hidden>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>
------------------------------
Message: 2
Date: Sun, 14 Oct 2012 17:02:24 -0500
From: Stephen <
address@hidden>
To:
address@hiddenCc:
address@hiddenSubject: Re: [Discuss-gnuradio] problem with 3.6.2
Message-ID: <
address@hidden>
Content-Type: text/plain; charset=ISO-8859-1
On 10/14/2012 12:06 PM, Josh Blum wrote:
>
>
>
> set_history needs to be at least 1.
>
> (because this actually means a history of user_history_setting-1 is
> prepended to the start of the buffer)
>
> -josh
>
thanks for the reply but I don't know what that means. What is
set_history? I don't explicitly use gr_buffer in my application. I do
use gr message queues. But all of my message queues are initialized
with a
size.
steve
------------------------------
Message: 3
Date: Mon, 15 Oct 2012 09:32:32 +1030
From: Jose Torres Diaz <
address@hidden>
To:
address@hiddenSubject: [Discuss-gnuradio] Help to understand "UHD AMsg Source"
Message-ID:
<CANLn+
address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
Hi Community,
I would like to ask if someone can give a hand to figure out how "UHD AMsg
Source" block works. I mean, I would like to understand in particular
how
this block can post message using pmt_dict type. The piece of routine that
I'm keen on it's this:
void post_async_md(const uhd::async_metadata_t &md){
pmt::pmt_t value_dict = pmt::pmt_make_dict();
if (md.has_time_spec){
pmt::pmt_t timestamp = pmt::pmt_make_tuple(
pmt::pmt_from_uint64(md.time_spec.get_full_secs()),
pmt::pmt_from_double(md.time_spec.get_frac_secs())
);
pmt::pmt_dict_add(value_dict, TIME_KEY, timestamp);
}
pmt::pmt_dict_add(value_dict, CHAN_KEY,
pmt::pmt_from_uint64(md.channel));
pmt::pmt_dict_add(value_dict,
EVENT_KEY,
pmt::pmt_from_uint64(md.event_code));
*this->post_msg(0, AMSG_KEY, value_dict, _id); // <--Here the
message is post downstream, but using pmt_dict*
}
I've tried to create my own block using stream to blob, using pmt_dict.
However, it was not possible to do such a post message with a pmt_dict type
of variable.
I think I'm missing/misunderstanding something important in this block UHD
AMsg source, that allows to post dictionaries downstream. However, I
couldn't figure out what it is.
Thanks a lot for your comments and help,
Regards,
Jose
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20121015/648b3a47/attachment.html>
------------------------------
Message: 4
Date: Mon, 15 Oct 2012 11:54:12 +1030
From: Jose Torres Diaz <
address@hidden>
To:
address@hiddenCc:
address@hiddenSubject: Re: [Discuss-gnuradio] Error using block UHD AMsg Source
Message-ID:
<CANLn+is=wK4DDcpMLxtye=ZnV+
address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
Hi Josh,
You
mentioned that:
"the code to add a key/value actually returns a new dictionary and doesnt
change the old ones.
I know this pmt stuff is crazy. Why didnt we just use std::map? :-)"
I'm confused with this, because I created the dictionary and added the
values. However, when I've checked the type, it shows that it is a
dictionary (as I expected), but also it is always empty.
pmt::pmt_t value_dict = pmt::pmt_make_dict();
std::cout << std::endl << "Making a dictionary" << std::endl;
pmt::pmt_dict_add(value_dict, TIME_KEY, pmt::pmt_from_uint64(3200));
this->post_msg(0, AMSG_KEY, value_dict, _id);
std::cout << std::endl << "Posting downstream" << std::endl;
std::cout << std::endl << "checking if
null:"
<<pmt::pmt_is_null(value_dict)<< std::endl; //Return true
std::cout << std::endl << "checking if dict:"
<<pmt::pmt_is_dict(value_dict)<< std::endl; //Return true
So, does it mean that I cannot access the values that are added into the
dictionary "value_dict"?. If it is possible, how should I access them?.
*Sort of related question:*
Since this is dictionary, in order to debug my code I printed out the
items, keys and values. I expected to see at least the items inside the
dictionary, but again everything is empty.
std::cout << std::endl << "Checking items ;" <<
pmt::pmt_dict_items(value_dict)<<std::endl;
std::cout << std::endl << "Checking keys ;" <<
pmt::pmt_dict_keys(value_dict)<<std::endl;
std::cout << std::endl << "Checking values;"
<<
pmt::pmt_dict_values(value_dict)<<std::endl;
Thanks a lot for your help,
Kind Regards,
Jose
On Thu, Oct 11, 2012 at 2:43 PM, Josh Blum <
address@hidden> wrote:
>
>
> On 10/10/2012 07:16 PM, Jose Torres Diaz wrote:
> > Hi Josh,
> >
> > I am very keen on this block (UHD_AMSG_SOURCE), because I saw that you
> post
> > a dictionary downstream in this example. Thus, I would like to analyze
> how
> > it works. I've tried to replicate your code in a different block, but I
> > have some issues with the dictionary.
> >
> > Here is my summary:
> >
> > *Issue (1):* According to the wiki:
> >
http://gnuradio.org/redmine/projects/gnuradio/wiki/TypePMT#Dictionaries.
> If
> > I want to set values in the dictionary, I should use
> >
> > pmt_dict_set(%parameters here)
>
> Doesnt exist. I think it should be added. This version could add the
> key/value to the existing dictionary. vs the pmt_dict_add which creates
> a new one
>
> >
> > However, this command it doesn't work for me (as it is not part of pmt).
> >
> > The command that works without problem is:
> >
> > pmt_dict_add(%parameters here)
> >
> >
> > *Issue (2):* I've set a dictionary with one value on it. (See the code
> > below). However, it is always empty when I tried to check the items, keys
> > or values:
> >
> > pmt::pmt_t value_dict=pmt::pmt_make_dict();
> >
std::cout << std::endl << "Making a dictionary : " << value_dict
> > <<std::endl;
> > pmt::pmt_dict_add (value_dict,blob_key,pmt::pmt_from_uint64(10));
> > std::cout << std::endl << "Adding the value, items : " <<
> > pmt::pmt_dict_items(value_dict) <<std::endl;
> > std::cout << std::endl << "Adding the value, keys : " <<
> > pmt::pmt_dict_keys(value_dict) <<std::endl;
> > std::cout << std::endl << "Adding the value, values : " <<
> > pmt::pmt_dict_values(value_dict) <<std::endl;
> >
> > Results (always empty!):
>
> the code to add a key/value actually returns a new dictionary and doesnt
> change the old ones.
>
> I know this pmt stuff is crazy. Why didnt we just use std::map?
:-)
>
> >
> > Adding the value, items : ()
> > Adding the value, keys : ()
> > Adding the value, values : ()
> >
> >
> > *Issue (3):* I post the dictionary downstream similar to the code in
> > "UHD_AMSG_SOURCE":
> >
> > this->post_msg(0,value_dict,_msg.value,_id);
>
> The key has to the a pmt that holds a string, the value does not have
> the restriction.
>
> >
> > However, similarly to my previous post, the flow graph complains that
> this
> > is a wrong type:
> >
> > thread[thread-per-block[8]: <gr_block msg_sourcer (9)>]:
> > gr_block_detail::add_item_tag key: wrong_type : ()
> >
> > For these reasons, I would like to see how your code is working with
> these
> > dictionaries.
> >
> > Thanks again,
>
>
> > Jose
> >
> > On Thu, Oct 11, 2012 at 12:05 PM, Jose Torres Diaz <
> >
address@hidden> wrote:
> >
> >> Hi Josh,
> >>
> >> I've changed the .xml file. Also, I've checked the new top_block.py file
> >> and it is generated as follows:
> >>
> >> self.extras_uhd_amsg_source_0 =
> >> gr_extras.uhd_amsg_source(uhd.device_addr="172.17.3.140"
> >>
> >> However, it is still complaining when I run the flow graph:
> >>
> >> File "/home/asrpuser/Desktop/Jose Torres Material /top_block.py",
> line 33
> >> self.extras_uhd_amsg_source_0 =
> >> gr_extras.uhd_amsg_source(uhd.device_addr="add=172.17.3.140")
> >>
SyntaxError: keyword can't be an _expression_
> >>
> >> Thanks,
> >>
> >> Jose.
> >>
> >>
> >>
> >> On Thu, Oct 11, 2012 at 11:44 AM, Josh Blum <
address@hidden> wrote:
> >>
> >>>
> >>>
> >>> On 10/10/2012 06:09 PM, Jose Torres Diaz wrote:
> >>>> Hi Josh,
> >>>>
> >>>> Do you mean to change in the top_block.py?. I did this, but when I run
> >>>> again the top_block.py, it changes back to:
> >>>>
> >>>> gr_extras.uhd_amsg_source(device_addr="add=172.17.3.140")
> >>>>
> >>>> even if I try:
> >>>>
> >>>>
gr_extras.uhd_amsg_source(uhd.device_addr="add=172.17.3.140")
> >>>>
> >>>> Thanks again Josh,
> >>>>
> >>>
> >>> I see. Its the xml definition. Too bad python/swig does get the
> >>> constructor overloads that c++ sees.
> >>>
> >>> I pushed this change to the repo:
> >>>> diff --git a/grc/extras_uhd_amsg_source.xml
> >>> b/grc/extras_uhd_amsg_source.xml
> >>>> index 5f8c261..5bb59f0 100644
> >>>> --- a/grc/extras_uhd_amsg_source.xml
> >>>> +++ b/grc/extras_uhd_amsg_source.xml
> >>>> @@ -4,7 +4,7 @@
> >>>> <key>extras_uhd_amsg_source</key>
> >>>> <import>from gnuradio import uhd</import>
> >>>>
<import>import gnuradio.extras as gr_extras</import>
> >>>> - <make>gr_extras.uhd_amsg_source(device_addr=$dev_addr)</make>
> >>>> +
> <make>gr_extras.uhd_amsg_source(uhd.device_addr($dev_addr))</make>
> >>>> <param>
> >>>> <name>Device Addr</name>
> >>>> <key>dev_addr</key>
> >>>
> >>> -josh
> >>>
> >>>> Regards,
> >>>>
> >>>> Jose
> >>>>
> >>>> On Thu, Oct 11, 2012 at 11:24 AM, Josh Blum <
address@hidden>
> wrote:
> >>>>
>
>>>>>
> >>>>>
> >>>>> On 10/10/2012 05:51 PM, Jose Torres Diaz wrote:
> >>>>>> Hi All,
> >>>>>>
> >>>>>> I'm checking the functionality of the block "UHD AMsg Source" using
> >>> the
> >>>>>> USRP N210. The device is correctly detected as you can see:
> >>>>>>
> >>>>>> uhd_find_devices
> >>>>>> linux; GNU C++ version 4.6.1; Boost_104601;
> >>> UHD_003.004.003-221-g9d6f9492
> >>>>>>
> >>>>>> --------------------------------------------------
> >>>>>> -- UHD Device 0
> >>>>>> --------------------------------------------------
> >>>>>> Device Address:
>
>>>>>> type: usrp2
> >>>>>> addr: 172.17.3.140
> >>>>>> name:
> >>>>>> serial: E0R17TCUP
> >>>>>>
> >>>>>> I've attached a screen-shot of the GRC file. When I run the flow
> >>> graph, I
> >>>>>> get the following error:
> >>>>>>
> >>>>>> Traceback (most recent call last):
> >>>>>> File "/home/asrpuser/Desktop/Jose Torres Material /top_block.py",
> >>> line
> >>>>>> 54, in <module>
> >>>>>> tb = top_block()
> >>>>>> File "/home/asrpuser/Desktop/Jose Torres Material /top_block.py",
> >>> line
>
>>>>>> 33, in __init__
> >>>>>> self.extras_uhd_amsg_source_0 =
> >>>>>> gr_extras.uhd_amsg_source(device_addr="add=172.17.3.140")
> >>>>>
> >>>>> try gr_extras.uhd_amsg_source(uhd.device_addr("addr=172.17.3.140"))
> >>>>>
> >>>>>> File
> >>>>>>
> >>>
> "/usr/local/lib/python2.7/dist-packages/gnuradio/extras/extras_swig.py",
> >>>>>> line 5384, in make
> >>>>>> return _extras_swig.uhd_amsg_source_make(*args, **kwargs)
> >>>>>> TypeError: in method 'uhd_amsg_source_make', argument 1 of type
> >>>>>> 'uhd::device_addr_t const &'
> >>>>>>
> >>>>>> Anyone has seen an error like this
before?, How can I
> >>> solve/workaround
> >>>>>> this error?
> >>>>>>
> >>>>>> Thanks a lot for your help,
> >>>>>>
> >>>>>> Jose.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> Discuss-gnuradio mailing list
> >>>>>>
address@hidden> >>>>>>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio> >>>>>>
> >>>>>
> >>>>>
_______________________________________________
> >>>>> 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/20121015/2e38622b/attachment.html>
------------------------------
Message:
5
Date: Mon, 15 Oct 2012 12:16:25 +1030
From: Jose Torres Diaz <
address@hidden>
To:
address@hiddenCc:
address@hiddenSubject: Re: [Discuss-gnuradio] Error using block UHD AMsg Source
Message-ID:
<CANLn+
address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
Hi Josh,
I've figure out the problem. I didn't check this:
https://github.com/guruofquality/grextras/commit/075bf6ec7e9f8169d9dee59fb9e74d13146b6ddbwhere you changed this:
- pmt::pmt_dict_add(value_dict, TIME_KEY, timestamp);
+ value_dict = pmt::pmt_dict_add(value_dict, TIME_KEY, timestamp);
Thanks,
Jose.
On Mon, Oct 15, 2012 at 11:54 AM, Jose Torres Diaz <
address@hidden> wrote:
> Hi Josh,
>
> You mentioned that:
>
>
> "the code to add a key/value actually returns a new dictionary and doesnt
> change the old ones.
>
> I know this pmt stuff is crazy. Why didnt we just use std::map? :-)"
>
> I'm confused with this, because I created the dictionary and added the
> values.
However, when I've checked the type, it shows that it is a
> dictionary (as I expected), but also it is always empty.
>
> pmt::pmt_t value_dict = pmt::pmt_make_dict();
> std::cout << std::endl << "Making a dictionary" << std::endl;
> pmt::pmt_dict_add(value_dict, TIME_KEY, pmt::pmt_from_uint64(3200));
> this->post_msg(0, AMSG_KEY, value_dict, _id);
> std::cout << std::endl << "Posting downstream" << std::endl;
>
> std::cout << std::endl << "checking if null:"
> <<pmt::pmt_is_null(value_dict)<< std::endl; //Return true
> std::cout << std::endl << "checking if dict:"
> <<pmt::pmt_is_dict(value_dict)<< std::endl; //Return true
>
> So, does it
mean that I cannot access the values that are added into the
> dictionary "value_dict"?. If it is possible, how should I access them?.
>
> *Sort of related question:*
>
> Since this is dictionary, in order to debug my code I printed out the
> items, keys and values. I expected to see at least the items inside the
> dictionary, but again everything is empty.
>
> std::cout << std::endl << "Checking items ;" <<
> pmt::pmt_dict_items(value_dict)<<std::endl;
> std::cout << std::endl << "Checking keys ;" <<
> pmt::pmt_dict_keys(value_dict)<<std::endl;
> std::cout << std::endl << "Checking values;" <<
> pmt::pmt_dict_values(value_dict)<<std::endl;
>
>
> Thanks a lot for your help,
>
> Kind Regards,
>
> Jose
>
>
> On Thu, Oct 11, 2012 at 2:43 PM,
Josh Blum <
address@hidden> wrote:
>
>>
>>
>> On 10/10/2012 07:16 PM, Jose Torres Diaz wrote:
>> > Hi Josh,
>> >
>> > I am very keen on this block (UHD_AMSG_SOURCE), because I saw that you
>> post
>> > a dictionary downstream in this example. Thus, I would like to analyze
>> how
>> > it works. I've tried to replicate your code in a different block, but I
>> > have some issues with the dictionary.
>> >
>> > Here is my summary:
>> >
>> > *Issue (1):* According to the wiki:
>> >
http://gnuradio.org/redmine/projects/gnuradio/wiki/TypePMT#Dictionaries.
>> If
>> > I want to
set values in the dictionary, I should use
>> >
>> > pmt_dict_set(%parameters here)
>>
>> Doesnt exist. I think it should be added. This version could add the
>> key/value to the existing dictionary. vs the pmt_dict_add which creates
>> a new one
>>
>> >
>> > However, this command it doesn't work for me (as it is not part of pmt).
>> >
>> > The command that works without problem is:
>> >
>> > pmt_dict_add(%parameters here)
>> >
>> >
>> > *Issue (2):* I've set a dictionary with one value on it. (See the code
>> > below). However, it is always empty when I tried to check the items,
>> keys
>> > or values:
>> >
>> > pmt::pmt_t value_dict=pmt::pmt_make_dict();
>> > std::cout << std::endl <<
"Making a dictionary : " << value_dict
>> > <<std::endl;
>> > pmt::pmt_dict_add (value_dict,blob_key,pmt::pmt_from_uint64(10));
>> > std::cout << std::endl << "Adding the value, items : " <<
>> > pmt::pmt_dict_items(value_dict) <<std::endl;
>> > std::cout << std::endl << "Adding the value, keys : " <<
>> > pmt::pmt_dict_keys(value_dict) <<std::endl;
>> > std::cout << std::endl << "Adding the value, values : " <<
>> > pmt::pmt_dict_values(value_dict) <<std::endl;
>> >
>> > Results (always empty!):
>>
>> the code to add a key/value actually returns a new dictionary and doesnt
>> change the old ones.
>>
>> I know this pmt stuff is crazy. Why didnt we just
use std::map? :-)
>>
>> >
>> > Adding the value, items : ()
>> > Adding the value, keys : ()
>> > Adding the value, values : ()
>> >
>> >
>> > *Issue (3):* I post the dictionary downstream similar to the code in
>> > "UHD_AMSG_SOURCE":
>> >
>> > this->post_msg(0,value_dict,_msg.value,_id);
>>
>> The key has to the a pmt that holds a string, the value does not have
>> the restriction.
>>
>> >
>> > However, similarly to my previous post, the flow graph complains that
>> this
>> > is a wrong type:
>> >
>> > thread[thread-per-block[8]: <gr_block msg_sourcer (9)>]:
>> > gr_block_detail::add_item_tag key: wrong_type : ()
>> >
>> > For these reasons, I would like to see how your code is
working with
>> these
>> > dictionaries.
>> >
>> > Thanks again,
>> >
>> > Jose
>> >
>> > On Thu, Oct 11, 2012 at 12:05 PM, Jose Torres Diaz <
>> >
address@hidden> wrote:
>> >
>> >> Hi Josh,
>> >>
>> >> I've changed the .xml file. Also, I've checked the new top_block.py
>> file
>> >> and it is generated as follows:
>> >>
>> >> self.extras_uhd_amsg_source_0 =
>> >> gr_extras.uhd_amsg_source(uhd.device_addr="172.17.3.140"
>> >>
>> >> However, it is still complaining when I run the flow graph:
>> >>
>> >> File "/home/asrpuser/Desktop/Jose Torres Material
/top_block.py",
>> line 33
>> >> self.extras_uhd_amsg_source_0 =
>> >> gr_extras.uhd_amsg_source(uhd.device_addr="add=172.17.3.140")
>> >> SyntaxError: keyword can't be an _expression_
>> >>
>> >> Thanks,
>> >>
>> >> Jose.
>> >>
>> >>
>> >>
>> >> On Thu, Oct 11, 2012 at 11:44 AM, Josh Blum <
address@hidden>
>> wrote:
>> >>
>> >>>
>> >>>
>> >>> On 10/10/2012 06:09 PM, Jose Torres Diaz wrote:
>> >>>> Hi Josh,
>> >>>>
>> >>>> Do you mean to change in the top_block.py?. I did this, but when I
>> run
>> >>>> again the
top_block.py, it changes back to:
>> >>>>
>> >>>> gr_extras.uhd_amsg_source(device_addr="add=172.17.3.140")
>> >>>>
>> >>>> even if I try:
>> >>>>
>> >>>> gr_extras.uhd_amsg_source(uhd.device_addr="add=172.17.3.140")
>> >>>>
>> >>>> Thanks again Josh,
>> >>>>
>> >>>
>> >>> I see. Its the xml definition. Too bad python/swig does get the
>> >>> constructor overloads that c++ sees.
>> >>>
>> >>> I pushed this change to the repo:
>> >>>> diff --git a/grc/extras_uhd_amsg_source.xml
>> >>> b/grc/extras_uhd_amsg_source.xml
>> >>>> index 5f8c261..5bb59f0 100644
>> >>>> ---
a/grc/extras_uhd_amsg_source.xml
>> >>>> +++ b/grc/extras_uhd_amsg_source.xml
>> >>>> @@ -4,7 +4,7 @@
>> >>>> <key>extras_uhd_amsg_source</key>
>> >>>> <import>from gnuradio import uhd</import>
>> >>>> <import>import gnuradio.extras as gr_extras</import>
>> >>>> - <make>gr_extras.uhd_amsg_source(device_addr=$dev_addr)</make>
>> >>>> +
>> <make>gr_extras.uhd_amsg_source(uhd.device_addr($dev_addr))</make>
>> >>>> <param>
>> >>>> <name>Device Addr</name>
>> >>>>
<key>dev_addr</key>
>> >>>
>> >>> -josh
>> >>>
>> >>>> Regards,
>> >>>>
>> >>>> Jose
>> >>>>
>> >>>> On Thu, Oct 11, 2012 at 11:24 AM, Josh Blum <
address@hidden>
>> wrote:
>> >>>>
>> >>>>>
>> >>>>>
>> >>>>> On 10/10/2012 05:51 PM, Jose Torres Diaz wrote:
>> >>>>>> Hi All,
>> >>>>>>
>> >>>>>> I'm checking the functionality of the block "UHD AMsg Source" using
>> >>> the
>> >>>>>> USRP N210. The device is correctly detected as you can see:
>>
>>>>>>
>> >>>>>> uhd_find_devices
>> >>>>>> linux; GNU C++ version 4.6.1; Boost_104601;
>> >>> UHD_003.004.003-221-g9d6f9492
>> >>>>>>
>> >>>>>> --------------------------------------------------
>> >>>>>> -- UHD Device 0
>> >>>>>> --------------------------------------------------
>> >>>>>> Device Address:
>> >>>>>> type: usrp2
>> >>>>>> addr: 172.17.3.140
>> >>>>>> name:
>> >>>>>> serial: E0R17TCUP
>> >>>>>>
>> >>>>>> I've attached a screen-shot of the GRC file. When I run the flow
>> >>> graph,
I
>> >>>>>> get the following error:
>> >>>>>>
>> >>>>>> Traceback (most recent call last):
>> >>>>>> File "/home/asrpuser/Desktop/Jose Torres Material /top_block.py",
>> >>> line
>> >>>>>> 54, in <module>
>> >>>>>> tb = top_block()
>> >>>>>> File "/home/asrpuser/Desktop/Jose Torres Material /top_block.py",
>> >>> line
>> >>>>>> 33, in __init__
>> >>>>>> self.extras_uhd_amsg_source_0 =
>> >>>>>> gr_extras.uhd_amsg_source(device_addr="add=172.17.3.140")
>> >>>>>
>> >>>>> try gr_extras.uhd_amsg_source(uhd.device_addr("addr=172.17.3.140"))
>>
>>>>>
>> >>>>>> File
>> >>>>>>
>> >>>
>> "/usr/local/lib/python2.7/dist-packages/gnuradio/extras/extras_swig.py",
>> >>>>>> line 5384, in make
>> >>>>>> return _extras_swig.uhd_amsg_source_make(*args, **kwargs)
>> >>>>>> TypeError: in method 'uhd_amsg_source_make', argument 1 of type
>> >>>>>> 'uhd::device_addr_t const &'
>> >>>>>>
>> >>>>>> Anyone has seen an error like this before?, How can I
>> >>> solve/workaround
>> >>>>>> this error?
>> >>>>>>
>> >>>>>> Thanks a lot for your help,
>> >>>>>>
>> >>>>>>
Jose.
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> _______________________________________________
>> >>>>>> Discuss-gnuradio mailing list
>> >>>>>>
address@hidden>> >>>>>>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>> >>>>>>
>> >>>>>
>> >>>>> _______________________________________________
>> >>>>> 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/20121015/73476cc9/attachment.html>
------------------------------
Message: 6
Date: Mon, 15 Oct 2012 03:15:44 -0700 (PDT)
From: nexy_sm <
address@hidden>
To:
address@hiddenSubject: Re: [Discuss-gnuradio] cannot make new signal processing
block
Message-ID: <
address@hidden>
Content-Type: text/plain; charset=us-ascii
Any suggestions how to make this thing working?
--
View this message in context:
http://gnuradio.4.n7.nabble.com/cannot-make-new-signal-processing-block-tp37924p37997.htmlSent from the GnuRadio mailing list archive at Nabble.com.
------------------------------
Message: 7
Date: Mon, 15 Oct
2012 05:11:40 -0700 (PDT)
From: Sajjad Safdar <
address@hidden>
To: "
address@hidden" <
address@hidden>
Subject: Re: [Discuss-gnuradio] 4. Re: usrp_nbfm_ptt.py in Gnu Radio
Companion. (Martin Braun (CEL)) Discuss-gnuradio Digest, Vol 119,
Issue 13
Message-ID:
<
address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
Dear Martin,
Yes i
can see that i hve errors because of the red marks, but i first want to know that whether i have all the control stuff in my reciever as from usrp_nbfm_ptt.py or should i have to add some more stuff which is not exactly translated into my GRC.
Best Regards,
SAJJAD SAFDAR
________________________________
From: "
address@hidden" <
address@hidden>
To:
address@hidden Sent: Saturday, October 13, 2012 9:00 PM
Subject: Discuss-gnuradio Digest, Vol 119, Issue 13
Send Discuss-gnuradio mailing list submissions to
???
address@hiddenTo subscribe or unsubscribe via the World Wide Web, visit
???
https://lists.gnu.org/mailman/listinfo/discuss-gnuradioor, via email, send a message with subject or body 'help' to
???
address@hiddenYou can reach the person managing the list at
???
address@hiddenWhen replying, please edit your Subject line so it is more specific
than "Re: Contents of Discuss-gnuradio digest..."
Today's Topics:
? 1. Problem with vector insert (Volker Schroer)
? 2. Re: Problem with vector insert (Tom Rondeau)
?
3. usrp_nbfm_ptt.py in Gnu Radio Companion. (Sajjad Safdar)
? 4. Re: usrp_nbfm_ptt.py in Gnu Radio Companion. (Martin Braun (CEL))
? 5. Re: Can the io signatur of the gnuradio blocks be dynamically
? ? ? updated? (Alex Zhang)
? 6. Re: [ USRP configuration with/without MIMO in??? unshared
? ? ? Ethernet mode ] (Ashish Raste)
? 7. Re: cannot make new signal processing block (nexy_sm)
? 8. grextras "make test" failure (Rick Graham)
? 9. Re: grextras "make test" failure (Josh Blum)
? 10. OOK Modulation (sibar002)
? 11. OOK Modulation (sibar002)
? 12. Re: Can the io signatur of the gnuradio blocks be dynamically
? ? ? updated? (Alex Zhang)
? 13. Re: GRC: set order of block instantiations (Josh Blum)
----------------------------------------------------------------------
Message: 1
Date: Fri, 12 Oct 2012 18:02:59 +0200
From: Volker Schroer <
address@hidden>
To:
address@hiddenSubject: [Discuss-gnuradio] Problem with vector insert
Message-ID: <
address@hidden>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Hi all,
I just tried to play around with the vector insert block.
It works if the elements are of type byte.
But if I try another type such as int I get the error
? File "./top_block.py", line 29, in __init__
? ? self.gr_vector_insert_x_0 = gr.vector_insert_i((10,12,13), 4, 3)
AttributeError: 'module' object has no attribute 'vector_insert_i'
If I look into the build directory I see only gr_vector_insert _b.* files.
So I tried to modify the
generate_common.py in
gnuradio/gnuradio-core/src/lib/gengen. But it seems that I didn't find
the proper place. Only gr_vector_insert _b.* files will be generated.
Any ideas ?
Thanks -- Volker
------------------------------
Message: 2
Date: Fri, 12 Oct 2012 12:06:37 -0400
From: Tom Rondeau <
address@hidden>
To: Volker Schroer <
address@hidden>
Cc:
address@hiddenSubject: Re: [Discuss-gnuradio] Problem with vector insert
Message-ID:
??? <CA+
address@hidden>
Content-Type: text/plain; charset=ISO-8859-1
On Fri, Oct 12, 2012 at 12:02 PM, Volker Schroer <
address@hidden> wrote:
> Hi all,
>
> I just tried to play around with the vector insert block.
> It works if the elements are of type byte.
> But if I try another type such as int I get the error
>
>? File "./top_block.py", line 29, in __init__
>? ? self.gr_vector_insert_x_0 = gr.vector_insert_i((10,12,13), 4, 3)
> AttributeError: 'module' object has no attribute 'vector_insert_i'
>
> If I look into the build directory I see only gr_vector_insert _b.* files.
>
> So I tried to modify the generate_common.py in
>
gnuradio/gnuradio-core/src/lib/gengen. But it seems that I didn't find the
> proper place. Only gr_vector_insert _b.* files will be generated.
>
> Any ideas ?
>
> Thanks -- Volker
Volker,
Take a look at gengen/CMakeLists.txt on line 85. You should just be
able to add the data types you want there. Depending on the guys of
the vector_insert block, you should be able to use any of the standard
data types.
Tom
------------------------------
Message: 3
Date: Fri, 12 Oct 2012 09:13:52 -0700 (PDT)
From: Sajjad Safdar <
address@hidden>
To: "
address@hidden" <
address@hidden>
Subject: [Discuss-gnuradio] usrp_nbfm_ptt.py in Gnu Radio Companion.
Message-ID:
??? <
address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
Hello,
I am trying to implement usrp_nbfm_ptt.py receiver side in GRC, but i am not sure whether I have translated the code into graphical manner right or there is something wrong, because there is always error.??
Screen shoot is attached for reference.
Best Regards,
SAJJAD SAFDAR
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20121012/0f67f228/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Ptt_recieve.grc.png
Type: image/png
Size: 98289 bytes
Desc: not available
URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20121012/0f67f228/attachment.png>
------------------------------
Message: 4
Date: Fri, 12 Oct 2012 18:30:09 +0200
From: "Martin Braun (CEL)" <
address@hidden>
To:
address@hiddenSubject: Re: [Discuss-gnuradio] usrp_nbfm_ptt.py in Gnu Radio
???
Companion.
Message-ID: <
address@hidden>
Content-Type: text/plain; charset="utf-8"
On Fri, Oct 12, 2012 at 09:13:52AM -0700, Sajjad Safdar wrote:
> I am trying to implement usrp_nbfm_ptt.py receiver side in GRC, but i am not
> sure whether I have translated the code into graphical manner right or there is
> something wrong, because there is always error.?
In that case, there's probably something wrong :)
Everything that's marked red, you must check. Also, check the error
messages. Perhaps you haven't set the rates to integer values?
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20121012/f9fb238d/attachment.pgp>
------------------------------
Message: 5
Date: Fri, 12 Oct 2012 11:39:04 -0500
From: Alex Zhang <
address@hidden>
To: Tom Rondeau <
address@hidden>
Cc:
address@hidden, gnuradio mailing list <
address@hidden>
Subject: Re: [Discuss-gnuradio] Can the io signatur of the gnuradio
??? blocks be dynamically updated?
Message-ID:
??? <CA+
address@hidden>
Content-Type: text/plain; charset="windows-1252"
Hi Tom, thanks for the response, but I am still have questions regarding
your comments as below inline:
On Fri, Oct 12, 2012 at 10:12 AM, Tom Rondeau <
address@hidden> wrote:
> On Thu, Oct 11, 2012 at 7:41 PM, Alex Zhang <
address@hidden>
> wrote:
> > Let me take an example for my question.
> >
> > For some OFDM blocks, the io signature is determined by the fft length,
> > during the constructing the block. However, sometimes, we need to adjust
> the
> > the fft length dynamically based on some physical environment or
> computing
> > environment.
>
> Hi Alex,
>
> I haven't thought about this too much, so my recollection of how
> things work could be a bit off. But I'm pretty sure that the answer is
> no, you cannot dynamically adjust this. You'd be messing too much with
> the scheduler.
>
> The way that you can do it is to lock the
flowgraph, swap out the
> block in question with a new block that has the new parameters, and
> unlock to restart the graph. But you are going to lose samples in the
> buffers into the block that you're removing.
>
> This would actually be a great case for the event stream scheduler.
> You could have different processing graphs that are selected based on
> the state that you need. So you could populate graphs of different FFT
> lengths and then dynamically select the right graph based on an event
> when you detect a different length is required. This is still a
> work-in-progress:
https://github.com/osh/gr-eventstream.
>
>
It seems that the event stream scheduler can only handle finite options for
selection?
This is different with what I am expecting. Sometimes, you don't know the
actual options and the
dynamic parameters is computed based on some other
optimization algorithm. Thus I can not pre-configure finite graphs for my
selection, but just adjust the exiting graph with specified parameter.
BTW, maybe my expectation is kind of over-design which brings more risk
than benefits. But from the Software defined radio perspective, the
dynamic/adaptive signal processing chain with expecting flexibility really
deserves? more attention.
> Tom
>
>
> > On Thu, Oct 11, 2012 at 6:29 PM, Alex Zhang <
address@hidden>
> wrote:
> >>
> >> Hi,
> >>
> >> I know it may not be possible in the current gnuradio blocks framework,
> >> but I am still curious if it can be done.
> >> When I write a signal processing block, the io signature could
be
> >> determined by some parameters. It is ok, if these parameters are fixed.
> But
> >> sometimes, especially in the adaptive system, I need to dynamically
> update
> >> these parameter, which result in the updating of io signature of the
> blocks.
> >> I can make the io_signature to be independent with the dynamic
> parameters,
> >> but it could be more convenient if the io signature can be adapted. Of
> >> course, it is not easy, as the io signature change could impact the
> upstream
> >> and downstream.
> >>
> >> Thanks,
> >>
> >> --
> >>
> >> Alex,
> >> Dreams can come true ? just believe.
> >>
> >
> >
> >
> > --
> >
> > Alex,
> > Dreams can come true ? just believe.
>
>
> >
> > _______________________________________________
> > Discuss-gnuradio mailing list
> >
address@hidden> >
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio> >
>
--
Alex,
*Dreams can come true ? just believe.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20121012/829cfe67/attachment.html>
------------------------------
Message: 6
Date: Sat, 13 Oct 2012 01:06:04 +0800
From: Ashish Raste <
address@hidden>
To:
address@hiddenSubject: Re: [Discuss-gnuradio] [ USRP configuration with/without MIMO
??? in??? unshared Ethernet mode ]
Message-ID:
??? <CALAnUMTS-qjq+
address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
*Thanks Josh.
Now I've got a clear idea on how the MIMO acts in different Ethernet
configurations**.
*
>
>
> Message: 1
> Date: Thu, 11 Oct 2012 11:34:39 -0700
> From: Josh Blum <
address@hidden>
> To:
address@hidden> Subject: Re: [Discuss-gnuradio] [ USRP configuration with/without MIMO
>? ? ? ? in unshared Ethernet mode ]
> Message-ID: <
address@hidden>
> Content-Type: text/plain; charset=windows-1252
>
>
> > received/transmitted via its own Ethernet interface? and the master?s
> > basedband data within the GRC design is received/transmitted? via its own
> > Ethernet interface? So, this means that the MIMO cable is only used for
> >? sending the clock and time signals from the Master to the Slave ?*
>
> Thats correct. When each USRP has its own ethernet link, the MIMO cable
> is only used for clock and time signals.
>
> >
> > *
*
> >
> > *Next, I retained the MIMO cable, set the Master USRP?s clock source to
> > external? and have a 10MHz source connected to the Reference input. The
> > slave USRP?s clock source and time source remained as MIMO mode.? So my
> > question is would the Slave USRP received the 10MHz Reference via the
> MIMO
> > cable? ? *
> >
>
> Yes. The slave device will still get 10MHz over the MIMO cable. This is
> regardless of how the master gets his reference.
>
> > * *
> >
> > *My second question is:
> > In a 4X4 USRP setup, how can we synchronize all the 4 USRPs without a
> MIMO
> > connection (between 2 USRPs within a pair), using a 10MHz reference split
> > to each of the USRP and a PPS source?
>
> Yes, you can split 10MHz and PPS signal to all 4 units.
>
>
--
Ashish
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20121013/67039a4d/attachment.html>
------------------------------
Message: 7
Date: Fri, 12 Oct 2012 11:04:57 -0700 (PDT)
From: nexy_sm <
address@hidden>
To:
address@hiddenSubject: Re: [Discuss-gnuradio] cannot make new signal processing
??? block
Message-ID: <
address@hidden>
Content-Type: text/plain;
charset=us-ascii
Python path is OK. Gnuradio works fine, I have tried some examples using GRC,
etc.
I also used gr-modtool like it was explained on the website.
I haven't looked at swig interface file since it was not part of the
tutorial, but I think it should have been generated correctly by gr-modtool.
How can I check installation of the SWIG?
Anyway I will not have chance to try anything until monday.
Regards and thanks
--
View this message in context:
http://gnuradio.4.n7.nabble.com/cannot-make-new-signal-processing-block-tp37924p37982.htmlSent from the GnuRadio mailing list archive at Nabble.com.
------------------------------
Message: 8
Date: Fri, 12 Oct 2012 17:06:52 -0400
From: Rick Graham <
address@hidden>
To: gnuradio <
address@hidden>
Subject: [Discuss-gnuradio] grextras "make test" failure
Message-ID:
??? <CAF+zCGQ+Hj8X9WVpemCUybZ7xv-dbPNd=
address@hidden>
Content-Type: text/plain; charset=ISO-8859-1
Is this a cause for concern?
[from "ctest -V"]
? ? Start 4: qa_noise_source
4: Test command: /bin/sh
"/usr/local/src/build-gnuradio/grextras/build/python/qa_noise_source_test.sh"
4: Test timeout computed to be: 9.99988e+06
4: linux; GNU C++ version 4.6.3 20120306 (Red Hat 4.6.3-2);
Boost_104700; UHD_003.004.003-255-gc7054ce5
4:
4: F
4:
======================================================================
4: FAIL: test_001 (__main__.test_noise_source)
4: ----------------------------------------------------------------------
4: Traceback (most recent call last):
4:? File "/usr/local/src/build-gnuradio/grextras/python/qa_noise_source.py",
line 55, in test_001
4:? ? self.assertEqual (expected_result, dst_data)
4: AssertionError: Tuples differ: (-6.88858699798584, 26.1499595... !=
(-6.88858699798584, 26.1499595...
4:
4: First differing element 10:
4: 1.21760773659
4: 1.21761083603
4:
4:? (-6.88858699798584,
4:? ? 26.149959564208984,
4:? ? 20.575775146484375,
4:? ? -7.934014320373535,
4:? ? 5.335927486419678,
4:? ? -12.552099227905273,
4:? ? 6.333674430847168,
4:? ? -23.830753326416016,
4:? ? -16.603046417236328,
4:? ? 2.9676761627197266,
4: -? 1.2176077365875244,
4: +? 1.2176108360290527,
4:? ?
15.100193977355957)
4:
4: ----------------------------------------------------------------------
4: Ran 1 test in 0.008s
4:
4: FAILED (failures=1)
4/9 Test #4: qa_noise_source ..................***Failed? ? 0.35 sec
------------------------------
Message: 9
Date: Fri, 12 Oct 2012 14:37:12 -0700
From: Josh Blum <
address@hidden>
To:
address@hiddenSubject: Re: [Discuss-gnuradio] grextras "make test" failure
Message-ID: <
address@hidden>
Content-Type: text/plain; charset=ISO-8859-1
On 10/12/2012 02:06 PM, Rick Graham wrote:
> Is this a cause for concern?
Nah, just a slight
rounding issue. And in one of the blocks that doesnt
even need predictable output :-) I will take a look...
-josh
>
> [from "ctest -V"]
>? ? Start 4: qa_noise_source
>
> 4: Test command: /bin/sh
> "/usr/local/src/build-gnuradio/grextras/build/python/qa_noise_source_test.sh"
> 4: Test timeout computed to be: 9.99988e+06
> 4: linux; GNU C++ version 4.6.3 20120306 (Red Hat 4.6.3-2);
> Boost_104700; UHD_003.004.003-255-gc7054ce5
> 4:
> 4: F
> 4: ======================================================================
> 4: FAIL: test_001 (__main__.test_noise_source)
> 4: ----------------------------------------------------------------------
> 4: Traceback (most recent call last):
> 4:? File "/usr/local/src/build-gnuradio/grextras/python/qa_noise_source.py",
> line 55, in test_001
> 4:? ? self.assertEqual
(expected_result, dst_data)
> 4: AssertionError: Tuples differ: (-6.88858699798584, 26.1499595... !=
> (-6.88858699798584, 26.1499595...
> 4:
> 4: First differing element 10:
> 4: 1.21760773659
> 4: 1.21761083603
> 4:
> 4:? (-6.88858699798584,
> 4:? ? 26.149959564208984,
> 4:? ? 20.575775146484375,
> 4:? ? -7.934014320373535,
> 4:? ? 5.335927486419678,
> 4:? ? -12.552099227905273,
> 4:? ? 6.333674430847168,
> 4:? ? -23.830753326416016,
> 4:? ? -16.603046417236328,
> 4:? ? 2.9676761627197266,
> 4: -? 1.2176077365875244,
> 4: +? 1.2176108360290527,
> 4:? ? 15.100193977355957)
> 4:
> 4: ----------------------------------------------------------------------
> 4: Ran 1 test in 0.008s
> 4:
> 4: FAILED (failures=1)
> 4/9 Test #4: qa_noise_source ..................***Failed? ? 0.35 sec
>
>
_______________________________________________
> Discuss-gnuradio mailing list
>
address@hidden>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>
------------------------------
Message: 10
Date: Fri, 12 Oct 2012 14:39:41 -0700 (PDT)
From: sibar002 <
address@hidden>
To:
address@hiddenSubject: [Discuss-gnuradio] OOK Modulation
Message-ID: <
address@hidden>
Content-Type: text/plain;
charset=us-ascii
--
View this message in context:
http://gnuradio.4.n7.nabble.com/OOK-Modulation-tp37985.htmlSent from the GnuRadio mailing list archive at Nabble.com.
------------------------------
Message: 11
Date: Fri, 12 Oct 2012 14:43:54 -0700 (PDT)
From: sibar002 <
address@hidden>
To:
address@hiddenSubject: [Discuss-gnuradio] OOK Modulation
Message-ID: <
address@hidden>
Content-Type: text/plain; charset=us-ascii
Hello,
I am working on creating a OOK Modulation
block. I have created a block
using the bpsk.py file as an example. I changed the constellation points
such that 1+0j and 0+0j. I am now trying to change the waveform that is
outputted from the USRP. I would like to transmit a square wave for 1 and
nothing for 0. I am not sure how I can do these. I would greatly appreciate
any help or advise that any one could give me. Thank you for your time and
help.
--
View this message in context:
http://gnuradio.4.n7.nabble.com/OOK-Modulation-tp37986.htmlSent from the GnuRadio mailing list archive at Nabble.com.
------------------------------
Message: 12
Date: Fri, 12 Oct 2012 16:57:52 -0500
From: Alex Zhang <
address@hidden>
To: Tom Rondeau <
address@hidden>
Cc:
address@hidden, gnuradio mailing list <
address@hidden>
Subject: Re: [Discuss-gnuradio] Can the io signatur of the gnuradio
??? blocks be dynamically updated?
Message-ID:
??? <CA+FEAnciERbLpgKtJ-_=5Tvbp-JfgNuJ=
address@hidden>
Content-Type: text/plain; charset="windows-1252"
Hi Tom,
There is the other thing I need to confirm:
It looks that the block's output buffer size can not be changed after its
construction, right?
On Fri, Oct 12, 2012 at 10:12 AM, Tom Rondeau <
address@hidden> wrote:
> On Thu, Oct 11, 2012 at 7:41 PM, Alex Zhang <
address@hidden>
> wrote:
> > Let me take an example for my question.
> >
> > For some OFDM blocks, the io signature is determined by the fft length,
> > during the constructing the block. However, sometimes, we need to adjust
> the
> > the fft length dynamically based on some physical environment or
> computing
> > environment.
>
> Hi Alex,
>
> I haven't thought about this too much, so my recollection of how
> things work could be a bit off. But I'm pretty sure that the answer is
> no, you cannot dynamically adjust this. You'd be messing too much with
> the scheduler.
>
> The way that you can do it is to lock the
flowgraph, swap out the
> block in question with a new block that has the new parameters, and
> unlock to restart the graph. But you are going to lose samples in the
> buffers into the block that you're removing.
>
> This would actually be a great case for the event stream scheduler.
> You could have different processing graphs that are selected based on
> the state that you need. So you could populate graphs of different FFT
> lengths and then dynamically select the right graph based on an event
> when you detect a different length is required. This is still a
> work-in-progress:
https://github.com/osh/gr-eventstream.
>
> Tom
>
>
> > On Thu, Oct 11, 2012 at 6:29 PM, Alex Zhang <
address@hidden>
> wrote:
> >>
> >> Hi,
> >>
> >> I know it may not be possible in the current gnuradio blocks framework,
> >> but I am still curious if it can be done.
> >> When I write a signal processing block, the io signature could be
> >> determined by some parameters. It is ok, if these parameters are fixed.
> But
> >> sometimes, especially in the adaptive system, I need to dynamically
> update
> >> these parameter, which result in the updating of io signature of the
> blocks.
> >> I can make the io_signature to be independent with the dynamic
> parameters,
> >> but it could be more convenient if the io signature can be adapted. Of
> >> course, it is not easy, as the io signature change could impact the
>
upstream
> >> and downstream.
> >>
> >> Thanks,
> >>
> >> --
> >>
> >> Alex,
> >> Dreams can come true ? just believe.
> >>
> >
> >
> >
> > --
> >
> > Alex,
> > Dreams can come true ? just believe.
> >
> >
> > _______________________________________________
> > Discuss-gnuradio mailing list
> >
address@hidden> >
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio> >
>
--
Alex,
*Dreams can come true ? just believe.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20121012/a6561e96/attachment.html>
------------------------------
Message: 13
Date: Fri, 12 Oct 2012 18:39:18 -0700
From: Josh Blum <
address@hidden>
To:
address@hiddenSubject: Re: [Discuss-gnuradio] GRC: set order of block instantiations
Message-ID: <
address@hidden>
Content-Type: text/plain; charset=ISO-8859-1
On 10/11/2012 12:03 PM, Gerald Baier wrote:
> Hi list,
>
> is there a way to set the order of block
instantiations in GNU Radio
> companion?
> The reason I am asking is, that I want to pass one block as a parameter
> to another block to get access to its methods. Is there an easier way to
> do this?
I think the order is either 1) alphabetical or 2) the z dimension of the
blocks in the flowgrah.
>
> Somehow related: Variables configured in GRC are defined before the
> block instantiations. Is it possible to tell GRC where in the final
> python script a variable should be defined?
>
The variable blocks are sorted by order of dependency amongst each other.
-josh
> Best regards
>
> Gerald
>
> _______________________________________________
> Discuss-gnuradio mailing list
>
address@hidden>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio------------------------------
_______________________________________________
Discuss-gnuradio mailing list
address@hiddenhttps://lists.gnu.org/mailman/listinfo/discuss-gnuradioEnd of Discuss-gnuradio Digest, Vol 119, Issue 13
*************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20121015/bfae81f5/attachment.html>
------------------------------
Message: 8
Date: Mon, 15 Oct 2012 10:23:55 -0400
From: Tom Rondeau <
address@hidden>
To: nexy_sm <
address@hidden>
Cc:
address@hiddenSubject: Re: [Discuss-gnuradio] cannot make new signal processing
block
Message-ID:
<CA+SzT6h4cphgerOrXpUWmyJW5zGMF_Wmp38om9+
address@hidden>
Content-Type: text/plain; charset=ISO-8859-1
On Fri, Oct 12, 2012 at 2:04 PM,
nexy_sm <
address@hidden> wrote:
> Python path is OK. Gnuradio works fine, I have tried some examples using GRC,
> etc.
Have you verified that that module is actually installed where you
think it is? If you are just building the gr-howto-write-a-block like
this:
cmake -DCMAKE_INSTALL_PREFIX=/opt/howto [path to source]/gr-howto-write-a-block
make && sudo make install
When you look in /opt/howto/lib/python2.7/dist-packages, you will find
a 'howto' directory. Under that, you'll find:
howto_swig.py
howto_swig.pyc
howto_swig.pyo
_howto_swig.so
__init__.py
__init__.pyc
__init__.pyo
All of those files have to be there. Then, if
PYTHONPATH=/opt/howto/lib/python2.7/dist-packages, you can 'import
howto' from inside Python.
Tom
> I also used gr-modtool like it was
explained on the website.
> I haven't looked at swig interface file since it was not part of the
> tutorial, but I think it should have been generated correctly by gr-modtool.
>
> How can I check installation of the SWIG?
>
> Anyway I will not have chance to try anything until monday.
>
> Regards and thanks
>
>
>
> --
> View this message in context:
http://gnuradio.4.n7.nabble.com/cannot-make-new-signal-processing-block-tp37924p37982.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------------------------------
Message: 9
Date: Mon, 15 Oct 2012 10:27:37 -0400
From: Tom Rondeau <
address@hidden>
To: sumitstop <
address@hidden>
Cc:
address@hiddenSubject: Re: [Discuss-gnuradio] Reg : difference between
gr.file_descriptor_source/sink and gr.file_source/sink
Message-ID:
<CA+SzT6h6t8nSu0CP0-uu+LS04mbpLQPFQNh7+
address@hidden>
Content-Type: text/plain; charset=ISO-8859-1
On Sun, Oct 14, 2012 at 10:18 AM, sumitstop
<
address@hidden> wrote:
> Q: What is the difference between gr.file_descriptor_source/sink and
> gr.file_source/sink .. I mean when shall we prefer one over other ?
file_source/sink takes in a string for a file name. This block will
create a new file with that name.
file_descriptor_source/sink takes in a file descriptor and writes to
that. This means you create your file descriptor externally and pass
it to the block. The file descriptor can be anything, now, an actual
file, FIFO, device, etc.
Tom
------------------------------
Message: 10
Date: Mon, 15 Oct 2012 10:32:21
-0400
From: Tom Rondeau <
address@hidden>
To: sibar002 <
address@hidden>
Cc:
address@hiddenSubject: Re: [Discuss-gnuradio] OOK Modulation
Message-ID:
<CA+
address@hidden>
Content-Type: text/plain; charset=ISO-8859-1
On Fri, Oct 12, 2012 at 5:43 PM, sibar002 <
address@hidden> wrote:
> Hello,
>
> I am working on creating a OOK Modulation block. I
have created a block
> using the bpsk.py file as an example. I changed the constellation points
> such that 1+0j and 0+0j. I am now trying to change the waveform that is
> outputted from the USRP. I would like to transmit a square wave for 1 and
> nothing for 0. I am not sure how I can do these. I would greatly appreciate
> any help or advise that any one could give me. Thank you for your time and
> help.
What are you seeing when you change the bpsk.py file for your new
constellation? That should be close. The bpsk modulator uses a root
raised cosine pulse shaping filter, is that what your problem is? If
you really want to transmit a square wave (but remember, doing that is
going to throw a lot of signal into the spectrum; also your
transmitter, receiver, and channel are all going to filter this signal
in their own way to distort it), you can change this to a LPF filter
with a wide enough
passband to pass the square wave. The filter also
interpolates the signal, which you'll want to do, too.
Tom
------------------------------
Message: 11
Date: Mon, 15 Oct 2012 10:34:52 -0400
From: Tom Rondeau <
address@hidden>
To: Alex Zhang <
address@hidden>
Cc:
address@hidden, gnuradio mailing list <
address@hidden>
Subject: Re: [Discuss-gnuradio] Can the io signatur of the gnuradio
blocks be dynamically updated?
Message-ID:
<CA+SzT6hgYJa413bCEgc8R1_RFTdwDLnivpq4KD8S+GCxh+
address@hidden>
Content-Type: text/plain; charset=windows-1252
On Fri, Oct 12, 2012 at 5:57 PM, Alex Zhang <
address@hidden> wrote:
> Hi Tom,
>
> There is the other thing I need to confirm:
> It looks that the block's output buffer size can not be changed after its
> construction, right?
On the latest git master/next, you can change the buffer size once
before you run the flowgraph. The buffers are actually created when
you call top_block.start(), and we've put in a call to the gr_blocks
that allows you to set the maximum buffer size. But you cannot change
it afterwards, even when you lock/unlock (you'd have to delete the old
block and create a new one).
The allocation of gr_buffer space is a very costly operation. You
really, really don't
want to be adjusting this during runtime.
Tom
> On Fri, Oct 12, 2012 at 10:12 AM, Tom Rondeau <
address@hidden> wrote:
>>
>> On Thu, Oct 11, 2012 at 7:41 PM, Alex Zhang <
address@hidden>
>> wrote:
>> > Let me take an example for my question.
>> >
>> > For some OFDM blocks, the io signature is determined by the fft length,
>> > during the constructing the block. However, sometimes, we need to adjust
>> > the
>> > the fft length dynamically based on some physical environment or
>> > computing
>> > environment.
>>
>> Hi Alex,
>>
>> I haven't thought about this too much, so my recollection of
how
>> things work could be a bit off. But I'm pretty sure that the answer is
>> no, you cannot dynamically adjust this. You'd be messing too much with
>> the scheduler.
>>
>> The way that you can do it is to lock the flowgraph, swap out the
>> block in question with a new block that has the new parameters, and
>> unlock to restart the graph. But you are going to lose samples in the
>> buffers into the block that you're removing.
>>
>> This would actually be a great case for the event stream scheduler.
>> You could have different processing graphs that are selected based on
>> the state that you need. So you could populate graphs of different FFT
>> lengths and then dynamically select the right graph based on an event
>> when you detect a different length is required. This is still a
>> work-in-progress:
https://github.com/osh/gr-eventstream.
>>
>> Tom
>>
>>
>> > On Thu, Oct 11, 2012 at 6:29 PM, Alex Zhang <
address@hidden>
>> > wrote:
>> >>
>> >> Hi,
>> >>
>> >> I know it may not be possible in the current gnuradio blocks framework,
>> >> but I am still curious if it can be done.
>> >> When I write a signal processing block, the io signature could be
>> >> determined by some parameters. It is ok, if these parameters are fixed.
>> >> But
>> >> sometimes, especially in the adaptive system, I need to dynamically
>> >> update
>> >> these parameter, which result in the
updating of io signature of the
>> >> blocks.
>> >> I can make the io_signature to be independent with the dynamic
>> >> parameters,
>> >> but it could be more convenient if the io signature can be adapted. Of
>> >> course, it is not easy, as the io signature change could impact the
>> >> upstream
>> >> and downstream.
>> >>
>> >> Thanks,
>> >>
>> >> --
>> >>
>> >> Alex,
>> >> Dreams can come true ? just believe.
>> >>
>> >
>> >
>> >
>> > --
>> >
>> > Alex,
>> > Dreams can come true ? just believe.
>> >
>> >
>> > _______________________________________________
>> > Discuss-gnuradio mailing
list
>> >
address@hidden>> >
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>> >
>
>
>
>
> --
>
> Alex,
> Dreams can come true ? just believe.
>
------------------------------
Message: 12
Date: Mon, 15 Oct 2012 16:41:48 +0200
From: Pol Henarejos <
address@hidden>
To:
address@hiddenSubject: [Discuss-gnuradio] How to report to gnuradio.org
Message-ID: <
address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
Dear list,
I am trying to report several bugs to gnuradio.org webpage but I cannot
see the option for reporting in the bug tracker. I am registered.
Thanks.
--
Pol Henarejos
Research Engineer, MSc
address@hiddenCentre Tecnol?gic de Telecomunicacions de Catalunya (CTTC)
Engineering Unit
Parc Mediterrani de la Tecnologia
Av. Carl Friedrich Gauss, 7
08860 Castelldefels, Barcelona (Spain)
Tel: +34 93 396 71 70 Ext: 2177
Fax. +34 93 645 29 01
www.cttc.es
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 549 bytes
Desc: OpenPGP digital signature
URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20121015/062c3313/attachment.pgp>
------------------------------
Message: 13
Date: Mon, 15 Oct 2012 10:51:50 -0400
From: Tom Rondeau <
address@hidden>
To: Pol Henarejos <
address@hidden>
Cc:
address@hiddenSubject: Re: [Discuss-gnuradio] How to report to gnuradio.org
Message-ID:
<CA+SzT6icTs+3m7KB41KREX6Lo3TLBHpZLwE37m4apf=
address@hidden>
Content-Type: text/plain; charset=ISO-8859-1
On Mon, Oct 15, 2012 at 10:41 AM, Pol Henarejos <
address@hidden> wrote:
> Dear list,
>
> I am trying to report several bugs to gnuradio.org webpage but I cannot
> see the option for reporting in the bug tracker. I am registered.
>
> Thanks.
>
> --
>
> Pol Henarejos
Pol,
Due to an excessive amount of spam on the site, I've had to lock it
down. You now have to be manually assigned to a project in order to
make edits.
I have now added you, so you can make your edits.
Thanks for contributing!
Tom
------------------------------
Message: 14
Date: Mon, 15 Oct 2012 08:24:31 -0700 (PDT)
From: nexy_sm <
address@hidden>
To:
address@hiddenSubject: Re: [Discuss-gnuradio] cannot make new signal processing
block
Message-ID: <
address@hidden>
Content-Type: text/plain; charset=us-ascii
Finaly it works.
Thanks!!!!!!!!!!!!!!!!!!!!!!!
--
View this message in context:
http://gnuradio.4.n7.nabble.com/cannot-make-new-signal-processing-block-tp37924p38005.htmlSent from the GnuRadio mailing list archive at
Nabble.com.
------------------------------
_______________________________________________
Discuss-gnuradio mailing list
address@hiddenhttps://lists.gnu.org/mailman/listinfo/discuss-gnuradioEnd of Discuss-gnuradio Digest, Vol 119, Issue 15
*************************************************