Re: phase locked loop SSTC

["Tesla list" <tesla-at-pupman-dot-com>]

Original poster: "Jim Lux by way of Terry Fritz <twftesla-at-qwest-dot-net>" <jimlux-at-earthlink-dot-net>

There are some nice (inexpensive(<$100)) DSP eval boards around which have
audio codecs on them.  I don't know if the sample rate would be high enough
though... If you want to do a PLL at the operating frequency, you'd
probably need to sample at, say, 100 times the fundamental frequency: 100
kHz times 100 is 10MHz sample rate.  Fairly straightforward (this kind of
a/d and d/a are in all manner of video equipment these days), but
non-trivial to make it work.  And, of course, you need to have a pretty
darn fast DSP.

On the other hand, if you didn't need to actually control the waveform, but
could closed loop control some parameter of the waveform generator (say,
the period, phase, amplitude?), then, your control loop only would need an
update rate on the order of the fundamental frequency (say, you wanted to
update 2 times per cycle... I suspect that spark growth occurs on this sort
of time scale).  Now you're talking a loop update rate of 100 kHz (or even
lower), which is well within range of cheap DSPs.  Maybe the DSP drives the
width parameter for a PWM source on a cycle by cycle basis?  Certainly, you
could synthesize almost any arbitrary waveform this way, if only by playing
back a fixed table (and a heck of a lot cheaper than Terry's ARB)

Personally, I favor the Analog Devices parts, but that's just because I
have the most experience with them recently, so I understand their
architecture and "the way they like to work".  TI and Motorola also have
nice DSPs.

Tesla list wrote:
> 
> Original poster: "Paul Nicholson by way of Terry Fritz
<twftesla-at-qwest-dot-net>" <paul-at-abelian.demon.co.uk>
> 
> I wrote:
> > How is the PLL coming along?
> Jan wrote:
> > I tried some things, but it seemed all to be rather troublesome,
> > gave up the "simple" PLL circuit idea and settled for a slightly
> > more luxurious one...
> > ...89C52 microcontroller...has three 16b timers...
> > ...two PLL ICs with identical timing components
> > ...One locks to the uC's 50% duty output signal, the other to
> > the (overdriven) TC base current...
> > ...gives info about whether both freqs are in-tune or lower
> > or higher...VCO input voltages compared...
> 
> Jan,
> 
> Why is it that you're always a step of two ahead of me in your
> thinking?  I wondered how you were getting on with the PLL because
> I've more or less ground to a halt with mine.  I've not built one yet
> because I can't even get it to work properly on paper.  I'm still
> waiting to hear from anyone who's successfully driving a TC from a
> PLL source phase locked to the coil base current.
> 
> I'd just got to wondering whether it might be better to synthesise
> the drive waveform, with a uP in the feedback loop to figure out, in
> real time, the 'best drive',  bit like an engine management system
> does for a car, except 10^3 times quicker. Thus turning the
> difficulties into an embedded coding problem.
> 
> But I see a problem with your approach. Your two PLLs generate
> voltages from the drive and feedback signals, which you
> then compare. But the snag is, the two voltages relate to the
> frequencies of the two locked signals, and these *are already the
> same* since they come from the same source.  It's the relative phase
> of the two that counts.  The controller must choose (search for?) a
> drive freq which gives zero phase angle between coil base current and
> drive voltage.
> 
> It seems to me that if the uP were fast enough, it could synthesise
> the drive square wave, and read the phase of the base current by
> sampling a single digital input.  The uP would look at the relative
> phase, and adjust its output square wave period accordingly.
> 
> Hardware-wise, that's much simpler - no external PLLs, etc, the uP
> does it all.
> 
> Your controller would then be a black box, with a single digital
> input (base current sensor) and a single digital output (drive wave).
> It's then just a matter of sorting out good algorithms to go in the
> middle.  Software PLL, with some overseeing logic to sort things out
> during arcing.
> 
> Maybe in years to come, we'll all be swapping the latest TC
> superchips...(Man! You should try the new Wagner 2002e, that really
> drives! :)
> --
> Paul Nicholson
> --