# Amplitude settings in uhd\_siggen **URL:** \ **Category:** GNU Radio\ **Created:** [February 10, 2015, 10:23am UTC](https://www.ruby-forum.com/t/amplitude-settings-in-uhd-siggen/234149 "2015-02-10T10:23:32Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![addis\_a](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/c4cdca/32.png) [@addis\_a](https://www.ruby-forum.com/u/addis_a)\ **Post date:** [February 10, 2015, 10:23am UTC](https://www.ruby-forum.com/t/amplitude-settings-in-uhd-siggen/234149/1 "2015-02-10T10:23:32Z")
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](http://gnuradio.4.n7.nabble.com/Amplitude-settings-in-uhd-siggen-tp52274.html) Sent from the GnuRadio mailing list archive at [Nabble.com](http://Nabble.com). ---
**Author:** ![zealdeal](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/z/ecb155/32.png) [@zealdeal](https://www.ruby-forum.com/u/zealdeal)\ **Post date:** [February 10, 2015, 4:12pm UTC](https://www.ruby-forum.com/t/amplitude-settings-in-uhd-siggen/234149/2 "2015-02-10T16:12:29Z")
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 ---
**Author:** ![zealdeal](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/z/ecb155/32.png) [@zealdeal](https://www.ruby-forum.com/u/zealdeal)\ **Post date:** [February 11, 2015, 12:06pm UTC](https://www.ruby-forum.com/t/amplitude-settings-in-uhd-siggen/234149/3 "2015-02-11T12:06:34Z")
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 ---
**Author:** ![zealdeal](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/z/ecb155/32.png) [@zealdeal](https://www.ruby-forum.com/u/zealdeal)\ **Post date:** [February 11, 2015, 10:46am UTC](https://www.ruby-forum.com/t/amplitude-settings-in-uhd-siggen/234149/4 "2015-02-11T10:46:44Z")
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](http://gnuradio.4.n7.nabble.com/Amplitude-settings-in-uhd-siggen-tp52274p52283.html) Sent from the GnuRadio mailing list archive at [Nabble.com](http://Nabble.com). ---
**Author:** ![zealdeal](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/z/ecb155/32.png) [@zealdeal](https://www.ruby-forum.com/u/zealdeal)\ **Post date:** [February 11, 2015, 12:13pm UTC](https://www.ruby-forum.com/t/amplitude-settings-in-uhd-siggen/234149/5 "2015-02-11T12:13:52Z")
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 ---
**Author:** ![zealdeal](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/z/ecb155/32.png) [@zealdeal](https://www.ruby-forum.com/u/zealdeal)\ **Post date:** [February 11, 2015, 12:28pm UTC](https://www.ruby-forum.com/t/amplitude-settings-in-uhd-siggen/234149/6 "2015-02-11T12:28:41Z")
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 ---
**Author:** ![zealdeal](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/z/ecb155/32.png) [@zealdeal](https://www.ruby-forum.com/u/zealdeal)\ **Post date:** [February 11, 2015, 4:01pm UTC](https://www.ruby-forum.com/t/amplitude-settings-in-uhd-siggen/234149/7 "2015-02-11T16:01:42Z")
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 ---
**Author:** ![zealdeal](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/z/ecb155/32.png) [@zealdeal](https://www.ruby-forum.com/u/zealdeal)\ **Post date:** [February 17, 2015, 8:29am UTC](https://www.ruby-forum.com/t/amplitude-settings-in-uhd-siggen/234149/8 "2015-02-17T08:29:57Z")
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](http://gnuradio.4.n7.nabble.com/Amplitude-settings-in-uhd-siggen-tp52274p52337.html) Sent from the GnuRadio mailing list archive at [Nabble.com](http://Nabble.com). ---
**Author:** ![zealdeal](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/z/ecb155/32.png) [@zealdeal](https://www.ruby-forum.com/u/zealdeal)\ **Post date:** [February 17, 2015, 11:19am UTC](https://www.ruby-forum.com/t/amplitude-settings-in-uhd-siggen/234149/9 "2015-02-17T11:19:58Z")
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 ---
**Author:** ![zealdeal](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/z/ecb155/32.png) [@zealdeal](https://www.ruby-forum.com/u/zealdeal)\ **Post date:** [February 17, 2015, 10:52am UTC](https://www.ruby-forum.com/t/amplitude-settings-in-uhd-siggen/234149/10 "2015-02-17T10:52:21Z")
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