Re: [Discuss-gnuradio] raised cosine filter taps implementation

[Nowlan, Sean]

More in general, is there a reason why the CPM modulator in the gr-digital 
package generates its own filter taps instead of using the functions in gr_cpm? 
Also, it seems that gr_cpm has other filters implemented through the 
phase_response function that belong in gr_firdes (which I assume stands for FIR 
design).

Thanks,
Sean

-----Original Message-----
From: address@hidden [mailto:address@hidden On Behalf Of Nowlan, Sean
Sent: Wednesday, November 16, 2011 4:02 PM
To: Nick Foster; Ben Reynwar; Tom Rondeau (address@hidden)
Cc: discuss-gnuradio Discussion Group
Subject: Re: [Discuss-gnuradio] raised cosine filter taps implementation

Is it just me, or does the gr_cpm::generate_cpm_lsrc_taps already implement a 
Raised Cosine filter? No need for me to reinvent the wheel then :c)

Sean

-----Original Message-----
From: address@hidden [mailto:address@hidden On Behalf Of Nick Foster
Sent: Monday, November 14, 2011 1:37 PM
To: Ben Reynwar
Cc: discuss-gnuradio Discussion Group
Subject: Re: [Discuss-gnuradio] raised cosine filter taps implementation

On Mon, Nov 14, 2011 at 10:21 AM, Ben Reynwar <address@hidden> wrote:
> On Mon, Nov 14, 2011 at 11:11 AM, Tom Rondeau <address@hidden> wrote:
>> On Mon, Nov 14, 2011 at 1:09 PM, Ben Reynwar <address@hidden> wrote:
>>>
>>> On Mon, Nov 14, 2011 at 10:03 AM, Tom Rondeau 
>>> <address@hidden>
>>> wrote:
>>> > On Mon, Nov 14, 2011 at 12:01 PM, Ben Reynwar <address@hidden> wrote:
>>> >>
>>> >> PSK31 for ham radio uses a raised cosine filter rather than the RRC.
>>> >
>>> > Interesting. Thanks.
>>> > Do you know why the do it? Do they just have the filter on one side?
>>> > Tom
>>> >
>>> I don't think it's for any good reason.  The raised cosine filter is 
>>> on the transmit side and I guess you can put whatever you want on 
>>> the receive side.  I would have thought another raised cosine filter 
>>> on the receiver side was the best way to go to maximise the signal 
>>> and then deal with the ISI afterwards.  I haven't looked at other 
>>> peoples code to see how they're doing it.
>>
>> I would have figured it was on the Tx side for bandwidth control, and 
>> you could do various things on the receiver side with that. It's of 
>> course why we normally use RRC filters though; restrict the 
>> transmitted signal bandwidth, then the receive RRC does both a 
>> matched filter and creates Nyquist pulses (ignoring multipath).
>> Tom
>>
> Yep.  I meant that I don't think there was a good reason for the 
> author of PSK31 choosing raised cosine over RRC.

I spent some time looking at it when I was writing a PSK31 decoder for GR. It 
seems like the transmit pulse-shaping filter is RC in order to keep the 
transmitted bandwidth even lower than it would be with RRC.
In other words, narrow bandwidth and steep skirts were given priority over ISI 
performance. PSK31 doesn't specify a receive filter, but the popular 
implementations (fldigi, G3PLX) seem to share the same filter, which is some 
weird custom LPF. I can go find the taps if people are interested.

I briefly looked into using fred harris's class of "ISI-corrected"
filters designed with a modified Remez algorithm (harris p.92) for both TX and 
RX, but it didn't really net me any more performance than just using a steep 
LPF, and I couldn't get Remez to converge reliably for the filters required. In 
any case, PSK31 is enough of a standard that introducing different TX filters 
would likely result in suboptimal performance for "standard" receivers.

--n

>>
>>>
>>> >>
>>> >> On Mon, Nov 14, 2011 at 9:26 AM, Tom Rondeau 
>>> >> <address@hidden>
>>> >> wrote:
>>> >> > On Mon, Nov 14, 2011 at 10:40 AM, Nowlan, Sean 
>>> >> > <address@hidden>
>>> >> > wrote:
>>> >> >>
>>> >> >> Because I need a raised cosine filter. If I convolve root 
>>> >> >> raised cosine filter coefficients with themselves (generated 
>>> >> >> with gr_firdes), do I need to apply a scaling factor?
>>> >> >
>>> >> > Ok, but my question was Why do you need a raised cosine filter? 
>>> >> > I'm just curious about what applications use this instead of 
>>> >> > RRC filters?
>>> >> > Tom
>>> >> >
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >> From: Tom Rondeau [mailto:address@hidden
>>> >> >> Sent: Monday, November 14, 2011 9:56 AM
>>> >> >> To: Nowlan, Sean
>>> >> >> Cc: address@hidden
>>> >> >> Subject: Re: [Discuss-gnuradio] raised cosine filter taps 
>>> >> >> implementation
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >> On Sun, Nov 13, 2011 at 6:56 PM, Nowlan, Sean 
>>> >> >> <address@hidden> wrote:
>>> >> >>
>>> >> >> I want to add a raised cosine filter to gr_firdes.* in 
>>> >> >> gnuradio/gnuradio-core/src/lib/general/. I see there's already 
>>> >> >> a root-raised cosine there. After looking through a few 
>>> >> >> sources, I have the following time-domain response of an RC
>>> >> >> filter:
>>> >> >>
>>> >> >> h(t) = [sin(pi * t / T_s) / (pi * t / T_s)] / [cos(pi * alpha
>>> >> >> * t /
>>> >> >> T_s) /
>>> >> >> (1 - (2 * alpha * t / T_s )^2 )]
>>> >> >>
>>> >> >> As far as I can tell, I should be able to compute the taps using:
>>> >> >>
>>> >> >> for n = -FLOOR(ntaps/2) to FLOOR(ntaps/2), do
>>> >> >>     h(n) = [sin(pi * n) / (pi * n)] / [cos(pi * alpha * n) /
>>> >> >> (1 - (2
>>> >> >> *
>>> >> >> alpha * n)^2 )]
>>> >> >> end_for
>>> >> >>
>>> >> >> The things I'll have to worry about:
>>> >> >> 1) if n is 0: h(n) = 1
>>> >> >> 2) if n is +/- 1/(2 * alpha): h(n) = (1 / (8 * alpha) ) * 
>>> >> >> sin(pi /
>>> >> >> (2 *
>>> >> >> alpha) )    #I think I did this right...
>>> >> >> 3) rounding errors: not sure what to do here given we're 
>>> >> >> operating with floats.
>>> >> >>
>>> >> >> Any tips/suggestions?
>>> >> >>
>>> >> >> Thanks,
>>> >> >> Sean
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >> Sean,
>>> >> >>
>>> >> >> We've gotten this question before, and I'm again curious why 
>>> >> >> you want a raised cosine filter? If you really are using it 
>>> >> >> for something, the easiest thing to do is just create a root 
>>> >> >> raised cosine filter and convolve it with itself.
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >> Tom
>>> >> >>
>>> >> >>
>>> >> >
>>> >> > _______________________________________________
>>> >> > Discuss-gnuradio mailing list
>>> >> > address@hidden
>>> >> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>> >> >
>>> >> >
>>> >
>>> >
>>
>>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio