HM
Hal Murray
Wed, Sep 28, 2011 6:19 PM
I'm looking for device with an external clock input as well as inputs for
multiple PPS signals that outputs timestamped messages for each input pulse
via RS232. ...
What sort of accuracy and/or resolution do you want/need?
- Using a FreeBSD or Linux box with multiple RS-232 inputs and using their
PPS API. However, outside of some ARM boards, I haven't found any boxes
that can be clocked by a external reference. And, I haven't enough
experience running FreeBSD or Linux on ARM to know how well this will work
for me.
- Use a box like in #5, and capture the PPS from the PRS-10 as well and
using that to scale the other PPS inputs that arrive around the same time.
If you have a Linux box handy, that one is easy to try.
After the 60Hz grab-every-cycle experiment, I started collecting every-cycle
data for PPS signals. I have a box with 3 PPS signals: one from a Z3801A
and 2 from low cost GPS units.
I can send you some files if you want to investigate. (5-6 megabytes per day)
I'll have to make some graphs. The ballpark is several microseconds of
noise, but that's on top of your system clock offset. I think it would be
easy to see 10 microseconds of offset. You would have to work harder to see
smaller numbers.
Reminder: Your system may have troubles catching 10 microsecond PPS signals.
TAPR says "no longer available" for the FatPPS. I poked John. He was going
to see if they could build another batch.
--
These are my opinions, not necessarily my employer's. I hate spam.
kevin@rosenberg.net said:
> I'm looking for device with an external clock input as well as inputs for
> multiple PPS signals that outputs timestamped messages for each input pulse
> via RS232. ...
What sort of accuracy and/or resolution do you want/need?
> 5) Using a FreeBSD or Linux box with multiple RS-232 inputs and using their
> PPS API. However, outside of some ARM boards, I haven't found any boxes
> that can be clocked by a external reference. And, I haven't enough
> experience running FreeBSD or Linux on ARM to know how well this will work
> for me.
> 7) Use a box like in #5, and capture the PPS from the PRS-10 as well and
> using that to scale the other PPS inputs that arrive around the same time.
If you have a Linux box handy, that one is easy to try.
After the 60Hz grab-every-cycle experiment, I started collecting every-cycle
data for PPS signals. I have a box with 3 PPS signals: one from a Z3801A
and 2 from low cost GPS units.
I can send you some files if you want to investigate. (5-6 megabytes per day)
I'll have to make some graphs. The ballpark is several microseconds of
noise, but that's on top of your system clock offset. I think it would be
easy to see 10 microseconds of offset. You would have to work harder to see
smaller numbers.
Reminder: Your system may have troubles catching 10 microsecond PPS signals.
TAPR says "no longer available" for the FatPPS. I poked John. He was going
to see if they could build another batch.
--
These are my opinions, not necessarily my employer's. I hate spam.
KR
Kevin Rosenberg
Wed, Sep 28, 2011 6:50 PM
On Sep 28, 2011, at 12:19 PM, Hal Murray wrote:
What sort of accuracy and/or resolution do you want/need?
Whoops, left out that critical piece of information!
It's for my son's project, he'll be looking at deviations probably
no shorter than one 1 sec, so milliseconds will be plenty for him.
- Use a box like in #5, and capture the PPS from the PRS-10 as well and
using that to scale the other PPS inputs that arrive around the same time.
If you have a Linux box handy, that one is easy to try.
I agree. That idea was listed last because I came up with it while describing
the other options that I considered. I do have a linux box with a 4-port PCI
serial port that seems to be supported by the kernel's PPSAPI.
After the 60Hz grab-every-cycle experiment, I started collecting every-cycle
data for PPS signals. I have a box with 3 PPS signals: one from a Z3801A
and 2 from low cost GPS units.
I can send you some files if you want to investigate. (5-6 megabytes per day)
Thanks, I would be interested. One of the PPS signals will be 60 Hz mains, but
probably will use two ICs to divide it by 60 to simplify the analysis for him
and keep all his signals nominally 1 Hz.
I'll have to make some graphs. The ballpark is several microseconds of
noise, but that's on top of your system clock offset. I think it would be
easy to see 10 microseconds of offset. You would have to work harder to see
smaller numbers.
That'd be more than enough resolution for him. The main thing I was hoping for
was something simple to use, without much construction, so that he can do the
project himself.
Reminder: Your system may have troubles catching 10 microsecond PPS signals.
TAPR says "no longer available" for the FatPPS. I poked John. He was going
to see if they could build another batch.
Your quite right about the PRS-10 PPS pulse, 10 us was obviously too fast for the
Soekris with a kernel timing frequency of 1000 Hz. I wasn't aware that FatPPS
had gone "no longer available". Makes me glad that I got mine last year along
with a TADD-1 which was also discontinued. That was considerate of you to mention
it to John to assist others who have such brief PPS pulses.
Thanks the great thoughts, Hal!
Kevin
On Sep 28, 2011, at 12:19 PM, Hal Murray wrote:
> What sort of accuracy and/or resolution do you want/need?
Whoops, left out that critical piece of information!
It's for my son's project, he'll be looking at deviations probably
no shorter than one 1 sec, so milliseconds will be plenty for him.
>> 7) Use a box like in #5, and capture the PPS from the PRS-10 as well and
>> using that to scale the other PPS inputs that arrive around the same time.
>
> If you have a Linux box handy, that one is easy to try.
I agree. That idea was listed last because I came up with it while describing
the other options that I considered. I do have a linux box with a 4-port PCI
serial port that seems to be supported by the kernel's PPSAPI.
> After the 60Hz grab-every-cycle experiment, I started collecting every-cycle
> data for PPS signals. I have a box with 3 PPS signals: one from a Z3801A
> and 2 from low cost GPS units.
>
> I can send you some files if you want to investigate. (5-6 megabytes per day)
Thanks, I would be interested. One of the PPS signals will be 60 Hz mains, but
probably will use two ICs to divide it by 60 to simplify the analysis for him
and keep all his signals nominally 1 Hz.
> I'll have to make some graphs. The ballpark is several microseconds of
> noise, but that's on top of your system clock offset. I think it would be
> easy to see 10 microseconds of offset. You would have to work harder to see
> smaller numbers.
That'd be more than enough resolution for him. The main thing I was hoping for
was something simple to use, without much construction, so that he can do the
project himself.
> Reminder: Your system may have troubles catching 10 microsecond PPS signals.
> TAPR says "no longer available" for the FatPPS. I poked John. He was going
> to see if they could build another batch.
Your quite right about the PRS-10 PPS pulse, 10 us was obviously too fast for the
Soekris with a kernel timing frequency of 1000 Hz. I wasn't aware that FatPPS
had gone "no longer available". Makes me glad that I got mine last year along
with a TADD-1 which was also discontinued. That was considerate of you to mention
it to John to assist others who have such brief PPS pulses.
Thanks the great thoughts, Hal!
Kevin
CA
Chris Albertson
Wed, Sep 28, 2011 7:21 PM
On Sep 28, 2011, at 12:19 PM, Hal Murray wrote:
What sort of accuracy and/or resolution do you want/need?
Whoops, left out that critical piece of information!
It's for my son's project, he'll be looking at deviations probably
no shorter than one 1 sec, so milliseconds will be plenty for him.
Milliseconds? So why are we talking about HP counters and PicTic and
so on. A basic low end Linux system that is controlled by NTP and a
GPS receiver is maybe about 100X better than your requirements.
(I figure you are looking for about 1000 parts per million, NTP is way
better then that if you have a local GPS)
Chris Albertson
Redondo Beach, California
On Wed, Sep 28, 2011 at 11:50 AM, Kevin Rosenberg <kevin@rosenberg.net> wrote:
> On Sep 28, 2011, at 12:19 PM, Hal Murray wrote:
>> What sort of accuracy and/or resolution do you want/need?
>
> Whoops, left out that critical piece of information!
> It's for my son's project, he'll be looking at deviations probably
> no shorter than one 1 sec, so milliseconds will be plenty for him.
Milliseconds? So why are we talking about HP counters and PicTic and
so on. A basic low end Linux system that is controlled by NTP and a
GPS receiver is maybe about 100X better than your requirements.
(I figure you are looking for about 1000 parts per million, NTP is way
better then that if you have a local GPS)
Chris Albertson
Redondo Beach, California
KR
Kevin Rosenberg
Wed, Sep 28, 2011 7:56 PM
On Sep 28, 2011, at 1:21 PM, Chris Albertson wrote:
Milliseconds? So why are we talking about HP counters and PicTic and
so on. A basic low end Linux system that is controlled by NTP and a
GPS receiver is maybe about 100X better than your requirements.
(I figure you are looking for about 1000 parts per million, NTP is way
better then that if you have a local GPS)
Heh! I suppose milliseconds don't really belong on time nuts, they're in
the range of polling! But, for his needs, that's sufficient resolution.
What would be nice is if the PPS times would just "show up" log file for
him. Hence, the request about off-the-shelf hardware.
But, as long as I'll be looking at buying some new hardware, I'd be glad to get
resolution of nanoseconds or better. Probably best sigma for the price will be
the XMega with 32 MHz input from Clockbox with a sigma of 31ns. I've written more
than my share of microcontroller firmwares. But, I feel strongly that he should do
as much of the project as he can himself. So, I'll be teaching him some more C,
but I'd like that at around the level of GPIB programming and fprintf rather than
low-level XMega or other micro-controller programming.
So, if there was a way for the 53230A to do this, it sure would have a pretty
display that he'd like (and a 20 ps single-shot resolution that I'd like).
Yes, I have some thunderbolts that I've used with some Soekris net4501's+nonoBSD
and they're great. But, he's keen on using an the PRS-10 for his reference
clock. Something about the term "atomic", I'm sure. And, since we're just talking
milliseconds(!) over a month or so, then the PRS-10 will do well without any
GPS disciplining.
Kevin
On Sep 28, 2011, at 1:21 PM, Chris Albertson wrote:
> Milliseconds? So why are we talking about HP counters and PicTic and
> so on. A basic low end Linux system that is controlled by NTP and a
> GPS receiver is maybe about 100X better than your requirements.
> (I figure you are looking for about 1000 parts per million, NTP is way
> better then that if you have a local GPS)
Heh! I suppose milliseconds don't really belong on time nuts, they're in
the range of polling! But, for his needs, that's sufficient resolution.
What would be nice is if the PPS times would just "show up" log file for
him. Hence, the request about off-the-shelf hardware.
But, as long as I'll be looking at buying some new hardware, I'd be glad to get
resolution of nanoseconds or better. Probably best sigma for the price will be
the XMega with 32 MHz input from Clockbox with a sigma of 31ns. I've written more
than my share of microcontroller firmwares. But, I feel strongly that he should do
as much of the project as he can himself. So, I'll be teaching him some more C,
but I'd like that at around the level of GPIB programming and fprintf rather than
low-level XMega or other micro-controller programming.
So, if there was a way for the 53230A to do this, it sure would have a pretty
display that he'd like (and a 20 ps single-shot resolution that I'd like).
Yes, I have some thunderbolts that I've used with some Soekris net4501's+nonoBSD
and they're great. But, he's keen on using an the PRS-10 for his reference
clock. Something about the term "atomic", I'm sure. And, since we're just talking
milliseconds(!) over a month or so, then the PRS-10 will do well without any
GPS disciplining.
Kevin
BC
Bob Camp
Wed, Sep 28, 2011 9:28 PM
Hi
For milliseconds, route the signals into a hard wired parallel port (not
USB) and sample the data. Looking at it 1K times a second is pretty easy.
All software running on a tired old PC. Sync the thing up with NTP or what
ever to keep it stable long term.
Bob
-----Original Message-----
From: time-nuts-bounces@febo.com [mailto:time-nuts-bounces@febo.com] On
Behalf Of Kevin Rosenberg
Sent: Wednesday, September 28, 2011 3:56 PM
To: Discussion of precise time and frequency measurement
Subject: Re: [time-nuts] Looking for off-the-shelf device to
timestampmultiple PPS inputs
On Sep 28, 2011, at 1:21 PM, Chris Albertson wrote:
Milliseconds? So why are we talking about HP counters and PicTic and
so on. A basic low end Linux system that is controlled by NTP and a
GPS receiver is maybe about 100X better than your requirements.
(I figure you are looking for about 1000 parts per million, NTP is way
better then that if you have a local GPS)
Heh! I suppose milliseconds don't really belong on time nuts, they're in
the range of polling! But, for his needs, that's sufficient resolution.
What would be nice is if the PPS times would just "show up" log file for
him. Hence, the request about off-the-shelf hardware.
But, as long as I'll be looking at buying some new hardware, I'd be glad to
get
resolution of nanoseconds or better. Probably best sigma for the price will
be
the XMega with 32 MHz input from Clockbox with a sigma of 31ns. I've written
more
than my share of microcontroller firmwares. But, I feel strongly that he
should do
as much of the project as he can himself. So, I'll be teaching him some more
C,
but I'd like that at around the level of GPIB programming and fprintf rather
than
low-level XMega or other micro-controller programming.
So, if there was a way for the 53230A to do this, it sure would have a
pretty
display that he'd like (and a 20 ps single-shot resolution that I'd like).
Yes, I have some thunderbolts that I've used with some Soekris
net4501's+nonoBSD
and they're great. But, he's keen on using an the PRS-10 for his reference
clock. Something about the term "atomic", I'm sure. And, since we're just
talking
milliseconds(!) over a month or so, then the PRS-10 will do well without any
GPS disciplining.
Kevin
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.
Hi
For milliseconds, route the signals into a hard wired parallel port (not
USB) and sample the data. Looking at it 1K times a second is pretty easy.
All software running on a tired old PC. Sync the thing up with NTP or what
ever to keep it stable long term.
Bob
-----Original Message-----
From: time-nuts-bounces@febo.com [mailto:time-nuts-bounces@febo.com] On
Behalf Of Kevin Rosenberg
Sent: Wednesday, September 28, 2011 3:56 PM
To: Discussion of precise time and frequency measurement
Subject: Re: [time-nuts] Looking for off-the-shelf device to
timestampmultiple PPS inputs
On Sep 28, 2011, at 1:21 PM, Chris Albertson wrote:
> Milliseconds? So why are we talking about HP counters and PicTic and
> so on. A basic low end Linux system that is controlled by NTP and a
> GPS receiver is maybe about 100X better than your requirements.
> (I figure you are looking for about 1000 parts per million, NTP is way
> better then that if you have a local GPS)
Heh! I suppose milliseconds don't really belong on time nuts, they're in
the range of polling! But, for his needs, that's sufficient resolution.
What would be nice is if the PPS times would just "show up" log file for
him. Hence, the request about off-the-shelf hardware.
But, as long as I'll be looking at buying some new hardware, I'd be glad to
get
resolution of nanoseconds or better. Probably best sigma for the price will
be
the XMega with 32 MHz input from Clockbox with a sigma of 31ns. I've written
more
than my share of microcontroller firmwares. But, I feel strongly that he
should do
as much of the project as he can himself. So, I'll be teaching him some more
C,
but I'd like that at around the level of GPIB programming and fprintf rather
than
low-level XMega or other micro-controller programming.
So, if there was a way for the 53230A to do this, it sure would have a
pretty
display that he'd like (and a 20 ps single-shot resolution that I'd like).
Yes, I have some thunderbolts that I've used with some Soekris
net4501's+nonoBSD
and they're great. But, he's keen on using an the PRS-10 for his reference
clock. Something about the term "atomic", I'm sure. And, since we're just
talking
milliseconds(!) over a month or so, then the PRS-10 will do well without any
GPS disciplining.
Kevin
_______________________________________________
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.
KR
Kevin Rosenberg
Wed, Sep 28, 2011 11:20 PM
Hi Bob,
That's a fine solution that wins on re-use of old PC's and scalability of inputs.
Obviously over the course of days, NTP is superior to an Rb clock, but my son
really wants to use the Rb for reference time. I suppose we could read the PPS
from the Rb to compare to the other two PPS lines, though. Could be a winner.
In fact, if don't use NTP to discipline the local clock, we can use the local clock
as a measurement of a the stability of a quartz oscillator for his project.
Not having used counters much, I'm a little surprised they can't do continuous
logging. I suppose their strengths, though, are in triggering and gating.
Kevin
Sent from my iPad
On Sep 28, 2011, at 3:28 PM, "Bob Camp" lists@rtty.us wrote:
Hi
For milliseconds, route the signals into a hard wired parallel port (not
USB) and sample the data. Looking at it 1K times a second is pretty easy.
All software running on a tired old PC. Sync the thing up with NTP or what
ever to keep it stable long term.
Bob
-----Original Message-----
From: time-nuts-bounces@febo.com [mailto:time-nuts-bounces@febo.com] On
Behalf Of Kevin Rosenberg
Sent: Wednesday, September 28, 2011 3:56 PM
To: Discussion of precise time and frequency measurement
Subject: Re: [time-nuts] Looking for off-the-shelf device to
timestampmultiple PPS inputs
On Sep 28, 2011, at 1:21 PM, Chris Albertson wrote:
Milliseconds? So why are we talking about HP counters and PicTic and
so on. A basic low end Linux system that is controlled by NTP and a
GPS receiver is maybe about 100X better than your requirements.
(I figure you are looking for about 1000 parts per million, NTP is way
better then that if you have a local GPS)
Heh! I suppose milliseconds don't really belong on time nuts, they're in
the range of polling! But, for his needs, that's sufficient resolution.
What would be nice is if the PPS times would just "show up" log file for
him. Hence, the request about off-the-shelf hardware.
But, as long as I'll be looking at buying some new hardware, I'd be glad to
get
resolution of nanoseconds or better. Probably best sigma for the price will
be
the XMega with 32 MHz input from Clockbox with a sigma of 31ns. I've written
more
than my share of microcontroller firmwares. But, I feel strongly that he
should do
as much of the project as he can himself. So, I'll be teaching him some more
C,
but I'd like that at around the level of GPIB programming and fprintf rather
than
low-level XMega or other micro-controller programming.
So, if there was a way for the 53230A to do this, it sure would have a
pretty
display that he'd like (and a 20 ps single-shot resolution that I'd like).
Yes, I have some thunderbolts that I've used with some Soekris
net4501's+nonoBSD
and they're great. But, he's keen on using an the PRS-10 for his reference
clock. Something about the term "atomic", I'm sure. And, since we're just
talking
milliseconds(!) over a month or so, then the PRS-10 will do well without any
GPS disciplining.
Kevin
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.
Hi Bob,
That's a fine solution that wins on re-use of old PC's and scalability of inputs.
Obviously over the course of days, NTP is superior to an Rb clock, but my son
really wants to use the Rb for reference time. I suppose we could read the PPS
from the Rb to compare to the other two PPS lines, though. Could be a winner.
In fact, if don't use NTP to discipline the local clock, we can use the local clock
as a measurement of a the stability of a quartz oscillator for his project.
Not having used counters much, I'm a little surprised they can't do continuous
logging. I suppose their strengths, though, are in triggering and gating.
Kevin
Sent from my iPad
On Sep 28, 2011, at 3:28 PM, "Bob Camp" <lists@rtty.us> wrote:
> Hi
>
> For milliseconds, route the signals into a hard wired parallel port (not
> USB) and sample the data. Looking at it 1K times a second is pretty easy.
> All software running on a tired old PC. Sync the thing up with NTP or what
> ever to keep it stable long term.
>
> Bob
>
> -----Original Message-----
> From: time-nuts-bounces@febo.com [mailto:time-nuts-bounces@febo.com] On
> Behalf Of Kevin Rosenberg
> Sent: Wednesday, September 28, 2011 3:56 PM
> To: Discussion of precise time and frequency measurement
> Subject: Re: [time-nuts] Looking for off-the-shelf device to
> timestampmultiple PPS inputs
>
> On Sep 28, 2011, at 1:21 PM, Chris Albertson wrote:
>> Milliseconds? So why are we talking about HP counters and PicTic and
>> so on. A basic low end Linux system that is controlled by NTP and a
>> GPS receiver is maybe about 100X better than your requirements.
>> (I figure you are looking for about 1000 parts per million, NTP is way
>> better then that if you have a local GPS)
>
>
> Heh! I suppose milliseconds don't really belong on time nuts, they're in
> the range of polling! But, for his needs, that's sufficient resolution.
> What would be nice is if the PPS times would just "show up" log file for
> him. Hence, the request about off-the-shelf hardware.
>
> But, as long as I'll be looking at buying some new hardware, I'd be glad to
> get
> resolution of nanoseconds or better. Probably best sigma for the price will
> be
> the XMega with 32 MHz input from Clockbox with a sigma of 31ns. I've written
> more
> than my share of microcontroller firmwares. But, I feel strongly that he
> should do
> as much of the project as he can himself. So, I'll be teaching him some more
> C,
> but I'd like that at around the level of GPIB programming and fprintf rather
> than
> low-level XMega or other micro-controller programming.
>
> So, if there was a way for the 53230A to do this, it sure would have a
> pretty
> display that he'd like (and a 20 ps single-shot resolution that I'd like).
>
> Yes, I have some thunderbolts that I've used with some Soekris
> net4501's+nonoBSD
> and they're great. But, he's keen on using an the PRS-10 for his reference
> clock. Something about the term "atomic", I'm sure. And, since we're just
> talking
> milliseconds(!) over a month or so, then the PRS-10 will do well without any
> GPS disciplining.
>
> Kevin
>
>
> _______________________________________________
> 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.
CA
Chris Albertson
Wed, Sep 28, 2011 11:46 PM
Hi Bob,
That's a fine solution that wins on re-use of old PC's and scalability of inputs.
Obviously over the course of days, NTP is superior to an Rb clock, but my son
really wants to use the Rb for reference time. I suppose we could read the PPS
from the Rb to compare to the other two PPS lines, though. Could be a winner.
In fact, if don't use NTP to discipline the local clock, we can use the local clock
as a measurement of a the stability of a quartz oscillator for his project.
Not having used counters much, I'm a little surprised they can't do continuous
logging. I suppose their strengths, though, are in triggering and gating.
Counters will not log the time of a pulse but they will continuously
measure time intervals. And the interval might be "time from the
last tick ofthe second." So you 'd use the Rb's PPS to trigger the
"start" channel and the device under test to trigger the "stop"
channel. the counter measures the time difference. You don't care
what the difference is but only how it changes over time. If the
pulses are going at different rates you will see the times get longer
and long and then very short. later you figure out the "beat
frequency" and then you have the rate of the DUT.
A Thunderbolt will do as well as Rb.
Chris Albertson
Redondo Beach, California
On Wed, Sep 28, 2011 at 4:20 PM, Kevin Rosenberg <kevin@rosenberg.net> wrote:
> Hi Bob,
>
> That's a fine solution that wins on re-use of old PC's and scalability of inputs.
> Obviously over the course of days, NTP is superior to an Rb clock, but my son
> really wants to use the Rb for reference time. I suppose we could read the PPS
> from the Rb to compare to the other two PPS lines, though. Could be a winner.
> In fact, if don't use NTP to discipline the local clock, we can use the local clock
> as a measurement of a the stability of a quartz oscillator for his project.
>
> Not having used counters much, I'm a little surprised they can't do continuous
> logging. I suppose their strengths, though, are in triggering and gating.
Counters will not log the time of a pulse but they will continuously
measure time intervals. And the interval might be "time from the
last tick ofthe second." So you 'd use the Rb's PPS to trigger the
"start" channel and the device under test to trigger the "stop"
channel. the counter measures the time difference. You don't care
what the difference is but only how it changes over time. If the
pulses are going at different rates you will see the times get longer
and long and then very short. later you figure out the "beat
frequency" and then you have the rate of the DUT.
A Thunderbolt will do as well as Rb.
Chris Albertson
Redondo Beach, California
KR
Kevin Rosenberg
Thu, Sep 29, 2011 12:10 AM
On Sep 28, 2011, at 5:46 PM, Chris Albertson wrote:
Counters will not log the time of a pulse but they will continuously
measure time intervals. And the interval might be "time from the
last tick ofthe second." So you 'd use the Rb's PPS to trigger the
"start" channel and the device under test to trigger the "stop"
channel. the counter measures the time difference. You don't care
what the difference is but only how it changes over time. If the
pulses are going at different rates you will see the times get longer
and long and then very short. later you figure out the "beat
frequency" and then you have the rate of the DUT.
Thanks, Chris, that makes sense. I considered recommending my DTS-2077
using a phase difference method like that. But, one of the goals is
to count all PPS cycles, not just the rate of the DUT, especially if one
of the oscillators is less stable than expected.
A Thunderbolt will do as well as Rb.
For timing purposes, sure. In the thread, also talked about the benefits
of NTP. Nonetheless, my son wants to use the Rb and (more importantly)
understand some of the physics of the Rb. So, while the Rb as a long-term
reference isn't as good as NTP +/- Thunderbolt, it intrigues him.
That's good enough for me to help him with his goal.
Kevin
On Sep 28, 2011, at 5:46 PM, Chris Albertson wrote:
> Counters will not log the time of a pulse but they will continuously
> measure time intervals. And the interval might be "time from the
> last tick ofthe second." So you 'd use the Rb's PPS to trigger the
> "start" channel and the device under test to trigger the "stop"
> channel. the counter measures the time difference. You don't care
> what the difference is but only how it changes over time. If the
> pulses are going at different rates you will see the times get longer
> and long and then very short. later you figure out the "beat
> frequency" and then you have the rate of the DUT.
Thanks, Chris, that makes sense. I considered recommending my DTS-2077
using a phase difference method like that. But, one of the goals is
to count all PPS cycles, not just the rate of the DUT, especially if one
of the oscillators is less stable than expected.
> A Thunderbolt will do as well as Rb.
For timing purposes, sure. In the thread, also talked about the benefits
of NTP. Nonetheless, my son wants to use the Rb and (more importantly)
understand some of the physics of the Rb. So, while the Rb as a long-term
reference isn't as good as NTP +/- Thunderbolt, it intrigues him.
That's good enough for me to help him with his goal.
Kevin
KR
Kevin Rosenberg
Mon, Oct 3, 2011 6:06 PM
Thank you to everyone for their thought answers and insights, they gave
me some great ideas. I was thinking about the parallel port polling idea,
but then my son wanted to measure the relation between temperature and XO
frequency, so we needed microsecond resolution.
tvb came up with just the perfect solution:
- Cheap, $5 per part
- Easy for my son to construct, an 8-pin PIC and a bypass capacitor for
each PPS line
- Easy to analyze results, one ASCII text line for each input pulse
- Continuously counting indefinitely
- sub-microsecond resolution (useful for measuring tempc for an XO)
Thanks again to everyone for their good thoughts and valuable time
spent considering my question.
Kevin
Thank you to everyone for their thought answers and insights, they gave
me some great ideas. I was thinking about the parallel port polling idea,
but then my son wanted to measure the relation between temperature and XO
frequency, so we needed microsecond resolution.
tvb came up with just the perfect solution:
- Cheap, $5 per part
- Easy for my son to construct, an 8-pin PIC and a bypass capacitor for
each PPS line
- Easy to analyze results, one ASCII text line for each input pulse
- Continuously counting indefinitely
- sub-microsecond resolution (useful for measuring tempc for an XO)
Thanks again to everyone for their good thoughts and valuable time
spent considering my question.
Kevin
TV
Tom Van Baak
Mon, Oct 3, 2011 7:54 PM
Hal, Don,
I too have tried all the PC-based (serial/parallel port) solutions.
As we discussed at lot with the TEC thread, they work pretty
well. But for general use, or stand-alone operation, what I use
for dirt cheap non-nanosecond timing is a TBolt-10MHz-driven
isochronous microcontroller.
tvb came up with just the perfect solution:
Hal, Don,
I too have tried all the PC-based (serial/parallel port) solutions.
As we discussed at lot with the TEC thread, they work pretty
well. But for general use, or stand-alone operation, what I use
for dirt cheap non-nanosecond timing is a TBolt-10MHz-driven
isochronous microcontroller.
> tvb came up with just the perfect solution:
Details here:
http://www.leapsecond.com/pic/picpet.htm
/tvb