DMTD to MMTD
Hi
DMTD looks at a pair of sources (crystal, rubidium, maser .) and tells you
the difference between them. If you looked at more than two, you can better
characterize the individual sources.
Any good papers out there on taking the DMTD approach and extending it to
simultaneous observation of a number (like 3 or 5) of oscillators? I'm sure
I've missed at least one ..
Bob
Bob Camp wrote:
Hi
DMTD looks at a pair of sources (crystal, rubidium, maser .) and tells you
the difference between them. If you looked at more than two, you can better
characterize the individual sources.
Any good papers out there on taking the DMTD approach and extending it to
simultaneous observation of a number (like 3 or 5) of oscillators? I'm sure
I've missed at least one ..
Bob
Bob
JPL have had such systems for many years:
http://tycho.usno.navy.mil/ptti/1994/Vol%2026_25.pdf
Bruce
Bruce Griffiths wrote:
Bob Camp wrote:
Hi
DMTD looks at a pair of sources (crystal, rubidium, maser .) and
tells you
the difference between them. If you looked at more than two, you can
better
characterize the individual sources.
Any good papers out there on taking the DMTD approach and extending
it to
simultaneous observation of a number (like 3 or 5) of oscillators?
I'm sure
I've missed at least one ..
Bob
Bob
JPL have had such systems for many years:
http://tycho.usno.navy.mil/ptti/1994/Vol%2026_25.pdf
Bruce
Hi
Thanks for the quick response.
The impression I've always had of that system is that it is comparing the
sources two at a time. They can select between a number of sources, but only
one pair is looked at.
I'm after stuff on a system that simultaneously looks at several sources. My
assumption is that you could simply use a bunch of DMTD's and then do the
math. You might also be able to simplify things a bit....
Bob
-----Original Message-----
From: time-nuts-bounces@febo.com [mailto:time-nuts-bounces@febo.com] On
Behalf Of Bruce Griffiths
Sent: Wednesday, February 17, 2010 3:57 PM
To: Discussion of precise time and frequency measurement
Subject: Re: [time-nuts] DMTD to MMTD
Bob Camp wrote:
Hi
DMTD looks at a pair of sources (crystal, rubidium, maser .) and tells you
the difference between them. If you looked at more than two, you can
better
characterize the individual sources.
Any good papers out there on taking the DMTD approach and extending it to
simultaneous observation of a number (like 3 or 5) of oscillators? I'm
sure
I've missed at least one ..
Bob
Bob
JPL have had such systems for many years:
http://tmo.jpl.nasa.gov/progress_report/42-169/169B.pdf
<edit to fix link>http://tmo.jpl.nasa.gov/progress_report/42-169/169B.pdf
http://tycho.usno.navy.mil/ptti/1994/Vol%2026_25.pdf
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.
Bob Camp wrote:
Hi
DMTD looks at a pair of sources (crystal, rubidium, maser .) and tells you
the difference between them. If you looked at more than two, you can better
characterize the individual sources.
Any good papers out there on taking the DMTD approach and extending it to
simultaneous observation of a number (like 3 or 5) of oscillators? I'm sure
I've missed at least one ..
NIST made such a system and did a few papers... essentially they just
made more channels from the same transfer oscillator. Logical extension.
Cheers,
Magnus
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.
I posted the link to the relevant paper which doesn't seem to have made
it to the list yet.
http://tycho.usno.navy.mil/ptti/ptti2006/paper11.pdf
http://tycho.usno.navy.mil/ptti/ptti2006/paper26.pdf
http://www.dtic.mil/cgi-bin/GetTRDoc?AD=ADA485911&Location=U2&doc=GetTRDoc.pdf
http://www.dtic.mil/cgi-bin/GetTRDoc?AD=ADA485911&Location=U2&doc=GetTRDoc.pdf
The first link is the relevant one.
They make use of the multichannel data to identify out sources that have
a problem.
This isnt possible when just monitoring 2 channels at a time.
Bruce
Bob Camp wrote:
Hi
Thanks for the quick response.
The impression I've always had of that system is that it is comparing the
sources two at a time. They can select between a number of sources, but only
one pair is looked at.
I'm after stuff on a system that simultaneously looks at several sources. My
assumption is that you could simply use a bunch of DMTD's and then do the
math. You might also be able to simplify things a bit....
Bob
-----Original Message-----
From: time-nuts-bounces@febo.com [mailto:time-nuts-bounces@febo.com] On
Behalf Of Bruce Griffiths
Sent: Wednesday, February 17, 2010 3:57 PM
To: Discussion of precise time and frequency measurement
Subject: Re: [time-nuts] DMTD to MMTD
Bob Camp wrote:
Hi
DMTD looks at a pair of sources (crystal, rubidium, maser .) and tells you
the difference between them. If you looked at more than two, you can
better
characterize the individual sources.
Any good papers out there on taking the DMTD approach and extending it to
simultaneous observation of a number (like 3 or 5) of oscillators? I'm
sure
I've missed at least one ..
Bob
Bob
JPL have had such systems for many years:
http://tmo.jpl.nasa.gov/progress_report/42-169/169B.pdf
<edit to fix link>http://tmo.jpl.nasa.gov/progress_report/42-169/169B.pdf
http://tycho.usno.navy.mil/ptti/1994/Vol%2026_25.pdf
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.
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.
-----Original Message-----
From: time-nuts-bounces@febo.com [mailto:time-nuts-bounces@febo.com] On Behalf Of Bob Camp
Sent: Wednesday, February 17, 2010 1:57 PM
To: 'Discussion of precise time and frequency measurement'
Subject: Re: [time-nuts] DMTD to MMTD
Hi
Thanks for the quick response.
The impression I've always had of that system is that it is comparing the
sources two at a time. They can select between a number of sources, but only
one pair is looked at.
It basically timestamps transitions on all 8 inputs. The post processing software that looks a the timestamps is what selects either 1 channel (single mixer+offset generator) or 2 channels (dual mixer time difference)
The counters in the FPGA are running at 100 MHz, so they have a basic resolution of 10 ns.
Lux, Jim (337C) wrote:
-----Original Message-----
From: time-nuts-bounces@febo.com [mailto:time-nuts-bounces@febo.com] On Behalf Of Bob Camp
Sent: Wednesday, February 17, 2010 1:57 PM
To: 'Discussion of precise time and frequency measurement'
Subject: Re: [time-nuts] DMTD to MMTD
Hi
Thanks for the quick response.
The impression I've always had of that system is that it is comparing the
sources two at a time. They can select between a number of sources, but only
one pair is looked at.
It basically timestamps transitions on all 8 inputs. The post processing software that looks a the timestamps is what selects either 1 channel (single mixer+offset generator) or 2 channels (dual mixer time difference)
The counters in the FPGA are running at 100 MHz, so they have a basic resolution of 10 ns.
-----Original Message-----
From: time-nuts-bounces@febo.com [mailto:time-nuts-bounces@febo.com] On Behalf Of Bruce Griffiths
Sent: Wednesday, February 17, 2010 2:27 PM
To: Discussion of precise time and frequency measurement
Subject: Re: [time-nuts] DMTD to MMTD
Lux, Jim (337C) wrote:
-----Original Message-----
From: time-nuts-bounces@febo.com [mailto:time-nuts-bounces@febo.com] On Behalf Of Bob Camp
Sent: Wednesday, February 17, 2010 1:57 PM
To: 'Discussion of precise time and frequency measurement'
Subject: Re: [time-nuts] DMTD to MMTD
Hi
Thanks for the quick response.
The impression I've always had of that system is that it is comparing the
sources two at a time. They can select between a number of sources, but only
one pair is looked at.
It basically timestamps transitions on all 8 inputs. The post processing software that looks a the
timestamps is what selects either 1 channel (single mixer+offset generator) or 2 channels (dual mixer
time difference)
The counters in the FPGA are running at 100 MHz, so they have a basic resolution of 10 ns.
That's basically the same as the IPN progress report you linked in the earlier email. Same figures, nicer typography, but the figures are better in the IPN progress report (169B).
As it says, referring to the Counter Assembly:
"It latches the readings of a continuously-running 100 MHz counter at the zero-crossing times of all channels that have a valid signal present. The output is fed continuously into the computer's serial port with no flow control."
Steve Cole doesn't show up in the phonebook, so I can't just call him for more details, but I could probably find a copy of the footnoted description. I'd actually be more interested in the design of the zero crosser.
Seeing if one could get a copy of NPO-40468 from NASA Tech Briefs (if it was published there) might also be useful.
Try this: http://www.techbriefs.com/component/content/738?task=view
Or
http://www.techbriefs.com/component/docman/doc_download/2222-progress-on-a-multichannel-dual-mixer-stability-analyzer
those reference
http://www.techbriefs.com/component/content/article/7326
http://www.techbriefs.com/component/docman/doc_download/1618-oscillator-stability-analyzer-based-on-a-time-tag-counter
but there's nothing much new in that one..
JPL have had such systems for many years:
http://tmo.jpl.nasa.gov/progress_report/42-169/169B.pdfhttp://tmo.jpl.nasa.gov/progress_report/42-
169/169B.pdf
Additional papers:
That's basically the same paper as the http://tmo.jpl.nasa.gov/ reference above.
That one just talks about the LITS standard, but doesn't describe any of the measurement technique, just results for the Hg+ ion clock.
http://www.dtic.mil/cgi-bin/GetTRDoc?AD=ADA485911&Location=U2&doc=GetTRDoc.pdf
http://www.dtic.mil/cgi-bin/GetTRDoc?AD=ADA485911&Location=U2&doc=GetTRDoc.pdf
There's not a huge amount of information in that one, more high level block diagrams of how DSN does its synchronization and screen shots of the software.
http://ipnpr.jpl.nasa.gov/progress_report/42-167/167C.pdf is a better description of the system.
Rummaging through here:
http://tmo.jpl.nasa.gov/index.cfm
might be productive. A lot of the IPN progress reports (formerly TMO, TDA, or DSN progress reports) don't get indexed in the JPL Technical Reports Server or the NASA equivalent.
-----Original Message-----
From: time-nuts-bounces@febo.com [mailto:time-nuts-bounces@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.
Hi
Any of the Cyclone III parts will do the FPGA part without breaking a sweat. That includes the FIFO and ASCII stuff. I agree that the "magic" is in the zero crossing stuff.
Bob
On Feb 17, 2010, at 6:34 PM, Lux, Jim (337C) wrote:
-----Original Message-----
From: time-nuts-bounces@febo.com [mailto:time-nuts-bounces@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.
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.
Lux, Jim (337C) wrote:
-----Original Message-----
From: time-nuts-bounces@febo.com [mailto:time-nuts-bounces@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.
Bruce
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.
Still need the FIFO..
Say you got one zero crossing at 0x01000 and the next at 0x01001 (where the number is the 20 bits in hex).. you'd still be sending the characters out the UART for the 0x01000 crossing when the next crossing occurred 10ns later.
If I were doing it today (and I have no idea how Steve built it 10 years ago), I'd do something like a character for channel number and direction (ascii 0 through 7 for positive going, 8 through F for negative going) and 5 characters for the count (in hex), followed by a carriage return. All printable characters, easy for testing, no hiccups with DOS or some device driver trying to interpret binary, etc.
You've got 8 channels, each zerocrossing at about 200-300 Hz (the difference frequency is 123 or 124 Hz, so you get twice that many zero crossings), or about 1600-2400 messages/second. At 6 characters per message, that's about 10,000 characters per second, so you'd need a fairly fast UART to keep up. (OTOH, the article mentions dropping characters..)
They might have only used one direction of zero crossing, which gets you down to the 5000 characters per second, which you might be able to squeeze into a 38.4kbps serial stream, especially if you go to a denser packing. But you'll still need a FIFO.
Next time I see one of the FTL guys, I'll ask.
Jim
Hi
With the number of gates you get today, taking the word length out to 32 bits it pretty easy. That helps on roll over, not so much on data rate ....
Bob
On Feb 17, 2010, at 7:09 PM, Lux, Jim (337C) wrote:
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.
Still need the FIFO..
Say you got one zero crossing at 0x01000 and the next at 0x01001 (where the number is the 20 bits in hex).. you'd still be sending the characters out the UART for the 0x01000 crossing when the next crossing occurred 10ns later.
If I were doing it today (and I have no idea how Steve built it 10 years ago), I'd do something like a character for channel number and direction (ascii 0 through 7 for positive going, 8 through F for negative going) and 5 characters for the count (in hex), followed by a carriage return. All printable characters, easy for testing, no hiccups with DOS or some device driver trying to interpret binary, etc.
You've got 8 channels, each zerocrossing at about 200-300 Hz (the difference frequency is 123 or 124 Hz, so you get twice that many zero crossings), or about 1600-2400 messages/second. At 6 characters per message, that's about 10,000 characters per second, so you'd need a fairly fast UART to keep up. (OTOH, the article mentions dropping characters..)
They might have only used one direction of zero crossing, which gets you down to the 5000 characters per second, which you might be able to squeeze into a 38.4kbps serial stream, especially if you go to a denser packing. But you'll still need a FIFO.
Next time I see one of the FTL guys, I'll ask.
Jim
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.
Lux, Jim (337C) wrote:
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.
Still need the FIFO..
Say you got one zero crossing at 0x01000 and the next at 0x01001 (where the number is the 20 bits in hex).. you'd still be sending the characters out the UART for the 0x01000 crossing when the next crossing occurred 10ns later.
If I were doing it today (and I have no idea how Steve built it 10 years ago), I'd do something like a character for channel number and direction (ascii 0 through 7 for positive going, 8 through F for negative going) and 5 characters for the count (in hex), followed by a carriage return. All printable characters, easy for testing, no hiccups with DOS or some device driver trying to interpret binary, etc.
You've got 8 channels, each zerocrossing at about 200-300 Hz (the difference frequency is 123 or 124 Hz, so you get twice that many zero crossings), or about 1600-2400 messages/second. At 6 characters per message, that's about 10,000 characters per second, so you'd need a fairly fast UART to keep up. (OTOH, the article mentions dropping characters..)
They might have only used one direction of zero crossing, which gets you down to the 5000 characters per second, which you might be able to squeeze into a 38.4kbps serial stream, especially if you go to a denser packing. But you'll still need a FIFO.
Next time I see one of the FTL guys, I'll ask.
Jim
A LAN, USB or Firewire interface may be more appropriate all are easy to
implement.
Bruce
Hi
No Windows 7 driver signing issues with a serial port. USB can be a bit of a tangle that way, not as easy as it used to be.
Bob
On Feb 17, 2010, at 7:20 PM, Bruce Griffiths wrote:
Lux, Jim (337C) wrote:
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.
Still need the FIFO..
Say you got one zero crossing at 0x01000 and the next at 0x01001 (where the number is the 20 bits in hex).. you'd still be sending the characters out the UART for the 0x01000 crossing when the next crossing occurred 10ns later.
If I were doing it today (and I have no idea how Steve built it 10 years ago), I'd do something like a character for channel number and direction (ascii 0 through 7 for positive going, 8 through F for negative going) and 5 characters for the count (in hex), followed by a carriage return. All printable characters, easy for testing, no hiccups with DOS or some device driver trying to interpret binary, etc.
You've got 8 channels, each zerocrossing at about 200-300 Hz (the difference frequency is 123 or 124 Hz, so you get twice that many zero crossings), or about 1600-2400 messages/second. At 6 characters per message, that's about 10,000 characters per second, so you'd need a fairly fast UART to keep up. (OTOH, the article mentions dropping characters..)
They might have only used one direction of zero crossing, which gets you down to the 5000 characters per second, which you might be able to squeeze into a 38.4kbps serial stream, especially if you go to a denser packing. But you'll still need a FIFO.
Next time I see one of the FTL guys, I'll ask.
Jim
A LAN, USB or Firewire interface may be more appropriate all are easy to implement.
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.
-----Original Message-----
From: time-nuts-bounces@febo.com [mailto:time-nuts-bounces@febo.com] On Behalf Of Bruce Griffiths
Sent: Wednesday, February 17, 2010 4:20 PM
To: Discussion of precise time and frequency measurement
Subject: Re: [time-nuts] DMTD to MMTD
Lux, Jim (337C) wrote:
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.
You've got 8 channels, each zerocrossing at about 200-300 Hz (the difference frequency is 123 or 124
Hz, so you get twice that many zero crossings), or about 1600-2400 messages/second. At 6 characters
per message, that's about 10,000 characters per second, so you'd need a fairly fast UART to keep up.
(OTOH, the article mentions dropping characters..)
A LAN, USB or Firewire interface may be more appropriate all are easy to
implement.
Yes, but faster rise times and potentially more EMI. The FTL guys are pretty obsessive about stray noise sources.
As far as interfaces.. if I were choosing, I'd use LAN (like pair a Rabbit with the FPGA.. the Rabbit does the UI as a static webserver kind of thing), although USB is ok, but ties the box to one computer. USB is cheaper though.
Firewire/1394 is a dying standard... If you need speed, then GigE would probably be a better choice.
-----Original Message-----
From: time-nuts-bounces@febo.com [mailto:time-nuts-bounces@febo.com] On Behalf Of Bob Camp
Sent: Wednesday, February 17, 2010 4:24 PM
To: Discussion of precise time and frequency measurement
Subject: Re: [time-nuts] DMTD to MMTD
Hi
No Windows 7 driver signing issues with a serial port. USB can be a bit of a tangle that way, not as
easy as it used to be.
Bob
That's what's nice about IP over Ethernet... hang it on the network, any machine can see it.
Yet another reason to use an operating system that doesn't enforce such
arcane requirements intended as part of an insidious content protection
systems that prevent one from acquiring ones own data.
Bruce
Bob Camp wrote:
Hi
No Windows 7 driver signing issues with a serial port. USB can be a bit of a tangle that way, not as easy as it used to be.
Bob
On Feb 17, 2010, at 7:20 PM, Bruce Griffiths wrote:
Lux, Jim (337C) wrote:
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.
Still need the FIFO..
Say you got one zero crossing at 0x01000 and the next at 0x01001 (where the number is the 20 bits in hex).. you'd still be sending the characters out the UART for the 0x01000 crossing when the next crossing occurred 10ns later.
If I were doing it today (and I have no idea how Steve built it 10 years ago), I'd do something like a character for channel number and direction (ascii 0 through 7 for positive going, 8 through F for negative going) and 5 characters for the count (in hex), followed by a carriage return. All printable characters, easy for testing, no hiccups with DOS or some device driver trying to interpret binary, etc.
You've got 8 channels, each zerocrossing at about 200-300 Hz (the difference frequency is 123 or 124 Hz, so you get twice that many zero crossings), or about 1600-2400 messages/second. At 6 characters per message, that's about 10,000 characters per second, so you'd need a fairly fast UART to keep up. (OTOH, the article mentions dropping characters..)
They might have only used one direction of zero crossing, which gets you down to the 5000 characters per second, which you might be able to squeeze into a 38.4kbps serial stream, especially if you go to a denser packing. But you'll still need a FIFO.
Next time I see one of the FTL guys, I'll ask.
Jim
A LAN, USB or Firewire interface may be more appropriate all are easy to implement.
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.
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.