Usrp_sounder question

Hi all,

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.
  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.

Thanks

Qi Chen

On Tue, Apr 22, 2008 at 10:54 AM, Qi Chen [email protected] 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.

  1. 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 C.
Corgan Enterprises LLC
http://corganenterprises.com/

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs