Transmission from usrp1 vs. usrp2


I have code that modulates and transmits a DBPSK signal, and code that
receives and processes the signal. Both sides work fine on the USRP1.
Once I
got my hands on some USRP2’s, I modified my code such that it works on
new hardware. However, the spectral output of the USRP2 is decidedly
different than the output of the USRP1. More specifically, the power
distribution of various frequencies is different, and there is
more out-of-band power than with the USRP1. I am using RFX dboards.
that I am transmitting the same, synthesized waveform stored on the hard
disk, I would expect (nearly) identical spectral output, but broadened
response to the increase in sample rate. Is is possible that the
on the U2’s DAC is less aggressive than that of the U1’s? Is there some
other obvious explanation?


Here is the FFT output of the two devices.


On Tue, 2009-08-11 at 09:38 -0600, Jordan J Riggs wrote:

Here is the FFT output of the two devices.

This looks like gain compression or even clipping on the USRP2.

The dynamic range of samples to be sent to the usrp.sink_c block for the
USRP1 is ± 32767.

The dynamic range of samples to be sent to the usrp2.sink_32fc block for
the USRP2 is ±1.0.

In either case, the RFX boards go into gain compression in the upper 20
dB or so of their transmit range, so if you have a modulation which
requires linear frequency response (e.g., filtered BPSK), you need to
restrict the sample amplitude to ± 3000 or so for USRP1 and += 0.1 or
so for USRP2.

If you are in fact sending the same actual sample range valid for the
USRP1 (±32767) into the USRP2 sink, you will of course get severe
distortion as the sink will clip this to a ±1.0 square wave.


YES. I also found this fact that the dynamic ranges of two usrps are so
different, just in these days.

Furthermore, the range of usrp.source_32fc is also ±1.0, right? Because
found the sample amplitude is very small when I use observe
same RF input on USRP2, compared with on USRP.


2009/8/11, Johnathan C. [email protected]:

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