[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Discuss-gnuradio] Re:Discuss-gnuradio Digest, Vol 90, Issue 26
From: |
weizhongshan |
Subject: |
[Discuss-gnuradio] Re:Discuss-gnuradio Digest, Vol 90, Issue 26 |
Date: |
Thu, 27 May 2010 17:29:56 +0800 (CST) |
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
>************************************************
- [Discuss-gnuradio] Re:Discuss-gnuradio Digest, Vol 90, Issue 26,
weizhongshan <=
- [Discuss-gnuradio] How to write a signal processing block problems, Tobias Schmid, 2010/05/27
- Re: [Discuss-gnuradio] Re:Discuss-gnuradio Digest, Vol 90, Issue 26, Eric Blossom, 2010/05/27
- Re:Re: [Discuss-gnuradio] Re:Discuss-gnuradio Digest, Vol 90, Issue 26, weizhongshan, 2010/05/27