Hi All, I am new to DSP, i have few qestions which many of you may find stupid but an early response is desired 1. cos(Wn)=cos( 2*pi*(Fc/Fs)n) is used in some documentation for oscillator, whereas some documenatin revelas use of IIR coeffecients for oscillator implementation. which apprach is correct? (i have understanding of FIR and IIR filter ) 2. If I use cos(Wn) for with appropriate parameter or downconversion hten would it work or i should do it though IIR oscillators? please reply soon Regards Masood
IIR oscillator or cos(Wn)
Started by ●September 21, 2006
Reply by ●September 21, 20062006-09-21
Masood wrote:> Hi All, > I am new to DSP, i have few qestions which many of you may find stupid > but an early response is desired > > 1. cos(Wn)=cos( 2*pi*(Fc/Fs)n) is used in some documentation for > oscillator, whereas some documenatin revelas use of IIR coeffecients for > oscillator implementation. which apprach is correct? (i have understanding > of FIR and IIR filter )Thjere are many ways to design oscillators in both hardware and software. What does "correct" mean to you? For that matter, what do Fc and Fn represent. (I can guess, but I don't know until you tell me.)> 2. If I use cos(Wn) for with appropriate parameter or downconversion hten > would it work or i should do it though IIR oscillators?How are you making your system? A fixed-point processor? A Pentium with enough speed to do trigonometry in real time? Something between? Jerry -- Engineering is the art of making what you want from things you can get. �����������������������������������������������������������������������
Reply by ●September 21, 20062006-09-21
Masood wrote:> Hi All, > I am new to DSP, i have few qestions which many of you may find stupid > but an early response is desired > > 1. cos(Wn)=cos( 2*pi*(Fc/Fs)n) is used in some documentation for > oscillator, whereas some documenatin revelas use of IIR coeffecients for > oscillator implementation. which apprach is correct? (i have understanding > of FIR and IIR filter )Neither, or both. You're leaving out a table look up. The IIR filter will give you the cos(wn) with the least amount of code, but you'll have issues with quantization noise making the amplitude creep around. You'll have to fix these issues one way or another, either by using more code space (and processor speed) or by accepting some harmonic distortion on your output. Doing a real cosine calculation will use a moderate amount of code and _lots_ of processing power. It's probably the way to go if you're doing the work off line, but probably _not_ the way to go if it's an embedded application. Doing a cosine calculation as a table look up can take significantly less time than an IIR filter on some processors, but you need this honking big look-up table. Take your pick. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com Posting from Google? See http://cfaj.freeshell.org/google/ "Applied Control Theory for Embedded Systems" came out in April. See details at http://www.wescottdesign.com/actfes/actfes.html
Reply by ●September 26, 20062006-09-26
Jerry Thanks for the reply, reply to your questions follows: 1. i am using pentium machine for DSP software implementation. 2. in cos( 2*pi*(Fc/Fs)n) Fc is signal frequency, Fs is sampling frequency and their ratio Fc/Fs is digital frequency. 3. if both IIR and cos(wn) are method of generating oscillator then i would prefer using cos equation for simplicity as i am doing it for first time. Regards Masood>Masood wrote: >> Hi All, >> I am new to DSP, i have few qestions which many of you may find stupid >> but an early response is desired >> >> 1. cos(Wn)=cos( 2*pi*(Fc/Fs)n) is used in some documentation for >> oscillator, whereas some documenatin revelas use of IIR coeffecientsfor>> oscillator implementation. which apprach is correct? (i haveunderstanding>> of FIR and IIR filter ) > >Thjere are many ways to design oscillators in both hardware and >software. What does "correct" mean to you? For that matter, what do Fc >and Fn represent. (I can guess, but I don't know until you tell me.) > >> 2. If I use cos(Wn) for with appropriate parameter or downconversionhten>> would it work or i should do it though IIR oscillators? > >How are you making your system? A fixed-point processor? A Pentium with >enough speed to do trigonometry in real time? Something between? > >Jerry >-- >Engineering is the art of making what you want from things you can get. >����������������������������������������������������������������������� >
Reply by ●September 26, 20062006-09-26
Masood wrote:> Jerry > Thanks for the reply, reply to your questions follows: > > 1. i am using pentium machine for DSP software implementation. > 2. in cos( 2*pi*(Fc/Fs)n) Fc is signal frequency, Fs is sampling > frequency and their ratio Fc/Fs is digital frequency. > 3. if both IIR and cos(wn) are method of generating oscillator then > i would prefer using cos equation for simplicity as i am doing it for > first time.Well then, there's not much to figure out. Just decide how much the phase is to advance every sample, and compute a new cosine. Suppose that you want a frequency that is Fs/n. Then the phase will advance 2*pi radians after n periods, or 2*pi/n radians per period. Define phase_increment "2*pi/n"; Set theta = 0; Define a function 'new_cos()': Theta += phase_increment; return cos(theta); end; If that's fast enough, go for it. Other methods can be about 20 times faster. Jerry -- of a thread, making it hard to follow. is that it interrupts the natural flow The thing I dislike about top posting ���������������������������������������������������������������������
Reply by ●September 26, 20062006-09-26
Another alternative is trade off a little math and indexing for table size. Use two tables instead of 1 table (1st covers 2*pi and 2nd covers smallest step in 1st table) to hold sin/cos (optimizations possible) and use the equation for cosine of sum of angles. Example: 8000 point cosine (full cycle) would use 8000 points in table. Could save memory by storing partial circle and making appropriate adjustments. Alternately could use a 100-point table and an 80-point table. 100-point table could hold 100 full cycle values (cos and sin obtained using offset pointers), the 80-point table would hold 80 each of sine and cosine for 160 more table entries. So you could use 260 table locations. Using a single pointer for the larger table would raise this to 360 locations in tables. Other combinations possible. Math cost is pointer math, and 2 multiplies + 1 subtract for the desired cosine of sum of angles calculation. Dirk Dirk Bell DSP Consultant Tim Wescott wrote:> Masood wrote: > > > Hi All, > > I am new to DSP, i have few qestions which many of you may find stupid > > but an early response is desired > > > > 1. cos(Wn)=cos( 2*pi*(Fc/Fs)n) is used in some documentation for > > oscillator, whereas some documenatin revelas use of IIR coeffecients for > > oscillator implementation. which apprach is correct? (i have understanding > > of FIR and IIR filter ) > > Neither, or both. You're leaving out a table look up. > > The IIR filter will give you the cos(wn) with the least amount of code, > but you'll have issues with quantization noise making the amplitude > creep around. You'll have to fix these issues one way or another, > either by using more code space (and processor speed) or by accepting > some harmonic distortion on your output. > > Doing a real cosine calculation will use a moderate amount of code and > _lots_ of processing power. It's probably the way to go if you're doing > the work off line, but probably _not_ the way to go if it's an embedded > application. > > Doing a cosine calculation as a table look up can take significantly > less time than an IIR filter on some processors, but you need this > honking big look-up table. > > Take your pick. > > > -- > > Tim Wescott > Wescott Design Services > http://www.wescottdesign.com > > Posting from Google? See http://cfaj.freeshell.org/google/ > > "Applied Control Theory for Embedded Systems" came out in April. > See details at http://www.wescottdesign.com/actfes/actfes.html
Reply by ●September 27, 20062006-09-27
dbell wrote:>> The IIR filter will give you the cos(wn) with the least amount of code, >> but you'll have issues with quantization noise making the amplitude >> creep around. You'll have to fix these issues one way or another, >> either by using more code space (and processor speed) or by accepting >> some harmonic distortion on your output.Correcting for amplitude is maybe three assembly instructions on many (3-x/2), so the correction multiplier for amplitude is .5*[3- cos(x)*cos(x) + sin(x)*sin(x)]. If sqrt[cos^2(x) + sin^2(x)] approximates 1 to n bits, the value will be good to 2n bits after the correction, so only one iteration is needed. ... Jerry -- "The rights of the best of men are secured only as the rights of the vilest and most abhorrent are protected." - Chief Justice Charles Evans Hughes, 1927 ���������������������������������������������������������������������
Reply by ●September 27, 20062006-09-27
>Masood wrote: >> Jerry >> Thanks for the reply, reply to your questions follows: >> >> 1. i am using pentium machine for DSP software implementation. >> 2. in cos( 2*pi*(Fc/Fs)n) Fc is signal frequency, Fs is sampling >> frequency and their ratio Fc/Fs is digital frequency. >> 3. if both IIR and cos(wn) are method of generating oscillator then >> i would prefer using cos equation for simplicity as i am doing itfor>> first time. > >Well then, there's not much to figure out. Just decide how much the >phase is to advance every sample, and compute a new cosine. > >Suppose that you want a frequency that is Fs/n. Then the phase will >advance 2*pi radians after n periods, or 2*pi/n radians per period. > >Define phase_increment "2*pi/n"; > >Set theta = 0; > >Define a function 'new_cos()': > >Theta += phase_increment; >return cos(theta); >end; > >If that's fast enough, go for it. Other methods can be about 20 times >faster. > >Jerry >-- > of a thread, making it hard to follow. > is that it interrupts the natural flow > The thing I dislike about top posting >��������������������������������������������������������������������� >If desired frequency is not exactly obtainable from Fs/n then what should be the solution. suppose Fs=48khz and i am downsampling 25 khz to 12 khz then i need 13 Khz (Local Oscillator)signal so(pseudo code) upto my understanding would be loop for n=0 to 1024 <-(sample count) (25 Khz signal)* cos(2*pi*(13kz/48khz)*n) <-cos(Wn) where, W=2*pi*Fc/Fs end where 13 Khz is (local oscillator)signal to get 25-13=12 Khz and 25+13=38 Khz 1. would it give same result as the algoithm you have mentioned in case desired frequency is exactly obtainable from Fs/n ? 2. if above is true then does it mean that it can be used for obtaining any (LO) frequency signal for downsampling and upconversion? reply soon.
Reply by ●September 27, 20062006-09-27
Masood wrote:>> Masood wrote: >>> Jerry >>> Thanks for the reply, reply to your questions follows: >>> >>> 1. i am using pentium machine for DSP software implementation. >>> 2. in cos( 2*pi*(Fc/Fs)n) Fc is signal frequency, Fs is sampling >>> frequency and their ratio Fc/Fs is digital frequency. >>> 3. if both IIR and cos(wn) are method of generating oscillator then >>> i would prefer using cos equation for simplicity as i am doing it > for >>> first time. >> Well then, there's not much to figure out. Just decide how much the >> phase is to advance every sample, and compute a new cosine. >> >> Suppose that you want a frequency that is Fs/n. Then the phase will >> advance 2*pi radians after n periods, or 2*pi/n radians per period. >> >> Define phase_increment "2*pi/n"; >> >> Set theta = 0; >> >> Define a function 'new_cos()': >> >> Theta += phase_increment; >> return cos(theta); >> end; >> >> If that's fast enough, go for it. Other methods can be about 20 times >> faster. >> >> Jerry >> -- >> of a thread, making it hard to follow. >> is that it interrupts the natural flow >> The thing I dislike about top posting >> ��������������������������������������������������������������������� >> > > If desired frequency is not exactly obtainable from Fs/n > then what should be the solution.'n' was a bad choice of variable name. It need not be an integer.> suppose Fs=48khz and i am downsampling 25 khz > to 12 khz then i need 13 Khz (Local Oscillator)signal so(pseudo code) > upto my understanding would be > > loop for n=0 to 1024 <-(sample count) > (25 Khz signal)* cos(2*pi*(13kz/48khz)*n) <-cos(Wn) where, W=2*pi*Fc/Fs > end > where 13 Khz is (local oscillator)signal to get 25-13=12 Khz and 25+13=38 > KhzYou described heterodyning, not downsampling.> 1. would it give same result as the algoithm you have mentioned > in case desired frequency is exactly obtainable from Fs/n ? > 2. if above is true then does it mean that it can be used for obtaining > any (LO) frequency signal for downsampling and upconversion?Jerry -- "The rights of the best of men are secured only as the rights of the vilest and most abhorrent are protected." - Chief Justice Charles Evans Hughes, 1927 ���������������������������������������������������������������������
Reply by ●September 28, 20062006-09-28
>Masood wrote: >>> Masood wrote: >>>> Jerry >>>> Thanks for the reply, reply to your questions follows: >>>> >>>> 1. i am using pentium machine for DSP software implementation. >>>> 2. in cos( 2*pi*(Fc/Fs)n) Fc is signal frequency, Fs is sampling >>>> frequency and their ratio Fc/Fs is digital frequency. >>>> 3. if both IIR and cos(wn) are method of generating oscillator then >>>> i would prefer using cos equation for simplicity as i am doing it >> for >>>> first time. >>> Well then, there's not much to figure out. Just decide how much the >>> phase is to advance every sample, and compute a new cosine. >>> >>> Suppose that you want a frequency that is Fs/n. Then the phase will >>> advance 2*pi radians after n periods, or 2*pi/n radians per period. >>> >>> Define phase_increment "2*pi/n"; >>> >>> Set theta = 0; >>> >>> Define a function 'new_cos()': >>> >>> Theta += phase_increment; >>> return cos(theta); >>> end; >>> >>> If that's fast enough, go for it. Other methods can be about 20 times>>> faster. >>> >>> Jerry >>> -- >>> of a thread, making it hard to follow. >>> is that it interrupts the natural flow >>> The thing I dislike about top posting >>> ��������������������������������������������������������������������� >>> >> >> If desired frequency is not exactly obtainable from Fs/n >> then what should be the solution. > >'n' was a bad choice of variable name. It need not be an integer. > >> suppose Fs=48khz and i am downsampling 25 khz >> to 12 khz then i need 13 Khz (Local Oscillator)signal so(pseudo code) >> upto my understanding would be >> >> loop for n=0 to 1024 <-(sample count) >> (25 Khz signal)* cos(2*pi*(13kz/48khz)*n) <-cos(Wn) where,W=2*pi*Fc/Fs>> end >> where 13 Khz is (local oscillator)signal to get 25-13=12 Khz and25+13=38>> Khz > >You described heterodyning, not downsampling. > >> 1. would it give same result as the algoithm you have mentioned >> in case desired frequency is exactly obtainable from Fs/n ? >> 2. if above is true then does it mean that it can be used forobtaining>> any (LO) frequency signal for downsampling and upconversion? > >Jerry >-- > "The rights of the best of men are secured only as the > rights of the vilest and most abhorrent are protected." > - Chief Justice Charles Evans Hughes, 1927 >��������������������������������������������������������������������� >Jerry you were right, it would be down conversion from 25 Khz to 12 Khz. can you comment on my questions below: suppose Fs=48khz and i am down converting it to 25 khz then i need 13 Khz (Local Oscillator)signal so(pseudo code) upto my understanding would be loop for n=0 to 1024 <-(sample count) (25 Khz signal)* cos(2*pi*(13kz/48khz)*n) <-cos(Wn) where, W=2*pi*Fc/Fs end where 13 Khz is (local oscillator)signal to get 25-13=12 Khz and 25+13=38 Khz 1. would it give same result as the algoithm you have mentioned ? 2. if above is true then does it mean that it can be used for obtaining any (LO) frequency signal for down conversion and up conversion of received signal ? Best Regards Masood
