Searching \ for '[OT]Tempus Fugit...' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/index.htm?key=tempus+fugit
Search entire site for: 'Tempus Fugit...'.

Exact match. Not showing close matches.
PICList Thread
'[OT]Tempus Fugit...'
2000\02\09@195143 by andy howard

flavicon
face
I've seen a number of PC apps that set the PC clock by connecting to an
atomic time standard, either directly-dialed or via the net.

Does anyone have any info on what time services are available, what
protocol is used to access them etc.?

This is for a data logger application for use in very remote areas that
will be subject to considerable temperature variations. I fear the RTC
will be prone to excessive drift unless it is regularly updated. Clock
needs to be accurate over periods of several months, maybe years,
betweeen maintenance visits.

These units will be primarily used in the UK, the rest of Europe and the
US, so references for dial-able time standards in those areas would be
most helpful - but info on standards anywhere in the world would be
welcome. UTC/GMT would be favorite but local time would be fine,
assuming I can find the relevant Daylight Saving changeover dates.

Because many target sites will have broadcast and other transmitters
nearby, the VLF-radio time transmissions (WWV, MSF etc.) as used by
radio-code clocks may not be possible in some cases but I'd still be
interested to hear of anyone's experiences in using those as a source of
standard time.

Suggestions for alternative schemes to keep an accurate clock over long
periods would also be welcome.



Cheers

Andy.



.

2000\02\09@210107 by Ken Webster

flavicon
face
I have several links posted here:
http://ken.webster.org/links/timefreq.html

One suggestion I have for keeping an accurate clock is to add a temperature
sensor and an EEPROM to your PIC, measure the oscillator's error and
temperature coefficient, and store it as a table in EEPROM.

This could be used in conjunction with services such as ACTS (dialup) to
allow the service to be called less frequently and save long-distance phone
charges.  Or it could allow WWVB or other VLF signals to be used in fringe
areas where reception is only good at certain times of day.

The dialup time service in the US is known as ACTS (Automated Computer Time
Service) and is detailed here:
http://www.bldrdoc.gov/timefreq/service/acts.htm

I have some old software (Visual Basic for Windows) which sets the
computer's clock via ACTS.  I could dig out the source-code if you are
interested.

I also wrote code to implement a WWVB receiver on a PIC16C73 using the A/D
and firmware to implement a PLL.  It can extract and decode a signal from a
very noisy input.  Since I live very close to the transmitter I have not
experimented with sensitive antennas and receiver circuits (a loopstick
antenna sans amplifier connected directly to the A/D input is sufficient!)

What kinds of transmitters are your dataloggers going to be near?  The
receiver I made can tolerate a great deal of noise as long as it is not too
near the 60kHz carrier frequency.  Commercial receivers typically employ
narrow-band crystal filters and thus I would expect them to be reasonably
immune to out-of-band noise also.

Cheers,

Ken



{Quote hidden}

2000\02\10@053620 by andy howard

flavicon
face
> I have several links posted here:
> http://ken.webster.org/links/timefreq.html

Great selection!  Many thanks for that Ken.

> One suggestion I have for keeping an accurate clock is to add a
temperature
> sensor and an EEPROM to your PIC, measure the oscillator's error and
> temperature coefficient, and store it as a table in EEPROM.
> This could be used in conjunction with services such as ACTS (dialup)
to
> allow the service to be called less frequently and save long-distance
phone
> charges.  Or it could allow WWVB or other VLF signals to be used in
fringe
> areas where reception is only good at certain times of day.

Neat idea. I'd not really thought about call costs at this stage - no
doubt the client will! My only concern is variance between individual
RTCs.  If one set of cal data would do for a production run then fine,
but it isn't going to be economical to do individual cals on these
units unfortunately. I'll have to get a handful of RTC chips and
experiment with this.


> The dialup time service in the US is known as ACTS (Automated Computer
Time
> Service) and is detailed here:
> www.bldrdoc.gov/timefreq/service/acts.htm
> I have some old software (Visual Basic for Windows) which sets the
> computer's clock via ACTS.  I could dig out the source-code if you are
> interested.

Yes please, at this stage any input is welcome. Once I've examined all
the possibilities it should be possible to devise an optimal solution
(famous last words)...

> I also wrote code to implement a WWVB receiver on a PIC16C73 using the
A/D
> and firmware to implement a PLL.  It can extract and decode a signal
from a
> very noisy input.  Since I live very close to the transmitter I have
not
> experimented with sensitive antennas and receiver circuits (a
loopstick
> antenna sans amplifier connected directly to the A/D input is
sufficient!)

Blimey! You must live *very* close. Can you turn off the fluorescent
lights in your house?

> What kinds of transmitters are your dataloggers going to be near?

Mostly FM and GSM, some AM band too so nothing below about 550kHz.

> The
> receiver I made can tolerate a great deal of noise as long as it is
not too
> near the 60kHz carrier frequency.  Commercial receivers typically
employ
> narrow-band crystal filters and thus I would expect them to be
reasonably
> immune to out-of-band noise also.

Ah, OK, so VLF is back on the menu then. If it works then that would be
my preferred solution for this application. Not needing to dial-up would
be a plus certainly.
Maybe VLF with dialup backup is the belt'n'braces (belt'n'suspenders in
the US) solution.

I've found the Temic and Simi VLF Rx links on your page so I'll pop off
and
grab some data there too.

Many thanks for the input.

Cheers,

Andy.








>
> >I've seen a number of PC apps that set the PC clock by connecting to
an
> >atomic time standard, either directly-dialed or via the net.
> >
> >Does anyone have any info on what time services are available, what
> >protocol is used to access them etc.?
> >
> >This is for a data logger application for use in very remote areas
that
> >will be subject to considerable temperature variations. I fear the
RTC
> >will be prone to excessive drift unless it is regularly updated.
Clock
> >needs to be accurate over periods of several months, maybe years,
> >betweeen maintenance visits.
> >
> >These units will be primarily used in the UK, the rest of Europe and
the
> >US, so references for dial-able time standards in those areas would
be
> >most helpful - but info on standards anywhere in the world would be
> >welcome. UTC/GMT would be favorite but local time would be fine,
> >assuming I can find the relevant Daylight Saving changeover dates.
> >
> >Because many target sites will have broadcast and other transmitters
> >nearby, the VLF-radio time transmissions (WWV, MSF etc.) as used by
> >radio-code clocks may not be possible in some cases but I'd still be
> >interested to hear of anyone's experiences in using those as a source
of
> >standard time.
> >
> >Suggestions for alternative schemes to keep an accurate clock over
long
{Quote hidden}

2000\02\10@061201 by Russell McMahon

picon face
Andy,


>I've seen a number of PC apps that set the PC clock by connecting to an
>atomic time standard, either directly-dialed or via the net.

>Suggestions for alternative schemes to keep an accurate clock over long
>periods would also be welcome.



Use of the cheapest available GPS unit with a serial interface will meet
your need. Needs only be powered up occasionally if power is a problem. Note
that it will require some minutes to acquire a full constellation of
satellites but time may be accurate before then).




     Russell McMahon
_____________________________

>From other worlds - http://www.easttimor.com
                               http://www.sudan.com

What can one man* do?
Help the hungry at no cost to yourself!
at  http://www.thehungersite.com/

(* - or woman, child or internet enabled intelligent entity :-))

2000\02\10@105729 by jamesnewton

face picon face
Telnet example: telnet time-a.nist.gov 13

The Time and Frequency Division is an operating unit of the Physics
Laboratory of the National Institute of Standards and Technology (NIST).
Located in Boulder, Colorado at the NIST Boulder Laboratories, the Time and
Frequency Division:

Maintains the primary frequency standard for the United States.
Develops and operates standards of time and frequency.
Coordinates U. S. Time and Frequency standards with other world standards.
Provides time and frequency services for United States clientele.
NIST time setting format
The NIST transmits in its own standard Automated Computer Timer Service
(ACTS). It is contacted via TCP/IP on port 13. After a setting is made the
time string from the NIST used in the setting is displayed in the NIST log
window. ClockWatch translates this string. All times from NIST are in UTC.
This time string is made up by a series of fields arranged end to end.

Message Format received from NIST, with an actual sample string below it:

MJD YYMMDD HHMMSS DST LS H ADV MISC
49010 93-01-23 22:01:22 00 0 0 50.0 UTC(NIST) *

MJD        The first number is the date expressed as a Modified Julian Day
number (MJD), in the above example 49010 is the Modified Julian Day. The
Modified Julian Day: is obtained by counting days from the starting point at
midnight on 17 November 1858. It is one way of telling what day it is with
the least possible ambiguity.

YYMMDD HHMMSS    The next 6 values give the Universal Coordinated date and
time (formerly called Greenwich Mean Time) as year, month, day, hour, minute
and second.

DST        The eighth number is the daylight saving time flag, DST. It is
based on the continental US system, which has transitions on the first
Sunday in April and the last Sunday in October.
DST = 0 means standard time is currently in effect.
DST = 50 means daylight saving time is currently in effect.
DST = 51 means the transition from standard time to daylight time is at 2am
local time today.
DST = 1 means the transition from daylight time to standard time is at 2am
local time today.
DST > 51 gives advance notice of the number of days to the transition to
daylight time. The DST parameter is decremented at 0000 every day during
this advance notice period, and the transition will occur when the parameter
reaches 51 as discussed above.
1 < DST < 50 gives advance notice of the number of days to the transition to
standard time. The DST parameter is decremented at 0000 every day during
this advance notice period, and the transition will occur when the parameter
reaches 1 as discussed above. The DST parameter is usually not needed for
UNIX systems which keep time internally using Universal Time.
Note: ClockWatch uses the Windows internal Time Zone setting to determine if
daylight savings time is both used and in effect.

LS        The next number is the leap second flag, LS.
LS = 0 means no leap second is scheduled.
LS = 1 means that a leap second is to be added as 23:59:60 on the last day
of the current month. The last minute will therefore be 61 seconds long.
Leap seconds are usually added at the end of either June or December.
LS = 2 means that second 23:59:59 is to be dropped on the last day of the
current month. The second following 23:59:58 will be 00:00:00 of the next
day. This minute will therefore be 59 seconds long. This situation is
unlikely to be necessary in the foreseeable future.
Note that leap seconds are inserted or deleted at the specified Universal
Times, while daylight savings transitions are always with respect to local
time.

H        The health parameter, H, gives the health of the timeserver:
H = 0 means that the server is healthy.
H = 1 means that the server is operating properly but that its time may be
in error by up to 5 seconds. This state should change to fully healthy
within 10 minutes.
H = 2 means that the server is operating properly but that its time is known
to be wrong by more than 5 seconds.
H = 3 means that the hardware or software have failed and that the time
error is unknown.

ADV        The advance parameter, ADV, gives the time advance of the
transmissions, in milliseconds. Each time packet is sent out early by this
amount to compensate (approximately) for the network delay.

MISC        The remaining characters on the line identify the time source
and are included for compatibility with the ACTS time system.

See Also:
http://techref.massmind.org/timers.htm

---
James Newton spam_OUTjamesnewtonTakeThisOuTspamgeocities.com 1-619-652-0593
http://techref.massmind.org NEW! FINALLY A REAL NAME!
Members can add private/public comments/pages ($0 TANSTAAFL web hosting)


{Original Message removed}

2000\02\10@173633 by Ken Webster

flavicon
face
>> One suggestion I have for keeping an accurate clock is to add a
>> temperature sensor and an EEPROM to your PIC, measure the
>> oscillator's error and temperature coefficient, and store it as
>> a table in EEPROM.  This could be used in conjunction with
>> services such as ACTS (dialup) to allow the service to be
>> called less frequently and save long-distance phone charges.
>> Or it could allow WWVB or other VLF signals to be used in fringe
>> areas where reception is only good at certain times of day.
>
>Neat idea. I'd not really thought about call costs at this stage - no
>doubt the client will! My only concern is variance between individual
>RTCs.  If one set of cal data would do for a production run then fine,
>but it isn't going to be economical to do individual cals on these
>units unfortunately. I'll have to get a handful of RTC chips and
>experiment with this.
>


Another thought I had was to measure the average and max and min
temperatures inbetween time measurements (calls to ACTS or powering up the
WWVB receiver) and if they are not too spread out (temperature didn't vary
too much) then put an entry into the EEPROM for the average temperature and
measured oscillator error.  Thus it would start out with poor performance
and through use it would automatically learn the characteristics of the
oscillator and improve its performance.



{Quote hidden}

The source-code is here:
http://kdsl32.dnvr.uswest.net/cgi-bin/tl2.exe/2way/2WAYM4.BAS

The subroutine that sets the clock is called SetClock()



{Quote hidden}

Fluorescent lights CAN be turned off???  You mean they're not supposed to
stay on all the time?  :o)

Actually I'm about 5 or 6 miles away (about 9km).  The loopstick that works
without any amplifier is a large one and it is tuned.  I can measure about
100mV p-p from it with my o'scope.


(snip)
>Ah, OK, so VLF is back on the menu then. If it works then that would be
>my preferred solution for this application. Not needing to dial-up would
>be a plus certainly.
>Maybe VLF with dialup backup is the belt'n'braces (belt'n'suspenders in
>the US) solution.


Definitely.  WWVB just finished a big power upgrade:
http://www.boulder.nist.gov/timefreq/wwvstatus.htm

Coverage is now reasonably good throughout the contiguous 48 states, the
northern part of Mexico, and the southern part of Canada.

Cheers,

Ken

2000\02\10@180617 by andy howard

flavicon
face
> >> One suggestion I have for keeping an accurate clock is to add a
> >> temperature sensor and an EEPROM to your PIC, measure the
> >> oscillator's error and temperature coefficient, and store it as
> >> a table in EEPROM.  This could be used in conjunction with
> >> services such as ACTS (dialup) to allow the service to be
> >> called less frequently and save long-distance phone charges.
> >> Or it could allow WWVB or other VLF signals to be used in fringe
> >> areas where reception is only good at certain times of day.

> >Neat idea. I'd not really thought about call costs at this stage - no
> >doubt the client will! My only concern is variance between individual
> >RTCs.  If one set of cal data would do for a production run then
fine,
> >but it isn't going to be economical to do individual cals on these
> >units unfortunately. I'll have to get a handful of RTC chips and
> >experiment with this.

> Another thought I had was to measure the average and max and min
> temperatures inbetween time measurements (calls to ACTS or powering up
the
> WWVB receiver) and if they are not too spread out (temperature didn't
vary
> too much) then put an entry into the EEPROM for the average
temperature and
> measured oscillator error.  Thus it would start out with poor
performance
> and through use it would automatically learn the characteristics of
the
> oscillator and improve its performance.

Excellent idea! An intelligent oscillator, I like it very much.

This may be the excuse I needed to invest in the fuzzy logic kit...


Many thanks for the input.  I'll post a summary to the list when the
project is done, and put up some pages with more detail too.



Cheers,

Andy.








.

More... (looser matching)
- Last day of these posts
- In 2000 , 2001 only
- Today
- New search...