Amplitude settings in uhd_siggen

GNU Radio
1

In uhd_siggen_gui tool, u cant set signal amplitude more than 1. Is
there any
reason behind this?

I commented out the code where the limit checking is done. Then, when I
increase the amplitude of the transmitted signal beyond 1, I dont see
any
change in amplitude of the recieved signal. What is the cause of this
restriction?

Thanks

–
View this message in context:
http://gnuradio.4.n7.nabble.com/Amplitude-settings-in-uhd-siggen-tp52274.html
Sent from the GnuRadio mailing list archive at Nabble.com.

2

On 02/10/2015 10:15 AM, zealdeal wrote:

In uhd_siggen_gui tool, u cant set signal amplitude more than 1. Is there any
reason behind this?

I commented out the code where the limit checking is done. Then, when I
increase the amplitude of the transmitted signal beyond 1, I dont see any
change in amplitude of the recieved signal. What is the cause of this
restriction?

Like the audio blocks, the UHD blocks normalize float data for 1.0 to be
full scale. So, you want to stay way below 1.0, in all cases. Going
above will cause clipping.

To further increase the signal amplitude, increase the Tx gain. Max Tx
gain can, in some cases, cause distortions but that depends on signal
shape etc. You would be able to see this on a spectrum analyzer
(clipping in particular very obviously distorts the spectrum).

M

3

On 02/11/2015 10:38 AM, zealdeal wrote:

Is this clipping behaviour specific to uhd_siggen? Earlier I have tried to
increase the amplitude of an OFDM subcarrier to more than 1.0 and saw linear
increase in received amplitude. Clipping took place at quite a high
amplitude.

No, 1.0 maps to FS for USRP blocks. In the OFDM example, watch the
amplitude of the signal before it enters the USRP sink. If it exceeds
1.0, I promise it will clip (and you will see this with a spectrum
analyzer).

M

4

Is this clipping behaviour specific to uhd_siggen? Earlier I have tried
to
increase the amplitude of an OFDM subcarrier to more than 1.0 and saw
linear
increase in received amplitude. Clipping took place at quite a high
amplitude.

–
View this message in context:
http://gnuradio.4.n7.nabble.com/Amplitude-settings-in-uhd-siggen-tp52274p52283.html
Sent from the GnuRadio mailing list archive at Nabble.com.

5

On 02/11/2015 03:05 AM, Martin B. wrote:

M
zealdeal could be talking about the amplitude of an OFDM carrier
before the IFFT.

Ron

6

Ah well, in that case, the energy of only one increased subcarrier will,
due to Parseval’s Theorem, still be present in the time signal, but be
split across all samples in the OFDM symbol (IDFT).

Anyway, in a practical system you’d limit the power-per-subcarrier, so
that no combination of subcarrier symbols can lead to time domain peaks
that get clipped.

Greetings,
Marcus

7

On 02/11/2015 12:12 PM, Ron E. wrote:

No, 1.0 maps to FS for USRP blocks. In the OFDM example, watch the
amplitude of the signal before it enters the USRP sink. If it exceeds
1.0, I promise it will clip (and you will see this with a spectrum
analyzer).

M
zealdeal could be talking about the amplitude of an OFDM carrier
before the IFFT.

I have the same suspicion, hence my recommendation of checking the final
output signal.
The rx_ofdm GRC example has a scope at the relevant position for this
reason.

M

8

I’m bit confused here.

You said “In the OFDM example, watch the amplitude of the signal before
it
enters the USRP sink. If it exceeds 1.0, I promise it will clip”

I transmitted OFDM symbols, keeping transmission amplitude as 0.2

Then, on the collected log, I ran gr_plot_ofdm.py tool. It shows the
plot of
transmitted signal in time domain.

I see that the amplitude is much more than 1 in that plot.

Could please tell me where am I going wrong?

–
View this message in context:
http://gnuradio.4.n7.nabble.com/Amplitude-settings-in-uhd-siggen-tp52274p52337.html
Sent from the GnuRadio mailing list archive at Nabble.com.

9

On 02/17/2015 08:21 AM, zealdeal wrote:

I see that the amplitude is much more than 1 in that plot.

Could please tell me where am I going wrong?

I’m not even entirely sure what gr_plot_ofdm.py does.
If your signal amplitude is smaller than 1.0 before it goes to the
usrp_sink, you’re good.

Cheers,
M

10

Dear Zealdeal,

you should know how OFDM works: An OFDM symbol is nothing more than the
IDFT of a vector of permutated, possibly padded symbols.
No, for the sake of a simple example, assume your symbol vector is
[1,1,1,…,1]; without doubt, you’ll notice that the IDFT of that vector
has an entry that exhibits a magnitude much larger than 1, whilst the
other elements of the IDFT have a much smaller magnitude (should be 0!).
This uneven distribution of power in time domain is a problem so common
to all OFDM systems that there is a fixed term coined for that: the PAPR
(peak/average power ratio); I’m pretty sure that you’ve stumbled across
that in whatever introduced you to OFDM.

Best regards,
Marcus