DSPRelated.com
Forums

Design of multirate filters

Started by Unknown February 24, 2009
On Feb 25, 7:24&#4294967295;pm, Jerry Avins <j...@ieee.org> wrote:
> aitezaz....@gmail.com wrote: > > On Feb 25, 5:27 am, "jbdore" <jbd...@gmail.com> wrote: > >> Do you perform an equalization on the data before plotting the > >> constellation? > > >> JB. > > @JB > > yes of course JB. do you think that filter imperfections should be > > handled by equalizer and i should look into equalizer algorithm? on > > baseband simulations, the equalizer works just fine. > > > @ Jerry > > thanks for your suggestion. another thing i was suspecting was the > > group delay of the filter. do you think increasing filter group delay > > with sharper transition bandwidth can be a problem? specially when we > > are going to downsample the output of this filter. > > > Thanks to both of you. > > How is extra delay different from the signal having been transmitted a > little later? If the delay is only in one path, then a compensating > delay in other paths can be added. I doubt that such is the case here. > > Jerry > -- > Engineering is the art of making what you want from things you can get. > &#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;
well it can be different that down sampler will throw different samples with respect to different group delays. i.e. downsampler will start randomly throwing a sample and keeping the other one. i thought that would be important ? thats why asked if this group delay is going to have any impact on the system. you are right, if we see the only the FIR filter and not the down sampler, there is no difference in both the scences.
aitezaz.abd@gmail.com wrote:
> On Feb 25, 7:24 pm, Jerry Avins <j...@ieee.org> wrote: >> aitezaz....@gmail.com wrote: >>> On Feb 25, 5:27 am, "jbdore" <jbd...@gmail.com> wrote: >>>> Do you perform an equalization on the data before plotting the >>>> constellation? >>>> JB. >>> @JB >>> yes of course JB. do you think that filter imperfections should be >>> handled by equalizer and i should look into equalizer algorithm? on >>> baseband simulations, the equalizer works just fine. >>> @ Jerry >>> thanks for your suggestion. another thing i was suspecting was the >>> group delay of the filter. do you think increasing filter group delay >>> with sharper transition bandwidth can be a problem? specially when we >>> are going to downsample the output of this filter. >>> Thanks to both of you. >> How is extra delay different from the signal having been transmitted a >> little later? If the delay is only in one path, then a compensating >> delay in other paths can be added. I doubt that such is the case here. >> >> Jerry >> -- >> Engineering is the art of making what you want from things you can get. >> &#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295; > well it can be different that down sampler will throw different > samples with respect to different group delays. i.e. downsampler will > start randomly throwing a sample and keeping the other one. i thought > that would be important ? thats why asked if this group delay is going > to have any impact on the system.
The decimator's phase is random to begin with, and any phase should work as well as any other.
> you are right, if we see the only the FIR filter and not the down > sampler, there is no difference in both the scences.
Jerry -- Engineering is the art of making what you want from things you can get. &#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;
jerry would you please comment on my previous post ? it is here for
your reference
--------------------------------------------------------------------------
Jerry i read article about Gibbs Phenomenon. What i got from this is
that this problem arises when we truncate the filter response in time.
That means if i increase the filter length with the same sharp
filters, i should get the better performance. But, when i increased
the filter length of the sharp filter, the performance improved from
what it was with fewer number of taps but it was still worse than the
performance of filter with larger transition bandwidth. Now where can
be the problem?
Im using the following code to generate the filter.

Fs_3 = 1e6;  % Sampling Frequency

Fpass = 250e3;              % Passband Frequency
Fstop = 500e3;             % Stopband Frequency
Dpass = 0.0028782312868;  % Passband Ripple
Dstop = 0.001;            % Stopband Attenuation
dens  = 80;                % Density Factor

% Calculate the order from the parameters using FIRPMORD.
[N, Fo, Ao, W] = firpmord([Fpass, Fstop]/(Fs_3/2), [1 0], [Dpass,
Dstop]);

% Calculate the coefficients using the FIRPM function.
pfir  = firpm(N, Fo, Ao, W, {dens});

i change the last line of the pfir  = firpm(N*2, Fo, Ao, W, {dens});
with different N*2 values to increase the no. of the taps.

Thanks for your time.
aitezaz.abd@gmail.com wrote:
> jerry would you please comment on my previous post ? it is here for > your reference > -------------------------------------------------------------------------- > Jerry i read article about Gibbs Phenomenon. What i got from this is > that this problem arises when we truncate the filter response in time.
Nit exactly. Truncating the coefficients decreases the *frequency* of the ringing, extending it further from the transition. It has no effect in the *amplitude*.
> That means if i increase the filter length with the same sharp > filters, i should get the better performance. But, when i increased > the filter length of the sharp filter, the performance improved from > what it was with fewer number of taps but it was still worse than the > performance of filter with larger transition bandwidth. Now where can > be the problem?
The sharper transition.
> Im using the following code to generate the filter. > > Fs_3 = 1e6; % Sampling Frequency > > Fpass = 250e3; % Passband Frequency > Fstop = 500e3; % Stopband Frequency > Dpass = 0.0028782312868; % Passband Ripple > Dstop = 0.001; % Stopband Attenuation > dens = 80; % Density Factor
That's not code, it's specification. Some program uses it to run code. Bad things happen when a sorcerer's apprentice lets himself believe he's a sorcerer. ... Jerry -- Engineering is the art of making what you want from things you can get. &#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;
On Feb 26, 9:00&#4294967295;pm, Jerry Avins <j...@ieee.org> wrote:
> aitezaz....@gmail.com wrote: > > jerry would you please comment on my previous post ? it is here for > > your reference > > -------------------------------------------------------------------------- > > Jerry i read article about Gibbs Phenomenon. What i got from this is > > that this problem arises when we truncate the filter response in time. > > Nit exactly. Truncating the coefficients decreases the *frequency* of > the ringing, extending it further from the transition. It has no effect > in the *amplitude*. > > > That means if i increase the filter length with the same sharp > > filters, i should get the better performance. But, when i increased > > the filter length of the sharp filter, the performance improved from > > what it was with fewer number of taps but it was still worse than the > > performance of filter with larger transition bandwidth. Now where can > > be the problem? > > The sharper transition. > > > Im using the following code to generate the filter. > > > Fs_3 = 1e6; &#4294967295;% Sampling Frequency > > > Fpass = 250e3; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295;% Passband Frequency > > Fstop = 500e3; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; % Stopband Frequency > > Dpass = 0.0028782312868; &#4294967295;% Passband Ripple > > Dstop = 0.001; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295;% Stopband Attenuation > > dens &#4294967295;= 80; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295;% Density Factor > > That's not code, it's specification. Some program uses it to run code. > Bad things happen when a sorcerer's apprentice lets himself believe he's > a sorcerer. >
of course i wrote below the MATLAB command firpm that uses Parks- McClellan algo for filter design. does that imply i should know this algorithm before designing filters?
On Feb 26, 9:00&#4294967295;pm, Jerry Avins <j...@ieee.org> wrote:
> aitezaz....@gmail.com wrote: > > jerry would you please comment on my previous post ? it is here for > > your reference > > -------------------------------------------------------------------------- > > Jerry i read article about Gibbs Phenomenon. What i got from this is > > that this problem arises when we truncate the filter response in time. > > Nit exactly. Truncating the coefficients decreases the *frequency* of > the ringing, extending it further from the transition. It has no effect > in the *amplitude*. > > > That means if i increase the filter length with the same sharp > > filters, i should get the better performance. But, when i increased > > the filter length of the sharp filter, the performance improved from > > what it was with fewer number of taps but it was still worse than the > > performance of filter with larger transition bandwidth. Now where can > > be the problem? > > The sharper transition. > > > Im using the following code to generate the filter. > > > Fs_3 = 1e6; &#4294967295;% Sampling Frequency > > > Fpass = 250e3; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295;% Passband Frequency > > Fstop = 500e3; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; % Stopband Frequency > > Dpass = 0.0028782312868; &#4294967295;% Passband Ripple > > Dstop = 0.001; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295;% Stopband Attenuation > > dens &#4294967295;= 80; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295;% Density Factor > > That's not code, it's specification. Some program uses it to run code. > Bad things happen when a sorcerer's apprentice lets himself believe he's > a sorcerer. >
of course i wrote below the MATLAB command firpm that uses Parks- McClellan algo for filter design. does that imply i should know this algorithm before designing filters?
On Feb 26, 9:00&#4294967295;pm, Jerry Avins <j...@ieee.org> wrote:
> aitezaz....@gmail.com wrote: > > jerry would you please comment on my previous post ? it is here for > > your reference > > -------------------------------------------------------------------------- > > Jerry i read article about Gibbs Phenomenon. What i got from this is > > that this problem arises when we truncate the filter response in time. > > Nit exactly. Truncating the coefficients decreases the *frequency* of > the ringing, extending it further from the transition. It has no effect > in the *amplitude*. > > > That means if i increase the filter length with the same sharp > > filters, i should get the better performance. But, when i increased > > the filter length of the sharp filter, the performance improved from > > what it was with fewer number of taps but it was still worse than the > > performance of filter with larger transition bandwidth. Now where can > > be the problem? > > The sharper transition. > > > Im using the following code to generate the filter. > > > Fs_3 = 1e6; &#4294967295;% Sampling Frequency > > > Fpass = 250e3; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295;% Passband Frequency > > Fstop = 500e3; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; % Stopband Frequency > > Dpass = 0.0028782312868; &#4294967295;% Passband Ripple > > Dstop = 0.001; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295;% Stopband Attenuation > > dens &#4294967295;= 80; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295;% Density Factor > > That's not code, it's specification. Some program uses it to run code. > Bad things happen when a sorcerer's apprentice lets himself believe he's > a sorcerer. >
of course i wrote below the MATLAB command firpm that uses Parks- McClellan algo for filter design. does that imply i should know this algorithm before designing filters?
aitezaz.abd@gmail.com wrote:
> On Feb 26, 9:00 pm, Jerry Avins <j...@ieee.org> wrote: >> aitezaz....@gmail.com wrote: >>> jerry would you please comment on my previous post ? it is here for >>> your reference >>> -------------------------------------------------------------------------- >>> Jerry i read article about Gibbs Phenomenon. What i got from this is >>> that this problem arises when we truncate the filter response in time. >> Nit exactly. Truncating the coefficients decreases the *frequency* of >> the ringing, extending it further from the transition. It has no effect >> in the *amplitude*. >> >>> That means if i increase the filter length with the same sharp >>> filters, i should get the better performance. But, when i increased >>> the filter length of the sharp filter, the performance improved from >>> what it was with fewer number of taps but it was still worse than the >>> performance of filter with larger transition bandwidth. Now where can >>> be the problem? >> The sharper transition. >> >>> Im using the following code to generate the filter. >>> Fs_3 = 1e6; % Sampling Frequency >>> Fpass = 250e3; % Passband Frequency >>> Fstop = 500e3; % Stopband Frequency >>> Dpass = 0.0028782312868; % Passband Ripple >>> Dstop = 0.001; % Stopband Attenuation >>> dens = 80; % Density Factor >> That's not code, it's specification. Some program uses it to run code. >> Bad things happen when a sorcerer's apprentice lets himself believe he's >> a sorcerer. >> > of course i wrote below the MATLAB command firpm that uses Parks- > McClellan algo for filter design. does that imply i should know this > algorithm before designing filters?
No. I meant to distinguish between the specification for a filter and the code that calculates coefficients to meed that specification. Driving a car doesn't involve knowing how to design one. Believing that driving is akin to mechanical engineering does nobody any good. Jerry -- Engineering is the art of making what you want from things you can get. &#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;
On Feb 26, 10:32&#4294967295;pm, Jerry Avins <j...@ieee.org> wrote:
> aitezaz....@gmail.com wrote: > > On Feb 26, 9:00 pm, Jerry Avins <j...@ieee.org> wrote: > >> aitezaz....@gmail.com wrote: > >>> jerry would you please comment on my previous post ? it is here for > >>> your reference > >>> -------------------------------------------------------------------------- > >>> Jerry i read article about Gibbs Phenomenon. What i got from this is > >>> that this problem arises when we truncate the filter response in time. > >> Nit exactly. Truncating the coefficients decreases the *frequency* of > >> the ringing, extending it further from the transition. It has no effect > >> in the *amplitude*. > > >>> That means if i increase the filter length with the same sharp > >>> filters, i should get the better performance. But, when i increased > >>> the filter length of the sharp filter, the performance improved from > >>> what it was with fewer number of taps but it was still worse than the > >>> performance of filter with larger transition bandwidth. Now where can > >>> be the problem? > >> The sharper transition. > > >>> Im using the following code to generate the filter. > >>> Fs_3 = 1e6; &#4294967295;% Sampling Frequency > >>> Fpass = 250e3; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295;% Passband Frequency > >>> Fstop = 500e3; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; % Stopband Frequency > >>> Dpass = 0.0028782312868; &#4294967295;% Passband Ripple > >>> Dstop = 0.001; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295;% Stopband Attenuation > >>> dens &#4294967295;= 80; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295;% Density Factor > >> That's not code, it's specification. Some program uses it to run code. > >> Bad things happen when a sorcerer's apprentice lets himself believe he's > >> a sorcerer. > > > of course i wrote below the MATLAB command firpm that uses Parks- > > McClellan algo for filter design. does that imply i should know this > > algorithm before designing filters? > > No. I meant to distinguish between the specification for a filter and > the code that calculates coefficients to meed that specification. > Driving a car doesn't involve knowing how to design one. Believing that > driving is akin to mechanical engineering does nobody any good. > > Jerry > -- > Engineering is the art of making what you want from things you can get. > &#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;
All right thanks for your help anyways. it meant a lot to me... i will try to compensate in the regions you highlighted jerry. Best Regards, Aitezaz
On Feb 26, 10:32&#4294967295;pm, Jerry Avins <j...@ieee.org> wrote:
> aitezaz....@gmail.com wrote: > > On Feb 26, 9:00 pm, Jerry Avins <j...@ieee.org> wrote: > >> aitezaz....@gmail.com wrote: > >>> jerry would you please comment on my previous post ? it is here for > >>> your reference > >>> -------------------------------------------------------------------------- > >>> Jerry i read article about Gibbs Phenomenon. What i got from this is > >>> that this problem arises when we truncate the filter response in time. > >> Nit exactly. Truncating the coefficients decreases the *frequency* of > >> the ringing, extending it further from the transition. It has no effect > >> in the *amplitude*. > > >>> That means if i increase the filter length with the same sharp > >>> filters, i should get the better performance. But, when i increased > >>> the filter length of the sharp filter, the performance improved from > >>> what it was with fewer number of taps but it was still worse than the > >>> performance of filter with larger transition bandwidth. Now where can > >>> be the problem? > >> The sharper transition. > > >>> Im using the following code to generate the filter. > >>> Fs_3 = 1e6; &#4294967295;% Sampling Frequency > >>> Fpass = 250e3; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295;% Passband Frequency > >>> Fstop = 500e3; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; % Stopband Frequency > >>> Dpass = 0.0028782312868; &#4294967295;% Passband Ripple > >>> Dstop = 0.001; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295;% Stopband Attenuation > >>> dens &#4294967295;= 80; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295;% Density Factor > >> That's not code, it's specification. Some program uses it to run code. > >> Bad things happen when a sorcerer's apprentice lets himself believe he's > >> a sorcerer. > > > of course i wrote below the MATLAB command firpm that uses Parks- > > McClellan algo for filter design. does that imply i should know this > > algorithm before designing filters? > > No. I meant to distinguish between the specification for a filter and > the code that calculates coefficients to meed that specification. > Driving a car doesn't involve knowing how to design one. Believing that > driving is akin to mechanical engineering does nobody any good. > > Jerry > -- > Engineering is the art of making what you want from things you can get. > &#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;
All right thanks for your help anyways. it meant a lot to me... i will try to compensate in the regions you highlighted jerry. Best Regards, Aitezaz