<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Hi,<br>
    </p>
    <div class="moz-cite-prefix">On 2020-01-27 15:01, Tom Wiltshire
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:22819289-CBFB-429D-B712-53A4EEC3C49A@electricdruid.net">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      <br class="">
      <div class="">
        <div style="word-wrap: break-word; -webkit-nbsp-mode: space;
          -webkit-line-break: after-white-space;" class="">
          <div style="color: rgb(0, 0, 0); font-family: Helvetica;
            font-size: 12px; font-style: normal; font-variant-caps:
            normal; font-weight: normal; letter-spacing: normal;
            orphans: auto; text-align: start; text-indent: 0px;
            text-transform: none; white-space: normal; widows: auto;
            word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br
              class="">
          </div>
        </div>
      </div>
      <div class=""><br class="webkit-block-placeholder">
      </div>
      <div class="">Thanks everyone for so many ideas. I’d like to go
        through some of them in turn, since there’s a lot I don’t
        understand.</div>
      <div><br class="">
        <blockquote type="cite" class="">
          <div class="">On 23 Jan 2020, at 12:23, René Schmitz <<a
              href="mailto:synth@schmitzbits.de" class=""
              moz-do-not-send="true">synth@schmitzbits.de</a>> wrote:</div>
          <div class="">
            <div class=""><br class="">
              One approach would be to somehow(*) raise the frequency of
              the NCO and divide it down afterwards. If the chip can not
              do that directly, its no longer a single chip solution.
              But if you could generate the frequency say 3 octaves up,
              then divide by 8, you reduce all effects.<br class="">
            </div>
          </div>
        </blockquote>
      </div>
      <br class="">
      <div class="">This might be possible. On the new chip, I have room
        to increase the frequency increment, (24-bit inc with 24-bit
        accumulator running on 32MHz clock) which would give a higher
        output frequency. This might then be able to be routed through
        some other internal module to divide it down - after all,
        there’s a lot of things that can be made to do a flip-flop's
        job.</div>
      <div class=""><br class="">
      </div>
      <div class="">What I don’t understand though is how this helps.
        Increasing the output frequency is going to increase aliasing
        too, and dividing it down again afterwards doesn’t seem to
        remove that to me. How does this work please, René?</div>
    </blockquote>
    It's a standard trick. With higher DDS clock you get smaller
    time-errors, and then the divide down just removes transitions
    between the transitions. Higher synthesized frequency allows you to
    use more of the upper bits of the DDS, to achieve more effective
    bits useable in the DDS.<br>
    <blockquote type="cite"
      cite="mid:22819289-CBFB-429D-B712-53A4EEC3C49A@electricdruid.net"><br>
      <div class="">
        <blockquote type="cite" class="">
          <div class="">On 23 Jan 2020, at 13:36, Magnus Danielson <<a
              href="mailto:magnus@rubidium.se" class=""
              moz-do-not-send="true">magnus@rubidium.se</a>> wrote:</div>
          <div class=""><br class="">
            You can increase the NCO resolution by doing a software
            extension of<br class="">
            bits, so you accumulate the error between where you wanted
            to steer the<br class="">
            NCO and what you have set it to. As you do this often
            enough, you can<br class="">
            keep amplitude of time error down and rate of update noise
            up.<br class="">
          </div>
        </blockquote>
        <div class=""><br class="">
        </div>
        This sounds interesting, but I don’t really understand what
        you’re proposing. What do you mean “time error” and “update
        noise”? And what do you mean “steering” the NCO? The value it
        gets set to is the required value given the current modulation
        value, but the problem is that that value doesn’t take effect
        immediately.</div>
      <div class=""><br class="">
      </div>
      <div class="">Note this is a hardware module, so I don’t get
        software access every time the frequency increment is added,
        only when the counter overflows (and then only in an interrupt a
        few cycles later). If that makes a difference.</div>
    </blockquote>
    What you can do is to alter the value you write into it. Consider
    that you can write 42 and 43, by alternating the pattern you can go
    from 42 42 42 42 to 42 42 43 42 to 42 43 42 43 to 42 43 43 43 to 43
    43 43 43. For this trivial example you now on average write 42.0,
    42.25, 42.50, 42.75 and 43.00. This increases your resolution. If
    you do this using a accumulator you can keep in memory how much you
    intended to write and then compensate that later. This is just a
    phase-accumulator or frequency error accumulator. Trivial code to
    achieve improved resolution.<br>
    <blockquote type="cite"
      cite="mid:22819289-CBFB-429D-B712-53A4EEC3C49A@electricdruid.net">
      <div class=""><br class="">
        <blockquote type="cite" class="">
          <div class="">Another trick is to use a PLL to clean up the
            noise.<br class="">
          </div>
        </blockquote>
        <div class=""><br class="">
        </div>
        <div class="">Several people mentioned using a PLL in one way or
          another. Clearly, I could design a “better” LFO+VCO
          combination that wouldn’t have the problems that I currently
          have, and using the PIC for the LFO and something like the
          4046 for the VCO would be a good way to go.</div>
        <div class="">But the point of the project was to simplify a
          flanger circuit as far as possible, so getting both the LFO
          and the VCO onto an 8-pin DIP chip counts as success, and
          using a 14-pin external VCO or larger 32-bit ARM processor
          doesn’t meet the aims.</div>
        <div class="">I’m willing to accept the limitations that go with
          this approach, but I’d like to learn as much as I can to
          enable me to minimise them as far as possible. I suspect (but
          don’t *know*) that further improvement is possible.</div>
      </div>
    </blockquote>
    <p>Well, either you use a modern clock circuit that provides what
      you need, or you have to build it separately yourself. Some chips
      contains clean-up oscillators, others lock up a high-frequency
      oscillator.</p>
    <p>What tools do you have to measure? Do you have a counter that can
      do time-interval measures?</p>
    <p>It is relatively easy to servo up another oscillator, and then
      analyze the output of the phase-detector. That way you can see the
      time-signal and spectrum of the phase-noise.<br>
    </p>
    <p>Cheers,<br>
      Magnus<br>
    </p>
    <br>
  </body>
</html>