Ugh, that was it, the usrp is coercing the sampling rate to 390k which gives me a 350MHz ish bandwidth. Must have missed that earlier.
Thanks for the help. ----------------------------- Jacob Knoles On Fri, May 11, 2018 at 12:36 PM Ian Buckley <i...@ionconcepts.com> wrote: > I may not have written my last response helpfully…the absolute value of > gain doesn’t tell you much about your actual power output, it’s very > waveform dependant. It was a hint to go vary this and see what happens. > If you drop a QT GUI Frequency Sink after your Cyclic prefixer you’ll get > a good feel for where all your signal power should be in an ideal world. If > that’s not what you see on a spectrum analyzer then something downstream is > causing your problem. > If you think about it, your actual OFDM waveform generation part of the > flow graph is Nyquist limited by the sample rate it runs at. Any digital > interpolation that happens from that sample rate to the ADC clock rate > within the FPGA applies appropriate filtering to prevent significant > aliasing. > > Now I think about it, you previously mentioned you are X310 based….not > sure it can interpolate in H/W from as low as 50/100kHz…the limit used to > be 512:1 when I originally designed it. Have you checked what UHD reports > when the flow graph starts? You may not be running at the sample rate you > asked for……(May need flow graph interpolator in S/W for low bandwidths) > > > On May 11, 2018, at 11:43 AM, Jacob Knoles <knole...@gmail.com> wrote: > > In the DSP prior to sending to USRP I scale everything by a const 0.05, > the TX gain for the USRP is 0.5 normalized. > ----------------------------- > Jacob Knoles > > > > On Fri, May 11, 2018 at 11:40 AM Ian Buckley <i...@ionconcepts.com> wrote: > >> What TX gain have you got set? Are you sure you are operating the PA in >> it’s linear region? OFDM waveforms are notorious for there PAPR >> requirements. >> >> On May 11, 2018, at 11:23 AM, Jacob Knoles <knole...@gmail.com> wrote: >> >> Hey guys, >> >> Please pardon my ignorance, I am trying to learn everything I need for >> DSP / OFDM on the fly. But I have noticed something with this OFDM gnuradio >> example. If I take the example and run it directly into the usrp without >> changing any variables, I get a 350 KHz wide signal out. >> Now the sample rate is only 100k, the occupied carriers are -26 to 26 >> (zero omitted) with pm 21 and pm 7 as pilot carriers. The fft length is >> 64. >> >> If the bandwidth is directly related to the sampling rate how am I >> getting 3x the bandwidth at low sample rates. >> >> For some further comparison I changed only the sample rate to a few other >> values, here is what I observed: >> >> Sample Rate : Observed Bandwidth >> 100k : 350 KHz >> 50k : 350 KHz >> 1M : 840 KHz >> 20M : 17 MHz >> >> The 1M and 20M rates make sense but I don't understand what is happening >> with the 100k and 50k rates. >> >> Thank you for the help. >> ----------------------------- >> Jacob Knoles >> >> >> >> On Wed, May 9, 2018 at 6:22 PM Marcus D. Leech <mle...@ripnet.com> wrote: >> >>> On 05/09/2018 07:57 PM, Jacob Knoles wrote: >>> >>> Thanks for the quick reply guys. >>> >>> Marcus the Re-sampling option makes perfect sense, and I believe, in >>> theory, since I am writing data to a file for later use I could interpolate >>> it just before writing then read it out at the usrp sample rate, right? >>> >>> Yes. >>> >>> >>> Ian, very interesting suggestion. I will have to give it a try. Thanks >>> for the input. And since I am doing all of the heavy processing prior to >>> tx'ing I don't image this change will create too great of a burden on the >>> CPU. As for reading from the file, I am just creating a small data set >>> which gets loaded into memory and repeated. >>> >>> Thanks!! >>> ----------------------------- >>> Jacob Knoles >>> >>> >>> >>> On Wed, May 9, 2018 at 4:21 PM Ian Buckley via USRP-users < >>> usrp-users@lists.ettus.com> wrote: >>> >>>> >>>> > On May 9, 2018, at 4:07 PM, Marcus D. Leech via USRP-users < >>>> usrp-users@lists.ettus.com> wrote: >>>> > >>>> > On 05/09/2018 06:53 PM, Jacob Knoles via USRP-users wrote: >>>> >> Hello All, >>>> >> >>>> >> I am trying to generate OFDM signals of various bandwidths using the >>>> X300 (UBX-160), particularly 20/40/80 and 160 MHz bandwidths. >>>> >> I have used the gnuradio ofdm_tx.grc example file to generate a data >>>> file which I then feed into the USRP an monitor on a spectrum analyzer. >>>> >> >>>> >> To quickly note, I do not care about the data being transferred, it >>>> will not be received or demodulated in any way and is simply an interfering >>>> signal. >>>> >> >>>> >> At this time I can produce a 20 MHz wide OFDM signal as well as a >>>> 100 MHz wide signal (?) but the 40/80 MHz signals are rounded and look more >>>> like an 802.11b signal. >>>> >> >>>> >> I have noted a message from the X300 that the requested sample rates >>>> (40/80 MS respectively) cannot be achieved due to the 200/x ratio being >>>> odd. >>>> >> >>>> >> So my question is this, how do I decouple the USRP's sample rate >>>> with the bandwidth of the signal I am trying to produce? >>>> >> To put it another way, I produce a data file at 40 MS/s rate then >>>> run it on the X300 at 100 MS/s and I get a 100 MHz wide signal instead of >>>> the 40 MHz I want. >>>> >> >>>> >> Thanks for the help. >>>> >> ----------------------------- >>>> >> Jacob Knoles >>>> >> >>>> > You would need to interpolate it up to the desired rate. UHD has no >>>> way of knowing that your samples represent data sampled at 40Msps, so when >>>> you >>>> > pull it out of your file at 100Msps, it will get presented as if it >>>> were 100Msps data. >>>> > >>>> > You'll need to use some DSP code, or Gnu Radio to up-sample your >>>> sample file. >>>> > >>>> ….or perhaps generate it off line using a non 2^n Fourier transform >>>> size that targets the USRP sample rate…for example instead of 64 bins @ >>>> 40MHz, 80 bins @ 50MHz, >>>> With zero data in the extra outlying bins (as you would have anyway in >>>> other bins). Might get interesting getting high bitrates out of a file, but >>>> equally, high bitrate M:N sample rate conversion will also be tricky for >>>> CPU >>>> _______________________________________________ >>>> USRP-users mailing list >>>> USRP-users@lists.ettus.com >>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >>>> >>> >>> >> >
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
