t...@leapsecond.com said:
Realize this is all just for fun. TEC should have zero impact on modern
computer networks.
It will be interesting to see how much gear there is out there that derives
time keeping from the line frequency.
I suspect a lot of it doesn't matter much at the
At 01:31 PM 6/28/2011, Tom Van Baak wrote:
I'm planning on counting 60Hz line cycles with some embedded
hardware, then dumping the count over RS-232 every minute or so to
a linux box running ntp. Any thoughts on what data to log?
Scott,
You have a PC and RS232? Skip the embedded hardware.
On Thu, Jun 30, 2011 at 8:12 AM, Scott Newell new...@cei.net wrote:
Any advice on an easy way to convert my timestampts from time_t to mjd? I'm
using C here.
If disk space is a problem I'd keep the log in binary format. Better
use zlib and compress the binary data before it reaches the disk.
Any advice on an easy way to convert my timestampts from time_t to mjd?
I'm using C here.
It's trivial. All you have to do is offset by the difference in starting
days.
MJD is usually printed as an integer rather than year-month-day format. (My
sample is tiny so that could easily be
At 01:24 PM 6/30/2011, Hal Murray wrote:
Any advice on an easy way to convert my timestampts from time_t to mjd?
I'm using C here.
It's trivial. All you have to do is offset by the difference in starting
days.
Got it working. Thanks!
--
newell N5TNL
: [time-nuts] TEC party file format?
The Linux or BSD pulse per second interface is general enough to work for this.
It does not care if the pulses are one per second or 100 per second, or 60.
Al it does it capture a timmer/counter when a pulse comes in. Then
fets a flag a user program can read
albertson.ch...@gmail.com
To: Discussion of precise time and frequency measurement
time-nuts@febo.com
Sent: Tuesday, June 28, 2011 4:06 PM
Subject: Re: [time-nuts] TEC party file format?
The Linux or BSD pulse per second interface is general enough to work for
this.
It does not care
: Tom Van Baak t...@leapsecond.com
To: Discussion of precise time and frequency measurement time-nuts@febo.com
Sent: Wed, June 29, 2011 7:53:43 AM
Subject: Re: [time-nuts] TEC party file format?
Chris,
Sounds good. Somebody that's interested or knows NTP (not me)
can be the first to set up a mains
Al it does it capture a timmer/counter when a pulse comes in. Then fets a
flag a user program can read that says data available. The user level
programs reads the device ad gets the captured counter value, the flag is
reset. Very simple and very low overhead.
How does the pulse trigger the
How does the pulse trigger the capture ? If some hardware line is polled,
how frequent is that polling ? The counter units may well be nanoseconds,
but the inherent uncertainty of the polling instant must be taken into
account.
If instead there is no polling, but it is a hardware
On Wed, Jun 29, 2011 at 10:54 AM, Hal Murray hmur...@megapathdsl.net wrote:
How does the pulse trigger the capture ? If some hardware line is polled,
how frequent is that polling ? The counter units may well be nanoseconds,
but the inherent uncertainty of the polling instant must be taken into
How does the pulse trigger the capture ? If some hardware line is
polled,
how frequent is that polling ? The counter units may well be
nanoseconds,
but the inherent uncertainty of the polling instant must be taken into
account.
If instead there is no polling, but it is a hardware
I suspect all of this happens MUCH faster then you could implement
using 7400 series TTL logic. The 5ns gate delay of a TTL chip is an
eternity for a modern CPU. Even for me who works with computers
We may be getting OT, but this assertion can't be true. If you
factor in all the things
.
/tvb
- Original Message -
From: Mark Spencer mspencer12...@yahoo.ca
To: Discussion of precise time and frequency measurement time-nuts@febo.com
Sent: Wednesday, June 29, 2011 9:55 AM
Subject: Re: [time-nuts] TEC party file format?
I thought I would try simply feeding a 60 Hz signal
b...@lysator.liu.se said:
It can be done entirely from user space as well.
/* wait till a serial port status change interrupt is generated */
if (ioctl(fd, TIOCMIWAIT, TIOCM_CD | TIOCM_CTS | TIOCM_DSR)!=0)
Yup. gpsd uses it. As far as I know, it's only available on Linux. I can't
I'm planning on counting 60Hz line cycles with some embedded
hardware, then dumping the count over RS-232 every minute or so to a
linux box running ntp. Any thoughts on what data to log?
Obviously, the 60 Hz cycle counter.
Timestamp when data was received at the serial port? (It looks like
I'm planning on counting 60Hz line cycles with some embedded
hardware, then dumping the count over RS-232 every minute or so to a
linux box running ntp. Any thoughts on what data to log?
Scott,
You have a PC and RS232? Skip the embedded hardware.
An easy trick is to convert the 60 Hz
On Tue, Jun 28, 2011 at 11:31 AM, Tom Van Baak t...@leapsecond.com wrote:
I'm planning on counting 60Hz line cycles with some embedded hardware,
then dumping the count over RS-232 every minute or so to a linux box running
ntp. Any thoughts on what data to log?
Scott,
You have a PC and
Coming into this late so I have a very basic question. What level if
resolution is required? Are variations in the line frequency
expected to be at the 1% level or is this parts per million?Can we
measure the frequency by averaging many cycles or are we looking for
transients where the
You can do even better. Connect the pulse to pin one (DTR?) This is
the same pin used for the PPS from a GPS unit. The Linux (or BSD)
...
Chris,
Then the next step is to use an NTP driver that treats the
60 Hz pulses on DTR as the local time/frequency reference.
Your PC will then run on
Then the next step is to use an NTP driver that treats the 60 Hz pulses on
DTR as the local time/frequency reference. Your PC will then run on mains
time instead of UTC. Not sure how low a stratum that would be. Still, if
you did this, then your existing NTP tools will give you all the
I don't think any of the current drivers in NTP will do the right thing for
this project.
The PPS driver is a bit tricky. It needs help to figure out which second a
pulse corresponds to. I think there is a filter in there to reject samples
that are too far off from what it thinks is a
So the PC itself becomes your frequency counter, with NTP providing the
long-term timebase stability you need.
Mains cycles-per-second become RS232 bytes-per-second. You will get, on
average, 60 bytes per second. At the end of a perfect day you would have
read 5184000 characters. In Europe,
I see two interesting problems with this sort of approach.
One is glitches on the line, either lightning/whatever causing extra counts,
or dropouts causing missed cycles. Does anybody know how often this sort of
stuff happens? Does anybody have scope pictures?
The beauty of time-stamping
How does NTP handle the cases where an accurate 1PPS is available but the
time itself isn't? This would be the case for most cesium or OCXO
references, or maybe even some GPS 1PPS references.
You need to get the rough time from some other source, say the network or
from GPS via the serial
The Linux or BSD pulse per second interface is general enough to work for this.
It does not care if the pulses are one per second or 100 per second, or 60.
Al it does it capture a timmer/counter when a pulse comes in. Then
fets a flag a user program can read that says data available. The
user
If I have a day of good data, then a break, then more good data, how long can
the break be so that I can correctly guess the number of cycles that were
missed? It depends upon how much the frequency changes. If I extrapolate
forward from before the break and back from after, the lines will
The Linux or BSD pulse per second interface is general enough to work for
this. It does not care if the pulses are one per second or 100 per second,
or 60.
Al it does it capture a timmer/counter when a pulse comes in. Then fets a
flag a user program can read that says data available. The
28 matches
Mail list logo
