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 < > [email protected]> 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 <[email protected]> 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 <[email protected]> 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 >>>>>> [email protected] >>>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Discuss-gnuradio mailing list >>>>> [email protected] >>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>>>> >>>> >>> >> >> >> >> > _______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
