ComputerVoltageSources group photo

Yahoo Groups archive

ComputerVoltageSources

Index last updated: 2026-04-28 22:42 UTC

Message

Re: Atompro timing anomolies....

2007-01-21 by Gary Chang

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

Attachments

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.