[Discuss-gnuradio] Re:Discuss-gnuradio Digest, Vol 90, Issue 26

[weizhongshan]

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:address@hidden 写道：
>Send Discuss-gnuradio mailing list submissions to
>       address@hidden
>
>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
>       address@hidden
>
>You can reach the person managing the list at
>       address@hidden
>
>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
>      (address@hidden)
>  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
>      (address@hidden)
>  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
>      (address@hidden)
>  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 <address@hidden>
>Subject: Re: [Discuss-gnuradio] Carrier leakage on transmit
>To: Charles Brain <address@hidden>
>Cc: address@hidden
>Message-ID: <address@hidden>
>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 <address@hidden>
>Subject: Re: [Discuss-gnuradio] 802.15.4 how to forward a parameter to
>       a c++   block
>To: address@hidden
>Cc: address@hidden
>Message-ID:
>       <address@hidden>
>Content-Type: text/plain; charset="iso-8859-1"
>
>On Tue, May 25, 2010 at 10:16 AM, <address@hidden> 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 <address@hidden>
>Subject: Re: [Discuss-gnuradio] Carrier leakage on transmit
>To: Charles Brain <address@hidden>
>Cc: address@hidden
>Message-ID: <address@hidden>
>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 <address@hidden>
>Subject: Re: [Discuss-gnuradio] Ethernet and bursting
>To: Charles Irick <address@hidden>
>Cc: discuss-gnuradio <address@hidden>
>Message-ID: <address@hidden>
>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 <address@hidden>
>Subject: Re: [Discuss-gnuradio] new inband plan? message passing?
>To: George Nychis <address@hidden>
>Cc: discuss-gnuradio <address@hidden>
>Message-ID: <address@hidden>
>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 <address@hidden>
>Subject: [Discuss-gnuradio] RFX-900/1800 very low Tx power in 1800Mhz
>       band
>To: "address@hidden" <address@hidden>
>Message-ID:
>       <address@hidden>
>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 <address@hidden>
>Subject: [Discuss-gnuradio] About tunnel.py again
>To: address@hidden
>Message-ID: <address@hidden>
>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 <address@hidden>
>Subject: Re: [Discuss-gnuradio] About tunnel.py again
>To: Juan Quiroz <address@hidden>
>Cc: address@hidden
>Message-ID: <address@hidden>
>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 <address@hidden>
>Subject: Re: [Discuss-gnuradio] tvrx and usrp_tv_rcv
>To: Eric Blossom <address@hidden>, Muhammad Najib
>       <address@hidden>,       address@hidden
>Message-ID:
>       <address@hidden>
>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 <address@hidden> 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: address@hidden
>Subject: Re: [Discuss-gnuradio] 802.15.4 how to forward a parameter to
>       a       c++ block
>To: "George Nychis" <address@hidden>
>Cc: address@hidden
>Message-ID: <address@hidden>
>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 <address@hidden>
>Subject: [Discuss-gnuradio] USRP1 Simulatenous Receive and Transmit
>To: address@hidden
>Message-ID: <address@hidden>
>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 <address@hidden>
>Subject: [Discuss-gnuradio] USRP1 Simultaneous Receive and Transmit
>To: address@hidden
>Message-ID: <address@hidden>
>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 <address@hidden>
>Subject: Re: [Discuss-gnuradio] Hi all, how to use usrp and gnuradio
>       support         triangulation to locate a cell phone
>To: Harley Myler <address@hidden>, address@hidden
>Message-ID:
>       <address@hidden>
>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 <address@hidden> 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
>> > address@hidden
>> > 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: address@hidden
>Subject: [Discuss-gnuradio] 802.15.4 how to forward a parameter to a
>       c++ block
>To: address@hidden
>Message-ID: <address@hidden>
>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 <address@hidden>
>Subject: Re: [Discuss-gnuradio] 802.15.4 how to forward a parameter to
>       a c++   block
>To: address@hidden
>Message-ID: <address@hidden>
>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
>> address@hidden
>> 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: address@hidden
>------------------------------------------------
>
>
>
>------------------------------
>
>Message: 16
>Date: Wed, 26 May 2010 15:43:17 +0200
>From: address@hidden
>Subject: Re: [Discuss-gnuradio] 802.15.4 how to forward a parameter to
>       a       c++ block
>To: "Markus Becker" <address@hidden>
>Cc: address@hidden
>Message-ID: <address@hidden>
>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 <address@hidden>
>Subject: [Discuss-gnuradio] Wimax
>To: address@hidden
>Message-ID:
>       <address@hidden>
>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 <address@hidden>
>Subject: Re: [Discuss-gnuradio] About tunnel.py
>To: address@hidden
>Message-ID: <address@hidden>
>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
>> address@hidden
>> 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 <address@hidden>
>Subject: [Discuss-gnuradio] gcellized FFTW has broken gcell block
>To: address@hidden
>Message-ID:
>       <address@hidden>
>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 <address@hidden>
>Subject: Re: [Discuss-gnuradio] USRP1 Simultaneous Receive and
>       Transmit
>To: Jim V <address@hidden>
>Cc: address@hidden
>Message-ID: <address@hidden>
>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 <address@hidden>
>Subject: Re: [Discuss-gnuradio] 802.15.4 how to forward a parameter to
>       a c++   block
>To: address@hidden
>Message-ID: <address@hidden>
>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
>address@hidden
>http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>End of Discuss-gnuradio Digest, Vol 90, Issue 26
>************************************************