Thanks Ron! You were very helpful. 2016-06-19 22:28 GMT-03:00 Ron Economos <[email protected]>:
> The intended application for the DVB-S2 transmitter in GNU Radio was > mostly for digital television over amateur radio. The example flow graph > transmits a 6 MHz wide signal (5 Msyms/s and 20% excess bandwidth), which > is about as wide as folks want to use on ham bands. Most amateurs are using > less bandwidth and a few are using narrow bandwidths (in the UK, there's a > temporary digital allocation at 146 to 147 MHz, and the typical symbol rate > is 333 ksyms/s). > > So the 2X oversampling didn't seem like too much of a burden. Pretty much > all transmit capable SDR's can handle 10 Msps. > > If you're interested in really wide bandwidth transmission, then the 2X > oversampling does get in the way a little. On my workstation with a B210 > and Via USB3.0 controller, I can run 20 Msyms (40 Msps) reliably for a 24 > MHz wide signal. Above that rate, it falls apart with underruns. > > With an optimum USB3.0 controller capable of 60 Msps, it should be > possible to do a commercial satellite transponder 36 MHz wide signal with a > B2X0. > > Ron > > > On 06/16/2016 12:36 PM, Francisco Albani wrote: > > Thanks! > > Why not moving the zero stuffing downstream and use a polyphase arbitrary > resampler with RRC taps? I'm not familiar with performance comparison > between PFAR and FFT FIR Filter. > > > > 2016-06-15 19:41 GMT-03:00 Ron Economos <[email protected]>: > >> The primary design decision was to use the FFT filter instead of the >> interpolating FIR filter for performance. The FFT filter is considerably >> faster, especially at the 100 taps used in the flow graph. However, (as far >> as I know) the FFT filter does not have an interpolation option, just >> decimation. So the 2X interpolation is done in the Physical Layer Framer >> block instead. >> >> You can remove the zero stuffing from the Physical Layer Framer and use >> the Interpolating FIR Filter block instead of the FFT filter block for RRC >> filtering. If you try that, be sure to remove the factor of two in lines >> 535, 548 and 680 in the PL framer block. >> >> Here's a link that explains why zero stuffing is the correct way to do >> interpolation. >> >> http://www.dspguru.com/dsp/faqs/multirate/interpolation >> >> Ron >> >> >> On 06/15/2016 02:37 PM, Francisco Albani wrote: >> >> Hi to all! Specially to Ron Economos! (and thanks for sharing your work) >> >> I was trying to understand the example *dvbs2_tx.grc* and, after putting >> graphical sinks after many blocks, I noticed that the one called "Physical >> Frame Layer" outputs one complex zero after each constellation point (see >> attached screenshot). Moreover, the FFT Filter that gives the RRC shape is >> *not* instructed to interpolate to fit any samples_per_symbol >> requirement. Moremoreover, the sample rate is hardcoded to symbol_rate*2. >> >> This makes me think this transmitter can only work for 2 samples per >> symbol. (I suppose one can resample to an arbitrary sps value if needed.) >> >> The point of this message is to confirm my suspicion and to ask why this >> was a design decision. I hope to learn some insight. >> >> Here is the code: * >> <https://github.com/gnuradio/gnuradio/blob/master/gr-dtv/lib/dvbs2/dvbs2_physical_cc_impl.cc#L684>https://github.com/gnuradio/gnuradio/blob/master/gr-dtv/lib/dvbs2/dvbs2_physical_cc_impl.cc#L684 >> <https://github.com/gnuradio/gnuradio/blob/master/gr-dtv/lib/dvbs2/dvbs2_physical_cc_impl.cc#L684>* >> >> Relevant lines: 80, 684, 704 and 727. >> >> Bye and thanks! >> >> >> >> _______________________________________________ >> Discuss-gnuradio mailing list >> [email protected] >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> > > > _______________________________________________ > Discuss-gnuradio mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > >
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
