Re: [time-nuts] Time syncing question
I'd say one jump if you just want to get the job done, but
incrementally if you want a cleaner solution or if you think you might
need to do this more than once.
For something like a phone system, I might try just smashing it to the right
time at 2 am each morning when there are not likely to be many users.
--
The suespammers.org mail server is located in California. So are all my
other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's. I hate spam.
Hal, I thought about doing this and it would be workable. However, something
in me just doesn't like the idea of brute forcing it. Tom's elegant solution
appeals to me more. Thanks for the suggestion, though.
For something like a phone system, I might try just smashing it to the
right
time at 2 am each morning when there are not likely to be many users.
You could just sync it once a week. 2am everyday is also a fine choice.
Most RTCs can keep within a second a week, I think. It may seem like a
really good idea to have super-accurate time on a phone system, but
(IMHO) I can't see a need for better than one second accuracy. AND,
every time you set the time, you risk something going wrong with the
phone system. Seriously. The phone system was likely designed to have
it's time set once and then left alone and the manufacturer tested only
that condition. If you update the time frequently, there's a good chance
that sooner or later, it'll coincide with some other event, which will
cause someone to be kicked off the conference-call-of-a-lifetime.
Just my $0.02,
glenn
Hal Murray wrote:
I'd say one jump if you just want to get the job done, but
incrementally if you want a cleaner solution or if you think you might
need to do this more than once.
For something like a phone system, I might try just smashing it to the right
time at 2 am each morning when there are not likely to be many users.
You could just sync it once a week. 2am everyday is also a fine choice.
Most RTCs can keep within a second a week, I think. It may seem like a
really good idea to have super-accurate time on a phone system, but
(IMHO) I can't see a need for better than one second accuracy. AND,
every time you set the time, you risk something going wrong with the
phone system. Seriously. The phone system was likely designed to have
it's time set once and then left alone and the manufacturer tested only
that condition. If you update the time frequently, there's a good chance
that sooner or later, it'll coincide with some other event, which will
cause someone to be kicked off the conference-call-of-a-lifetime.
An interesting theory and set of assumptions. Perhaps
to replace said fear of risk with confidence in design I'd
suggest that Joseph run his time setting program in a
sort of time jitter test mode -- where for minutes at a time,
or all day if necessary, he randomly, or rapidly, sets the
time ahead or behind by seconds or fractions of a second.
If no one reports any problems during this test period then
we all sit back knowing that at least this system handles
dynamic time setting robustly.
Which brings up another hack to solve both Joseph's
problem and Glenn's worry. Have your program just run
in a tight loop: get PC time; set telephone time; and wait
10 seconds. This excessive update rate will not only
guarantee the telephone stay in sync with the NTP PC
to millisecond levels but if there are any bugs in the
telephone system firmware they will show up in the
first day instead of the conference-call-of-a-lifetime.
/tvb
What a marvelous range of answers this topic has produced.
Perhaps it is the blind men and the elephant, again. Here
are some of my blind observations:
-
Experience logging industrial process values taught me
that it is most important that time be monotonically
increasing. How would you plan to handle daylight savings
time? Leap seconds? Is there a time when the device is
certain to be idle? If so, you do not have an international
business. What are the consequences of not having steadily
increasing time, in your application? -
There have been some wild guesses about the telco time
error rate and direction of change. I have an AT&T Caller
ID device which shows time of day and corrects it every
time a call is received. This implies that the telco has a
pretty good idea of the time of day, as well as frequency.
Also have an AT&T 7720 cordless answering machine which is
not set but gains 10-15 seconds per day. YATS32 tells me my
computer gains 5.3 seconds per day. What we need is the
expected drift rate of the telco device and the tolerance
you have for absolute drift. I reset my answering machine
every 3-6 months. I can always calibrate the difference by
pressing the Clock button and hearing its current time. -
We do not know exactly how the telco device time can be
set, or if time can be read from the device. -
If you elect an elegant solution (if one exists) who will
pay for it? I assume this is a business application and not
a hobby that we are talking about.
Does this shed any light on the problem? Or are we blind men
wearing coarse gloves.
Regards,
Bill Hawkins
Telco's know exactly what time it is. Although, frequency is much
more important than time. Central Offices use either Rb or Cs for a
Time & Freq. standard. They need to keep all the trunk signals in
perfect sync to keep from loosing bits.
Cell sites generally use GPSDO's. Either OXCO or Rb. Most of the Rb
sources on ebay are from cell site upgrades. Ditto for the Motorola
Oncores.
Most cell phones set their time to "network time." Usually within
one second. Although I have seen cell phones set themselves and be
off by nearly a minute.
If leap seconds are a problem, use TAI, not UTC.
As for who pays, I've found that (in general), if something isn't
going to increase profit, or decrease expenses, it's probably not
going to get funded by a business. Hence, many of us just do this for
the fun of it.
As for the blind leading the blind, AFAIK many people on this list
make their living designing/building/selling precise timing products.
Others have experience using precise timing equipment.
cheers,
glenn
Ah, the hazards of e-mail.
Glenn says, "As for the blind leading the blind, AFAIK many
people on this list make their living designing/building/
selling precise timing products."
I never meant to say that the blind led the blind. Nor did
I comment on anyone's ability to use precision timing
instruments.
What I did say was that I was blind to the requirements for
the unknown telco device logging project. From the way other
replies were going, it looked like others were having similar
problems.
Maybe what got to me was that others were cheerfully offering
complex solutions to cover all the bases, when the description
of the problem was incomplete. In my 45 years of engineering
experience, that always means that the project will cost more
than it needs to, and that there is a hazard that it will not
work.
Five years ago, I worked on time synchronization for an industrial
Ethernet project. NTP appeared to be the best choice, so I studied
it and corresponded with David Mills. But the devices on the network
had limited processing power and memory - limited by available
technology and the target cost of the devices. We were able to fall
back to SNTP to meet the project requirements.
I apologize for trying to apply rigorous methods to this incompletely
specified project. As Brooke says, we're here to have fun.
Regards,
Bill Hawkins
-----Original Message-----
From: time-nuts-bounces@febo.com [mailto:time-nuts-bounces@febo.com] On
Behalf Of Glenn
Sent: Wednesday, August 30, 2006 8:15 AM
To: Discussion of precise time and frequency measurement
Subject: Re: [time-nuts] Time syncing question
Telco's know exactly what time it is. Although, frequency is much more
important than time. Central Offices use either Rb or Cs for a Time &
Freq. standard. They need to keep all the trunk signals in perfect sync
to keep from loosing bits.
Cell sites generally use GPSDO's. Either OXCO or Rb. Most of the Rb
sources on ebay are from cell site upgrades. Ditto for the Motorola
Oncores.
Most cell phones set their time to "network time." Usually within one
second. Although I have seen cell phones set themselves and be off by
nearly a minute.
If leap seconds are a problem, use TAI, not UTC.
As for who pays, I've found that (in general), if something isn't going
to increase profit, or decrease expenses, it's probably not going to get
funded by a business. Hence, many of us just do this for the fun of it.
As for the blind leading the blind, AFAIK many people on this list make
their living designing/building/selling precise timing products.
Others have experience using precise timing equipment.
cheers,
glenn
time-nuts mailing list
time-nuts@febo.com
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
I have observed that some cell phones set their clock when you power
them up, and others set it at regular time. Some automatically change
time zone as you travel and some don't, maybe due to the same process.
Didier KO4BB
Glenn wrote:
Most cell phones set their time to "network time." Usually within
one second. Although I have seen cell phones set themselves and be
off by nearly a minute.
CDMA phones have their clocks set by the system, as they require more precise
synchronization of not only the data stream bit timing, but also the
synchronization of the psuedo random key streams. These are used for syncing up
the Walsh codes as well as security encryption key functions.
Daun
N8ASB
-----Original Message-----
From: time-nuts-bounces@febo.com [mailto:time-nuts-bounces@febo.com] On Behalf
Of Didier Juges
Sent: Wednesday, August 30, 2006 8:53 PM
To: Discussion of precise time and frequency measurement
Subject: Re: [time-nuts] Time syncing question
I have observed that some cell phones set their clock when you power them up,
and others set it at regular time. Some automatically change time zone as you
travel and some don't, maybe due to the same process.
Didier KO4BB
Glenn wrote:
Most cell phones set their time to "network time." Usually within
one second. Although I have seen cell phones set themselves and be off
by nearly a minute.
time-nuts mailing list
time-nuts@febo.com
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
From: "Daun Yeagley" daun@yeagley.net
Subject: Re: [time-nuts] Time syncing question
Date: Wed, 30 Aug 2006 20:59:12 -0400
Message-ID: 009501c6cc98$ad006f60$1900a8c0@daunthinkpad
CDMA phones have their clocks set by the system, as they require more precise
synchronization of not only the data stream bit timing, but also the
synchronization of the psuedo random key streams. These are used for syncing up
the Walsh codes as well as security encryption key functions.
GSM phones is being timed to transmitt in advance of time, such that their
time-slot is perfectly matched in time when it arrives to the base-station.
This doesn't prohibit the Time-Of-Day to be way off, since that is a separate
service and not all operator have it enabled in their network. So, just because
you have high timing accuracy doesn't mean you get correct time of day.
Ah well.
We thank CDMA for the wealth of Z3801A on the second hand market!
Cheers,
Magnus
On Wed, Aug 30, 2006 at 07:53:19PM -0500, Didier Juges wrote:
I have observed that some cell phones set their clock when you power
them up, and others set it at regular time. Some automatically change
time zone as you travel and some don't, maybe due to the same process.
Didier KO4BB
I assume most members of this august group know that all CDMA
cellphones MUST know the correct time to within about 1 us or so in
order to correctly spread and despread the forward and reverse channel
signals.
There are mechanisms (pilot signals) built into the signaling
format that allow a CDMA cellphone with cheap TCXO time base to acquire
the necessary frequency and then time lock when it is first turned on or
first sees a signal.
But a CDMA cellphone locked up on a base-station (its normal
state) should know the CDMA system time with microsecond accuracy and
also be able to correct its TCXO time base and lock it to the system
reference so it too should be very accurate.
And essentially ALL CDMA systems lock system time and frequency
to GPSDOs at the cell sites (easiest way of keeping a whole network of
them locked together so handoffs work) and keep system time set to UTC.
So the only thing preventing the clock on a CDMA cellphone from
being essentially arbitrarily accurate is laziness or sloppiness in the
GUI firmware that handles the visible clock display - in engine room in
the bowels of the phone there is VERY accurate time of day.
Glenn wrote:
Most cell phones set their time to "network time." Usually within
one second. Although I have seen cell phones set themselves and be
off by nearly a minute.
time-nuts mailing list
time-nuts@febo.com
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
--
Dave Emery N1PRE, die@dieconsulting.com DIE Consulting, Weston, Mass 02493
"An empty zombie mind with a forlorn barely readable weatherbeaten
'For Rent' sign still vainly flapping outside on the weed encrusted pole - in
celebration of what could have been, but wasn't and is not to be now either."
Good explanation!
Daun
N8ASB
-----Original Message-----
From: time-nuts-bounces@febo.com [mailto:time-nuts-bounces@febo.com] On Behalf
Of David I. Emery
Sent: Thursday, August 31, 2006 12:01 AM
To: Discussion of precise time and frequency measurement
Subject: Re: [time-nuts] Time syncing question
On Wed, Aug 30, 2006 at 07:53:19PM -0500, Didier Juges wrote:
I have observed that some cell phones set their clock when you power
them up, and others set it at regular time. Some automatically change
time zone as you travel and some don't, maybe due to the same process.
Didier KO4BB
I assume most members of this august group know that all CDMA cellphones
MUST know the correct time to within about 1 us or so in order to correctly
spread and despread the forward and reverse channel signals.
There are mechanisms (pilot signals) built into the signaling format
that allow a CDMA cellphone with cheap TCXO time base to acquire the necessary
frequency and then time lock when it is first turned on or first sees a signal.
But a CDMA cellphone locked up on a base-station (its normal
state) should know the CDMA system time with microsecond accuracy and also be
able to correct its TCXO time base and lock it to the system reference so it too
should be very accurate.
And essentially ALL CDMA systems lock system time and frequency to
GPSDOs at the cell sites (easiest way of keeping a whole network of them locked
together so handoffs work) and keep system time set to UTC.
So the only thing preventing the clock on a CDMA cellphone from being
essentially arbitrarily accurate is laziness or sloppiness in the GUI firmware
that handles the visible clock display - in engine room in the bowels of the
phone there is VERY accurate time of day.
Glenn wrote:
Most cell phones set their time to "network time." Usually within
one second. Although I have seen cell phones set themselves and be
off by nearly a minute.
time-nuts mailing list
time-nuts@febo.com
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
--
Dave Emery N1PRE, die@dieconsulting.com DIE Consulting, Weston, Mass 02493
"An empty zombie mind with a forlorn barely readable weatherbeaten 'For Rent'
sign still vainly flapping outside on the weed encrusted pole - in celebration
of what could have been, but wasn't and is not to be now either."
time-nuts mailing list
time-nuts@febo.com
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
-
They actually only need to be correct to within 10us, according to
the spec. -
Companies like endrun (www.endruntechnologies.com) make cute ($$$-y,
though) and symmetricom make little CDMA time receivers that will get
you ~10us accuracy indoors. Nice toys to have in your arsenal if you
maintain time in machine rooms and don't like drilling through the ceiling.
-Dave
Daun Yeagley wrote:
Good explanation!
Daun
N8ASB
-----Original Message-----
From: time-nuts-bounces@febo.com [mailto:time-nuts-bounces@febo.com] On Behalf
Of David I. Emery
Sent: Thursday, August 31, 2006 12:01 AM
To: Discussion of precise time and frequency measurement
Subject: Re: [time-nuts] Time syncing question
On Wed, Aug 30, 2006 at 07:53:19PM -0500, Didier Juges wrote:
I have observed that some cell phones set their clock when you power
them up, and others set it at regular time. Some automatically change
time zone as you travel and some don't, maybe due to the same process.
Didier KO4BB
I assume most members of this august group know that all CDMA cellphones
MUST know the correct time to within about 1 us or so in order to correctly
spread and despread the forward and reverse channel signals.
There are mechanisms (pilot signals) built into the signaling format
that allow a CDMA cellphone with cheap TCXO time base to acquire the necessary
frequency and then time lock when it is first turned on or first sees a signal.
But a CDMA cellphone locked up on a base-station (its normal
state) should know the CDMA system time with microsecond accuracy and also be
able to correct its TCXO time base and lock it to the system reference so it too
should be very accurate.
And essentially ALL CDMA systems lock system time and frequency to
GPSDOs at the cell sites (easiest way of keeping a whole network of them locked
together so handoffs work) and keep system time set to UTC.
So the only thing preventing the clock on a CDMA cellphone from being
essentially arbitrarily accurate is laziness or sloppiness in the GUI firmware
that handles the visible clock display - in engine room in the bowels of the
phone there is VERY accurate time of day.
Glenn wrote:
Most cell phones set their time to "network time." Usually within
one second. Although I have seen cell phones set themselves and be
off by nearly a minute.
time-nuts mailing list
time-nuts@febo.com
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
Dave Andersen wrote:
- They actually only need to be correct to within 10us, according to
the spec.
I haven't read the spec, but I don't think it applies to the time
display. I'd also hazard a guess that the cell phone application
programmers
don't care too much about exactly what time it is. They certainly don't
care about "non-critical bugs." Apologies to anyone out there that
actually writes cell phone apps that work reliably.
-glenn
On Aug 31, 2006, at 11:32 AM, Glenn wrote:
Dave Andersen wrote:
- They actually only need to be correct to within 10us,
according to
the spec.
I haven't read the spec, but I don't think it applies to the time
display. I'd also hazard a guess that the cell phone application
programmers
don't care too much about exactly what time it is. They certainly
don't
care about "non-critical bugs." Apologies to anyone out there that
actually writes cell phone apps that work reliably.
Doesn't apply to the display at all. The synchronization is required
for CDMA soft handoff between base stations.
-Dave
Which reminds me.. I think Sprint in my area needs a little work on their
snychronization. On my way between work and home I go through a spot
where it tries to hand off and it drops the call every time. It is
repeatable to about 100 yards, and it's NOT because of lack of signal
strength. I'm pretty sure that it is because I'm moving from one area to
another, not "just" an adjacent cell.
Daun
On Aug 31, 2006, at 11:32 AM, Glenn wrote:
Dave Andersen wrote:
- They actually only need to be correct to within 10us,
according to
the spec.
I haven't read the spec, but I don't think it applies to the time
display. I'd also hazard a guess that the cell phone application
programmers
don't care too much about exactly what time it is. They certainly
don't
care about "non-critical bugs." Apologies to anyone out there that
actually writes cell phone apps that work reliably.
Doesn't apply to the display at all. The synchronization is required
for CDMA soft handoff between base stations.
-Dave
time-nuts mailing list
time-nuts@febo.com
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
The first phone I had where I observed the time zone error, after the
plane had landed in a new time zone and the phone had not been turned
off during the flight (and no, the plane did not crash, not that time)
was an Alltel phone. Alltel uses CDMA.
Again, this was just an observation.
I suspect the radio inside the phone knows time precisely (to within uS)
so it can encode and decode the signals, but it only knows the time
modulo some period of milliseconds or seconds. It does not need to know
time of day, only relative time with respect to the sync signal from the
cell tower. The processor driving the UI knows time of day, but does not
necessarily share the precise clock with the radio.
I have also observed that systems with an acurate time base needed for
some specific processing do not necessarily use the same time base for
general uP operation, or even for time of day. It is sometimes simpler
and cheaper and less troublesome to have a cheap XO near the processor
just so that you do not need to carry the sensitive precise clock all
over the equipment.
Didier KO4BB
I assume most members of this august group know that all CDMA cellphones
MUST know the correct time to within about 1 us or so in order to correctly
spread and despread the forward and reverse channel signals.