ComputerVoltageSources

Being one of very few that has more than one of the PSIM-1 module, I
did a little test to evaluate the relative timing accuracy of the
PSIM'S internal clock, by loading the maf-lfo2.bas application into
each of three modules and starting them with a common start pulse.

The test results can be heard in an mp3 called PSIM mayhem, found in
the files folder of this group.

So - it looks as if we are going to need an external sync reference to
get these guys to be time reliable. Probably a simple pilot tone
(such as a vco) would be the easiest to reference....

GC

Gary,

The INIT routine in maf-lfo2.bas contains approximately 1.2 seconds of delay
in a for/next loop to flash the LEDs on and off, and then another 100ms
before it even looks for the start signal from either the start button or
input. Each of your three PSIM-1 modules may be in a different part of the
loop before getting the start signal.

Try the attached file. I modified the INIT sequence and removed the pauses
and blinking LEDs. This is as close as you'll get to a synced startup
sequence. The ATOM-Pro processes approximately 100k lines of code per
second. This is in a tight loop of 3 lines of code waiting for the *start*.
Should be close enough. :)

Let me know...

Best regards,
Brice

----- Original Message -----
From: "Gary Chang" <gchang@...>
To: <ComputerVoltageSources@yahoogroups.com>
Sent: Tuesday, January 09, 2007 4:26 AM
Subject: [ComputerVoltageSources] Atompro timing anomolies....


> Being one of very few that has more than one of the PSIM-1 module, I
> did a little test to evaluate the relative timing accuracy of the
> PSIM'S internal clock, by loading the maf-lfo2.bas application into
> each of three modules and starting them with a common start pulse.
>
> The test results can be heard in an mp3 called PSIM mayhem, found in
> the files folder of this group.
>
> So - it looks as if we are going to need an external sync reference to
> get these guys to be time reliable. Probably a simple pilot tone
> (such as a vco) would be the easiest to reference....
>
> GC
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>


[Non-text portions of this message have been removed]

The data sheet for the AtomPro24 specifies a 16 MHz resonator, not a
crystal. Resonators are about 0.5% accurate, vs. a crystal that is
measured in ppm. At .5% accuracy, after 60 seconds your PSIMs could
be off by 300 mS, or as much as 600 mS if one was +.5% and one was -.
5%. I always thought that they had crystals, but when I wrote my
clock program, I noticed that it gained or lost time after minutes and
hours. A crystal should be better than this so I think they are
resonators.

I would synchronize the PSIMs. I'm not sure what Aux is doing since
inputs and outputs are not documented in the code. Perhaps one PSIM
could 'watch' the other Aux output to synchronize. There would be a
little latency but this could be accommodated by adding appropriate
delay in the master PSIM.

I personally would use my MIDI for synchronization as a background
communication channel. I would simply send a status byte from one
PSIM to the other to keep then synchronized or perhaps to even send a
timestamp value. I've always been a proponent of MIDI on the PSIM,
even if you aren't using MIDI, as a way of expanding capability. I
think John Loffink has some of the display/MIDI expansion boards still
available and have been just amazed that PSIM owners haven't snapped
them up.

I'd comment more on how to synchronize this program, but don't have
the patience to figure out inputs, outputs, and functionality in
generally undocumented code.

When I get my second module going, I'll probably look into how to
synchronize programs. In general, I'd probably use a timer as a real-
time reference. I generally run it at 1 mS interrupts. It would be
easy to generate an event on a binary value, such as on the 256th
count, or so, in the interupt routine to pulse Aux. On the other
PSIM, I'd setup Aux as an edge trigger as use the interrupt to
synchronize the real time reference to the nearest 256 timer count.
All outputs would be referenced to this real time reference, and not
pause commands. Seems very doable.

Dave


--- In ComputerVoltageSources@yahoogroups.com, "Gary Chang" <gchang@.
..> wrote:

>
> Being one of very few that has more than one of the PSIM-1 module, I
> did a little test to evaluate the relative timing accuracy of the
> PSIM'S internal clock, by loading the maf-lfo2.bas application into
> each of three modules and starting them with a common start pulse.
>
> The test results can be heard in an mp3 called PSIM mayhem, found in
> the files folder of this group.
>
> So - it looks as if we are going to need an external sync reference

to

> get these guys to be time reliable. Probably a simple pilot tone
> (such as a vco) would be the easiest to reference....
>
> GC
>

Dave,

First off, thanks for the analysis - indeed, the phasing of the three
PSIMs seems to coincide with the 5% error spec that you list in your note.

Dave, when you finally get down to it (syncing your two PSIMs, that
is), please consider just creating an external sync clock input, so
that each of the PSIMs will run from a common external clock - there
is no need to provide a way for a 'master' PSIM to slave another PSIM,
since the master clock is not accurate enough to be useful!

A simple clock input, with supporting code to specify what the PSIM is
hearing (240 ppm, 96 ppm, 24 ppm, etc.) would be useful.


Gary




"djbrow54" <davebr@...> wrote:

>
> The data sheet for the AtomPro24 specifies a 16 MHz resonator, not a
> crystal. Resonators are about 0.5% accurate, vs. a crystal that is
> measured in ppm. At .5% accuracy, after 60 seconds your PSIMs could
> be off by 300 mS, or as much as 600 mS if one was +.5% and one was -.
> 5%. I always thought that they had crystals, but when I wrote my
> clock program, I noticed that it gained or lost time after minutes and
> hours. A crystal should be better than this so I think they are
> resonators.
>
> I would synchronize the PSIMs. I'm not sure what Aux is doing since
> inputs and outputs are not documented in the code. Perhaps one PSIM
> could 'watch' the other Aux output to synchronize. There would be a
> little latency but this could be accommodated by adding appropriate
> delay in the master PSIM.
>
> I personally would use my MIDI for synchronization as a background
> communication channel. I would simply send a status byte from one
> PSIM to the other to keep then synchronized or perhaps to even send a
> timestamp value. I've always been a proponent of MIDI on the PSIM,
> even if you aren't using MIDI, as a way of expanding capability. I
> think John Loffink has some of the display/MIDI expansion boards still
> available and have been just amazed that PSIM owners haven't snapped
> them up.
>
> I'd comment more on how to synchronize this program, but don't have
> the patience to figure out inputs, outputs, and functionality in
> generally undocumented code.
>
> When I get my second module going, I'll probably look into how to
> synchronize programs. In general, I'd probably use a timer as a real-
> time reference. I generally run it at 1 mS interrupts. It would be
> easy to generate an event on a binary value, such as on the 256th
> count, or so, in the interupt routine to pulse Aux. On the other
> PSIM, I'd setup Aux as an edge trigger as use the interrupt to
> synchronize the real time reference to the nearest 256 timer count.
> All outputs would be referenced to this real time reference, and not
> pause commands. Seems very doable.
>
> Dave
>
>
> --- In ComputerVoltageSources@yahoogroups.com, "Gary Chang" <gchang@
> ..> wrote:
> >
> > Being one of very few that has more than one of the PSIM-1 module, I
> > did a little test to evaluate the relative timing accuracy of the
> > PSIM'S internal clock, by loading the maf-lfo2.bas application into
> > each of three modules and starting them with a common start pulse.
> >
> > The test results can be heard in an mp3 called PSIM mayhem, found in
> > the files folder of this group.
> >
> > So - it looks as if we are going to need an external sync reference
> to
> > get these guys to be time reliable. Probably a simple pilot tone
> > (such as a vco) would be the easiest to reference....
> >
> > GC
> >
>

Brice,

If you listen to the mp3, you will note that 1). All three PSIMs
start simultaneously and together, so there is no issue in the
preliminary codes of the application....

Even if this were the case, and the PSIMs' timing were identical, the
result would be a constant delay between the modules, not a every
widening delay, which what you hear when the speed is slightly
different (as demonstrated in the mp3).

Dave is right on this one - the PSIMs reflect a 5% error on speed
accuracy.

gary


"Brice D. Hornback" <bdh@...> wrote:

>
> Gary,
>
> The INIT routine in maf-lfo2.bas contains approximately 1.2 seconds

of delay

> in a for/next loop to flash the LEDs on and off, and then another 100ms
> before it even looks for the start signal from either the start

button or

> input. Each of your three PSIM-1 modules may be in a different part

of the

> loop before getting the start signal.
>
> Try the attached file. I modified the INIT sequence and removed the

pauses

> and blinking LEDs. This is as close as you'll get to a synced startup
> sequence. The ATOM-Pro processes approximately 100k lines of code per
> second. This is in a tight loop of 3 lines of code waiting for the

*start*.

> Should be close enough. :)
>
> Let me know...
>
> Best regards,
> Brice
>
> ----- Original Message -----
> From: "Gary Chang" <gchang@...>
> To: <ComputerVoltageSources@yahoogroups.com>
> Sent: Tuesday, January 09, 2007 4:26 AM
> Subject: [ComputerVoltageSources] Atompro timing anomolies....
>
>
> > Being one of very few that has more than one of the PSIM-1 module, I
> > did a little test to evaluate the relative timing accuracy of the
> > PSIM'S internal clock, by loading the maf-lfo2.bas application into
> > each of three modules and starting them with a common start pulse.
> >
> > The test results can be heard in an mp3 called PSIM mayhem, found in
> > the files folder of this group.
> >
> > So - it looks as if we are going to need an external sync reference to
> > get these guys to be time reliable. Probably a simple pilot tone
> > (such as a vco) would be the easiest to reference....
> >
> > GC
> >
> >
> >
> >
> >
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
>
>
> [Non-text portions of this message have been removed]
>

You are right. Synchronizing the PSIMs will not improve the accuracy,
it will only make all track together. If the overall accuracy is not
good enough, an external clock would be a good solution. However, the
error might be fairly constant. In my clock program, for example, I
can correct it by adjusting the timer to ~1 mS by measuring the
frequency externally and changing the divisors. You might be able to
do something similar with a correction factor if error is constant.

Another option is to replace the resonator on the AtomPro. I have
replace the power-on reset chip on my AtomPro28. You'd have to find a
crystal with the right dimensions and have a steady hand ...

Dave

--- In ComputerVoltageSources@yahoogroups.com, "Gary Chang" <gchang@.
..> wrote:

>
> Dave,
>
> First off, thanks for the analysis - indeed, the phasing of the

three

> PSIMs seems to coincide with the 5% error spec that you list in your

note.

>
> Dave, when you finally get down to it (syncing your two PSIMs, that
> is), please consider just creating an external sync clock input, so
> that each of the PSIMs will run from a common external clock - there
> is no need to provide a way for a 'master' PSIM to slave another

PSIM,

> since the master clock is not accurate enough to be useful!
>
> A simple clock input, with supporting code to specify what the PSIM

is

> hearing (240 ppm, 96 ppm, 24 ppm, etc.) would be useful.
>
>
> Gary
>
>
>
>
> "djbrow54" <davebr@> wrote:
> >
> > The data sheet for the AtomPro24 specifies a 16 MHz resonator, not

a

> > crystal. Resonators are about 0.5% accurate, vs. a crystal that

is

> > measured in ppm. At .5% accuracy, after 60 seconds your PSIMs

could

> > be off by 300 mS, or as much as 600 mS if one was +.5% and one was

-.

> > 5%. I always thought that they had crystals, but when I wrote my
> > clock program, I noticed that it gained or lost time after minutes

and

> > hours. A crystal should be better than this so I think they are
> > resonators.
> >
> > I would synchronize the PSIMs. I'm not sure what Aux is doing

since

> > inputs and outputs are not documented in the code. Perhaps one

PSIM

> > could 'watch' the other Aux output to synchronize. There would be

a

> > little latency but this could be accommodated by adding

appropriate

> > delay in the master PSIM.
> >
> > I personally would use my MIDI for synchronization as a background
> > communication channel. I would simply send a status byte from one
> > PSIM to the other to keep then synchronized or perhaps to even

send a

> > timestamp value. I've always been a proponent of MIDI on the

PSIM,

> > even if you aren't using MIDI, as a way of expanding capability.

I

> > think John Loffink has some of the display/MIDI expansion boards

still

> > available and have been just amazed that PSIM owners haven't

snapped

> > them up.
> >
> > I'd comment more on how to synchronize this program, but don't

have

> > the patience to figure out inputs, outputs, and functionality in
> > generally undocumented code.
> >
> > When I get my second module going, I'll probably look into how to
> > synchronize programs. In general, I'd probably use a timer as a

real-

> > time reference. I generally run it at 1 mS interrupts. It would

be

> > easy to generate an event on a binary value, such as on the 256th
> > count, or so, in the interupt routine to pulse Aux. On the other
> > PSIM, I'd setup Aux as an edge trigger as use the interrupt to
> > synchronize the real time reference to the nearest 256 timer

count.

> > All outputs would be referenced to this real time reference, and

not

> > pause commands. Seems very doable.
> >
> > Dave
> >
> >
> > --- In ComputerVoltageSources@yahoogroups.com, "Gary Chang"

<gchang@

> > ..> wrote:
> > >
> > > Being one of very few that has more than one of the PSIM-1

module, I

> > > did a little test to evaluate the relative timing accuracy of

the

> > > PSIM'S internal clock, by loading the maf-lfo2.bas application

into

> > > each of three modules and starting them with a common start

pulse.

> > >
> > > The test results can be heard in an mp3 called PSIM mayhem,

found in

> > > the files folder of this group.
> > >
> > > So - it looks as if we are going to need an external sync

reference

> > to
> > > get these guys to be time reliable. Probably a simple pilot

tone

> > > (such as a vco) would be the easiest to reference....
> > >
> > > GC
> > >
> >
>

Actually, I said 0.5%, not 5%.

I opened the file Psim madness.mp3 in an editor and measured the
delay. There are three pings, correct? At 1 minute 23.582 seconds,
the second ping was 100 mS late and the third ping was 220 mS late.

At 83.5 seconds, the second PSIM represents an error of 0.1/83.5, or
0.12% (~1/10 of 1 percent). Not bad. The third ping represents an
error of 0.22/83.5, or 0.26%.

Certainly these aren't accurate enough to track together over long
periods of time, but for overall timing accuracy, how tight do you
need it? My sense of timing isn't that precise.

Dave


--- In ComputerVoltageSources@yahoogroups.com, "Gary Chang" <gchang@.
..> wrote:

>
> Dave,
>
> First off, thanks for the analysis - indeed, the phasing of the

three

> PSIMs seems to coincide with the 5% error spec that you list in your

note.

>
> Dave, when you finally get down to it (syncing your two PSIMs, that
> is), please consider just creating an external sync clock input, so
> that each of the PSIMs will run from a common external clock - there
> is no need to provide a way for a 'master' PSIM to slave another

PSIM,

> since the master clock is not accurate enough to be useful!
>
> A simple clock input, with supporting code to specify what the PSIM

is

> hearing (240 ppm, 96 ppm, 24 ppm, etc.) would be useful.
>
>
> Gary
>
>
>
>
> "djbrow54" <davebr@> wrote:
> >
> > The data sheet for the AtomPro24 specifies a 16 MHz resonator, not

a

> > crystal. Resonators are about 0.5% accurate, vs. a crystal that

is

> > measured in ppm. At .5% accuracy, after 60 seconds your PSIMs

could

> > be off by 300 mS, or as much as 600 mS if one was +.5% and one was

-.

> > 5%. I always thought that they had crystals, but when I wrote my
> > clock program, I noticed that it gained or lost time after minutes

and

> > hours. A crystal should be better than this so I think they are
> > resonators.
> >
> > I would synchronize the PSIMs. I'm not sure what Aux is doing

since

> > inputs and outputs are not documented in the code. Perhaps one

PSIM

> > could 'watch' the other Aux output to synchronize. There would be

a

> > little latency but this could be accommodated by adding

appropriate

> > delay in the master PSIM.
> >
> > I personally would use my MIDI for synchronization as a background
> > communication channel. I would simply send a status byte from one
> > PSIM to the other to keep then synchronized or perhaps to even

send a

> > timestamp value. I've always been a proponent of MIDI on the

PSIM,

> > even if you aren't using MIDI, as a way of expanding capability.

I

> > think John Loffink has some of the display/MIDI expansion boards

still

> > available and have been just amazed that PSIM owners haven't

snapped

> > them up.
> >
> > I'd comment more on how to synchronize this program, but don't

have

> > the patience to figure out inputs, outputs, and functionality in
> > generally undocumented code.
> >
> > When I get my second module going, I'll probably look into how to
> > synchronize programs. In general, I'd probably use a timer as a

real-

> > time reference. I generally run it at 1 mS interrupts. It would

be

> > easy to generate an event on a binary value, such as on the 256th
> > count, or so, in the interupt routine to pulse Aux. On the other
> > PSIM, I'd setup Aux as an edge trigger as use the interrupt to
> > synchronize the real time reference to the nearest 256 timer

count.

> > All outputs would be referenced to this real time reference, and

not

> > pause commands. Seems very doable.
> >
> > Dave
> >
> >
> > --- In ComputerVoltageSources@yahoogroups.com, "Gary Chang"

<gchang@

> > ..> wrote:
> > >
> > > Being one of very few that has more than one of the PSIM-1

module, I

> > > did a little test to evaluate the relative timing accuracy of

the

> > > PSIM'S internal clock, by loading the maf-lfo2.bas application

into

> > > each of three modules and starting them with a common start

pulse.

> > >
> > > The test results can be heard in an mp3 called PSIM mayhem,

found in

> > > the files folder of this group.
> > >
> > > So - it looks as if we are going to need an external sync

reference

> > to
> > > get these guys to be time reliable. Probably a simple pilot

tone

> > > (such as a vco) would be the easiest to reference....
> > >
> > > GC
> > >
> >
>

"djbrow54" <davebr@...> wrote:

>
> Actually, I said 0.5%, not 5%.
>
> I opened the file Psim madness.mp3 in an editor and measured the
> delay. There are three pings, correct?

yes, three pings.

At 1 minute 23.582 seconds,

> the second ping was 100 mS late and the third ping was 220 mS late.
>
> At 83.5 seconds, the second PSIM represents an error of 0.1/83.5, or
> 0.12% (~1/10 of 1 percent). Not bad. The third ping represents an
> error of 0.22/83.5, or 0.26%.

not bad for setting off explosives...8*)

>
> Certainly these aren't accurate enough to track together over long
> periods of time, but for overall timing accuracy, how tight do you
> need it? My sense of timing isn't that precise.

The length of Psim Madness is not long in terms of music duration -
any typical piece of music is much longer than that. Honestly, a high
school music student has a better sense of time than the PSIM.

INHO, ability to slave the PSIM is essential.

If these devices can't play 16 bars together with something else, it's
pretty much useless as a sequential pitch source.... except for a
phasing minimalist piece (such as PSIM madness).


gary

>
> --- In ComputerVoltageSources@yahoogroups.com, "Gary Chang" <gchang@
> ..> wrote:
> >
> > Dave,
> >
> > First off, thanks for the analysis - indeed, the phasing of the
> three
> > PSIMs seems to coincide with the 5% error spec that you list in your
> note.
> >
> > Dave, when you finally get down to it (syncing your two PSIMs, that
> > is), please consider just creating an external sync clock input, so
> > that each of the PSIMs will run from a common external clock - there
> > is no need to provide a way for a 'master' PSIM to slave another
> PSIM,
> > since the master clock is not accurate enough to be useful!
> >
> > A simple clock input, with supporting code to specify what the PSIM
> is
> > hearing (240 ppm, 96 ppm, 24 ppm, etc.) would be useful.
> >
> >
> > Gary
> >
> >
> >
> >
> > "djbrow54" <davebr@> wrote:
> > >
> > > The data sheet for the AtomPro24 specifies a 16 MHz resonator, not
> a
> > > crystal. Resonators are about 0.5% accurate, vs. a crystal that
> is
> > > measured in ppm. At .5% accuracy, after 60 seconds your PSIMs
> could
> > > be off by 300 mS, or as much as 600 mS if one was +.5% and one was
> -.
> > > 5%. I always thought that they had crystals, but when I wrote my
> > > clock program, I noticed that it gained or lost time after minutes
> and
> > > hours. A crystal should be better than this so I think they are
> > > resonators.
> > >
> > > I would synchronize the PSIMs. I'm not sure what Aux is doing
> since
> > > inputs and outputs are not documented in the code. Perhaps one
> PSIM
> > > could 'watch' the other Aux output to synchronize. There would be
> a
> > > little latency but this could be accommodated by adding
> appropriate
> > > delay in the master PSIM.
> > >
> > > I personally would use my MIDI for synchronization as a background
> > > communication channel. I would simply send a status byte from one
> > > PSIM to the other to keep then synchronized or perhaps to even
> send a
> > > timestamp value. I've always been a proponent of MIDI on the
> PSIM,
> > > even if you aren't using MIDI, as a way of expanding capability.
> I
> > > think John Loffink has some of the display/MIDI expansion boards
> still
> > > available and have been just amazed that PSIM owners haven't
> snapped
> > > them up.
> > >
> > > I'd comment more on how to synchronize this program, but don't
> have
> > > the patience to figure out inputs, outputs, and functionality in
> > > generally undocumented code.
> > >
> > > When I get my second module going, I'll probably look into how to
> > > synchronize programs. In general, I'd probably use a timer as a
> real-
> > > time reference. I generally run it at 1 mS interrupts. It would
> be
> > > easy to generate an event on a binary value, such as on the 256th
> > > count, or so, in the interupt routine to pulse Aux. On the other
> > > PSIM, I'd setup Aux as an edge trigger as use the interrupt to
> > > synchronize the real time reference to the nearest 256 timer
> count.
> > > All outputs would be referenced to this real time reference, and
> not
> > > pause commands. Seems very doable.
> > >
> > > Dave
> > >
> > >
> > > --- In ComputerVoltageSources@yahoogroups.com, "Gary Chang"
> <gchang@
> > > ..> wrote:
> > > >
> > > > Being one of very few that has more than one of the PSIM-1
> module, I
> > > > did a little test to evaluate the relative timing accuracy of
> the
> > > > PSIM'S internal clock, by loading the maf-lfo2.bas application
> into
> > > > each of three modules and starting them with a common start
> pulse.
> > > >
> > > > The test results can be heard in an mp3 called PSIM mayhem,
> found in
> > > > the files folder of this group.
> > > >
> > > > So - it looks as if we are going to need an external sync
> reference
> > > to
> > > > get these guys to be time reliable. Probably a simple pilot
> tone
> > > > (such as a vco) would be the easiest to reference....
> > > >
> > > > GC
> > > >
> > >
> >
>

Tell me more about the timing requiremetns. In looking at
metronomes, "highly accurate" is described as +/- 1%. The PSIM is
better than that. In a 5 minute musical piece, 1% accuracy would be
3 seconds. 0.1% would be 300 mS. I don't know the exact accuracy
of the PSIM since I don't know the resonator used but it is probably
well less than the 1%.

Is this something that MIDI timing clocks could be used for? If
MIDI could be used as a master clock, it would be easy to build a
reference timebase. My first MIDI code implemented an interrupt
routine for input. I later adopted to the HSERIN command which
buffers the data. Going back to my original code, I could use real
time nature of the interrupt to implement a real time clock. I have
no relevant experience with MIDI clock and synchronization. It would
be simple to add and implement, though. Multiple PSIMs would be
synchronized to the same MIDI reference. In fact, an AVR2313 with a
crystal and two resistors could be used to generate such a
reference. Might be a nifty accessory.

Dave

--- In ComputerVoltageSources@yahoogroups.com, "Gary Chang" > The
length of Psim Madness is not long in terms of music duration -

> any typical piece of music is much longer than that. Honestly, a

high

> school music student has a better sense of time than the PSIM.
>
> INHO, ability to slave the PSIM is essential.
>
> If these devices can't play 16 bars together with something else,

it's

> pretty much useless as a sequential pitch source.... except for a
> phasing minimalist piece (such as PSIM madness).
>
>
> gary

"djbrow54" <davebr@...> wrote:

>
> Tell me more about the timing requiremetns. In looking at
> metronomes, "highly accurate" is described as +/- 1%.

The only "accurate" metronomes were manufactured for the film industry
by UREI - the 900 and 962 Digital Metronomes. They are the metronomes
that every film score was recorded to from post WWII until the advent
of computer generated tempos. These metronomes were designed so that
you could record music on two different days, or at two different
locations and the tempos would be exactly the same. Starting two of
these metronomes together would result in the exact same tempos for
over 10 minutes. They were crystal clocked.

>
> Is this something that MIDI timing clocks could be used for? If
> MIDI could be used as a master clock, it would be easy to build a
> reference timebase. My first MIDI code implemented an interrupt
> routine for input.

I later adopted to the HSERIN command which

> buffers the data. Going back to my original code, I could use real
> time nature of the interrupt to implement a real time clock. I have
> no relevant experience with MIDI clock and synchronization. It would
> be simple to add and implement, though.

A good model about syncronization is to consider syncronizing two
computers that are playing back a recording of an instrument. If
there is a proper lock in syncronization, the two tracks will phase.
Improper syncing results in a phenomena similar to PSIM Madness...


Multiple PSIMs would be

> synchronized to the same MIDI reference. In fact, an AVR2313 with a
> crystal and two resistors could be used to generate such a
> reference. Might be a nifty accessory.

Sounds like an essential accessory!

gary

>
> --- In ComputerVoltageSources@yahoogroups.com, "Gary Chang" > The
> length of Psim Madness is not long in terms of music duration -
> > any typical piece of music is much longer than that. Honestly, a
> high
> > school music student has a better sense of time than the PSIM.
> >
> > INHO, ability to slave the PSIM is essential.
> >
> > If these devices can't play 16 bars together with something else,
> it's
> > pretty much useless as a sequential pitch source.... except for a
> > phasing minimalist piece (such as PSIM madness).
> >
> >
> > gary
>

Dave,

Take a look at this:
http://www.sparkfun.com/commerce/product_info.php?products_id=99#

Yes, you could build one pretty cheap but this is plug 'n play and
pretty cheap already (no building required).

Besides adding an I2C realtime clock w/ battery backup to the AtomPRO
that should stay accurate to within 1 minute per month (~20ppm
accuracy), it has a 1Hz output pin (square wave) that could be used
as a timing pulse to syncronize multiple AtomPROs.

Also, if you really want to go nuts... one could remove the
oscillator, the two caps, and one resistor from the AtomPro and use
an external clock source (such as a frequency generator synced with a
cesium frequency standard) to the OSC1 pin on the H8/3664. See page
69 in the H8/3664 datasheet for details on using an External Clock
Input.

One thing I did notice was that the datasheet shows when not using a
Subclock, X1 connected to VCL or VSS yet on the AtomPRO schematic is
shows them both as not connected to anything. I wonder if this could
cause some drift issues. Thoughts?

Best regards,
Brice


--- In ComputerVoltageSources@yahoogroups.com, "djbrow54"
<davebr@...> wrote:

>
> Tell me more about the timing requiremetns. In looking at
> metronomes, "highly accurate" is described as +/- 1%. The PSIM is
> better than that. In a 5 minute musical piece, 1% accuracy would

be

> 3 seconds. 0.1% would be 300 mS. I don't know the exact accuracy
> of the PSIM since I don't know the resonator used but it is

probably

> well less than the 1%.
>
> Is this something that MIDI timing clocks could be used for? If
> MIDI could be used as a master clock, it would be easy to build a
> reference timebase. My first MIDI code implemented an interrupt
> routine for input. I later adopted to the HSERIN command which
> buffers the data. Going back to my original code, I could use real
> time nature of the interrupt to implement a real time clock. I

have

> no relevant experience with MIDI clock and synchronization. It

would

> be simple to add and implement, though. Multiple PSIMs would be
> synchronized to the same MIDI reference. In fact, an AVR2313 with

a

> crystal and two resistors could be used to generate such a
> reference. Might be a nifty accessory.
>
> Dave
>
> --- In ComputerVoltageSources@yahoogroups.com, "Gary Chang" > The
> length of Psim Madness is not long in terms of music duration -
> > any typical piece of music is much longer than that. Honestly, a
> high
> > school music student has a better sense of time than the PSIM.
> >
> > INHO, ability to slave the PSIM is essential.
> >
> > If these devices can't play 16 bars together with something else,
> it's
> > pretty much useless as a sequential pitch source.... except for a
> > phasing minimalist piece (such as PSIM madness).
> >
> >
> > gary
>

The Urei 960 digital metronome is more accurate than most computers
that are running music software. In the case of music computers that
aspire to be as accurate as the 960, (such as the Synclavier, for
instance), there is a calibration routine.... On the Synclavier, the
routine counts 30 clicks that it generates for 30 seconds, and then
biases the calibration to make the metronome as accurate as possible.

Or, as an alternative, comprehensive digital music systems have tempos
that are locked to the external sync clock input of the digital/analog
interface....



gc



"bdhornback" <bdh@...> wrote:

>
> Dave,
>
> Take a look at this:
> http://www.sparkfun.com/commerce/product_info.php?products_id=99#
>
> Yes, you could build one pretty cheap but this is plug 'n play and
> pretty cheap already (no building required).
>
> Besides adding an I2C realtime clock w/ battery backup to the AtomPRO
> that should stay accurate to within 1 minute per month (~20ppm
> accuracy), it has a 1Hz output pin (square wave) that could be used
> as a timing pulse to syncronize multiple AtomPROs.
>
> Also, if you really want to go nuts... one could remove the
> oscillator, the two caps, and one resistor from the AtomPro and use
> an external clock source (such as a frequency generator synced with a
> cesium frequency standard) to the OSC1 pin on the H8/3664. See page
> 69 in the H8/3664 datasheet for details on using an External Clock
> Input.
>
> One thing I did notice was that the datasheet shows when not using a
> Subclock, X1 connected to VCL or VSS yet on the AtomPRO schematic is
> shows them both as not connected to anything. I wonder if this could
> cause some drift issues. Thoughts?
>
> Best regards,
> Brice
>
>
> --- In ComputerVoltageSources@yahoogroups.com, "djbrow54"
> <davebr@> wrote:
> >
> > Tell me more about the timing requiremetns. In looking at
> > metronomes, "highly accurate" is described as +/- 1%. The PSIM is
> > better than that. In a 5 minute musical piece, 1% accuracy would
> be
> > 3 seconds. 0.1% would be 300 mS. I don't know the exact accuracy
> > of the PSIM since I don't know the resonator used but it is
> probably
> > well less than the 1%.
> >
> > Is this something that MIDI timing clocks could be used for? If
> > MIDI could be used as a master clock, it would be easy to build a
> > reference timebase. My first MIDI code implemented an interrupt
> > routine for input. I later adopted to the HSERIN command which
> > buffers the data. Going back to my original code, I could use real
> > time nature of the interrupt to implement a real time clock. I
> have
> > no relevant experience with MIDI clock and synchronization. It
> would
> > be simple to add and implement, though. Multiple PSIMs would be
> > synchronized to the same MIDI reference. In fact, an AVR2313 with
> a
> > crystal and two resistors could be used to generate such a
> > reference. Might be a nifty accessory.
> >
> > Dave
> >
> > --- In ComputerVoltageSources@yahoogroups.com, "Gary Chang" > The
> > length of Psim Madness is not long in terms of music duration -
> > > any typical piece of music is much longer than that. Honestly, a
> > high
> > > school music student has a better sense of time than the PSIM.
> > >
> > > INHO, ability to slave the PSIM is essential.
> > >
> > > If these devices can't play 16 bars together with something else,
> > it's
> > > pretty much useless as a sequential pitch source.... except for a
> > > phasing minimalist piece (such as PSIM madness).
> > >
> > >
> > > gary
> >
>

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

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
>

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

I would take a much simpler approach. You don't have to follow the
MIDI standard. Whatever code I wrote would rely upon the timer for
some standard timing increment. I do all of my code with a 1 mS
timer. If you ignore the accuracy and assume the resonator is good
enough (mine is 0.1% accurate), I would simply declare one processor
to be a master, and during the ISR I would send a timing code out via
serial/MIDI. You can pick whatever code you want as long as it is
unused by your application. The other PSIMs do not use a timer
routine, but rather implement received serial via interrupts. That
particular code replaces the timer interrupt and is filtered from the
MIDI stream (if you're even using MIDI). There is some latency. At
MIDI rates, it would be 320 uS. Figure out what the latency is and
add it to the master with a software delay. I figure you can keep all
of these sync'd with some relative timing offset but good overall
accuracy. You don't have to do the 24 ppq but can run on a much
higher rate. The idea is to keep the processors from drifting apart
over long time intervals. The solution is to only use one timing
reference.

The other option would be to use an external clock via Aux. You can
set up Aux for edge interrupts. The master timer ISR pulses Aux. The
slaves setup Aux for edge interrupts Latency is much lower but
consume one I/O pin.

Dave


--- In ComputerVoltageSources@yahoogroups.com, Eric Brombaugh
<ebrombaugh@...> wrote:

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

I coded up two approaches to module synchronization.

Alt 1: I setup the PSIM as the master clock using 1 mS timer
interrupts. I sent a $fe midi active sense every mS to the other
module. I generated the real-time clock in the other module on
receipt of the midi active sense instead of the timer. Latency
between the two was ~400 uS which is what I would expect given
transmission time and interrupt latency.

Alt 2: I setup both modules using 1 mS timer interrupts. I sent a
$fe midi active sense every 256 mS to synchronize the two clocks. I
output a periodic 1 mS clock and there is some minor jitter but the
modules stay synchronized. I put a .wmv video in the
Files>BasicAtomPro>Original PSIM>Dave Brown folder showing the
results.

In both cases I would need to add some code for specific
synchronization due to reset and start-up time differences between
modules. In alternative 1 I would just pause long enough to make
sure the interrupts were enabled. In alternative 2 I would probably
add code for a midi reset to reset the real-time clock value.

Dave


--- In ComputerVoltageSources@yahoogroups.com, "djbrow54" <davebr@...>
wrote:

>
> I would take a much simpler approach. You don't have to follow the
> MIDI standard. Whatever code I wrote would rely upon the timer for
> some standard timing increment. I do all of my code with a 1 mS
> timer. If you ignore the accuracy and assume the resonator is good
> enough (mine is 0.1% accurate), I would simply declare one processor
> to be a master, and during the ISR I would send a timing code out

via

> serial/MIDI. You can pick whatever code you want as long as it is
> unused by your application. The other PSIMs do not use a timer
> routine, but rather implement received serial via interrupts. That
> particular code replaces the timer interrupt and is filtered from

the

> MIDI stream (if you're even using MIDI). There is some latency. At
> MIDI rates, it would be 320 uS. Figure out what the latency is and
> add it to the master with a software delay. I figure you can keep

all

> of these sync'd with some relative timing offset but good overall
> accuracy. You don't have to do the 24 ppq but can run on a much
> higher rate. The idea is to keep the processors from drifting apart
> over long time intervals. The solution is to only use one timing
> reference.
>
> The other option would be to use an external clock via Aux. You can
> set up Aux for edge interrupts. The master timer ISR pulses Aux.

The

> slaves setup Aux for edge interrupts Latency is much lower but
> consume one I/O pin.
>
> Dave

Hi Eric

Thanks for the info & analysis...very enlightening

--- In ComputerVoltageSources@yahoogroups.com, Eric Brombaugh
<ebrombaugh@...> wrote:

> I agree that implementing a digital tracking PLL in
> the AtomPro code would be significant hassle.
>

if the code is written with with sync implemented from the ground up
it's less onerous- not easy , mind youbut less of a pain in the @$$.
But modding synch into existing code (especially if linear or curved
gestures are produced) is... well... let's just say , it's not well
suited for a volunteer effort or even a 'reasonably priced' effort...
;'>
also...
designing-in the sync scheme demands that the sync conventions be
carved reliably in GRANITE before one begins to frame out the code...
i once stepped into an industrial control design project wherein the
user wanted to be able to drive the system with un-specified ,
'future' , timing references. Suffice to say it never even got as far
as a prototype.

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

whoa! that's a barrier, at those speeds all kinds of physical factors
bear hard on the design.

> Probably a bit more hackery than most folks want to
> deal with.
>

certaily out of my league.... This is really located in BasicMicro's
realm but i doubt our little niche would merit the expense and effort
for them.


Thanks again for your insight
i learned something.

-doc

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

While running an errand, it dawned on me that rather than just
synchronize the clocks, I could determine the error and adjust the
timer to dial in the slave's frequency. I normally use a gra of 2000
which divides the ~2 MHz timer input for a 1 mS interrupt. If the
slave clock is slower, then I decrease gra to increase the clock, and
the reverse if the slave clock is faster. I display the current gra
value on my LCD and it varies between 2001 and 2002 so it doesn't make
much difference. When I disconnect the synchronization, the two do
drift apart slower.

My real-time clock just increments a long variable so it will wrap
around to 0 every 49 days. It depends on how the code is written, but
it is pretty simple to calculate delays. For example, to set the Aux
output high in 20 mS, I simply compute a future time value such as
turn_off=time_count+19.

Then, either in the interrupt routine, or in main code, I set Aux low
when time_count>turn_off. The timing may be off by less than a mS
from my time_count due to latency, but errors never accumulate.

Dave


--- In ComputerVoltageSources@yahoogroups.com, "djbrow54" <davebr@...>

> Alt 2: I setup both modules using 1 mS timer interrupts. I sent a
> $fe midi active sense every 256 mS to synchronize the two clocks. I
> output a periodic 1 mS clock and there is some minor jitter but the
> modules stay synchronized. I put a .wmv video in the
> Files>BasicAtomPro>Original PSIM>Dave Brown folder showing the
> results.

Dave,

You have mentioned measured degrees of error, asking what is
acceptable. The film, video and music systems that I use (as others
in the industry use) are based on 'no degree of error is acceptable'.
For instance, in a video shoot that involves several video cameras,
audio, and video and audio mixers, one does not rely on the accuracy
of each individual device - they use a master sync source to
synchronize each an every device. This sync is NOT timecode - it is a
pilot tone that each and every video device recognizes and devices
such as a microlynx, (which I have in my system) will phase lock my
digital audio system to the video sync reference. (This is what David
K. is talking about in his message a few messages ago).

In the case of the PSIM, to simply be able to record a tone on my DAW
and then play it back, each time triggering the PSIM to play at the
EXACT same tempo so that I can do multiple passes of the same pattern
with different sounds would be the benchmark of acceptability -
anything short of this would be worthless. What would be even better
would be to be able to reference a sync source that other devices
refer to, so that one could get the PSIM to synchronize tempo with
another sequencer!

gary

"djbrow54" <davebr@...> wrote:

>
> While running an errand, it dawned on me that rather than just
> synchronize the clocks, I could determine the error and adjust the
> timer to dial in the slave's frequency. I normally use a gra of 2000
> which divides the ~2 MHz timer input for a 1 mS interrupt. If the
> slave clock is slower, then I decrease gra to increase the clock, and
> the reverse if the slave clock is faster. I display the current gra
> value on my LCD and it varies between 2001 and 2002 so it doesn't make
> much difference. When I disconnect the synchronization, the two do
> drift apart slower.
>
> My real-time clock just increments a long variable so it will wrap
> around to 0 every 49 days. It depends on how the code is written, but
> it is pretty simple to calculate delays. For example, to set the Aux
> output high in 20 mS, I simply compute a future time value such as
> turn_off=time_count+19.
>
> Then, either in the interrupt routine, or in main code, I set Aux low
> when time_count>turn_off. The timing may be off by less than a mS
> from my time_count due to latency, but errors never accumulate.
>
> Dave
>
>
> --- In ComputerVoltageSources@yahoogroups.com, "djbrow54" <davebr@>
> > Alt 2: I setup both modules using 1 mS timer interrupts. I sent a
> > $fe midi active sense every 256 mS to synchronize the two clocks. I
> > output a periodic 1 mS clock and there is some minor jitter but the
> > modules stay synchronized. I put a .wmv video in the
> > Files>BasicAtomPro>Original PSIM>Dave Brown folder showing the
> > results.
>

I sort of follow this. Don't these devices phase-lock to the
frequency of the pilot tone? The AtomPro doesn't have the processing
capability nor the phase-lock capabilities to do any of this. Even if
you replace the resonator with an xtal, you still have to synchronize
them due to power-on and instruction execution differences. As such,
I think each PSIM needs to be externally synchronized to some type of
external unit.

What kind of time resolution is required for events? 1 mS, 10 mS?

There isn't much time available in a 1 mS interrupt routine but there
might be in a 10 mS interval. That would allow the main code to
execute and calculate output values, and then an interrupt routine
could actually do the output. Just setting the four DACs requires
~760 uS. However, if the interrupt latency was the same for each PSIM
depending upon the code, they would more or less stay in sync but just
be delayed from the external clock. That might work.

It seems to me that this external unit could translate the pilot
tone into an appropriate external clock and sync for the PSIMs. P6
and P7 could be used for external clocks. Both can be setup for
external edge interrupts so one could be used for a master
synchronized reset and one could be used for a clock. Or, if latency
could be tolerated, for serial communication where the data provides
the intelligence as to clock or reset. Multiple PSIMs could each
monitor the same master signals.

Does such a unit exist? I would think there could be pilot tone
clocking units. I have no first hand knowledge of any of this.

Dave


--- In ComputerVoltageSources@yahoogroups.com, "Gary Chang" <gchang@.
..> wrote:

> they use a master sync source to synchronize each an every device.

> In the case of the PSIM, to simply be able to record a tone on my
> DAW and then play it back, each time triggering the PSIM to play
> at the EXACT same tempo

On 1/23/07, djbrow54 <davebr@...> wrote:

>
>
> I sort of follow this. Don't these devices phase-lock to the
> frequency of the pilot tone? The AtomPro doesn't have the processing
> capability nor the phase-lock capabilities to do any of this. Even if
> you replace the resonator with an xtal, you still have to synchronize
> them due to power-on and instruction execution differences. As such,
> I think each PSIM needs to be externally synchronized to some type of
> external unit.
>

HArry :>) !!

I´d like to see the modification (a simple one, as it is) for xtal
timebase for one-too many Atompros.

This should resolve this timing problem and for those who like
Midi-clock, Dave has the answer.

Samppa (Who only drifts once in a while)

You just replace the resonator with a crystal and two 12 pF
capacitors. I've already replaced the power-on reset chip on my
AtomPro28 and I'm not ready yet to experiment on mine with more
unsoldering and modifications. I suppose someone makes a nice pin-
compatible crystal and capacitor module. Section 5.1 of the hardware
H8 manual details the System Clock.

Dave


--- In ComputerVoltageSources@yahoogroups.com, "Samppa Tolvanen"
<samppa.tolvanen@...> wrote:

> I´d like to see the modification (a simple one, as it is) for xtal
> timebase for one-too many Atompros.
>
> This should resolve this timing problem and for those who like
> Midi-clock, Dave has the answer.
>
> Samppa (Who only drifts once in a while)
>

Actually, now that I look at my AtomPro28 photo in the photos section,
I see they put a 1M resistor across the clock inputs. You probably
want to remove that also. - Dave


--- In ComputerVoltageSources@yahoogroups.com, "djbrow54" <davebr@...>
wrote:

>
> You just replace the resonator with a crystal and two 12 pF
> capacitors. I've already replaced the power-on reset chip on my
> AtomPro28 and I'm not ready yet to experiment on mine with more
> unsoldering and modifications. I suppose someone makes a nice pin-
> compatible crystal and capacitor module. Section 5.1 of the

hardware

> H8 manual details the System Clock.
>
> Dave
>
>
> --- In ComputerVoltageSources@yahoogroups.com, "Samppa Tolvanen"
> <samppa.tolvanen@> wrote:
>
> > I´d like to see the modification (a simple one, as it is) for xtal
> > timebase for one-too many Atompros.
> >
> > This should resolve this timing problem and for those who like
> > Midi-clock, Dave has the answer.
> >
> > Samppa (Who only drifts once in a while)
> >
>

On 1/23/07, djbrow54 <davebr@...> wrote:

>

> Actually, now that I look at my AtomPro28 photo in the photos section,
> I see they put a 1M resistor across the clock inputs. You probably
> want to remove that also. - Dave
>

I hear, I hear. That´s for single AtomPro28 (24). But what I wanted
was to run 4 or something from the same clock. The chip supports it,
right?

One xtal leg grounded and the other driven by a logick
pulse?

Samppa

Yes, it looks like you can drive it that way. Taking the resonator
off will not be for the faint of heart. Mine appears to be 3mm x 4mm
with full landing pads from edge to edge under the device. There is
no way to remove it with a conventional soldering iron. The center
pad is ground so you'd have to connect this to one of the inputs and
drive the other. At least you have good sized pads for connecting a
wire ...

Dave

--- In ComputerVoltageSources@yahoogroups.com, "Samppa Tolvanen"
<samppa.tolvanen@...> wrote:

>
> On 1/23/07, djbrow54 <davebr@...> wrote:
> >
>
> > Actually, now that I look at my AtomPro28 photo in the photos

section,

> > I see they put a 1M resistor across the clock inputs. You

probably

> > want to remove that also. - Dave
> >
> I hear, I hear. That´s for single AtomPro28 (24). But what I wanted
> was to run 4 or something from the same clock. The chip supports it,
> right?
>
> One xtal leg grounded and the other driven by a logick
> pulse?
>
> Samppa
>

"djbrow54" <davebr@...> wrote:

>
> I sort of follow this. Don't these devices phase-lock to the
> frequency of the pilot tone? The AtomPro doesn't have the processing
> capability nor the phase-lock capabilities to do any of this. Even if
> you replace the resonator with an xtal, you still have to synchronize
> them due to power-on and instruction execution differences.

I do understand the limitations of the PSIM's processing capabilities
regarding this syncing situation - I am just trying to sketch for you
the extent that the musical and audio/video industries have gone in
the regard of 'syncronizaton.' It is a rather complex issue to try to
sync up a video tape recorder, running off of a 59.97 khz NTSC pilot
tone, to a digital audio workstation, running at 48 khz, so there
exists "Master Sync Generators" that output a variety of Xtal-locked
sync tones for various formats and media. (Aren't you glad that the
PSIM is not spec'd for audio?!)

As such,

> I think each PSIM needs to be externally synchronized to some type of
> external unit.
>
> What kind of time resolution is required for events? 1 mS, 10 mS?

This is where a decision has to be made - is sync source tempo
related, or is it a very high frequency tone that all time references
are subdivided? MIDI clock is a tempo related time reference -
although it is relatively low resolution, the tempo contiuosly varies,
so at least you have that amount of resolution at all tempos.

>
> There isn't much time available in a 1 mS interrupt routine but there
> might be in a 10 mS interval. That would allow the main code to
> execute and calculate output values, and then an interrupt routine
> could actually do the output. Just setting the four DACs requires
> ~760 uS.

At 120BPMs, a sixteenth note is 125 ms - so 1ms would be acceptable in
a world of interrupts that can keep the errors from accumulating into
larger numbers. 10ms is too large an interval - it would be very
noticeable - like the difference between jazz musicians and classical
players playing a shuffle.


However, if the interrupt latency was the same for each PSIM

> depending upon the code, they would more or less stay in sync but just
> be delayed from the external clock. That might work.

Latency, although annoying can be worked around - I return to my
DAW-synced model - let's try to record a pilot tone into a DAW, and
then play it back to drive the PSIM. If this syncronization scheme is
working, then the PSIM would play back with identical latency on each
pass, and the performances would be identical.

>
> It seems to me that this external unit could translate the pilot
> tone into an appropriate external clock and sync for the PSIMs. P6
> and P7 could be used for external clocks. Both can be setup for
> external edge interrupts so one could be used for a master
> synchronized reset and one could be used for a clock. Or, if latency
> could be tolerated, for serial communication where the data provides
> the intelligence as to clock or reset. Multiple PSIMs could each
> monitor the same master signals.

What you are describing is exactly the setup in Video/Digital Audio -
a pilot tone Master Sync Clock, with Timecode, which each and every
dyncronized device periodically looks at to see if there is any error
to correct, from time to time...

>
> Does such a unit exist? I would think there could be pilot tone
> clocking units. I have no first hand knowledge of any of this.

http://www.soundonsound.com/sos/1997_articles/oct97/aardsync.html

http://www.soundonsound.com/sos/1997_articles/jan97/motumtpav.html

Here are a few links to a few devices that meet your description.

Hi Dave
thanks for the exploration
i took a look at processor pins 9&10 on my PSIM PCB and ... boy! you
ain't a-kiddin' about the 'not for the faint-of-heart'!
Like most human-sized, 70's wire-twisters, (with half-century old
eyesight and a propensity to sneeze SOIC components off the workbench)
...i'm not terribly comfortable tearing into surface-mount under good
conditions but this layout is tight as a... well...
(this is an all ages site so... let's just say it's TIGHT)
hmmmmmm, so far i looks to me like shopping list for external
processor clocking will include, at a minimum, expert SOIC component
removal skills/tools, flying wires off the BasicAtom and cancelling
the modularity that allows a BasicAtom swap....
and that list excludes the design of a module that caters to the
H8/3664's clock requirements and ostensibly some arbitrary form of
compatibility with an external standard....

That shopping list will require a very motivated buyer
and...
it looks like it would score just about the same pain in the ass
index as a workaround-software scheme , ie: trying to , as Senor
Brombaugh put it, implement some sort of software PLL.

yuck...
even the 'elegant' solutions are inelegant
(and brute force will be expensive)

another point for Murphy's law!
-doc



--- In ComputerVoltageSources@yahoogroups.com, "djbrow54" <davebr@...>
wrote:

>
> Yes, it looks like you can drive it that way. Taking the resonator
> off will not be for the faint of heart. Mine appears to be 3mm x 4mm
> with full landing pads from edge to edge under the device. There is
> no way to remove it with a conventional soldering iron. The center
> pad is ground so you'd have to connect this to one of the inputs and
> drive the other. At least you have good sized pads for connecting a
> wire ...
>
> Dave
>
> --- In ComputerVoltageSources@yahoogroups.com, "Samppa Tolvanen"
> <samppa.tolvanen@> wrote:
> >
> > On 1/23/07, djbrow54 <davebr@> wrote:
> > >
> >
> > > Actually, now that I look at my AtomPro28 photo in the photos
> section,
> > > I see they put a 1M resistor across the clock inputs. You
> probably
> > > want to remove that also. - Dave
> > >
> > I hear, I hear. That´s for single AtomPro28 (24). But what I wanted
> > was to run 4 or something from the same clock. The chip supports it,
> > right?
> >
> > One xtal leg grounded and the other driven by a logick
> > pulse?
> >
> > Samppa
> >
>

Incidentally, Dave, (and all of this list), I submit my comments
regarding this project WITH ALL DUE RESPECT. I defer to your
technical expertise.

I have felt that this has been a healthy collaboration regarding the
PSIM - the solving of issues in some of the early software has taken
both technical and musical sensitivities. I am glad to participate,
and am proud to know you and have nothing but repect for your domain
of knowledge. 8*>

gary

The resonator is reasonably sized compared to the other components and
the landing pads are long enough that I think you could even solder
discrete parts to it. I'm a bit perplexed as to how to get the
resonator off there without specialized SMT desoldering equipment.
One thought I had was to grind it off with a dremel tool and then
unsolder each pad and hopefully not destroy the module. Or perhaps
with enough heat on top of the resonator the three lower pads would
desolder. However, I'm not prepared to try. I may ask one of the
techs at work how it is done. After that it looks easy enough but you
are correct - there are some really fine pitched parts on that module.

Another thought (and I'm looking at my AtomPro28, not the 24) is that
one clock run is reasonably long along the side. The other goes to a
feedthrough right above the resonator. I suppose if you are lucky,
the feedthrough "could" be the pin that you would leave open and the
long run "could" be one that you could cut and feed the clock into.
It would be a matter of tracing the runs out.

Dave

--- In ComputerVoltageSources@yahoogroups.com, "drmabuce" <drmabuce@.
..> wrote:

>
> Hi Dave
> thanks for the exploration
> i took a look at processor pins 9&10 on my PSIM PCB and ... boy! you
> ain't a-kiddin' about the 'not for the faint-of-heart'!
> Like most human-sized, 70's wire-twisters, (with half-century old
> eyesight and a propensity to sneeze SOIC components off the

workbench)

> ...i'm not terribly comfortable tearing into surface-mount under

good

> conditions but this layout is tight as a... well...
> (this is an all ages site so... let's just say it's TIGHT)
> hmmmmmm, so far i looks to me like shopping list for external
> processor clocking will include, at a minimum, expert SOIC component
> removal skills/tools, flying wires off the BasicAtom and cancelling
> the modularity that allows a BasicAtom swap....
> and that list excludes the design of a module that caters to the
> H8/3664's clock requirements and ostensibly some arbitrary form of
> compatibility with an external standard....
>
> That shopping list will require a very motivated buyer
> and...
> it looks like it would score just about the same pain in the ass
> index as a workaround-software scheme , ie: trying to , as Senor
> Brombaugh put it, implement some sort of software PLL.
>
> yuck...
> even the 'elegant' solutions are inelegant
> (and brute force will be expensive)
>
> another point for Murphy's law!
> -doc

Thanks for the compliment. I'm more of an engineer (actually I'm a
manager) and less of a musician. I never record but mostly play and I
don't have a great sense of timing so my questions about accuracy are
truly from ignorance.

What I have been pondering is whether the inherent accuracy of the
AtomPro needs to be improved, or if it could be accomplished through
synchronization. The issue is there isn't much processing time
available if 1mS resolution is required.

I have to read your references from the other posting but I'm starting
to think we need to improve the accuracy with a crystal oscillator and
then use synchronization at a much longer time interval or perhaps
just at initialization to sync them together. The available pins do
provide edge-sensitive interrupts so a single external event should
be able to easily synchronize the. I do have a spare AtomPro28 and may
try to see if I can get an oscillator or crystal to fit. That's some
serial rework, though.

Dave

--- In ComputerVoltageSources@yahoogroups.com, "Gary Chang" <gchang@.
..> wrote:

>
> Incidentally, Dave, (and all of this list), I submit my comments
> regarding this project WITH ALL DUE RESPECT. I defer to your
> technical expertise.
>
> I have felt that this has been a healthy collaboration regarding the
> PSIM - the solving of issues in some of the early software has taken
> both technical and musical sensitivities. I am glad to participate,
> and am proud to know you and have nothing but repect for your domain
> of knowledge. 8*>
>
> gary
>

"djbrow54" <davebr@...> wrote:

>
> What I have been pondering is whether the inherent accuracy of the
> AtomPro needs to be improved, or if it could be accomplished through
> synchronization. The issue is there isn't much processing time
> available if 1mS resolution is required.

In a pinch, relying on synchronization for dead-on accuracy can work -
and it would solve the issue of retrofitting the clock in the Atompro
- which seems to defeat the purpose of having a plug-and-play
processor that is easy to acquire and implement. Swapping out soic
hardware is really an expert's domain - and a young expert at that!


gary

HI DAve

--- In ComputerVoltageSources@yahoogroups.com, "djbrow54" <davebr@...>
wrote:

> I'm a bit perplexed as to how to get the
> resonator off there without specialized SMT desoldering equipment.

i'll bet that that's a class of implement that would inspire tool-envy
in even the most jaded DIYer heart.!!!

> One thought I had was to grind it off with a dremel tool and then
> unsolder each pad and hopefully not destroy the module.

LOL!
Dremel... the universal solvent!
Boy am i relieved to learn that you considered this!
This notion crossed my mind and i dared not speak it out loud for fear
that my already tawdry reputation as a club-footed DIY barbarian would
become even more intractable!!!
i'm still too nervous to do it though, if that Dremel bit seizes
something tough and hurls itself off-target there's just too much in
the way of delicate innards in the neighborhood for it to land on.

> Or perhaps
> with enough heat on top of the resonator the three lower pads would
> desolder. However, I'm not prepared to try.

ahh .... basically, burn it off! i'd worry about heat stress on the
neighboring components though....

the loss of modularity is the biggest issue to me ... i might have the
brass to do this operation once but the prospect of doing it over and
over in the future really turns me off.

With all due empathy for Maestro Chang's situation, it's academic to
me anyway. i don't expect i'll ever have more than one PSIM in my rig.
And my prospects for soundtrack work sync'd to video are still very bleak.

-doc

I've found that applying liquid flux and then adding solder to smt parts
will usually get them off pretty quickly. Get the part hot, keep the
iron moving between the pads and keep adding solder. Then cleanup the
mess with solder wick and finally isopropyl alcohol. I've yet to damage
a board doing this. With some of the special tools, it is actually
easier to damage the board when used incorrectly. A hot-air desoldering
tool can scorch a pcb very quickly.

There is also this, a special low temp alloy used to make removing
soldered parts easier:

http://www.chipquik.com/

I haven't tried it, but it looks very interesting. Unfortunately it is
a little bit pricey.

-Dave

>
> --- In ComputerVoltageSources@yahoogroups.com, "djbrow54" <davebr@...>
> wrote:
>> I'm a bit perplexed as to how to get the
>> resonator off there without specialized SMT desoldering equipment.

I pulled my AtomPro28 tonight and replaced it with my spare. I blew
the reset supervisor on this one so thought I would experiment with
it. I'll take it to work tomorrow and let one of the techs remove the
part with the proper equipment. I have a thru-hole xtal that I'll try
soldering on and seeing if I can program the part. I'll update the
group as soon as I have some results.

Dave


--- In ComputerVoltageSources@yahoogroups.com, Dave Manley <dlmanley@
...> wrote:

>
> I've found that applying liquid flux and then adding solder to smt

parts

> will usually get them off pretty quickly. Get the part hot, keep

the

> iron moving between the pads and keep adding solder. Then cleanup

the

> mess with solder wick and finally isopropyl alcohol. I've yet to

damage

> a board doing this. With some of the special tools, it is actually
> easier to damage the board when used incorrectly. A hot-air

desoldering

> tool can scorch a pcb very quickly.
>
> There is also this, a special low temp alloy used to make removing
> soldered parts easier:
>
> http://www.chipquik.com/
>
> I haven't tried it, but it looks very interesting. Unfortunately it

is

> a little bit pricey.
>
> -Dave
>
> >
> > --- In ComputerVoltageSources@yahoogroups.com, "djbrow54"

<davebr@>

> > wrote:
> >> I'm a bit perplexed as to how to get the
> >> resonator off there without specialized SMT desoldering

equipment.

>

Dave,

Tally ho on your mission! I hope that it is successful....

gary



"djbrow54" <davebr@...> wrote:

>
> I pulled my AtomPro28 tonight and replaced it with my spare. I blew
> the reset supervisor on this one so thought I would experiment with
> it. I'll take it to work tomorrow and let one of the techs remove the
> part with the proper equipment. I have a thru-hole xtal that I'll try
> soldering on and seeing if I can program the part. I'll update the
> group as soon as I have some results.
>
> Dave
>
>
> --- In ComputerVoltageSources@yahoogroups.com, Dave Manley <dlmanley@
> ...> wrote:
> >
> > I've found that applying liquid flux and then adding solder to smt
> parts
> > will usually get them off pretty quickly. Get the part hot, keep
> the
> > iron moving between the pads and keep adding solder. Then cleanup
> the
> > mess with solder wick and finally isopropyl alcohol. I've yet to
> damage
> > a board doing this. With some of the special tools, it is actually
> > easier to damage the board when used incorrectly. A hot-air
> desoldering
> > tool can scorch a pcb very quickly.
> >
> > There is also this, a special low temp alloy used to make removing
> > soldered parts easier:
> >
> > http://www.chipquik.com/
> >
> > I haven't tried it, but it looks very interesting. Unfortunately it
> is
> > a little bit pricey.
> >
> > -Dave
> >
> > >
> > > --- In ComputerVoltageSources@yahoogroups.com, "djbrow54"
> <davebr@>
> > > wrote:
> > >> I'm a bit perplexed as to how to get the
> > >> resonator off there without specialized SMT desoldering
> equipment.
> >
>

Success! I had a tech at work take off the resonator. I added the
capacitors (0302, I think) and a through-hole crystal. Man were those
capacitors small! Rock solid performance! Photo "AtomPro28 crystal.
jpg" is in the Files>BasicAtomPro>Original PSIM>Dave Brown folder.

Dave

--- In ComputerVoltageSources@yahoogroups.com, "Gary Chang" <gchang@.
..> wrote:

>
> Dave,
>
> Tally ho on your mission! I hope that it is successful....
>
> gary
>
>
>
> "djbrow54" <davebr@> wrote:
> >
> > I pulled my AtomPro28 tonight and replaced it with my spare. I

blew

> > the reset supervisor on this one so thought I would experiment

with

> > it. I'll take it to work tomorrow and let one of the techs remove

the

> > part with the proper equipment. I have a thru-hole xtal that I'll

try

> > soldering on and seeing if I can program the part. I'll update

the

> > group as soon as I have some results.
> >
> > Dave

Success! I know I posted last night. Perhaps someone got a private
posting instead of to the group.

I soldered some 0302 capacitors across the pads and a through hole
crystal. Rock solid performance at 16 MHz. I think it would be
easier to solder radial caps across the crystal and then solder the
crystal to the pads.

I put a photo AtomPro28 crystal.jpg in the Files>BasicAtomPro>Original
PSIM>Dave Brown folder.

I also got a 32,768 Hz crystal for the sub-oscillator but do not see
any way to solder it with the fine pitch.

Dave

--- In ComputerVoltageSources@yahoogroups.com, "djbrow54" <davebr@...>
wrote:

>
> I pulled my AtomPro28 tonight and replaced it with my spare. I blew
> the reset supervisor on this one so thought I would experiment with
> it. I'll take it to work tomorrow and let one of the techs remove

the

> part with the proper equipment. I have a thru-hole xtal that I'll

try

> soldering on and seeing if I can program the part. I'll update the
> group as soon as I have some results.
>
> Dave

Nice soldering job - very tidy.

I suppose that the real test of this modification
would be how well two such systems track each other in
real-time.

Ceramic Resonators such as was originally mounted have
+/- 0.5% accuracy. Crystal accuracy is typically
+/-50ppm (100x better than the resonator), that means
a worst-case error between 2 crystal oscillators of
100ppm. If you were using these to run a clock that
equates to .36 seconds disagreement over an hour.

To hit the 1ms accuracy that Gary quoted earlier you'd
need to resynchronize such a system at least every 10
seconds minimum. So, while using a crystal doesn't
eliminate the synchronization problem, it
significantly reduces the effort required to do so and
still maintain reasonable accuracy.

Eric

--- djbrow54 <davebr@...> wrote:

> Success! I had a tech at work take off the
> resonator. I added the
> capacitors (0302, I think) and a through-hole
> crystal. Man were those
> capacitors small! Rock solid performance! Photo
> "AtomPro28 crystal.
> jpg" is in the Files>BasicAtomPro>Original PSIM>Dave
> Brown folder.

____________________________________________________________________________________
Need Mail bonding?
Go to the Yahoo! Mail Q&A for great tips from Yahoo! Answers users.
http://answers.yahoo.com/dir/?link=list&sid=396546091

Thanks for the math. I was going to try and figure that out.

The capacitors were a pain. I have to take this crystal off when my
replacement supervisor chip comes. I soldered up another crystal and
just wired the two capacitors across it. I think that will be easier
to solder to the three traces on the PCB.

I would still use the timer interrupt to set a real time value that is
used for program timing. I would hesitate to set the interrupts any
faster than 1 mS to have a reasonable balance between program and
interrupt processing. The Aux input can be set to edge-triggered
interrupts. I believe so can P6 and P7 on J3 with the same mechanism
although I never have tried it. It seems like you could wire the
slave PSIMs for edge interrupts to all monitor one of these signals as
a master clock and use this interrupt as the increment for the real
time value.

There are a couple of alternatives for clocking.
1. Have a master PSIM that simply clocks this line as part of the
timer interrupt routine. Accuracy is limited by the resonator.
2. Do the crystal mod on the master PSIM and clock to improve the
accuracy.
3. Have all the PSIMs be slaves and clock from some other more
accurate timing reference.

I'm still thinking about the tone burst ideas ...

Dave


--- In ComputerVoltageSources@yahoogroups.com, Eric Brombaugh
<ebrombaugh@...> wrote:

>
>
> Nice soldering job - very tidy.
>
> I suppose that the real test of this modification
> would be how well two such systems track each other in
> real-time.
>
> Ceramic Resonators such as was originally mounted have
> +/- 0.5% accuracy. Crystal accuracy is typically
> +/-50ppm (100x better than the resonator), that means
> a worst-case error between 2 crystal oscillators of
> 100ppm. If you were using these to run a clock that
> equates to .36 seconds disagreement over an hour.
>
> To hit the 1ms accuracy that Gary quoted earlier you'd
> need to resynchronize such a system at least every 10
> seconds minimum. So, while using a crystal doesn't
> eliminate the synchronization problem, it
> significantly reduces the effort required to do so and
> still maintain reasonable accuracy.
>
> Eric
>
> --- djbrow54 <davebr@...> wrote:
>
> > Success! I had a tech at work take off the
> > resonator. I added the
> > capacitors (0302, I think) and a through-hole
> > crystal. Man were those
> > capacitors small! Rock solid performance! Photo
> > "AtomPro28 crystal.
> > jpg" is in the Files>BasicAtomPro>Original PSIM>Dave
> > Brown folder.

I played a bit today with my two modules to sync together the maf-lfo.
bas program. I can't use P6 or P7 to sync since I dedicated those to
i2c so I used aux instead. I commented out the aux lines in the
program and created a master and slave version. It would be simple
enough to modify the program to use P6 or P7 to synchronize the
modules.

The slave version looks for both edges of aux for the pause function.

The master version sets aux high for the duration of the pause.

It seemed to work pretty good although I didn't put the time into it
to consider if it would function correctly in extreme tolerance
cases. It cerainly works good enough to validate the master / slave
arrangement. I frequency modulate the master PSIM and they are
locked together now after about 30 minutes.

Photo and programs in the
Files > BasicAtomPro > Original PSIM > Dave Brown
folder.

Scope capture is synced mal-lfo2.jpg
yellow is aux sync
magenta and cyan are out1 of my two modules

Master program which drives aux is maf-lfo2-master.bas
Slave program which listens to aux is maf-lfo2-slave.bas

Dave


--- In ComputerVoltageSources@yahoogroups.com, "Gary Chang" <gchang@.
..> wrote:

>
> Being one of very few that has more than one of the PSIM-1 module, I
> did a little test to evaluate the relative timing accuracy of the
> PSIM'S internal clock, by loading the maf-lfo2.bas application into
> each of three modules and starting them with a common start pulse.
>
> The test results can be heard in an mp3 called PSIM mayhem, found in
> the files folder of this group.
>
> So - it looks as if we are going to need an external sync reference

to

> get these guys to be time reliable. Probably a simple pilot tone
> (such as a vco) would be the easiest to reference....
>
> GC
>

Dave,

Thanks for providing the master/slave apps to try - I will get to them
this week!

gary


"djbrow54" <davebr@...> wrote:

>
> I played a bit today with my two modules to sync together the maf-lfo.
> bas program. I can't use P6 or P7 to sync since I dedicated those to
> i2c so I used aux instead. I commented out the aux lines in the
> program and created a master and slave version. It would be simple
> enough to modify the program to use P6 or P7 to synchronize the
> modules.
>
> The slave version looks for both edges of aux for the pause function.
>
> The master version sets aux high for the duration of the pause.
>
> It seemed to work pretty good although I didn't put the time into it
> to consider if it would function correctly in extreme tolerance
> cases. It cerainly works good enough to validate the master / slave
> arrangement. I frequency modulate the master PSIM and they are
> locked together now after about 30 minutes.
>
> Photo and programs in the
> Files > BasicAtomPro > Original PSIM > Dave Brown
> folder.
>
> Scope capture is synced mal-lfo2.jpg
> yellow is aux sync
> magenta and cyan are out1 of my two modules
>
> Master program which drives aux is maf-lfo2-master.bas
> Slave program which listens to aux is maf-lfo2-slave.bas
>
> Dave
>
>
> --- In ComputerVoltageSources@yahoogroups.com, "Gary Chang" <gchang@
> ..> wrote:
> >
> > Being one of very few that has more than one of the PSIM-1 module, I
> > did a little test to evaluate the relative timing accuracy of the
> > PSIM'S internal clock, by loading the maf-lfo2.bas application into
> > each of three modules and starting them with a common start pulse.
> >
> > The test results can be heard in an mp3 called PSIM mayhem, found in
> > the files folder of this group.
> >
> > So - it looks as if we are going to need an external sync reference
> to
> > get these guys to be time reliable. Probably a simple pilot tone
> > (such as a vco) would be the easiest to reference....
> >
> > GC
> >
>