I suppose it's probably too late to help you (what did you end up doing?), But it can help the next guy.
Here's an example of a programming-related golf game that I just wrote on one line C that will sing along with you:
main(a,b){for(;;)a+=((b+=16+a/1024)&256?1:-1)*getchar()-a/512,putchar(b);}
I present this tiny golf version in the first place to convince you that software phase locks are actually quite simple, just like software, although they can be complex.
If you feed 8-bit linear patterns to stdin, it will produce 8-bit ramp patterns trying to track one octave higher on stdout. At 8,000 samples per second, it tracks frequencies around 250 Hz, just above B below average C. On Linux, you can do this by typing arecord | ./pll | aplay arecord | ./pll | aplay arecord | ./pll | aplay . A low 9 bit b is a generator (which may be a VCO in hardware implementation) that generates a square wave (1 or -1) that gets multiplied by the input waveform ( getchar() ) to create the output of a phase detector. This output is then filtered in the lower pass at a to obtain a smoothed phase error signal, which is used to adjust the vibration frequency b to press a in the direction 0. The natural frequency of the square wave, when a == 0 , for b increase by 16 each sample, which increases it by 512 (full cycle) every 32 samples. 32 samples at a speed of 8000 samples per second are 1/250 seconds, so the natural frequency is 250 Hz.
putchar() takes the lower 8 bits of b , which make up a sawtooth wave at a frequency of 500 Hz or so, and spews them like an audio output stream.
There are several things in this simple example:
It has no good way to detect blocking . If you have silence, noise, or a strong clean 250 Hz input, a will be approximately equal to zero, and b will oscillate with its default frequency. Depending on your application, you may find out if you found a signal or not! Camenzind's suggestion in Chapter 12, Designing Analog Chips, is to feed a second “phase detector” 90 ° in phase from a real phase detector; its smoothed output gives you the amplitude of the signal that you theoretically blocked.
The natural frequency of the oscillator is fixed and does not cover . The PLL capture range, the frequency range within which it will notice oscillations if it is not currently locked, is quite narrow; its blocking range over which it will be located to monitor the signal after it is blocked is much larger. Because of this, as a rule, it picks up the PLL frequency in the entire range where you expect to find a signal until you get a lock, and then stop sweeping.
The golf version is higher than the more readable example of a phase-locked loop in C that I wrote today, which does lock detection but does not sweep. It needs about 100 processor cycles for each sample input on the PLL on the Atom processor in my netbook.
I think that if I were in your situation, I would do the following (besides the obvious things, such as finding someone who knows more about signal processing than I do and generating test data). I probably won’t filter and down convert the signal at the front end, since it is already at such a low frequency. Shift conversion to the 200 Hz-400 Hz band is hardly necessary. I suspect that the PSK will cause some new problems, because if the signal suddenly shifts the phase by 90 ° or more, you lose phase lock; but I suspect that these problems will be easily resolved, and this is unlikely to be unreasonable territory.