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
> How accurate and precise do you need the
> time stamp to be? I assume time resolution is probably one second, so
> you do not need more accuracy than that between updates.
Yes, keeping the time synced to less than 1 S is preferred. Afterall, if I'm
going to bother doing this, I should at least
OK, I assumed the operation was initiated by the phone system, but I
believe you mean that the time can be set by sending a command via the
serial port (for instance, or via ethernet) from a computer or a serial
terminal.
In that case, running a cron job on an NTP connected computer that would
For various reasons, I can't change the software on the device. It would be
even more impossible to modify the hardware. The device's time is settable
at any time via either serial port or HTTP, as I mentioned earlier.
Considering what I am allowed to do with the device, I think an external
pro
I guess it would help to know if the phone system computer runs over a
general purpose OS, such as Linux or a variation of Windows or other
GPOS. If so, you may be able to install a good time keeping utility
designed for that OS and have it steer and update the RTC from an NTP
time server. If n
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
> tim
Tom, your solution looks like just the type of thing I need. Thanks a lot
for sharing it. I especially like the simplicity of your approach.
> Here's what I did on a similar project a while back.
> Your specs aren't quite the same as mine, but
> you get the idea. My goal was to slowly adjust
> ti
> 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 likel
> Tom, thanks for your very clear and simple reply. I may be over thinking
> about the problem and trying to make it more complicated than it is.
>
> The target device is a phone system. The time is used for call logging and
> display on the phones. Considering that the device's RTC doesn't keep ve
Joe,
Thank you for the kind words :)
Actually, there is a new version there (2.0.2 as of a few minutes ago)
that fixes a few spelling errors.
-GH
>
> I just took a look at your software. You are to be commended on your clear
> and detailed documentation. Most GPL software documentation seems t
I just took a look at your software. You are to be commended on your clear
and detailed documentation. Most GPL software documentation seems to be a
few cryptic lines that assume you don't need the documentation anyhow.
> You can get the software from here:
>
> http://www.gs3tech.com/
>
> under
Magnus,
I have written a Linux based control and graph
application for the HPZ3801A. The software also
controls Motorola GPS Receivers.
It is curses based and also generates graphs
of Holdover Uncertainty and EFC (TI values are also stored).
For some graphs of my two Z3801A's look here:
http://
Fellow Time-nuts,
I've left my HP Z3801A unattended but running for quite some time. It now seems
to have started making more sense. When I checked it a few days ago, it was
still a bit high in Predicted holdover uncertainty, but right now it clocks in
at 900 ns/initial 24 hrs. That's about 1E-11
Tom, thanks for your very clear and simple reply. I may be over thinking
about the problem and trying to make it more complicated than it is.
The target device is a phone system. The time is used for call logging and
display on the phones. Considering that the device's RTC doesn't keep very
goo
Hi Philip:
It's been my experience that each manufacture of GPS receivers has their
own proprietary command language that gets used in all that
manufacturers products. Some products implement commands that others do
not, but the core commands stay the same. So you might just get from
the Tri
Dear Sirs
Can anybody help with the TRANS II and ACE II
I am looking for user / operation manual and programming manual for both
units
and perhaps if anybody has a Service type information Circuit Diagrams parts
list etc..
Used in a Truetime GPS-DC and XL-AK Truetime receivers
If an
> I have a piece of equipment that has its time set either via a
> serial port or via HTTP. After initial setting, the device keeps
> its own time (although badly). The device has no NTP capability
> itself. Although I'm describing a particular piece of equipment,
> I have seen many other devices t
17 matches
Mail list logo
