Re: [Thumbgps-devel] Fwd: Long term SiRF data

[Patrick Maupin <pmaupin@gmail.com>]

On Sat, Mar 17, 2012 at 1:04 PM, Ron Frazier (NTP)
<timekeepingntplist@c3energy.com> wrote:
> I don't know what all your design criteria are, but for just the little
> piece of the problem you mentioned above, you could try something like this.
>  Take the output of one of those OCXO's, which I think you said is 26 Mhz.
>  If I'm doing my math right, run that through a 15 bit counter to divide it
> down.  The output should be a very accurate 793.457 Hz square wave.  You
> could, of course add more bits to divide further.  You could also add some
> glue logic to reset the counter at any point you wanted, to get less ugly
> output frequencies.  Take that 793 Hz square wave and feed it into one of
> the handshaking pins, like DCD, on any Prolific or FTDI based serial - usb
> converter that passes handshaking.  I have a Trendnet TU-S9 unit which I
> hope to be testing soon.  This should give you very consistent USB messages
> coming from the converter with a period of about 1.2 ms.

I'm not a huge fan of discrete logic, and I'm buying reasonable sized
FPGAs, so we don't need to do really fancy stuff to get count values
that we want.  It will be dead easy.  In fact, my thought was that the
system could tell it what frequency it wanted to be interrupted.
Sometimes you might want to monitor things closely, other times just
run minimal interrupts in the background.

Also, I can send characters to the host with fairly precise timing
(the parallel mode of the FTDI has a SIWU pin that you can assert to
empty the buffer to the host), so I thought I could send a counter to
the host, so you'd never get "lost".  I can also send timestamps for
external events, if we hook it up to other hardware.

BTW, the FPGA can internally multiply the clock up to around 200 MHz,
with only around 300 ps of jitter, so I can interrupt at pretty much
whatever really precise rate we want.

For work designs, I usually pick a clock rate around 130 MHz or so as
a nice balance -- 7.5 ns gives you close timing, and you can still get
plenty of gates between flops without violating timing.  At work I'm
usually using something like 8.192 MHz * 16 = 131.072 MHz, but with a
26 MHz crystal, I'll just use 26 * 5 = 130.000 MHz.

I've used the parallel mode of the FTDI chip a lot, and I can transfer
data between the FTDI and the FPGA at an equivalent baud rate > 30
MBaud, so we can have pretty tight tolerances there as well.

So the whole thing should be pretty flexible.

Regards,
Pat