Digital filter simulators?

Try Octave! The syntax is very much similar to MATLAB

Hello Sivakanth,

> Try Octave! The syntax is very much similar to MATLAB
> 


Would love to. But I am not a great MATLAB user either. I need something 
that is simple, like some of the configurable FFT programs out there. A 
few of these almost do what I need but stop just short of coefficient 
granularization.

Regards, Joerg

http://www.analogconsultants.com

Hello Tim,

> 
> If someone would fund me, and if I thought the Scilab team would pay 
> attention, I'd love to dig in and write _good_ documentation for that 
> package.
> 

That's exactly the point. Many excellent SW packages and even some uC 
are so poorly documented that they don't make it into mainstream for 
that reason. Academians often won't go below the highest level of 
abstraction and there are no "Heathkit style" grunt work examples. But 
all this will be needed to get engineers on board. Especially the busy 
ones who can't spend weeks reading up on stuff.

Even in many books it's like that. My favorite here is Haddad Parsons 
but when it comes to practical implementation they immediately assume 
you can always have the horsepower of a TMS320. Well, it just ain't so 
with most projects. Sometimes you'll simply have to concede and accept 
that there absolutely will not be a HW multiplier because it's 50 cents 
too much. It is like the farmer who has to make do with his old F250 
because he can't have that new truck with the Cummins in there.

Regards, Joerg

http://www.analogconsultants.com

Joerg wrote:
> I have some filter design software that came with DSP books but they
> don't go that far. They assume 'ideal' coefficient granularity base on
> the available word width. Didn't find anything with Google but maybe I
> hadn't used optimal search phrases.

Out of curiosity: What is "coefficient granularity"?
Never heard the term before.

Rune

Joerg wrote:
> Hello Tim,
>
> >
> > If someone would fund me, and if I thought the Scilab team would pay
> > attention, I'd love to dig in and write _good_ documentation for that
> > package.
> >
>
> That's exactly the point. Many excellent SW packages and even some uC
> are so poorly documented that they don't make it into mainstream for
> that reason. Academians often won't go below the highest level of
> abstraction and there are no "Heathkit style" grunt work examples. But
> all this will be needed to get engineers on board. Especially the busy
> ones who can't spend weeks reading up on stuff.

Academics don't know what the term "documentation" means. A couple of
weeks ago, the professor who took up the methods and techniques I used
to work with, called me and wanted to discuss some questions. The
questions concerned a computer I last worked with 5 years ago, that I
got
10 years ago from somebody who had modified 15 years old public domain
code. The "documentation" of the original PD code consisted of a 6-page
short summary of a general technique, where some variables were
stated "without proof". In the program (Fortran 77) the variables
were named as "acc", "bb", "cmn"... with no comments and apparently
with no connection to the article. The program was written in the
"implicit declaration" style that fortran allows, where a variable
needs
not be declared but where its data type (real, complex, integer) is
implicitly given by its name. An utter nightmare. The professor had
spent two months getting the thing to compile and run, due to the less
than standardized way fortran works. It would have been way faster to
write the program from scratch.

I'm happy that other people take over those tasks; I'm pretty fed up
with the stuff. But if I ever get a call like that again, I'll charge
$250 per
hour.

So what I have done in my programming projects, is to write the
basics in LaTeX and document the code so that HTML documents
can be generated with Doxygen. These tools are free, and are
available to students, but can not necessarily be used by companies.
Are there alternatives available that can be used in commercial
projects,
that can be used for other programming languages than C/C++?

Rune

Hello Rune,

> So what I have done in my programming projects, is to write the
> basics in LaTeX and document the code so that HTML documents
> can be generated with Doxygen. These tools are free, and are
> available to students, but can not necessarily be used by companies.
> Are there alternatives available that can be used in commercial
> projects,
> that can be used for other programming languages than C/C++?
> 

No idea, I don't code much. But if I do I document everything in HTML. 
Code, module specs, schematics, revision history and so on. I am a 
strong believer that source code comments are not a sufficient form of 
documentation.

Regards, Joerg

http://www.analogconsultants.com

Rune Allnor wrote:

> Joerg wrote:
> 
>>I have some filter design software that came with DSP books but they
>>don't go that far. They assume 'ideal' coefficient granularity base on
>>the available word width. Didn't find anything with Google but maybe I
>>hadn't used optimal search phrases.
> 
> 
> Out of curiosity: What is "coefficient granularity"?
> Never heard the term before.
> 
> Rune
> 
Jeorg:  You mean quantization, right?

You shouldn't overlook data quantization, either.  Both coefficient and 
data quantization can be easily modeled and analyzed without having to 
simulate, although its usually a good idea to simulate so you'll find 
out what you forgot to account for.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Hello Rune,
> 
> Out of curiosity: What is "coefficient granularity"?
> Never heard the term before.
> 

The reduction of the total available number of coefficients to less than 
the word width would theoretically allow. IOW causing the selection to 
be more granular than usual.

For example let's say a certain project cannot afford a device with a HW 
multiplier and must also run on batteries, limiting the processor clock 
frequency. To save on processor cycles the amount of ones in an eight 
bit data word that is to be used as a multiplier may have to be limited 
to, say, four or five.

Granularity is probably not a common word in the DSP world. It is often 
used in radar and ultrasound beamforming which is my home turf.

Regards, Joerg

http://www.analogconsultants.com

Hello Tim,

> Jeorg:  You mean quantization, right?
> 

Kind of. It's like picking the low hanging fruit, coefficients that have 
the least number of ones in there. I have pretty much given up on the 
luxury of a HW multiplier for the project at hand (or the proposal 
thereof). Too expensive.


> You shouldn't overlook data quantization, either.  Both coefficient and 
> data quantization can be easily modeled and analyzed without having to 
> simulate, although its usually a good idea to simulate so you'll find 
> out what you forgot to account for.
> 

True. In my case it might not easily work though because I have to 
filter first and then 'level select'. I need a huge dynamic range. 
Ranging before the filters would cost too much precious horsepower and 
RAM. So data will be 16 bits while the coefficients are probably going 
to have to be 6-8 bits.

Regards, Joerg

http://www.analogconsultants.com

Joerg wrote:

> Hello Rune,
> 
>>
>> Out of curiosity: What is "coefficient granularity"?
>> Never heard the term before.
>>
> 
> The reduction of the total available number of coefficients to less than 
> the word width would theoretically allow. IOW causing the selection to 
> be more granular than usual.
> 
> For example let's say a certain project cannot afford a device with a HW 
> multiplier and must also run on batteries, limiting the processor clock 
> frequency. To save on processor cycles the amount of ones in an eight 
> bit data word that is to be used as a multiplier may have to be limited 
> to, say, four or five.
> 
> Granularity is probably not a common word in the DSP world. It is often 
> used in radar and ultrasound beamforming which is my home turf.
> 
> Regards, Joerg
> 
> http://www.analogconsultants.com

You should stick to "quantization" if you want us poor DSP types to 
understand.

Restricting the precision of the multiplication to save time works for me.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com