Re: [Discuss-gnuradio] OFDM TX/RX PAPR
How do you reduce the PAPR with existing block in GRC ? I've tried with Scrambler->Encoder CCSDS->Interleaver but it doesn't seems to work. I'm still not having any signal at the output of the OFDM receiver. Guillaume Le 27/03/2018 à 11:58, Ron Economos a écrit : Yes, I think the whitener does the trick. If you plot the PAPR of band limited white noise, it's pretty much the same curve. Ron On 03/27/2018 02:36 AM, Müller, Marcus (CEL) wrote: Oooh, that's a nice plot! This is way better than I would have anticipated. Can I attribute that to awesome whitening properties of the code itself and following scramblers/interleavers? Marcus On Tue, 2018-03-27 at 02:31 -0700, Ron Economos wrote: CCDF (Complementary Cumulative Distribution Function) is often used to show PAPR probability. Here's what the GNU Radio DVB-T2 transmitter looks like at 32K (27841 active) carriers with an without tone reservation PAPR reduction. Ron On 03/27/2018 02:09 AM, Müller, Marcus (CEL) wrote: On Fri, 2018-03-23 at 14:21 -0700, Martin Braun wrote: If you've increased the number of carriers, PAPR also goes up (a bit). Yep, by the same factor as you increase the number of carriers (proof idea: time-symbol with worst PAPR is the discrete dirac over the vector of FFT length N. That has a PAPR of N/1 = N if freq domain samples were amplitude-limited to 1.) The probability to hit a PAPR that bad is, however, limited. Considering an M-PSK modulation on the N subcarriers. Then there's a total of M^N possible time-domain OFDM symbols, but only M·N of these are worst-PAPR, so P(worst PAPR for N carriers) = M·N/M^N = N / M^(N-1) assuming equally likely symbols. Since M^N pretty certainly grows faster than N, your likelihood of ending up in the "worst PAPR" scenario actually drops with N. The story looks a bit different if you're not interested in the worst- PAPR-symbol, but in all symbols that have a PAPR worse than some threshold, e.g. 20dB. Especially for LTE, there's a lot of simulative/monte carlo PAPR>threshold curves, as things like trading clipping for amplifier efficiency plays a very commercially relevant role there. Best regards, Marcus ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio _ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. tx_ofdm.grc Description: application/gnuradio-grc ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] OFDM TX/RX
Yes, I think the whitener does the trick. If you plot the PAPR of band limited white noise, it's pretty much the same curve. Ron On 03/27/2018 02:36 AM, Müller, Marcus (CEL) wrote: Oooh, that's a nice plot! This is way better than I would have anticipated. Can I attribute that to awesome whitening properties of the code itself and following scramblers/interleavers? Marcus On Tue, 2018-03-27 at 02:31 -0700, Ron Economos wrote: CCDF (Complementary Cumulative Distribution Function) is often used to show PAPR probability. Here's what the GNU Radio DVB-T2 transmitter looks like at 32K (27841 active) carriers with an without tone reservation PAPR reduction. Ron On 03/27/2018 02:09 AM, Müller, Marcus (CEL) wrote: On Fri, 2018-03-23 at 14:21 -0700, Martin Braun wrote: If you've increased the number of carriers, PAPR also goes up (a bit). Yep, by the same factor as you increase the number of carriers (proof idea: time-symbol with worst PAPR is the discrete dirac over the vector of FFT length N. That has a PAPR of N/1 = N if freq domain samples were amplitude-limited to 1.) The probability to hit a PAPR that bad is, however, limited. Considering an M-PSK modulation on the N subcarriers. Then there's a total of M^N possible time-domain OFDM symbols, but only M·N of these are worst-PAPR, so P(worst PAPR for N carriers) = M·N/M^N = N / M^(N-1) assuming equally likely symbols. Since M^N pretty certainly grows faster than N, your likelihood of ending up in the "worst PAPR" scenario actually drops with N. The story looks a bit different if you're not interested in the worst- PAPR-symbol, but in all symbols that have a PAPR worse than some threshold, e.g. 20dB. Especially for LTE, there's a lot of simulative/monte carlo PAPR>threshold curves, as things like trading clipping for amplifier efficiency plays a very commercially relevant role there. Best regards, Marcus ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] OFDM TX/RX
Oooh, that's a nice plot! This is way better than I would have anticipated. Can I attribute that to awesome whitening properties of the code itself and following scramblers/interleavers? Marcus On Tue, 2018-03-27 at 02:31 -0700, Ron Economos wrote: > CCDF (Complementary Cumulative Distribution Function) is often used to show > PAPR probability. Here's what the GNU Radio DVB-T2 transmitter looks like at > 32K (27841 active) carriers with an without tone reservation PAPR reduction. > > Ron > On 03/27/2018 02:09 AM, Müller, Marcus (CEL) wrote: > > On Fri, 2018-03-23 at 14:21 -0700, Martin Braun wrote: > > > If you've > > > increased the number of carriers, PAPR also goes up (a bit). > > > > Yep, by the same factor as you increase the number of carriers (proof > > idea: time-symbol with worst PAPR is the discrete dirac over the vector > > of FFT length N. That has a PAPR of N/1 = N if freq domain samples were > > amplitude-limited to 1.) > > > > The probability to hit a PAPR that bad is, however, limited. > > Considering an M-PSK modulation on the N subcarriers. Then there's a > > total of M^N possible time-domain OFDM symbols, but only M·N of these > > are worst-PAPR, so > > P(worst PAPR for N carriers) = M·N/M^N = N / M^(N-1) > > assuming equally likely symbols. Since M^N pretty certainly grows > > faster than N, your likelihood of ending up in the "worst PAPR" > > scenario actually drops with N. > > > > The story looks a bit different if you're not interested in the worst- > > PAPR-symbol, but in all symbols that have a PAPR worse than some > > threshold, e.g. 20dB. Especially for LTE, there's a lot of > > simulative/monte carlo PAPR>threshold curves, as things like trading > > clipping for amplifier efficiency plays a very commercially relevant > > role there. > > > > Best regards, > > > > Marcus > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio smime.p7s Description: S/MIME cryptographic signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] OFDM TX/RX
On Fri, 2018-03-23 at 14:21 -0700, Martin Braun wrote: > If you've > increased the number of carriers, PAPR also goes up (a bit). Yep, by the same factor as you increase the number of carriers (proof idea: time-symbol with worst PAPR is the discrete dirac over the vector of FFT length N. That has a PAPR of N/1 = N if freq domain samples were amplitude-limited to 1.) The probability to hit a PAPR that bad is, however, limited. Considering an M-PSK modulation on the N subcarriers. Then there's a total of M^N possible time-domain OFDM symbols, but only M·N of these are worst-PAPR, so P(worst PAPR for N carriers) = M·N/M^N = N / M^(N-1) assuming equally likely symbols. Since M^N pretty certainly grows faster than N, your likelihood of ending up in the "worst PAPR" scenario actually drops with N. The story looks a bit different if you're not interested in the worst- PAPR-symbol, but in all symbols that have a PAPR worse than some threshold, e.g. 20dB. Especially for LTE, there's a lot of simulative/monte carlo PAPR>threshold curves, as things like trading clipping for amplifier efficiency plays a very commercially relevant role there. Best regards, Marcus smime.p7s Description: S/MIME cryptographic signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] OFDM TX/RX
On 03/16/2018 09:33 AM, guillaume.toc...@orange.com wrote: > Hello all, > > I want to make a flow graph for transmitting and receiving OFDM > modulated data. To be precise, I want to do a LTE-M "like" > transmission/reception, so I am trying to transmit data with a BW of > 1.08 MHz OFDM. > To do so, I use the following configuration : samp_rate = 1.92 MHz, fft > length = 128, number of sub carriers = 72 , cp = 32 > > I modified the tx_ofdm.grc example file > (/gnuradio/gr-digital/examples/ofdm/tx_ofdm.grc) > To summary, I change the occupied carriers : range(-36, -21) + > range(-20, -7) + range(-6, 0) + range(1, 7) + range(8, 21) + range(22, > 37),) ; pilot carriers and symbols unchanged ; double the sync words to > be equal to fft length. > > The problem is at the output of the "Tag debug" I have just those > messages : > INFO: Parser returned #f > INFO: Detected an invalid packet at item 1496 > .. > INFO: Parser returned #f > INFO: Detected an invalid packet at item 681901 > > And the spectrum isn't "stable" at 1.08 MHz BW. Are you going across the air? The most common cause for this is too much gain, and resulting distortions caused by large PAPR. If you've increased the number of carriers, PAPR also goes up (a bit). -- M > > > What am I doing wrong ? How the sync words are determine ? Should I add > pilot/symbol carriers ? > > > Best Regards and thanks by advance, > > Guillaume Tochou > > > > > _ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu > ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete > this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. > > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] OFDM TX/RX
Hello all, I want to make a flow graph for transmitting and receiving OFDM modulated data. To be precise, I want to do a LTE-M "like" transmission/reception, so I am trying to transmit data with a BW of 1.08 MHz OFDM. To do so, I use the following configuration : samp_rate = 1.92 MHz, fft length = 128, number of sub carriers = 72 , cp = 32 I modified the tx_ofdm.grc example file (/gnuradio/gr-digital/examples/ofdm/tx_ofdm.grc) To summary, I change the occupied carriers : range(-36, -21) + range(-20, -7) + range(-6, 0) + range(1, 7) + range(8, 21) + range(22, 37),) ; pilot carriers and symbols unchanged ; double the sync words to be equal to fft length. The problem is at the output of the "Tag debug" I have just those messages : INFO: Parser returned #f INFO: Detected an invalid packet at item 1496 .. INFO: Parser returned #f INFO: Detected an invalid packet at item 681901 And the spectrum isn't "stable" at 1.08 MHz BW. What am I doing wrong ? How the sync words are determine ? Should I add pilot/symbol carriers ? Best Regards and thanks by advance, Guillaume Tochou _ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. tx_ofdm.grc Description: application/gnuradio-grc ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] OFDM tx rx error
Jenny, we have a limit in place for packet sizes, which depends on your system. If you type sysctl -a, it'll say something like kernel.shmmax = 18446744073692774399 100 OFDM symbols seems pretty long, though. If your packet length is 96, as in the example, that means a total packet length of 100 (including CRC). With 48 useful carriers, you get 6 bytes per OFDM symbol, which results in 17 OFDM symbols, plus 2 more for the header. You'll need to give us some more info for us to help you. Cheers, Martin On 03/19/2016 11:44 AM, Jingyi Sun wrote: > Hi, > > I'm using the examples rx_ofdm.grc and tx_ofdm.grc together to transmit > and receive packets over the air. Both work over a simulated channel, > but when I actually transmit and receive over the air, I get the error: > > *"Detected a packet larger than max frame size (100 symbols)"* > > I saw the previous thread on this called "OFDM transmitter receiver" > which goes as follows, but I don't really know what to make of this... > > I tried to run /sysctl kernel.shmmax /in terminal, but I got the message > "No such file or directory". I'm also not sure what kernel.shmmax is. > > These are my parameters: > > fft length= 64 > > cyclic prefix = 16 > packet length = 96 > no. of occupied carriers = 53 > no. of pilot carriers = 4 > > > I'm very new to gnuradio, and any insights into this would be appreciated!! > > > Thanks, > Jenny > > -- > > *From*: Martin Braun > *Subject*:Re: [Discuss-gnuradio] OFDM transmitter receiver > *Date*: Tue, 26 Aug 2014 11:10:53 +0200 > *User-agent*: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 > Thunderbird/24.6.0 > > > > Try and not kill the context in a mailing list thread; these are also > archived and are used by others for referral. > > Max frame size depends on max_output_buffer(). 80 symbols at a 64-sized > FFT would be ~40kB... that doesn't seem unreasonable. Not sure if > there's a problem here. I suggest you have a look at the buffer sizes to > track down this problem. > > M > > On 08/25/2014 03:31 PM, Martin Braun wrote: >>/What's your kernel.shmmax value? (run sysctl kernel.shmmax)/ >>// >>/M/ >>// >>/On 08/25/2014 12:47 PM, sreena p h wrote:/ >>/> Hi/ >>/> I used the ofdm transmitter receiver blocks to create a simple system as/ >>/> shown in the attachment. I used the system parameters as those used in/ >>/> the example transmitter and receiver grcs. Now I get error that/ >>/> 'Detected a packet larger than max frame size (80 symbols)'. I would/ >>/> like to know how the max frame size is set and should I add more/ >>/> information to the grc. / >>/>/ >>/> My transmitter- receiver parameters/ >>/>/ >>/> fft length= 64/ >>/> cyclic prefix = 16/ >>/> packet length = 96/ >>/> no. of occupied carriers = 48/ >>/> no. of pilot carriers = 4/ >>/>/ >>/>/ >>/>/ >>/> ___/ > > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] OFDM tx rx error
Hi, I'm using the examples rx_ofdm.grc and tx_ofdm.grc together to transmit and receive packets over the air. Both work over a simulated channel, but when I actually transmit and receive over the air, I get the error: *"Detected a packet larger than max frame size (100 symbols)"* I saw the previous thread on this called "OFDM transmitter receiver" which goes as follows, but I don't really know what to make of this... I tried to run *sysctl kernel.shmmax *in terminal, but I got the message "No such file or directory". I'm also not sure what kernel.shmmax is. These are my parameters: fft length= 64 cyclic prefix = 16 packet length = 96 no. of occupied carriers = 53 no. of pilot carriers = 4 I'm very new to gnuradio, and any insights into this would be appreciated!! Thanks, Jenny PS sorry if this is redundant. I didn't get my email through the list so I'm assuming it didn't go through the first time. -- *From*: Martin Braun *Subject*: Re: [Discuss-gnuradio] OFDM transmitter receiver *Date*: Tue, 26 Aug 2014 11:10:53 +0200 *User-agent*: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 -- Try and not kill the context in a mailing list thread; these are also archived and are used by others for referral. Max frame size depends on max_output_buffer(). 80 symbols at a 64-sized FFT would be ~40kB... that doesn't seem unreasonable. Not sure if there's a problem here. I suggest you have a look at the buffer sizes to track down this problem. M On 08/25/2014 03:31 PM, Martin Braun wrote: >* What's your kernel.shmmax value? (run sysctl kernel.shmmax)* > >* M* > >* On 08/25/2014 12:47 PM, sreena p h wrote:* >*> Hi* >*> I used the ofdm transmitter receiver blocks to create a simple system as* >*> shown in the attachment. I used the system parameters as those used in* >*> the example transmitter and receiver grcs. Now I get error that* >*> 'Detected a packet larger than max frame size (80 symbols)'. I would* >*> like to know how the max frame size is set and should I add more* >*> information to the grc. * >*>* >*> My transmitter- receiver parameters* >*>* >*> fft length= 64* >*> cyclic prefix = 16* >*> packet length = 96* >*> no. of occupied carriers = 48* >*> no. of pilot carriers = 4* >*>* >*>* >*>* >*> ___* ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] OFDM tx rx error
Hi, I'm using the examples rx_ofdm.grc and tx_ofdm.grc together to transmit and receive packets over the air. Both work over a simulated channel, but when I actually transmit and receive over the air, I get the error: *"Detected a packet larger than max frame size (100 symbols)"* I saw the previous thread on this called "OFDM transmitter receiver" which goes as follows, but I don't really know what to make of this... I tried to run *sysctl kernel.shmmax *in terminal, but I got the message "No such file or directory". I'm also not sure what kernel.shmmax is. These are my parameters: fft length= 64 cyclic prefix = 16 packet length = 96 no. of occupied carriers = 53 no. of pilot carriers = 4 I'm very new to gnuradio, and any insights into this would be appreciated!! Thanks, Jenny -- *From*: Martin Braun *Subject*: Re: [Discuss-gnuradio] OFDM transmitter receiver *Date*: Tue, 26 Aug 2014 11:10:53 +0200 *User-agent*: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 -- Try and not kill the context in a mailing list thread; these are also archived and are used by others for referral. Max frame size depends on max_output_buffer(). 80 symbols at a 64-sized FFT would be ~40kB... that doesn't seem unreasonable. Not sure if there's a problem here. I suggest you have a look at the buffer sizes to track down this problem. M On 08/25/2014 03:31 PM, Martin Braun wrote: >* What's your kernel.shmmax value? (run sysctl kernel.shmmax)* > >* M* > >* On 08/25/2014 12:47 PM, sreena p h wrote:* >*> Hi* >*> I used the ofdm transmitter receiver blocks to create a simple system as* >*> shown in the attachment. I used the system parameters as those used in* >*> the example transmitter and receiver grcs. Now I get error that* >*> 'Detected a packet larger than max frame size (80 symbols)'. I would* >*> like to know how the max frame size is set and should I add more* >*> information to the grc. * >*>* >*> My transmitter- receiver parameters* >*>* >*> fft length= 64* >*> cyclic prefix = 16* >*> packet length = 96* >*> no. of occupied carriers = 48* >*> no. of pilot carriers = 4* >*>* >*>* >*>* >*> ___* ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] OFDM TX/RX with large packet_len size
Hi, I've problem to use a large packet_len size (ie; 1500 bytes) in OFDM Flowgraph as in the digital folder examples. I got this error: sched: block ofdm_cyclic_prefixer (34) is requesting more input data than we can provide. ninput_items_required = 34 max_possible_items_available = 31 If this is a filter, consider reducing the number of taps. My setup is: FFT=256 Packet_len=1512 header_mod=QPSK payload_mod=QAM16 min output buffer in cyclic prefix=10 Btw, if i'm using FFT=64, it does works fine when I increase the kernel shmax value. I attached the GRC that i'm using. Please kindly advice for this problem. My objective is to make this OFDM flowgraph to works with UDP/TCP packets. Or maybe there is another workaround to implement this? Another question, is this OFDM TX/RX example is working good for QAM16? I've try this with my b200, it seems I got lots of packet lost when I'm trying to transmit a file or some random source. Thanks ofdm_txrx_new_256.grc Description: application/gnuradio-grc ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] OFDM Tx/Rx with USRP
Hi everyone,In our group, we are trying to experiment with OFDM and want to setup an OFDM Tx/Rx chain and performs experiments and evaluate several synchronization (timing/frequency) and equalization algorithms. We finally want to be able to transmit/receive OTA at 2.4 Ghz ISM band. I saw some stuff from chuck in one of the emails on the list. I also see on the ettus research website that the 2.4 Ghz transciever should be available by now (Q1 2006). We have some question and would be glad to get opinions 1. What daughter boards do we need to build this chain. I think we will need Flex 2400 daugther boards, USRP boards and suitable antennas. Is the Flex 2400 daughter board available ?2. Later on, we may want to use a DSP kit/ FPGA development board to take the samples from USRP and then do further processing for real time performance. Is this possible ? RegardsPrateek -- Prateek Dayalwww.prateek.hostingzero.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
