I think that we maybe in danger of comparing gr=
apes=20
with bananas, if we are not careful. There is a fixed cycle time for the=20
interrupt polling in a computer, both for the communications interface and f=
or=20
the program switching. Your multi tasking computer still only runs one progr=
am=20
at a time - it just looks more capable since every cycle it polls a list to=20
determine which are active. On one of the old IBM type computers that I=
=20
checked, this was about every 10 milli sec, but it is likely to be more=
=20
frequent on the current offerings. There are also different levels of interr=
upt=20
priority.
Then there are network response delays and digi=
tal=20
transmission delays. Local phone networks are likely to be more accurat=
e. I=20
have measured transmission delays of 3 sec from the NIST clock over the inte=
rnet=20
to the 60 KHz radio time, but that was exceptional. The on line clock s=
eems=20
to have stated error bands of 0.5 to over 1.5 sec.
I asked Steve what was the absolute accuracy th=
at=20
he had measured over the network time servers, but he didn't seem to fully=20
understand my question. I quite believe that his own internal GPS network ca=
n=20
detect a 1 mS error, but this is not an=20
indication of how badly the network time servers and the=20
communications programs are performing in practice.
<=
FONT=20
style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000 size=
=3D2>If you=20
don't have a GPS, as I said, the software comes with an extensive
list=20=
of=20
network time servers that can be accessed via the Internet to=20
obtain
accurate time. Overall, the experience with this software packag=
e=20
has been
very positive and after 30-days of testing I'm now recommendin=
g it=20
to other
members of the Public Seismic Network.
Does it give any timing accuracies in mill=
i=20
seconds for the various time servers?
We do need to get a reasonable approximati=
on=20
to Universal Time, say better than 0.1 sec and this needs to be maintained=20
at all times. We also need to remember that o=
ur=20
filters can give very significant delays. A 6 pole 10 Hz Butterworth filter=20
peaks at about 100 mS. A 6 pole 10 Hz Bessel gives about 40 mS. However, if=20=
you=20
reduce the cut-off to 1.5 Hz, the figures are about 500 and 260 mS respectiv=
ely.=20
Part of this difference is the result of defining the cut-off as the 3=20=
dB=20
point, rather than matching up the ultimate slopes. The P waves may roll in=20=
at=20
~10 Km / sec.
We wouldn't be having this discussion if comput=
ers=20
were fitted with reasonably accurate clocks. The 4.194 MHz timing crystals c=
an=20
be trimmed to a few seconds per fortnight, but high precision temperature=20
tracking modules can give 0.1 ppm. The lousy apology for a clock fitted=
to=20
my current computer has drifted 8 sec in the last 2 hours. Even hourly updat=
es=20
would not give me anywhere near=20
the precision required. You used to be able to buy boards with clo=
ck=20
modules on them, but I haven't seen any about lately.
Since you can get 60 KHz receiver modues and=20
aerials, it would be helpful if A/D boards were able to read and update thei=
r=20
clocks directly using WWVB signals. This should be maybe 1/3 the cost o=
f a=20
GPS system and you would not be dependant on having a permanent phone=20
connection.
Regards,
Chris=20
Chapman
Subject: RE: Network time standard
From: "Steve Hammond" shammon1@.............
Date: Sat, 9 Apr 2005 23:30:52 -0700
Hi Chris, sorry for note being more direct.
>> Does it give any timing accuracies in milli seconds for the various
time servers?
To answer your question, no it does not. The best analysis I could provide
you was within a few milliseconds which I know is not that accurate and that
was by estimating and deduction as I stated. The software does not provide
a means for that level of analysis. However, if you read the help file I
attached, you will see that it attempts to determine the network delay and
adjust the clock accordingly. It would be nice if the software posted the
information or facilitated a means to measure it. But it does not.
Once again I will state, because I'm certain you don't understand, this
software package is a simple network time standard for keeping "all" the
systems on your network in time. I now realized that any confusion is due to
my weak usage statement. I think you believed that I intended the software
to provide a detailed time standard for a seismic system without a GPS. I
did not. I originally stated that the software was compatible with WinSDR
using a Motorola GPS for providing a time standard for the PC's in your
network. It has solved all my network time issues with having file dates and
times over/under and even days off and I'm very happy with its compatibility
with WinSDR. That's why I think it does the job.
In reading your analysis below, I have to agree with you that the PC
hardware impact the results and my experience tells me that every PC has
been different and will drift accordingly. In the past, I used Right Time
which had a self learning feature to help resolve PC clock drift. It
accuracy was close, but no banana... When I converted to WinSDR, I thought I
would use the HP 58503A. It has a frequency accuracy when locked to better
than 1 X 10 to the -12th for a one day average from 0 to 50 degrees C.
However, because of software incompatibility, when I configured the system
to use this hardware time standard and the GPScon software to set the system
clock, I was forced to configure WinSDR to use the system clock to obtain
event timing. I found that the timing of the event files were drifting so
badly that the data was unusable. The best solution I have found is to use
an internally connected Motorola GPS, Larry's hardware package and WinSDR
because it time stamps the data before it reaches the PC. Once I installed
the Motorola GPS as Larry suggested I didn't have too many time issues with
the seismic data. However occasionally for some unknown reason, the WinSDR
software gets set to ADD mode and adds 4 or 5 min. to the data. I need to
read the manual and see what I'm doing wrong. I must be hitting a button or
somewhere along the way. But when its working correctly, the data timing is
much better than anything I've ever used before. If you are interested in
its accuracy, I know that Larry has done some work in this area and can
provide the details.
Again, sorry for any confusion I may have caused you, but I'm really happy
with Net Time and its operational stability. I highly recommend it.
Regards, Steve Hammond Aptos CA
Public Seismic Network San Jose
http://www.publicseismicnetwork.com
-----Original Message-----
From: psn-l-request@.............. [mailto:psn-l-request@.................
Behalf Of ChrisAtUpw@.......
Sent: Saturday, April 09, 2005 9:15 PM
To: psn-l@..............
Subject: Re: Network time standard
In a message dated 10/04/2005, shammon1@............. writes:
My experience when working for TrueTime (Now a division of Symmetricom)
was that you could achieve 10 milliseconds or so if the server was not too
far away on the public internet. If you run a local time service on your
own network, the timing is much better than that. It usually takes several
messages to get there due to the filtering. Also, true NTP will perform
much better if you give it more than one server to work with. The software
makes some attempt to evaluate the stability of each source and choose the
best.
Hi Keith,
I think that we maybe in danger of comparing grapes with bananas, if
we are not careful. There is a fixed cycle time for the interrupt polling in
a computer, both for the communications interface and for the program
switching. Your multi tasking computer still only runs one program at a
time - it just looks more capable since every cycle it polls a list to
determine which are active. On one of the old IBM type computers that I
checked, this was about every 10 milli sec, but it is likely to be more
frequent on the current offerings. There are also different levels of
interrupt priority.
Then there are network response delays and digital transmission
delays. Local phone networks are likely to be more accurate. I have measured
transmission delays of 3 sec from the NIST clock over the internet to the 60
KHz radio time, but that was exceptional. The on line clock seems to have
stated error bands of 0.5 to over 1.5 sec.
I asked Steve what was the absolute accuracy that he had measured over
the network time servers, but he didn't seem to fully understand my
question. I quite believe that his own internal GPS network can detect a 1
mS error, but this is not an indication of how badly the network time
servers and the communications programs are performing in practice.
If you don't have a GPS, as I said, the software comes with an extensive
list of network time servers that can be accessed via the Internet to
obtain
accurate time. Overall, the experience with this software package has
been
very positive and after 30-days of testing I'm now recommending it to
other
members of the Public Seismic Network.
Does it give any timing accuracies in milli seconds for the various
time servers?
We do need to get a reasonable approximation to Universal Time, say
better than 0.1 sec and this needs to be maintained at all times. We also
need to remember that our filters can give very significant delays. A 6 pole
10 Hz Butterworth filter peaks at about 100 mS. A 6 pole 10 Hz Bessel gives
about 40 mS. However, if you reduce the cut-off to 1.5 Hz, the figures are
about 500 and 260 mS respectively. Part of this difference is the result of
defining the cut-off as the 3 dB point, rather than matching up the ultimate
slopes. The P waves may roll in at ~10 Km / sec.
We wouldn't be having this discussion if computers were fitted with
reasonably accurate clocks. The 4.194 MHz timing crystals can be trimmed to
a few seconds per fortnight, but high precision temperature tracking modules
can give 0.1 ppm. The lousy apology for a clock fitted to my current
computer has drifted 8 sec in the last 2 hours. Even hourly updates would
not give me anywhere near the precision required. You used to be able to buy
boards with clock modules on them, but I haven't seen any about lately.
Since you can get 60 KHz receiver modues and aerials, it would be
helpful if A/D boards were able to read and update their clocks directly
using WWVB signals. This should be maybe 1/3 the cost of a GPS system and
you would not be dependant on having a permanent phone connection.
Regards,
Chris Chapman
Hi Chris, sorry for note being =
more=20
direct.
>> =
Does it=20
give any timing accuracies in milli seconds for the various time =
servers?=20
To answer your question, no =
it does=20
not. The best analysis I could provide you was within a=20
few milliseconds which I know is not that accurate and that=20
was by estimating and deduction as I stated. The=20
software does not provide a means for that level =
of analysis.=20
However, if you read the help file I attached, you will see that it =
attempts to=20
determine the network delay and adjust the clock accordingly. It would =
be nice=20
if the software posted the information or facilitated a means to measure =
it. But=20
it does not.
Once again I will =
state, because=20
I'm certain you don't understand, this software package is a simple =
network=20
time standard for keeping "all" the systems on your network in time. I =
now=20
realized that any confusion is due to my weak usage statement. I =
think you=20
believed that I intended the software to provide a detailed time =
standard for a=20
seismic system without a GPS. I did not. I originally stated that the =
software=20
was compatible with WinSDR using a Motorola GPS for providing a time =
standard=20
for the PC's in your network. It has solved all my network time =
issues with=20
having file dates and times over/under and even days off and =
I'm very happy=20
with its compatibility with WinSDR. That's why I think it does the=20
job.
In reading your analysis =
below, I have=20
to agree with you that the PC hardware impact the results =
and my=20
experience tells me that every PC has been different and will =
drift=20
accordingly. In the past, I used Right Time which had a =
self=20
learning feature to help resolve PC clock drift. It accuracy was close, =
but no=20
banana... When I converted to WinSDR, I thought I would use the HP =
58503A. It=20
has a frequency accuracy when locked to better than 1 X 10 to the -12th =
for a=20
one day average from 0 to 50 degrees C. However, because of software=20
incompatibility, when I configured the system to use this hardware time =
standard=20
and the GPScon software to set the system clock, I was forced=20
to configure WinSDR to use the system clock to =
obtain event=20
timing. I found that the timing of the event files were =
drifting so=20
badly that the data was unusable. The best solution I have found is =
to=20
use an internally connected Motorola GPS, Larry's =
hardware package and=20
WinSDR because it time stamps the data before it reaches the =
PC. Once=20
I installed the Motorola GPS as Larry suggested I=20
didn't have too many time issues with the seismic data. =
However=20
occasionally for some unknown reason, the WinSDR software gets set to =
ADD mode=20
and adds 4 or 5 min. to the data. I need to read the manual and see what =
I'm=20
doing wrong. I must be hitting a button or somewhere along the way. But =
when its=20
working correctly, the data timing is much better than anything I've =
ever used=20
before. If you are interested in its accuracy, I know that Larry has =
done some=20
work in this area and can provide the details.
Again, sorry for any confusion I =
may have=20
caused you, but I'm really happy with Net Time and its operational =
stability. I=20
highly recommend it.
Regards, Steve Hammond Aptos =
CA
Public Seismic Network San=20
Jose
http://www.publicseismicnetw=
ork.com
In a message dated 10/04/2005, shammon1@............. =
writes:
My experience when working for TrueTime =
(Now a=20
division of Symmetricom) was that you could achieve 10 milliseconds =
or so if=20
the server was not too far away on the public internet. If you =
run a=20
local time service on your own network, the timing is much better =
than=20
that. It usually takes several messages to get there due to =
the=20
filtering. Also, true NTP will perform much better if you give =
it more=20
than one server to work with. The software makes some attempt =
to=20
evaluate the stability of each source and choose the=20
best.
Hi Keith,
I think that we maybe in danger of =
comparing=20
grapes with bananas, if we are not careful. There is a fixed cycle =
time for=20
the interrupt polling in a computer, both for the communications =
interface and=20
for the program switching. Your multi tasking computer still only runs =
one=20
program at a time - it just looks more capable since every cycle it =
polls a=20
list to determine which are active. On one of the old IBM type =
computers=20
that I checked, this was about every 10 milli sec, but it is likely =
to be=20
more frequent on the current offerings. There are also different =
levels of=20
interrupt priority.
Then there are network response delays =
and=20
digital transmission delays. Local phone networks are likely to =
be more=20
accurate. I have measured transmission delays of 3 sec from the NIST =
clock=20
over the internet to the 60 KHz radio time, but that was =
exceptional. The=20
on line clock seems to have stated error bands of 0.5 to over 1.5 =
sec.
I asked Steve what was the absolute =
accuracy that=20
he had measured over the network time servers, but he didn't seem to =
fully=20
understand my question. I quite believe that his own internal GPS =
network can=20
detect a 1 mS error, but this is not an=20
indication of how badly the network time servers and the =
communications programs are performing in practice.
If you don't =
have a GPS, as=20
I said, the software comes with an extensive
list of network time =
servers=20
that can be accessed via the Internet to obtain
accurate time. =
Overall,=20
the experience with this software package has been
very positive =
and=20
after 30-days of testing I'm now recommending it to other
members =
of the=20
Public Seismic Network.
Does it give any timing accuracies =
in milli=20
seconds for the various time servers?
We do need to get a reasonable =
approximation=20
to Universal Time, say better than 0.1 sec and this needs to be =
maintained=20
at all times. We also need to remember =
that our=20
filters can give very significant delays. A 6 pole 10 Hz Butterworth =
filter=20
peaks at about 100 mS. A 6 pole 10 Hz Bessel gives about 40 mS. =
However, if=20
you reduce the cut-off to 1.5 Hz, the figures are about 500 and 260 mS =
respectively. Part of this difference is the result of defining =
the=20
cut-off as the 3 dB point, rather than matching up the ultimate =
slopes. The P=20
waves may roll in at ~10 Km / sec.
We wouldn't be having this discussion if=20
computers were fitted with reasonably accurate clocks. The 4.194 MHz =
timing=20
crystals can be trimmed to a few seconds per fortnight, but high =
precision=20
temperature tracking modules can give 0.1 ppm. The lousy apology =
for a=20
clock fitted to my current computer has drifted 8 sec in the last 2 =
hours.=20
Even hourly updates would not give me anywhere=20
near the precision required. You used to be =
able to=20
buy boards with clock modules on them, but I haven't seen any about=20
lately.
Since you can get 60 KHz receiver modues =
and=20
aerials, it would be helpful if A/D boards were able to read and =
update their=20
clocks directly using WWVB signals. This should be maybe 1/3 the =
cost of=20
a GPS system and you would not be dependant on having a permanent =
phone=20
connection.
Regards,
Chris=20
Chapman
Subject: Re: Network time standard
From: ian ian@...........
Date: Sun, 10 Apr 2005 08:40:50 +0100
Hi,
an interesting discussion. I note that a spec of <0.1 seconds has been
mentioned (below). Could I ask, how is this derived? Apologies if this
is documented somewhere on the psn site.
I only ask because I know that using specs that are higher than needed
can lead to costs that could have been avoided. I guess one would start
by determining what is a reasonable error in calculating epicentre
distance that can be tolerated and working back from there to derive a
time spec.
Another question is, which of the many factors influencing epicentre
calculation is the limiting one? I would imagine that the average speed
from the epicentre to a psn station would vary from station to station
since each station is (obviously) located on a different part of the
Earth and (presumably) the wave will travel through different parts of
the Earth at a slightly different speed for each direction.
If all the psn stations were locked in time to less than 0.1 seconds,
then the average speed of the wave would have to be no worse than this
for the data to benefit. For a teleseismic event which took, say, 15
minutes to arrive, all the "rays" would have to travel at the same
average speed to within about 0.01% of each other. Is this possible?!
Ian Smith
ChrisAtUpw@....... wrote:
> In a message dated 10/04/2005, shammon1@............. writes:
>
> My experience when working for TrueTime (Now a division of
> Symmetricom) was that you could achieve 10 milliseconds or so if
> the server was not too far away on the public internet. If you
> run a local time service on your own network, the timing is much
> better than that. It usually takes several messages to get there
> due to the filtering. Also, true NTP will perform much better if
> you give it more than one server to work with. The software makes
> some attempt to evaluate the stability of each source and choose
> the best.
>
> Hi Keith,
>
> I think that we maybe in danger of comparing grapes with bananas,
> if we are not careful. There is a fixed cycle time for the interrupt
> polling in a computer, both for the communications interface and for
> the program switching. Your multi tasking computer still only runs one
> program at a time - it just looks more capable since every cycle it
> polls a list to determine which are active. On one of the old IBM type
> computers that I checked, this was about every 10 milli sec, but it is
> likely to be more frequent on the current offerings. There are also
> different levels of interrupt priority.
> Then there are network response delays and digital transmission
> delays. Local phone networks are likely to be more accurate. I have
> measured transmission delays of 3 sec from the NIST clock over the
> internet to the 60 KHz radio time, but that was exceptional. The on
> line clock seems to have stated error bands of 0.5 to over 1.5 sec.
>
> I asked Steve what was the absolute accuracy that he had measured
> over the network time servers, but he didn't seem to fully understand
> my question. I quite believe that his own internal GPS network can
> detect a 1 mS error, but this is not an indication of how badly the
> network time servers and the communications programs are performing in
> practice.
>
> If you don't have a GPS, as I said, the software comes with an
> extensive
> list of network time servers that can be accessed via the Internet
> to obtain
> accurate time. Overall, the experience with this software package
> has been
> very positive and after 30-days of testing I'm now recommending it
> to other
> members of the Public Seismic Network.
>
> Does it give any timing accuracies in milli seconds for the
> various time servers?
>
> We do need to get a reasonable approximation to Universal Time,
> say better than 0.1 sec and this needs to be maintained at all times.
> We also need to remember that our filters can give very significant
> delays. A 6 pole 10 Hz Butterworth filter peaks at about 100 mS. A 6
> pole 10 Hz Bessel gives about 40 mS. However, if you reduce the
> cut-off to 1.5 Hz, the figures are about 500 and 260 mS respectively.
> Part of this difference is the result of defining the cut-off as the 3
> dB point, rather than matching up the ultimate slopes. The P waves may
> roll in at ~10 Km / sec.
>
> We wouldn't be having this discussion if computers were fitted
> with reasonably accurate clocks. The 4.194 MHz timing crystals can be
> trimmed to a few seconds per fortnight, but high precision temperature
> tracking modules can give 0.1 ppm. The lousy apology for a clock
> fitted to my current computer has drifted 8 sec in the last 2 hours.
> Even hourly updates would not give me anywhere near the precision
> required. You used to be able to buy boards with clock modules on
> them, but I haven't seen any about lately.
>
> Since you can get 60 KHz receiver modues and aerials, it would be
> helpful if A/D boards were able to read and update their clocks
> directly using WWVB signals. This should be maybe 1/3 the cost of a
> GPS system and you would not be dependant on having a permanent phone
> connection.
>
> Regards,
>
> Chris Chapman
Hi,
an interesting discussion. I note that a spec of <0.1 seconds has
been mentioned (below). Could I ask, how is this derived? Apologies
if this is documented somewhere on the psn site.
I only ask because I know that using specs that are higher than needed
can lead to costs that could have been avoided. I guess one would
start by determining what is a reasonable error in calculating
epicentre distance that can be tolerated and working back from there to
derive a time spec.
Another question is, which of the many factors influencing epicentre
calculation is the limiting one? I would imagine that the average
speed from the epicentre to a psn station would vary from station to
station since each station is (obviously) located on a different part
of the Earth and (presumably) the wave will travel through different
parts of the Earth at a slightly different speed for each direction.
If all the psn stations were locked in time to less than 0.1 seconds,
then the average speed of the wave would have to be no worse than this
for the data to benefit. For a teleseismic event which took, say, 15
minutes to arrive, all the "rays" would have to travel at the same
average speed to within about 0.01% of each other. Is this possible?!
Ian Smith
ChrisAtUpw@....... wrote:
My experience when working
for TrueTime (Now a division of Symmetricom) was that you could achieve
10 milliseconds or so if the server was not too far away on the public
internet. If you run a local time service on your own network, the
timing is much better than that. It usually takes several messages to
get there due to the filtering. Also, true NTP will perform much
better if you give it more than one server to work with. The software
makes some attempt to evaluate the stability of each source and choose
the best.
Hi Keith,
I think that we maybe in danger of comparing grapes with
bananas, if we are not careful. There is a fixed cycle time for the
interrupt polling in a computer, both for the communications interface
and for the program switching. Your multi tasking computer still only
runs one program at a time - it just looks more capable since every
cycle it polls a list to determine which are active. On one of the old
IBM type computers that I checked, this was about every 10 milli sec,
but it is likely to be more frequent on the current offerings. There
are also different levels of interrupt priority.
Then there are network response delays and digital
transmission delays. Local phone networks are likely to be more
accurate. I have measured transmission delays of 3 sec from the NIST
clock over the internet to the 60 KHz radio time, but that was
exceptional. The on line clock seems to have stated error bands of 0.5
to over 1.5 sec.
I asked Steve what was the absolute accuracy that he had
measured over the network time servers, but he didn't seem to fully
understand my question. I quite believe that his own internal GPS
network can detect a 1 mS error, but this is not an
indication of how badly the network time servers and the
communications programs are performing in practice.
If you don't have a GPS, as I said, the software comes with
an extensive
list of network time servers that can be accessed via the Internet to
obtain
accurate time. Overall, the experience with this software package has
been
very positive and after 30-days of testing I'm now recommending it to
other
members of the Public Seismic Network.
Does it give any timing accuracies in milli seconds for the
various time servers?
We do need to get a reasonable approximation to Universal
Time, say better than 0.1 sec and this needs to be maintained at
all times. We also need to remember that our filters can
give very significant delays. A 6 pole 10 Hz Butterworth filter peaks
at about 100 mS. A 6 pole 10 Hz Bessel gives about 40 mS. However, if
you reduce the cut-off to 1.5 Hz, the figures are about 500 and 260 mS
respectively. Part of this difference is the result of defining the
cut-off as the 3 dB point, rather than matching up the ultimate slopes.
The P waves may roll in at ~10 Km / sec.
We wouldn't be having this discussion if computers were
fitted with reasonably accurate clocks. The 4.194 MHz timing crystals
can be trimmed to a few seconds per fortnight, but high precision
temperature tracking modules can give 0.1 ppm. The lousy apology for a
clock fitted to my current computer has drifted 8 sec in the last 2
hours. Even hourly updates would not give me anywhere near
the precision required. You used to be able to buy boards with clock
modules on them, but I haven't seen any about lately.
Since you can get 60 KHz receiver modues and aerials, it
would be helpful if A/D boards were able to read and update their
clocks directly using WWVB signals. This should be maybe 1/3 the cost
of a GPS system and you would not be dependant on having a permanent
phone connection.
Regards,
Chris Chapman
Subject: time issue
From: "Thomas Dick" dickthomas01@.............
Date: Sun, 10 Apr 2005 11:27:56 -0500
I have followed this discussion with interest. I used a time sync =
program before I got into seismology -- almost ten years ago. Syncing a =
local network is a lot easier than time syncing WinSDR. One of the =
drawbacks of using Internet sources to set time is that the source is =
not available all the time. Maybe, your provider isn't doing maintenance =
or isn't slowed down by heavy demand like mine is at times or the =
provider may even be shut down by viruses or mechanical problems in the =
lines or center computer breakdown. Certainly access to a time source =
will NOT be as dependable as you think.
Chris has a point, too, about the computer we use with the detection =
equipment. I doubt many of you use the newest computer to run WinSDR -- =
it is overkill. But the older computers ARE slow to multitask and their =
clocks are not that stable. I don't see Larry's GPS board that big an =
expense for the accuracy it provides plus it is easy to install.
I might also add that variations in dependability in over-the-air =
reception should be expected as well; there is day-to-night, sun spot =
interference -- even the arrival of long path-short path signals at the =
same time and place can be a problem . There is also human created noise =
such as power generators that carpenters use to power tools at =
construction sites, even legal amateur radio broadcasting, broken =
insulators on nearby power poles and by all means drift in the receivers =
being used to capture time pulses over the air.
GPS is best for no other reason that it operates in frequencies above =
the normal interferences -- it comes from straight up there -- with no =
bending over the horizon
I have followed this discussion with =
interest. I=20
used a time sync program before I got into seismology -- almost ten =
years ago.=20
Syncing a local network is a lot easier than time syncing WinSDR. One of =
the=20
drawbacks of using Internet sources to set time is that the source is =
not=20
available all the time. Maybe, your provider isn't doing maintenance or =
isn't=20
slowed down by heavy demand like mine is at times or the =
provider may=20
even be shut down by viruses or mechanical problems in the lines or =
center=20
computer breakdown. Certainly access to a time source will NOT be as =
dependable=20
as you think.
Chris has a point, too, about the =
computer we use=20
with the detection equipment. I doubt many of you use the newest =
computer=20
to run WinSDR -- it is overkill. But the older computers ARE slow to =
multitask=20
and their clocks are not that stable. I don't see Larry's GPS board that =
big an=20
expense for the accuracy it provides plus it is easy to =
install.
I might also add that variations in =
dependability=20
in over-the-air reception should be expected as well; there is =
day-to-night, sun=20
spot interference -- even the arrival of long path-short path signals at =
the=20
same time and place can be a problem . There is also human =
created=20
noise such as power generators that carpenters use to power tools at=20
construction sites, even legal amateur radio broadcasting, broken =
insulators on=20
nearby power poles and by all means drift in the receivers being =
used to=20
capture time pulses over the air.
GPS is best for no other reason that it =
operates in=20
frequencies above the normal interferences -- it comes from straight up =
there --=20
with no bending over the horizon
Subject: Re: time issue
From: Bobhelenmcclure@.......
Date: Sun, 10 Apr 2005 22:25:16 EDT
I depend indirectly on WWVB via an "atomic" wall clock for timing. I use a
DI-194 Dataq A/D for data recording. This device allows event marks to be
placed on the recorded data, and I use the clock to pick off minute marks. I am
very satisfied with my setup, but I do not know if it could be readily adapted
to WinSDR. Please take a look at:
http://www.jclahr.com/science/psn/mcclure/timing/index.html
and tell me what you think.
I avoid the time delay distortion normally encountered with filtering by
using my application called "WQFilter.exe", which uses low-pass filters of my
own design. These filters are applied both forward and backward in time. They
therefore do not work in real time, but are useful in preparing WinQuake event
files.
This application can be downloaded from
http://www.jclahr.com/science/psn/mcclure/wdq_utilities/index.html
It is contained in the ZIP file "seismic_dataq.zip". It works with PSN Type
4 files. It also has a filter which digitally extends the long period
response of my sensors, which have natural periods of only 6, 8, and 13 seconds,
respectively. I use it to prepare all my event files from station REM, Locust
Valley, NY. My prepared waveforms compare very closely with those from the nearby
LDEO station PAL. Real-time and archival drum plots from PAL can be seen at:
http://www.ldeo.columbia.edu/cgi-bin/LCSN/WebSeis/24hr_heli.pl?id=
Regards,
Bob McClure
I depend indirectly on WWVB=20=
via an "atomic" wall clock for timing. I use a DI-194 Dataq A/D for data rec=
ording. This device allows event marks to be placed on the recorded data, an=
d I use the clock to pick off minute marks. I am very satisfied with my setu=
p, but I do not know if it could be readily adapted to WinSDR. Please take a=
look at:
http://www.jclahr.com/science/psn/mcclure/timing/index.html
and tell me what you think.
I avoid the time delay distortion normally encountered with filtering=
by using my application called "WQFilter.exe", which uses low-pass filters=20=
of my own design. These filters are applied both forward and backward in tim=
e. They therefore do not work in real time, but are useful in preparing WinQ=
uake event files.
This application can be downloaded from
http://www.jclahr.com/science/psn/mcclure/wdq_utilities/index.html
It is contained in the ZIP file "seismic_dataq.zip". It works with PS=
N Type 4 files. It also has a filter which digitally extends the long period=
response of my sensors, which have natural periods of only 6, 8, and=20=
13 seconds, respectively. I use it to prepare all my event files from statio=
n REM, Locust Valley, NY. My prepared waveforms compare very closely with th=
ose from the nearby LDEO station PAL. Real-time and archival drum plots from=
PAL can be seen at:
http://www.ldeo.columbia.edu/cgi-bin/LCSN/WebSeis/24hr_heli.pl?id=3D<=
BR>
Regards,
Bob McClure
Subject: Re: Network time standard
From: ChrisAtUpw@.......
Date: Sun, 10 Apr 2005 23:52:01 EDT
In a message dated 10/04/2005, ian@........... writes:
Hi,
an interesting discussion. I note that a spec of <0.1 seconds has been
mentioned (below). Could I ask, how is this derived? Apologies if this is
documented somewhere on the psn site.
Hi Ian,
It is very simple. You have to determine the start of the P wave signal
which is of the order of 1 Hz against a noisy background. Local P waves may
also have higher frequency components added in. There may also be
uncertainties in the filter delay, particularly if you use Butterworth filters. The
delay in Bessel filters is shorter and better defined. This accuracy of wave
timing should be achievable by amateur seismologists in practice.
I only ask because I know that using specs that are higher than needed can
lead to costs that could have been avoided. I guess one would start by
determining what is a reasonable error in calculating epicentre distance that can
be tolerated and working back from there to derive a time spec.
I agree that you can't use the sub microsecond accuracy of a good GPS
clock. However, if your clock only had an accuracy of 1 sec, you would have a
possible error of ~10 km. If it had an error of 10 sec, the possible error is
~100 km. Neither would be particularly helpful when estimating the depth of a
quake at, say 40 km, or of it's position. I'm sorry to put it so bluntly,
but if you CAN'T give error limits to your measurements, you are JUST
COLLECTING GARBAGE !
If your signals are to have any value, you cannot accept a cumulative
timing error which builds up in an unknown way to the equivalent of many kms
uncertainty - eg a rubbishy timing system.
Another question is, which of the many factors influencing epicentre
calculation is the limiting one? I would imagine that the average speed from the
epicentre to a psn station would vary from station to station since each
station is located on a different part of the Earth and the wave will travel
through different parts of the Earth at a slightly different speed for each
direction.
If all the psn stations were locked in time to less than 0.1 seconds, then
the average speed of the wave would have to be no worse than this for the data
to benefit. For a teleseismic event which took, say, 15 minutes to arrive,
all the "rays" would have to travel at the same average speed to within about
0.01% of each other. Is this possible?!
Sure. You do not seem to be thinking correctly about the problem. Let's
put the measurements in context. With a P wave velocity to ~10 km / sec, it
takes under an hour for the wave to traverse the earth. At a frequency of 1
Hz, the wavelength is about 10 km. Structures which are smaller than this will
not effect the transmission significantly at any great distance. The wave
path traverses regions of the Earth which have different velocities and the
track is inevitably curved. What you observe with the seismometer is the 'net
result at one observation point'. But this signal may be modified significantly
by the local sub surface geology.
Under favourable conditions, you can measure the time difference between
the P & S waves and get a rough estimate of the distance to the source, but
only if you can make 'reasonable' assumptions about the average wave
velocities. The location programme then has the job of reverse tracing the waves to
the source, for several seismometer responses at different places and getting
the best overall 'fit'. The average travel / time curves that you have seen
give the first approximation to this relationship and THEY ARE CURVES - you do
NOT have straight line relationships. See the AmaSeis overplots. Moreover,
each seismometer location and wave direction may have slightly different
properties depending on the sub surface geology - the curves are only averaged
values.
We wouldn't be having this discussion if computers were fitted with
reasonably accurate clocks. The 4.194 MHz timing crystals can be trimmed to a few
seconds per fortnight, but high precision temperature tracking modules can
give 0.1 ppm. The 32 kHz crystals often found in watches are much more
temperature sensitive. The lousy apology for a clock
fitted to my current computer drifted 8 sec in the first 2 hours and was down 28
sec on a day. Even hourly web updates would not give me anywhere near the
precision required. You used to be able to buy input expansion boards with clock
modules on them, but I haven't seen any about lately.
Since you can get 60 KHz receiver modules and aerials, it would be
helpful if A/D boards were able to read and update their clocks directly using
WWVB signals. This should be maybe 1/3 the cost of a GPS system and you would
not be dependant on having a permanent phone connection.
Perhaps Larry could stock them?
The A/D board that I use has the timing and radio signal synchronisation
built into it's microprocessor. It has a low drift A/T cut crystal, which is
frequency trimmed. It is not inside the hot computer case. The
microprocessor is set for hourly radio updates and there is a lock idicator to confirm the
update status. I can periodically sync the computer clock with the board or
with the net, but I am not dependant on the computer software clock, or on a
permanent net connection, for accurate timing and sampling.
I bought a 60 KHz radio corrected digital quartz crystal clock and it
has been a very valuable reference for the station. I can thoroughly recommend
them.
Regards,
Chris Chapman
In a message dated 10/04/2005, ian@........... writes:
<=
FONT=20
style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000=20
size=3D2>Hi,
an interesting discussion. I note that a spec of <=
;0.1=20
seconds has been mentioned (below). Could I ask, how is this=20
derived? Apologies if this is documented somewhere on the psn=20
site.
Hi Ian,
It is very simple. You have to determine the st=
art=20
of the P wave signal which is of the order of 1 Hz against a noisy=20
background. Local P waves may also have higher frequency components add=
ed=20
in. There may also be uncertainties in the filter delay, particularly=20=
if=20
you use Butterworth filters. The delay in Bessel filters is shorter and bett=
er=20
defined. This accuracy of wave timing should be achievable by amateur=20
seismologists in practice.
<=
FONT=20
style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000=20
size=3D2> I only ask because I know that using spec=
s that=20
are higher than needed can lead to costs that could have been avoided.&nbs=
p; I=20
guess one would start by determining what is a reasonable error in calcula=
ting=20
epicentre distance that can be tolerated and working back from there to de=
rive=20
a time spec.
I agree that you can't use the sub microsecond=20
accuracy of a good GPS clock. However, if your clock only had an accuracy of=
1=20
sec, you would have a possible error of ~10 km. If it had an error of 10 sec=
,=20
the possible error is ~100 km. Neither would be particularly helpful when=20
estimating the depth of a quake at, say 40 km, or of it's position. I'm sorr=
y to=20
put it so bluntly, but if you CAN'T give error limits to your=20
measurements, you are JUST COLLECTING GARBAGE !
If your signals are to have any value,=20
you cannot accept a cumulative timing error which=20
builds up in an unknown way to the equivalent of=20
many kms uncertainty - eg a rubbishy timing=20
system.
<=
FONT=20
style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000=20
size=3D2> Another question is, which of the many fa=
ctors=20
influencing epicentre calculation is the limiting one? I would imagi=
ne=20
that the average speed from the epicentre to a psn station would vary from=
=20
station to station since each station is located on a different part of th=
e=20
Earth and the wave will travel through different parts of the Earth at a=20
slightly different speed for each=20
direction.
If all the psn stati=
ons=20
were locked in time to less than 0.1 seconds, then the average speed of th=
e=20
wave would have to be no worse than this for the data to benefit. Fo=
r a=20
teleseismic event which took, say, 15 minutes to arrive, all the "rays" wo=
uld=20
have to travel at the same average speed to within about 0.01% of each=20
other. Is this possible?!
Sure. You do not seem to be thinking corre=
ctly=20
about the problem. Let's put the measurements in context. With a P wave velo=
city=20
to ~10 km / sec, it takes under an hour for the wave to traverse the=20
earth. At a frequency of 1 Hz, the wavelength is about 10 km. Structure=
s=20
which are smaller than this will not effect the transmission significantly a=
t=20
any great distance. The wave path traverses regions of the Earth which have=20
different velocities and the track is inevitably curved. What you observe wi=
th=20
the seismometer is the 'net result at one observation point'. Bu=
t=20
this signal may be modified significantly by the local sub surface geology.=20
Under favourable conditions, you can measu=
re=20
the time difference between the P & S waves and get a rough=20
estimate of the distance to the source, but only if you can make=20
'reasonable' assumptions about the average wave velocities. The location=20
programme then has the job of reverse tracing the waves to the source, for=20
several seismometer responses at different places and getting the best=20
overall 'fit'. The average travel / time curves that you have seen give=
the=20
first approximation to this relationship and THEY ARE CURVES - you do N=
OT=20
have straight line relationships. See the AmaSeis overplots. Moreover, each=20
seismometer location and wave direction may have slightly different properti=
es=20
depending on the sub surface geology - the curves are only averaged=20
values.
<=
FONT=20
style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000 size=
=3D2>
We wouldn't be having this discussion if=20
computers were fitted with reasonably accurate clocks. The 4.194 MHz tim=
ing=20
crystals can be trimmed to a few seconds per fortnight, but high precisi=
on=20
temperature tracking modules can give 0.1 ppm. The 32 kHz crystals=20
often found in watches are much more temperature=20
sensitive. &n=
bsp; =
=20
The lousy apology for a clock fitted to my current computer drifted=
8=20
sec in the first 2 hours and was down 28 sec on a day. Even=20
hourly web updates would not give me anywhere near the precisi=
on=20
required. You used to be able to buy input expansion=20
boards with clock modules on them, but I haven't seen any about=20
lately.
Since you can get 60 KHz receiver modules a=
nd=20
aerials, it would be helpful if A/D boards were able to read and update=20
their clocks directly using WWVB signals. This should be maybe 1/3=20=
the=20
cost of a GPS system and you would not be dependant on having a permanen=
t=20
phone connection.
Perhaps Larry could stock them?
The A/D board that I use has the timing and rad=
io=20
signal synchronisation built into it's microprocessor. It has a low d=
rift=20
A/T cut crystal, which is frequency trimmed. It is not inside the hot comput=
er=20
case. The microprocessor is set for hourly radio updates and there is a lock=
=20
idicator to confirm the update status. I can periodically sync the computer=20
clock with the board or with the net, but I am not=20
dependant on the computer software clock, or on a permanent ne=
t=20
connection, for accurate timing and sampling.
I bought a 60 KHz radio corrected digital quart=
z=20
crystal clock and it has been a very valuable reference for the station. I c=
an=20
thoroughly recommend them.
Regards,
Chris Chapman
Subject: Re: time issue
From: ChrisAtUpw@.......
Date: Mon, 11 Apr 2005 00:14:51 EDT
In a message dated 10/04/2005, dickthomas01@............. writes:
Chris has a point, too, about the computer we use with the detection
equipment. I doubt many of you use the newest computer to run WinSDR -- it is
overkill. But the older computers ARE slow to multitask and their clocks are not
that stable. I don't see Larry's GPS board that big an expense for the accuracy
it provides plus it is easy to install.
I might also add that variations in dependability in over-the-air reception
should be expected as well; there is day-to-night, sun spot interference --
even the arrival of long path-short path signals at the same time and place
can be a problem. There is also human created noise such as power generators
that carpenters use to power tools at construction sites, even legal amateur
radio broadcasting, broken insulators on nearby power poles and by all means
drift in the receivers being used to capture time pulses over the air.
In my limited experience, new computers seem to be even less reliable
for clock accuracy than older ones.
These seem to be more problems that I would associate with WWV signals.
WWVB may be a lot more reliable and my 60 KHz module has a crystal filter. I
have checked it for operation up to 1800 miles.
GPS is best for no other reason that it operates in frequencies above the
normal interferences -- it comes from straight up there -- with no bending over
the horizon
Assuming that you have clear vision to the satellites and no trees or
power lines in the way.... But GPS costs roughly 3x as much as a radio module +
aerial.
Regards,
Chris Chapman
In a message dated 10/04/2005, dickthomas01@............. writes:
<=
FONT=20
style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000 size=
=3D2>
Chris has a point, too, about the compute=
r we use=20
with the detection equipment. I doubt many of you use the newest comp=
uter=20
to run WinSDR -- it is overkill. But the older computers ARE slow to multi=
task=20
and their clocks are not that stable. I don't see Larry's GPS board that b=
ig=20
an expense for the accuracy it provides plus it is easy to=20
install.
I might also add that variations in depen=
dability=20
in over-the-air reception should be expected as well; there is day-to-nigh=
t,=20
sun spot interference -- even the arrival of long path-short path signals=20=
at=20
the same time and place can be a problem. There is also human created=
=20
noise such as power generators that carpenters use to power tools at=20
construction sites, even legal amateur radio broadcasting, broken insulato=
rs=20
on nearby power poles and by all means drift in the receivers being u=
sed=20
to capture time pulses over the air.
In my limited experience, new computers seem to=
be=20
even less reliable for clock accuracy than older ones.
These seem to be more problems that I would=20
associate with WWV signals. WWVB may be a lot more reliable and my 60 K=
Hz=20
module has a crystal filter. I have checked it for operation up to 1800=20
miles.
<=
FONT=20
style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000 size=
=3D2>
GPS is best for no other reason that it o=
perates=20
in frequencies above the normal interferences -- it comes from straight up=
=20
there -- with no bending over the horizon
Assuming that you have clear vision to the=20
satellites and no trees or power lines in the way.... But GPS costs roughly=20=
3x=20
as much as a radio module + aerial.
Regards,
Chris Chapman
Subject: On timing
From: Kevin McCue asc@...............
Date: Mon, 11 Apr 2005 14:17:51 +1000
Reluctant as I was to get involved in a good story,=A0=A0Chris=20
Chapman=A0=A0finally got me in with:
'=A0I agree that you can't use the sub microsecond accuracy of a good =
GPS=20
clock. However, if your clock only had an accuracy of 1 sec, you would=20=
have a possible error of ~10 km. If it had an error of 10 sec, the=20
possible error is ~100 km. Neither would be particularly helpful when=20
estimating the depth of a quake at, say 40 km, or of it's position. I'm=20=
sorry to put it so bluntly, but if you CAN'T give error limits to your=20=
measurements, you are JUST COLLECTING GARBAGE !'
You can use S-P intervals to locate the epicentre, travel time curves=20
to compute an origin time and depth-phase identification to sort out=20
focal depth - one could get away without accurate time at all, but it=20
makes life easier.
Cheers
Kevin
Kevin McCue
Director
Australian Seismological Centre
PO Box 324 Jamison Centre
ACT 2614
Australia
ph: 61 (0)2 6251 1291=
__________________________________________________________
Public Seismic Network Mailing List (PSN-L)
Subject: Re: Network time standard
From: Angel sismos@..............
Date: Mon, 11 Apr 2005 06:31:39 -0500
Hi,
I have come in a little late on this very interesting time thread.
Windows has the ability to be synchronized by another computer on the
same network. If you you have a windows box with good time you can
slave other to it with the command, (make it a batch file)
nettime \\computer_with_good_time / set / yes
Replacing "computer_with_good_time" with the network name of the
computer who has good time, the one with the GPS or whatever.
Here is a page with some detailed instructions.
http://www.wown.com/j_helmig/nettime.htm
It's nothing fancy but it works. I use it, I don't know how
"accurate" it is.
Regards,
Angel
__________________________________________________________
Public Seismic Network Mailing List (PSN-L)
Subject: RE: Network time standard
From: "Keith Payea" kpayea@...........
Date: Mon, 11 Apr 2005 09:53:10 -0700
I use NTPTime: http://home.att.net/~Tom.Horsley/ntptime.html, which I found
by visiting www.ntp.org and looking for Windows 2k compatible builds of NTP.
If you are looking for a Linux version, there are many. Go to ntp.org and
poke around.
According to the log files, NTPTime is checking once an hour, and it is
adjusting the clock about +- 20 mS each time. My computer is always on, and
I have DSL, so it can check whenever it wants. However, my "Office" has no
temperature control, so NTPTime is able to deal with that fairly well.
For the purposes of seismic monitoring, I'm assuming the computer is always
on. Someone mentioned how bad the time is when the computer is off. Also,
there was some mention of Millenium Edition. If you can manage it, dump
that in favor of something else. Even Microsoft admits it was not their
finest effort.....
There are also problems with Microsoft's implementation of NTP in Windows.
They have ignored the standard in a couple of places, so it can't get time
from some of the public servers.
AboutTime cited below appears to be an SNTP client, which also supports some
of the older (TIME and DAYTIME) protocols. It's fine for getting you to a
second or better.
As I mentioned in my previous post, a good NTP implementation will
compensate somewhat for transmission delays. This is done by using four
time stamps: 1) at the time the request is sent, 2) at the time the request
is received, 3) at the time the response is sent, 4) at the time the
response is received. The NTP packet has room for all four, so the client
gets them all back. From that, the bulk of the transmission time can be
removed, and the true offset between the client and the server can be
calculated. Things that cause it problems are if the message takes a
radically different route in each direction. The odds of this happening
increase with distance, so that's why a nearer time server is a better
choice than a "better" server that is farther away. Routing changes
relatively slowly based on demand. This is also why the best
implementations need to filter the offset over several messages. They then
adjust the system clock speed (not the crystal, just the interrupt rate!) to
compensate - they don't just jam the new time into the clock.
Before flaming me about any of my simplifications, remember to check
www.ntp.org and read through their stuff. They have put a huge amount of
work into solving this problem while working around the OS limitations.
Keith
-----Original Message-----
From: psn-l-request@.............. [mailto:psn-l-request@............... On
Behalf Of John or Jan Lahr
Sent: Saturday, April 09, 2005 4:51 PM
To: psn-l@..............
Subject: RE: Network time standard
At 02:53 PM 4/9/2005, Keith wrote:
>Not all NTP clients are created equal...
In your experience, which is the best, free time-sync software for a PC with
an Internet connection but no local time server.
Can you evaluate
AboutTime:
http://www.arachnoid.com/abouttime/ ?
Thanks,
John
__________________________________________________________
Public Seismic Network Mailing List (PSN-L)
__________________________________________________________
Public Seismic Network Mailing List (PSN-L)
Subject: Re: On timing
From: ChrisAtUpw@.......
Date: Mon, 11 Apr 2005 22:03:12 EDT
In a message dated 11/04/2005, asc@............... writes:
Reluctant as I was to get involved in a good story, Chris
Chapman finally got me in with:
' I agree that you can't use the sub microsecond accuracy of a good GPS
clock. However, if your clock only had an accuracy of 1 sec, you would
have a possible error of ~10 km. If it had an error of 10 sec, the
possible error is ~100 km. Neither would be particularly helpful when
estimating the depth of a quake at, say 40 km, or of it's position. I'm
sorry to put it so bluntly, but if you CAN'T give error limits to your
measurements, you are JUST COLLECTING GARBAGE !'
You can use S-P intervals to locate the epicentre, travel time curves
to compute an origin time and depth-phase identification to sort out
focal depth - one could get away without accurate time at all, but it
makes life easier.
Cheers
Kevin
Kevin McCue
Director
Australian Seismological Centre
Dear Dr McCue,
Thank you for your comment!
I am not sure if you have appreciated quite how erratic computer
software clocks can be? Let's say that we have three amateur stations which know
their Lat and Long co-ordinates, but are each only 50 km apart in a roughly
straight line in a UK setting. My clock lost 6 sec per hour and the central
station gained 6 sec per hour when checked last week, but the other end one is
unknown. We are all using the standard Widows clock update of once per week and
are at the end of the cycle. We all measure a P / S delay times of the order
of 10 min, but we have only the one vertical sensor with some cross
sensitivity.
Sure we can put in figures for the average travel times for a range of
depths, but estimating a 'cocked hat position' and working back to the time of
origin leaves several minutes unexplained.
How do you suggest that we get an estimate of the time, location and
depth of the quake and the probable errors, please?
Regards,
Chris Chapman
In a message dated 11/04/2005, asc@............... writes:
<=
FONT=20
style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000=20
size=3D2>Reluctant as I was to get involved in a good story, Chris=20
Chapman finally got me in with:
' I agree that=20=
you=20
can't use the sub microsecond accuracy of a good GPS
clock. However, i=
f=20
your clock only had an accuracy of 1 sec, you would
have a possible er=
ror=20
of ~10 km. If it had an error of 10 sec, the
possible error is ~100 km=
..=20
Neither would be particularly helpful when
estimating the depth of a q=
uake=20
at, say 40 km, or of it's position. I'm
sorry to put it so bluntly, bu=
t if=20
you CAN'T give error limits to your
measurements, you are JUST COLLECT=
ING=20
GARBAGE !'
You can use S-P intervals to locate the epicentre, trave=
l=20
time curves
to compute an origin time and depth-phase identification t=
o=20
sort out
focal depth - one could get away without accurate time at all=
,=20
but it
makes life easier.
Cheers
Kevin
Kevin=20
McCue
Director
Australian Seismological=20
Centre
Dear Dr McCue,
Thank you for your comment!
I am not sure if you have appreciated quite how=
=20
erratic computer software clocks can be? Let's say that we have three amateu=
r=20
stations which know their Lat and Long co-ordinates, but are each only =
50=20
km apart in a roughly straight line in a UK setting. My clock lost =
;6=20
sec per hour and the central station gained 6 sec per hour wh=
en=20
checked last week, but the other end one is unknown. We are all us=
ing=20
the standard Widows clock update of once per week and are at the end of the=20
cycle. We all measure a P / S delay times of the order of 10 min,=20=
but=20
we have only the one vertical sensor with some cross sensitivity.
Sure we can put in figures for the average trav=
el=20
times for a range of depths, but estimating a 'cocked hat position' and work=
ing=20
back to the time of origin leaves several minutes unexplained.
How do you suggest that we get an estimate of t=
he=20
time, location and depth of the quake and the probable errors,=20
please?
Regards,
Chris Chapman
Subject: Re: On timing
From: John or Jan Lahr JohnJan@........
Date: Mon, 11 Apr 2005 22:21:16 -0600
At 08:03 PM 4/11/2005, you wrote:
> How do you suggest that we get an estimate of the time, location and
> depth of the quake and the probable errors, please?
Hi Chris,
I don't advocate poor timing, but because it sometimes happens my HYPOELLIPSE
program for locating regional earthquakes in Alaska allowed stations to
provide P and
S times that would be used only for their S minus P interval. If all of
the available
stations had only the S minus P interval, then it was still possible to
compute the
latitude, longitude, depth, and spatial error ellipsoid, but the origin
time remained
unknown.
Cheers,
John
__________________________________________________________
Public Seismic Network Mailing List (PSN-L)
Subject: Re: On timing
From: Mike Price mprice@........
Date: Mon, 11 Apr 2005 21:58:18 -0700
Chris,
The RTC in a typical PC is a joke. However, if you run clock
synchronization SW you can discipline your PC clock to be quite stable
and accurate despite the poor performance of the RTC HW. Generally, the
HW clock is ignored - only the system clock (in the OS) matters and that
is adjusted regularly as its drift with respect to a time standard is
monitored. NTP is quite capable of maintaining accurate local time even
when the routing path to the server is inconsistent since each server
transaction involves multiple exchanges to determine the offset between
the local clock and the server. We manage a large number of remote
computers synchronized through the Internet using ntp and they maintain
clock synchronization to within a few jiffies (jiffy=10mS).
Mike
ChrisAtUpw@....... wrote:
> Dear Dr McCue,
>
> Thank you for your comment!
>
> I am not sure if you have appreciated quite how erratic computer
> software clocks can be? Let's say that we have three amateur stations
> which know their Lat and Long co-ordinates, but are each only 50 km
> apart in a roughly straight line in a UK setting. My clock lost 6 sec
> per hour and the central station gained 6 sec per hour when checked
> last week, but the other end one is unknown. We are all using the
> standard Widows clock update of once per week and are at the end of
> the cycle. We all measure a P / S delay times of the order of 10 min,
> but we have only the one vertical sensor with some cross sensitivity.
>
> Sure we can put in figures for the average travel times for a
> range of depths, but estimating a 'cocked hat position' and working
> back to the time of origin leaves several minutes unexplained.
>
> How do you suggest that we get an estimate of the time, location
> and depth of the quake and the probable errors, please?
>
> Regards,
>
> Chris Chapman
>
__________________________________________________________
Public Seismic Network Mailing List (PSN-L)
Subject: Where was it?
From: 1goss@...........
Date: Thu, 14 Apr 2005 18:49:57 +0000
I got this event very clear! and and it was on Ceri PWLA EHZ NM : Pickwick Lake, AL Helicorder Display. I wrote a letter to CERI asking why it was not ploted on the Recent Earthquakes in Central US. I got a reply and do appreicate they took time to investigate.They are very nice.
I would like to know what you all on the list think,does this happen often?? links to my event and the CERI seismograph 30 miles north of me are at the bottom of the page.
The prociding is the letter they sent me back.
Hi Bryan:
You can just barely see this one on our next closest stations, OXF and LRAL.
These events can be seen very well on PWLA but not on a sufficient number of
other stations to reliably locate it. We only publish reliably located events.
It is a bit of an enigma where the events are actually coming from (most
likely south of PWLA, or perhaps local and shallow) and why. PWLA is an unusually
sensitive stations and records well events not seen by the rest of the network.
On Thu, 14 Apr 2005, Bryan Goss wrote:
> I did not see this event on the Recent Earthquakes in Central US.
>
> UTC 4/13/05 14:06:16
>
>
> This is Ceri PWLA EHZ NM : Pickwick Lake, AL Helicorder Display
> http://folkworm.ceri.memphis.edu/heli_nm/PWLA_EHZ_NM.2005041300.gif
>
>
> I saw it on my homebuilt Lehman seismometer
> In Corinth MS. as well this is why I ask.
> https://home.comcast.net/~bryangoss/micro.jpg
I also submitted this on the CERI ask a Ask a Seismologist / Geologist Page .
Mitch
Center for Earthquake Research and Information (CERI)
University of Memphis Ph: 901-678-4940
Memphis, TN 38152 Fax: 901-678-4734
__________________________________________________________
Public Seismic Network Mailing List (PSN-L)
Subject: Re: Where was it?
From: John or Jan Lahr JohnJan@........
Date: Thu, 14 Apr 2005 13:39:26 -0600
You might be able to get a rough location by using the S minus P intervals at
your station and at PWLA. This will be ambiguous with just two stations, but
the weak arrivals at the other stations might eliminate one of the two possible
locations.
Sooner or later there will probably be a larger event from the same
location that is
located.
John
At 12:49 PM 4/14/2005, you wrote:
>I got this event very clear!
__________________________________________________________
Public Seismic Network Mailing List (PSN-L)
Subject: Nice to be enjoyed ... I guess
From: "RANDY KIMBALL" randy.kimball@...........
Date: Thu, 14 Apr 2005 18:32:55 -0500
Hi,
By now I'm sure I have been the laughing stock of the whole PSN group.
Actually, I've taken it is stride. I've done a good job of screwing up =
several posts and wouldn't give up the experience for the world.
It has been a humble pie to eat that I deserve intently. Thank you for =
each of your patience as I fumble through the learning experience still =
thrilled that I can actually see results and plot them on my map from =
events on the other side of the world.
-randy- (the nerd in Keller, Texas)
Hi,
By now I'm sure I have been the =
laughing stock of=20
the whole PSN group.
Actually, I've taken it is =
stride. I've done=20
a good job of screwing up several posts and wouldn't give up the =
experience for=20
the world.
It has been a humble pie to eat =
that I deserve=20
intently. Thank you for each of your patience as I fumble through =
the=20
learning experience still thrilled that I can actually see results and =
plot them=20
on my map from events on the other side of the world.
-randy- (the nerd in Keller,=20
Texas)
Subject: Re: Nice to be enjoyed ... I guess
From: ChrisAtUpw@.......
Date: Thu, 14 Apr 2005 22:31:32 EDT
In a message dated 15/04/2005, randy.kimball@........... writes:
Hi,
By now I'm sure I have been the laughing stock of the whole PSN group.
Hi Randy,
That is nonsense. We try to be co-operative and helpful to new members.
Learning a new science like seismology takes quite a lot of hard work and
some study. We were mostly new members 10 yours ago! Fortunately there are a
hard core of amateurs with semi professional experience about. If you don' t
understand, just say so and others will try to help.
Regards,
Chris Chapman
In a message dated 15/04/2005, randy.kimball@........... writes:
<=
FONT=20
style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000 size=
=3D2>
Hi,
By now I'm sure I have been the laughing=20=
stock of=20
the whole PSN group.
Hi Randy,
That is nonsense. We try to be co-operative and=
=20
helpful to new members. Learning a new science like seismology takes quite a=
lot=20
of hard work and some study. We were mostly new members 10 yours a=
go!=20
Fortunately there are a hard core of amateurs with semi professional=20
experience about. If you don' t understand, just say so and others will try=20=
to=20
help.
Regards,
Chris Chapman
Subject: Re: Nice to be enjoyed ... I guess
From: "RANDY KIMBALL" randy.kimball@...........
Date: Thu, 14 Apr 2005 22:50:06 -0500
Thanx, Chris,
I was being light hearted. I'm having a blast with my sensors, ... I'm =
short of time to spend with them ... but the time I get to fool around =
and experment is priceless.
I have made plenty of mistakes and I'm sure many others have too. The =
thing is to enjoy our mistakes, learn from them and realize those that =
make no mistakes are either not being honest with themselves or not =
pushing the envelope. At this point with my present professional =
position and the many other irons I have stuffed into my fire, I am =
pushing the envelope to the hilt. To maintain a reality, a good poke at =
myself is great medicine. Thank you each again and as soon as I get a =
grip on the subject a bit more perhaps I will be smart enough to =
articulate some questions. In the mean time I'm having a good time with =
a new, for me, technology. This whole process makes me tick. =20
You people should all be very proud. This is a platform from which a =
vital learning curve is being nurtured towards learning how to someday =
predict seismic events and progressively save more and more lives and =
property. This is not a bad thing to be a part of. I hope to =
eventually provide a tiny bit of useful input. When I eventually do get =
time, I hope to work towards improved instruments, as are and do many of =
you. I am very much interested in Z axis. In the mean time my =
instruments are set-up as passable at best.
A humble bow to all members. ... kudos .... a toast to progress.
-randy-
----- Original Message -----=20
From: ChrisAtUpw@..........
To: psn-l@.................
Sent: Thursday, April 14, 2005 9:31 PM
Subject: Re: Nice to be enjoyed ... I guess
In a message dated 15/04/2005, randy.kimball@........... writes:
Hi,
By now I'm sure I have been the laughing stock of the whole PSN =
group.
Hi Randy,
That is nonsense. We try to be co-operative and helpful to new =
members. Learning a new science like seismology takes quite a lot of =
hard work and some study. We were mostly new members 10 yours ago! =
Fortunately there are a hard core of amateurs with semi professional =
experience about. If you don' t understand, just say so and others will =
try to help.
Regards,
Chris Chapman
Thanx, Chris,
I was being light hearted. I'm having a blast with my =
sensors, ...=20
I'm short of time to spend with them ... but the time I get to fool =
around and=20
experment is priceless.
I have made plenty of mistakes and I'm sure many others have =
too. The=20
thing is to enjoy our mistakes, learn from them and realize those that =
make no=20
mistakes are either not being honest with themselves or not pushing the=20
envelope. At this point with my present professional position and =
the many=20
other irons I have stuffed into my fire, I am pushing the envelope to =
the=20
hilt. To maintain a reality, a good poke at myself is great=20
medicine. Thank you each again and as soon as I get a grip on the =
subject=20
a bit more perhaps I will be smart enough to articulate some =
questions. In=20
the mean time I'm having a good time with a new, for me, =
technology. This=20
whole process makes me tick.
You people should all be very proud. This is a platform from =
which a=20
vital learning curve is being nurtured towards learning how to someday =
predict=20
seismic events and progressively save more and more lives and =
property. =20
This is not a bad thing to be a part of. I hope to eventually =
provide a=20
tiny bit of useful input. When I eventually do get time, I hope to =
work=20
towards improved instruments, as are and do many of you. I am very =
much=20
interested in Z axis. In the mean time my instruments are set-up =
as=20
passable at best.
A humble bow to all members. ... kudos .... a toast to =
progress.
-randy-
----- Original Message -----
From:=20
ChrisAtUpw@.......
Hi there,
I have inspected six new computer motherboards.=
=20
They all appeared to be using the miniature cylindrical 32,768=20
Hz watch crystals. You can get AT cut crystals in these cases=20
but watch crystals are the commonest. 32 KHz Watch crystals have a=20
parabolic error plot with temperature, peaking at about 25 or 30 C, +/-5 C.=20=
The=20
coefficient is ~ 0.04 x (Cdiff)^2 ppm. If it is a 30 C crystal and=20
the temperature falls to 5 C, you can expect to get 25 ppm drift - abou=
t 2=20
sec per day.
However, the time loss errors shown on my=20
newish computers are very considerably above this, so I suspect that this mu=
st=20
be due to changes / errors in the counted interrupt rate. On older=20
computers the disk drive R/Ws could override the regular interrupt timing. T=
he=20
time update options given in Windows do NOT seem to "discipline" the rate lo=
ss=20
of the time system. Some other programs can do this.
Most of the USA can receive the WWVB 60 KHz tim=
ing=20
signals. The coverage is shown on
http=
://www.boulder.nist.gov/timefreq/stations/wwvbcoverage.htm Galleon=20
Systems at http://www.ntp-time-server.com/=
=20
produce a range of timing products, from complete time server units to separ=
ate=20
module boards.
The receivers use a 60 KHz tuned ferrite=20
aerial, costing $2.68.
The EM2S receivers cost $10.89. They have a nor=
mal=20
operating range of 3 to 12 V DC. They use a crystal filter to get a high=20
stability narrow band response and have an AVC circuit to optimise=20
reception for changes in signal strength.
The MCM-RS232 Microcontroller Module costs $15.=
89.=20
It operates off 3 V DC. When combined with the EM2 Receiver Module and the=20
Antenna, it provides time information in standard RS232 data format via a se=
rial=20
interface. External buffering to full RS232 levels is required using a=20
proprietary RS232 level shifter IC. The advantage of the module compared to=20
direct host decoding of the receiver output is the continuous availability o=
f=20
exact decoded time information with no host processing overhead. The=20
module has a real time clock that recalibrates itself against the Atomi=
c=20
Radio Time Signal.
I have used these modules 1,800 miles from=
the=20
transmitter and they worked reliably. At ranges over about 500 miles, t=
he=20
ferrite aerial should be horizontal, mounted perpendicular to the direction=20=
of=20
the transmitter and it can be an advantage to mount the modules high up and=20
external to the building, facing in the direction of the transmitter. I=
=20
tried a variety of situations to try to make the system fail. Failures were=20=
all=20
due to the presence of strong interfering radio signals and not to signal=20
strength / internal noise problems. The decoder modules need about 4 mi=
ns=20
of clear signal to synchronise initially, but can update hourly in less than=
90=20
sec. I connected a piezo earpiece to the receiver output and listened f=
or=20
any interfering signals or changes in the output pulse rate. I also measured=
the=20
voltage on the AVC capacitor, min 0.7 V up to the normal range of 0.9 to 1 V=
, as=20
a logarithmic indication of the signal strength when selecting reception=20
sites.
The receiver + aerial need to be >6 ft away=20=
from=20
CRT computer monitors and TV sets. It didn't work well very close to ra=
dio=20
and TV transmitters. Steel framed buildings and Al foil / corrugated ir=
on=20
covered roof spaces showed low signal levels. Roof spaces can suffer fr=
om=20
very large temperature variations. The radio signal was still received OK, b=
ut=20
the presence of utility power wiring allowed the pickup of RFI. Local=20
lightning can prevent clear reception. Local electric arc welding may a=
lso=20
give problems.
The EM2S receiver would work without problems i=
n=20
poor signal locations where my LW AM radio was seriously effected by=20
internal noise. You can buy (borrow?) battery clocks which give=20
'Atomic Time' eg Oregon Scientific. These work off the WWVB signal=20
and those with LCD displays have a radiating aerial mast display with f=
our=20
levels indicating the signal strength at the last update. My clock updates e=
very=20
hour. I have no financial or other connection to Galleon Systems.
If you look at
http=
://www.boulder.nist.gov/timefreq/stations/wwvbtimecode.htm you=20
will see that the 59th and the 1st second of WWVB signal both start with 800=
mS=20
low pulses. It should be quite easy to set up a dual retriggerable monostabl=
e=20
multivibrator to detect this and to give high precision minute timing and /=20=
or=20
second timing pulses.
Larry, I would like to suggest that you give=20
consideration to providing the 16-bit Serial Output A/D Board for WinSDR wit=
h an=20
option to receive and fully decode WWVB signals, or the ability to read the=20
output of a MCM microcontroller module. I have read your note, dated 1998, o=
n=20
WWVB signal reception.
I note that the serial board can currently use=20=
WWV=20
minute tone decode signals, but you state that 'You will not get 24 hour=20
reception on any one channel, as long as you can get 4 to 6 hours per day wi=
ll=20
be fine. At my location I get best reception on 5.0Mhz at night and during t=
he=20
day 10.0Mhz or 15.0Mhz.'
Does the timing for SDR originate on the board,=
or=20
is it dependant on the computer clock, please? My computers can NOT keep tim=
e=20
over a timing break of maybe 12 hours, to better than about 2 sec. This is=20
certainly NOT good enough for seismic work! Unlike WWV, WWVB has t=
he=20
potential to provide accurate timing signals over the full 24 hrs for most=20
places in the USA. The extreme range daytime WWVB signal is certainly a=
lot=20
weaker than the nightime signal, but with the possible exception of Mai=
ne,=20
it should be satisfactory
The ability to fully decode the WWVB signal cou=
ld=20
cope with the situation of a power outage. It wasn't until I bought a 60 KHz=
=20
radio corrected digital clock that I realised just how bad my computer timin=
g=20
systems were! Another reason for doing this is to provide a timing=
=20
system totally independant of the www. There are already=20
predictions of future communications problems on the web.
The total cost could well be about that of=20
just a GPS ANTENNA !
Regards,
Chris Chapman
Subject: Re: Improvements
From: ChrisAtUpw@.......
Date: Fri, 15 Apr 2005 22:17:31 EDT
In a message dated 15/04/2005, 1goss@........... writes:
Chris Chapman,
Thanks for the link to the ball bearings, I have them on the way.
I am going to do a total rebuild. I have in hand =BD square aluminium, will=
=20
this be ok for the boom. If it is not I will buy the =BD nominal stainless =20=
steel=20
water pipe you suggested.
Hi Bryan,
=20
How flexible is your 1/2" Al? I would rate this as a minimum size. I=20
prefer to 'do things the easy way', if there are no other disadvantages. Be=
ing=20
able to buy compression ends for water pipe is an easier than making plug e=
nds=20
for a square tube. Before you decide, see what pipe you can easily buy? You=
=20
can mount your hard plate on the flat end and drill the other end to hold t=
he=20
support plate for the coil. Check whether you can get compression Xs withou=
t=20
too much trouble. They are available, but not from every supplier.=20
I also ordered 12*18*=BC inch aluminum plate for the base.
If I use a boom length of 30 inches where should I put the weight I will tr=
y=20
to attach the support wire the way you suggested as well. It will take me=20
some time but I want the best seismograph I can build.
I would mount the weight as far along the boom as possible, just before the=
=20
end stop for the sensor. I would put a tongue of damping copper horizontall=
y=20
under the boom with a gap of maybe 3/4", space enough to slide a damping=20
fixing over it. The magnets are 1/4" thick and so are the backing plates. =20=
The=20
tongue 'faces back' toward the pivot. Did I send you a drawing of the fixtu=
re=20
that I use? Cancel this?
Alternatively, put your existing damping plate right on the end, using=20
your existing magnets and mount the coil under the arm on the bearing side=20=
of=20
the mass. One query - your mass looks as if it is in a tin can? Is this mad=
e=20
of steel or Al? If it is steel or has a steel lip, you will have to watch o=
ut=20
for interactions with the magnets.
=20
** Before you disassemble everything, I suggest that you drain your oil=20
tray and check that you can get enough damping with your existing magnets,=20
narrowing the gap as necessary. **=20
=20
What thickness is your copper damping plate?=20
I saw one seismometer which used a 3/8" thick horizontal copper plate 5=
"=20
x 5" for the mass and put the damping magnets on top and bottom! But I=20
don't know what it cost!=20
=20
There is no 'perfect' way to build a seismometer, but there are=20
constructional / instumentation problems which are best avoided. Knife edge=
bearings=20
and oil damping are two of them!
=20
Regards,
=20
Chris Chapman
How flexible is your 1/2" Al? I would rate this=
as=20
a minimum size. I prefer to 'do things the easy way', if there are no other=20
disadvantages. Being able to buy compression ends for water pipe is an easie=
r=20
than making plug ends for a square tube. Before you decide, see what pipe yo=
u=20
can easily buy? You can mount your hard plate on the flat end and drill the=20
other end to hold the support plate for the coil. Check whether you can=
get=20
compression Xs without too much trouble. They are available, but not from ev=
ery=20
supplier.
![https://home.= comcast.net/~bryangoss/noise11am.jpg](3D"https://home.comcast.net/~bryangoss/noise11am.jpg"){kind=link}
![https://home.comc= ast.net/~bryangoss/winsdr.jpg](3D"https://home.comcast.net/~bryangoss/winsdr.jpg"){kind=link}
![https://home.c= omcast.net/~bryangoss/pipeunion.jpg](3D"https://home.comcast.net/~bryangoss/pipeunion.jpg"){kind=link}
![https://home.com= cast.net/~bryangoss/damping.jpg](3D"https://home.comcast.net/~bryangoss/damping.jpg"){kind=link}
![https://home.comcas= t.net/~bryangoss/coil.jpg](3D"https://home.comcast.net/~bryangoss/coil.jpg"){kind=link}
![https://h= ome.comcast.net/~bryangoss/overall.jpg](3D"https://home.comcast.net/~bryangoss/overall.jpg"){kind=link}