Software PLL
in [DSP]
|
From: Vladimir Vassilevsky on 16 Apr 2010 09:54 smc123 wrote: > I'm looking for guidance on writing a software PLL for a signal acquired > from a data acquisition board: > The daq board will be sampling at 10kSPS. > The signals to which I'd like to lock on to are from 5Hz to 1kHz, sine or > square wave. > The output of the PLL will be used to multiply a signal acquired on an > adjacent channel of the daq board. Lock-in amplifier application. > The processing of the signals will be done on a PC-based software app. If you need this to be done for good and quick, my contact is at the web site below. Vladimir Vassilevsky DSP and Mixed Signal Design Consultant http://www.abvolt.com
From: Tim Wescott on 16 Apr 2010 13:14 HardySpicer wrote: > On Apr 16, 2:32 pm, Tim Wescott <t...(a)seemywebsite.now> wrote: >> smc123 wrote: >>> I'm looking for guidance on writing a software PLL for a signal acquired >>> from a data acquisition board: >>> The daq board will be sampling at 10kSPS. >>> The signals to which I'd like to lock on to are from 5Hz to 1kHz, sine or >>> square wave. >>> The output of the PLL will be used to multiply a signal acquired on an >>> adjacent channel of the daq board. Lock-in amplifier application. >>> The processing of the signals will be done on a PC-based software app. >> Do you know anything about phase locked loops? >> >> If no, then say so, and/or hit the books (Floyd Gardner's book is highly >> regarded, I prefer Dan Wolavar's book but only because I took the class >> from him). There may be more modern books that include digital PLL >> theory, but if you understand analog PLLs you can do the digital ones. >> >> Are there interfering signals? >> >> Is there noise? >> >> If no and no, then get your NCO close by detecting zero crossings, then >> lock to the pilot tone by multiplying by the NCO output and averaging. >> I suggest you average the phase detector output by an integer number of >> cycles of the NCO; this will limit your loop bandwidth when the pilot >> tone is at 5Hz, but just about anything will. >> >> Does the pilot tone have a substantially constant amplitude? >> >> If yes, you're done. If no, then cook up some sort of AGC, because >> otherwise loop stability and lock-in time will be an issue. >> >> -- > > > AGC's are typically low bandwidth and do not have any effect on the > envelope. (they do scale the overall waveform of course) > You can up the gain however and crush the envelope ie flatten it. Well, long term they affect the envelope. I was thinking of a slowly-varying signal. In the digital world you can't just amplify and slice, unless you can stand some serious timing jitter. In time domain terms, your zero crossings aren't accurate enough. In frequency domain terms, you create lots of high-frequency harmonics that alias down to your desired frequency. In either view, Bad Things happen. Cycle-by-cycle "AGC" would work -- multiply the pilot tone by both the NCO signal and the NCO in quadrature, then use these two numbers to estimate the phase error. That would handily correct for amplitude variations in the pilot tone, were it necessary. It'd also make your system susceptible to noise in a big way, which is why I was asking about the amount of noise in the pilot tone signal... -- Tim Wescott Control system and signal processing consulting www.wescottdesign.com
From: Tim Wescott on 16 Apr 2010 13:17 HardySpicer wrote: > On Apr 16, 10:31 am, "smc123" <xmacleod(a)n_o_s_p_a_m.yahoo.com> wrote: >> I'm looking for guidance on writing a software PLL for a signal acquired >> from a data acquisition board: >> The daq board will be sampling at 10kSPS. >> The signals to which I'd like to lock on to are from 5Hz to 1kHz, sine or >> square wave. >> The output of the PLL will be used to multiply a signal acquired on an >> adjacent channel of the daq board. Lock-in amplifier application. >> The processing of the signals will be done on a PC-based software app. >> >> Thanks for your help > > Ok first you need a signal with no Amplitude variations. Could use a > hard limiter but this is not good at low SNR's. > Could use a fast acting AGC of some sort. It's also not at all good when your signal frequency comes within an order of magnitude (or two) of your sampling rate -- you lose an incredible amount of timing information when you do the hard limiting in a sampled-time system. > Then you need a VCO in software - easy to do. A multiplier will do > for the phase detector and then the tricky bit. > You need to know a bit about stabilising feedback loops. > Suggest the simplest type of Loop - a type 1! The VCO acts as a pure > integrator Kv/s where Kv is the oscillator constant > (you may need to find this!). Then use a low-pass filter + gain K/ > (1+sT) where T is the time-constant and K is a gain. > > You must plot a Bode-plot and decide what freq unity gain crossover > freq you need. Anyway - do some reading first... > > Hardy -- Tim Wescott Control system and signal processing consulting www.wescottdesign.com
From: smc123 on 16 Apr 2010 15:03 Thanks to all that responded. First, in response to Tim's questions: I understand the operation of PLLs (analog background) but this is my first need for one so I've been doing some reading on software PLLs as you've suggested. So, not an expert by any means. The signal source will not have any significant noise or interfering signals. It will come from either test equipment or a data acq board. The pilot tone will have a constant amplitude but will vary per the application. In any case, its level will be at least a few volts. Still uncertain about how to implement so a few more questions. For the NCO, I'm thinking that I would use a 12 bit phase accumulator, which would allow the generation of frequencies down to 2.44Hz (10k sample rate). And rather than a lookup table, I could just compute the sine for the corresponding value in the phase accumulator register. Also, the way the daq board works is that a buffer of x samples at time is collected, and the data processing of the buffer can be done by the PC application while the next buffer is being acquired. I can implement the multiplier and low pass filter (if that's all I need) so then putting it all together is a matter of piecing together the individual blocks in the sampled time domain? rather than trying coming up with a closed loop form of a transfer equation? Tim, you mentioned "get your NCO close by detecting zero crossings, then lock to the pilot tone by multiplying by the NCO output and averaging." Is the zero crossing detector part of the loop or is it a one-time initialization of the NCO? The amplitude of the pilot signal will be different depending on the application, I'm thinking that since the data is acquired in buffers and then processed, that I could normalize the amplitude before applying it to the PLL. Thanks again for the help and sorry for the novice level questions.
From: Tim Wescott on 16 Apr 2010 15:52 smc123 wrote: > Thanks to all that responded. First, in response to Tim's questions: > > I understand the operation of PLLs (analog background) but this is my first > need for one so I've been doing some reading on software PLLs as you've > suggested. So, not an expert by any means. If you really need a PLL, the biggest part of the knowledge set addresses the "PLL-ness" of the problem. > The signal source will not have any significant noise or interfering > signals. It will come from either test equipment or a data acq board. Lucky you!! > The pilot tone will have a constant amplitude but will vary per the > application. In any case, its level will be at least a few volts. One-time amplitude measurements are easy, and will serve for adjusting gains if necessary, then. > Still uncertain about how to implement so a few more questions. > > For the NCO, I'm thinking that I would use a 12 bit phase accumulator, > which would allow the generation of frequencies down to 2.44Hz (10k sample > rate). And rather than a lookup table, I could just compute the sine for > the corresponding value in the phase accumulator register. How? If you're thinking of using the C library 'sine' function then you may as well use floating point for the phase accumulator -- you'll lose far more clock ticks to the sin(x) calculation than to your phase accumulator. > Also, the way > the daq board works is that a buffer of x samples at time is collected, and > the data processing of the buffer can be done by the PC application while > the next buffer is being acquired. This leads to the thought that you may not want to use a PLL at all -- you may be better off finding phase and frequency as a batch process, particularly if you can do it independently with each buffer of samples. > I can implement the multiplier and low pass filter (if that's all I need) > so then putting it all together is a matter of piecing together the > individual blocks in the sampled time domain? rather than trying coming up > with a closed loop form of a transfer equation? Well, yes, but if you want a PLL you still need a loop, and it still needs to be tuned. You can tune it by cut and try without writing down any transfer functions, but you can't tune it from theory without writing things down -- and digital NCOs are some of the most predictable plants in the world, so you can often do a dynamite job from theory alone. > Tim, you mentioned "get your NCO close by detecting zero crossings, then > lock to the pilot tone by multiplying by the NCO output and averaging." Is > the zero crossing detector part of the loop or is it a one-time > initialization of the NCO? That would depend on the nature of the pilot tone. I generally make that sort of thing an integral part of the loop out of paranoia, designed so that if the loop is in lock the zero-crossing detector doesn't affect anything, but if the loop falls out of lock because of a glitch in the system it automatically cuts in. But on the face of it, the nature of your data collection argues strongly for a batch process as I describe below, so the point may be moot. > The amplitude of the pilot signal will be different depending on the > application, I'm thinking that since the data is acquired in buffers and > then processed, that I could normalize the amplitude before applying it to > the PLL. Indeed. Or, if you're already using trig functions and haven't run out of clock ticks, find the inphase and quadrature components and measure phase directly using atan2. > Thanks again for the help and sorry for the novice level questions. DO NOT apologize or novice level questions. With only a very few notable exceptions we're here to help (and a lot of us don't mind if you decide you can't do it and hire us instead :-). Bring 'em on. Doing everything in batch, you get into an almost not quite really a PLL at all. If you know the approximate frequency you can measure the phase in chunks throughout your file, remove the discontinuities, and do a best fit for offset and slope. Then you can go back through the file and do your analysis. If you have clock cycles to burn you can measure the approximate frequency with an FFT; if you want your code to be thriftier you can do something like counting zero crossings, or differentiating the signal and measuring the amplitude of the result (which, come to think of it, won't work well for your square wave case). I don't normally do shameless plugs, but Vladimir has already broken the ice on this thread*. I've done stuff like this recently and successfully, decoding CDMA from on-air captures. There's a lot of little details involved in getting it really, really right, particularly if your processor is even remotely constrained in performance. So having it done by someone who's been down the road may not be a bad idea, and it's certainly something I can help with. If you don't want to take Vladimir** up on his offer*** get in touch with me. * So it's All His Fault, and I am _completely blameless_. ** or Eric, or any of the other regulars on the list who consult. *** Portland is _much_ more stylish than Kansas City, BTW ;-). -- Tim Wescott Control system and signal processing consulting www.wescottdesign.com
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 Prev: COMP.DSP 2010 pictures and presentations Next: T1CMPR and CMPR1 |