Problem with capture playout WBX daughterboard USRP N210

Hi All

Using USRP N 210, WBX board, GPSDO, UHD 3.2.2, under Windows 7

We want to use the example scripts to capture then playout a signal we
get from the air (satellite link with bursts). We proceed as follow :

  1. capture using rx_samples_to_file.exe --type short --rate 10000000
    –freq 1057232000 --gain 10

  2. playout the newly captured file
    tx_samples_from_file.exe --type short --rate 10000000 --freq 1057232000
    –gain 2

  3. Using a spectrum analyzer, we expect to see similar things when
    looking at signal from air (few small carriers, bursty), than when
    looking at USRP played out signal.

But the USRP only output an around 2.5 MHz carrier, which does not
contains the burst of the original carrier (looking on live signal the
centered carrier constantly goes up and down). The carrier is extremely
steady during all the playout time. Also, the doc
(http://www.ettus.com/downloads/ettus_daughterboards.pdf) specifies
30MHz bandwidth, why can’t we see the same bandwidth from played out
signal than from original signal ?

Also, we use the rx/tx port of the WBX board to capture then to playout

Regards
Bastien

On 08/23/2011 10:36 AM, Bastien Auneau wrote:

tx_samples_from_file.exe --type short --rate 10000000 --freq 1057232000
(http://www.ettus.com/downloads/ettus_daughterboards.pdf) specifies
30MHz bandwidth, why can’t we see the same bandwidth from played out
signal than from original signal ?

Also, we use the rx/tx port of the WBX board to capture then to playout

Here is my take on your method:
http://gnuradio.org/redmine/projects/gnuradio/wiki/CannedResponses#Flying-Blind

-josh

Thanks for the advice
The thing is we want to use pure UHD, no gnuradio or flow graph…
We already have done many test using labview and Gnu Radio Companion

Also, by increasing the gain on capture (using rx_samples_to_file.exe)
we get a better signal. When playing out, we can actually see small
bursty carriers on the spectrum analyzer, as we see with the original
(live) signal.

The problem now is that there is a high and thin bell shaped carrier in
the center frequency, as added on top of what is recorded. It looks
similar to
http://lists.gnu.org/archive/html/discuss-gnuradio/2010-12/msg00432.html
except there are no harmonics. the top of this bell shaped carrier
reached -20db

Regards
Bastien

Also regarding the bell shaped high and thin carrier that is added on
top of sampled signal. My colleague noticed that this bell shaped
carrier is present in the .dat file. So it is not a tx problem. He looks
at the .dat file using some FFT (FFT power spectrum), running through
the samples. (I guess this is what Marcus said. We are doing it also, I
just did not know that was an FFT…)

Regards
Bastien

On 23/08/2011 3:18 PM, Bastien Auneau wrote:

Thanks for the advice
The thing is we want to use pure UHD, no gnuradio or flow graph…
We already have done many test using labview and Gnu Radio Companion
In which case, you should probably be posting your questions to
usrp-users, instead of this list.

http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Gnu Radio has lots of built-in tools to assist in debugging/developing
this type of system, but if you don’t/won’t use them, then this is
clearly not the right place to post your queries.

To use a proximal metaphor, posting queries about Java usage on a C
programmers list may net you some answers from people
who are well-versed in both, but you’ll get better satisfaction by
posting to the correct list.

On 08/23/2011 12:18 PM, Bastien Auneau wrote:

Thanks for the advice
The thing is we want to use pure UHD, no gnuradio or flow graph…
We already have done many test using labview and Gnu Radio Companion

You are mailing the gnuradio mailing list. You cant blame me for
recommending you to use gnuradio…

Also, by increasing the gain on capture (using rx_samples_to_file.exe)
we get a better signal. When playing out, we can actually see small
bursty carriers on the spectrum analyzer, as we see with the original
(live) signal.

Well, what does the captured signal look like on the host; ie before you
re-transmit it? Screen shots would help.

-josh

On 23/08/2011 3:49 PM, Bastien Auneau wrote:

Best Regards

My suspicion would be DC offset. UHD has facilities for offsetting away
from the LO so that your signal of interest is well away from DC.

This is an inherent “problem” in direct-conversion receivers. There
will always be some unwanted LO leakage, which always cause
some amount of DC offset, not all of which can be cancelled. For
wide-band signals, you can often simply ignore it, since it constitutes
such a small fraction of your overall signal. Or you can high-pass
your signals, or notch it out, or you can shift the LO. It’s typically
very
narrow, and whether it appears at all is dependent on a number of
factors, including degree of LO leakage, and amplitude and
phase balance of the analog mixers at the frequency of interest.

When you construct a tune_request in your UHD-only C++ code, you can
specify the desired LO offset. Consult the UHD Doxygen
documents for more details.

When you construct a tune_request in your UHD-only C++ code, you can
specify the desired LO offset. Consult the UHD Doxygen
documents for more details.

You can call uhd.tune_request(freq, lo_offset) in grc

:slight_smile:

Thanks again for the answer
Posting on both Discuss Gnuradio and USRP User. So far never got answer
from USRP User list… So I stick on Gnu Radio

Here is a screenshot of the the FFT. You can see some of the small
bursty carriers on the right, but also this huge peak in the middle.

We also transmitted some data on a different frequency that what we
capture, to be sure this peak is not due to echo of the tx to the rx.

Best Regards