Hi All,
I am trying to send a GSM modulated signal using the USRP and the RFX900
board using the ‘tune’ function as in the provided usrp examples:
r = self.u.tune(self.subdev._which, self.subdev, target_freq)
The desired frequency is 925.6MHz, and I am getting a -381.47m
residual_frequency as shown below.
What will be the best way to correct that, so I get the signal modulated
to
the desired frequency?
Thanks in advance to all for your help!
—8<----
Using TX d’board A: Flex 900 Tx MIMO B
r.baseband_freq = 930M
r.dxc_freq = -4.4M
r.residual_freq = -381.47m
r.inverted = False
After doing some experiments I came out with another more important
problem…
Instead of my previous frequency that gave some residual, I tried the
integer frequency 926M, so I get:
Using TX d’board A: Flex 900 Tx MIMO B
r.baseband_freq = 930M
r.dxc_freq = -4M
r.residual_freq = 0
r.inverted = False
The issue is that on the spectrum analyzer I get the signal centered at
930
and not 926M.
Any clue why the r.dxc offsset is not working? I check the ‘tune’
function
and it should do…
Thanks!
On Fri, Apr 18, 2008 at 3:38 PM, Wireless Monster <
On Fri, Apr 18, 2008 at 03:38:37PM -0400, Wireless Monster wrote:
Hi All,
I am trying to send a GSM modulated signal using the USRP and the RFX900
board using the ‘tune’ function as in the provided usrp examples:
r = self.u.tune(self.subdev._which, self.subdev, target_freq)
The desired frequency is 925.6MHz, and I am getting a -381.47m
residual_frequency as shown below.
Note that that’s 381.47 milli Hz == 0.381 Hz. There’s nothing you
have to do about it.
r.residual_freq = -381.47m
r.inverted = False
Eric
Hi Eric,
Thank you for your help.
You are right 0.384Hz is nothing to worry about 
I misunderstood the
‘m’
Regarding the frequency I finally found where the problem comes from:
After the gmsk modulation (blks2.gmsk_mod) I have to scale the value
(for
example by multiplying it by 8000) before sending it to the USRP to get
the
resulting signal centered at the right frequency. If don’t do it the
output
signal is shifted… I assume some minimum signal level is needed in the
FPGA blocks to work correctly.
Rgds,
On Fri, Apr 18, 2008 at 07:38:15PM -0400, Wireless Monster wrote:
r.inverted = False
The issue is that on the spectrum analyzer I get the signal centered at 930
and not 926M.
Any clue why the r.dxc offsset is not working? I check the ‘tune’ function
and it should do…
Thanks!
If you use usrp_siggen.py does the signal end up where you expect?
If so, the problem’s somewhere in your code.
I’m not very good at mind reading…
Eric
On Mon, Apr 21, 2008 at 5:21 PM, Wireless Monster
[email protected] wrote:
After the gmsk modulation (blks2.gmsk_mod) I have to scale the value (for
example by multiplying it by 8000) before sending it to the USRP to get the
resulting signal centered at the right frequency. If don’t do it the output
signal is shifted… I assume some minimum signal level is needed in the
FPGA blocks to work correctly.
So a linear operation resulted in a change in frequency?
Uh oh…
On Mon, Apr 21, 2008 at 2:21 PM, Wireless Monster
[email protected] wrote:
After the gmsk modulation (blks2.gmsk_mod) I have to scale the value (for
example by multiplying it by 8000) before sending it to the USRP to get the
resulting signal centered at the right frequency. If don’t do it the output
signal is shifted… I assume some minimum signal level is needed in the
FPGA blocks to work correctly.
The “full scale” output to the RFX boards is ±32767.0. It is not
recommended that you actually use this, as it will drive the RFX
output stages into a strongly non-linear operating range, increasing
noise and spurious signals significantly. From empirical
measurements, the RFX boards can only get to about 15% full scale
before they go into gain compression. That would be about ±5000 into
usrp.sink_c.
It’s likely that what you were seeing before was a spur from the local
oscillator feedthrough of the mixer, can be up to 4 MHz away from your
requested frequency. Once you sent a waveform of significant
amplitude out to the card, you then saw it instead of the spur (which
was still there, but much lower in power). So it looks like one
signal “shifted” somehow, but was really two different signals.
–
Johnathan C.
Corgan Enterprises LLC
http://corganenterprises.com/
On Mon, Apr 21, 2008 at 6:16 PM, Johnathan C.
[email protected] wrote:
The “full scale” output to the RFX boards is ±32767.0. It is not
recommended that you actually use this, as it will drive the RFX
output stages into a strongly non-linear operating range, increasing
noise and spurious signals significantly. From empirical
measurements, the RFX boards can only get to about 15% full scale
before they go into gain compression. That would be about ±5000 into
usrp.sink_c.
Just for the knowledge of the list and to better understand the
hardware, in the application defined by the original poster a
constant envelope GMSK signal is being used.
With that being said:
a) Should the compression of the output stages really affect his
constant envelope GMSK signal?
b) Is there any future enhancement scheduled to feed the
daughterboard a normalized signal with a “backoff” in dB which will
try to ensure linearity?
The answer to (a) is just for my own curiosity whereas the answer to
(b) might be helpful for people investigating OFDM, or M-QAM signals
where the PAPR might be upwards of 10 to 12 dB.
Brian
On Mon, Apr 21, 2008 at 5:06 PM, Brian P. [email protected]
wrote:
a) Should the compression of the output stages really affect his
constant envelope GMSK signal?
Not directly. However, by operating a normally linear amplifier in
gain compression, the third-order mixing products of the signal and
any spurs and noise will be disproportionately higher than if the
amplifier were run in its linear range.
b) Is there any future enhancement scheduled to feed the
daughterboard a normalized signal with a “backoff” in dB which will
try to ensure linearity?
Well, not this specifically. It would be a matter of calibration
anyway, as the 1dB gain compression point of the output stages would
likely be different from board to board.
We’re of course open to suggestions.
–
Johnathan C.
Corgan Enterprises LLC
http://corganenterprises.com/