I am using a pair of USRP2s, each equipped with a XCVR2450, for
transmission over-the-air of an RRC-filtered BPSK signal. The Tx antenna
has 3dBi gain, and the Rx antenna has 18 dBi gain. The transmitted
signal is at maximum amplitude, with gain set to 30 dB. The clocks on
each end of the link are running from the internal oscillators - i.e.
the clocks are not locked.
At the receive side, using an MM synchroniser and Costas loop, I am able
to see a BPSK constellation at the receiver when the Rx Gain setting is
30 dB.
The amplitude of the constellation points is around 0.15 in this
instance. However, when I increase the Rx Gain beyond 33 dB (in which
case the constellation is centered around +/- 0.2 on the scope sink),
there seems to be a large IQ amplitude balance, whereby the I signal is
much stronger. Indeed, the Q signal disappears entirely when the Rx Gain
is above around 36 dB.
Is this expected behaviour, and if so, can anyone please explain
why this is expected to occur?
able to see a BPSK constellation at the receiver when the Rx Gain
setting is 30 dB. The amplitude of the constellation points is around
0.15 in this instance. However, when I increase the Rx Gain beyond 33
dB (in which case the constellation is centered around +/- 0.2 on the
scope sink), there seems to be a large IQ amplitude balance, whereby
the I signal is much stronger. Indeed, the Q signal disappears
entirely when the Rx Gain is above around 36 dB.
Is this expected behaviour, and if so, can anyone please explain why
this is expected to occur?
I’m not sure exactly what you’re describing here, but I am pretty sure
it is not what I would call IQ imbalance. IQ imbalance would show up
before any frequency translation, so at the Costas loop output is not
where you would see it.
The purpose of a costas loop is to track the phase of the incoming
signal. That means that the majority of the energy in a BPSK signal
will be in I and little will be in Q when the loop is locked. The
stronger the signal and the better the SNR, the smaller the Q amplitude
will be relative to the I signal.
Having seen your reply, I realise I was not clear in my original post.
At the time I observed this error, it was even at the output of the RRC
filter, i.e. prior to the MM synch. and Costas loop. The strange thing
is, now I am unable to repeat this problem. Instead, now I see clipping
of both the I and Q components when I increase the Rx gain beyond a
particular level.
While on this matter, is there any risk of damaging the equipment by
simply setting the Rx gain too high, or is clipping the only
consequence?
As long as the input level is in the safe range, having too much gain
would probably not damage anything. On the WBX, however, too much gain
with a strong but normally safe level might be a problem.
Can you please confirm by input level you are referring to the input to
the transceiver daughterboard? I am using the XCVR2450, for over-the-air
reception. The input level (to the XCVR2450 at the receiver) would have
been roughly:
As far as I can tell based on the above (presuming the 20 dBm transmit
power is based on max. gain setting for the Transmitting XCVR2450), the
largest signal I could have at the Rx port after the Rx antenna is:
20 + 3 - 46 + 14 = -9 dBm
So, if this is the case, I presume all was safe regardless of the chosen
Rx gain setting for the receiving daughterboard.
Can you please confirm if this would be the case, as I am encountering
inconsistent behaviour with my equipment (such as the unrepeatable error
mentioned earlier, and occasional fails to lock at 5 GHz without first
trying to lock to a much lower frequency).
As far as I can tell based on the above (presuming the 20 dBm transmit
power is based on max. gain setting for the Transmitting XCVR2450), the
largest signal I could have at the Rx port after the Rx antenna is:
20 + 3 - 46 + 14 = -9 dBm
So, if this is the case, I presume all was safe regardless of the chosen
Rx gain setting for the receiving daughterboard.
Yes, -9 dBm is safe.
Can you please confirm if this would be the case, as I am encountering
inconsistent behaviour with my equipment (such as the unrepeatable error
mentioned earlier, and occasional fails to lock at 5 GHz without first
trying to lock to a much lower frequency).
I have not seen the problem locking without trying a lower frequency.
What if you try 5 GHz twice in a row?
I have not seen the problem locking without trying a lower frequency.
What if you try 5 GHz twice in a row?
The problem with the not locking to 5G is very intermittent. A few times
when it did occur, I tried your suggestion of trying 5G a second time:
2 out of 3 times, it locked the second time. The other time, it did not,
but then trying 2.35G followed by 5G did then work.
Regarding the other intermittent issue that appeared as IQ imbalance, I
have swapped the USRP2/XCVR2450 pair used for transmit with the receive
one, and haven’t observed the issue since. It may still occasionally
occur for the first pair, but this is a workaround for me. I am still
confused as to why it occurred to begin with.
I am measuring IQ imbalance. The values are generally quite good.
However, one thing I don’t understand is that the mirror frequency
doesn’t turn up on exactely “-f” but a few Hertz off. I don’t get this.
Are we sure that the down-conversion on the FPGA is completely turned off ?
No, the down converter is not. The way the tune command works is that
the daughterboard code tries to get as close as possible to the
requested frequency. It returns the actual frequency which it tuned to,
not the requested one, and these can be as much as about 100 Hz
different. The next layer up tunes the CORDIC to remove that remaining
frequency offset. If you modify the daughterboard code to return the
requested frequency instead of the actual frequency, that delta will be
zero and the cordic will be effectively disabled.
I also have a xcvr2450 that won’t lock sometimes. This is at 2.4GHz.
Also an issue about IQ imbalance:
I am measuring IQ imbalance. The values are generally quite good.
However, one thing I don’t understand is that the mirror frequency
doesn’t turn up on exactely “-f” but a few Hertz off. I don’t get this.
Are we sure that the down-conversion on the FPGA is completely turned off ?
What size FFT are you using to see the mirror freq? What is the
bandwidth of the data into the FFT? From this you
could calculate Hz/bin and see if that helps to explain the offset.
I also have a xcvr2450 that won’t lock sometimes. This is at 2.4GHz.
Also an issue about IQ imbalance:
I am measuring IQ imbalance. The values are generally quite good.
However, one thing I don’t understand is that the mirror frequency
doesn’t turn up on exactely “-f” but a few Hertz off. I don’t get this.
Are we sure that the down-conversion on the FPGA is completely turned
off ?
BR/
Per
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.