[time-nuts] DMTD to MMTD

Magnus Danielson magnus at rubidium.dyndns.org
Thu Feb 18 09:42:13 UTC 2010

Bruce Griffiths wrote:
> Lux, Jim (337C) wrote:
>>> -----Original Message-----
>>> From: time-nuts-bounces at febo.com [mailto:time-nuts-bounces at 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.

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.


More information about the time-nuts mailing list