FIR filtering in the Fourier domain

Andor wrote:
> Jerry wrote:
> 
> 
>>He is trying to improve the intelligibility of voice on noisy commercial
>>stereo FM. The first step is to disable stereo decoder, gaining 3? dB
>>SNR, then (if it's still necessary) remove those frequencies that carry
>>noise but not intelligence.
> 
> 
> Unfortunately, much of the noise that drastically reduces
> intelligibility is in-band, ie. in the same frequency range as the
> voice itself. Imagine a voice recording covered with white noise. A
> bandpass filter is not going to buy much that way (unless there is very
> heavy high or low-frequency disturbances) - some real noise reduction
> algorithm is required. Seeing that the OP wants a quick and dirty
> solution, that seems out of the question. It wouldn't have been very
> difficult to do some research about this, since mobile telephony has
> initiated a burst of research in that area.

"Quick-and-dirty" is forcing Mono mode. Many receivers go mono when the 
signal strength is too low, but their idea of "too low" and mine differ. 
I suppose that all receivers that revert to mono with weak signals do it 
long before intelligibility of speech is affected. It is possible that 
the matrixing is in fact off, and the outputs of Philip's L and R 
channels are identical.

Philip: what kind of antenna do you use? Is it at least an indoor folded 
dipole? A little more signal strength can produce a lot of quieting!

Here, I tend to take questions at face value and try to answer them. As 
a consultant, I try to get at the root of the question: what prompted 
it? Early on, I had the dilemma of giving the customer either what he 
wanted or what he needed; those are often at odds. Later, I had the 
luxury making that choice myself, usually in favor of necessity, and 
damn the consequences. Some people who at first rejected my prescription 
later returned to have it filled. (And sometimes I was wrong, as 
everyone here knows.)

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

Jerry Avins wrote:
...
> Here, I tend to take questions at face value and try to answer them. As
> a consultant, I try to get at the root of the question: what prompted
> it?

As I wrote in an earlier post in this thread, many people come here and
ask "how do I get on the bus?" *) instead of "how can I travel to Papua
New Guinea?". Sometimes it's possible to guess their final destination,
most of the time it isn't.

I think that's a syndrome from a typcial disease: one is overwhelmed in
one's current project **) and starts with the implementation of the
first detail that one thinks one understands. Writing code relieves of
the burden of project design (I sometimes see this in myself as well).
Usually, such code written at the start of a project turns out to be a
waste of time (as in the current example). The act of coding is a
soothing refuge from the project deadlines - but only for a short time.
Such problem-ducking always ricochets.

> Early on, I had the dilemma of giving the customer either what he
> wanted or what he needed; those are often at odds. Later, I had the
> luxury making that choice myself, usually in favor of necessity, and
> damn the consequences. Some people who at first rejected my prescription
> later returned to have it filled. (And sometimes I was wrong, as
> everyone here knows.)

>From my point of view (which is not consulting, but manufacturing),
getting the product right the first time round requires an elevated
kind of inspiration. If this is not available (ie. the standard
situation), the product needs several turns in a development spiral:
the manufacturer chooses a selected few customers for the
develop/review rounds. Eventually, the goal is to converge the features
with the requirements. So even though we sell hardware, the design
structures are very similar to software. It is hardly ever a one-time
decision of the type "here is the product which I believe you need,
damn the consequences" :-).

Regards,
Andor

*) I think the metapher is actually from you, Jerry.

**) This is the greatest kind of work for me (as an engineer): the
project is always bigger than your expertise (sometimes more or less).
What better way to expand your skills and horizon?

Andor wrote:
> Jerry Avins wrote:
> ...
> > Here, I tend to take questions at face value and try to answer them. As
> > a consultant, I try to get at the root of the question: what prompted
> > it?

Hmmm.... I've seen you say that many times before, and it's the kind
of thing I've tried to do myself. But in my experience, seeing past
the customers requestes and to his needs, is interpreted by the
customer as a claim of his incompetence. Which, of course, it is.

It's a highly dangerous route. One would be very lucky (well, stupid)
to follow it through, into old age and retirement.

> As I wrote in an earlier post in this thread, many people come here and
> ask "how do I get on the bus?" *) instead of "how can I travel to Papua
> New Guinea?". Sometimes it's possible to guess their final destination,
> most of the time it isn't.
>
> I think that's a syndrome from a typcial disease: one is overwhelmed in
> one's current project **) and starts with the implementation of the
> first detail that one thinks one understands. Writing code relieves of
> the burden of project design (I sometimes see this in myself as well).
> Usually, such code written at the start of a project turns out to be a
> waste of time (as in the current example). The act of coding is a
> soothing refuge from the project deadlines - but only for a short time.
> Such problem-ducking always ricochets.

Yep. Been there, done that.

> > Early on, I had the dilemma of giving the customer either what he
> > wanted or what he needed; those are often at odds. Later, I had the
> > luxury making that choice myself, usually in favor of necessity, and
> > damn the consequences. Some people who at first rejected my prescription
> > later returned to have it filled. (And sometimes I was wrong, as
> > everyone here knows.)
>
> >From my point of view (which is not consulting, but manufacturing),
> getting the product right the first time round requires an elevated
> kind of inspiration. If this is not available (ie. the standard
> situation), the product needs several turns in a development spiral:
> the manufacturer chooses a selected few customers for the
> develop/review rounds. Eventually, the goal is to converge the features
> with the requirements. So even though we sell hardware, the design
> structures are very similar to software. It is hardly ever a one-time
> decision of the type "here is the product which I believe you need,
> damn the consequences" :-).

With my limited (i.e. nonexisttent) experience from HW development,
I have the impression it is far "simpler" to make a HW delivery than
a SW one. In the HW case, (I believe) the algorithm is more or less
given
in advance, the functionality is given and test functions can be
implemented and checked agains the spec. If the piece of equipment
meets
the quantitative spec, the delivery is accepted. In my SW problems,
it's more about qualitative questions like "make me an algorithms that
finds oil and gas, and that discards water and gravel". It's a delivery

that is impossible to make, but no customer who present such requests
(and I don't thinke there are anyone in the sonar or seismic buisnesses

who do NOT), will accept the fact that they have no clue whatsoever
about how data processing, -analyis and interpretation actually works.

> Regards,
> Andor
>
> *) I think the metapher is actually from you, Jerry.
>
> **) This is the greatest kind of work for me (as an engineer): the
> project is always bigger than your expertise (sometimes more or less).
> What better way to expand your skills and horizon?

Well... there are limits to everything. I think you will find that
most successful engineers and scientists expanded their horizons
by just the right amount each time. They also would have had basic
skills in their crafts. "Ambitious" organizations and individuals
that live by the "we don't waste time with the trivial stuff, we
only do the hard stuff" credo will find themselves lacking the basic
skills needed to attempt the hard stuff. With the obvious outcome.

Rune

Rune Allnor wrote:
> 
> Andor wrote:
> 
>>Jerry Avins wrote:
>>...
>>
>>>Here, I tend to take questions at face value and try to answer them. As
>>>a consultant, I try to get at the root of the question: what prompted
>>>it?
> 
> 
> Hmmm.... I've seen you say that many times before, and it's the kind
> of thing I've tried to do myself. But in my experience, seeing past
> the customers requestes and to his needs, is interpreted by the
> customer as a claim of his incompetence. Which, of course, it is.
> 
> It's a highly dangerous route. One would be very lucky (well, stupid)
> to follow it through, into old age and retirement.

It's a luxury that only very few employees ever have. I was fired once 
for doing that, but I stayed with the company and the idiot who fired me 
left instead. A few months later, he tried to hire me away. I declined.

   ...

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

Jerry Avins wrote:
> Rune Allnor wrote:
> >
> > Andor wrote:
> >
> >>Jerry Avins wrote:
> >>...
> >>
> >>>Here, I tend to take questions at face value and try to answer them. As
> >>>a consultant, I try to get at the root of the question: what prompted
> >>>it?
> >
> >
> > Hmmm.... I've seen you say that many times before, and it's the kind
> > of thing I've tried to do myself. But in my experience, seeing past
> > the customers requestes and to his needs, is interpreted by the
> > customer as a claim of his incompetence. Which, of course, it is.
> >
> > It's a highly dangerous route. One would be very lucky (well, stupid)
> > to follow it through, into old age and retirement.
>
> It's a luxury that only very few employees ever have. I was fired once
> for doing that, but I stayed with the company and the idiot who fired me
> left instead. A few months later, he tried to hire me away. I declined.

Seems to me as if you had support from competent people elsewhere
in the company. Even that is a rare luxury, in my experience. I don't
know if I chose the wrong profession (I might have, ref my rants about
the current states in contemporary underwater acoustics) or the wrong
place to be born. Norway has a very "egalitarian" cultural base, based
on the notion that no one should get advantages based on right of
birth. The country is unique in Europe in that is has had no
aristocracy
for centuries.

These days, "egalitarism" has degenerated to "skills or competence
is not essential, anybody can do anything". Polls show that Norwegian
students perform the worst of all European or OECD countries, when
tested for knowledge and skills. This is a pattern that is consistent
over age group and subject. To compensate, Norwegian students, by far,
have the "best" time at school, in the sense that they like being
at school, and enjoy the time they spend there.

So for some reason, competence and skills don't count at all when
hiring people. I even lost a job I applied for in my "ideal" company,
because I scored too high on the special competence the company was
after: "You are likely to see the flaws and quirks in our projects.
We want a loyal 'team player', not an obstinate trouble-maker."

They were, to be fair, right on both accounts: I do tend to see the
problems with the projects I have been involved with, and I do tend
to make my opinions known. As far as I know, I haven't been proven
wrong in any of my objections, though. But then, none of the projects
have worked.

So the company hired somebody who would never go against anybody,
and who would never be able to make a project, good or bad, work.
These patterns of employment will cause huge difficulties in just a
few years time. 

Rune

Rune Allnor wrote:
> 
> Andor wrote:
> 
>>Jerry Avins wrote:
>>...
>>
>>>Here, I tend to take questions at face value and try to answer them. As
>>>a consultant, I try to get at the root of the question: what prompted
>>>it?
> 
> 
> Hmmm.... I've seen you say that many times before, and it's the kind
> of thing I've tried to do myself. But in my experience, seeing past
> the customers requestes and to his needs, is interpreted by the
> customer as a claim of his incompetence. 

There are ways of presenting things diplomaticaly so you lessen the 
tendency for it to be so interpreted.  Here's a few:

1.  Let your surprise at being so lucky as to have stumbled onto the 
answer show.  Even if your surprise was 20 years ago when you were an 
undergrad, show it now.

2.  Give them an out; let them blame their teachers (oh, they just 
_never_ teach that stuff in school you have to learn the hard way -- 
wanna see my scars?).

3.  "Well, I'm just a math geek who can't pick up women: but while I've 
been failing socially look at what I found out about our problem".

> Which, of course, it is.

Not necessarily.  Folks can be competent in one area and not another, or 
they can just get blindsided.  I never assume that just because I'm 
really good at a few things means that I'm morally superior to any 
particular fellow human.  The truely incompetant will not accept that, 
of course, but most people understand this instinctively.
> 
> It's a highly dangerous route. One would be very lucky (well, stupid)
> to follow it through, into old age and retirement.
> 
Your comments on Norwegen culture follow.  It is, indeed, a narrow and 
rocky path.  In the US, however, it can lead to success if you gain a 
reputation for being right and you never, ever, try to take credit where 
it isn't due (letting things slide when others take credit for your work 
doesn't hurt, either).  I trumpet my own successes, but I always try to 
trumpet other's as well -- "Gee, I was really stuck until Phil asked 
about XXX, then I realized that I could do a Prsnorble transform on the 
system grap-knurl and by golly his idea is mathematically provable!".

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

Rune Allnor wrote:
> 
> Jerry Avins wrote:

   ...

>>It's a luxury that only very few employees ever have. I was fired once
>>for doing that, but I stayed with the company and the idiot who fired me
>>left instead. A few months later, he tried to hire me away. I declined.
> 
> 
> Seems to me as if you had support from competent people elsewhere
> in the company. 

Yes. And I had taken steps to cover my ass before the thing went down.

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

Jerry Avins wrote:
> Rune Allnor wrote:
> >
> > Jerry Avins wrote:
>
>    ...
>
> >>It's a luxury that only very few employees ever have. I was fired once
> >>for doing that, but I stayed with the company and the idiot who fired me
> >>left instead. A few months later, he tried to hire me away. I declined.
> >
> >
> > Seems to me as if you had support from competent people elsewhere
> > in the company.
>
> Yes. And I had taken steps to cover my ass before the thing went down.

Your carreer was more "luxorious" that I think you realize.

I was involved in a project for passive tracking of moving targets
from a stationary sensor. Some guy had done something almost similar,
he had "tracked" a stationary targed from a moving sensor. No problem,
whatsoever, just apply a Kalman filter to the bearing estimates, and
Voila! There's your position of the target. The method was basically
that of triangulation, where the one sensor was moved a little bit
between measurements.

The problem was, in the moving sensor scenario the observer knows
the triangulation baseline. He gets several independent measurements,
he knows the Closes Point of Approach, in short, he knows everything
he needs. In the stationary sensor scenario, on the other hand, nothing

is known. The bearing estimates depend on the velocity and course of
the target, which in general are not known. If they were, one would
probably possess enough information about the target to render the
passive system obsolete. To estimate a position by means of passive
stationary sensors, one needs at least two sensors, perhaps more,
depending on the sensors used. This is basic 7th grade maths.

[ There are, however, methods of finding the information needed about
the speed and course of very specific targets. These techniques do
not work in the general case. ]

Despite this, I was asked (well, ordered) by my then boss, with support

from may then former boss, a professor in underwater acoustics, to make

a general passive tracking system based on one stationary sensor.

I resigned from the job.

In my next job, I was involved in drafting a project proposal where
the objective was to design an "object positioning system" for marine
operations. Somebody wanted to deply a piece of kit on a specified
location at the sea floor, and we were asked to propose a "deployment
guidance system", to track the object as it descended through the
water. I had some nifty ideas about how to achieve this, what factors
to consider, how to exploit the equipment involved in the operation
etc.
Could have been a very interesting project, really.

What happened, was that my boss intervened, and said "We need only the
source position and the recieved signal. No need to make any additional

measurements, like sound speed in the water, we just need the signals."
I am not a mind reader, so I can only guess that he was influenced
by the infamous "focalization" paper I am so mad about. Apparently,
this guy actually thought it is possible to estimate position based
solely on thravel time and no knowledge of sound speeds.

The project proposal didn't pass, perhaps because of the obvious
lack of enthusiasm of the part of the draft, that I had written.

In the next project I was involved with, the objective was to estimate
the physical state of buried objects, no less. Once an object had been
located on the sea floor, my group was supposed to do detailed acoustic

measurements and use these to infer certain physical qualities of the
objects: Are there corrotion? Is a volume filled with sediments or with

water? Are the original contents leaking out?

Again, not very easy questions to answer (impossible, really, with
the acoustics and signal processing I know). The method of "analysis"
was "easy", according to my boss: "Take the measured data and compare
them to every possible model for the object, and run all possible
parameter sets through each model". Again, I am not good at reading
minds, but in this case I am pretty sure the project was "inspired"
by the "focalization" paper. There are not really much to say about
this kind of task description, so I didn't.

I went into a sick leave that eventually lasted for a full year.

Before you ask: It was not an option to go elsewhere in the companies/
organizations to find support. My various bosses were research
directors
and professors with 30 - 40 years each of "experience" in the business,

and were "top dogs" in these fields of "research". Needless to say,
the people who are recruited to this business (and stay), are those
who see no problems whatsoever with these types of projects.  

Rune

"Rune Allnor" <allnor@tele.ntnu.no> writes:
> [...]
> Despite this, I was asked (well, ordered) by my then boss, with support
>
> from may then former boss, a professor in underwater acoustics, to make
>
> a general passive tracking system based on one stationary sensor.
>
> I resigned from the job.

These are some amazing stories, Rune. Thanks for sharing them.

--Randy

-- 
%  Randy Yates                  % "Midnight, on the water... 
%% Fuquay-Varina, NC            %  I saw...  the ocean's daughter." 
%%% 919-577-9882                % 'Can't Get It Out Of My Head' 
%%%% <yates@ieee.org>           % *El Dorado*, Electric Light Orchestra
http://home.earthlink.net/~yatescr

"Jerry Avins" <jya@ieee.org> wrote in message 
news:P7OdnVqefvOZNkffRVn-vA@rcn.net...
>
>
> Yes. And I had taken steps to cover my ass before the thing went down.
>
> Jerry

Jerry,

That only proves that you're smarter than I am....  I took steps to make 
sure the reasons for likely failure were known - with the objective of 
finding solutions, workarounds, new approaches, etc.  Little did I know that 
some of them were only resolvable if there was extremely good luck ... 
somewhat similar to the old joke: [a miracle occurs here].

Fred