[time-nuts] DMTD to MMTD

Bruce Griffiths bruce.griffiths at xtra.co.nz
Thu Feb 18 19:59:06 UTC 2010


System constraints arent necessarily due to cost constraints.
The constraints may be imposed by experience limitations and the 
learning curve associated with FPGAs etc.
If one already has a high end DSP in the system its almost possible 
(with the right DSP) to implement the multichannel time tagging purely 
in software.

Bruce

Bob Camp wrote:
> Hi
>
> Just to bound the problem a little.
>
> An EP3C5 fpga, with all the support stuff (flash chip, regulators..) is
> under $30. It's gross overkill for the application.
>
> A set of Mini-Circuits SYPD-2 mixers at $19 each are $114 for six channels.
>
> A set of 20 stage limiters at $2 per op amp would be $240 for the six
> channels. They could be $1, they also could be $5 each.
>
> The FPGA is not what leaps out on the bill of material. It's down in the 10%
> round off error range....
>
> Bob
>
> -----Original Message-----
> From: time-nuts-bounces at febo.com [mailto:time-nuts-bounces at febo.com] On
> Behalf Of Bruce Griffiths
> Sent: Thursday, February 18, 2010 7:28 AM
> To: Discussion of precise time and frequency measurement
> Subject: Re: [time-nuts] DMTD to MMTD
>
> Magnus Danielson wrote:
>    
>> 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.
>>
>>      
> 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 at febo.com
> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>
>
>
>
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>
>    





More information about the time-nuts mailing list