Overrun problem on gr-sounder project

Hi Johnathan,

I’m modifying the gr-sounder project to transmit a 113-bit legendre
sequence of the bandwith 32kHz and upconvert to certain frequency in the
range 1MHz to 20MHz. At receiver side, the received signal is
downconverted to baseband and store the received sequence into a data
file.

The daughterbaord I’m using is LFTX/LFRX.

I modified the FPGA configuration by using clk_divider to downconvert
the mater_clock, clk64 to 32kHz, and applied the 32kHz to module
adc_interface, sounder,rx_buffer, dac_interface instead of clk64. The
other modules still keep the chip-rate(clk64) as the working frequency.
At the receiver side, I got rid of the correlation part, made the
receiver directly store the received data into rx_buffer.

The result shows some USRP overrun signs (uO), and the received data is
as shown below:
 -1 - 1i
 -1 + 0i
  0 + 0i
  0 + 0i
  0 + 0i
  0 - 1i
 -1 - 1i
 -1 - 1i
 -1 - 1i
  0 + 0i
  0 + 0i
  0 + 0i
  0 + 0i
 -1 - 1i
 -1 - 1i
 -1 - 1i
 -1 + 0i
  0 + 0i
  0 + 0i
  0 + 0i

However, the frequency of baseband data should be 32kHz, which doesn’tÂ
exceed the maximum USB data rate 8MHz, why the USRP overrun?Â

The received data should be the amplitude of the code, 4096, and the
data should be real part only. What is the possible reason why the
received data is as the shown.

Thank you so much!

Regards,
Yan

On Thu, Apr 22, 2010 at 09:21, Yan N. [email protected] wrote:

I’m modifying the gr-sounder project to transmit a 113-bit legendre sequence
of the bandwith 32kHz and upconvert to certain frequency in the range 1MHz
to 20MHz. At receiver side, the received signal is downconverted to baseband
and store the received sequence into a data file.

There is no way to diagnose what you are doing incorrectly, as you are
writing your own modified FPGA code.

However, my question to you is–why are you doing this in the FPGA at
all? The gr-sounder component was designed as a way of processing a
very wide bandwidth signal (up to the full baseband bandwidth of the
daughterboard in use). Due to limitations in the transport speed of
USB, this can only be done on the FPGA.

You describe a baseband waveform of 32 ksps, and you are storing the
received signal samples to a file. Why don’t you just use the stock
FPGA image and write a simple GNU Radio application?

Johnathan

writing your own modified FPGA code.
You describe a baseband waveform of 32 ksps, and you areÂ
storing the
received signal samples to a file. Why don’t you just useÂ
the stock
FPGA image and write a simple GNU Radio application?

Thank you so much Johnathan.Â

If writing a new GNU Radio application which implement the same
functionality as what you did in gr-sounder, is there any existing
project in GNURadio packet, which I can refer to? I’m doing the very
similar thing as what you did in gr-sounder, transmitting a 113-bit
sequence of the frequency 32kHz modulated as BPSK with the user provided
center frequency. The received signal is down converted to baseband and
directly stored in a data file.

Thank you againÂ

Regards,
Yan

Hi Johnathan,

Thank you so much for the response on the suggestion of BPSK modulation
implementation. I still have some questions on FPGA configuration and
USRP baord:

  1. What signal on the input of the receiver side (rx_a_a and rx_b_a) in
    gr-sounder application? (should the 12-bit signal be the amplitude of
    the received signal, which corresponds to the amplitude the usr
    provided?)

  2. How does the tune() function work? Does that tune the signal after
    ADC, by creating a analog daughterboard? or it tunes the signal on the
    LFRX daughterboard  before ADC?

Thank you so much!

Regards,
Yan

On Thu, Apr 22, 2010 at 4:38 PM, Yan N. [email protected] wrote:

  1. How does the tune() function work? Does that tune the signal after ADC,
    by creating a analog daughterboard? or it tunes the signal on the LFRX
    daughterboard before ADC?

I looked at the source and found the following.

/*!

  • \brief High-level “tune” method. Works for the single channel
    case.
  • This method adjusts both the daughterboard LO and the DDC so that
  • target_freq ends up at DC in the complex baseband samples.
  • \param chan which DDC channel we’re controlling (almost always 0).
  • \param db the daughterboard we’re controlling.
  • \param target_freq the RF frequency we want at DC in the complex
    baseband.
  • \param[out] result details how the hardware was configured.
  • \returns true iff everything was successful.
    */

Thomas

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