hello everyone ,I want to use the fm_tx_2_daughters.py as a template to realize my own module ,so I copy it to my own folder. but when I set the interpolate to 64 and test the copy module ,"uU" appears.then I run the usrp_benchmark_usb.py,the result shows "Max USB/USRP throughput = 32MB/sec".I wonder the "uU" appears thanks forward<br><br>在2010-05-27 00:00:43，[email protected] 写道： >Send Discuss-gnuradio mailing list submissions to > [email protected] > >To subscribe or unsubscribe via the World Wide Web, visit > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio >or, via email, send a message with subject or body 'help' to > [email protected] > >You can reach the person managing the list at > [email protected] > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of Discuss-gnuradio digest..." > > >Today's Topics: > > 1. Re: Carrier leakage on transmit (Matt Ettus) > 2. Re: 802.15.4 how to forward a parameter to a c++ block > (George Nychis) > 3. Re: Carrier leakage on transmit (Matt Ettus) > 4. Re: Ethernet and bursting (Matt Ettus) > 5. Re: new inband plan? message passing? (Matt Ettus) > 6. RFX-900/1800 very low Tx power in 1800Mhz band (Uri Savoray) > 7. About tunnel.py again (Juan Quiroz) > 8. Re: About tunnel.py again (Eric Blossom) > 9. Re: tvrx and usrp_tv_rcv (Muhammad Najib) > 10. Re: 802.15.4 how to forward a parameter to a c++ block > ([email protected]) > 11. USRP1 Simulatenous Receive and Transmit (Jim V) > 12. USRP1 Simultaneous Receive and Transmit (Jim V) > 13. Re: Hi all, how to use usrp and gnuradio support > triangulation to locate a cell phone (John Wu) > 14. 802.15.4 how to forward a parameter to a c++ block > ([email protected]) > 15. Re: 802.15.4 how to forward a parameter to a c++ block > (Markus Becker) > 16. Re: 802.15.4 how to forward a parameter to a c++ block > ([email protected]) > 17. Wimax (Mohammad Hosein) > 18. Re: About tunnel.py (Jim V) > 19. gcellized FFTW has broken gcell block (matty) > 20. Re: USRP1 Simultaneous Receive and Transmit (Matt Ettus) > 21. Re: 802.15.4 how to forward a parameter to a c++ block (Josh Blum) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Tue, 25 May 2010 09:03:37 -0700 >From: Matt Ettus <[email protected]> >Subject: Re: [Discuss-gnuradio] Carrier leakage on transmit >To: Charles Brain <[email protected]> >Cc: [email protected] >Message-ID: <[email protected]> >Content-Type: text/plain; charset=ISO-8859-1; format=flowed > >On 05/25/2010 03:17 AM, Charles Brain wrote: >> Hi, >> >> Is there any way of calibrating out or mitigating the carrier at the WBX >> tx frequency? I am sending >> a wideband signal and the carrier (which I assume is due to dc coupling >> in the WBX) is at a significant level compared to my signal. > > >What Johnathan describes is a way of hiding the DC offset by moving it >outside your passband. The proper thing to do is to actually correct >it. In order to do that, you'll need to write a little bit of code, but >it isn't too complex. The DC offset will be a function of many things, >including LO frequency and temperature. These are the steps you need to >follow: > >1 - Tune your TX to the frequency you want and turn it on. You don't >need to transmit a strong signal, but you do need to transmit. You can >transmit at a very high interpolation as well, since there is really no >signal there. > >2 - Tune your RX to a different but nearby frequency. +1 MHz away is >reasonable > >3 - Measure the amplitude of the TX DC offset as received by the RX (in >this case at -1 MHz). Iteratively adjust your I TX DC offset number >until you get to the lowest power you can see. Then do the same for Q. > If it still isn't low enough, do I again. > > >Matt > > > >------------------------------ > >Message: 2 >Date: Tue, 25 May 2010 12:14:12 -0400 >From: George Nychis <[email protected]> >Subject: Re: [Discuss-gnuradio] 802.15.4 how to forward a parameter to > a c++ block >To: [email protected] >Cc: [email protected] >Message-ID: > <[email protected]> >Content-Type: text/plain; charset="iso-8859-1" > >On Tue, May 25, 2010 at 10:16 AM, <[email protected]> wrote: > >> Hi, >> >> I'm currently using the UCLA ZigBee PHY implementation posted on: >> https://www.cgran.org/wiki/UCLAZigBee >> with gnuradio. >> >> My question is the following: >> How can I forward a parameter from: src/python/ieee802_15_4_pkt.py >> ... e.g. from the "send_pkt(...)" function (or any other) >> to the c++ block in : src/lib/ucla_symbols_to_chips_bi.cc ? >> >> Or more generally speaking: How can I forward a parameter from a python >> application to the c++ processing block? >> If possible it would be great to use the io_signatures... >> >> >during instantiation of the block or during runtime? If it's during >instantiation, you can use a parameter to the constructor of your C++ >block. But, if you want something during runtime I do not think it is >possible given the current architecture. You do not explicitly call the >work() function where the processing is done, this is done within the GNU >Radio framework. > >- George >-------------- next part -------------- >An HTML attachment was scrubbed... >URL: >http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20100525/22833404/attachment.html > >------------------------------ > >Message: 3 >Date: Tue, 25 May 2010 09:45:41 -0700 >From: Matt Ettus <[email protected]> >Subject: Re: [Discuss-gnuradio] Carrier leakage on transmit >To: Charles Brain <[email protected]> >Cc: [email protected] >Message-ID: <[email protected]> >Content-Type: text/plain; charset=ISO-8859-1; format=flowed > >On 05/25/2010 07:40 AM, Charles Brain wrote: >> Well I have had another look at the offset stuff. >> >> What seems to be happening is that when you apply an offset you have to >> scale back the max IQ values being sent to the USRP2. >> >> I get this situation. >> >> No LO offset, great raised cosine shaped QPSK signal >> Add LO offset, QPSK signal looks awful. >> >> Reduce IQ signal amplitude QPSK signal again looks good and I can see >> the LO offset on the spectrum analyser. >> >> I have also noticed that when I try OFDM the unwanted rubbish on either >> side of my OFDM signal changes with LO offset. >> >> There seems to be an interaction in there somewhere probably >> to do with the complex mixer in the FPGA. I have not ruled out my own >> code yet but it seems unlikely. > > >When there is no LO offset, your I signals passes straight through, as >does the Q. When there is LO offset, the cordic is rotating them, and >when both are high, and the rotation is 45/135/225/315 degrees, the peak >of the signal is now sqrt(2) times as big. > >To look at it another way, your QPSK signal is being generated on the >corners of a square in the IQ plane. When you rotate it (which only >happens with LO offset), the corners can now go to higher values, like >when it is rotated 45 degrees and the points align with an axis. > >Matt > > > > >------------------------------ > >Message: 4 >Date: Tue, 25 May 2010 10:17:02 -0700 >From: Matt Ettus <[email protected]> >Subject: Re: [Discuss-gnuradio] Ethernet and bursting >To: Charles Irick <[email protected]> >Cc: discuss-gnuradio <[email protected]> >Message-ID: <[email protected]> >Content-Type: text/plain; charset=ISO-8859-1; format=flowed > >On 05/23/2010 08:20 AM, Charles Irick wrote: >> Hi, >> Im trying to understand a little more about the Ethernet communication >> model used for GNU Radio. I notice that the frames have start of burst >> and end of burst flags. Is this related to sending Ethernet frames? >> How many frames can be sent in a single burst? If these are not >> related to Ethernet, what is their purpose? Any good documents to look >> at relating to this? Thanks. > > >The burst refer to transmission bursts, not ethernet. If you are going >to send a continuous stream, then end of burst should not be set. End >of burst indicates that the TX should turn off after this packet has >been sent. It is more typically used in timed discontinuous transmission. > >Matt > > > > >------------------------------ > >Message: 5 >Date: Tue, 25 May 2010 10:20:43 -0700 >From: Matt Ettus <[email protected]> >Subject: Re: [Discuss-gnuradio] new inband plan? message passing? >To: George Nychis <[email protected]> >Cc: discuss-gnuradio <[email protected]> >Message-ID: <[email protected]> >Content-Type: text/plain; charset=ISO-8859-1; format=flowed > >On 05/13/2010 05:19 PM, George Nychis wrote: >> Hi all, >> >> What is the gameplan for the new inband infrastructure? VRT now defines >> the protocol/structure of the messages between the USRP and host... but >> what about message passing at the host? >> >> This is something I'm going to need in the near future, and if the price >> (a very, very, solid plan) is right, I may be able to contribute to the >> code. > > >The plan is to have a unified inband signaling system that looks the >same no matter which hardware you are using. It will be accessed >through the UHD, and use VRT under the hood. It is essentially working >now for the USRP2, and will be backported to the USRP1. > >As for how this gets accessed from GNU Radio, that is part of the >message passing system, and Johnathan can probably answer that best. > >Matt > > > > >------------------------------ > >Message: 6 >Date: Tue, 25 May 2010 20:56:45 +0300 >From: Uri Savoray <[email protected]> >Subject: [Discuss-gnuradio] RFX-900/1800 very low Tx power in 1800Mhz > band >To: "[email protected]" <[email protected]> >Message-ID: > <[email protected]> >Content-Type: text/plain; charset="us-ascii" > >We are trying to transmit from a RFX-1800 / RFX-900 cards. In the 900Mhz range >we get a normal +23 dBm output. However, in the 1800 range, the output is less >than -6dbm. Has anybody else seen this? This is also with fresh new cards from >Ettus. We made the following changes: burned the eeprom, installed the >capacitor and even got rid of the SAW filter. Any known malfunction that could >cause this? >Thanks, >Uri >-------------- next part -------------- >An HTML attachment was scrubbed... >URL: >http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20100525/f3c3fd2e/attachment.html > >------------------------------ > >Message: 7 >Date: Tue, 25 May 2010 10:03:32 -0700 (PDT) >From: Juan Quiroz <[email protected]> >Subject: [Discuss-gnuradio] About tunnel.py again >To: [email protected] >Message-ID: <[email protected]> >Content-Type: text/plain; charset="iso-8859-1" > >I'm trying to connect two computers using tunnel.py example but it fails with >a message uOBBBB, I'm working with Ubuntu >9.04, openSUSE 11.1 and GNU radio 3.2.2. Everything was fine when I did >it with GNU radio 3.1.3 and both computers with openSUSE 11.1Please can >somebody tell me what BBBB means? > >JhonQ > > > >-------------- next part -------------- >An HTML attachment was scrubbed... >URL: >http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20100525/2389fbcb/attachment.html > >------------------------------ > >Message: 8 >Date: Tue, 25 May 2010 18:03:47 -0700 >From: Eric Blossom <[email protected]> >Subject: Re: [Discuss-gnuradio] About tunnel.py again >To: Juan Quiroz <[email protected]> >Cc: [email protected] >Message-ID: <[email protected]> >Content-Type: text/plain; charset=iso-8859-1 > >On Tue, May 25, 2010 at 10:03:32AM -0700, Juan Quiroz wrote: >> I'm trying to connect two computers using tunnel.py example but it fails >> with a message uOBBBB, I'm working with Ubuntu >> 9.04, openSUSE 11.1 and GNU radio 3.2.2. Everything was fine when I did >> it with GNU radio 3.1.3 and both computers with openSUSE 11.1Please can >> somebody tell me what BBBB means? >> >> JhonQ > >A quick look at the code reveals that it means that the transmitter >has backed off because it detected carrier. > > while 1: > payload = os.read(self.tun_fd, 10*1024) > if not payload: > self.tb.send_pkt(eof=True) > break > > if self.verbose: > print "Tx: len(payload) = %4d" % (len(payload),) > > delay = min_delay > while self.tb.carrier_sensed(): > sys.stderr.write('B') > time.sleep(delay) > if delay < 0.050: > delay = delay * 2 # exponential back-off > > self.tb.send_pkt(payload) > > >Try changing the carrier threshold using the -c command line option. > >Eric > > > >------------------------------ > >Message: 9 >Date: Wed, 26 May 2010 14:43:13 +0700 >From: Muhammad Najib <[email protected]> >Subject: Re: [Discuss-gnuradio] tvrx and usrp_tv_rcv >To: Eric Blossom <[email protected]>, Muhammad Najib > <[email protected]>, [email protected] >Message-ID: > <[email protected]> >Content-Type: text/plain; charset=UTF-8 > >Thank you for your previous response, > >About the algorithm,, it's rather straight forward without >modification from the textbook >1. for the usrp, i use decimation of 8, with tuning frekuency at the >middle of the channel(706MHz). >2.1 using 2 sine signal source, i shift video and audio carrier to 0Mhz. >2.2 using sine and cosine signal source, i take the u and v signal. >3. audio demod using wfm_rcv_pll >4. video demod using tv_rcv+synch > >in total, there are 4 sine/cosine signal generators, 5/6 filters, few >operators. > >without color decoding, i've already got video and audio playing, >my question is which block gives the most load to the CPU? >is the additional signal generators add so much load ? > >thank you for your response > >On Mon, Mar 8, 2010 at 9:29 PM, Eric Blossom <[email protected]> wrote: >> On Mon, Mar 08, 2010 at 11:33:18AM +0700, Muhammad Najib wrote: >>> Hello All, >>> >>> I'm trying to recreate Mr. Dayal's thesis about analog tv decoding >>> using gnuradio. >>> i have already got the black and white picture after taking 8MHz band >>> with frequency centered in the middle of the channel. >>> >>> the problem is, i got about one or two fps with my computer(2.3GHz >>> atlon64 x2 4400). Is this normal? what is the minimum cpu/memory >>> requirement for this? >>> >>> thank you for your response. >>> --Najib. >> >> I'm not familiar with the code that you're using, but in general, yes, >> I would expect it to be possible to decode analog TV with your >> equipment.  Algorithms make a big difference... >> >> Note also that the passband of the the TVRX is about 6 MHz wide >> (NTSC), so if your channel bandwidth really is 7 or 8 MHz wide >> (PAL/SECAM), you're probably filter some of the signal. >> >> Eric >> > > > >------------------------------ > >Message: 10 >Date: Wed, 26 May 2010 11:17:43 +0200 >From: [email protected] >Subject: Re: [Discuss-gnuradio] 802.15.4 how to forward a parameter to > a c++ block >To: "George Nychis" <[email protected]> >Cc: [email protected] >Message-ID: <[email protected]> >Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; > format="flowed" > >>> Hi, >>> >>> I'm currently using the UCLA ZigBee PHY implementation posted on: >>> https://www.cgran.org/wiki/UCLAZigBee >>> with gnuradio. >>> >>> My question is the following: >>> How can I forward a parameter from: src/python/ieee802_15_4_pkt.py >>> ... e.g. from the "send_pkt(...)" function (or any other) >>> to the c++ block in : src/lib/ucla_symbols_to_chips_bi.cc ? >>> >>> Or more generally speaking: How can I forward a parameter from a python >>> application to the c++ processing block? >>> If possible it would be great to use the io_signatures... >>> >>> >> during instantiation of the block or during runtime? If it's during >> instantiation, you can use a parameter to the constructor of your C++ >> block. But, if you want something during runtime I do not think it is >> possible given the current architecture. You do not explicitly call the >> work() function where the processing is done, this is done within the GNU >> Radio framework. >> >> - George >> >Well I'd need it during runtime. >What about using a shared memory block between the python and the c++ >block? Or what about calling a function from within the c++ block, >which would get the parameter from the python block or a specific >memory block > >Thanks for the help! > >- Bjoern > > > > > >------------------------------ > >Message: 11 >Date: Wed, 26 May 2010 03:22:51 -0700 (PDT) >From: Jim V <[email protected]> >Subject: [Discuss-gnuradio] USRP1 Simulatenous Receive and Transmit >To: [email protected] >Message-ID: <[email protected]> >Content-Type: text/plain; charset=us-ascii > > >Hi everyone, > >is it feasible to transmit and receive simultaneously having one USRP1 with >2 daughtercards (2 RFX) (for example in Side A receiving and in Side B >transmitting)? Is there any example in GnuRadio? > >Thank you in advance >-- >View this message in context: >http://old.nabble.com/USRP1-Simulatenous-Receive-and-Transmit-tp28678838p28678838.html >Sent from the GnuRadio mailing list archive at Nabble.com. > > > > >------------------------------ > >Message: 12 >Date: Wed, 26 May 2010 03:23:39 -0700 (PDT) >From: Jim V <[email protected]> >Subject: [Discuss-gnuradio] USRP1 Simultaneous Receive and Transmit >To: [email protected] >Message-ID: <[email protected]> >Content-Type: text/plain; charset=us-ascii > > >Hi everyone, > >is it feasible to transmit and receive simultaneously having one USRP1 with >2 daughtercards (2 RFX) (for example in Side A receiving and in Side B >transmitting)? Is there any example in GnuRadio? > >Thank you in advance >-- >View this message in context: >http://old.nabble.com/USRP1-Simultaneous-Receive-and-Transmit-tp28678838p28678838.html >Sent from the GnuRadio mailing list archive at Nabble.com. > > > > >------------------------------ > >Message: 13 >Date: Wed, 26 May 2010 18:25:05 +0800 >From: John Wu <[email protected]> >Subject: Re: [Discuss-gnuradio] Hi all, how to use usrp and gnuradio > support triangulation to locate a cell phone >To: Harley Myler <[email protected]>, [email protected] >Message-ID: > <[email protected]> >Content-Type: text/plain; charset="iso-8859-1" > >Harley Thanks >I find another way call hyperbolic location method that is more accurate to >locate a cell phone. and what u said is correct, I must first get a phone's >communication. Now the easier way what I know is using openbts and usrp >build a gsm bts to communicate with cell phone. Am I right? > >On Tue, May 25, 2010 at 8:11 PM, Harley Myler <[email protected]> wrote: > >> >> On May 24, 2010, at 10:06 PM, John Wu wrote: >> >> > Hi all, I am a fresh on usrp and gnuradio, now I want to use them to >> support locate a cell phone, and what I know is locate a cell phone need to >> use triangulation method. Anyone know if gnuradio contain triangulation >> block or any open triangulation algorithm available? >> > >> > Thanks! >> > _______________________________________________ >> > Discuss-gnuradio mailing list >> > [email protected] >> > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> John, the dilemma you will face in locating a cell phone will be the coding >> that it incorporates as it communicates with towers. If you know the signal >> that a particular phone emits, or of you can establish communication with >> one, then the direction finding should be trivial. I am working on ADF now, >> but my interest is in locating the towers, not the phones. >> >> What you may need to do is set up your GR to act like a tower, establish >> comm with a phone and then use an antenna array to determine it's location. >> I just recently managed to squeeze out of the Ettus group how to control >> something with the GPIO so that I can manipulate an antenna array, so you >> are pretty much on your own for anything beyond the example programs in the >> existing software. >> >> I did not understand the youtube popcorn thing. >> >> >> >> >> CONFIDENTIALITY: Any information contained in this e-mail (including >> attachments) is the property of The State of Texas and unauthorized >> disclosure or use is prohibited. Sending, receiving or forwarding of >> confidential, proprietary and privileged information is prohibited under >> Lamar Policy. If you received this e-mail in error, please notify the sender >> and delete this e-mail from your system. >> >> >-------------- next part -------------- >An HTML attachment was scrubbed... >URL: >http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20100526/850c2845/attachment.html > >------------------------------ > >Message: 14 >Date: Wed, 26 May 2010 13:19:14 +0200 >From: [email protected] >Subject: [Discuss-gnuradio] 802.15.4 how to forward a parameter to a > c++ block >To: [email protected] >Message-ID: <[email protected]> >Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; > format="flowed" > >>>> Hi, >>>> >>>> I'm currently using the UCLA ZigBee PHY implementation posted on: >>>> https://www.cgran.org/wiki/UCLAZigBee >>>> with gnuradio. >>>> >>>> My question is the following: >>>> How can I forward a parameter from: src/python/ieee802_15_4_pkt.py >>>> ... e.g. from the "send_pkt(...)" function (or any other) >>>> to the c++ block in : src/lib/ucla_symbols_to_chips_bi.cc ? >>>> >>>> Or more generally speaking: How can I forward a parameter from a python >>>> application to the c++ processing block? >>>> If possible it would be great to use the io_signatures... >>>> >>>> >>> during instantiation of the block or during runtime? If it's during >>> instantiation, you can use a parameter to the constructor of your C++ >>> block. But, if you want something during runtime I do not think it is >>> possible given the current architecture. You do not explicitly call the >>> work() function where the processing is done, this is done within the GNU >>> Radio framework. >>> >>> - George >>> >> Well I'd need it during runtime. >> What about using a shared memory block between the python and the >> c++ block? Or what about calling a function from within the c++ >> block, which would get the parameter from the python block or a >> specific memory block >> >> Thanks for the help! >> >> - Bjoern > > >Or how could I extend "ucla_symbols_to_chips_bi" to have more inputs, >such that I could have one more stream forwarded from >"ieee_802_15_4.py" to "ucla_symbols_to_chips_bi"? >This then could be used within the work() function, wouldn't it? > >many thanks to all! >-Björn > > > > >------------------------------ > >Message: 15 >Date: Wed, 26 May 2010 15:36:20 +0200 >From: Markus Becker <[email protected]> >Subject: Re: [Discuss-gnuradio] 802.15.4 how to forward a parameter to > a c++ block >To: [email protected] >Message-ID: <[email protected]> >Content-Type: Text/Plain; charset="iso-8859-1" > >> >>> Hi, >> >>> >> >>> I'm currently using the UCLA ZigBee PHY implementation posted on: >> >>> https://www.cgran.org/wiki/UCLAZigBee >> >>> with gnuradio. >> >>> >> >>> My question is the following: >> >>> How can I forward a parameter from: src/python/ieee802_15_4_pkt.py >> >>> ... e.g. from the "send_pkt(...)" function (or any other) >> >>> to the c++ block in : src/lib/ucla_symbols_to_chips_bi.cc ? >> >>> >> >>> Or more generally speaking: How can I forward a parameter from a python >> >>> application to the c++ processing block? >> >>> If possible it would be great to use the io_signatures... >> >> >> >> during instantiation of the block or during runtime? If it's during >> >> instantiation, you can use a parameter to the constructor of your C++ >> >> block. But, if you want something during runtime I do not think it is >> >> possible given the current architecture. You do not explicitly call the >> >> work() function where the processing is done, this is done within the >> >> GNU Radio framework. >> >> >> >> - George >> > >> > Well I'd need it during runtime. >> > What about using a shared memory block between the python and the >> > c++ block? Or what about calling a function from within the c++ >> > block, which would get the parameter from the python block or a >> > specific memory block >> > >> > Thanks for the help! >> > >> > - Bjoern >> >> Or how could I extend "ucla_symbols_to_chips_bi" to have more inputs, >> such that I could have one more stream forwarded from >> "ieee_802_15_4.py" to "ucla_symbols_to_chips_bi"? > >For that you need to change the io_signature. > >gr_make_io_signature (1, -1, sizeof (unsigned char)), >to >gr_make_io_signature (2, -1, sizeof (unsigned char)), > >> This then could be used within the work() function, wouldn't it? >> >> many thanks to all! >> -Björn >> >> >> _______________________________________________ >> Discuss-gnuradio mailing list >> [email protected] >> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio >------------------------------------------------ >| ATTENTION: NEW TELEPHONE EXTENSION! >------------------------------------------------ >| Dipl.-Ing. Markus Becker >| Communication Networks >| Mobile Research Center >| TZI - Center for Computing Technologies >| University Bremen >| Germany >------------------------------------------------ >| web: http://www.comnets.uni-bremen.de/~mab/ >| mailto: [email protected] >------------------------------------------------ > > > >------------------------------ > >Message: 16 >Date: Wed, 26 May 2010 15:43:17 +0200 >From: [email protected] >Subject: Re: [Discuss-gnuradio] 802.15.4 how to forward a parameter to > a c++ block >To: "Markus Becker" <[email protected]> >Cc: [email protected] >Message-ID: <[email protected]> >Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; > format="flowed" > >>> >>> Hi, >>> >>> >>> >>> I'm currently using the UCLA ZigBee PHY implementation posted on: >>> >>> https://www.cgran.org/wiki/UCLAZigBee >>> >>> with gnuradio. >>> >>> >>> >>> My question is the following: >>> >>> How can I forward a parameter from: src/python/ieee802_15_4_pkt.py >>> >>> ... e.g. from the "send_pkt(...)" function (or any other) >>> >>> to the c++ block in : src/lib/ucla_symbols_to_chips_bi.cc ? >>> >>> >>> >>> Or more generally speaking: How can I forward a parameter from a python >>> >>> application to the c++ processing block? >>> >>> If possible it would be great to use the io_signatures... >>> >> >>> >> during instantiation of the block or during runtime? If it's during >>> >> instantiation, you can use a parameter to the constructor of your C++ >>> >> block. But, if you want something during runtime I do not think it is >>> >> possible given the current architecture. You do not explicitly call the >>> >> work() function where the processing is done, this is done within the >>> >> GNU Radio framework. >>> >> >>> >> - George >>> > >>> > Well I'd need it during runtime. >>> > What about using a shared memory block between the python and the >>> > c++ block? Or what about calling a function from within the c++ >>> > block, which would get the parameter from the python block or a >>> > specific memory block >>> > >>> > Thanks for the help! >>> > >>> > - Bjoern >>> >>> Or how could I extend "ucla_symbols_to_chips_bi" to have more inputs, >>> such that I could have one more stream forwarded from >>> "ieee_802_15_4.py" to "ucla_symbols_to_chips_bi"? >> >> For that you need to change the io_signature. >> >> gr_make_io_signature (1, -1, sizeof (unsigned char)), >> to >> gr_make_io_signature (2, -1, sizeof (unsigned char)), > >Ah, great, thanks a lot! >But where can I find that new stream to fill!? In other words: >-how can I generate a new variable / stream and >-where do I submit it, such that it is forwarded to the corresponding >c++ block, and >-how can I access it from within the c++ block!? > >thanks a lot >best, >Bjoern > > > > >------------------------------ > >Message: 17 >Date: Wed, 26 May 2010 19:24:32 +0430 >From: Mohammad Hosein <[email protected]> >Subject: [Discuss-gnuradio] Wimax >To: [email protected] >Message-ID: > <[email protected]> >Content-Type: text/plain; charset="utf-8" > >hello, >evaluating the possibility of start a Wimax fuzzing test bed project with >Gnu Radio/USRP . anybody knows if : >- there is a working 802.16d implementation based on Gnu Radio , that works >fine with USRP >- there are SDR based projects preferably based on GNU Radio , to fuzz Radio >systems : GSM BTS , Wimax Radio , TETRA base stations , etc . the goal is to >do with the Radio what we do with software in Fuzzing stage of security >related projects . to conduct a huge series of tests , examine the results >and see when and how the Radio is not up to the task > >regards >-------------- next part -------------- >An HTML attachment was scrubbed... >URL: >http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20100526/d2b739a3/attachment.html > >------------------------------ > >Message: 18 >Date: Wed, 26 May 2010 07:12:34 -0700 (PDT) >From: Jim V <[email protected]> >Subject: Re: [Discuss-gnuradio] About tunnel.py >To: [email protected] >Message-ID: <[email protected]> >Content-Type: text/plain; charset=UTF-8 > > >Hello Juan, > >according to the FAQ ( http://gnuradio.org/redmine/wiki/1/UsrpFAQGen >http://gnuradio.org/redmine/wiki/1/UsrpFAQGen ): > > "u" = USRP > "a" = audio (sound card) > "O" = overrun (PC not keeping up with received data from usrp or audio >card) > "U" = underrun (PC not providing data quickly enough) > >uOuO == USRP overrun (USRP samples dropped because they weren't read in time > > >I don't know what B means. > > > >Juan Quiroz-2 wrote: >> >> I'm trying to connect two computers  using tunnel.py example but it fails >> with a message uOBBBB, I'm working with Ubuntu 9.04, openSUSE 11.1 and GNU >> radio 3.2.2. Everything was fine when I did it with GNU radio 3.1.3 and >> both computers with openSUSE 11.1Please can somebody tell me what uOBBBB >> means? specially that B >> >> JhonQ >> >> >> >> >> _______________________________________________ >> Discuss-gnuradio mailing list >> [email protected] >> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> > >-- >View this message in context: >http://old.nabble.com/About-tunnel.py-tp28638207p28681357.html >Sent from the GnuRadio mailing list archive at Nabble.com. > > > > >------------------------------ > >Message: 19 >Date: Wed, 26 May 2010 17:09:16 +0200 >From: matty <[email protected]> >Subject: [Discuss-gnuradio] gcellized FFTW has broken gcell block >To: [email protected] >Message-ID: > <[email protected]> >Content-Type: text/plain; charset="iso-8859-1" > >Last day's I installed gcellized FFTW or better I have to say FFTW-WIP, >because the gcellized FFTW svn folder on cgran was empty. >So I downloaded the code using > >$ svn co >https://www.cgran.org/cgran/projects/fftw-gcell/branches/developers/eb/fftw-wip > >and compiled the source. > >$ ./bootstrap.sh > >"PLEASE IGNORE WARNINGS AND ERRORS" says bootstrap.sh > >abort with error: > >(cd .; *.mli *.ml > .depend) >/bin/sh: algsimp.mli: command not found. >make: *** [depend] Error 127 > >so i've done > >$ ./configure >$ make >$ make check > >make check said: FFTW transforms passed basic tests! > >So i installed the FFTW and got binaries in /usr/local/bin (fftw-wisdom) and >libraries in /usr/local/lib. > >After installing FFTW-WIP i looked for a solution to set up with gcell. But >entering python to do *import gcell* python said no module named gcell. >Prior it worked. I can import gnuradio and from gnuradio import gcell. But >import gcell doesn't work. > >I think it could be an issue with gcellized FFTW Code, but at the moment i >have no answer for this. > >Did i everything wrong? > >Best regards >Matty >-------------- next part -------------- >An HTML attachment was scrubbed... >URL: >http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20100526/7e6b4e99/attachment.html > >------------------------------ > >Message: 20 >Date: Wed, 26 May 2010 08:29:22 -0700 >From: Matt Ettus <[email protected]> >Subject: Re: [Discuss-gnuradio] USRP1 Simultaneous Receive and > Transmit >To: Jim V <[email protected]> >Cc: [email protected] >Message-ID: <[email protected]> >Content-Type: text/plain; charset=ISO-8859-1; format=flowed > >On 05/26/2010 03:23 AM, Jim V wrote: >> >> Hi everyone, >> >> is it feasible to transmit and receive simultaneously having one USRP1 with >> 2 daughtercards (2 RFX) (for example in Side A receiving and in Side B >> transmitting)? Is there any example in GnuRadio? >> >> Thank you in advance > > >Yes, this is known as full duplex. You can even do it with a single RFX >card both transmitting and receiving, but it will have somewhat higher >crosstalk than with 2 daughterboards. > >Matt > > > > >------------------------------ > >Message: 21 >Date: Wed, 26 May 2010 08:43:45 -0700 >From: Josh Blum <[email protected]> >Subject: Re: [Discuss-gnuradio] 802.15.4 how to forward a parameter to > a c++ block >To: [email protected] >Message-ID: <[email protected]> >Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > >> >> Ah, great, thanks a lot! >> But where can I find that new stream to fill!? In other words: >> -how can I generate a new variable / stream and >> -where do I submit it, such that it is forwarded to the corresponding >> c++ block, and >> -how can I access it from within the c++ block!? >> > >See message_source and message_sink blocks. The message blocks get data >in and out of the c++ realm using message queues so you can directly >manipulate the gnuradio streams in python. > >-Josh > > > >------------------------------ > >_______________________________________________ >Discuss-gnuradio mailing list >[email protected] >http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > >End of Discuss-gnuradio Digest, Vol 90, Issue 26 >************************************************
_______________________________________________ Discuss-gnuradio mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
