DMTD to MMTD
Hi
Yes, but look at all the Danish lawyers that earn a living by going after just such stupidity ....
Bob
On Feb 17, 2010, at 7:33 PM, Bruce Griffiths wrote:
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.
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.
Bruce Griffiths wrote:
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.
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.
Cheers,
Magnus
Magnus Danielson wrote:
Bruce Griffiths wrote:
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.
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
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@febo.com [mailto:time-nuts-bounces@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@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.
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.
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@febo.com [mailto:time-nuts-bounces@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@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.
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.
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.
Bruce Griffiths wrote:
Magnus Danielson wrote:
Bruce Griffiths wrote:
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.
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.
With your clarifying comment yes... because it is until now that you
have clarified the merit of the flag system, lowered implementation
complexity vs. lowered signalling capacity.
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.
But it produces more data, which was what I was commenting on. Indeed it
is very simple to implement, but it's a complexity which is still on the
low-end.
So, finally you made the point of the merit of the approach in such a
way that it became clear to me why you have maintained that standpoint.
Cheers,
Magnus
Bruce Griffiths wrote:
System constraints arent necessarily due to cost constraints.
The constraints may be imposed by experience limitations and the
learning curve associated with FPGAs etc.
The level of design ability needed is still moderate, and for a skilled
designer, the effort to produce one for a friend in need is moderate.
The I/O is probably going to cause more head-ache than the measurement
engine anyway. Even a serial port with binary data takes some care in
designing.
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.
Getting it right with a DSP could be just as challenging.
Cheers,
Magnus
Hi
The one I've done up sends hex ascii. It doubles the serial rate, but the decode on the computer end is much easier. With short cables and modern hardware, high speed RS-232 is pretty reliable stuff.
Bob
On Feb 18, 2010, at 9:41 PM, Magnus Danielson wrote:
Bruce Griffiths wrote:
System constraints arent necessarily due to cost constraints.
The constraints may be imposed by experience limitations and the learning curve associated with FPGAs etc.
The level of design ability needed is still moderate, and for a skilled designer, the effort to produce one for a friend in need is moderate. The I/O is probably going to cause more head-ache than the measurement engine anyway. Even a serial port with binary data takes some care in designing.
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.
Getting it right with a DSP could be just as challenging.
Cheers,
Magnus
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.
Magnus Danielson wrote:
Bruce Griffiths wrote:
Magnus Danielson wrote:
Bruce Griffiths wrote:
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.
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.
With your clarifying comment yes... because it is until now that you
have clarified the merit of the flag system, lowered implementation
complexity vs. lowered signalling capacity.
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.
But it produces more data, which was what I was commenting on. Indeed
it is very simple to implement, but it's a complexity which is still
on the low-end.
So, finally you made the point of the merit of the approach in such a
way that it became clear to me why you have maintained that standpoint.
Cheers,
Magnus
One can always reduce the data sent to the PC by removing redundant
information, or increase it by Ascii coding of channels and slope
polarities.
In general in the absence of significant constraints either method will
work, they just have different tradeoffs.
Its tempting to see if one can just synchronously clock the synchronised
ZCD output signals directly into a processor and derive the timestamps
entirely in software.
The only question being what is the maximum clock frequency at which
this can be done without missing any ZCD transitions.
A Blackfin DSP for example should be able to do this with a maximum ZCD
sampling clock frequency of at least 50MHz.
Bruce
Hi
Anything over 100 MHz should do the trick. On a machine with a full OS on it that kind of sustained I/O would be tough to do un-interupted.
Now, doing a 32 bit shift register externally and clocking in a word at 100 / 32 MHz - not quite as hard.
Bob
On Feb 18, 2010, at 9:54 PM, Bruce Griffiths wrote:
Magnus Danielson wrote:
Bruce Griffiths wrote:
Magnus Danielson wrote:
Bruce Griffiths wrote:
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.
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.
With your clarifying comment yes... because it is until now that you have clarified the merit of the flag system, lowered implementation complexity vs. lowered signalling capacity.
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.
But it produces more data, which was what I was commenting on. Indeed it is very simple to implement, but it's a complexity which is still on the low-end.
So, finally you made the point of the merit of the approach in such a way that it became clear to me why you have maintained that standpoint.
Cheers,
Magnus
One can always reduce the data sent to the PC by removing redundant information, or increase it by Ascii coding of channels and slope polarities.
In general in the absence of significant constraints either method will work, they just have different tradeoffs.
Its tempting to see if one can just synchronously clock the synchronised ZCD output signals directly into a processor and derive the timestamps entirely in software.
The only question being what is the maximum clock frequency at which this can be done without missing any ZCD transitions.
A Blackfin DSP for example should be able to do this with a maximum ZCD sampling clock frequency of at least 50MHz.
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.