[time-nuts] DAC for OCXO disciplining

Tim S tim.strommen at gmail.com
Sun Jan 19 17:51:53 UTC 2020


I agree on this point,

      A while back I thought that it was easier to do things in software
with a cheap PIC, but as I found by accident how easy it was to do CPLDs
and FPGAs is reality with modern tools and needed more accurate timing and
control, I've been moving more over "hardware".  PWM and PDM are
fairly easy to do and the clock intervals can be controlled with very tight
tolerances (as the edges are driven directly by the clocked logic at
known/fixed timing).

PDM for example can be done with an adder/accumulator (carry-out adds 2 so
that ZERO never occurs in the accumulator, so 1-255 for example), some flip
flops and a few XORs, AND'd to a setting register at any bit depth that
fits in your CPLD/FPGA.  Because it'll run at clock speed once timing is
closed, the intervals are very precise even over long time periods - and
the output is from 0-255 (in an 8-bit design) spread evenly over t =
frequency / ( 2^bitdepth - 1).  Once you understand what's going on to
generate the PDM it's pretty easy, the hint is accumulator generated edges
and setting register endian-ness.  An over spec'd bit depth at a higher
clock rate through a reconstruction filter (low-pass) can give one a very
good output.  I tuned one of these on a THX Certified analog video output
about 15 years ago when that was still a thing.

Somewhere I have an OpenOffice Calc document where I have a live
demonstration of this logic.

Once you dig into the control algorithms/loops themselves they are fairly
straightforward to implement in CPLD/FPGA so that when the power is turned
on the hardware will just do what it's supposed to do to make the system
function, and you can run it as slow as is necessary to execute the
algorithm.  Then if you want to pull out registers to interface with
something like a UART, the reading/writing won't impact timing at all as it
won't interrupt any software functions - and you can even do that it a
separate timing domain if you need with FPGAs (run correction logic at
20Hz, run UART at 10MHz for example).

-Tim

Date: Sat, 18 Jan 2020 23:51:44 +0100
> From: Magnus Danielson <magnus at rubidium.se>
> To: time-nuts at lists.febo.com
> Subject: Re: [time-nuts] DAC for OCXO disciplining
> Message-ID: <fd74e008-bb60-0ff1-2808-7020de6ef3fe at rubidium.se>
> Content-Type: text/plain; charset=utf-8
>
> Hi Hal,
>
> On 2020-01-18 22:50, Hal Murray wrote:
> > magnus at rubidium.se said:
> >> I was amazed that it was this simple to move energy to where it makes
> less
> >> damage. Turns out that FPGA logic wise, it's at the same cost as PWM.
> > You can do the same thing in software.  Many small CPUs have IO gear
> that lets
> > you send raw bits.  Just setup a buffer in memory and send it out.
> >
> > Simple UARTs aren't ideal due to start/stop bits but you can probably
> work
> > around that.  Your output range is 10% to 90% rather than 0-100.  Many
> serial
> > ports have modes without start/stop bits.  I haven't looked carefully
> but some
> > of the gear for simple 2 or 3 wire protocols may work.
> >
> Sure, you can do this in CPU, but you want to make the updates fairly
> well spread over time, with relatively robust timing, which you for sure
> can do, the PICDIV shows this, but you need to know this is part of the
> design problem and focus on that.
>
> I implemented it in FPGA because I was already doing it in the FPGA
> domain, and getting stable enough timing was trivial and would still be
> my preferred method.
>
> Cheers,
> Magnus
>



More information about the Time-nuts_lists.febo.com mailing list