discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio]usrp_sounder question


From: Johnathan Corgan
Subject: Re: [Discuss-gnuradio]usrp_sounder question
Date: Tue, 22 Apr 2008 11:46:27 -0700

On Tue, Apr 22, 2008 at 10:54 AM, Qi Chen <address@hidden> wrote:

>  I have a question about the usrp_sounder. I realized that it uses a custom
> fpga bit file to avoid the USB I/O bottleneck entirely, which makes sense to
> me. So if I would like to do off-line processing (cross-correlation, and
> etc) instead of real-time, I would use usrp_rx_cfile.py to read data off of
> the usrp. My questions are:

>  1. where exactly does this python program read data from? does it always
> read data after the ADC or it depends.

In the standard build, the 64 Msps samples from the ADC are passed
through a low pass filter and decimated by a minimum factor of 8,
resulting in a maximum of 8 Msps complex baseband over the USB.  This
is about 8 MHz of bandwidth, though there is some droop on the ends
from the filter.

Since the gr-sounder transmitter creates a 32 Mchip/s waveform, the
resultant bandwidth is much to high to receive using the standard FPGA
build.

>  2. If I set one usrp to be the transmit sounder, which constantly sending
> out m-sequences, and I could read data off of the ADC, would the results
> make any sense if I do off-line processing? For example, I generate an
> m-sequence of the same length and cross-correlate it with the received
> sequence.

You need to generate the m-sequences at a slower chip-rate on the TX
side such that the bulk of the energy is in 8 MHz.  You could do this
with a GNU Radio flowgraph that sends a bipolar m-sequence to the USRP
at an interpolation rate of 32, equivalent to a 4 Mchip/second BPSK
waveform.  The central lobe of this signal will be 8 MHz wide (unless
you are at baseband).  The gr.glfsr_source_b block can generate the
m-sequence but it needs to be converted to bipolar floats for the
usrp.sink_c() to use.  The noise.py audio example actually shows how
to do this to output noise at audio frequencies to the speakers.

Your offline processing will need to correlate the received signal
with the m-sequence, resulting in the (noisy) impulse response for the
channel.  Beware, though, that coherently averaging successive impulse
responses is difficult because the frequency/timing offset between the
two USRP crystals will cause the correlation peak to move from record
to record. (This same problem occurs even more severely with
gr-sounder, due to non-optimal way the FPGA does the correlation.)

-- 
Johnathan Corgan
Corgan Enterprises LLC
http://corganenterprises.com/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]