Where did the root_raised_cosine filter go? I recently began exploring GRC in the svn trunk, and quickly realized that the root_raised_cosine filter has gone missing. Missing is perhaps too strong of word... the filter exists in the gr_firdes general library, but isn't brought out to a GRC block of that name that I can find. Do I simply need to create a custom XML wrapper for it, or is it hidden in another filter as an option? I've begun to edit my "custom" XML filter, but am second guessing myself now. Is there some other SDR black magic (math) that I don't know? I'm new to fairly gnuradio and still getting oriented to the source code. Thanks in advance, Glenn

on 2008-12-12 21:55

on 2008-12-12 23:48

See http://gnuradio.org/trac/wiki/GNURadioCompanion#FilterDesign you have access to all the firdes function from inside grc. Just pick out an FIR filter block, and enter firdes.root_raised_cosine(...) for the taps parameter. I made a few wrappers around the FIR filters for the pass band taps: low pass, high pass... are all in grc. I could easily make another for the root raised cosine FIR filter, so you dont have to type this firdes.... nonsense. The issue is that there are a N blocks that take taps as a parameter, and there are M taps generators, and it would be hell to make MxN convenience wrappers for all of them. However, I would like to make these convenience blocks for some of the combinations. Would RRC FIR be useful? Any other suggestions for some practical combinations? -Josh

on 2008-12-13 00:20

On Fri, Dec 12, 2008 at 1:47 PM, Josh B. <removed_email_address@domain.invalid> wrote: > However, I would like to make these convenience blocks for some of the > combinations. Would RRC FIR be useful? Any other suggestions for some > practical combinations? A rational resampler that used RRC taps would be useful as a transmit side RRC interpolator. A common MPSK transmitter chain is to create a symbol stream at a particular number of samples per symbol (related to your input data), perform RRC filtering, then resample to meet the rate expected by the USRP at some particular hardware interpolation rate. You can economize CPU cycles by merging the RRC and resampling filter stages, that is, by using properly calculated RRC taps in the place of the resampler lowpass filter. You could make a GRC wrapper for this. Come to think of it, this would be a good opportunity to make a hierarchical block for the blks2 namespace. -Johnathan

on 2008-12-13 00:43

Johnathan C. wrote: > > A common MPSK transmitter chain is to create a symbol stream at a > particular number of samples per symbol (related to your input data), > perform RRC filtering, then resample to meet the rate expected by the > USRP at some particular hardware interpolation rate. > > You can economize CPU cycles by merging the RRC and resampling filter > stages, that is, by using properly calculated RRC taps in the place of > the resampler lowpass filter. > Our transmit chain indeed follows this exact pattern. The RRC was/is used to shape the data stream, and then we resampled in a second block. I would be interested to measure the performance gain by eliminating the extra block(s). (There is a constant gain block as well, to bring the level up to the USRP's expectations.) However, I'm still back working on understanding how all these taps are "properly created". :)

on 2008-12-13 01:25

On Fri, Dec 12, 2008 at 2:42 PM, Glenn R. <removed_email_address@domain.invalid> wrote: > Our transmit chain indeed follows this exact pattern. The RRC was/is used > to shape the data stream, and then we resampled in a second block. > > I would be interested to measure the performance gain by eliminating the > extra block(s). (There is a constant gain block as well, to bring the level > up to the USRP's expectations.) However, I'm still back working on > understanding how all these taps are "properly created". :) You can eliminate the constant gain block by scaling the RRC taps by that much. In fact, the RRC tap calculator has a gain parameter to do just that. To "properly" calculate the RRC taps, you have to understand how the polyphase rational resampler works. First the incoming sample stream is zero-stuffed by the interpolation rate, then this sample stream goes into a polyphase FIR filter that produces output samples at the decimated output rate. However, the taps for the FIR filter need to be calculated as if you weren't decimating the result; that is, at the input data rate * the interpolation rate. The filter doesn't actually run at this possibly very high rate--it only operates to produce samples at the output that wouldn't get thrown away by the decimation, For example, let's say you have a 7 Mbps QPSK transmitter and the USRP1. At some point in the flowgraph, the item stream will be 3.5 Msps QPSK constellation points. If you set the USRP interpolation to 16, then it expects an item stream at 8 Msps. This can be achieved by using a rational resampler that interpolates by 16 and decimates by 7. You would calculate the RRC taps assuming an input rate of 1 sample/symbol and sample rate of 16 samples/symbol. From Python (the formatting probably won't survive): taps = gr.firdes.root_raised_cosine(interp*amplitude, #gain interp, # sample rate 1.0, # symbol rate excess_bw, # excess bandwidth interp*taps_per_sym) # ntaps The gain parameter is calculated assuming the QPSK symbols have unity values and overcome the interpolation loss as well. Taps per symbol is based on how many symbol periods you want to apply the RRC filter kernel over. Hope this makes things more clear. The perfomance gain is demonstrable--you are eliminating a FIR filter and multiplier block, both of which are operating at the highest data rate in your flowgraph. -Johnathan