Phase-locked loop
  • I've been trying to create a phase-locked loop module and I seem to have run into an insoluble problem. I built a double d-type flip-flop based phase comparator which seems to work fine in testing. I get positive pulses out when the reference frequency is lower that the input or the phase lags and negative pulses when the reference frequency is higher or the phase is leading. However when I attempt to use the output of the phase comparator to control the frequency of the reference oscillator, the phase comparator stops working. It seems to stop running as soon as the feedback connection is made. I suspect that it is some sort of feedback delay issue, but I've been unable to figure out a way around it. Any help would be appreciated. I've posted my test setup.
    PLL test.audulus
    25K
    Screen Shot 2017-08-04 at 4.25.43 PM.png
    1000 x 612 - 91K
  • oof ... I played with trying to make a PLL for a few weeks and hit a wall (maybe the same one you hit, not sure but it was definitely a feedback delay problem) ... but I'll be watching this thread for sure.

    (Sorry, wish I had the answer man!)
  • I came up with a pretty funky approach using a zero-crossing detector and the sync input. Not really ideal, but it works at least at low frequencies. I don't have a scope available at the moment so I can't really check it at audio frequencies. The zero-crossing detector gets it close and then the sync input brings it into phase.
    PseudoPLL.audulus
    14K
    Screen Shot 2017-08-04 at 6.08.19 PM.png
    924 x 715 - 106K
  • @stschoen If I get a chance later today I will check out your patch on an oscilloscope with an analog reference signal :)
  • @RobertSyrett, that would be great. I haven't totally given up on the original approach, but it seems like Taylor has built in some anti-race "feedback delays" which are preventing the standard PLL design from working. I've re-built the d-type flip-flop using S&H nodes rather than NAND gates, but haven't had a chance to test it in the PLL as yet. It's frustrating since the double d-type phase comparator seems to work fine until I connect it as a feedback signal. I haven't found the feedback delay node to be of much use. It really ought to provide a propagation delay similar to that in "real" logic elements, but I find that modeled flip-flops built from NAND gates have zero delay and feedback loops do not behave predictably. If I can slow down the phase lock using the hack with a slew limiter, I may be able to re-create the wobblebug by using the hack to actually do the phase lock and the phase comparator to drive the rest of the circuit. If I understand it correctly, the wobblebug uses the output of the phase comparator to lock the first VCO with the second and the settling time of the lock is the "woggle time". The first and second oscillators are XORed together for the ring modulated output. The rest of the circuit should be fairly straightforward if I can get the PLL to work (one way or the other)
  • @stschoen Sorry for the delay, I ended up gaming with friends into the wee hours of the morning. So I converted the patch to a cv friendly format and plugged in the pulse wave output of the Noise Reap Bermuda analog oscillator. The green is the audulus PLL osc, the red and blue are the Bermuda sine and pulse waveforms. The slave osc tracks really well, although the phase is kind of all over the place. Sometimes I needed to add .25 and other times .75 or some other more random number. If there is any specific test you would like me to run let me know. I will have the oscilloscope set up all day.

    On a side note, the oscillators in that patch have a slight error in them, an updated version is included with the patch I am uploading.
    PseudoPLL CV.audulus
    9K
    IMG_0804.jpg
    3264 x 2448 - 1M
    IMG_0809.jpg
    3264 x 2448 - 1M
  • Thanks for taking the time to test it out. Interesting that the phase would shift that way. Did it drift over time or did the phase shift stay relatively constant once the oscillator stabilized? It's not really a very satisfactory approach since the zero-crossing detector only outputs an approximate value for the input frequency. I'm not really sure what the sync input does under the hood, but using the sync input to attempt to phase match two oscillators running at slightly different frequencies is definitely a work-around at best. I still haven't been able to get around the feedback loop issue. I'm sure Taylor has attempted to build in protection to prevent race and deadlock situations from arising and I suspect that is what's causing the phase detector to stop when I attempt to use it to control the oscillator frequency.
  • For science!
    The phase was constant for any given pitch, it just would phase (so much phasing) as I swept the pitch knob. I made a quick video on my phone (excuse the poor quality) and made some notes on the specifics. I might actually get a larger sample size so I can see if there is a clear pattern that can be patched around.



    image
  • Graphs are fun :)

    image

    So I tracked the phase offset and it seems to be fairly linear ramp wave pattern repeating every ~58.5 hz or so. After I did the offset test, I checked to see for what frequencies the analog oscillator was in phase with the pseudo PLL and it lined up at 58.6, 117,176, 236, 194, 352, 411, 470, 530, 587, and 644. I made the hypothesis that I could find an arbitrary high frequency that was in phase and it would be a multiple of 58.5. I tuned in 1582 Hz and it is 27*58.5 within 3 sig figs.

    Any thoughts on how to patch around this?
    Screen Shot 2017-08-06 at 7.23.24 PM.png
    1140 x 463 - 80K
  • It certainly looks like there is a pattern there. It seems to shift smoothly as you change frequency. The sync pulse is fired when the input goes positive so maybe it's related to a processing delay. What's your scale for the phase offset? I'm assuming 1 is 360 degrees or 2π radians. I'm going to have another shot at the more conventional PLL. I re-engineered my design for an edge triggered d flip- flop when I was inspired by your post to try my hand at building a version of the Turing Machine module. I thought no problem building a shift register, only to discover that my original design using nand gates had no propagation delay so all the flip-flops in the register flipped at once. I built one using a couple of S&H nodes that loads the data on the rising edge of the clock but delays the output until the falling edge. I added the volts and pulses expander sections as well. I posted it on the Turing Machine thread if you're interested. Now if only I could come up with a good graphic for noise :)
  • Two things
    1) The phase offset is an artifact of the fixed latency. When I ran the signal through audulus and then back into the oscilloscope rather than the other way around it disappeared.

    2) Just to test the accuracy of my measurements I ran Hz/58.5 into the phase input of the oscillator. And it worked! The post latency waveform was in phase for any given frequency below ~ 750 Hz. Above that it starts to freak out and sounds legitimately like the LOCK mode on the DPO which is a PLL circuit. I will try and upload some video comparisons after dinner.

    Also I will totally make a noise graphic if you need one. I think the convention is just some squiggly lines though.
  • Just saw your last post. Maybe we could vary the sync timing using a delay or bias the zero crossing output. It would be interesting to see if the 58.5 shift cycle showed up if you removed the sync pulse. At this point I don't really know which part of the circuit is at fault. Timing in Audulus is largely a "black-box" so generally I just keep trying different things hoping sooner of later I find something that works. Taylor has done a remarkable job, but this kind of simulation, particularly running at audio frequencies in a multi-threaded environment is inherently prone to deadlock and race conditions. Still it's a lot of fun to play with.
  • We're crossing posts this evening. Not sure I understand exactly which latency you're referring to. Are you talking about I/O latency. I hadn't really considered that, but clearly there is an inevitable delay to and from the "real world". I use Reaper as my DAW and it does a pretty good job of compensating but I have certainly dealt with some significant latency issues in the past particularly with the iPad. Don't know why It didn't occur to me in this case.
  • Yep, it's the ES-8 and the ipad are the source of the latency, I quickly tested the patch without the sync from the analog oscillator and it drifts quite a bit.

    BTW, Reaper looks like a pretty awesome daw. I kind of wish I had heard of it before buying Ableton. It has an astonishing value for the price you pay as an individual and the interface seems super flexible.
  • I've been pretty happy with it. It's sometimes a bit confusing, but I haven't found anything it won't do. It runs both AUs and VSTs, has good midi support and is updated frequently. I quickly got tired of garage band but didn't want to pay the price for Logic. I have a "lite" version of Ableton which came with my Focusrite interface but Reaper was such a bargain that it didn't make sense to spend more. I wonder if we can preshift the reference oscillator to compensate for the latency. For a given interface and sample rate it should be fixed. It would need to be set on a case by case basis since different i/o devices, sample rates and buffer sizes will all change it. I'm assuming that the goal to lock an Audulus oscillator to an external signal. The wobblebug is a different scenario entirely and seems to depend on the lag as the phase comparator output brings the PLL into lock to generate its output. Still don't quite get all the signal flow.