Re: [Discuss-gnuradio] Proposal for GSoC on gr-gsm
Hi Zhenhua, gr-gsm should be a good project for you and for the community. I wish you success. You may want to look at the slow frequency hopping implementation of airprobe that is placed here: https://github.com/BogdanDIA/airprobe-hopping. It uses PFB to split a 20mhz band received with USRP-N210 into GSM channels and then use all of them according to the hopping algorithm decoded on the Immediate Assignment message and SI 1. It is not a perfect implementation as airprobe is not perfect too, that is why I think this will be a good project. The hopping patch has been done two years ago and has API for gnuradio3.6 era. I did not update it yet on 3.7. Here is small paper I wrote at the moment of creating a patch. It may be of help to you. http://yo3iiu.ro/blog/wp-content/uploads/2012/04/Evaluating_GSM_hopping_V1.1.pdf Bogdan On Tuesday, March 11, 2014 5:40 AM, zhenhua han hzhua...@gmail.com wrote: Hi all, As Martin Braun noticed in the mail list yesterday, I haven't open my proposal here. Here is the link:https://github.com/hzhua/grgsm_proposal If you have any suggestions, please don't be hesitate to contact me. Thanks to Sylvain Munaut for his help on reviewing my first draft. Thanks to Piot Krysik for his suggestions on gr-gsm. Best wishes, Zhenhua ___ 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] Proposal for GSoC on gr-gsm
On 03/11/2014 04:40 AM, zhenhua han wrote: Hi all, As Martin Braun noticed in the mail list yesterday, I haven't open my proposal here. Here is the link: https://github.com/hzhua/grgsm_proposal If you have any suggestions, please don't be hesitate to contact me. Thanks to Sylvain Munaut for his help on reviewing my first draft. Thanks to Piot Krysik for his suggestions on gr-gsm. Hey, congrats on publishing the first proposal! It looks quite good. It's unclear if you have good algorithms to implement your deliverables. A few hints: - The FCH detection can be efficiently implemented using an adaptive filter. Here's a paper that explains the technique, although it's very poorly written: http://ieeexplore.ieee.org/xpl/login.jsp?tp=arnumber=1404796url=http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=1404796 There's also some code for this somewhere... can't find it right now. - A CEL student wrote a highly optimized MLSE, specifically for GSM, a while back (a *long* while back, it still uses autotools). Still, the code is very good, and there's a lot to be taken out of this. He tried out a lot of compiler switches, too, so check out lib/Makefile.am. https://github.com/pgoeser/gnuradio-mlse.git It assumes frame synchronization (i.e. post-SCCH sync), but you just drop in a frame, and it returns the equalized result. MB ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] looping with work() function
On 03/11/2014 06:10 AM, Sumedha Goyal wrote: Hello I am executing a flowgraph where I pass different parameters to the work() function of my block in every iteration. I'm not sure I'm understanding you correctly, but this is not how you use GNU Radio blocks. Have a look at gr-digital/examples/berawgn.py. Is this what you want to do? 1. I would like my flowgraph to execute once with a certain set of parameters and on satisfying a certain condition, it should stop execution (even if the queue/buffer of the block is not empty). 2. The control should come back to the main() function and the next iteration should start with a new set of parameters and again upon satisfying a certain condition the flowgraph should exit. You shut down a flow graph by returning WORK_DONE (or -1) from the work function. M *The work() function is of the block test_demo:* *new_test_tx.py#* class test_demo(gras.Block): def__init__(self,parameters): gras.Block.__init__(self,name=test, in_sig = [numpy.uint8,numpy.uint8,numpy.uint8], out_sig = [numpy.uint8,numpy.uint8]) def work(self, ins, outs): --some process here *The top_block is as following and has code for all the connections(not shown here):* class top_block(grc_wxgui.top_block_gui): def __init__(self,options,llr): grc_wxgui.top_block_gui.__init__(self, title=Top Block) _icon_path = /usr/share/icons/hicolor/32x32/apps/gnuradio-grc.png self.SetIcon(wx.Icon(_icon_path, wx.BITMAP_TYPE_ANY)) self.=new_test_tx.test_demo(options.parameters) def main(): parser = OptionParser(option_class=eng_option, conflict_handler=resolve) parser.add_option(, --args,default=, help=set the address of usrp_device [default='']) (options, args) = parser.parse_args () # build the graph tb=top_block(options,param) tb.Run(True) if __name__==__main__: main() I am able to execute the flowgraph once and then the main() function exits. I would like to perform this action for some 1000 iterations. It is a kind of for loop that I use during C/Python programming. How can I use it with GNURadio and Python. Thanks and Regards, Sumedha ___ 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] Should return the number of input or the number of output?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Well, it's basically the idea of not writing a special case for a single type of block; and if you are aware that sync blocks are only subclasses of normal blocks that implement a general_work which consumes *and* produces the return value of work, than everything is clear and readable :) Greetings, Marcus On 11.03.2014 01:34, Activecat wrote: Dear Martin, Apparently the consistency of code across different source files is more emphasized than its clarity in individual file. Nevertheless that is clear now, thanks. Regards, Activecat On Mon, Mar 10, 2014 at 9:18 PM, Martin Braun martin.br...@ettus.comwrote: OK, I admit I was unclear. Let's try from scratch: - The return function from work() or general_work() is the amount of items that were *produced*. - In a sync block, the number of items produced is the number of items consumed, so we can use that to save the developer from manually consuming(). In other words, in a sync block, the return value is *both* the number of produced and consumed items. - Sinks and sources are syncs, therefore the mechanic is always the same. - Sinks are a special case because they don't produce anything. However, the scheduler knows the block's io signature, and knows what to do. The consume/produce mechanic stays the same, for consistency's sake, as with all other sync blocks. Hope this clears things up! M On 03/10/2014 02:09 PM, Activecat wrote: If the return value of work() is used to tell the scheduler how much we have consumed, than it is very clear! In general_work() of new templates generated by gr_modtool, we always see this, even for sink blocks: // Tell runtime system how many output items we produced. return noutput_items; The comment sounds like the return value of general_work() is to tell the scheduler how many output items have produced. If this is true, for sink block, we should actually returned zero because sink block doesn't produce any output item. To avoid confusion, and to be more consistent, I suggest to put this instead into work() of new templates of sink block: // Tell runtime system how many input items have been consumed. return noutput_items; Because when I look into sync_block.cc, the return value of work() is actually used for consume_each(r). Just a silly suggestion. Thanks. Regards, Activecat ___ 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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTHtKDAAoJEBQ6EdjyzlHtKhsIAJaKRWiOkmZ8/icO07FjTDCP M7DFTEvaWXl/WFRSVfGYkccE513iXU/wTmud4gF8ywYHK+YWJbEOmPV3aEKNNTU5 8C1GNa6a0yPfGz7l4+WK0oKt8vIklViSKqt+sOJ3G/FGu/bllSoStbOvGnzw2ubI mJDfE4BzAuBIGSRr6Ar11UJ7xRNwLg9pcGsDYEAy12HUKpuJSqKP9rrb1wb1Kwco t/Ov+KvmgPiNnP8w6V2VZ5FIWtE77BsdALtDZy4dKsQaSCiOPb+AxZyOZUP1XDYD rV0POlRWuQ4kPqRH8MhzxUn6h7yKs31q+9GSkWOCO8YiCC9EvYDYvi3Jm/oZndY= =4uZc -END PGP SIGNATURE- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Pybombs make error
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Saran,
you're system is missing the doxygen executable. Install doxygen using
your package manager.
Greetings,
Marcus
On 11.03.2014 06:25, sarankumar wrote:
hi, I am trying to install GNU Radio through PyBombs in Ubuntu
12.04. I get the following error,
[ 21%] Built target pygen_gr_uhd_examples_python_d7761 [ 21%] Built
target _pmt_swig_doc_tag Scanning dependencies of target
pmt_swig_swig_doc [ 21%] Generating doxygen xml for pmt_swig_doc
docs /bin/sh: 1: DOXYGEN_EXECUTABLE-NOTFOUND: not found make[2]:
*** [gnuradio-runtime/swig/pmt_swig_doc_swig_docs/xml/index.xml]
Error 127 make[1]: ***
[gnuradio-runtime/swig/CMakeFiles/pmt_swig_swig_doc.dir/all] Error
2 make[1]: *** Waiting for unfinished jobs [ 22%] Building CXX
object
gnuradio-runtime/lib/pmt/CMakeFiles/gnuradio-pmt.dir/pmt_unv.cc.o [
22%] [ 22%] [ 22%] Building CXX object
gnuradio-runtime/lib/pmt/CMakeFiles/gnuradio-pmt.dir/pmt.cc.o
Building CXX object
gnuradio-runtime/lib/pmt/CMakeFiles/gnuradio-pmt.dir/pmt_io.cc.o [
22%] Building CXX object
gnuradio-runtime/lib/pmt/CMakeFiles/gnuradio-pmt.dir/pmt_pool.cc.o
Building CXX object
gnuradio-runtime/lib/pmt/CMakeFiles/gnuradio-pmt.dir/pmt_serialize.cc.o
Linking C shared library libvolk.so
[ 22%] Built target volk Linking CXX shared library
libgnuradio-pmt-3.7.4git.so [ 22%] Built target gnuradio-pmt make:
*** [all] Error 2 ERROR:root:PyBOMBS Make step failed for package
(gnuradio) please see bash output above for a reason (hint: look
for the word Error)
I also tried to reconfigure with builddocs=OFF. But I get the
following error on doing so.
Install Prefix Traceback (most recent call last): File ./pybombs,
line 198, in module pybombs_ops.config_init(config, True) File
/home/tslsb/pybombs/mod_pybombs/cfg.py, line 70, in config_init
if os.path.basename(pwd)==pybombs: File
/usr/lib/python2.7/posixpath.py, line 112, in basename i =
p.rfind('/') + 1 AttributeError: 'NoneType' object has no attribute
'rfind'
Can anyone help me?
Regards, Saran
___ Discuss-gnuradio
mailing list Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJTHtNFAAoJEBQ6EdjyzlHt3xgH/2VkAIr/mdnyGBSZW3iiaMsv
Y3/azZ9k3uzMup0DqpaqyK3lwLLIYW1q6YdpwddNCtTTYL+b6ht0aJqxgQv2Y5vz
BPhDiA26HY7WqNmneWQXob8cxL0pZsivxom7biB2Sh2axdlO86X4RP4LMC3O975r
VfpBDpchkJlcOIpc0ATinkghtqIMicJvo6YJmck/H+qWhtoYhiW5Fj/lRq8zxps2
B5Qy20j+dqHpmVLHY9CLwCIAaEq4zvdZHBmJM0Gnw54qSoroRaPHWau9fJJQF7Sb
SCBe9gtaQ4f/dBCsVr5ZEqhwHSHQtuX+sOdam59UvzUyRJTCOA0/LFLhN0h75l8=
=TO/M
-END PGP SIGNATURE-
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Should return the number of input or the number of output?
Yes I agree with you all. Everything are now clear and readable. Thank you very much. Regards, Activecat On Tue, Mar 11, 2014 at 5:08 PM, Marcus Müller mar...@hostalia.de wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Well, it's basically the idea of not writing a special case for a single type of block; and if you are aware that sync blocks are only subclasses of normal blocks that implement a general_work which consumes *and* produces the return value of work, than everything is clear and readable :) Greetings, Marcus On 11.03.2014 01:34, Activecat wrote: Dear Martin, Apparently the consistency of code across different source files is more emphasized than its clarity in individual file. Nevertheless that is clear now, thanks. Regards, Activecat On Mon, Mar 10, 2014 at 9:18 PM, Martin Braun martin.br...@ettus.comwrote: OK, I admit I was unclear. Let's try from scratch: - The return function from work() or general_work() is the amount of items that were *produced*. - In a sync block, the number of items produced is the number of items consumed, so we can use that to save the developer from manually consuming(). In other words, in a sync block, the return value is *both* the number of produced and consumed items. - Sinks and sources are syncs, therefore the mechanic is always the same. - Sinks are a special case because they don't produce anything. However, the scheduler knows the block's io signature, and knows what to do. The consume/produce mechanic stays the same, for consistency's sake, as with all other sync blocks. Hope this clears things up! M On 03/10/2014 02:09 PM, Activecat wrote: If the return value of work() is used to tell the scheduler how much we have consumed, than it is very clear! In general_work() of new templates generated by gr_modtool, we always see this, even for sink blocks: // Tell runtime system how many output items we produced. return noutput_items; The comment sounds like the return value of general_work() is to tell the scheduler how many output items have produced. If this is true, for sink block, we should actually returned zero because sink block doesn't produce any output item. To avoid confusion, and to be more consistent, I suggest to put this instead into work() of new templates of sink block: // Tell runtime system how many input items have been consumed. return noutput_items; Because when I look into sync_block.cc, the return value of work() is actually used for consume_each(r). Just a silly suggestion. Thanks. Regards, Activecat ___ 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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTHtKDAAoJEBQ6EdjyzlHtKhsIAJaKRWiOkmZ8/icO07FjTDCP M7DFTEvaWXl/WFRSVfGYkccE513iXU/wTmud4gF8ywYHK+YWJbEOmPV3aEKNNTU5 8C1GNa6a0yPfGz7l4+WK0oKt8vIklViSKqt+sOJ3G/FGu/bllSoStbOvGnzw2ubI mJDfE4BzAuBIGSRr6Ar11UJ7xRNwLg9pcGsDYEAy12HUKpuJSqKP9rrb1wb1Kwco t/Ov+KvmgPiNnP8w6V2VZ5FIWtE77BsdALtDZy4dKsQaSCiOPb+AxZyOZUP1XDYD rV0POlRWuQ4kPqRH8MhzxUn6h7yKs31q+9GSkWOCO8YiCC9EvYDYvi3Jm/oZndY= =4uZc -END PGP SIGNATURE- ___ 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] Proposal for GSoC on gr-gsm
Thank you, Martin. I will check these and extend my proposal with more details. Best wishes, Zhenhua 2014-03-11 17:00 GMT+08:00 Martin Braun martin.br...@ettus.com: On 03/11/2014 04:40 AM, zhenhua han wrote: Hi all, As Martin Braun noticed in the mail list yesterday, I haven't open my proposal here. Here is the link: https://github.com/hzhua/grgsm_proposal If you have any suggestions, please don't be hesitate to contact me. Thanks to Sylvain Munaut for his help on reviewing my first draft. Thanks to Piot Krysik for his suggestions on gr-gsm. Hey, congrats on publishing the first proposal! It looks quite good. It's unclear if you have good algorithms to implement your deliverables. A few hints: - The FCH detection can be efficiently implemented using an adaptive filter. Here's a paper that explains the technique, although it's very poorly written: http://ieeexplore.ieee.org/xpl/login.jsp?tp=arnumber=1404796url=http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=1404796 There's also some code for this somewhere... can't find it right now. - A CEL student wrote a highly optimized MLSE, specifically for GSM, a while back (a *long* while back, it still uses autotools). Still, the code is very good, and there's a lot to be taken out of this. He tried out a lot of compiler switches, too, so check out lib/Makefile.am. https://github.com/pgoeser/gnuradio-mlse.git It assumes frame synchronization (i.e. post-SCCH sync), but you just drop in a frame, and it returns the equalized result. MB ___ 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] GSoC 2014: Wireless Network in the loop
Hi Asma, this sounds very interesting, especially the implementation of new channel models would be a great enhancement to the WiNeLo project (and, if implemented as standard GR blocks, to GR in general). Concerning this matter - and as an additional option - one could possibly also improve and extend the already existing gr-channelsounder OOT (see https://github.com/gbaier/gr_channelsounder). Your second thought is also a great idea, but to me it sounds more like a demo application for the WiNeLo framework. I am really looking forward to see such applications running on top of WiNeLo, but I think that we should invest all the valuable development effort in the framework itself or the hardware and channel models right now. I am looking forward to read your opinion on these ideas! Nico Von: discuss-gnuradio-bounces+nico.otterbach=student.kit@gnu.org [discuss-gnuradio-bounces+nico.otterbach=student.kit@gnu.org] im Auftrag von Asma Afzal [asmaafz...@gmail.com] Gesendet: Montag, 10. März 2014 10:57 An: discuss-gnuradio@gnu.org Betreff: [Discuss-gnuradio] GSoC 2014: Wireless Network in the loop Dear All, My name is Asma Afzal. I am currently pursuing a PhD in Electrical Engineering (Wireless Communication ) from the University of Leeds, UK. I am interested in working on the WiNeLo GSoC project. WiNeLo is an in-the-loop simulation framework for communication networks based on the GNU Radio software radio toolkit. gr-winelo mimics the behavior of common RF frontends such as the USRP, but instead of sending the signal over the air, a central server plays the role of the wireless communication channel. Arbitrary channel models can be simulated, by passing their respective GNU Radio processing block to the server. Since this whole setup is completely transparent to GNU Radio applications, it is at any moment possible to switch between simulations and real-world tests. After watching the FOSDEM video, I believe I can make (part of) the following additions to the ongoing project 1. Implementation of various analytical channel models on the server to mimic real wireless channel. (Rayleigh, Nakagami-m, Rician, Weibull fading, Lognormal Shadowing) 2. Implementation of different transmission strategies such as CDM or interference free TDM with different digital modulation schemes. A user will be provisioned to input various controlling parameters like the frequency, rate of symbol transmission, wireless environment (indoor/outdoor), etc. With reference to these points, I wanted to ask senior members of the community regarding which tasks would be beneficial to the community immediately? I will appreciate your input to point out the exact goal. I believe that my skills are particularly well suited for this project. I did my Masters in Telecommunication and Networks from NUST, Pakistan. I studied Wireless communication and Wireless networks in detail. I am familiar with modulation schemes and wireless channel impairments like path loss, slow/fast fading, shadowing, noise and interference. My current research is based on stochastic modeling of wireless networks in presence of path loss and fading. I have recently presented a paper at Globecom 2013. The paper hasn’t come on IEEE Xplore yet but you can find an electronic copy on this link. http://ipt.seecs.nust.edu.pk/Pubs/Asma%20Globecom%202013.pdf Although I don’t have prior experience with GNU Radios, but I have strong programming skills in C/C++ and Matlab. During my masters, I worked on a collaborative project with Cypress Semi-Conductor, USA. The project involved implementation of AES-128 encryption and a part of thermal management system on Programmable System on Chip (PSoC). As a result of successful implementation, I got two technical articles published (listed below). http://www.embedded.com/design/safety-and-security/4417178/Enhancing-system-efficiency-of-embedded-encryption-applications http://www.embedded.com/design/prototyping-and-development/4422955/Building-an-efficient--intelligent--and-flexible-thermal-management-system I am a keen learner and I have always wanted to apply my theoretical knowledge on practical systems. This is my chance to do that. It will be extremely beneficial for my understanding of wireless systems and since this project is so relevant to my research, I would like to pursue it after summer as well and contribute to the GNU Radio open source community. Thank you. Kind Regards, Asma Afzal. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] looping with work() function
On Tue, Mar 11, 2014 at 5:04 PM, Martin Braun martin.br...@ettus.comwrote: On 03/11/2014 06:10 AM, Sumedha Goyal wrote: Hello I am executing a flowgraph where I pass different parameters to the work() function of my block in every iteration. If the parameters could be fed into work() as input elements, than that is possible. Please describe the parameters in details. 1. I would like my flowgraph to execute once with a certain set of parameters and on satisfying a certain condition, it should stop execution (even if the queue/buffer of the block is not empty). 2. The control should come back to the main() function and the next iteration should start with a new set of parameters and again upon satisfying a certain condition the flowgraph should exit. In flow-graph there is no main() function, but only the scheduler in the background. Please give specific examples of what you are trying to accomplish. Regards, Activecat ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Fwd: Proposal for GSoC on gr-gsm
-- Forwarded message -- From: zhenhua han hzhua...@gmail.com Date: 2014-03-11 16:00 GMT+08:00 Subject: Re: [Discuss-gnuradio] Proposal for GSoC on gr-gsm To: Bogdan Diaconescu b_diacone...@yahoo.com Thank you, Bogdan. Your work is a great help in developing the channel hopping part. As there are only 14 weeks in GSoC, the schedule is a little tight. However, I will continue working on this project after GSoC (if I am selected). And Channel hopping will be the first task after I finish all the tasks planned in GSoC. Best wishes, Zhenhua 2014-03-11 15:34 GMT+08:00 Bogdan Diaconescu b_diacone...@yahoo.com: Hi Zhenhua, gr-gsm should be a good project for you and for the community. I wish you success. You may want to look at the slow frequency hopping implementation of airprobe that is placed here: https://github.com/BogdanDIA/airprobe-hopping. It uses PFB to split a 20mhz band received with USRP-N210 into GSM channels and then use all of them according to the hopping algorithm decoded on the Immediate Assignment message and SI 1. It is not a perfect implementation as airprobe is not perfect too, that is why I think this will be a good project. The hopping patch has been done two years ago and has API for gnuradio3.6 era. I did not update it yet on 3.7. Here is small paper I wrote at the moment of creating a patch. It may be of help to you. http://yo3iiu.ro/blog/wp-content/uploads/2012/04/Evaluating_GSM_hopping_V1.1.pdf Bogdan On Tuesday, March 11, 2014 5:40 AM, zhenhua han hzhua...@gmail.com wrote: Hi all, As Martin Braun noticed in the mail list yesterday, I haven't open my proposal here. Here is the link: https://github.com/hzhua/grgsm_proposal If you have any suggestions, please don't be hesitate to contact me. Thanks to Sylvain Munaut for his help on reviewing my first draft. Thanks to Piot Krysik for his suggestions on gr-gsm. Best wishes, Zhenhua ___ 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] WSR14 and Hackfest
Quick reminder that we will have a meet-up in Vogelbräu tonight at 19:00. This is not limited to WSR participants! All GNU Radio enthusiasts are invited. I've booked a table and will be there slightly before 7. Our table should be easy to find, just scan for the homing beacon signal I'll be transmitting at 785 MHz, or should I forgot to do so because this is a pub after all, look out for GNU Radio logos. Martin On 02/16/2014 11:25 PM, Martin Braun wrote: Sebastian, thanks for organizing this! On Tuesday, March 11th, there will also be the (by now traditional) meeting of GR enthusiasts in Vogelbräu [1]. I'll book a table for 19:00. MB [1] Address: Kapellenstraße 50, http://www.vogelbraeu.de/ On 02/16/2014 03:58 PM, Sebastian Koslowski wrote: After the workshop we'll hold a 3-day hackfest here at the CEL- 2 1/2 days to be exact, that is March 13-15. Over the last years hackfests have become a regular event for GR developers to get together and work on new features, bug fixes, and discuss where to go next. As far as I know this will be the first hackfest in Europe and so we would like to invite everyone interested to stay a few days longer in Karlsruhe and do some GR coding. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Fwd: Proposal for GSoC on gr-gsm
On 03/11/2014 11:14 AM, zhenhua han wrote: -- Forwarded message -- From: *zhenhua han* hzhua...@gmail.com mailto:hzhua...@gmail.com Date: 2014-03-11 16:00 GMT+08:00 Subject: Re: [Discuss-gnuradio] Proposal for GSoC on gr-gsm To: Bogdan Diaconescu b_diacone...@yahoo.com mailto:b_diacone...@yahoo.com Thank you, Bogdan. Your work is a great help in developing the channel hopping part. As there are only 14 weeks in GSoC, the schedule is a little tight. However, I will continue working on this project after GSoC (if I am selected). And Channel hopping will be the first task after I finish all the tasks planned in GSoC. You should definitely check out the PFB channelization, though. For multi-ARFCN applications, this will always be a requirement. M ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] looping with work() function
My top_block class represents the whole flowgraph. The class test_demo is one of the blocks of this flowgraph for which its own work() function is defined. The test_demo checks for a start sign(given by the user) and participates in data transmission process and upon receiving an ACK for success should stop further transmission. At this point, the flowgraph should stop and start again with a new start sign for next iteration and so on. I am planning to plot the number of packets transmitted before receiving an ACK against this start sign. Therefore, I need my flowgraph to execute several times. I hope this description explains my intention. I am not very familiar with scheduler. How can I use the scheduler to do this? On Tue, Mar 11, 2014 at 3:12 PM, Activecat active...@gmail.com wrote: On Tue, Mar 11, 2014 at 5:04 PM, Martin Braun martin.br...@ettus.comwrote: On 03/11/2014 06:10 AM, Sumedha Goyal wrote: Hello I am executing a flowgraph where I pass different parameters to the work() function of my block in every iteration. If the parameters could be fed into work() as input elements, than that is possible. Please describe the parameters in details. 1. I would like my flowgraph to execute once with a certain set of parameters and on satisfying a certain condition, it should stop execution (even if the queue/buffer of the block is not empty). 2. The control should come back to the main() function and the next iteration should start with a new set of parameters and again upon satisfying a certain condition the flowgraph should exit. In flow-graph there is no main() function, but only the scheduler in the background. Please give specific examples of what you are trying to accomplish. Regards, Activecat ___ 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] looping with work() function
On 03/11/2014 01:31 PM, Sumedha Goyal wrote: My top_block class represents the whole flowgraph. The class test_demo No, it doesn't. It doesn't have any connect() calls or anything. This is not a flow graph. is one of the blocks of this flowgraph for which its own work() function is defined. The test_demo checks for a start sign(given by the user) and participates in data transmission process and upon receiving an ACK for success should stop further transmission. At this point, the flowgraph should stop and start again with a new start sign for next iteration and so on. I am planning to plot the number of packets transmitted before receiving an ACK against this start sign. Therefore, I need my flowgraph to execute several times. I hope this description explains my intention. I am not very familiar with scheduler. How can I use the scheduler to do this? If you're using a flow graph, you use the scheduler automatically, you don't need to set it up or anything. Have a look at the file I recommended. If you feel you don't understand something, first read the introductory documents on the wiki, as well as http://gnuradio.org/redmine/projects/gnuradio/wiki/Simulations. Good luck, Martin On Tue, Mar 11, 2014 at 3:12 PM, Activecat active...@gmail.com mailto:active...@gmail.com wrote: On Tue, Mar 11, 2014 at 5:04 PM, Martin Braun martin.br...@ettus.com mailto:martin.br...@ettus.com wrote: On 03/11/2014 06:10 AM, Sumedha Goyal wrote: Hello I am executing a flowgraph where I pass different parameters to the work() function of my block in every iteration. If the parameters could be fed into work() as input elements, than that is possible. Please describe the parameters in details. 1. I would like my flowgraph to execute once with a certain set of parameters and on satisfying a certain condition, it should stop execution (even if the queue/buffer of the block is not empty). 2. The control should come back to the main() function and the next iteration should start with a new set of parameters and again upon satisfying a certain condition the flowgraph should exit. In flow-graph there is no main() function, but only the scheduler in the background. Please give specific examples of what you are trying to accomplish. Regards, Activecat ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org mailto: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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Transmit from RF1, receive from RF2
I am using SBX board. I read somewhere that this board can transmit and receive from port 1 and only receive from port 2. Is this correct? Is there any way, using this board, to transmit and receive simultaneously even from only one port? If yes, how may I do this in GRC? From: Matt Ettus [mailto:m...@ettus.com] Sent: Tuesday, March 11, 2014 4:31 AM To: Dimitris Siafarikas Cc: GNURadio Subject: Re: [Discuss-gnuradio] Transmit from RF1, receive from RF2 Which daughterboard are you using? The only ones where you can receive 2 signals at once are BasicRX, LFRX, and TVRX2. The others only allow you to receive from one antenna port at a time. Matt On Mon, Mar 10, 2014 at 3:54 PM, Dimitris Siafarikas jimsia...@hotmail.com mailto:jimsia...@hotmail.com wrote: Hi list, here is the thing. I would like to know, how I can create a flow with blocks in GNU Radio companion, in order to receive a signal from the RF1 port of my URSP N210 and simultaneously , receive another signal from the RF2 port of the same USRP. Is there any option defining the port of the USRP when selecting USRP source/sink block? Thank you in advance. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org mailto: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
[Discuss-gnuradio] how to limit the size of buffer/queue for a block?
Hello The flowgraph of my top_block has test_demo as one of the blocks. The work() function associated with it has only one print statement. When I execute the flowgraph, the statement keeps on printing the statement I AM IN WORK on the screen. Why does it happen? My flowgraph is : File source---stream to datagram---test_demodatagram to stream-file sink test_demo.py is : import timing import numpy import gras import Queue import thread from gnuradio import gr from gnuradio import digital from gnuradio import uhd import grextras class test_demo(gras.Block): def __init__(self, threshold): gras.Block.__init__(self,name=test_demo, in_sig = [numpy.uint8,numpy.uint8,numpy.uint8], out_sig = [numpy.uint8,numpy.uint8]) self.input_config(0).reserve_items = 0 self.input_config(1).reserve_items = 0 self.output_config(1).reserve_items = 4096 self.output_config(0).reserve_items = 4096 self.threshold=threshold print inside test_demo def work(self,ins,outs): print I AM IN WORK If it is due to the size of buffer/queue of the block then how can I limit it? I understand that work() keeps on executing till the block receives something at its input ports. I want work() to return the control to main flowgraph upon satisfying a user specified condition such as if (i=5): self.mark_done() It should ignore all the pending packets of the buffer/queue. I want to start my flowgraph fresh after this process. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] get_tags_in_range
On Mon, Mar 10, 2014 at 4:16 PM, Nowlan, Sean
sean.now...@gtri.gatech.edu wrote:
On Mon, Mar 10, 2014 at 5:55 AM, Martin Braun martin.br...@ettus.com wrote:
On 03/10/2014 01:08 AM, Nowlan, Sean wrote:
I'm using get_tags_in_range with bounds outside the absolute sample
offsets presented in each work function. I'm using this to add
end-of-burst tags at offset K-1 for every start-of-burst tag that I
find at offset K (except the very first K).
I just want to confirm that this is valid. All my tests have shown
that it is, since I believe the underlying deque is completely
independent of the data stream except that offsets are used for both
absolute sample offsets and tag bookkeeping.
I think you're right, but only if you do this *after* the current
bounds, not before.
M
Yes, the scheduler prunes all tags before the window after work is done.
Basically, since we're tagging a data sample, if that sample is no longer
available to you, neither is it's tag. You'll have to get them and store
them locally for your uses later.
Tom
Ok, that makes sense; I'd be unable to read tags from the past. But what
happens if I *create* a tag on a past data sample? Will it be propagated or
ignored?
( A ) { B }
(0 1) { 2 3 4 } 5 ...
Let's say section ( A ) is from a previous call to work. Let's also say { B }
is the current work window, i.e., nitems_read(0) == 2 and noutput_items == 3.
If I find a start-of-burst tag on absolute offset 2, is it impossible to
create a new tag on absolute offset 1?
The vast majority of the time, this would not be a problem. The boundary
condition is really the only source of trouble. I suppose I could use
set_history(2) so that I can always see the tags at the offset range
endpoints. Do you advise this? Does history ensure the scheduler doesn't
prune tags from the history region?
Sean
Yeah, if you set a tag to a time in the past, the following blocks
will (likely, based on the dynamics of the scheduler) prune it before
your follow-on block can process it.
I'd have to double check and think about the case where you use
set_history for this. It seems like it should work, but just remember
that set history really just initializes your read pointers back by
history()-1 number of items. So the tag wouldn't go on item-2 in the
stream since index 0 of the buffer /is/ item-2 already.
But something like this, if not exactly, should work, yes.
Tom
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Running GNU Radio on Linux in VMware Workstation
On Mon, Mar 10, 2014 at 5:08 PM, Mike Harpe m...@mikeharpe.com wrote: I have been working for a week or so on getting GNU Radio going on a Debian Linux platform running inside a VM. GNU Radio is compiled and runs fine. The VM sees my Funcube Pro+ dongle. Using 'plughw:0,0' got rid of the audio stuttering problem. After struggling with a couple of the demo flowgraphs I downloaded and built gqrx. It runs. I can tune it to the local NOAA Weather Radio transmitter. I use that for testing because its very strong where I am. I have the same problem there that I have in GNU Radio: no receive audio. Can anyone give me some advice how to proceed? To answer the one question, yes, I am pursuing building a Debian system on a flash drive that I can boot natively. Mike Harpe, N4PLE Sellersburg, IN, USA You can specify the audio output device globally for your system by editing $prefix/etc/gnuradio/conf.d/gr-audio-alsa.conf (I'm assuming that's what you are working with given the use of plughw). You can set that 'plughw:0,0' in as the 'default_output_device' argument. If you are running PulseAudio, you can use 'pulse' for this, too, which tends to work more reliably for me these days. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Transmit from RF1, receive from RF2
This board has one receiver, one transmitter. You can transmit and receive simultaneously with it, but only on different ports. No TX and RX at the same time on one port, no RX and RX at the same time at all. Ralph. From: discuss-gnuradio-bounces+ralph=schmid@gnu.org [mailto:discuss-gnuradio-bounces+ralph=schmid@gnu.org] On Behalf Of Dimitris Siafarikas Sent: Tuesday, March 11, 2014 1:59 PM To: 'Matt Ettus' Cc: 'GNURadio' Subject: Re: [Discuss-gnuradio] Transmit from RF1, receive from RF2 I am using SBX board. I read somewhere that this board can transmit and receive from port 1 and only receive from port 2. Is this correct? Is there any way, using this board, to transmit and receive simultaneously even from only one port? If yes, how may I do this in GRC? From: Matt Ettus [mailto:m...@ettus.com] Sent: Tuesday, March 11, 2014 4:31 AM To: Dimitris Siafarikas Cc: GNURadio Subject: Re: [Discuss-gnuradio] Transmit from RF1, receive from RF2 Which daughterboard are you using? The only ones where you can receive 2 signals at once are BasicRX, LFRX, and TVRX2. The others only allow you to receive from one antenna port at a time. Matt On Mon, Mar 10, 2014 at 3:54 PM, Dimitris Siafarikas jimsia...@hotmail.com mailto:jimsia...@hotmail.com wrote: Hi list, here is the thing. I would like to know, how I can create a flow with blocks in GNU Radio companion, in order to receive a signal from the RF1 port of my URSP N210 and simultaneously , receive another signal from the RF2 port of the same USRP. Is there any option defining the port of the USRP when selecting USRP source/sink block? Thank you in advance. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org mailto: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] Fwd: Proposal for GSoC on gr-gsm
I totally agree with Martin regarding PFB channelizer. The PFB for gsm will be also a good challenge for gnuradio in general as obtaining only a moderate number of channels(say 50) takes a lot of processing power and achieving realtime processing is not possible currently. Split per thereads and VOLK should be taken in consideration. Bogdan On Tuesday, March 11, 2014 2:30 PM, Martin Braun martin.br...@ettus.com wrote: On 03/11/2014 11:14 AM, zhenhua han wrote: -- Forwarded message -- From: *zhenhua han* hzhua...@gmail.com mailto:hzhua...@gmail.com Date: 2014-03-11 16:00 GMT+08:00 Subject: Re: [Discuss-gnuradio] Proposal for GSoC on gr-gsm To: Bogdan Diaconescu b_diacone...@yahoo.com mailto:b_diacone...@yahoo.com Thank you, Bogdan. Your work is a great help in developing the channel hopping part. As there are only 14 weeks in GSoC, the schedule is a little tight. However, I will continue working on this project after GSoC (if I am selected). And Channel hopping will be the first task after I finish all the tasks planned in GSoC. You should definitely check out the PFB channelization, though. For multi-ARFCN applications, this will always be a requirement. M ___ 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] looping with work() function
Dear Sumedha Goyal, The test_demo checks for a start sign(given by the user) and participates in data transmission process and upon receiving an ACK for success should stop further transmission. Q1: What do you mean by participates in data transmission process? Does it just send out what it receives, or insert any new data? Q2: For upon receiving an ACK:- from where the ACK will comes from, from upstream, downstream, or somewhere else? At this point, the flowgraph should stop and start again with a new start sign for next iteration and so on. I am planning to plot the number of packets transmitted before receiving an ACK against this start sign. If I understand you requirement correctly, you need a block that continuously getting input from somewhere. This input contains start sign and later followed by ACK. Upon receiving start sign, this block will pass through all it receives to its output port. Upon receiving ACK, this block will stop the pass through (means no output), until it receive another start sign again. Meanwhile, you want the block to count the number of inputs between the start sign and ACK, and use this number to plot graph. Is this what you want? If yes then I am able to help you. Let's clarify your requirements first. Regards, Activecat ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] GSoC'14: Read Me Links
To all GSoC'14 potential participants: The application period for GSoC'14 is open (as of Monday, March 10). The deadline for getting your application in is Friday, March 21 @ 19:00 UTC (3 PM/US/ET). I've added some read me links to the GR Wiki GSoC Manifest page http://gnuradio.org/redmine/projects/gnuradio/wiki/GSoCManifest#Related-reading . I encourage all GSoC potential participants to read them (they are not very long), no matter which type of participant you are; there is good wisdom for all of us in these pages! - MLD ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] looping with work() function
Please stay on the mailing list. On 03/11/2014 02:37 PM, Sumedha Goyal wrote: I haven't shown the whole code here but the top_class has all the connect() functions required to connect the various blocks. I've gone through the link that you have sent me. In this example, the work() function is not used anywhere. I would like to do a similar thing but cannot avoid work(). Is there a way around? work() is called in every single block. This is how blocks work. Have a look at the out of tree module tutorial. Martin On Tue, Mar 11, 2014 at 6:19 PM, Martin Braun martin.br...@ettus.com mailto:martin.br...@ettus.com wrote: On 03/11/2014 01:31 PM, Sumedha Goyal wrote: My top_block class represents the whole flowgraph. The class test_demo No, it doesn't. It doesn't have any connect() calls or anything. This is not a flow graph. is one of the blocks of this flowgraph for which its own work() function is defined. The test_demo checks for a start sign(given by the user) and participates in data transmission process and upon receiving an ACK for success should stop further transmission. At this point, the flowgraph should stop and start again with a new start sign for next iteration and so on. I am planning to plot the number of packets transmitted before receiving an ACK against this start sign. Therefore, I need my flowgraph to execute several times. I hope this description explains my intention. I am not very familiar with scheduler. How can I use the scheduler to do this? If you're using a flow graph, you use the scheduler automatically, you don't need to set it up or anything. Have a look at the file I recommended. If you feel you don't understand something, first read the introductory documents on the wiki, as well as http://gnuradio.org/redmine/projects/gnuradio/wiki/Simulations. Good luck, Martin On Tue, Mar 11, 2014 at 3:12 PM, Activecat active...@gmail.com mailto:active...@gmail.com mailto:active...@gmail.com mailto:active...@gmail.com wrote: On Tue, Mar 11, 2014 at 5:04 PM, Martin Braun martin.br...@ettus.com mailto:martin.br...@ettus.com mailto:martin.br...@ettus.com mailto:martin.br...@ettus.com wrote: On 03/11/2014 06:10 AM, Sumedha Goyal wrote: Hello I am executing a flowgraph where I pass different parameters to the work() function of my block in every iteration. If the parameters could be fed into work() as input elements, than that is possible. Please describe the parameters in details. 1. I would like my flowgraph to execute once with a certain set of parameters and on satisfying a certain condition, it should stop execution (even if the queue/buffer of the block is not empty). 2. The control should come back to the main() function and the next iteration should start with a new set of parameters and again upon satisfying a certain condition the flowgraph should exit. In flow-graph there is no main() function, but only the scheduler in the background. Please give specific examples of what you are trying to accomplish. Regards, Activecat ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org mailto:Discuss-gnuradio@gnu.org mailto:Discuss-gnuradio@gnu.org mailto:Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org mailto:Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org mailto: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] how to limit the size of buffer/queue for a block?
On 03/11/2014 02:20 PM, Sumedha Goyal wrote: Hello The flowgraph of my top_block has test_demo as one of the blocks. The work() function associated with it has only one print statement. When I execute the flowgraph, the statement keeps on printing the statement I AM IN WORK on the screen. Why does it happen? My flowgraph is : File source---stream to datagram---test_demodatagram to stream-file sink test_demo.py is : Sumedha, when posting Python code, make sure the indents get preserved (ideally, don't send HTML emails). M import timing import numpy import gras import Queue import thread from gnuradio import gr from gnuradio import digital from gnuradio import uhd import grextras class test_demo(gras.Block): def __init__(self, threshold): gras.Block.__init__(self,name=test_demo, in_sig = [numpy.uint8,numpy.uint8,numpy.uint8], out_sig = [numpy.uint8,numpy.uint8]) self.input_config(0).reserve_items = 0 self.input_config(1).reserve_items = 0 self.output_config(1).reserve_items = 4096 self.output_config(0).reserve_items = 4096 self.threshold=threshold print inside test_demo def work(self,ins,outs): print I AM IN WORK If it is due to the size of buffer/queue of the block then how can I limit it? I understand that work() keeps on executing till the block receives something at its input ports. I want work() to return the control to main flowgraph upon satisfying a user specified condition such as if (i=5): self.mark_done() It should ignore all the pending packets of the buffer/queue. I want to start my flowgraph fresh after this process. ___ 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
[Discuss-gnuradio] output operand requires a reduction, but reduction is not enabled
Thanks Martin, this is clear and makes sense. I should have read the numpy data types more thoroughly and worked it out. Anyway... My collaborators are writing their Wireless Network Coding bits in Python. Once I get this block working, I can combined it with the relay work I was doing and we will have a pretty exciting setup to report!! :) I have one more problem though... I have out_bA1 = output_items[0] ... ...code ... out_bA1[0:len(est_bA1m)] = est_bA1m where out_bA1.shape = (1,) est_bA1m.shape = (3840,) I get the error output operand requires a reduction, but reduction is not enabled *Sometimes* I get out_bA1.shape = (2,) est_bA1m.shape = (3840,) and I get the error operands could not be broadcast together with shapes (2) (3840) I wondered if the problem is with 'forecast' (which I have not changed since the template was created by gr_modtool) or having to set_output_multiple? The scheduling aspect of GNU radio seems complex. If I use out_bA1 = est_bA1m Then it *runs* OK, but the output of the block i.e. output_items[0] is then no longer altered and 0's are output. Many thanks, David -Original Message- From: discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org [mailto:discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org] On Behalf Of Martin Braun Sent: 11 March 2014 08:33 To: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Python block, itemsize mismatch On 03/11/2014 02:06 AM, David Halls wrote: You're a genius! It works. Interestingly for a float it requires numpy.float32 or a similar error occurs. Yes, in GNU Radio we consistently use 32-bit floats. A complex value consists of two of these, hence the 64 bits. Note that this is just for buffers. A lot of blocks use double internally (i.e. 64-bit float, or 128-bit complex) for accuracy reason. However, for signals, it's just a waste of bandwidth (most of time, SNR will trump quantization noise anyway). M ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio NOTE: The information in this email and any attachments may be confidential and/or legally privileged. This message may be read, copied and used only by the intended recipient. If you are not the intended recipient, please destroy this message, delete any copies held on your system and notify the sender immediately. Toshiba Research Europe Limited, registered in England and Wales (2519556). Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, England. Web: www.toshiba.eu/research/trl --- This email has been scanned for email related threats and delivered safely by Mimecast. For more information please visit http://www.mimecast.com --- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] output operand requires a reduction, but reduction is not enabled
On 03/11/2014 03:30 PM, David Halls wrote: Thanks Martin, this is clear and makes sense. I should have read the numpy data types more thoroughly and worked it out. Anyway... My collaborators are writing their Wireless Network Coding bits in Python. Once I get this block working, I can combined it with the relay work I was doing and we will have a pretty exciting setup to report!! :) That is very interesting to hear -- I hope you'll be publishing some papers and code around network coding! I have one more problem though... I have out_bA1 = output_items[0] ... ...code ... out_bA1[0:len(est_bA1m)] = est_bA1m where out_bA1.shape = (1,) est_bA1m.shape = (3840,) I get the error output operand requires a reduction, but reduction is not enabled *Sometimes* I get out_bA1.shape = (2,) est_bA1m.shape = (3840,) and I get the error operands could not be broadcast together with shapes (2) (3840) I wondered if the problem is with 'forecast' (which I have not changed since the template was created by gr_modtool) or having to set_output_multiple? The scheduling aspect of GNU radio seems complex. This is a Python error, basically it's saying that the arrays have the wrong shapes. Note that in your example, out_bA1 has a limited size before you do any assigning. Make sure you stay within valid index ranges. If you want to do it very fool-proof (albeit ugly), try: for i in range(len(out_bA1)): out_bA1[i] = # whatever if i (matches whatever condition): break If I use out_bA1 = est_bA1m Then it *runs* OK, but the output of the block i.e. output_items[0] is then no longer altered and 0's are output. That's because you're rebinding out_bA1, and the original buffer is not written to. MB Many thanks, David -Original Message- From: discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org mailto:discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org [mailto:discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org] On Behalf Of Martin Braun Sent: 11 March 2014 08:33 To: discuss-gnuradio@gnu.org mailto:discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Python block, itemsize mismatch On 03/11/2014 02:06 AM, David Halls wrote: You're a genius! It works. Interestingly for a float it requires numpy.float32 or a similar error occurs. Yes, in GNU Radio we consistently use 32-bit floats. A complex value consists of two of these, hence the 64 bits. Note that this is just for buffers. A lot of blocks use double internally (i.e. 64-bit float, or 128-bit complex) for accuracy reason. However, for signals, it's just a waste of bandwidth (most of time, SNR will trump quantization noise anyway). M ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org mailto:Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio NOTE: The information in this email and any attachments may be confidential and/or legally privileged. This message may be read, copied and used only by the intended recipient. If you are not the intended recipient, please destroy this message, delete any copies held on your system and notify the sender immediately. Toshiba Research Europe Limited, registered in England and Wales (2519556). Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, England. Web: www.toshiba.eu/research/trl http://www.toshiba.eu/research/trl This email has been scanned for email related threats and delivered safely by Mimecast. For more information please visit http://www.mimecast.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GSoC'14: Read Me Links
On 03/11/2014 03:03 PM, Michael Dickens wrote: To all GSoC'14 potential participants: The application period for GSoC'14 is open (as of Monday, March 10). The deadline for getting your application in is Friday, March 21 @ 19:00 UTC (3 PM/US/ET). I've added some read me links to the GR Wiki GSoC Manifest page http://gnuradio.org/redmine/projects/gnuradio/wiki/GSoCManifest#Related-reading . I encourage all GSoC potential participants to read them (they are not very long), no matter which type of participant you are; there is good wisdom for all of us in these pages! - MLD Michael, thanks for putting this up. To all students: You will get subjective negative points if you don't read everything before posting/asking questions, so please take this seriously. M ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] output operand requires a reduction, but reduction is not enabled
On 03/11/2014 04:24 PM, David Halls wrote: Please see the papers we've submitted so far this year. Not exactly WNC, yet... We're putting one together as we speak though. I am not sure I understand your reply fully... Len(out_bA1) is only 1 or 2, so I can only set one or two elements? Is this before or after you assign something? What's len(output_items[0])? How can I extend the length of out_bA1, so I can output all of est_bA1m? You can't, not in the work function. You can do things like set_output_multiple() to influence the size of the output buffer. Or alternatively Is it possible for me to set output_items[0][0:len(est_bA1m)] = est_bA1m That would work, if len(est_bA1m) len(output_items[0]) AND they have the right shape (in matrix terms). ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] get_tags_in_range
On Mon, Mar 10, 2014 at 4:16 PM, Nowlan, Sean sean.now...@gtri.gatech.edu
wrote:
On Mon, Mar 10, 2014 at 5:55 AM, Martin Braun martin.br...@ettus.com wrote:
On 03/10/2014 01:08 AM, Nowlan, Sean wrote:
I'm using get_tags_in_range with bounds outside the absolute sample
offsets presented in each work function. I'm using this to add
end-of-burst tags at offset K-1 for every start-of-burst tag that I
find at offset K (except the very first K).
I just want to confirm that this is valid. All my tests have shown
that it is, since I believe the underlying deque is completely
independent of the data stream except that offsets are used for
both absolute sample offsets and tag bookkeeping.
I think you're right, but only if you do this *after* the current
bounds, not before.
M
Yes, the scheduler prunes all tags before the window after work is done.
Basically, since we're tagging a data sample, if that sample is no longer
available to you, neither is it's tag. You'll have to get them and store
them locally for your uses later.
Tom
Ok, that makes sense; I'd be unable to read tags from the past. But what
happens if I *create* a tag on a past data sample? Will it be propagated or
ignored?
( A ) { B }
(0 1) { 2 3 4 } 5 ...
Let's say section ( A ) is from a previous call to work. Let's also say { B
} is the current work window, i.e., nitems_read(0) == 2 and noutput_items ==
3. If I find a start-of-burst tag on absolute offset 2, is it impossible to
create a new tag on absolute offset 1?
The vast majority of the time, this would not be a problem. The boundary
condition is really the only source of trouble. I suppose I could use
set_history(2) so that I can always see the tags at the offset range
endpoints. Do you advise this? Does history ensure the scheduler doesn't
prune tags from the history region?
Sean
Yeah, if you set a tag to a time in the past, the following blocks will
(likely, based on the dynamics of the scheduler) prune it before your
follow-on block can process it.
I'd have to double check and think about the case where you use set_history
for this. It seems like it should work, but just remember that set history
really just initializes your read pointers back by
history()-1 number of items. So the tag wouldn't go on item-2 in the stream
since index 0 of the buffer /is/ item-2 already.
Ok, I guess I should go poke around the prune_tags logic and see how it works.
If it respects history(), it wouldn't prune tags from any item that is
available at the start of the read pointer, including history. If it doesn't,
tags may be abandoned/pruned even though I have access to history()-1 number of
previous items, and I'm still stuck.
Functionally speaking, if I can read a sample, I should be able to read its
associated tags. But history() only involves input buffers, not output buffers,
so perhaps I'm still falling into the trap mentioned above, i.e., the tag may
be pruned before the downstream block can see it.
But something like this, if not exactly, should work, yes.
I'm trying to determine an exact solution. This is another way to work around
PFB arb resampler tag propagation issues (discussed in issue #652). Basically
I'm adding a start-of-burst tag to the first sample of a stream pre-resampler,
and then once things have been resampled, I go back and fill in end-of-burst
tags. This avoids having to know when the PFB arb resampler adds +/- 1 samples.
This block I've written is a sync_block that simply does a memcpy of samples
and the tag processing mentioned above.
Now I'm thinking a workaround could be to return noutput_items-1 items. This
way I get to check the last item of a work input buffer,
nitems_read(0)+noutput_items-1, for a start-of-burst tag and place an
end-of-burst tag at nitems_read(0)+noutput_items-2. At the next call to work,
that last item of the previous input buffer is the first item of the input
buffer, and I can put an end-of-burst tag at nitems_read(0) if I find a tag at
nitems_read(0)+1. Makes sense in my head, at least...
Tom
Sean
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] output operand requires a reduction, but reduction is not enabled
Hi, Yes, the len(output_items[0]), is either 1 or 2... If I set_output_multiple to 10, then this value raises to 10. It is dominated by the fact that one of the inputs to my block is much lower than the other?? Input[0] is the data stream and has say 768 items, input[1] is the packet average SNR, so it only has 1 or 2 items in the same period. Forecast is currently For I in range (len(ninput_items_required)): Ninput_items_required[i] = noutput_items Does this need to be altered for my case where I have two inputs with very different requirements. If I ever get my head around the scheduler in GNU radio, it will be a happy day :) D -Original Message- From: discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org [mailto:discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org] On Behalf Of Martin Braun Sent: 11 March 2014 15:27 To: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] output operand requires a reduction, but reduction is not enabled On 03/11/2014 04:24 PM, David Halls wrote: Please see the papers we've submitted so far this year. Not exactly WNC, yet... We're putting one together as we speak though. I am not sure I understand your reply fully... Len(out_bA1) is only 1 or 2, so I can only set one or two elements? Is this before or after you assign something? What's len(output_items[0])? How can I extend the length of out_bA1, so I can output all of est_bA1m? You can't, not in the work function. You can do things like set_output_multiple() to influence the size of the output buffer. Or alternatively Is it possible for me to set output_items[0][0:len(est_bA1m)] = est_bA1m That would work, if len(est_bA1m) len(output_items[0]) AND they have the right shape (in matrix terms). ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio NOTE: The information in this email and any attachments may be confidential and/or legally privileged. This message may be read, copied and used only by the intended recipient. If you are not the intended recipient, please destroy this message, delete any copies held on your system and notify the sender immediately. Toshiba Research Europe Limited, registered in England and Wales (2519556). Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, England. Web: www.toshiba.eu/research/trl --- This email has been scanned for email related threats and delivered safely by Mimecast. For more information please visit http://www.mimecast.com --- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Transmit from RF1, receive from RF2
Ok, let's say I want to Tx from port1 and receive from port2. How am I supposed to do that on GRC? Or is set when I add a USRP source and a USRP sink automatically? From: Ralph A. Schmid, dk5ras [mailto:ra...@schmid.xxx] Sent: Tuesday, March 11, 2014 3:34 PM To: 'Dimitris Siafarikas'; 'Matt Ettus' Cc: 'GNURadio' Subject: RE: [Discuss-gnuradio] Transmit from RF1, receive from RF2 This board has one receiver, one transmitter. You can transmit and receive simultaneously with it, but only on different ports. No TX and RX at the same time on one port, no RX and RX at the same time at all. Ralph. From: discuss-gnuradio-bounces+ralph=schmid@gnu.org mailto:discuss-gnuradio-bounces+ralph=schmid@gnu.org [mailto:discuss-gnuradio-bounces+ralph=schmid@gnu.org] On Behalf Of Dimitris Siafarikas Sent: Tuesday, March 11, 2014 1:59 PM To: 'Matt Ettus' Cc: 'GNURadio' Subject: Re: [Discuss-gnuradio] Transmit from RF1, receive from RF2 I am using SBX board. I read somewhere that this board can transmit and receive from port 1 and only receive from port 2. Is this correct? Is there any way, using this board, to transmit and receive simultaneously even from only one port? If yes, how may I do this in GRC? From: Matt Ettus [mailto:m...@ettus.com] Sent: Tuesday, March 11, 2014 4:31 AM To: Dimitris Siafarikas Cc: GNURadio Subject: Re: [Discuss-gnuradio] Transmit from RF1, receive from RF2 Which daughterboard are you using? The only ones where you can receive 2 signals at once are BasicRX, LFRX, and TVRX2. The others only allow you to receive from one antenna port at a time. Matt On Mon, Mar 10, 2014 at 3:54 PM, Dimitris Siafarikas jimsia...@hotmail.com mailto:jimsia...@hotmail.com wrote: Hi list, here is the thing. I would like to know, how I can create a flow with blocks in GNU Radio companion, in order to receive a signal from the RF1 port of my URSP N210 and simultaneously , receive another signal from the RF2 port of the same USRP. Is there any option defining the port of the USRP when selecting USRP source/sink block? Thank you in advance. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org mailto: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] looping with work() function
1. There is a file source that frames data packets for the test_demo. This is part of a transmitter USRP. 2. I have another USRP as receiver that sends an ACK upon reception of data packets to the transmitter. 3. Start sign is a threshold value. If the packet information (calculated by some method) exceeds this threshold, transmission starts and upon receiving an ACK stops. 4. I change this threshold value for every new iteration and count how many packets were transmitted before receiving a success ACK. I can do this manually for every iteration but how to automate it for say some 1000 iterations? I hope it explains everything. On Mar 11, 2014 7:28 PM, Activecat active...@gmail.com wrote: Dear Sumedha Goyal, The test_demo checks for a start sign(given by the user) and participates in data transmission process and upon receiving an ACK for success should stop further transmission. Q1: What do you mean by participates in data transmission process? Does it just send out what it receives, or insert any new data? Q2: For upon receiving an ACK:- from where the ACK will comes from, from upstream, downstream, or somewhere else? At this point, the flowgraph should stop and start again with a new start sign for next iteration and so on. I am planning to plot the number of packets transmitted before receiving an ACK against this start sign. If I understand you requirement correctly, you need a block that continuously getting input from somewhere. This input contains start sign and later followed by ACK. Upon receiving start sign, this block will pass through all it receives to its output port. Upon receiving ACK, this block will stop the pass through (means no output), until it receive another start sign again. Meanwhile, you want the block to count the number of inputs between the start sign and ACK, and use this number to plot graph. Is this what you want? If yes then I am able to help you. Let's clarify your requirements first. Regards, Activecat ___ 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
[Discuss-gnuradio] flow graph fails when the complexity increased (without USRP device)
Hi all, I am using GNURADIO 3.7, Ubuntu 13.04 I want to generate dictionary elements using flow graph. dvbt_dictionary block connects to FFT block it connects to dvbt_dictionary2 and again after FFT block it connects to dvbt_dictionary3. dvbt_dictionary2.cc saves files as a dictionary elements. The problem is that when I increase the complexity (generate more elements) it does not work (For example when I want to generate more than 100 elements). I attach three .cc files and flow graph. Can someone help me? -- NE dvbt_dic.py Description: Binary data dvbt_dic.grc Description: Binary data dvbt_dictionary.cc Description: Binary data dvbt_dictionary3.cc Description: Binary data dvbt_dictionary2.cc Description: Binary data ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] [Fwd: Re: HPRT receiving station]
---BeginMessage--- Hi Pablo, NOAA HRPT is Manchester BPSK. I used Johnathan's noaa_hrpt_decoder.cc/h and enhanced the deframer. Perhaps Johnathan can help you more? http://gnuradio.org/redmine/projects/gnuradio/repository/revisions/350726ae56d46d2c7c1adf71b7049369a428d455/show/gr-noaa/lib Patrik On Tue, 2014-03-11 at 17:48 +0100, Pablo Fernández Alonso wrote: Hello Patrik, Where can I find a detailed explanation for the structure of the HRPT receiver in GNU radio? I saw several examples, but I don't understand how the signa lis demodulated. Regards, Pablo. -Mensaje original- De: Patrik Tast [mailto:pat...@poes-weather.com] Enviado el: miércoles, 5 de marzo de 2014 13:47 Para: Pablo Fernández Alonso Asunto: Re: HPRT receiving station Hi Pablo, Before you order I suspect you could use an offset dish (70 x 50cm) I guess you can buy on for €1, as a start? Patrik On Wed, 2014-03-05 at 12:11 +0100, Pablo Fernández Alonso wrote: Hi Patrik, I am going to order a 1.5 m parabolic dish and the distance between the dish and the PC is around 40 meters. I designed helix feed with 9 dB of gain for F/D = 0.5. I need a (cheap) lnb downconverter to vhf in order to reduce the cable attenuation. Regards, Pablo. 2014-03-05 10:52 GMT+01:00 Patrik Tast pat...@poes-weather.com: Hi Pablo, 8.5dB (at the receiver) and a LHCP helix feed designed for that dish will work. We must know your COAX cable type and length so we can calculate your loss. When designing the helix feed, use dish 10 dB taper, usually 3 turns for a parabolic dish but if an offset dish is used use +6 turns. If you provide me data of your dish size (parabolic or offset), f/D and COAX type and length I can quickly help you with an option. A good enough LNA can be found here http://lna4all.blogspot.fi/ Regards, Patrik On Wed, 2014-03-05 at 10:35 +0100, Pablo Fernández Alonso wrote: Hi Patrik, Do you think it is possible to receive HRPT using the dish but without a LNA? I saw an article where the author receives with an helical antenna with 8.5 dB of gain and a 20 dB LNA. I tried to contact with them, but I received no answer. http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=arnumber=1488531tag=1 Regards, Pablo. 2014-02-26 21:04 GMT+01:00 Patrik Tast pat...@poes-weather.com: Hi Pablo, No, you will run into problems, as you can see I'm using a 1.5m dish and you need to track the satellite Patrik On Wed, 2014-02-26 at 13:02 +0100, Pablo Fernández Alonso wrote: Hello Patrik, You replied my question about an HRPT receiver using GNU radio. I am designing the station, and I don't know the gain needed to receive this sort of images correctly, so if you could help me I would be really helpful. I am designing a microstrip array to do it but I don't know if the gain would be enough. Regards, Pablo Fernandez ---End Message--- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Google Summer of Code 2014 applicant : Optimization with VOLK
Hi Nathan and Abhishek, On 10/03/2014 23:22, West, Nathan wrote: Ah! So there was a slight miscommunication. Yes, porting the OpenAirInterfaces SIMD code to VOLK is a good option as well. The turbo channel coder/decoder is part of that. I've *briefly* looked at the code to see what is currently there, and it's my understanding that the work involved will be to write generic C implementations of vectorized code where the generic version does not exist. Beyond that porting to newer/different ISAs (AVX or NEON depending on your preference and hardware availability). I think Florian is on the gr-discuss mailing list, but I've CCed him to hopefully provide more details as he's more familiar with the original code base. I only joined this mailing list recently, so I probably missed a part of the discussion. Let me summarize briefly what OpenAirInterface can provide. We have optimized SIMD (SSE4) implementations of the LTE turbo encoder and decoder as well as the LTE tail-biting Viterbi encoder and decoder. We also have the 802.11 Viterbi encoder and decoder. The only functions for which we have generic non-vectorized functional equivalents is the LTE turbo decoder. I am not sure I understand why it is necessary to write generic versions for the already optimized SIMD code. My idea was to port the optimized SIMD code from OpenAirInterface to VOLK, such that is can be used by GR applications. I am not familiar with VOLK (yet) but this might just be as easy as writing a wrapper function. As Nathan suggested, the more interesting part is probably to upgrade the code to AVX2 or similar. Cheers, Florian. attachment: Florian_Kaltenberger.vcf___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] FW: output operand requires a reduction, but reduction is not enabled
From: David Halls Sent: 11 March 2014 16:10 To: Martin Braun; discuss-gnuradio@gnu.org Subject: RE: [Discuss-gnuradio] output operand requires a reduction, but reduction is not enabled Hi, Yes, the len(output_items[0]), is either 1 or 2... If I set_output_multiple to 10, then this value raises to 10. It is dominated by the fact that one of the inputs to my block is much lower than the other?? Input[0] is the data stream and has say 768 items, input[1] is the packet average SNR, so it only has 1 or 2 items in the same period. Forecast is currently For I in range (len(ninput_items_required)): Ninput_items_required[i] = noutput_items Does this need to be altered for my case where I have two inputs with very different requirements. If I ever get my head around the scheduler in GNU radio, it will be a happy day :) D -Original Message- From: discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org [mailto:discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org] On Behalf Of Martin Braun Sent: 11 March 2014 15:27 To: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] output operand requires a reduction, but reduction is not enabled On 03/11/2014 04:24 PM, David Halls wrote: Please see the papers we've submitted so far this year. Not exactly WNC, yet... We're putting one together as we speak though. I am not sure I understand your reply fully... Len(out_bA1) is only 1 or 2, so I can only set one or two elements? Is this before or after you assign something? What's len(output_items[0])? How can I extend the length of out_bA1, so I can output all of est_bA1m? You can't, not in the work function. You can do things like set_output_multiple() to influence the size of the output buffer. Or alternatively Is it possible for me to set output_items[0][0:len(est_bA1m)] = est_bA1m That would work, if len(est_bA1m) len(output_items[0]) AND they have the right shape (in matrix terms). ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio NOTE: The information in this email and any attachments may be confidential and/or legally privileged. This message may be read, copied and used only by the intended recipient. If you are not the intended recipient, please destroy this message, delete any copies held on your system and notify the sender immediately. Toshiba Research Europe Limited, registered in England and Wales (2519556). Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, England. Web: www.toshiba.eu/research/trl --- This email has been scanned for email related threats and delivered safely by Mimecast. For more information please visit http://www.mimecast.com --- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Google Summer of Code 2014 applicant : Optimization with VOLK
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Florian, the generic implementation serves 2 purposes, at least in my opinion. Firstly, in case the necessary hardware extension is not available on the target hardware, there is a backup default. Secondly, the generic implementation is usually easier to read and thus preferable as a reference. I know that this is a 'the code is the documentation' argument. But even though documentation might be really good, sometimes looking at the code just makes things clearer. happy hacking Johannes On 11.03.2014 23:08, Florian Kaltenberger wrote: Hi Nathan and Abhishek, On 10/03/2014 23:22, West, Nathan wrote: Ah! So there was a slight miscommunication. Yes, porting the OpenAirInterfaces SIMD code to VOLK is a good option as well. The turbo channel coder/decoder is part of that. I've *briefly* looked at the code to see what is currently there, and it's my understanding that the work involved will be to write generic C implementations of vectorized code where the generic version does not exist. Beyond that porting to newer/different ISAs (AVX or NEON depending on your preference and hardware availability). I think Florian is on the gr-discuss mailing list, but I've CCed him to hopefully provide more details as he's more familiar with the original code base. I only joined this mailing list recently, so I probably missed a part of the discussion. Let me summarize briefly what OpenAirInterface can provide. We have optimized SIMD (SSE4) implementations of the LTE turbo encoder and decoder as well as the LTE tail-biting Viterbi encoder and decoder. We also have the 802.11 Viterbi encoder and decoder. The only functions for which we have generic non-vectorized functional equivalents is the LTE turbo decoder. I am not sure I understand why it is necessary to write generic versions for the already optimized SIMD code. My idea was to port the optimized SIMD code from OpenAirInterface to VOLK, such that is can be used by GR applications. I am not familiar with VOLK (yet) but this might just be as easy as writing a wrapper function. As Nathan suggested, the more interesting part is probably to upgrade the code to AVX2 or similar. Cheers, Florian. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTH56MAAoJEO7fmkDsqywMb+AP/jNXrJoV7Cs6wY7Cx9AHkllM NEo1mxxBhaALsxWv9xwTImaGpA83guiBZ8o0CufYj65oN/i1mN8dUHgK9D/SlLSn GhWTZSBlBiVvIUtxFskDaAA0sqg/2Ae+iYoDKm0yxJerU49K5YGrTBFhzgl7i/r5 fZz+BIGPm29rP1kHyRfw/ROmonXOlz1z+jIR7PGK7DEQbw/Uy9eITchVVKMNsdjm X73+vJHF9UXftzbpwEF/CsgwWVnTvWEVy3YjvxaKRMET/2zQWtEJst51l+aVWFLp M4ejRtf4zmuSBx5JUMf0/eY1lnNWUkqdlcEaLkddalDwl5chkkfxtS+Gwd6YEqJH pdqIa7BfHMaPwrKJ/bX3Wp9u9czWcwI9c8A9GjxnFrASIy2g+QLzU21XDdmImFWm iqaOB0p+/y6bK/V91a4ZjL9gtTBRahlmlmB2EIcPsxlnW+PjJZKNPA833BkuqEE8 gU7w9diq5nbEQYhsvxeqz0WX16yZNwJlz98ane8+oZaVNt9JRI0cjuj0JX24EEPT 9wUfPkmnr1325NJISFJx8X7w2mAQV3zrf5Md1wOfI6Ls9Byfp8+WjeRYrTfzC95b kXvcTVID0XZdoTItSjQUEbbJAbl8IkfwWaQCNgHCcJzfZLdJ2hHy7RqpiBAkMmAv QzLU1GZSSHXzEPKUI1fM =INm4 -END PGP SIGNATURE- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] looping with work() function
Dear Sumedha Goyal, On Wed, Mar 12, 2014 at 1:51 AM, Sumedha Goyal sumedha1...@gmail.com wrote: 1. There is a file source that frames data packets for the test_demo. This is part of a transmitter USRP. 2. I have another USRP as receiver that sends an ACK upon reception of data packets to the transmitter. 3. Start sign is a threshold value. If the packet information (calculated by some method) exceeds this threshold, transmission starts and upon receiving an ACK stops. It sounds like you are trying to transfer file from PC#1 to PC#2, connected via USRPs. At PC#1, user payload is read from a file on harddisk. This data is fed into a custom block. This block will start transmitting when certain criteria is met. When PC#2 receive the packets, it will send ACK back to PC#1. If this is what you try to accomplished, of course this could be implemented by gnuradio. There are thousands of such setup being tested using gnuradio. You should have told us the big picture, let us figure out the implementation details for you, not the opposite way. Forget about your initial python code because that limit us to dead end. 4. I change this threshold value for every new iteration and count how many packets were transmitted before receiving a success ACK. I can do this manually for every iteration but how to automate it for say some 1000 iterations? When you automate it you must have a calculation formula or decision algorithm. Please give a simple example of such calculation formula. Now I am still in the midst of trying to understand your requirements correctly. Meanwhile, please do not top-post. Refer http://gnuradio.org/redmine/projects/gnuradio/wiki/ReportingErrors#How-should-I-format-my-message Regards, Activecat ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Controlport error in GRC
Hi,
I am trying to run a GRC flow graph with control port probe and control
port monitor.
I get the following error in GRC:
Traceback (most recent call last):
File /usr/local/bin/gr-ctrlport-monitor, line 30, in module
from gnuradio.ctrlport.IceRadioClient import *
File
/usr/local/lib/python2.7/dist-packages/gnuradio/ctrlport/IceRadioClient.py,
line 27, in module
from gnuradio.ctrlport import GNURadio
File
/usr/local/lib/python2.7/dist-packages/gnuradio/ctrlport/GNURadio/__init__.py,
line 8, in module
import gnuradio_ice
File /usr/local/lib/python2.7/dist-packages/gnuradio_ice.py, line 98,
in module
_M_gnuradio.ctrlport.GNURadio._t_Knob =
IcePy.defineClass('::GNURadio::Knob', Knob, -1, (), False, False, None, (),
())
TypeError: function takes exactly 7 arguments (9 given)
can anyone help me with the problem?
GNU Radio companion version: 3.7.4
Regards,
Saran
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
