Raised Cosine filter output not what I expect

bill mofson wrote:

   ...

> Oops!
> 
> My mistake: sampling rate is 6MHz (6e6) and bit rate is 1MHz (1e6)

Well that's 10,000% better! Might you have entered a mistaken exponent 
into one of your design programs at one point?

Jerry
-- 
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������

Jerry Avins wrote:
> bill mofson wrote:
> 
>   ...
> 
>> Oops!
>>
>> My mistake: sampling rate is 6MHz (6e6) and bit rate is 1MHz (1e6)
> 
> Well that's 10,000% better! Might you have entered a mistaken exponent 
> into one of your design programs at one point?
> 
> Jerry
Jerry,

I've triple checked at this point - all is ok.

Bill

Bill,

Not sure if someone suggested this, but what happens when you stick in
a sequence like [1 0 0 0 0 0 0 0 0 0 0 0 0 ..........0 0 0 0 0 00 etc]
i.e. the unit impulse?  You should get back your original FIR filter
coefficients.  What do you get?

col


bill mofson wrote:
> I'm working on a digital transmission system that requires a raised
> cosine filter on the transmitted data.   Symbol rate is 1e6MHz, Sample
> rate is 6e6Mhz.  Rolloff (Beta) is .5  Filter length is 6 bits (actually
> 6.1666 bits since I re-specify the taps to be 37 instead of 36 so I can
> get a peak out of the impulse response).
>
> Because this filter is used to decrease ISI, the coefficients are
> supposed to be 0 every 6 samples, except for the impulse sample - and my
> filter tools are generating exactly this (Quartus 6.0 FIR filter as well
> as ScopeFIR).  I'm referencing a spec which calls out this raised cosine
> filter and shows an example output of a specific data pattern.  In this
> example, they are using the filter before an FM modulator.  So with this
> filter they show how the modulator goes from a 1(+dF) to a -1(-dF)
> smoothly.  The significance of the example is that at each sample
> period, the output is either 1 or -1, whereas between sample periods,
> the frequency output is greater or less than (1,-1) due to the effects
> of the raised cosine filter and the specific bit pattern as it goes
> through the filter (e.g. a pattern of 010 goes directly from -1,1,-1
> with no overshoot at either 1 or -1.  A pattern of 011 goes from -1 to
> 1, settles at about 1.4 before coming back to 1 between the second and
> third bits).
>
> My filter doesn't do this.  The filter output differs based on what bit
> pattern is run through it.  For example, if all 0's go through, I'll
> declare the filter value to be -1.  If all 1's I'll declare the value
> equivalent to the 1. If I run alternating 0,1 (e.g. 01010101) - I get,
> say, something on the order of .8 to -.8 (always undershoots).  If I run
> groups of 0,1 (e.g. 11001100), the filter overshoots at the sample
> period, not between the sample period.  Basically I never see values
> that represent 1 and -1 for any random bit pattern.
>
>
> Any insight as to what I'm doing wrong is very much appreciated.
> 
> Bill M.

bill mofson wrote:
> Jerry Avins wrote:
>> bill mofson wrote:
>>
>>   ...
>>
>>> Oops!
>>>
>>> My mistake: sampling rate is 6MHz (6e6) and bit rate is 1MHz (1e6)
>>
>> Well that's 10,000% better! Might you have entered a mistaken exponent 
>> into one of your design programs at one point?
>>
>> Jerry
> Jerry,
> 
> I've triple checked at this point - all is ok.

Too bad. That would have been an easy one to fix.

Jerry
-- 
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������

In article <fS8Cg.67623$Lh4.6267@trnddc02>,
 bill mofson <bill.mofson@removeverizon.net> wrote:


|  My filter doesn't do this.  The filter output differs based on what bit 
|  pattern is run through it.  For example, if all 0's go through, I'll 
|  declare the filter value to be -1.  If all 1's I'll declare the value 
|  equivalent to the 1. If I run alternating 0,1 (e.g. 01010101) - I get, 
|  say, something on the order of .8 to -.8 (always undershoots).  If I run 
|  groups of 0,1 (e.g. 11001100), the filter overshoots at the sample 
|  period, not between the sample period.  Basically I never see values 
|  that represent 1 and -1 for any random bit pattern.
|  
|  
|  Any insight as to what I'm doing wrong is very much appreciated.

I suspect that your filter isn't symmetric -- for a 37-tap filter you 
should have 18 coefficients before the center sample coefficient (which 
should be 1.0), and the same 18 coefficients (mirrored) following the 
center coefficient.

While a raised-cosine filter isn't exactly a sinc filter, it is close.  
The coefficients for a sinc filter for your example would look like:

 #(0.0 0.056 0.103 0.127 0.118 0.073 0.0 -0.087 -0.165 -0.212 -0.207 
-0.136 0.0 0.191 0.413 0.637 0.827 0.955 1.0 0.955 0.827 0.637 0.413 
0.191 0.0 -0.136 -0.207 -0.212 -0.165 -0.087 0.0 0.073 0.118 0.127 0.103 
0.056 0.0).

What do your coefficients look like compared to those above, and how 
does your filter respond when using the sinc coefficients?

   -- Tim Olson

Bill,

Are you upsampling by 6 prior to sending the data into the filter?  You
should take your random bit pattern (e.g. 0,1,0,0); map it to data
levels (-1, +1, -1, -1) and then upsample by 6 (insert 5 zeros between
each mapped data level.)

Wilson

Wilson wrote:
> Bill,
> 
> Are you upsampling by 6 prior to sending the data into the filter?  You
> should take your random bit pattern (e.g. 0,1,0,0); map it to data
> levels (-1, +1, -1, -1) and then upsample by 6 (insert 5 zeros between
> each mapped data level.)
> 
> Wilson
> 

Wilson,

Interesting.  I'm not doing that.  I am upsampling with the same value, 
e.g. from your example, I would put into the filter: -1 six times, +1 
six times, etc.

Can you explain why zeros have to be inserted instead?  I'm pretty new 
to dsp with only the math background from a c.s. degree too many years ago.

Thanks for your help,
Bill

Tim Olson wrote:
> In article <fS8Cg.67623$Lh4.6267@trnddc02>,
>  bill mofson <bill.mofson@removeverizon.net> wrote:
> 
> 
> |  My filter doesn't do this.  The filter output differs based on what bit 
> |  pattern is run through it.  For example, if all 0's go through, I'll 
> |  declare the filter value to be -1.  If all 1's I'll declare the value 
> |  equivalent to the 1. If I run alternating 0,1 (e.g. 01010101) - I get, 
> |  say, something on the order of .8 to -.8 (always undershoots).  If I run 
> |  groups of 0,1 (e.g. 11001100), the filter overshoots at the sample 
> |  period, not between the sample period.  Basically I never see values 
> |  that represent 1 and -1 for any random bit pattern.
> |  
> |  
> |  Any insight as to what I'm doing wrong is very much appreciated.
> 
> I suspect that your filter isn't symmetric -- for a 37-tap filter you 
> should have 18 coefficients before the center sample coefficient (which 
> should be 1.0), and the same 18 coefficients (mirrored) following the 
> center coefficient.
> 
> While a raised-cosine filter isn't exactly a sinc filter, it is close.  
> The coefficients for a sinc filter for your example would look like:
> 
>  #(0.0 0.056 0.103 0.127 0.118 0.073 0.0 -0.087 -0.165 -0.212 -0.207 
> -0.136 0.0 0.191 0.413 0.637 0.827 0.955 1.0 0.955 0.827 0.637 0.413 
> 0.191 0.0 -0.136 -0.207 -0.212 -0.165 -0.087 0.0 0.073 0.118 0.127 0.103 
> 0.056 0.0).
> 
> What do your coefficients look like compared to those above, and how 
> does your filter respond when using the sinc coefficients?
> 
>    -- Tim Olson

Tim,

I'm using Quartus 6.0 FIR megacore compiler.  The coefficients are 
symmetrical around the center sample with 18 per side.  Quartus gives 
the floating point coefficients (with the center sample at .166 - so do 
ScopeFIR trial version).  Quartus then scales based on user selection 
(auto, manual, etc - I'm using auto scale), then it converts to integer. 
   ScopeFIR makes it easier to scale to 1; which I've tried.  Here is 
half the coefficients and the center sample from ScopeFIR that I've 
tried, but has the same effect with the data coming out of the filter:

  0.000000000000000000
  0.002068715034919408
  0.008457886463857050
  0.017148882212516307
  0.023020625697220579
  0.019205369520780884
-0.000000000000000013
-0.035514528236823766
-0.080572189940272057
-0.120042175487614130
-0.132909644432039090
-0.097775201815256174
  0.000000000000000039
  0.161773515730696950
  0.372147004409709710
  0.600210877438070780
  0.805721899402720210
  0.948745254326576640
  1.000000000000000000 - other half is same as first 18 values.

I'll give your coefficients a try though.

Thanks for your help.

Bill

bill mofson wrote:
> Wilson wrote:
>> Bill,
>>
>> Are you upsampling by 6 prior to sending the data into the filter?  You
>> should take your random bit pattern (e.g. 0,1,0,0); map it to data
>> levels (-1, +1, -1, -1) and then upsample by 6 (insert 5 zeros between
>> each mapped data level.)
>>
>> Wilson
>>
> 
> Wilson,
> 
> Interesting.  I'm not doing that.  I am upsampling with the same value, 
> e.g. from your example, I would put into the filter: -1 six times, +1 
> six times, etc.
> 
> Can you explain why zeros have to be inserted instead?  I'm pretty new 
> to dsp with only the math background from a c.s. degree too many years ago.
> 
> Thanks for your help,
> Bill

Wilson,

It just dawned on me why the other 5 bits have to be 0.  And of course 
it now works!  If you can recommend a good book on filters for digital 
transmission systems, it would be appreciated.  Many thanks for your 
help (and thanks to everyone else too)

Bill

>
> It just dawned on me why the other 5 bits have to be 0.  And of course
> it now works!  If you can recommend a good book on filters for digital
> transmission systems, it would be appreciated.  Many thanks for your
> help (and thanks to everyone else too)
>
> Bill

I was almost certain that was your problem.  I have done it many times
myself !

The standard text is Proakis "Digital Communications".  This is
probably a bit advanced.

I would recommend Lyons "Understanding Digital Signal Processing"  That
book is so good I almost cried the first time I read it.

Wilson