# Re : Discuss-gnuradio Digest, Vol 113, Issue 30 **URL:** \ **Category:** GNU Radio\ **Created:** [April 29, 2012, 5:36pm UTC](https://www.ruby-forum.com/t/re-discuss-gnuradio-digest-vol-113-issue-30/246540 "2012-04-29T17:36:27Z")\ **Posts on this page:** 1\ **Page:** 1
**Author:** ![guelord\_ingala](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/g/d07c76/32.png) [@guelord\_ingala](https://www.ruby-forum.com/u/guelord_ingala)\ **Post date:** [April 29, 2012, 5:36pm UTC](https://www.ruby-forum.com/t/re-discuss-gnuradio-digest-vol-113-issue-30/246540/1 "2012-04-29T17:36:27Z")
Message: 3 Subject: [Discuss-gnuradio] selecting the USRP antenna port in GRC I?m using an USRP-2 with a WBX daughterboard (Gnuradio 3.5.0), and I want to use the RX2 port as the receiver and the TX/RX port as the transmitter. In the GNU Radio companion flowgraph, I enter RX2 in the ?antenna?-field for the receiver UHD::USRP source block and TX/RX in the ?antenna?-field for the transmitter UHD::USRP sink block. When transmitting, I deliberately provoke underflows at the transmitter side (I transmit packets, and stop transmitting in between). When connecting a scope at the receiver end, I seem to observe that during these underflow periods, the receiver still switches back to the TX/RX port. When transmitting, it switches to the RX2 port. This is despite the fact that I specify that the receiver has to use the RX2 port, which it should use all the time. Any advice on this? Fran?ois Quitin, Ph.D Hi Francois, I will suggest you to attach the GRC flowgraph you created. It will be easier to discuss the issue. Dominique Ingala Regards. — En date de: Jeu 26.4.12, [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) a crit: De: [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Objet: Discuss-gnuradio Digest, Vol 113, Issue 30 : [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Date: Jeudi 26 avril 2012, 18h00 Send Discuss-gnuradio mailing list submissions to [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) To subscribe or unsubscribe via the World Wide Web, visit [Discuss-gnuradio Info Page](https://lists.gnu.org/mailman/listinfo/discuss-gnuradio) or, via email, send a message with subject or body ‘help’ to [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) You can reach the person managing the list at [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) When replying, please edit your Subject line so it is more specific than “Re: Contents of Discuss-gnuradio digest…” Today’s Topics: 1. Re: burst timestamps not being respected (Nowlan, Sean) 2. Re: Question about USRP2 Tx procedure (Josh B.) 3. selecting the USRP antenna port in GRC (Francois Quitin) 4. Re: Question about USRP2 Tx procedure ([removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)) 5. Re: Transmit and receive suing GMSK (wayne roberts) 6. Porting new hardware to GNURadio (Getz, Robin) 7. Re g: usrp\_fft.py (sumitstop) 8. Re: Question about USRP2 Tx procedure (Josh B.) 9. Re: Re g: usrp\_fft.py (Marcus D. Leech) 10. Re: selecting the USRP antenna port in GRC (Josh B.) 11. Re: Transmit and receive suing GMSK (Jamie Wo) 12. Re: Transmit and receive suing GMSK (Jamie Wo) 13. Re: Transmit and receive suing GMSK (Jamie Wo) 14. Re: Porting new hardware to GNURadio (Martin B.) 15. benchmark\_tx.py BPSK Signal Details (Sebastian =?iso-8859-1?Q?D=F6ring?=) 16. CMake build problem ([removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)) 17. Re: Porting new hardware to GNURadio (Getz, Robin) 18. Re: Porting new hardware to GNURadio (Johnathan C.) 19. Post-facto waterfall plots (Marcus D. Leech) 20. Re: benchmark\_tx.py BPSK Signal Details (Alick Z.) 21. Re: Porting new hardware to GNURadio (Getz, Robin) 22. Re: Transmit and receive suing GMSK (wayne roberts) 23. Re: USRP: is performance degradation of PSK OK? (Alick Z.) * * * Message: 1 Date: Wed, 25 Apr 2012 16:20:04 +0000 From: “Nowlan, Sean” [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) To: “[removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)” [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid), “[removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)” [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Cc: “[removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)” [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Subject: Re: [Discuss-gnuradio] burst timestamps not being respected Message-ID: [195933287DC65748BA7AE867BA8E430B6218B125@apatlisdmbx02](mailto:195933287DC65748BA7AE867BA8E430B6218B125@apatlisdmbx02) Content-Type: text/plain; charset=“iso-8859-1” Thanks for clarifying that. I ran a few tests and things look good. I’m glad this turned out to be an easy fix! Sean * * * From: [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [removed\_email\_address@domain.invalid] Sent: Wednesday, April 25, 2012 11:43 AM To: Nowlan, Sean Cc: [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Subject: RE: [Discuss-gnuradio] burst timestamps not being respected No. The only time you need to do that is when you reconfigure the _topology_ of a flow-graph. Parameters on individual blocks can be changed on the fly without calling lock(). Although not all parameters on all blocks can be changed on the fly, those that can be don’t require lock(). The constant on a multiply\_const definitely is changeable on the fly, and most definitely doesn’t require lock()/unlock() around it. On Wed, 25 Apr 2012 15:39:19 +0000, Nowlan, Sean wrote: It was my understanding that this was necessary before reconfiguring a flowgraph. Is that not the case? * * * From: [discuss-gnuradio-bounces+sean.nowlan=removed\_email\_address@domain.invalid](mailto:discuss-gnuradio-bounces+sean.nowlan=removed_email_address@domain.invalid) [discuss-gnuradio-bounces+sean.nowlan=removed\_email\_address@domain.invalid] on behalf of [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [removed\_email\_address@domain.invalid] Sent: Wednesday, April 25, 2012 11:34 AM To: [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Subject: Re: [Discuss-gnuradio] burst timestamps not being respected On Wed, 25 Apr 2012 15:28:09 +0000, Nowlan, Sean wrote: Hi all, \*\* Warning: this is rather a Josh question, but anyone’s comments are welcome 😛 \*\* I’m running some flowgraphs in Python that transmit timed bursts. I implemented a burst\_tagger block whose work(…) function is very similar to that of the stream tags demo in gr-uhd/examples. I also need to be able to dynamically reconfigure the transmit power, which I’m controlling with a gr\_multiply\_const\_ff block. Calling lock() → mult.set\_k(k) → unlock() does this. My biggest problem is that I’m observing that calls to lock (and/or unlock) are emptying the USRP buffer prematurely, causing a burst to be transmitted out-of-sync. I confirmed that the “tx\_time” tag has the right absolute time on it, but it’s not being respected by the USRP. At first I thought it could be a USRP problem, but then I looked at the implementation of gr\_top\_block and found that unlock() makes a call to restart(), which in turn calls stop(). The implementation of gr\_uhd\_usrp\_sink overrides the stop() method to send an end-of-burst packet to the USRP. I’m wondering if this is what’s clearing my buffer and forcing it to be transmitted without respecting the time\_spec in the metadata. I haven’t dug through UHD code but I imagine end-of-burst packets get higher priority than start-of-burst packets or time\_specs. On a sort-of related topic, I don’t like that the “tx\_eob” tag affixed by the burst tagger uses one sample; it causes an ugly spike to be transmitted. I have two thoughts - I could write 0 to this sample, or I could find a way to send a tag without a sample. I’m not sure if the latter method is even possible. I’m guessing it’s not and that I’d have to implement message passing. Respectfully, Sean Nowlan So, why are you calling lock() around setting a simple constant for a multiplier block? -------------- next part -------------- An HTML attachment was scrubbed… URL: [http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120425/5ad23d13/attachment.html](http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120425/5ad23d13/attachment.html) * * * Message: 2 Date: Wed, 25 Apr 2012 11:33:34 -0700 From: Josh B. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) To: baobaonanpo D [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Cc: [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Subject: Re: [Discuss-gnuradio] Question about USRP2 Tx procedure Message-ID: [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Content-Type: text/plain; charset=ISO-8859-1 > If so, why we use half the time, that is the time changed from 0.65s > to 0.32s when we set the bitrate from 1M to 2M? the data proceed in > PC should be fixed and unrelated to the transmission rate, and much > lower than the transmission rate, so the time processing the same > amount data which stored in gnuradio’s FIFO must be still 0.65s, is > it? If I am understanding correctly: 1. Gnuradio creates a fixed amount of buffering 2. The data source produces data faster than USRP consumes 3. The buffering in gnuradio becomes filled 100% with samples 4. The USRP consumes samples from this buffer at a fixed rate So I think it makes logical sense that when you increase sample rate (USRP consumes faster), the time to drain the buffer decreases. Also, I want to point out: There is a hook to control the size of these buffers in gnuradio (presumably to reduce flow graph latency). You may be interested in modifying this number and experimenting: void start(int max\_noutput\_items=100000); [http://gnuradio.org/cgit/gnuradio.git/tree/gnuradio-core/src/lib/runtime/gr\_top\_block.h#n63](http://gnuradio.org/cgit/gnuradio.git/tree/gnuradio-core/src/lib/runtime/gr_top_block.h#n63) -Josh * * * Message: 3 Date: Wed, 25 Apr 2012 11:38:57 -0700 From: “Francois Quitin” [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) To: [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Subject: [Discuss-gnuradio] selecting the USRP antenna port in GRC Message-ID: [006d01cd2312$ae6aa2e0$0b3fe8a0$@ac.be](mailto:006d01cd2312$ae6aa2e0$0b3fe8a0$@ac.be) Content-Type: text/plain; charset=“iso-8859-1” Dear mailing list, I have a small question: I?m using an USRP-2 with a WBX daughterboard (Gnuradio 3.5.0), and I want to use the RX2 port as the receiver and the TX/RX port as the transmitter. In the GNU Radio companion flowgraph, I enter RX2 in the ?antenna?-field for the receiver UHD::USRP source block and TX/RX in the ?antenna?-field for the transmitter UHD::USRP sink block. When transmitting, I deliberately provoke underflows at the transmitter side (I transmit packets, and stop transmitting in between). When connecting a scope at the receiver end, I seem to observe that during these underflow periods, the receiver still switches back to the TX/RX port. When transmitting, it switches to the RX2 port. This is despite the fact that I specify that the receiver has to use the RX2 port, which it should use all the time. Any advice on this? Fran?ois Quitin, Ph.D. BAEF Post-doctoral research fellow Electrical & Computer Engineering Dept. University of California Santa Barbara, CA 93106-9560 Phone: +1-805-883-8599 Email: [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Home: www.ece.ucsb.edu/~fquitin -------------- next part -------------- An HTML attachment was scrubbed… URL: [http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120425/74052629/attachment.html](http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120425/74052629/attachment.html) * * * Message: 4 Date: Wed, 25 Apr 2012 14:53:49 -0400 From: [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) To: [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Subject: Re: [Discuss-gnuradio] Question about USRP2 Tx procedure Message-ID: [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Content-Type: text/plain; charset=“utf-8” Oooh, is there a configurable parameter for that in GRC yet? On Wed, 25 Apr 2012 11:33:34 -0700, Josh B. wrote: > Also, I want to > point out: > There is a hook to control the size of these buffers in > gnuradio > (presumably to reduce flow graph latency). You may be > interested in > modifying this number and experimenting: > > void > start(int max\_noutput\_items=100000); [http://gnuradio.org/cgit/gnuradio.git/tree/gnuradio-core/src/lib/runtime/gr\_top\_block.h#n63](http://gnuradio.org/cgit/gnuradio.git/tree/gnuradio-core/src/lib/runtime/gr_top_block.h#n63) [1] > -Josh ## Links: [1] [http://gnuradio.org/cgit/gnuradio.git/tree/gnuradio-core/src/lib/runtime/gr\_top\_block.h#n63](http://gnuradio.org/cgit/gnuradio.git/tree/gnuradio-core/src/lib/runtime/gr_top_block.h#n63) -------------- next part -------------- An HTML attachment was scrubbed… URL: [http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120425/234b6b34/attachment.html](http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120425/234b6b34/attachment.html) * * * Message: 5 Date: Wed, 25 Apr 2012 12:12:54 -0700 From: wayne roberts [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) To: Jamie Wo [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Cc: [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Subject: Re: [Discuss-gnuradio] Transmit and receive suing GMSK Message-ID: [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Content-Type: text/plain; charset=“iso-8859-1” I was messing with the same thing myself. First off, i’m not sure the packet decoder outputs in a real-time fashion to drive an audio sink. Try a scope sink to see how often the packet decoder output updates: is there a better way? On the GMSK demodulator side, I would think its best to observe the signal going into the demodulator, from uhd rx source. To see it in time domain, you can use Quadrature Demod → throttle → scope sink, making sure signal is centered at 0 and is reasonable distortion free. To be sure what its supposed to look like, you can put on the transmitter side Quadrature Demod → throttle → scope sink on the output of GMSK modulator. And of course you can put an FFT sink right on the UHD source to see it in frequency domain. On the transmitter side, to UHD sink, I have found the GMSK modulator outputs signal level near the maximum, meaning some transient peaks could cause clipping on USRP transmitter, so it might be prudent to put a multiply const (with 0.99 or so) just before going to UHD sink. On Wed, Apr 25, 2012 at 1:41 AM, Jamie Wo [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > Data in file source can be received by the receiver. However, I am not > the data may be correctly received. However, after I tried this, the sound > To do what I want, is there any other blocks that need to be added in the > [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) > [Discuss-gnuradio Info Page](https://lists.gnu.org/mailman/listinfo/discuss-gnuradio) -------------- next part -------------- An HTML attachment was scrubbed… URL: [http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120425/eecaeb44/attachment.html](http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120425/eecaeb44/attachment.html) * * * Message: 6 Date: Wed, 25 Apr 2012 17:37:16 -0400 From: “Getz, Robin” [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) To: [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Cc: “Hennerich, Michael” [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Subject: [Discuss-gnuradio] Porting new hardware to GNURadio Message-ID: [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Content-Type: text/plain; charset=“us-ascii” Hi. Sorry for what might appear as a commercial at first - but I do have some real questions at the end - I’ll try to the description short. ## We have developed a new RF learning platform [1] on a standard FMC card [2] (meets the electrical requirements, not the mechanical - it’s too long) which can connect to nearly any recent Xilinx development system, that we started showing at X-Fest[3] yesterday. The advantage of this, vs some existing platforms is bandwidth. The DAC is a 16-Bit, 1200 MSPS (limited on this platform to 1GSPS, due to the clock chip we used), and the ADC is 14-Bit, 250 MSPS. The RF side includes a 400 MHz to 6 GHz Quadrature Modulator/Demodulator, separate Tx and Rx LO Synthesisers (35MHz to 4400MHz), and fixed gain on the Tx side, and a Variable Gain on the Rx Side. It’s clocking can handle multiple boards attached to the same FPGA (for MIMO), and can sync to a 1 pps (from GPS, or IEEE 1588) to sync many, many, many boards together. The demo we are showing at X-Fest is the FMComms board, attached to a Xilinx ML605 FPGA, which runs Linux on Microblaze - playing a tone (Xilinx DDS) out the DAC, modulating that up to 2.4 GHz, sending it out the antenna, receiving it on the same board, demodulating it (at 2.4GHz), passing it through the VGA, to the ADC, were we capture the samples (into DDR), passing the data to GNU plot to create a png, and then passing the png to a web server, so it can be displayed on an external client across the network. We have ported this to the Series 7 platforms - KC705, and others, and are in process finishing the port to Zynq[4] - for the standard Xilinx ZC702 platform [5] and the newly announced Zed[6]. This (I think) is where things get a little interesting. Microblaze running Linux is a little pokey - Zynq on the otherhand - is a dual ARM Cortex A9, running at 800MHz each, plus FPGA fabric - which allows some serious horsepower. This is a kit (Zynq+FMComms) that Avnet plans on selling [7]. Which brings me to the question: We already have Linux IIO drivers[8] for all the parts on the board (including the ADCs[9] and DACs[10]), and are just trying to determine how (if at all) this fits within the GNU Radio framework. When I looked at things (which wasn’t very long) - I didn’t see much in terms of native / real time connections to a platform which was running Linux (PCIe, other other bus). Did I miss something? Thanks in advance -Robin Just to be fair - others have done the same type of FMC Card [11] - the advantage we have is gobs of channel bandwidth - enough to sample all of bluetooth without doing any hopping at all. [1] [http://wiki.analog.com/resources/fpga/xilinx/fmc/ad-fmcomms1-ebz](http://wiki.analog.com/resources/fpga/xilinx/fmc/ad-fmcomms1-ebz) [2] [http://www.vita.com/fmc.html](http://www.vita.com/fmc.html) [3] [https://www.weboom.com/avnet2012/](https://www.weboom.com/avnet2012/) [4] [Zynq 7000 SoCs](http://www.xilinx.com/products/silicon-devices/epp/zynq-7000/index.htm) [5] [Evaluation Boards](http://www.xilinx.com/products/boards-and-kits/EK-Z7-ZC702-G.htm) [6] [http://www.zedboard.org/](http://www.zedboard.org/) [7] [Challenge Validation](http://www.em.avnet.com/en-us/design/drc/Pages/Analog-Devices-Zynq-Software-Defined-Radio-Kit.aspx) [8] [Linux Industrial I/O Subsystem [Analog Devices Wiki]](http://wiki.analog.com/software/linux/docs/iio/iio) [9] [https://github.com/mhennerich/linux/blob/fa8fc592243c82c0ddaa43f51be10e2123e1fa9b/drivers/staging/iio/adc/cf\_ad9467\_core.c](https://github.com/mhennerich/linux/blob/fa8fc592243c82c0ddaa43f51be10e2123e1fa9b/drivers/staging/iio/adc/cf_ad9467_core.c) [10] [https://github.com/mhennerich/linux/blob/fa8fc592243c82c0ddaa43f51be10e2123e1fa9b/drivers/staging/iio/frequency/ad9122.c](https://github.com/mhennerich/linux/blob/fa8fc592243c82c0ddaa43f51be10e2123e1fa9b/drivers/staging/iio/frequency/ad9122.c) [11] [http://www.4dsp.com/FMC30RF.php](http://www.4dsp.com/FMC30RF.php) * * * Message: 7 Date: Wed, 25 Apr 2012 15:28:51 -0700 (PDT) From: sumitstop [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) To: [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Subject: [Discuss-gnuradio] Re g: usrp\_fft.py Message-ID: [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Content-Type: text/plain; charset=us-ascii While running usrp\_fft.py in gnuradio 3.4.0 I am getting the following error. I installed in many system but only in single system this error is coming. Any clue 🙂 oalec@ubuntu:/usr/local/bin$ ./usrp\_fft.py -h Traceback (most recent call last): File “./usrp\_fft.py”, line 27, in from gnuradio.wxgui import stdgui2, fftsink2, waterfallsink2, scopesink2, form, slider File “/usr/local/lib/python2.6/dist-packages/gnuradio/wxgui/fftsink2.py”, line 31, in from fftsink\_gl import fft\_sink\_f, fft\_sink\_c File “/usr/local/lib/python2.6/dist-packages/gnuradio/wxgui/fftsink\_gl.py”, line 27, in import fft\_window File “/usr/local/lib/python2.6/dist-packages/gnuradio/wxgui/fft\_window.py”, line 33, in import forms File “/usr/local/lib/python2.6/dist-packages/gnuradio/wxgui/forms/ **init**.py”, line 29, in from converters import File “/usr/local/lib/python2.6/dist-packages/gnuradio/wxgui/forms/converters.py”, line 118, in class float\_converter(abstract\_converter): File “/usr/local/lib/python2.6/dist-packages/gnuradio/wxgui/forms/converters.py”, line 119, in float\_converter def **init** (self, formatter=eng\_notation.num\_to\_str): AttributeError: ‘module’ object has no attribute ‘num\_to\_str’ * * * ## Sumit Kr. Research Assistant Communication Research center IIIT Hyderabad India View this message in context: [http://old.nabble.com/Reg%3A-usrp\_fft.py-tp33750042p33750042.html](http://old.nabble.com/Reg%3A-usrp_fft.py-tp33750042p33750042.html) Sent from the GnuRadio mailing list archive at [Nabble.com](http://Nabble.com). * * * Message: 8 Date: Wed, 25 Apr 2012 15:29:20 -0700 From: Josh B. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) To: [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Subject: Re: [Discuss-gnuradio] Question about USRP2 Tx procedure Message-ID: [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Content-Type: text/plain; charset=ISO-8859-1 On 04/25/2012 11:53 AM, [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > Oooh, is there a configurable parameter for that in GRC yet? Not yet. It would fit well in the options block. Pretty easy to add, but it would be a little more change to get the parameter into the WX gui top block class. Qtgui and nogui mode both directly call the flow graph start/run method, so the code change is purely in the generator. -josh > > > > * * * > > [1] [http://gnuradio.org/cgit/gnuradio.git/tree/gnuradio-core/src/lib/runtime/gr\_top\_block.h#n63](http://gnuradio.org/cgit/gnuradio.git/tree/gnuradio-core/src/lib/runtime/gr_top_block.h#n63) > * * * > > Discuss-gnuradio mailing list > [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) > [Discuss-gnuradio Info Page](https://lists.gnu.org/mailman/listinfo/discuss-gnuradio) * * * Message: 9 Date: Wed, 25 Apr 2012 18:42:15 -0400 From: “Marcus D. Leech” [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) To: [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Subject: Re: [Discuss-gnuradio] Re g: usrp\_fft.py Message-ID: [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Content-Type: text/plain; charset=ISO-8859-1; format=flowed On 04/25/2012 06:28 PM, sumitstop wrote: > scopesink2, form, slider > import forms > line 119, in float\_converter > def **init** (self, formatter=eng\_notation.num\_to\_str): > AttributeError: ‘module’ object has no attribute ‘num\_to\_str’ > > * * * > > Sumit Kr. > Research Assistant > Communication Research center > IIIT Hyderabad > India > Well, if there is a bug, that version of Gnu Radio is no longer > fashionable, and more particularly, the entire “USRP classic” API has > been > deprecated, for a long time. In “modern” Gnu Radio, you use the UHD API to talk to Ettus’ hardware, and the corresponding application is uhd\_fft.py – Marcus L. Principal Investigator Shirleys Bay Radio Astronomy Consortium > **[Live Draw HK Tercepat | Result HK | HK Pools | Live HK | HK Prize Hari Ini](https://www.sbrac.org/)** > > Temukan live draw hk tercepat melalui halaman hk pools yang resmi dan dapatkan result hk prize melalui live hk secara langsung di situs kami. * * * Message: 10 Date: Wed, 25 Apr 2012 16:08:16 -0700 From: Josh B. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) To: [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Subject: Re: [Discuss-gnuradio] selecting the USRP antenna port in GRC Message-ID: [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Content-Type: text/plain; charset=ISO-8859-1 > Any advice on this? This seems to be the opposite behaviour of what I would expect. From the description above, I would guess that the source block has the antenna set to TX/RX. When you transmit, the receive antenna is forced to RX2. When not transmitting, the receive antenna is . [http://files.ettus.com/uhd\_docs/manual/html/dboards.html#wbx-series](http://files.ettus.com/uhd_docs/manual/html/dboards.html#wbx-series) You can confirm the behaviour with a test signal on RX2 and calling uhd\_fft -A RX2. uhd\_fft -A TX/RX should show only leakage -josh * * * Message: 11 Date: Thu, 26 Apr 2012 14:08:24 +1000 From: Jamie Wo [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) To: wayne roberts [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Cc: [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Subject: Re: [Discuss-gnuradio] Transmit and receive suing GMSK Message-ID: [CABS7YrgM35rH-V57WX6cekkFEUDYQEtYhe=pOm9YoVr=removed\_email\_address@domain.invalid](mailto:CABS7YrgM35rH-V57WX6cekkFEUDYQEtYhe=pOm9YoVr=removed_email_address@domain.invalid) Content-Type: text/plain; charset=“iso-8859-1” On Thu, Apr 26, 2012 at 5:12 AM, wayne roberts [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)wrote: Hi Wayne, Thanks for your reply. My responses are: > I was messing with the same thing myself. > > First off, i’m not sure the packet decoder outputs in a real-time fashion > to drive an audio sink. Try a scope sink to see how often the packet > decoder output updates: is there a better way? I am not sure the real-time fashion to drive an audio sink either, but there should be a way to support it, I guess. I ran the flow graph and saw the update time interval from a scope sink is 3 - 5s . Is this too long? Do you know what does this update time mean? On the GMSK demodulator side, I would think its best to observe the signal > prudent to put a multiply const (with 0.99 or so) just before going to UHD > sink. I used Quadrature Demod → throttle → scope sink on the receiver side to see the signal going into the GSMK demod after uhd source. Also I used Quadrature Demod → throttle → scope sink after the output of GMSK mod. The time and frequency domain outputs are attached. Theoretically, these two output should be similar or the same, However, they are quite different after travelling over the air. Can you see any problems from the figures? Thanks, Jamie > > The receiver side: UHD source → GMSK Demod → Packet decoder → File > > The receiver side: UHD source → GMSK Demod → Packet decoder → Audio > > decoder → audio sink.(samp\_rate 48K), it works very well. > > > > Jamie > > > > * * * > > > > Discuss-gnuradio mailing list > > [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) > > [Discuss-gnuradio Info Page](https://lists.gnu.org/mailman/listinfo/discuss-gnuradio) -------------- next part -------------- An HTML attachment was scrubbed… URL: [http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120426/22c86d42/attachment.html](http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120426/22c86d42/attachment.html) -------------- next part -------------- A non-text attachment was scrubbed… Name: Transmit\_frequency.png Type: image/png Size: 15836 bytes Desc: not available URL: [http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120426/22c86d42/attachment.png](http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120426/22c86d42/attachment.png) -------------- next part -------------- A non-text attachment was scrubbed… Name: Tramsmit\_time.png Type: image/png Size: 14351 bytes Desc: not available URL: [http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120426/22c86d42/attachment-0001.png](http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120426/22c86d42/attachment-0001.png) -------------- next part -------------- A non-text attachment was scrubbed… Name: Receiver\_time.png Type: image/png Size: 15332 bytes Desc: not available URL: [http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120426/22c86d42/attachment-0002.png](http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120426/22c86d42/attachment-0002.png) -------------- next part -------------- A non-text attachment was scrubbed… Name: Receiver\_frequency.png Type: image/png Size: 15574 bytes Desc: not available URL: [http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120426/22c86d42/attachment-0003.png](http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120426/22c86d42/attachment-0003.png) * * * Message: 12 Date: Thu, 26 Apr 2012 14:18:08 +1000 From: Jamie Wo [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) To: Huzaifa Zafar [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Cc: [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Subject: Re: [Discuss-gnuradio] Transmit and receive suing GMSK Message-ID: [CABS7YrhgoaoEB7VEMa4fu=removed\_email\_address@domain.invalid](mailto:CABS7YrhgoaoEB7VEMa4fu=removed_email_address@domain.invalid) Content-Type: text/plain; charset=“iso-8859-1” Hi Huzaifa, I increased the sampling rate, but the problem is still there. Can you give me some details on what you have done to solve this problem? Thanks! Jamie On Thu, Apr 26, 2012 at 12:05 AM, Huzaifa Zafar [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)wrote: > > The transmit side: File source → Packet encoder → GMSK Mod → UHD > > The transmit side: Wav source → Packet encoder → GMSK Mod → UHD > > this: > > – > Huzaifa Zafar -------------- next part -------------- An HTML attachment was scrubbed… URL: [http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120426/af63d0cb/attachment.html](http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120426/af63d0cb/attachment.html) * * * Message: 13 Date: Thu, 26 Apr 2012 14:32:47 +1000 From: Jamie Wo [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) To: Javier S. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Cc: [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Subject: Re: [Discuss-gnuradio] Transmit and receive suing GMSK Message-ID: [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Content-Type: text/plain; charset=“iso-8859-1” Hi Javier, The sample rate of the UHD is 240KHz (uhd source and sink), the samples/symbol is 2(Packet encoder and Decode) and the bits/symbol is 1(Packet Encoder). Other parameters are set by default. The sample of the audio sink is 48KHz as the wav file is sampled at 48Khz. So I added rational resampler on both sides. I also tired to set the sample rate at 48Khz without changing it during the process. Any ideas? Thanks, Jamie My parameters setting On Thu, Apr 26, 2012 at 12:06 AM, Javier S. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > -------------- next part -------------- An HTML attachment was scrubbed… URL: [http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120426/6a14574d/attachment.html](http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120426/6a14574d/attachment.html) * * * Message: 14 Date: Thu, 26 Apr 2012 09:19:20 +0200 From: Martin B. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) To: [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Subject: Re: [Discuss-gnuradio] Porting new hardware to GNURadio Message-ID: [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Content-Type: text/plain; charset=“utf-8” On Wed, Apr 25, 2012 at 05:37:16PM -0400, Getz, Robin wrote: > Which brings me to the question: > > We already have Linux IIO drivers[8] for all the parts on the board (including > the ADCs[9] and DACs[10]), and are just trying to determine how (if at all) > this fits within the GNU Radio framework. Hi Robin, if you have the drivers, it should be a cakewalk to add sink/source blocks. > When I looked at things (which wasn’t very long) - I didn’t see much in terms > of native / real time connections to a platform which was running Linux > (PCIe, other other bus). Did I miss something? What exactly do you mean? The standard GNU Radio source comes with (real time capable) drivers for all the Ettus stuff (via UHD), Funcube Dongle, soundcards and more (see also [http://gnuradio.org/redmine/projects/gnuradio/wiki/Hardware](http://gnuradio.org/redmine/projects/gnuradio/wiki/Hardware)), plus there’s 3rd-party stuff like Balint’s drivers for RTL2832 TV tuners available on the webs. These things connect to the PC via USB or GigE. I’m not sure if that’s what you were looking for, though. MB – Karlsruhe Institute of Technology (KIT) Communications Engineering Lab (CEL) Dipl.-Ing. Martin B. Research Associate Kaiserstra?e 12 Building 05.01 76131 Karlsruhe Phone: +49 721 608-43790 Fax: +49 721 608-46071 www.cel.kit.edu KIT – University of the State of Baden-W?rttemberg and National Laboratory of the Helmholtz Association -------------- next part -------------- A non-text attachment was scrubbed… Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: [http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120426/b6aa70fe/attachment.pgp](http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120426/b6aa70fe/attachment.pgp) * * * Message: 15 Date: Thu, 26 Apr 2012 10:05:41 +0200 From: “Sebastian =?iso-8859-1?Q?D=F6ring?=” [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) To: [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Subject: [Discuss-gnuradio] benchmark\_tx.py BPSK Signal Details Message-ID: [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Content-Type: text/plain;charset=iso-8859-1; format=“flowed” Hello all, I want to know how I could possibly find out the complete details about the BPSK-Signal generated by the benchmark\_tx.py GNU Radio script. Should I look at the code and at which file respectively? Thanks in advance. -Sebastian- * * * Message: 16 Date: Thu, 26 Apr 2012 12:30:51 +0100 From: [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) To: [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Subject: [Discuss-gnuradio] CMake build problem Message-ID: [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Content-Type: text/plain; charset=us-ascii Hi, I’m running debian unstable on a AMD64 platform and am running into a problem which starts right at the top of the build process for a newly checkout gnuradio version from git. Below is output from running cmake: [snip] – Performing Test HAVE\_WARN\_ALL – Performing Test HAVE\_WARN\_ALL - Success – Performing Test HAVE\_WARN\_NO\_UNINITIALIZED – Performing Test HAVE\_WARN\_NO\_UNINITIALIZED - Success – Found PythonLibs: optimized;/usr/lib/python3.2/config/libpython3.2.so;debug;/usr/lib/python3.2/config/libpython3.2.so (found version “2.7.3rc2”) – Found SWIG: /usr/bin/swig2.0 (found version “2.0.4”) [snip] So it found that /usr/bin/python is version 2.7.3rc2, but it decides to use version 3.2 to link against. This makes the build process rather sad later on! (Lots of link failures) To get around this I changed in CMakeLists.txt find\_package(PythonLibs) to be find\_package(PythonLibs 2.7.3) But obviously that’ll only work for people running 2.7.3! (I’ve not played with cmake before now, so there might be a simple way to fix it) I’m running cmake version 2.8.7. However the build process goes further this time, but now breaks with: [49%] Built target \_runtime\_swig\_doc\_tag [49%] Generating doxygen xml for runtime\_swig\_doc docs [49%] Generating runtime\_swig\_doc.i [49%] Generating doxygen xml for general\_swig\_doc docs [49%] Generating general\_swig\_doc.i [49%] Generating doxygen xml for gengen\_swig\_doc docs [49%] Generating gengen\_swig\_doc.i XML parsing problem with file /home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen\_swig\_doc.i, retrying. XML parsing problem with file /home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen\_swig\_doc.i, retrying. XML parsing problem with file /home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen\_swig\_doc.i, retrying. XML parsing error with file /home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen\_swig\_doc.i. giving up. XML parsing problem with file /home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen\_swig\_doc.i, retrying. XML parsing problem with file /home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen\_swig\_doc.i, retrying. XML parsing problem with file /home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen\_swig\_doc.i, retrying. XML parsing problem with file /home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen\_swig\_doc.i, retrying. XML parsing error with file /home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen\_swig\_doc.i. giving up. XML parsing problem with file /home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen\_swig\_doc.i, retrying. XML parsing problem with file /home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen\_swig\_doc.i, retrying. XML parsing problem with file /home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen\_swig\_doc.i, retrying. XML parsing problem with file /home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen\_swig\_doc.i, retrying. XML parsing error with file /home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen\_swig\_doc.i. giving up. XML parsing problem with file /home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen\_swig\_doc.i, retrying. XML parsing problem with file /home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen\_swig\_doc.i, retrying. XML parsing problem with file /home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen\_swig\_doc.i, retrying. XML parsing problem with file /home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen\_swig\_doc.i, retrying. XML parsing error with file /home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen\_swig\_doc.i. giving up. XML parsing error with file /home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen\_swig\_doc.i. giving up. Traceback (most recent call last): File “/home/matt/gnuradio/docs/doxygen/swig\_doc.py”, line 294, in make\_swig\_interface\_file(di, swigdocfilename, custom\_output=custom\_output) File “/home/matt/gnuradio/docs/doxygen/swig\_doc.py”, line 222, in make\_swig\_interface\_file make\_func = di.get\_member(make\_name(block.name()), DoxyFunction) File “/home/matt/gnuradio/docs/doxygen/doxyxml/base.py”, line 157, in get\_member raise member() doxyxml.base.Duplicate make[2]: \*\*\* [gnuradio-core/src/lib/swig/gengen\_swig\_doc.i] Error 1 make[1]: \*\*\* [gnuradio-core/src/lib/swig/CMakeFiles/\_gnuradio\_core\_filter.dir/all] Error 2 make: \*\*\* [all] Error 2 Which I don’t know where to start to fix! However I can tell you that the file its looking for, /home/…/swig/gengen\_swig\_doc.i doesn’t exist, but I don’t know what should have created it. Thanks, Matt * * * Message: 17 Date: Thu, 26 Apr 2012 10:38:20 -0400 From: “Getz, Robin” [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) To: [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Cc: “Hennerich, Michael” [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Subject: Re: [Discuss-gnuradio] Porting new hardware to GNURadio Message-ID: [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Content-Type: text/plain; charset=“utf-8” On Thu 26 Apr 2012 03:19, Martin B. pondered: > blocks. > Are there pointers for doing that? > Looks like: > [http://gnuradio.org/redmine/projects/gnuradio/wiki/BlocksCodingGuide](http://gnuradio.org/redmine/projects/gnuradio/wiki/BlocksCodingGuide) > ? > Is there a “golden” reference to look at? (I assume > gr-howto-write-a-block-3.6.0.tar.gz > should have everything we need?) > > When I looked at things (which wasn’t very long) - I didn’t see much in > > terms of native / real time connections to a platform which was running > > Linux (PCIe, other other bus). Did I miss something? > > What exactly do you mean? The standard GNU Radio source comes with (real > time capable) drivers for all the Ettus stuff (via UHD), Funcube Dongle, > soundcards and more (see also > [http://gnuradio.org/redmine/projects/gnuradio/wiki/Hardware](http://gnuradio.org/redmine/projects/gnuradio/wiki/Hardware)), Yeah, that’s what I was missing. If it supports Comedi - it should support IIO without many issues. SLOC Directory SLOC-by-Language (Sorted) 387 gr-comedi cpp=376,python=11 If that’s all that’s necessary - it shouldn’t take much time at all… > plus there’s > 3rd-party stuff like Balint’s drivers for RTL2832 TV tuners available on > the webs. These things connect to the PC via USB or GigE. > > I’m not sure if that’s what you were looking for, though. Close - although it appears we need to extend our FSF copyright assignments before we get too busy. Thanks -Robin * * * Message: 18 Date: Thu, 26 Apr 2012 07:58:01 -0700 From: Johnathan C. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) To: “Getz, Robin” [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Cc: “Hennerich, Michael” [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid), [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Subject: Re: [Discuss-gnuradio] Porting new hardware to GNURadio Message-ID: [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Content-Type: text/plain; charset=ISO-8859-1 On Thu, Apr 26, 2012 at 07:38, Getz, Robin [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > Is there a “golden” reference to look at? (I assume > gr-howto-write-a-block-3.6.0.tar.gz > should have everything we need?) This will give you the “canonical” format for writing your own out-of-tree installable GNU Radio blocks. A hardware source block would have no input ports, one or more output ports for whatever streams your device generates, and a work function that wraps calls to your existing sample-based I/O library for your device. The main purpose of the work function would be to retrieve samples from the device and put them into the block output buffer, and some housekeeping to tell the GNU Radio runtime what you’ve done. You’d also need write any needed setter/getter functions to perform configuration of your source block either at initialization or during runtime. > …although it appears we need to extend our FSF copyright assignments > before we get too busy. This isn’t needed to develop your own distributed GNU Radio blocks; you only need comply with the GPLv3 license terms of GNU Radio. Johnathan * * * Message: 19 Date: Thu, 26 Apr 2012 10:58:23 -0400 From: “Marcus D. Leech” [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) To: “[removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)” [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Subject: [Discuss-gnuradio] Post-facto waterfall plots Message-ID: [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Does anyone have any gnuplot scripts or Octave macros for producing a waterfall plot from pre-recorded complex-float data? – Marcus L. Principal Investigator Shirleys Bay Radio Astronomy Consortium > **[Live Draw HK Tercepat | Result HK | HK Pools | Live HK | HK Prize Hari Ini](https://www.sbrac.org/)** > > Temukan live draw hk tercepat melalui halaman hk pools yang resmi dan dapatkan result hk prize melalui live hk secara langsung di situs kami. * * * Message: 20 Date: Thu, 26 Apr 2012 23:04:01 +0800 From: Alick Z. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) To: [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Subject: Re: [Discuss-gnuradio] benchmark\_tx.py BPSK Signal Details Message-ID: [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Content-Type: text/plain; charset=UTF-8 On Thu, 26 Apr 2012 10:05:41 +0200, Sebastian D?ring wrote: > Hello all, > > I want to know how I could possibly find out the complete details about > the BPSK-Signal generated by the benchmark\_tx.py GNU Radio script. > Should I look at the code and at which file respectively? > > Thanks in advance. > > -Sebastian- I assume you are talking about the benchmark\_tx.py under narrowband/ directory. With my (limited) experience with it, I can tell that it depends on code in transmit\_path.py under the same directory. The packets related function can be found at gr-digital/python/{pkt.py and packet\_utils.py}. As with the modulation, it utilizes the code in gr-digital/python/generic\_mod\_demod.py. So have a look at these files you will get some more information about how the blocks are connected. When you want to know the implementation/algorithm of blocks, you will need to look into the C++ code (under lib/ and include/ directory). Besides, the benchmark\_tx.py script has a option ‘–log’, which can be used to dump the output data of some blocks into files. You can then use Octave/Matlab to read these data files and play with them(by plotting, etc). To read the data files into Octave vectors you can use functions described here.[1] [1] [http://gnuradio.org/redmine/projects/gnuradio/wiki/Octave](http://gnuradio.org/redmine/projects/gnuradio/wiki/Octave) – alick Fedora 16 (Verne) user > **[User:Alick - Fedora Project Wiki](https://fedoraproject.org/wiki/User:Alick)** * * * Message: 21 Date: Thu, 26 Apr 2012 11:31:40 -0400 From: “Getz, Robin” [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) To: Johnathan C. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Cc: “Hennerich, Michael” [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid), “[removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)” [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Subject: Re: [Discuss-gnuradio] Porting new hardware to GNURadio Message-ID: [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Content-Type: text/plain; charset=“iso-8859-1” On Thu 26 Apr 2012 10:58, Johnathan C. pondered: > On Thu, Apr 26, 2012 at 07:38, Getz, Robin [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > > > Is there a “golden” reference to look at? (I assume > > gr-howto-write-a-block-3.6.0.tar.gz > > should have everything we need?) > > This will give you the “canonical” format for writing your own > out-of-tree installable GNU Radio blocks. And what is preferred? I always think in-tree is better - but that’s just me. > A hardware source block would have no input ports, one or more output > ports for whatever streams your device generates, and a work function > that wraps calls to your existing sample-based I/O library for your > device. The main purpose of the work function would be to retrieve > samples from the device and put them into the block output buffer, and > some housekeeping to tell the GNU Radio runtime what you’ve done. What is the widest band device (MSPS) that GNURadio can keep up with in real time? With this card - we are limited in memory bandwidth (vs a desktop), and Cortex A9 isn’t bad - but it’s no Intel CPU in terms of floating point performance… Who actually manages the location of the buffer? If GNURadio mmaps the location (rather than malloc), it will save a memcpy in the work function. What’s the format that GNURadio wants (16-bit fixed? float? other?) We can make the format converter in the HDL, to decrease the load on the processor. > You’d also need write any needed setter/getter functions to perform > configuration of your source block either at initialization or during > runtime. There are lots of potential settings (Tx/Rx modulator frequencies, ADC/DAC sample rates, sync, MIMO config, etc) - I’m assuming some of those configuration knobs are exposed to the python interface in a standard manner across hardware? > > …although it appears we need to extend our FSF copyright assignments > > before we get too busy. > > This isn’t needed to develop your own distributed GNU Radio blocks; > you only need comply with the GPLv3 license terms of GNU Radio. Right - but I would think that it would be better to have things in tree? With all the FSF packages that we have contributed to in the past (gcc, binutils, gdb, etc) without a FSF copyright assignment - the package maintainer would not accept patches. I believe that is what is indicated here: [http://gnuradio.org/redmine/projects/gnuradio/wiki/Development#Whats-this-Copyright-Assignment](http://gnuradio.org/redmine/projects/gnuradio/wiki/Development#Whats-this-Copyright-Assignment) Thanks -Robin * * * Message: 22 Date: Thu, 26 Apr 2012 08:48:29 -0700 From: wayne roberts [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) To: Jamie Wo [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Cc: [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Subject: Re: [Discuss-gnuradio] Transmit and receive suing GMSK Message-ID: [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Content-Type: text/plain; charset=“iso-8859-1” You should use FFT sink with complex input, so its direct from uhd source with only throttle in between. But the FFT you attached seems to indicate you have no signal into the receiver. Make sure they’re on the same RF frequency, and adjust gains appropriate for the path loss between transmitter and receiver. I am sure the packet encoder/decoder has some overhead, because its adding preamble, access\_code, and crc. It means the thruput should be less than your actual over-the-air bitrate. If you are sending audio, then you might be better served by one of the audio encoders, such as the stuff under Vocoders category. On Wed, Apr 25, 2012 at 9:08 PM, Jamie Wo [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > > I was messing with the same thing myself. > > Do you know what does this update time mean? > > in frequency domain. On the transmitter side, to UHD sink, I have found > > these two output should be similar or the same, However, they are quite > > > > > Data in file source can be received by the receiver. However, I am not > > > I think if the sound received on the receiver is the same as the wav > > > test how to receive correctly right? > > > > > > * * * > > > > > > Discuss-gnuradio mailing list > > > [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) > > > [Discuss-gnuradio Info Page](https://lists.gnu.org/mailman/listinfo/discuss-gnuradio) -------------- next part -------------- An HTML attachment was scrubbed… URL: [http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120426/33c21263/attachment.html](http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120426/33c21263/attachment.html) * * * Message: 23 Date: Thu, 26 Apr 2012 23:52:19 +0800 From: Alick Z. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Cc: [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Subject: Re: [Discuss-gnuradio] USRP: is performance degradation of PSK OK? Message-ID: [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Content-Type: text/plain; charset=UTF-8 On Wed, 25 Apr 2012 12:01:33 +0800, Alick Z. wrote: > > bounds and being handled appropriately. Verify that clock recovery is > > keeping a lock on the incoming data. > > > > –n I also make some plots with the logged data. I can see that consecutive 1000 points of data after freq\_recov or time\_recov are distributed around the unit circle. I think the freq/time recovery may not work well. Given static indoor environment, the coherence time should be long. I’d expect that the constellation points after timing recovery should stay around two certain points for some thousands of samples. Is it so? If the problem is with the recovery loop, I wonder how I can adjust the parameters of the loop. I have read Tom’s post about loop gain values[1]. It seems that damping factor (0.707) should not be changed, and loop bw is somewhere around pi/100 to 2\*pi/100. So I find little change can be done. By plotting data directly output by usrp source I find that the constellation points are disperse too. But I think it is due to lack of synchronization between tx/rx. Am I wrong about this? [1] [Control Loop Gain Values — Rondeau Research](http://www.trondeau.com/blog/2011/8/13/control-loop-gain-values.html) – alick Fedora 16 (Verne) user > **[User:Alick - Fedora Project Wiki](https://fedoraproject.org/wiki/User:Alick)** * * * * * * Discuss-gnuradio mailing list [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) > **[Discuss-gnuradio Info Page](https://lists.gnu.org/mailman/listinfo/discuss-gnuradio)** End of Discuss-gnuradio Digest, Vol 113, Issue 30 * * *