[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
discrete-event simulator.


>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
>downstream consumers.

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 
actors, or
part of an actor itself?  Is ad-hoc interpolation 'good enough' to solve the
signal-processing problem.


>In this case, data streams are representations of band-limited continuous
>signals.  What would be an appropriate way of dealing with these in
>Ptolemy?

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 
'extremely oversampled'?
In which case, you can ignore the asynchrony in the sampling by just using 
the previous
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 
periodically sampled
data, and makes the conversion part of composition.


>- Equip actors with interpolation/resampling abilities, and use the DDE
>   domain?

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 
'sequentially', then
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 
receiving data.


>- 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 
sending data.
This would probably solve some of the issues with interpolation more 
elegantly than
putting it in the receiving actors, although you would still have problems 
with feedback.


>- 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 
computation.


>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 
interpolation.
In practice, the control system community generally oversamples heavily, 
uses zero-order
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 
approximation
by trying to accurately simulate the asynchrony using multiple models of 
computation
in 
Ptolemy: 
http://ptolemy.eecs.berkeley.edu/publications/papers/04/BeyondHybridSystems/
(see the end of section 5).


>thanks,
>Tobin Fricke





More information about the Kepler-dev mailing list