[kepler-dev] domain for signal procesing
Stephen Andrew Neuendorffer
neuendor at eecs.berkeley.edu
Wed Jun 16 16:36:42 PDT 2004
At 03:57 PM 6/16/2004, Tobin Fricke wrote:
>Ptolemy's ``simple signal processing'' examples work with sampled data
>that have globally synchronous sampling points and a fixed, universal
>sampling rate; these examples therefore are well-suited to the SDF domain.
>I'm wondering what would be the best model of computation for a more `real
>world' signal processing system. Signals could have idiosyncratic
>sampling rates and sampling that is in general not synchronized. Here
>each token is a measured value of a signal at an associated time stamp,
>and relations have an associated `sample rate' property. This sounds very
>much like the distributed discrete events (DDE) domain.
Not really... DDE is a whole 'nother beast entirely... It is a multi-threaded
>An actor might have two inputs providing non-synchronized data streams at
>differing sample rates. The actor would have to interpolate and resample
>these incoming data streams in order to act on them (say, to compute their
>sum) and ultimately produce a sampled output at a sample rate agreeable to
OK, so we know basically what we want to happen... the big questions to me
are: should this
be explicit or implictly specified? Is it part of the interaction between
part of an actor itself? Is ad-hoc interpolation 'good enough' to solve the
>In this case, data streams are representations of band-limited continuous
>signals. What would be an appropriate way of dealing with these in
As I understand it, each stream is periodic, but streams are not synchronous?
Or are you talking about random (non-periodic) samples? Are you dealing with
finite or infinite streams? My guess is that by 'band-limited' you mean
In which case, you can ignore the asynchrony in the sampling by just using
most recent sample... (Trivial interpolation through zero-order hold).
>- Provide explicit interpolation/resampling actors, carefully set the
> sample rate of each actor and each relation, and use the SDF domain?
This seems like one possibility... although it is fairly explicit, assumes
data, and makes the conversion part of composition.
>- Equip actors with interpolation/resampling abilities, and use the DDE
I would probably use DE instead of DDE (although, from your point of view, it
doesn't matter) I think the big difficulty with this (and with the SDF
solution above, in fact)
is the kind of interpolation you intend on doing... If you handle it
you will limit yourself to prediction based on previous values (estimate
x(t) given x(t-D-kT))
if you accept some delay in the system, then you can interpolate x(t) given
x(t-D-kT) and x(t-D+kT)
real interpolation kills you if there is any feedback.
Basically, this would put the interpolation implicitly in the actors
>- Provide continuous-time estimators in the sampled data sources and use
> (something like) the Continuous Time domain?
Basically, this would put the interpolation implicitly in the actor's
This would probably solve some of the issues with interpolation more
putting it in the receiving actors, although you would still have problems
>- Some fancy scheme whereby the Director resamples signals and provides
> actors with synchronized samples?
Basically, this would put the interpolation implicitly in the model of
>Ideas/comments/referrals to literature would be appreciated.
I can't think of anything I've seen off the top of my head, but it sounds
like an interesting problem...
I've thought about some of this in the context of control systems, where
you have the
additional constraint of wanting to minimize the delay in the system due to
In practice, the control system community generally oversamples heavily,
hold interpolation, and uses design techniques that are robust in the
presence of noise
to ensure good performance. This paper tries to address the control
by trying to accurately simulate the asynchrony using multiple models of
(see the end of section 5).
More information about the Kepler-dev