Magnus Danielson wrote:
Bruce Griffiths wrote:
Lux, Jim (337C) wrote:
-----Original Message-----
From: time-nuts-boun...@febo.com
[mailto:time-nuts-boun...@febo.com] On Behalf Of Bruce Griffiths
Sent: Wednesday, February 17, 2010 2:10 PM
To: Discussion of precise time and frequency measurement
Subject: Re: [time-nuts] DMTD to MMTD
The latest version actually records time stamps from a continuously
running counter clocked at some at a constant frequency (100Mhz??)for
all channels simultaneously.
They may use a flag bit for each for each channel to indicate to which
channel or channels the zero crossing time stamp belongs.
Simpler than that.. it grabs 20 bit numbers and shoves them out in
ASCII over a com port with an indication of which channel it was for.
The FPGA has a 20 bit free running counter at 100 MHz. When an input
changes state, it latches the counter, and shoves it out along with
the channel number. They use an offset frequency>100 Hz so that you
don't have to disambiguate the counter rollovers. (20 bits rolls
over every 10+milliseconds counting at 100 MHz)
I don't know if there's a FIFO in front of the UART (e.g. what if
you get simultaneous zero crossings).. but I would expect there is.
The "hard work" is in the zero crossing detector ahead of the FPGA.
(and perhaps in the latching of the ZCD inputs into the FPGA).
Given how long ago it was made, that FPGA isn't a huge one.
Using 8 flag bits (one per channel) together with the associated time
stamp is a little more efficient and very easy to do and it doesn't
require a FIFO to ensure that simultaneous zero crossings aren't missed.
It doesn't help at all for this application. The 8 channels is more
likely to be spread out and as Jim pointed out, the next bin is
sufficient for needing a unique time-stamp. The flag-solution is less
efficient (8 bits rather than 3) and the FIFO need is always there,
but may be implemented in various ways. For the flag system to be
efficient, a high probability for the same time-bins to be used needs
to exist, and a high resolution system can expect to actually see
noise spread out the channels over the time-bins.
Depending on the system constraints it may be the difference between
being able to do implement it or not.
A DMTD systems have a low rate of events per channel, but the nominal
distance of events for each channel is fairly long, worst-case burst
is when all channels time-stamps. For a 100 Hz beating and 100 MHz
clock, the nominal rate of rise/fall events is 200 Hz or 5 ms. Letting
the locked value stay put for at least 4 ms. If all channels could be
emptied within these 4 ms (just another way of saying that it has
enough transport capacity) then a fairly simple schedule system can
loop through the channels to find a new sample to transmit.
I think the re-occurring flag system should be put to rest, it doesn't
contribute and is a red herring, at least for this application.
Nonsense, it requires simpler logic and for a device with limited
internal connection/routing capability and a large number of channels
the data path interconnections may be simpler and easier to route. It
may also run with a higher clock frequency.
It should even be possible to impement in a relatively small CPLD albeit
with an external FIFO or equivalent (eg a PPI port on a Blackfin DSP).
Each additional channels requires one input pin, one output pin, a 2 bit
synchroniser and a 1 bit wider data path and little else.
Cheers,
Magnus
Bruce
_______________________________________________
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
