Re: [Discuss-gnuradio] TX/RX with USRPN200 and GNURadio
I have Ubuntu 12.04 in this PC http://www.amazon.com/HP-FF825AV-Workstation-2-8GHz-nVidia/dp/B00B90WIGE (Quad Core and 12GB RAM). With the scheme with loop I have: Generating: /home/caruiz_ext/Escritorio/generadoresGNU/top_block.py Generating: /home/caruiz_ext/Escritorio/generadoresGNU/top_block.py Executing: /home/caruiz_ext/Escritorio/generadoresGNU/top_block.py linux; GNU C++ version 4.6.3; Boost_105300; UHD_003.006.002-64-g92b0b7ab -- Opening a USRP2/N-Series device... -- Current recv frame size: 1472 bytes -- Current send frame size: 1472 bytes Using Volk machine: sse4_2_64 UU[..more U...] What is the problem? Maybe there is none? You don't write anything about your rates etc., but U means underrun, which in turn means your computer isn't producing data fast enough (or on time). M ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Works with GR 3.6, breaks with 3.7
On 10/18/2014 05:57 PM, Luke Berndt wrote: The Band Edge FLL works great for me too, on 3.6. Does anyone know if there were changes to it or surrounding blocks in 3.7 that would make it stop working? None of the DSP was changed, if it worked before it should(TM) still work. The reason we say it's a bad choice is that it was derived for PSK/PAM signals. The reason it still might work is that the implementation runs 2 filters at the band-edges and compares the energy content of those, and that difference might be sufficient to correct your frequency offset if you have sufficient averaging (i.e. low enough loop bandwidth). M ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Looking for 802.11 MAC PHY Package
On 10/16/2014 11:50 AM, Vanush Vaswani wrote: Is it possible to do 11ac on SDR? Vanush, the answer to *any* question of the type can we do standard X on SDR is always 'yes'. Are you planning to do this yourself, or are you looking for a finished solution? Also, what's your goals? M On Wed, Oct 15, 2014 at 10:07 PM, Bastian Bloessl bloe...@ccs-labs.org wrote: Hi, On 10/10/2014 06:20 PM, Zhang, Jiayi wrote: Dear Marcus and Bloessl, Thanks for the reply. I also notice the fully functional gr-ieee802-11 package provide by Bloessl. Previously I thought it's only PHY, but as Marcus mentioned it also include MAC. It seems to me in the gr-ieee802-11-master package, the MAC does not run csma. I also find the gr-ieee802-11-csma package, which is smaller than the master package but indicate csma in name and one of examples. Sorry, I don't get what you mean with smaller. Are you talking about the file size of the sources? All branches add / parse the MAC header as defined in the standard. So the frame format is OK on all branches. The 'csma' branch implements channel access for broadcast frames. After checking the Readme and other pulications from WIME project, I cannot find detail description regarding the MAC and CSMA function for the package. It's the one at the top http://www.ccs-labs.org/bib/bloessl2014timings/ 1. Does the csma package should be used with the master package? No. 'csma' is the name of a branch. You would checkout and use that branch. 2. Does the csma package support multiple nodes in an ad-hoc network? The CSMA implementation is for broadcast frames only. So depends on what you want to do. Return to Marcus's advice, do you mean that to realize the MAC (CSMA), we still need implement FPGA (not the one in USRP?) to handle it in hardware, no matter we use the software lib, e.g. GRU Radio or Click Module Router? To support CSMA functionality you will have to change the FPGA otherwise you will not be able to meet the timing constraints of 802.11. For the broadcast case you only need some small changes. If you want to support ACKS and RTS/CTS you need a lot of functionality on the FPGA. In my opinion this will not happen on a N210, but AFAIK Ettus has a 802.11 implementation for RFNoC (i.e. for the FPGA) which most likely meets all timing constraints. Best, Bastian Many thanks for your help again! Best regards, Jiayi On Thu, Oct 9, 2014 at 4:05 PM, Marcus Müller marcus.muel...@ettus.com mailto:marcus.muel...@ettus.com wrote: Hi Jiayi, :) gr-ieee802-11 is, as far as I know, the most comprehensive, functional implementation so far. It *can* talk to consumer cards -- but of course, that's not because it has a complete MAC implementation. Actually, doing a really standards-compliant IEEE802.11agp MAC can't really be done in host software alone -- the gigabit ethernet interface alone just has too much latency, and you'll have to be really fast when detecting ACK's, calculating checksums and sending out the reply. I doubt you can implement a fully working IEEE802.11 MAC in software alone without touching the FPGA. Here's the official source code: https://github.com/bastibl/gr-ieee802-11 has the source code, btw. Greetings, Marcus On 09.10.2014 21:47, Zhang, Jiayi wrote: Dear Marcus and all, Many thanks for the advice regarding the Hydra and ORBIT project. Actually I'm looking for the open-source 802.11 PHYMAC packages which are compatible with Recent GNU Radio and USRP N210/X310. I've searched from internet and got some findings listed below: 1) Hydra PHY MAC from University of Texas at Austin [1] 2) FTW IEEE802.11a/g/p OFDM Frame Encoder [2] 3) UWICORE m-HOP 802.11 MAC for USRP based on the FTW PHY [3] http://www.uwicore.umh.es/mhop-software.html *** All (1-3) only compatible with gnuradio-3.2.2 which was too many years ago. 4) WIME IEEE 802.11a/g/p Transceiver for GNU Radio v3.7 [3] http://www.ccs-labs.org/software/gr-ieee802-11/ *** This is a most recent package for gnuradio 3.7, but is PHY only. Are there any MAC package which compatible with this WIME PHY? 5) ORBIT Project [5] *** This is a huge project which can be studied. Are there any project provide both 802.11 MAC PHY like Hydrd did before? Best regards, Jiayi [1] K. Mandke, Soon-Hyeok Choi, Gibeom Kim, R. Grant, R. Daniels, Wonsoo Kim, R. W. Heath, Jr., and S. Nettles, “Early Results on Hydra: A Flexible MAC/PHY Multihop Testbed,” Proc. of IEEE Vehicular Tech. Conf. , pp. 1896-1900, Dublin, Ireland, April 23 – 25, 2007. [2] http://www.cgran.org/wiki/ftw80211ofdmtx [3] J.R. Gutierrez-Agullo, B. Coll-Perales and J. Gozalvez, An
Re: [Discuss-gnuradio] TX/RX with USRPN200 and GNURadio
I have this flowgraph: sampleTX is a recorded signal of 5 minutes. 2014-10-20 9:23 GMT+02:00 Martin Braun martin.br...@ettus.com: I have Ubuntu 12.04 in this PC http://www.amazon.com/HP-FF825AV-Workstation-2-8GHz-nVidia/dp/B00B90WIGE (Quad Core and 12GB RAM). With the scheme with loop I have: Generating: /home/caruiz_ext/Escritorio/generadoresGNU/top_block.py Generating: /home/caruiz_ext/Escritorio/generadoresGNU/top_block.py Executing: /home/caruiz_ext/Escritorio/generadoresGNU/top_block.py linux; GNU C++ version 4.6.3; Boost_105300; UHD_003.006.002-64-g92b0b7ab -- Opening a USRP2/N-Series device... -- Current recv frame size: 1472 bytes -- Current send frame size: 1472 bytes Using Volk machine: sse4_2_64 UU[..more U...] What is the problem? Maybe there is none? You don't write anything about your rates etc., but U means underrun, which in turn means your computer isn't producing data fast enough (or on time). 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
[Discuss-gnuradio] Guided Tutorials - Experience
Hello, I did 2 of the Guided Tutorials - Programming GNU Radio in Python and C++ and want to tell you about my experiences. First thanks for making this tutorials! They really help me to get a good start with GNU Radio. Tutorial with Python: Since I don t have any programming experience in Pyton (and C++) I really liked it that it is very detailed! Could do it and understand everything! Tutorial with C++: Really had problems doing this tutorial. I must admit that my C++ knowledge is very low. - In the tutorial there is just written to edit the and how to edit the .cc file. But in the header there are also things to be edited. - After declaring the function get_minimum_distances in header file and trying to compile (make) I get the error: unknown variable d_gray_code. So I guess in the .cc file there has to be done some assignment like d_gray_code = gray_code ? - After doing some editings in header and .cc file I managed to compile. - To prevent any errors I copied the given (on the tutorial page) .xml code into my .xml file. After cmake ../ -- make -- sudo make install -- sudo ldconfig -- restart GRC -- new block did not appear ? - Maybe it s because the last 6 lines of xml file ? There appear /block 2 times. After editing the file made by gr_modtool with the instructions it worked :-) But after having done a QA test as it is written on the tutorial I get wrong results (AssertError). Seems that although I call qpsk = tutorial.my_qpsk_demod_cb(gray_code) with gray_code = false The code just enters the if clause with gray_code == true? Do you have any idea why? Here are my files, which are nearly the same as the ones in examples. https://dl.dropboxusercontent.com/u/33858807/my_qpsk_demod_cb_impl.cc https://dl.dropboxusercontent.com/u/33858807/my_qpsk_demod_cb_impl.h https://dl.dropboxusercontent.com/u/33858807/qa_my_qpsk_demod_cb.py Thank you in advance! Best regards, Vlad ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Compiling SWIG python bindings with -builtin option
Hello Martin, thank you for reviewing this idea. I'm already working on a branch with the required changes. The required changes are the build flag and some adjustment to the SWIG bindings. With builtin object classes there isn't anymore a python wrapper class therefore it is not possible to fiddle with the class methods at runtime. For example, the __repr__() method cannot be patched in at runtime but needs to be defined in the SWIG interface. So far I have gnuradio-runtime, including pmt, and gr-blocks compiling and I haven't found any major change required and I'm looking for the cleaner way to implement some things. I haven't yet tried to propagate my changes to the other modules. I hope to have a proof of concept ready in the next few days. I'm not familiar with SWIG (and it is not very friendly), so the process of finding the right way of doing things has been mostly a process of try and error. Cheers, Daniele On 20/10/14 09:36, Martin Braun wrote: Daniele, this is interesting. However, I'm not 100% clear about the implications this would have (i.e. which changes are necessary). Is it just the build flag, and then of course the accompanying limitations listed in the manual (those would not be a problem, as far as I can tell)? One thing I can say for sure is that it won't be merged into GNU Radio 3.7, since it requires a compat bump for SWIG. However, we are planning that for 3.8, so this change is not unreasonable. This is new to me, and I just gave the manual a quick browse. From that, it seems a good idea, but as I said, I can't quite see all the consequences. If you could provide a branch with the necessary changes (an incomplete proof of concept would be fine, just so we can see what needs to be changed), branched off of next, that would be great. Thanks for suggesting this! Martin On 10/15/2014 08:12 PM, Daniele Nicolodi wrote: Hello, I use the vector_source_x and vector_sinc_x blocks quite a lot for testing, debugging and simulations, even with quite large input and output data streams. Therefore I was looking in speeding up the feeding and retrieval of data by implementing the Python buffer interface [0] that permits to exposed data to other components handling uniform vectors of data in a copy-free manner. Investigating how to do that in SWIG I found that [1] the only supported way of doing this is to compile the bindings with the SWIG -builtin option [2] that modifies how the Python bindings are constructed. Making a long story short, the Python class definition is not done anymore in python code, but with a proper Python extension (in a more clean way, IMHO). At first I tried to implement this in an out-of-tree GNURadio module, however I run into problems because SWIG is unable to generate bindings with the -builtin flag for types subclassing from types defined in an extension compiled without the -builtin option (sorry, that reads a bit too convoluted...). There is interest in switching GNURadio over to the -builtin way of generating the bindings? We would gain somehow cleaner bindings, the possibility of populating the Python objects slots to implement specific object behaviors (to get rid of the __repr__() override necessary for each block, and the buffer interface, for example). If there is interest, I can look into providing a patch. A quick test revealed no problems in adding the -builtin option to the makefiles. Thank you for reading all that :-) Cheers, Daniele [0] https://docs.python.org/2.7/c-api/buffer.html [1] http://swig.10945.n7.nabble.com/swig-python-extension-accessing-PyObject-to-implment-pep-3118-revised-buffer-Protocol-td2419.html [2] http://quantlib.org/reposit/docs/swig/Python.html#Python_builtin_types ___ 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
[Discuss-gnuradio] Transmitting bursts with GRC by inserting SOB and EOB
Hello, I am trying to implement a burst transmitter using GNU Radio Companion and an USRP N210 with WBX board. My problem is when inserting zeros as gap between the bursts the USRP is transmitting a non-neglectable carrier signal (due to DC offset I guess?). So I want to try inserting tx_sob and tx_eob stream tags to make the USRP shutting down the TX chain. For that I created a sample flow graph which creates one burst with 6 samples. The tags are inserted by a Message Burst Source. The important part of the generated .py file is as follows: ## # Variables ## self.tx_gain = tx_gain = 15 self.samp_rate = samp_rate = 20 self.f_center = f_center = 1.47e9 ## # Message Queues ## blocks_message_sink_0_msgq_out = blocks_message_burst_source_0_msgq_in = gr.msg_queue(2) ## # Blocks ## self.usrp_sink = uhd.usrp_sink( device_addr=device, stream_args=uhd.stream_args( cpu_format=fc32, channels=range(1), ), ) self.usrp_sink.set_samp_rate(samp_rate) self.usrp_sink.set_center_freq(f_center, 0) self.usrp_sink.set_gain(tx_gain, 0) self.usrp_sink.set_antenna(TX/RX, 0) self.blocks_vector_source_x_0 = blocks.vector_source_c((1,1,1,1,1,0), False, 1, []) self.blocks_tag_debug_0 = blocks.tag_debug(gr.sizeof_gr_complex*1, , ); self.blocks_tag_debug_0.set_display(True) self.blocks_message_sink_0 = blocks.message_sink(gr.sizeof_gr_complex*1, blocks_message_sink_0_msgq_out, False) self.blocks_message_burst_source_0 = blocks.message_burst_source(gr.sizeof_gr_complex*1, blocks_message_burst_source_0_msgq_in) ## # Connections ## self.connect((self.blocks_vector_source_x_0, 0), (self.blocks_message_sink_0, 0)) self.connect((self.blocks_message_burst_source_0, 0), (self.blocks_tag_debug_0, 0)) self.connect((self.blocks_message_burst_source_0, 0), (self.usrp_sink, 0)) Through the Tag Debug block I observe that the tags are set correctly (tx_sob at sample 0 and tx_eob at sample 5). Nevertheless the USRP is still transmitting at the carrier frequency after the actual burst is completed. I observed that with a second USRP as receiver. It seems like the USRP Sink is ignoring the tags. Trying the tags_demo application showed the desired behaviour. No carrier between the bursts. I checked the source code and noticed that they are additionally assigning time stamps as tags to the samples. Is this necessary to achieve my goal? I am using GNU Radio 3.7.2.1 and UHD_003.005.005-0. Any comments on this issue are highly appreciated! Frederik. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Compiling SWIG python bindings with -builtin option
On 10/20/2014 11:19 AM, Daniele Nicolodi wrote: Hello Martin, thank you for reviewing this idea. I'm already working on a branch with the required changes. The required changes are the build flag and some adjustment to the SWIG bindings. With builtin object classes there isn't anymore a python wrapper class therefore it is not possible to fiddle with the class methods at runtime. For example, the __repr__() method cannot be patched in at runtime but needs to be defined in the SWIG interface. So far I have gnuradio-runtime, including pmt, and gr-blocks compiling and I haven't found any major change required and I'm looking for the cleaner way to implement some things. I haven't yet tried to propagate my changes to the other modules. I hope to have a proof of concept ready in the next few days. I'm not familiar with SWIG (and it is not very friendly), so the process of finding the right way of doing things has been mostly a process of try and error. Oh, we know what you're talking about :) I'm interested what happens when you reach blocks that *do* fiddle with SWIG. gr-uhd does this, and in gr-digital with have a couple of tweaks. Having to write .i files for everything would be a nuisance, given that we mostly got rid of that in 3.7. Also, I'm very interested in benchmarks. If there's some effort involved here, it has to pay off in terms of speed. I'd suggest you open an issue on our tracker, and we take the discussion there. I'm hoping that that some people with more SWIG experience can chime in here, too. M ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Compiling SWIG python bindings with -builtin option
On 20/10/14 11:50, Martin Braun wrote: On 10/20/2014 11:19 AM, Daniele Nicolodi wrote: Hello Martin, thank you for reviewing this idea. I'm already working on a branch with the required changes. The required changes are the build flag and some adjustment to the SWIG bindings. With builtin object classes there isn't anymore a python wrapper class therefore it is not possible to fiddle with the class methods at runtime. For example, the __repr__() method cannot be patched in at runtime but needs to be defined in the SWIG interface. So far I have gnuradio-runtime, including pmt, and gr-blocks compiling and I haven't found any major change required and I'm looking for the cleaner way to implement some things. I haven't yet tried to propagate my changes to the other modules. I hope to have a proof of concept ready in the next few days. I'm not familiar with SWIG (and it is not very friendly), so the process of finding the right way of doing things has been mostly a process of try and error. Oh, we know what you're talking about :) I'm interested what happens when you reach blocks that *do* fiddle with SWIG. gr-uhd does this, and in gr-digital with have a couple of tweaks. I had a look at what gr-uhd does in its python code and it looks like it mostly corrects for things that could be also solved easily in SWIG. Worst case what can be done is that the SWIGGed class is renamed (with a SWIG directive) and at is sub-classed in Python to tweat with it at will. However, I don't see the need of it so far. Having to write .i files for everything would be a nuisance, given that we mostly got rid of that in 3.7. I don't understand what you mean with this. We have .i files for everything! For out-of-tree modules they are auto-generated by gr_modtool and some parts are hidden behind SWIG macros, but there definitely are .i files for all the classes in GNURadio. It is how SWIG works :) Also, I'm very interested in benchmarks. If there's some effort involved here, it has to pay off in terms of speed. I don't think there are any speed advantages for blocks coded in C++, what can be sped up is instantiation and configuration of the blocks. The actual work methods are already called in C++ context without Python overhead, so there is nothing to to gain there. This is different for blocks coded in Python, but to take advantage of the improved SWIG wrappers other changes would be required, probably. There is quite a bit of magic involved at the moment, that can be probably simplified with better wrappers. However, I have the feeling that if speed is a goal, SWIG is probably not the right tool. The code it generates it sub-optimal under many aspects (starting with the double type system it puts in place: the SWIG type system somehow glued on top of the Python type system...) I'd suggest you open an issue on our tracker, and we take the discussion there. I'm hoping that that some people with more SWIG experience can chime in here, too. I'll do. Cheers, Daniele ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] TX/RX with USRPN200 and GNURadio
Another question. I have a GPS receiver ( http://u-blox.com/images/downloads/Product_Docs/LEA-NEO-6T_ProductSummary_%28GPS.G6-HW-09020%29.pdf ) with a Osmo board ( http://openbsc.osmocom.org/trac/wiki/osmo-lea6t-gps ) Can I directly connect the USRP (WBX) to the GPS receiver? Can I damage the WBX board with the power of receiver RF port? 2014-10-20 9:54 GMT+02:00 Carlos Alberto Ruiz Naranjo carlosruiznara...@gmail.com: I have this flowgraph: sampleTX is a recorded signal of 5 minutes. 2014-10-20 9:23 GMT+02:00 Martin Braun martin.br...@ettus.com: I have Ubuntu 12.04 in this PC http://www.amazon.com/HP-FF825AV-Workstation-2-8GHz-nVidia/dp/B00B90WIGE (Quad Core and 12GB RAM). With the scheme with loop I have: Generating: /home/caruiz_ext/Escritorio/generadoresGNU/top_block.py Generating: /home/caruiz_ext/Escritorio/generadoresGNU/top_block.py Executing: /home/caruiz_ext/Escritorio/generadoresGNU/top_block.py linux; GNU C++ version 4.6.3; Boost_105300; UHD_003.006.002-64-g92b0b7ab -- Opening a USRP2/N-Series device... -- Current recv frame size: 1472 bytes -- Current send frame size: 1472 bytes Using Volk machine: sse4_2_64 UU[..more U...] What is the problem? Maybe there is none? You don't write anything about your rates etc., but U means underrun, which in turn means your computer isn't producing data fast enough (or on time). 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] Guided Tutorials - Experience
Vlad, thanks for going through the guided tutorials, and thanks for your feedback. We'll address those soon and fix the tutorials. As for your solution, I'm not sure. I recommend putting a couple of print statements so you can tell what's going on. cheers, M On 10/20/2014 10:06 AM, Vlad Stoica wrote: Hello, I did 2 of the Guided Tutorials - Programming GNU Radio in Python and C++ and want to tell you about my experiences. First thanks for making this tutorials! They really help me to get a good start with GNU Radio. Tutorial with Python: Since I don t have any programming experience in Pyton (and C++) I really liked it that it is very detailed! Could do it and understand everything! Tutorial with C++: Really had problems doing this tutorial. I must admit that my C++ knowledge is very low. - In the tutorial there is just written to edit the and how to edit the .cc file. But in the header there are also things to be edited. - After declaring the function get_minimum_distances in header file and trying to compile (make) I get the error: unknown variable d_gray_code. So I guess in the .cc file there has to be done some assignment like d_gray_code = gray_code ? - After doing some editings in header and .cc file I managed to compile. - To prevent any errors I copied the given (on the tutorial page) .xml code into my .xml file. After cmake ../ -- make -- sudo make install -- sudo ldconfig -- restart GRC -- new block did not appear ? - Maybe it s because the last 6 lines of xml file ? There appear /block 2 times. After editing the file made by gr_modtool with the instructions it worked :-) But after having done a QA test as it is written on the tutorial I get wrong results (AssertError). Seems that although I call qpsk = tutorial.my_qpsk_demod_cb(gray_code) with gray_code = false The code just enters the if clause with gray_code == true? Do you have any idea why? Here are my files, which are nearly the same as the ones in examples. https://dl.dropboxusercontent.com/u/33858807/my_qpsk_demod_cb_impl.cc https://dl.dropboxusercontent.com/u/33858807/my_qpsk_demod_cb_impl.h https://dl.dropboxusercontent.com/u/33858807/qa_my_qpsk_demod_cb.py Thank you in advance! Best regards, Vlad ___ 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] Transmitting bursts with GRC by inserting SOB and EOB
A couple of comments, maybe this helps you on your tracks: - You're using an ancient UHD version. Is there a reason you can't use a newer one? - In current GNU Radio, you can use 'length tags' to mark bursts, if that's any help. - You'll know if your USRP hasn't acknowledged tx_eob if you see 'U's between bursts. Cheers, M On 10/20/2014 11:43 AM, Frederik Wing wrote: Hello, I am trying to implement a burst transmitter using GNU Radio Companion and an USRP N210 with WBX board. My problem is when inserting zeros as gap between the bursts the USRP is transmitting a non-neglectable carrier signal (due to DC offset I guess?). So I want to try inserting tx_sob and tx_eob stream tags to make the USRP shutting down the TX chain. For that I created a sample flow graph which creates one burst with 6 samples. The tags are inserted by a Message Burst Source. The important part of the generated .py file is as follows: ## # Variables ## self.tx_gain = tx_gain = 15 self.samp_rate = samp_rate = 20 self.f_center = f_center = 1.47e9 ## # Message Queues ## blocks_message_sink_0_msgq_out = blocks_message_burst_source_0_msgq_in = gr.msg_queue(2) ## # Blocks ## self.usrp_sink = uhd.usrp_sink( device_addr=device, stream_args=uhd.stream_args( cpu_format=fc32, channels=range(1), ), ) self.usrp_sink.set_samp_rate(samp_rate) self.usrp_sink.set_center_freq(f_center, 0) self.usrp_sink.set_gain(tx_gain, 0) self.usrp_sink.set_antenna(TX/RX, 0) self.blocks_vector_source_x_0 = blocks.vector_source_c((1,1,1,1,1,0), False, 1, []) self.blocks_tag_debug_0 = blocks.tag_debug(gr.sizeof_gr_complex*1, , ); self.blocks_tag_debug_0.set_display(True) self.blocks_message_sink_0 = blocks.message_sink(gr.sizeof_gr_complex*1, blocks_message_sink_0_msgq_out, False) self.blocks_message_burst_source_0 = blocks.message_burst_source(gr.sizeof_gr_complex*1, blocks_message_burst_source_0_msgq_in) ## # Connections ## self.connect((self.blocks_vector_source_x_0, 0), (self.blocks_message_sink_0, 0)) self.connect((self.blocks_message_burst_source_0, 0), (self.blocks_tag_debug_0, 0)) self.connect((self.blocks_message_burst_source_0, 0), (self.usrp_sink, 0)) Through the Tag Debug block I observe that the tags are set correctly (tx_sob at sample 0 and tx_eob at sample 5). Nevertheless the USRP is still transmitting at the carrier frequency after the actual burst is completed. I observed that with a second USRP as receiver. It seems like the USRP Sink is ignoring the tags. Trying the tags_demo application showed the desired behaviour. No carrier between the bursts. I checked the source code and noticed that they are additionally assigning time stamps as tags to the samples. Is this necessary to achieve my goal? I am using GNU Radio 3.7.2.1 and UHD_003.005.005-0. Any comments on this issue are highly appreciated! Frederik. ___ 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] Compiling SWIG python bindings with -builtin option
On 10/20/2014 12:16 PM, Daniele Nicolodi wrote: Having to write .i files for everything would be a nuisance, given that we mostly got rid of that in 3.7. I don't understand what you mean with this. We have .i files for everything! For out-of-tree modules they are auto-generated by gr_modtool and some parts are hidden behind SWIG macros, but there definitely are .i files for all the classes in GNURadio. It is how SWIG works :) No, we barely have any (unless you're using a very old GNU Radio). We have top-level .i files which include the actual block header, per-in-tree component if that's what you mean. We do *not* need to write .i files for every block (and are glad about it :). The few modifications we need these days are taken care of by modtool. Also, I'm very interested in benchmarks. If there's some effort involved here, it has to pay off in terms of speed. I don't think there are any speed advantages for blocks coded in C++, what can be sped up is instantiation and configuration of the blocks. The actual work methods are already called in C++ context without Python overhead, so there is nothing to to gain there. This is different for blocks coded in Python, but to take advantage of the improved SWIG wrappers other changes would be required, probably. There is quite a bit of magic involved at the moment, that can be probably simplified with better wrappers. However, I have the feeling that if speed is a goal, SWIG is probably not the right tool. The code it generates it sub-optimal under many aspects (starting with the double type system it puts in place: the SWIG type system somehow glued on top of the Python type system...) SWIG isn't going anywhere soon. But if we can improve on what we have, that's interesting. I'd suggest you open an issue on our tracker, and we take the discussion there. I'm hoping that that some people with more SWIG experience can chime in here, too. I'll do. Thanks! M ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] TX/RX with USRPN200 and GNURadio
On 10/20/2014 12:33 PM, Carlos Alberto Ruiz Naranjo wrote: Another question. I have a GPS receiver ( http://u-blox.com/images/downloads/Product_Docs/LEA-NEO-6T_ProductSummary_%28GPS.G6-HW-09020%29.pdf ) with a Osmo board ( http://openbsc.osmocom.org/trac/wiki/osmo-lea6t-gps ) Can I directly connect the USRP (WBX) to the GPS receiver? Can I damage the WBX board with thepower of receiver RF port? Carlos, please don't mix questions in threads -- they get lost very easily that way. Also, for USRP-specific questions I recommend the usrp-users mailing list. You can definitely damage daughterboards with too much rx power. I'm not sure why you'd connect this board to the WBX -- or do you want to connect it to the REF in ports? M ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Compiling SWIG python bindings with -builtin option
On 20/10/14 13:46, Martin Braun wrote: On 10/20/2014 12:16 PM, Daniele Nicolodi wrote: Having to write .i files for everything would be a nuisance, given that we mostly got rid of that in 3.7. I don't understand what you mean with this. We have .i files for everything! For out-of-tree modules they are auto-generated by gr_modtool and some parts are hidden behind SWIG macros, but there definitely are .i files for all the classes in GNURadio. It is how SWIG works :) No, we barely have any (unless you're using a very old GNU Radio). We have top-level .i files which include the actual block header, per-in-tree component if that's what you mean. We do *not* need to write .i files for every block (and are glad about it :). The few modifications we need these days are taken care of by modtool. Now I see what you mean, but the fact that the .i files are quite small and mostly auto-generated does not change the fact that we need the .i files to tell SWIG to generate code for the blocks :) The .i files for regular GNURadio blocks are not going to change much with the switch to builtin object classes. The only changes required are related to providing a __repr__() method because, unfortunately, the glued on swig type system does not make it possible to have it inherited from parent classes, at least as far as my understand of SWIG goes. I'll try to have a branch with my changes ready to review soon, so we can talk about something more concrete. Cheers, Daniele ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Writing a Radio Driver
Harrison, On option is to start with Nutaq's software package for the Zedboard (http://nutaq.com/en/products/zeptosdr). This software package includes GNU Radio sink/source blocks on PC to get your samples from the ADC through your Zynq into your user land on the PC. It also includes those same GNU Radio sink/source blocks, but for a GNU Radio running on the ARM processor (includes image with Linux, GNU Radio, Nutaq drivers, etc.. for ARM). The FPGA image with comprehensive source files and documentation, and the matching host and ARM drivers (with source code) as well as the GNU Radio user land interface are provided, which should kick-start your work on the Zedboard as far as streaming from GNU Radio on the Zedboard is concerned. Additionally, when using the FMC Radio420x RF daughter card, software package contains GNU Radio blocks to expose your hardware controls practically. Our software package includes an FPGA IP Core for the Radio420x that aims at abstracting the list of the AXI-lite Registers through the use of this user friendly Radio420x FPGA core, as well as the corresponding GNU Radio blocks so that you can avoid pulling signals in the user logic to control the Radio420x and rather call functions on the host computer to control the radio parameters (clk freq, Tx freq, Rx freq, filters, gains, auto-calibration of DC offset and IQ imbalance, etc...). When using an FMC daughter card from a 3rd party vendor with the Zedboard, you may use generic AXI-lite Registers read and write functions in the Nutaq API to control the AXI-lite FMC IP core provided with the FMC card and easily integrate the new card with your existing GNU Radio application. The package also includes GNU Radio blocks to read and write to Zynq FPGA registers. It should kick-start your work on the Zedboard as far as controlling registers from GNU Radio on the Zedboard is concerned. This software package is available online but password protected until we find the most comprehensive way to decouple what's specific to Zedboard from what's specific to the FMC Radio420x. But you can request access for a free evaluation. Good luck. Tristan tristan.mar...@nutaq.com -Message d'origine- De : discuss-gnuradio-bounces+tristan.martin=nutaq@gnu.org [mailto:discuss-gnuradio-bounces+tristan.martin=nutaq@gnu.org] De la part de Marcus Müller Envoyé : 16 octobre 2014 15:29 À : discuss-gnuradio@gnu.org Objet : Re: [Discuss-gnuradio] Writing a Radio Driver Hi Harrison, There's no driver architecture in GNU Radio; you just write sink/source blocks. If you have a few minutes to spare, start with the GNU Radio tutorials [1] from start to hardware; that should give you a solid primer on how things work with GNU Radio. If you then know how you get your samples from the ADC through your Zynq into your userland, you're basically set :D well, aside from minor things like figuring out how to expose your hardware controls most practically to GNU Radio, and how to avoid overhead. Again, there's no standard for hardware control in GNU Radio[1]. UHD is quite specific to Ettus devices, so I don't think screwing your stuff onto that seems very wise (though I've seen parts similar to yours in Ettus products ;) [2]). UHD, though, is open source, including the FPGA image and the matching drivers as well as the userland interface, and I don't think the developers mind you looking at the code they produced to tackle the FPGA-userland interface. Greetings, Marcus [1] maybe there should be. I think we should wrap this up in clean interface specifications, and define CORBA objects for that :D j/k. [2] There is an upcoming embedded USRP, employing a Zynq, the E300. Ettus presented some information on grcon 2014: http://www.trondeau.com/storage/grcon14/presentations/Sep16_05_Ettus_Updates.pdf On 16.10.2014 20:21, Harrison Caudill wrote: Hello Everyone, I have a custom PCB to power an SDR, and I'm going to need to provide a gnuradio driver for it. We are using: * Xilinx Zynq 7020 SoC * Analog Devices AD9364 ADC * AvNet ZedBoard for prototyping I can only imagine that we will ultimately use a tweaked version of the Ettus Research UHD driver. I have found a couple of other drivers that people have written, as well. Short of old-fashioned source-diving, I am unsure of where to begin. Can anyone recommend some good reading on the gnuradio architecture and/or driver layer? I'm guessing I'll have to write a source block for the radio, leaving the issue of running the flow graph on the PL of the Zynq and interfacing properly with the AXI bus. Thanks, Harrison ___ 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] Import block
Hi, I am a new user of GNURadio and I am interested in use the Import block, to import the PSK.PY file, according to a tutorial that I am reading. The problem is that file doesn' t exists in the file sytem of my GNURADIO. When I try to paste it (after download the file from the page of GNURadio), the block still not work because the Gnuradio doesn't catch the file. (with others file on the same folder it works fine). Could someone help me? What I have to do? Thanks ! Regards, *Fernando L. Rodríguez Brizuela -* ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Import block
Fernando, Set the PYTHONPATH environment variable to include the location of the file you want to import, then re-run gnuradio-companion (or the generated Python file). In bash: export PYTHONPATH=$PYTHONPATH:/some/other/directory Then you can put 'import psk' in an Import block. - Jeff On 10/20/2014 01:36 PM, Fernando Rodríguez Brizuela wrote: Hi, I am a new user of GNURadio and I am interested in use the Import block, to import the PSK.PY file, according to a tutorial that I am reading. The problem is that file doesn' t exists in the file sytem of my GNURADIO. When I try to paste it (after download the file from the page of GNURadio), the block still not work because the Gnuradio doesn't catch the file. (with others file on the same folder it works fine). Could someone help me? What I have to do? Thanks ! Regards, *Fernando L. Rodríguez Brizuela -* ___ 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] Import block
On 10/20/2014 03:42 PM, Jeff Long wrote: Fernando, Set the PYTHONPATH environment variable to include the location of the file you want to import, then re-run gnuradio-companion (or the generated Python file). In bash: export PYTHONPATH=$PYTHONPATH:/some/other/directory Then you can put 'import psk' in an Import block. - Jeff Also, if you can say what tutorial you're reading, it would help. If you're referring to the built-in psk.py, you would use something like: from gnuradio.digital import psk Maybe the tutorial is old and you're using a newer version of GNU Radio? - Jeff On 10/20/2014 01:36 PM, Fernando Rodríguez Brizuela wrote: Hi, I am a new user of GNURadio and I am interested in use the Import block, to import the PSK.PY file, according to a tutorial that I am reading. The problem is that file doesn' t exists in the file sytem of my GNURADIO. When I try to paste it (after download the file from the page of GNURadio), the block still not work because the Gnuradio doesn't catch the file. (with others file on the same folder it works fine). Could someone help me? What I have to do? Thanks ! Regards, *Fernando L. Rodríguez Brizuela -* ___ 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] Transmitting bursts with GRC by inserting SOB and EOB
Thank you Martin for your fast response! - You're using an ancient UHD version. Is there a reason you can't use a newer one? I am using Ubuntu 14.04 LTS and just pulled GNU Radio and UHD from the packet sources. There is no newer version available. And I don't like to compile myself unless it is absolutely necessary. I don't think it's because of an outdated version of UHD as the tags_demo application is working perfectly with my current version. - In current GNU Radio, you can use 'length tags' to mark bursts, if that's any help. I tried using length tags by inserting an Stream to tagged Stream block and adding the length_tag_name property to the USRP Sink. Here is my sample code, now with a burst of 5 samples: ## # Variables ## self.tx_gain = tx_gain = 15 self.samp_rate = samp_rate = 20 self.f_center = f_center = 1.47e9 self.device = device = type=usrp2 ## # Blocks ## self.usrp_sink = uhd.usrp_sink( device_addr=device, stream_args=uhd.stream_args( cpu_format=fc32, length_tag_name=packet_len, channels=range(1), ), ) self.usrp_sink.set_samp_rate(samp_rate) self.usrp_sink.set_center_freq(f_center, 0) self.usrp_sink.set_gain(tx_gain, 0) self.usrp_sink.set_antenna(TX/RX, 0) self.blocks_vector_source_x_0 = blocks.vector_source_c((1,)*5, False, 1, []) self.blocks_stream_to_tagged_stream_0 = blocks.stream_to_tagged_stream(gr.sizeof_gr_complex, 1, 5, packet_len) ## # Connections ## self.connect((self.blocks_vector_source_x_0, 0), (self.blocks_stream_to_tagged_stream_0, 0)) self.connect((self.blocks_stream_to_tagged_stream_0, 0), (self.usrp_sink, 0)) It's not working either... I can still observe the carrier at the receiver. - You'll know if your USRP hasn't acknowledged tx_eob if you see 'U's between bursts. I am getting exactly one U. Both for the code in my previous post as well as for the above one. It really seems like the USRP is not recognizing the stream tags. Any further ideas? Can someone reproduce this behaviour? Frederik ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Compiling SWIG python bindings with -builtin option
On 10/20/2014 05:06 AM, Daniele Nicolodi wrote: I'll try to have a branch with my changes ready to review soon, so we can talk about something more concrete. I just wanted to chime in and say that when you have a branch for review I'll be happy to test it. As Martin mentioned, it would likely have to be applied to the next branch, which would get turned in the 3.8.x. However, the benefits seem worth the effort. -- Johnathan Corgan, Corgan Labs SDR/DSP Training and Consulting Services http://corganlabs.com attachment: johnathan.vcf signature.asc Description: OpenPGP digital signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] OpenBTS-UMTS
Hi all, Is there anyone who used OpenBTS-UMTS http://openbts.org/w/index.php/OpenBTS-UMTS with USRPs? I want to know is there possible to run this openBTS on USRP with UHD? And if it is, what is the configuration process? Thanks in advance, Mostafa ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] OpenBTS-UMTS
Have you tried the OpenBTS mailing lists? OpenBTS is *NOT* a Gnu Radio application, although it uses the same hardware as some Gnu Radio apps, it's not a Gnu Radio app itself. On 2014-10-20 15:15, Mostafa Alizadeh wrote: Hi all, Is there anyone who used OpenBTS-UMTS [2] with USRPs? I want to know is there possible to run this openBTS on USRP with UHD? And if it is, what is the configuration process? Thanks in advance, Mostafa ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [1] Links: -- [1] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [2] http://openbts.org/w/index.php/OpenBTS-UMTS ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] OpenBTS-UMTS
No, I didn't try OpenBTS mailing list, but I think this is possible to run the BTS over USRPs with some specific UHD configuration. Thank you for your hint. OpenBTS isn't even a GNURadio app. Did you try it? On Mon, Oct 20, 2014 at 3:17 PM, mle...@ripnet.com wrote: Have you tried the OpenBTS mailing lists? OpenBTS is *NOT* a Gnu Radio application, although it uses the same hardware as some Gnu Radio apps, it's not a Gnu Radio app itself. On 2014-10-20 15:15, Mostafa Alizadeh wrote: Hi all, Is there anyone who used OpenBTS-UMTS http://openbts.org/w/index.php/OpenBTS-UMTS with USRPs? I want to know is there possible to run this openBTS on USRP with UHD? And if it is, what is the configuration process? Thanks in advance, Mostafa ___ Discuss-gnuradio mailing listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- *** Department of Electrical Engineering Aboureyhan Building MMWCL LAB Amirkabir University Of Technology Tehran IRAN Tel: +98 (919) 158-7730 LAB: http://ele.aut.ac.ir/~mmwcl/?page_id=411 Homepage: http://ele.aut.ac.ir/~alizadeh/ *** ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] OpenBTS-UMTS
Hello Mostafa Alizadeh: OpenBTS and OpenBTS-UMTS do not use the GNU Radio framework at all, and so you don't need to install GNU Radio in order to use them. To use OpenBTS and OpenBTS-UMTS with USRP radios, you will need to install UHD [1], which you should install before installing OpenBTS and OpenBTS-UMTS. However, I don't think there is an OpenBTS-UMTS transceiver process for USRP radios yet, and you can't substitute the OpenBTS transceiver. [1] https://github.com/EttusResearch/uhd This conversation should be continued on the openbts-discuss mailing list. --Neel On Mon, Oct 20, 2014 at 12:23 PM, Mostafa Alizadeh m.alizade...@gmail.com wrote: No, I didn't try OpenBTS mailing list, but I think this is possible to run the BTS over USRPs with some specific UHD configuration. Thank you for your hint. OpenBTS isn't even a GNURadio app. Did you try it? On Mon, Oct 20, 2014 at 3:17 PM, mle...@ripnet.com wrote: Have you tried the OpenBTS mailing lists? OpenBTS is *NOT* a Gnu Radio application, although it uses the same hardware as some Gnu Radio apps, it's not a Gnu Radio app itself. On 2014-10-20 15:15, Mostafa Alizadeh wrote: Hi all, Is there anyone who used OpenBTS-UMTS http://openbts.org/w/index.php/OpenBTS-UMTS with USRPs? I want to know is there possible to run this openBTS on USRP with UHD? And if it is, what is the configuration process? Thanks in advance, Mostafa ___ Discuss-gnuradio mailing listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- *** Department of Electrical Engineering Aboureyhan Building MMWCL LAB Amirkabir University Of Technology Tehran IRAN Tel: +98 (919) 158-7730 LAB: http://ele.aut.ac.ir/~mmwcl/?page_id=411 Homepage: http://ele.aut.ac.ir/~alizadeh/ *** ___ 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] OpenBTS-UMTS
I will ask the opentBTS-UMTS mailing list. I hop to find a wag y to run the BTS on a USRP. Best On Oct 20, 2014 11:04 PM, Neel Pandeya neel.pand...@ettus.com wrote: Hello Mostafa Alizadeh: OpenBTS and OpenBTS-UMTS do not use the GNU Radio framework at all, and so you don't need to install GNU Radio in order to use them. To use OpenBTS and OpenBTS-UMTS with USRP radios, you will need to install UHD [1], which you should install before installing OpenBTS and OpenBTS-UMTS. However, I don't think there is an OpenBTS-UMTS transceiver process for USRP radios yet, and you can't substitute the OpenBTS transceiver. [1] https://github.com/EttusResearch/uhd This conversation should be continued on the openbts-discuss mailing list. --Neel On Mon, Oct 20, 2014 at 12:23 PM, Mostafa Alizadeh m.alizade...@gmail.com wrote: No, I didn't try OpenBTS mailing list, but I think this is possible to run the BTS over USRPs with some specific UHD configuration. Thank you for your hint. OpenBTS isn't even a GNURadio app. Did you try it? On Mon, Oct 20, 2014 at 3:17 PM, mle...@ripnet.com wrote: Have you tried the OpenBTS mailing lists? OpenBTS is *NOT* a Gnu Radio application, although it uses the same hardware as some Gnu Radio apps, it's not a Gnu Radio app itself. On 2014-10-20 15:15, Mostafa Alizadeh wrote: Hi all, Is there anyone who used OpenBTS-UMTS with USRPs? I want to know is there possible to run this openBTS on USRP with UHD? And if it is, what is the configuration process? Thanks in advance, Mostafa ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- *** Department of Electrical Engineering Aboureyhan Building MMWCL LAB Amirkabir University Of Technology Tehran IRAN Tel: +98 (919) 158-7730 LAB: http://ele.aut.ac.ir/~mmwcl/?page_id=411 Homepage: http://ele.aut.ac.ir/~alizadeh/ *** ___ 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] Transmitting bursts with GRC by inserting SOB and EOB
Hello Frederik, On 10/20/2014 05:53 PM, Frederik Wing wrote: Thank you Martin for your fast response! - You're using an ancient UHD version. Is there a reason you can't use a newer one? I am using Ubuntu 14.04 LTS and just pulled GNU Radio and UHD from the packet sources. There is no newer version available. And I don't like to compile myself unless it is absolutely necessary. Consider it outdated. Ubuntu's packet sources are most of the time horribly out of pace compared to GNU Radio's development process. For UHD it's the same. Note that Ettus ships its own Ubuntu packages for UHD *and* GNU Radio, so you can get a non-ancient version of both without even compiling it. By the way: GNU Radio is a software radio developer's framework. You can do great things with it without touching a compiler, but at many points it becomes helpful when one can write his own C++ block, so you definitely need to lose your fear of compilers if you want to use GNU Radio to its fullest potential :) I don't think it's because of an outdated version of UHD as the tags_demo application is working perfectly with my current version. ... Well, my old tube radio also still works ;) Martin went through some work improving the uhd blocks in GNU Radio recently. You'll greatly profit. And: seriously, please use something recent. Using an old version makes it really hard to get qualified help! Also, all the tutorials on gnuradio.org of course revolve around recent versions, so if you want to learn GNU Radio, you should learn it with a modern base. - In current GNU Radio, you can use 'length tags' to mark bursts, if that's any help. I tried using length tags by inserting an Stream to tagged Stream block and adding the length_tag_name property to the USRP Sink. Here is my sample code, now with a burst of 5 samples: The GNU Radio doxygen contains documentation for the current GNU Radio build, containing the newly available message passing functionality. Maybe that's of interest to you! Greetings, Marcus ## # Variables ## self.tx_gain = tx_gain = 15 self.samp_rate = samp_rate = 20 self.f_center = f_center = 1.47e9 self.device = device = type=usrp2 ## # Blocks ## self.usrp_sink = uhd.usrp_sink( device_addr=device, stream_args=uhd.stream_args( cpu_format=fc32, length_tag_name=packet_len, channels=range(1), ), ) self.usrp_sink.set_samp_rate(samp_rate) self.usrp_sink.set_center_freq(f_center, 0) self.usrp_sink.set_gain(tx_gain, 0) self.usrp_sink.set_antenna(TX/RX, 0) self.blocks_vector_source_x_0 = blocks.vector_source_c((1,)*5, False, 1, []) self.blocks_stream_to_tagged_stream_0 = blocks.stream_to_tagged_stream(gr.sizeof_gr_complex, 1, 5, packet_len) ## # Connections ## self.connect((self.blocks_vector_source_x_0, 0), (self.blocks_stream_to_tagged_stream_0, 0)) self.connect((self.blocks_stream_to_tagged_stream_0, 0), (self.usrp_sink, 0)) It's not working either... I can still observe the carrier at the receiver. - You'll know if your USRP hasn't acknowledged tx_eob if you see 'U's between bursts. I am getting exactly one U. Both for the code in my previous post as well as for the above one. It really seems like the USRP is not recognizing the stream tags. Any further ideas? Can someone reproduce this behaviour? Frederik ___ 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
