Re: [Discuss-gnuradio] Using the dqpsk modulator

[Maduike, Dumezie]

Hello all.  In reference to this post, how does the signal actually get 
transmitted through the wireless channel?  Does the qpsk block need to be 
connected to a usrp_sink_c() block?  

Thanks
Dumezie

- Original Message -
From: "Eric Blossom" 
To: "karim" 
Cc: discuss-gnuradio@gnu.org
Sent: Thursday, April 9, 2009 12:20:25 PM GMT -06:00 Guadalajara / Mexico City 
/ Monterrey
Subject: Re: [Discuss-gnuradio] Using the dqpsk modulator

On Thu, Apr 09, 2009 at 09:46:43AM -0700, karim wrote:
> Hi,
> I am trying to use the dqpsk modulator block to modulate some data and  
> then take the output and separate it to real and imag. This is the code,  
>  it runs but the sinks are empty and have no data. What am I doing wrong?

You're printing the contents of the vector sinks in your
initialization code, before the graph has started running.

Try printing their contents after my_top_block().run() returns.

Eric


> I also get this when I run it:
> >>> gr_fir_ccf: using SSE
> What does it mean?

It means that the FIR block is using hand coded SSE instead of the
"generic" c++ implementation.

> My code is below.
> Cheers,
> Karim
>
> #no GUI
> #source: stream from file_source
> #connect with DQPSK: input: byte stream, output:complex
> #change it to 2 parts:imagine and Real
> #connect with gr.complex_to_real or gr.complex_to_imag
> #display data in sink1 (real) and sink2 (imag)
>
> class my_top_block(gr.top_block):
>
>   def __init__(self):
> gr.top_block.__init__(self)
>
> src_data = (1,0,1,0,1,0,1,0)
> src = gr.vector_source_b (src_data)
>
> #input: unsigned char, output: complex
> qpsk = blks2.dqpsk_mod(2,.35,True, False, False)
> self.connect (src,qpsk)
>
> real = gr.complex_to_real()
> imag = gr.complex_to_imag()
> self.connect(qpsk,real)
> self.connect(qpsk,imag)
>
> sink1 = gr.vector_sink_f()
> sink2 = gr.vector_sink_f()
>
> self.connect(real,sink1)
> self.connect(imag,sink2)
>
> print "Data in sink1 is: ",sink1.data()
>
> print "Data in sink2 is: ",sink2.data()
>
>
> if __name__ == '__main__':
> try:
> my_top_block().run()
> except KeyboardInterrupt:
> pass


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] USRP Basics questions

[Josh Blum]

Somya Ajmera wrote:

HI Josh, we have basic TX , RX daughter board with us. also what is that range 
you have mentioned into your reply is for?


Many times, users give the usrp sink numbers between +/- 1.0 and there 
is no transmit power. Just to double check, you should be giving usrp 
numbers around +/- 10e3 :-)


As far as how you can see the signal:

You can hook up an oscilloscope to one of the SMA connectors on the 
basic TX (TXA or TXB)


Or, connect the basic RX to the basic TX with SMA to SMA connector, and 
use a program like usrp_oscope.py or usrp_fft.py to look at the received 
signal.


-Josh


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Benchmarking with URSP_benchmark_usb.py

[edi k]

Hi, Dear All,

I've just installed cygwin and gnu radio in my laptop. I'm trying to run
usrp_benchmark_usb.py. and i get this message:

Testing 2MB/sec...usb_control_msg failed:usb_control_msg:sending control
message failed,win error: A device attached to the system is not functioning
usb_control_msg failed:usb_control_msg:sending control message failed,win
error: A device attached to the system is not functioning
usb_control_msg failed:usb_control_msg:sending control message failed,win
error: A device attached to the system is not functioning
usb_control_msg failed:usb_control_msg:sending control message failed,win
error: A device attached to the system is not functioning
usb_throughput = 2M
ntotal = 100
nright = 998019
nlength =  998019
delta = 1981
OK
Testing 4MB/sec
...


does anyone know about this. because it looks error ,
"usb_control_msg:sending control message failed" . but it looks OK as well, 
usb_throughput = 2M
ntotal = 100
nright = 998019
nlength =  998019
delta = 1981
OK

need your help?...

thanks,
Edi
-- 
View this message in context: 
http://www.nabble.com/Benchmarking-with-URSP_benchmark_usb.py-tp23033021p23033021.html
Sent from the GnuRadio mailing list archive at Nabble.com.



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Simultaneous RX/TV with RFX2400

[Jakub Moskal]

Hi Michael,

my intention is to allow a communication between two USRP's hooked up
to two different computers. Each USRP has one RFX2400 daughterboard
and one antenna connected to the Tx/Rx port.  I have a more of a CS
than ECE background and my focus here is on the application level. I
would like the radios to be able to send and receive messages
asynchronously - which can mean asynchronous communication at the
application layer, but synchronous below - perhaps not even observable
above. In my scenario, radios send messages which are read from some
buffer and at the same time receive messages and put them in a
different buffer for further processing. How do I go about
implementing such scenario? Do I have to implement a protocol which
consists of some time-based switching of rx/tx? Can I achieve it with
only one antenna per USRP, or do I need two of them - one for Tx//Rx
and one for Rx2 port?

I imagine that in the case of only two radios, I could achieve this
behavior by allowing one radio to Rx while the other is Tx-ing and
after short time, switching the direction to the opposite, to allow
the first radio to Tx. However, I don't see how this could be achieved
if 2+ radios are involved - without the prior knowledge of the number
of "neighbors". That is why I thought each radio should be allowed to
Tx and Rx at the same time.

Thank you for help!
Jakub.

On Mon, Apr 13, 2009 at 4:19 PM, Michael Dickens  wrote:
> Hi Jakub - 2 possibilities, depending on how one interprets your question:
>
> A) If what you mean is "using a single host computer that controls the two
> USRPs such that one transmits while the other receives and vice-versa, but
> never a single USRP both Tx and Rx simultaneously", then yes, that can be
> done; you could probably even use two host computers that sync the Tx/Rx in
> a MAC-like way using the current GNU Radio software, so long as each USRP is
> not trying to do simultaneous Tx and Rx.  If using a single host computer:
> on each USRP, you'd use set_auto_tr(true) and then control both USRPs from
> the same Python script.  My colleague Glenn has done this in a "TDMA
> fashion" to compare properties of actual and theoretical relays; see his MS
> thesis and related paper at UND <
> http://www.nd.edu/~jnl/group/glenn-bradford/ >.
>
> B) If what you mean is "simultaneous Tx/Rx on each USRP, using a single RFX
> and single antenna", then this problem is (1) possibly not do-able in the
> current state of GNU Radio software and USRP hardware; and (2) even if it is
> do-able, certainly not easily so in GNU Radio software without significant
> hacking to make it work.  The primary issue is in jointly estimating the
> channel parameters (both the Tx -> Rx delay and filter coefficients), which
> might be time-varying or dependent on qualities beyond the direct TX signal.
>  I'm happy to discuss this interpretation further off-list.
>
> Hope this helps! - MLD
>


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] using gnuradio for GPS

[davek]

www.gps-sdr.com

On Tue, Apr 14, 2009 at 12:05 AM, Woody Dickson  wrote:
> Hi,
>
> Does anyone know if there is any reference implementation on the use
> of gnuradio for GPS?
>
> I am interested in DIYing my own GPS system.
>
> Any information will be greatly appreciated.
>
> Thanks,
> Woody
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] using gnuradio for GPS

[Woody Dickson]

Hi,

Does anyone know if there is any reference implementation on the use
of gnuradio for GPS?

I am interested in DIYing my own GPS system.

Any information will be greatly appreciated.

Thanks,
Woody


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] browsing the Internet through GNU Radio

[Jhon Lee]

Hi all,

I am trying to figure out the easiest way to implement  an 802.11 AP with RTS 
function using GNU Radio based on existing projects, such as BBN, CMU_MAC, 
Click, etc. I have not found any projects which are the same as my needs. I 
have two USRPs. One USRP with a PC as an AP and one USRP with a PC as a host. I 
want to browse the Internet at the host; the host and the AP should connect 
with each other through wireless 802.11. The AP connects to the Internet 
through the Ethernet. Does anyone know how to make this work? examples? hints?

Thank you so much!


  ___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] USRP Basics questions

[Somya Ajmera]

HI Josh, we have basic TX , RX daughter board with us. also what is that range 
you have mentioned into your reply is for?

Thanks & Regards,
Somya Ajmera

--- On Tue, 14/4/09, Josh Blum  wrote:
From: Josh Blum 
Subject: Re: [Discuss-gnuradio] USRP Basics questions
To: ajmeraso...@yahoo.com
Cc: "'discuss-gnuradio@gnu.org'" 
Date: Tuesday, 14 April, 2009, 4:37 AM

> 
> 3) While using GRC, when we transmit the signal using the USRP block, how
can we check or see the transmitted signal? Is there any pin on the USRP board
which can be probed with the oscilloscope in order to view the transmitted
signal.  

What daughterboards do you have?

Make sure that the amplitude of the signal going into usrp sink is  on the
order of 10,000 (since usrp range is +/- 32768)

-Josh



  Get your new Email address!
Grab the Email name you've always wanted before someone else does!
http://mail.promotions.yahoo.com/newdomains/aa/___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Re: Software Communication Architecture (SCA) and GNU Radio

[Sheng Liao]

Hi Philip,

Sorry for the late reply. I am new in this field. Is it possible for you 
to explain more?

> 
> I've always thought it would be interesting to encapsulate a gnu radio
> flow graph inside an SCA component. This would provide a rapid component
> development environment for SCA waveform developers.
> 
> I'm very familiar with the SCA and OSSIE and know enough GNU Radio to be
> dangerous. I strongly suspect you could create gnu radio blocks to adapt
> the GNU Radio control and data interfaces to the SCA port structures. I
> haven't had time to look into this, but I am pretty sure it could be
> prototyped in a few weeks.

  Dangerous??

> This would be an interesting exercise. At first I saw this as a way to
> get around the old single threaded nature of GNU Radio, but the thread
> per block scheduler resolved that issue in a much cleaner way. The rapid
> prototyping for SCA waveform development is still very interesting.
> 
> Philip

Thank you,
Sheng
-- 
Posted via http://www.ruby-forum.com/.


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Simultaneous RX/TV with RFX2400

[Michael Dickens]

On Apr 13, 2009, at 5:17 PM, Bishal Thapa wrote:

I was working on the similar problem. What about using two TX daughter
boards in the same motherboard, and BOTH TRANSMITTING  signals
simultaneously, one from each daughter board, but in an "overlapped"
fashion. Is it easily possible? What I mean is, I would like to have  
two
signals generated from two daughter boards plugged into the same  
motherboard

but interleaved in some fashion so that I can study the effect of that
interleaving on the receiver side (receiver is on a different host  
far from
these two simultaneously transmitting USRPs). Sorry if I am not  
being clear.


Hi Bishal - I understand the basics if what you're trying to do, but  
not the specifics.  If the TX interleaving is done in frequency (FDMA  
or OFDM) or codes (CDMA), then you should be able to do what you want  
with some clever programming.  OTOH, TDMA interleaving could be an  
issue -- depends on how you've implemented the overall system.  I can  
think of a number of ways to configure TDMA-like transmissions that  
could work in your dual USRP setup -- that said, they all require very  
clever programming.  Tell us more specifics of what you're trying to  
do, and maybe we can help more precisely (either on or off list, as  
you see fit). - MLD



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] USRP Basics questions

[Josh Blum]

3) While using GRC, when we transmit the signal using the USRP block, how can we check or see the transmitted signal? Is there any pin on the USRP board which can be probed with the oscilloscope in order to view the transmitted signal.  


What daughterboards do you have?

Make sure that the amplitude of the signal going into usrp sink is  on 
the order of 10,000 (since usrp range is +/- 32768)


-Josh


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] USRP Basics questions

[Somya Ajmera]

Hi All, I was wondering about some basic functions of the USRP board:

1) To what carrier frequency does the USRP board (specifically AD9862) up 
converts the base band signal and how can we change that?

2) At what transmission power does the USRP board transmits? and how that can 
be controlled or regulated?

3) While using GRC, when we transmit the signal using the USRP block, how can 
we check or see the transmitted signal? Is there any pin on the USRP board 
which can be probed with the oscilloscope in order to view the transmitted 
signal.  

Any help is really appreciated,

Thanks & Regards,
Somya Ajmera



  New Email names for you! 
Get the Email name you've always wanted on the new @ymail and @rocketmail. 
Hurry before someone else does!
http://mail.promotions.yahoo.com/newdomains/aa/___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] QPSK phase noise

[Bill Stevenson]

u r welcomed!

e.g.dst = gr.vector_sink_c ()
   result = dst.data()
dump that result into a file using dump(result, the handle of 
that file).
Thanks!

Bill 





From: yufeng wang 
To: Bill Stevenson 
Sent: Friday, April 10, 2009 6:17:49 PM
Subject: Re: [Discuss-gnuradio] QPSK phase noise

Thanks, Bill. I think we may also use the plot codes under the file
gr-utils, where plot_const.py and usrp_fft.py can be found. I have
used the usrp_fft.py to display the output signal, and I'm trying to
install scipy to enable the plot_const.py, etc. I also wanna load the
data using Matlab, I wonder how can you output the data to a sink
file? Thanks!



On Fri, Apr 10, 2009 at 4:46 PM, Bill Stevenson
 wrote:
> Hi,
>
> We can output the data to a sink file, from which we load the data using
> Matlab. Then we use scatterplot.
>
> Thanks!
>
> Bill
>
> 
> From: yufeng wang 
> To: Bill Stevenson 
> Sent: Friday, April 10, 2009 12:22:15 PM
> Subject: Re: [Discuss-gnuradio] QPSK phase noise
>
> Hi, Bill,
>
> Regarding to Paco's images, I wonder which programme did you use to
> display the output of the images that he had got? like the
> constellations?
>
> I'm using benchmark.py to transmit and receive BPSK signals. I can use
> usrp_fft.py to display the output of the transmitter. Thanks in
> advance!
>
>
>
> On Fri, Apr 10, 2009 at 12:03 PM, Bill Stevenson
>  wrote:
>> Hi, Paco
>>
>> Actually, I got the similar result as you did. I think there was something
>> wrong in the mpsk_receiver block. I am checking it. Thanks!
>>
>> Bill
>>
>> 
>> From: Paco Garcia 
>> To: Discuss-gnuradio@gnu.org
>> Sent: Wednesday, April 8, 2009 9:26:36 AM
>> Subject: Re: [Discuss-gnuradio] QPSK phase noise
>>
>>
>> Johnathan, you were right with the distortion issue at the TX, I am now
>> using
>> these parameters:
>>
>> ./benchma-m dqpsk -f 1.25G -m dqpsk --tx-amplitude=500 -r 1M -M 
>> --excess-bw=0.35
>> ./benchmark_rx.py -r 1M -m dqpsk --log --costas-alpha=0.05 -S 4 --verbose
>> -r
>> 1M --gain-mu=0.01 --excess-bw=0.35 -f 1.25G --rx-gain=45
>>
>> But still, for a 40dB SNR (
>> http://img149.imageshack.us/img149/4583/screenshot4h.png ) I think we
>> should
>> get a much better constellation than this one (
>> http://img149.imageshack.us/img149/7968/screenshot3t.png )
>>
>> I am using the latest gnuradio trunk and the
>> ../gnuradio-examples/digital/benchmark
>> I have disabled all the data loggins but the rx_receiver.dat from the
>> /usr/local/lib/python2.5/site-packages/gnuradio/blks2impl/dqpsk.py to
>> reduce
>> the computational requirements.
>>
>> I tried the 0.5M as eric suggested but the results are even worse (
>> http://img18.imageshack.us/img18/2306/screenshot5hhm.png )
>>
>> The 2M rate constellation is the same as 1M.
>>
>> If I go with BPSK, I get this:
>> http://img212.imageshack.us/img212/3010/screenshot10.png
>> using
>> ./benchmark_tx.py -m dbpsk -f 1.25G -m dbpsk --tx-amplitude=500 -r 200k -M
>>  --excess-bw=0.35
>> ./benchmark_rx.py -m dbpsk --verbose -S 4 -r 200k --excess-bw=0.35 -f
>> 1.25G
>> --rx-gain=30 > debug
>>
>> The image below shows the costas loop error:
>> ( http://img156.imageshack.us/img156/1521/screenshot11.png )
>> (zoom frequency > http://img514.imageshack.us/img514/2173/screenshot12.png
>> )
>> blue: phase
>> red: phase_error
>> cian: Q
>> purple: I
>> green: freq
>>
>> So once the costas locks, there is still some error which is causing the
>> blur constellation. But I think that for an almost 40dB SNR signal (
>> http://img212.imageshack.us/img212/551/screenshot13.png ) we should get
>> much
>> better results.
>>
>> The M&M block influences a lot, if I change the samples per symbol to 2 I
>> get this: ( http://img201.imageshack.us/img201/9436/screenshot14.png )
>>
>> I have also tried via air interface getting similar results. My question
>> is
>> whether this is normal for the mpsk gnuradio block receiver implementation
>> or I am doing something wrong.
>>
>> What are your thoughts about this?
>>
>> Thank you for your time.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/QPSK-phase-noise-tp22934944p22950446.html
>> Sent from the GnuRadio mailing list archive at Nabble.com.
>>
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>
>
>
> --
> Best wishes,
>
> Yufeng
>
>



-- 
Best wishes,

Yufeng


  ___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Simultaneous RX/TV with RFX2400

[Bishal Thapa]

Dear Michael and Jakub,
I was working on the similar problem. What about using two TX daughter
boards in the same motherboard, and BOTH TRANSMITTING  signals
simultaneously, one from each daughter board, but in an "overlapped"
fashion. Is it easily possible? What I mean is, I would like to have two
signals generated from two daughter boards plugged into the same motherboard
but interleaved in some fashion so that I can study the effect of that
interleaving on the receiver side (receiver is on a different host far from
these two simultaneously transmitting USRPs). Sorry if I am not being clear.
But I am guessing Michael and Jakub will understand what I am asking.

-Sincerely,
-Bishal.

On Mon, Apr 13, 2009 at 4:19 PM, Michael Dickens  wrote:

> Hi Jakub - 2 possibilities, depending on how one interprets your question:
>
> A) If what you mean is "using a single host computer that controls the two
> USRPs such that one transmits while the other receives and vice-versa, but
> never a single USRP both Tx and Rx simultaneously", then yes, that can be
> done; you could probably even use two host computers that sync the Tx/Rx in
> a MAC-like way using the current GNU Radio software, so long as each USRP is
> not trying to do simultaneous Tx and Rx.  If using a single host computer:
> on each USRP, you'd use set_auto_tr(true) and then control both USRPs from
> the same Python script.  My colleague Glenn has done this in a "TDMA
> fashion" to compare properties of actual and theoretical relays; see his MS
> thesis and related paper at UND < 
> http://www.nd.edu/~jnl/group/glenn-bradford/
> >.
>
> B) If what you mean is "simultaneous Tx/Rx on each USRP, using a single RFX
> and single antenna", then this problem is (1) possibly not do-able in the
> current state of GNU Radio software and USRP hardware; and (2) even if it is
> do-able, certainly not easily so in GNU Radio software without significant
> hacking to make it work.  The primary issue is in jointly estimating the
> channel parameters (both the Tx -> Rx delay and filter coefficients), which
> might be time-varying or dependent on qualities beyond the direct TX signal.
>  I'm happy to discuss this interpretation further off-list.
>
> Hope this helps! - MLD
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Simultaneous RX/TV with RFX2400

[Michael Dickens]

Hi Jakub - 2 possibilities, depending on how one interprets your  
question:


A) If what you mean is "using a single host computer that controls the  
two USRPs such that one transmits while the other receives and vice- 
versa, but never a single USRP both Tx and Rx simultaneously", then  
yes, that can be done; you could probably even use two host computers  
that sync the Tx/Rx in a MAC-like way using the current GNU Radio  
software, so long as each USRP is not trying to do simultaneous Tx and  
Rx.  If using a single host computer: on each USRP, you'd use  
set_auto_tr(true) and then control both USRPs from the same Python  
script.  My colleague Glenn has done this in a "TDMA fashion" to  
compare properties of actual and theoretical relays; see his MS thesis  
and related paper at UND < http://www.nd.edu/~jnl/group/glenn- 
bradford/ >.


B) If what you mean is "simultaneous Tx/Rx on each USRP, using a  
single RFX and single antenna", then this problem is (1) possibly not  
do-able in the current state of GNU Radio software and USRP hardware;  
and (2) even if it is do-able, certainly not easily so in GNU Radio  
software without significant hacking to make it work.  The primary  
issue is in jointly estimating the channel parameters (both the Tx ->  
Rx delay and filter coefficients), which might be time-varying or  
dependent on qualities beyond the direct TX signal.  I'm happy to  
discuss this interpretation further off-list.


Hope this helps! - MLD


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Communication Error using USRP with XCVR2450 Daughter-boards

[Ahmed Majeed Khan]

Hi All,
I am trying to communicate between two USRPs with XCVR2450 daughter-boards 
attached with two separate PCs. When I tried running benchmark_tx.py, an error 
appeared; 
"ValueError: No class defined to handle daughter-board (dbid = 96)"

Can any one please help me rectify the error. Waiting reply.

-Ahmed___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Wx openGL sinks and segmentation faults

[Josh Blum]

I would be interested in reports from other people, especially which 
chipsets/drivers segfault and which dont.


Stefan


I added this to the wxgui wiki page: 
http://gnuradio.org/trac/wiki/CompGrWxgui#GLSinks


There is a table with cards and known issues/solutions. Maybe we can get 
a few more problem cards to fill in and notice a pattern.


Testers needed!

-Josh


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] RTS and NAV functions (don't consider strict timing issues)

[Jane Chen]

Hi all,
 
I have two USRPs. I would like to implement some functions (RTS and NAV) 
in 802.11 MAC. Actually, I want to use RTS to control one of the nodes when to 
send out packets. When the node recieves the RTS, it should set up its NAV. 
Hence, the node will not send any packets out during the NAV. I read the codes 
in the BBN project and still have no idea how to implement the functions that I 
need.  Could anyone please give me some hints or examples to implement the 
funcations? 
 
    RTS
  Node1  -->   Node2 (after 
receives RTS, set up NAV)
 
   data
  Node1  <--   Node2 (after 
NAV, send out data)
 
 
Should I run both bbn_80211b_tx.py and bbn80211b_rx.py on each USRP? For 
example, I have Node1 and Node2.  Node1 run bbn_80211b_tx.py to send out RTS 
and  run bbn80211b_rx.py to receive data that sends from Node2. Node2 run 
bbn_80211b_tx.py to send out data and  run bbn80211b_rx.py to receive RTS that 
sends from Node1 and then set up NAV. 
 
I don't consider the strict timing issues of MAC at this moment. I only want to 
implement the functions. 
 
Thank you,
Jane


  ___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Wx openGL sinks and segmentation faults

[Eric Blossom]

On Mon, Apr 13, 2009 at 09:11:38AM -0700, Josh Blum wrote:
>
>
> A quick way to enable the gl sinks if not done so:
>
> mkdir ~/.gnuradio/
> echo [wxgui] >> ~/.gnuradio/config.conf
> echo style=gl >> ~/.gnuradio/config.conf
>
> -Josh

You're probably safer editing the file in your favorite editor, since
some of us have other settings in there ;-)

Eric


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Wx openGL sinks and segmentation faults

[Josh Blum]

The segfault can be avoided with LIBGL_ALWAYS_INDIRECT=1, eg,
$> LIBGL_ALWAYS_INDIRECT=1 usrp_oscope.py


thats very useful to know

Although this slows things down a little bit, it should still be faster than 
pure software rendering.


I would be interested in reports from other people, especially which 
chipsets/drivers segfault and which dont.




perhaps we can start a wiki page, with chip sets, error messages, 
versions, and recommendations.


Who else has GL working, or has GL issues, what is chipset?

A quick way to enable the gl sinks if not done so:

mkdir ~/.gnuradio/
echo [wxgui] >> ~/.gnuradio/config.conf
echo style=gl >> ~/.gnuradio/config.conf

-Josh


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Re: max throughput USB 2.0

[feldmaus]

Firas Abbas  yahoo.com> writes:

> 
> 
> Hi,
> 
> > On Mon, 4/13/09, feldmaus  gmx.de> wrote:
> > 
> > you are right, but why are we calculating with 32MByte/s
> > and not with 60MByte/s or something else ? 
> 
> Did you saw USRP FAQ? Always check before ask. See:
> http://gnuradio.org/trac/wiki/UsrpFAQ/Gen#USB:480MBitsec32MBytesec

Ahhh i understand.

Thanks that was i searched for. :-)

Regards Markus





___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Re: max throughput USB 2.0

[Firas Abbas]

Hi,

> On Mon, 4/13/09, feldmaus  wrote:
> 
> you are right, but why are we calculating with 32MByte/s
> and not with 60MByte/s or something else ? 


Did you saw USRP FAQ? Always check before ask. See:
http://gnuradio.org/trac/wiki/UsrpFAQ/Gen#USB:480MBitsec32MBytesec

And see also:
http://gnuradio.org/trac/wiki/ReportingErrors


Best Regards

Firas


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] basic questions about usrp_fft.py and usrp_oscope

[yufeng wang]

Hi,

Does anyone has some discription about the two programs usrp_fft.py
and usrp_oscope.py? I try to search in the archive but didn't find any
basic discriptions. For example, I'm using digital-bert
benchmark_tx.py to transmit a sequence of 1's, which modulated by
BPSK; on the other computer, I use python usrp_fft.py -f 900M -T B -R
TX/RX -d 32 to display the output.

I've some signals at the center frequency, but I don't know whether it
is the signals at the transmitter side usrp or signals received in the
other usrp? Similar question to usrp_oscope.py as well, and I also
wonder what do the two lines mean, the red one and the blue one?

Thanks in advance. Your help is highly appreciated.


-- 
Best wishes,

Y


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] os.popen broken pipe error

[Thomas Schmid]

python pipes are buffered. if your command produces a lot of output,
then the pipes can fill up, if you don't read from them. One solution
is to move to the subprocess module:

 http://docs.python.org/library/subprocess.html#module-subprocess

Cheers,

Thomas

On Sun, Apr 12, 2009 at 9:52 PM,   wrote:
>> On Sun, Apr 12, 2009 at 08:42:59PM -0400, satar...@eden.rutgers.edu wrote:
>>> Hi,
>>>
>>> I am trying to open one python script from another using the following
>>> code:
>>>
>>>
>>> command = 'python send.py -d %d -s %d -c %d -n %d -f trash_file.txt'
>>> %(dest_addr, sender_addr, cmd, seqno)
>>> os.popen(command)
>>>
>>> I get the broken pipe error for some reason. Can anyone please explain
>>> what is happening? Following are the file links if you want to reproduce
>>> the error:
>>
>> A "broken pipe" occurs when when you attempt to write on a pipe
>> without a reader (See man 7 pipe).
>>
>> You're not specifying the second argument to os.popen.
>> It defaults to 'r'.  Do you want 'w'?
>>
>> See the python library reference for more info.
>>
>>> http://www.eden.rutgers.edu/~aanchan/input.txt
>>> http://www.eden.rutgers.edu/~aanchan/send.py
>>> http://www.eden.rutgers.edu/~aanchan/transceiver.py
>>> http://www.eden.rutgers.edu/~aanchan/trash_file.txt
>>>
>>> I am calling send.py from transceiver.py. The txt files are used as
>>> inputs.
>>>
>>> thanks and regards,
>>>
>>> -Sumit
>>>
>>
>> Eric
>>
>
> I was surprised actually when I got the above mentioned bug because I had
> have always been giving only one argument, when I wanted the "command" to
> be executed on the shell. Anyway, the problem was actually solved when I
> stored the output of the above "command" in a text file (rx_ack_log.txt)
> as follows:
>
> command = 'python send.py -d %d -s %d -c %d -n %d -f trash_file.txt >>
> rx_ack_log.txt' %(dest_addr, sender_addr, cmd, seqno)
> os.popen(command)
>
> thanks for the help!
> regards,
> -Sumit
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>



-- 
"Don't complain; Just work harder" - Randy Pausch

Thomas Schmid, Ph.D. Candidate
Networked & Embedded Systems Laboratory (NESL)
University of California, Los Angeles (UCLA)


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] [benchmark_ofdm]

[rita pfc]

Thank you for your explanation,
I 've been reading documentation about ofdm in 802.11g, and now I know what
values I must put for the parameters. I added the size of the packet with
'-s', and it  worked.
Thanks


2009/4/8 Martin Braun 

> On Tue, Apr 07, 2009 at 10:32:20AM -0700, Rita's pfc wrote:
> >
> > Hi,
> > I'm using benchmark_ofdm tx and rx in 2.4 GHz. I'm trying to transmit a
> > fixed size of payload everytime (1328 Bytes). My problem is I don't know
> > what values I must put in the parameters: fft-length, occupied-tones,
> > cp-length. I know that fft-length is the total number of subcarriers, cp
> the
>
> Hi,
> just to be clear: fft-length is not the total number of subcarriers, it
> is, as the name says, the FFT length. If these were identical, it would
> be pretty difficult to filter out the OFDM signal as it would uniformly
> fill the Nyquist band.
> Sorry if this is what you meant, it jusn't wasn't quite clear to me.
>
> > cyclic prefix, occupied-tones number of subcarriers used for data. I have
> > been running modifications of these benchmarks, and the best performance
> I
> > get is when the values of these parameters are: fft-length 512, cp 128,
> > occupied tones 300. In this case, the 80 % of paquetes I receive are
> right.
> > How can I calculate the apropiate values ? Must I used the parameter "-s"
> > for fixed the packet size to the one I want, 1328? what happen with the
> "-i"
> > and "-d" in the transmitter and the receiver?
>
> The packet length and the OFDM settings are not directly connected -
> that is, in principle, you can have any combination (although that does
> not always make sense). In theory, GNU Radio works well with any OFDM
> setting, so all you have to do is adapt the settings according to your
> data transmission requirements (bit rate, channel characteristics etc.).
>
> I haven't got a working setup at my fingertips right now, but -s should
> be the right thing to do. However, note that the benchmark_ofdm* code
> uses the GNU radio packet module, which itself does stuff to your data,
> so perhaps your signal does not look exactly as you expected it to be.
>
> On a side note, when I was playing around with the OFDM benchmark code,
> I never achieved a brilliant packet error rate, 80% was close to the
> best I achieved - but I never tore the code apart to check for the
> cause.
>
> Good luck,
> MB
>
> --
> Dipl.-Ing. Martin Braun   Phone: +49-(0)721-608 3790
> Institut fuer Nachrichtentechnik  Fax:   +49-(0)721-608 6071
> Universitaet Karlsruhe (TH)   http://www.int.uni-karlsruhe.de/
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Wx openGL sinks and segmentation faults

[Stefan Bruens]

Hi,

I have noticed that I always get a segmentation fault if I use the openGL 
versions of the sinks. This seems to be dependent on the graphics chipset, I 
have two computers both with Intel G965.

The segfault can be avoided with LIBGL_ALWAYS_INDIRECT=1, eg,
$> LIBGL_ALWAYS_INDIRECT=1 usrp_oscope.py
Although this slows things down a little bit, it should still be faster than 
pure software rendering.

I would be interested in reports from other people, especially which 
chipsets/drivers segfault and which dont.

Stefan
-- 
Stefan Brüns  /  Bergstraße 21  /  52062 Aachen
phone: +49 241 53809034 mobile: +49 151 50412019


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Re: max throughput USB 2.0

[feldmaus]

Vincenzo Pellegrini  gmail.com> writes:

> 
> 
> Maximum sustained throughput that we have achieved so far, given our chipsets
and the USRP's cypress usb interfaceis 32 MB/sec that yields, at 16 bit sample
resolution
Hi Vincenzo,

you are right, but why are we calculating with 32MByte/s and not with
60MByte/s or something else ? 
>From where comes the 32MByte/s ?
 
USB 2.0 supports a maximum of 60MByte/s. And although our ADC can
handle 32MHz we coudle use 2Byte pro Sample so we get 64MByte/s.
This would be a little more than USB 2.0 can handle. But maybe there
is a solution to get near to 60MByte/s ?



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] why do i need gr-qtgui

[Eric Blossom]

On Mon, Apr 13, 2009 at 02:53:46AM -0400, davek wrote:
> can some one tell me what exactly does the gr-qtgui module add to gnuradio ?
> im having troubles getting it to compile, and if i don't really need
> it then why bother?
> the gui should still work without the qt libs correct?
> 

You don't need it.  GNU Radio offers lots of things, many of the
optional.  gr-qtgui is one of them.

Eric


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio