Re: [Discuss-gnuradio] Problem with capture playout WBX daughterboard USRP N210

[Bastien Auneau]

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

On 2011-08-23 16:59, Marcus D. Leech wrote:
> On 23/08/2011 2:28 PM, Bastien Auneau wrote:
>> Hi Josh
>>
>> I'll stop flying blind for now
>> But I'm not sure what else can be done ?!
>>
>> We are using USRP to create a DVB-RCS terminal
>> We already have a commercial product using another HW platform
>> We are now moving this product to the USRP N210 platform
>> UHD programming has been mostly done, especially regarding time settings
>> (as DVB-RCS is TDMA).
>> To make it short, we now have a proto-terminal that can transmit data at
>> required time using timestamp. Next step is to send some hard coded
>> data, to ensure that the system is fine (especially the time stability,
>> using DVB-RCS burst receiver as time reference). Following step is to
>> actually create the burst to send (coding and modulation done in
>> mathlab).
>>
>> So we want now to send some hard coded data (a specific burst). In order
>> to test the system and avoid problem on the burst generation side. The
>> idea is to capture for a couple of second, a signal that contain wanted
>> burst. Then use these captured burst to transmit theme at regular
>> interval.
>>
>> To do that, we are using the example script to capture the data (and the
>> tx example to test that captured data is correct)
>> There is no processing of the file, except for what the provided
>> examples do.
>>
>> We tried first to capture a signal from a DVB-RCS commercial terminal
>> that we own, but this did not work. Then tried the same with a live
>> signal from the air.
>>
>> When did it go wrong ?
>> Why playing out data just captured (using strictly same parameters) is
>> "flying blind" ?
>> Do you have any suggestion on how to acquire a burst for later use
>> (except generating it, as we want to avoid that for now)?
>>
>> Best Regards
>> Bastien
>>
>>
>>
>>
>> On 08/23/2011 10:36 AM, Bastien Auneau wrote:
>>> 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
>>>
>> Here is my take on your method:
>> http://gnuradio.org/redmine/projects/gnuradio/wiki/CannedResponses#Flying-Blind
>>
>>
>> -josh
> I think Josh' "flying blind" comments apply to the debugging methodology
> here.  If I had this problem, instead of streaming the
>   samples to a file, then playing them back immediately, I'd use
> something like uhd_fft.py to grab a spectra sample of the incoming
>   data, and confirm that spectrally, it looks "right".
> 
> Once I'd done that, I'd construct a flow-graph that takes samples from
> the file, and along with sending them to the USRP2, I'd again
>   plot them on an FFT display within the flow-graph, to make sure, once
> again, that they're as expected.
> 
> Also, keep in mind that the WBX has a hardware AGC loop in the TX path,
> that can cause "pulsating levels" for some types of transmissions,
>   particularly at high transmit levels.
> 
> 
> 
> 
>