RE: FM Demodulation problem (Lyons Ch. 13.22)

Rune Allnor wrote:

> Leaving the subtleties of professional jargon aside (we discussed
> this a couple of years ago, see
>
> http://groups.google.com/group/comp.dsp/browse_frm/thread/46174ccbd583b5bb/84aae22860faae18?q=author:allnor@tele.ntnu.no+trancedental+imaginary+magic&rnum=1#84aae22860faae18

The link didn't work. Try this one instead:

http://groups.google.com/group/comp.dsp/msg/84aae22860faae18

Rune

Rune Allnor wrote:

> Leaving the subtleties of professional jargon aside (we discussed
> this a couple of years ago, see
>
> http://groups.google.com/group/comp.dsp/browse_frm/thread/46174ccbd583b5bb/84aae22860faae18?q=author:allnor@tele.ntnu.no+trancedental+imaginary+magic&rnum=1#84aae22860faae18

The link didn't work. Try this one instead:

http://groups.google.com/group/comp.dsp/msg/84aae22860faae18

Rune

hi Rune,

not having followed this (or any other thread) very long, i might offer a
little refinement.  FWIW:

in article 1125530122.032278.293160@g44g2000cwa.googlegroups.com, Rune
Allnor at allnor@tele.ntnu.no wrote on 08/31/2005 19:15:

> The terms stay, since they express properties of the systems
> regardless of whether they are used on-line or off-line.

i presume what you mean by "on-line" process is what i usually mean by a
"real-time" process.  if that's not correct, lemme know.

> As you know, a non-causal system can not be implemented on-line,
> so the term serves a purpose in deciding what could be a suitable
> system for a given application. The term "causality" is, in the
> context of DSP, defined as
> 
> "There is no reaction at the output of a system for n < k, when the
> system is excited by a Kronecker delta signal d[n-k]"
> 
> where the d[n-k] signal was defined in my previous post.

i would say that this definition of a "causal system" is good only for
linear systems.  for a general signal processing system (analog or digital)
with inputs and outputs, i think the base definition of causal is that the
output at any time is a function of the inputs at only that present time and
at previous times.  a causal system's output cannot be a function of any
inputs at any future time.  that's the base definition.  that base
definition, plus the additional property that the system is linear results
in the definition you have above.

also, in an "off-line" process (i presume one that operates on a file or
buffer of data), i guess we can define the "present time" in the file to be
anywhere and since the "future" samples have already been recorded, then we
can create an acausal process that looks at those "future" samples.

-- 

r b-j                  rbj@audioimagination.com

"Imagination is more important than knowledge."

Rune Allnor wrote:

   ...

> So "causal" and "on-line" are not synonyms, with the obvious
> extension to "noncausal" and "off-line".

Yes indeed.

   ...

> If one rejects the terms causal/anticausal/noncausal just
> because one works off-line, one can remove the terms completely
> since the only would serve to obfuscate communications.
> 
> The terms stay, since they express properties of the systems
> regardless of whether they are used on-line or off-line.

If we share a pizza and I complain that my half is smaller than your 
half, we both know what I mean, but the arithmetic is faulty. Since the 
output of filtfilt doesn't happen until after it gets the input, how is 
it violate causality? After all, it remains true that everything that 
physically works must be causal. I think you find the word "causal" 
indispensable only because you use it to refer to something that it 
doesn't properly mean. (You are not alone.)

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

robert bristow-johnson wrote:

   ...

> also, in an "off-line" process (i presume one that operates on a file or
> buffer of data), i guess we can define the "present time" in the file to be
> anywhere and since the "future" samples have already been recorded, then we
> can create an acausal process that looks at those "future" samples.

Reading that I had an epiphany. The key is "acausal". It means "having 
nothing to do with causality"; my earlier use of it to mean "not causal" 
was simply incorrect. Consider the relation between "moral", "immoral", 
and "amoral".

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

robert bristow-johnson wrote:
> hi Rune,
>
> not having followed this (or any other thread) very long, i might offer a
> little refinement.  FWIW:
>
> in article 1125530122.032278.293160@g44g2000cwa.googlegroups.com, Rune
> Allnor at allnor@tele.ntnu.no wrote on 08/31/2005 19:15:
>
> > The terms stay, since they express properties of the systems
> > regardless of whether they are used on-line or off-line.
>
> i presume what you mean by "on-line" process is what i usually mean by a
> "real-time" process.  if that's not correct, lemme know.

Yes, I do.

> > As you know, a non-causal system can not be implemented on-line,
> > so the term serves a purpose in deciding what could be a suitable
> > system for a given application. The term "causality" is, in the
> > context of DSP, defined as
> >
> > "There is no reaction at the output of a system for n < k, when the
> > system is excited by a Kronecker delta signal d[n-k]"
> >
> > where the d[n-k] signal was defined in my previous post.
>
> i would say that this definition of a "causal system" is good only for
> linear systems.  for a general signal processing system (analog or digital)
> with inputs and outputs, i think the base definition of causal is that the
> output at any time is a function of the inputs at only that present time and
> at previous times.  a causal system's output cannot be a function of any
> inputs at any future time.  that's the base definition.  that base
> definition, plus the additional property that the system is linear results
> in the definition you have above.

I can't see how the restriction to linear systems fit in above,
otherwise
we agree completely.

> also, in an "off-line" process (i presume one that operates on a file or
> buffer of data), i guess we can define the "present time" in the file to be
> anywhere and since the "future" samples have already been recorded, then we
> can create an acausal process that looks at those "future" samples.

My point exactly.

Rune

On 25 Aug 2005 14:08:56 -0700, "Jerry W." <sl_jerry1@hotmail.com>
wrote:

>I've been looking more closely at Chap. 13.22 (of Lyons, 2nd. ed.) and
>at Rune's MATLAB code, and I have two questions.

Hi Jerry,

>  1. In Fig. 13-61a on p. 551, doesn't the lower branch (the inverse of
>the magnitude) need the same Delay as the i(n) and q(n), to keep it
>time-aligned with the Differentiator outputs?

Yes, you (and Clay) are correct.  A time delay is needed either just 
before or just after the "Inverse" operation in Figure 13-61(a).
The length of that (missing) delay element should be 
the same length as the delays in the I and Q input paths.

Forgive me for failing to include that delay element in the figure
Jerry and "Thanks Much" for pointing it out to me.  Your name is 
now officially on the list of guys to whom I owe a beer.

The 3-tap differentiator in Figure 13-61(b) was the 
simplest (fewest computations) differentiator that I could 
think of that had an integer-valued delay.
As far as I know, that differentiator is called a 
"central difference" differentiator.

See Ya',
[-Rick-]

On 25 Aug 2005 14:08:56 -0700, "Jerry W." <sl_jerry1@hotmail.com>
wrote:

Hi,
  Oops I forgot to say, Jerry, that if you send me 
(remove the "_BOGUS_" from my address) the 
"Printing Number" of your copy of my book, I'll 
send you the errata for your copy.

Good Luck & See Ya',
[-Rick-]
 

On 25 Aug 2005 14:08:56 -0700, "Jerry W." <sl_jerry1@hotmail.com>
wrote:

Hi Jerry,
  I forgot to mention (in my earlier post) 
that the 3-tap differentiators in Figure 13-61(b)
only work "well" for low frequency signals.
That's because this 3-tap digital differentiator only 
approximates true differentiation over the 
frequency range of zero Hz to, say, one tenth 
of the sample rate.

This behavior is a kind of DSP truism:

  "Simple (3-tap) processing yields poor performance.
   High performance requires many computations."

[-Rick-]