Neat idea.
I agree that implementing a digital tracking PLL in
the AtomPro code would be significant hassle.
Probably the easiest hardware solution would be to
remove the clock resonator from the AtomPros and run
all of them from a common clock oscillator. That would
probably mean building up a separate clock source with
multiple outputs.
Unfortunately, the H8/3664 that the AtomPro is based
on doesn't have an on-chip PLL like many MCUs
available today do. This means that the clock source
has to be full rate, rather than a lower frequency
reference.
Probably a bit more hackery than most folks want to
deal with.
Eric
--- drmabuce <
drmabuce@...> wrote:
> Hi All
> External sync at the 'macro-level' as described by
> Maestro Chang
> must be implemented at the application code level. i
> ,for one, don't
> relish the prospect of trying to code smooth (or as
> smooth as a DAC
> allows) portamento in 24ppq increments. Things get
> zippery enough for
> me at full-on processor speed. But i'm way more of
> an app. guy than a
> 'kernel' guy so i put the question to some of you
> engine tweakers....
> Is the prospect of syncing the main clock of
> multiple BasicAtom's
> to a common timing reference unfeasible?
> i grasp that the processor is using a resonator
> for it's timing
> components and that Xtal components would be more
> accurate. Also these
> are passive , on board components of course and i
> know better than to
> think that multiple processors can 'share' an Xtal
> especially over a
> physical distance so i suppose my questions is
> whether there's an
> 'active' circuit that could overcome physical
> proximity (et al) issues
> and serve as a common reference for multiple
> BasicAtoms?
>
> -doc
>
>
>
>
>
>
> --- In ComputerVoltageSources@yahoogroups.com, "Gary
> Chang"
> <gchang@...> wrote:
> >
> > Regardless of the accuracy of the timing source or
> the AtomPro (and
> > its scientific accuracy), it is essential that an
> external sync
> > reference can be used to enable the PSIM to
> reliably playback at the
> > same exact tempo. This could be something as
> simple as an audio tone.
> > (I would generate a tone from a pluging in my
> DAW, making it
> > repeatable and reliable). The issue is the
> frequency of the pilot
> > tone, whether it be something mundane and standard
> like a 24 ppn midi
> > click that tempo changes with frequency, or a
> higher resolution
> > constant clock that allows for different tempos to
> be subdivided
> from it.
> >
> > A MIDI timecode-locked device is running off of
> its internal clock,
> > but is periodically checking its timecode position
> to the timecode
> > coming it is being fed from the master. If the
> device is reasonably
> > accurate (within a milliscond or two in a minute),
> this method can be
> > employed. A routine of error compensation is
> employed to keep the
> > slave close to the master. Most computer based
> sequencing apps run in
> > this mode.
> >
> > A MIDI click-locked device takes the 24 pulse per
> note midi clock
> > pulse stream and references all timing information
> to that.
> >
> > gary
> >
>
>
>
____________________________________________________________________________________
Finding fabulous fares is fun.
Let Yahoo! FareChase search your favorite travel sites to find flight and hotel bargains.
http://farechase.yahoo.com/promo-generic-14795097