Does anyone know of an accurate realtime clock, better than 5ppm, in a
PC104 module?
Thanks,
David Kuechenmeister
David Kuechenmeister wrote:
Does anyone know of an accurate realtime clock, better than 5ppm, in a
PC104 module?You generally aren’t going to do better than GPS. Google “PC104 GPS” will
generate a few hits.
Is it only important that you maintain the two systems in sync with
each other? Or do you need an actual accurare time of day?
I have a routine that will keep two QNX4 systems synced to each other.
They may both be wrong, but they’ll both be wrong together. It can
easily stay with 10 ms (1ms on most computers).
It you like I can post the code here and you can port it to QNX 6.
David Kuechenmeister <david.kuechenmeister@viasat.com> wrote:
DK > Thanks, of course not, but I have situations where visibility is restricted
DK > and where the extra cost may not be required by customer specs.
DK > Application-wise, I’d like to set the target board’s clock only often enough
DK > to maintain approximately 10 ms of synchronization between two computers.
DK > PC104 RTC does generate quite a few hits, but they mostly seem to refer to
DK > the clock on the cpu board. If those are less than 25ppm, I’d be amazed. The
DK > Winsystems rtc varies between about 45 and 250 ppm, depending on the board.
DK > I’ve experimented enough with NTP to have discovered it’s not very well
DK > suited to dynamic conditions. It doesn’t react well when the server clock is
DK > updated regularly; the client sees quite a bit of jitter in the server
DK > clock, so the client will drift a lot.
DK > Regards,
DK > David Kuechenmeister
DK > “Rennie Allen” <rallen@csical.com> wrote in message
DK > news:3F71D520.6080503@csical.com…
David Kuechenmeister wrote:
Does anyone know of an accurate realtime clock, better than 5ppm, in a
PC104 module?You generally aren’t going to do better than GPS. Google “PC104 GPS” will
generate a few hits.
\
–
Bill Caroselli – Q-TPS Consulting
1-(708) 308-4956 <== Note: New Number
qtps@earthlink.net
Thanks, of course not, but I have situations where visibility is restricted
and where the extra cost may not be required by customer specs.
Application-wise, I’d like to set the target board’s clock only often enough
to maintain approximately 10 ms of synchronization between two computers.
PC104 RTC does generate quite a few hits, but they mostly seem to refer to
the clock on the cpu board. If those are less than 25ppm, I’d be amazed. The
Winsystems rtc varies between about 45 and 250 ppm, depending on the board.
I’ve experimented enough with NTP to have discovered it’s not very well
suited to dynamic conditions. It doesn’t react well when the server clock is
updated regularly; the client sees quite a bit of jitter in the server
clock, so the client will drift a lot.
Regards,
David Kuechenmeister
“Rennie Allen” <rallen@csical.com> wrote in message
news:3F71D520.6080503@csical.com…
David Kuechenmeister wrote:
Does anyone know of an accurate realtime clock, better than 5ppm, in a
PC104 module?You generally aren’t going to do better than GPS. Google “PC104 GPS” will
generate a few hits.
Actually one is a windows XP. That was why we tried the experiment with NTP.
If you think that the code can be ported to XP, I’d be interested. If it
depends on a property of QNX, I don’t know that I could use it.
Thanks,
David
“Bill Caroselli” <qtps@earthlink.net> wrote in message
news:bkskmj$9sn$2@inn.qnx.com…
Is it only important that you maintain the two systems in sync with
each other? Or do you need an actual accurare time of day?I have a routine that will keep two QNX4 systems synced to each other.
They may both be wrong, but they’ll both be wrong together. It can
easily stay with 10 ms (1ms on most computers).It you like I can post the code here and you can port it to QNX 6.
David Kuechenmeister <> david.kuechenmeister@viasat.com> > wrote:
DK > Thanks, of course not, but I have situations where visibility is
restricted
DK > and where the extra cost may not be required by customer specs.
DK > Application-wise, I’d like to set the target board’s clock only often
enough
DK > to maintain approximately 10 ms of synchronization between two
computers.
DK > PC104 RTC does generate quite a few hits, but they mostly seem to
refer to
DK > the clock on the cpu board. If those are less than 25ppm, I’d be
amazed. The
DK > Winsystems rtc varies between about 45 and 250 ppm, depending on the
board.DK > I’ve experimented enough with NTP to have discovered it’s not very
well
DK > suited to dynamic conditions. It doesn’t react well when the server
clock is
DK > updated regularly; the client sees quite a bit of jitter in the
server
DK > clock, so the client will drift a lot.DK > Regards,
DK > David Kuechenmeister
DK > “Rennie Allen” <> rallen@csical.com> > wrote in message
DK > news:> 3F71D520.6080503@csical.com> …
David Kuechenmeister wrote:
Does anyone know of an accurate realtime clock, better than 5ppm, in
a
PC104 module?You generally aren’t going to do better than GPS. Google “PC104 GPS”
will
generate a few hits.
\Bill Caroselli – Q-TPS Consulting
1-(708) 308-4956 <== Note: New Number
qtps@earthlink.net
David Kuechenmeister <david.kuechenmeister@viasat.com> wrote:
DK > Actually one is a windows XP. That was why we tried the experiment with NTP.
DK > If you think that the code can be ported to XP, I’d be interested. If it
DK > depends on a property of QNX, I don’t know that I could use it.
DK > Thanks,
DK > David
Sorry no.
Maybe someone else can help.
David Kuechenmeister wrote:
Thanks, of course not, but I have situations where visibility is restricted
and where the extra cost may not be required by customer specs.
Application-wise, I’d like to set the target board’s clock only often enough
to maintain approximately 10 ms of synchronization between two computers.
PC104 RTC does generate quite a few hits, but they mostly seem to refer to
the clock on the cpu board. If those are less than 25ppm, I’d be amazed. The
Winsystems rtc varies between about 45 and 250 ppm, depending on the board.I’ve experimented enough with NTP to have discovered it’s not very well
suited to dynamic conditions. It doesn’t react well when the server clock is
updated regularly; the client sees quite a bit of jitter in the server
clock, so the client will drift a lot.
If the QNX machine is the critical machine, why not have the QNX machine
be the NTP server, and the Windows machine be the NTP client ? Also,
why is the server clock being “updated”, by what, and by how much ?
Customer circumstances dictate the configuration. The configuration that is
a problem has to slave the indoor unit to an IRIG-B source. There aren’t any
windows NTP drivers for that…yet. The difficulty is that NTP has to use
something for a reference, either a clock or another server. The indoor unit
is a server to the outdoor unit and the indoor unit uses its own system
clock as the reference in this configuration. The IRIG-B source is sampled
at an interval and then the indoor system clock is updated. The updates to
the system clock are what cause the jitter and the eventual drift of the
outdoor clock. I was poking around in the source code and for the local
clock reference, there are notes about just such a phenomena.
As an aside, when the configuration allows a stratum 1 or 2 server for the
indoor units reference, NTP still takes a relatively long time to sync the
outdoor computer to UTC time. First the indoor computer has to sync to the
external source, then the outdoor computer needs to sync to the indoor
computer. Maybe part of the problem is the way XP forwards ip packets
between its interfaces, but even when I configure NTP to “burst”, I still
see times of up to a half hour before the in/out computers are sync’d to
UTC.
“Rennie Allen” <rallen@csical.com> wrote in message
news:3F71F510.7010701@csical.com…
David Kuechenmeister wrote:
Thanks, of course not, but I have situations where visibility is
restricted
and where the extra cost may not be required by customer specs.
Application-wise, I’d like to set the target board’s clock only often
enough
to maintain approximately 10 ms of synchronization between two
computers.
PC104 RTC does generate quite a few hits, but they mostly seem to refer
to
the clock on the cpu board. If those are less than 25ppm, I’d be amazed.
The
Winsystems rtc varies between about 45 and 250 ppm, depending on the
board.I’ve experimented enough with NTP to have discovered it’s not very well
suited to dynamic conditions. It doesn’t react well when the server
clock is
updated regularly; the client sees quite a bit of jitter in the server
clock, so the client will drift a lot.If the QNX machine is the critical machine, why not have the QNX machine
be the NTP server, and the Windows machine be the NTP client ? Also,
why is the server clock being “updated”, by what, and by how much ?
David Kuechenmeister wrote:
Customer circumstances dictate the configuration. The configuration that is
a problem has to slave the indoor unit to an IRIG-B source. There aren’t any
windows NTP drivers for that…yet. The difficulty is that NTP has to use
something for a reference, either a clock or another server.
This is incorrect. An NTP server can use the local clock as a time source.
This is done by specifying the server as IP address 127.127.1.1 (IIRC). Your
comments below about reading the source in and around the “local clock reference”
indicate that you are probably aware of this, but I just want to clarify this
statement for other readers.
The indoor unit
is a server to the outdoor unit and the indoor unit uses its own system
clock as the reference in this configuration. The IRIG-B source is sampled
at an interval and then the indoor system clock is updated. The updates to
the system clock are what cause the jitter and the eventual drift of the
outdoor clock. I was poking around in the source code and for the local
clock reference, there are notes about just such a phenomena.As an aside, when the configuration allows a stratum 1 or 2 server for the
indoor units reference, NTP still takes a relatively long time to sync the
outdoor computer to UTC time. First the indoor computer has to sync to the
external source, then the outdoor computer needs to sync to the indoor
computer. Maybe part of the problem is the way XP forwards ip packets
between its interfaces, but even when I configure NTP to “burst”, I still
see times of up to a half hour before the in/out computers are sync’d to
The time to synchronize is probably because of slew rate adjustments, or by
the initial clock “grooming” that the server is doing on XP. Both of these
are good things ™. Why do you care if it initially takes 30 minutes to
sync (you could use ntpdate to force a rapid step change once the XP servers
clock is groomed) ? Once the systems are synchronized they’ll stay that way.
“Rennie Allen” <rallen@csical.com> wrote in message
news:3F72FDF8.3010706@csical.com…
[some history deleted]
The time to synchronize is probably because of slew rate adjustments, or
by
the initial clock “grooming” that the server is doing on XP. Both of
these
are good things ™. Why do you care if it initially takes 30 minutes to
sync (you could use ntpdate to force a rapid step change once the XP
servers
clock is groomed) ? Once the systems are synchronized they’ll stay that
way.
Generally, our customers don’t expect this kind of lag. I think we are
pushing/exceeding the capability of NTP in this application. Here’s why.
The indoor unit calculates satellite positions and, of course, that’s very
time dependant for LEOs. In order to track a satellite that isn’t visible,
we allow the customers to adjust the system time. That’s why we need to
switch from the external servers to the local clock, and back to the
external server without excessive delays. A half-hour is way too long to
wait, especially if you have to catch that satellite pass that’s coming up
in five minutes.
I have experimented with ntpdate, too. It’s okay once the indoor clock is
synched, but there isn’t any good programmatic way to tell when that
happens. Short of pulling ntpq apart and testing for the kinds of data that
“peers” displays, anyway.
That’s the short of it, anyway. I had hoped to get a quick lead on a RTC,
but thanks for the discussion on NTP. By the way, isn’t the purpose of the
driftfile to reduce the “grooming” time after a source is acquired?
In article <bkvdeb$bmb$1@inn.qnx.com>, david.kuechenmeister@viasat.com says…
“Rennie Allen” <> rallen@csical.com> > wrote in message
news:> 3F72FDF8.3010706@csical.com> …
[some history deleted]The time to synchronize is probably because of slew rate adjustments, or
by
the initial clock “grooming” that the server is doing on XP. Both of
these
are good things ™. Why do you care if it initially takes 30 minutes to
sync (you could use ntpdate to force a rapid step change once the XP
servers
clock is groomed) ? Once the systems are synchronized they’ll stay that
way.
Generally, our customers don’t expect this kind of lag. I think we are
pushing/exceeding the capability of NTP in this application. Here’s why.The indoor unit calculates satellite positions and, of course, that’s very
time dependant for LEOs. In order to track a satellite that isn’t visible,
we allow the customers to adjust the system time.
What a weird design 
Why don’t allow your calculator to use virtual time in variable instead of
system time? Actually, if you use some NORAD predict telegrams or similar data for calculation,
calculation of satellite position isn’t a realtime task at all. It can be done once a day or on any
other time basis, as a result of calculation you will have a schedule for nearest period. This
schedule should be used for realtime part of system (which has precise system time and never lose
it) in order to track passing sitellite (control of receiver, antenna system etc.)
And returning to precise system time - no, I don’t know any of RTC chips quite reliable and precise
for this purpose. We used interrupts from external sync clock.
Best regards,
Eduard.
That’s why we need to
switch from the external servers to the local clock, and back to the
external server without excessive delays. A half-hour is way too long to
wait, especially if you have to catch that satellite pass that’s coming up
in five minutes.I have experimented with ntpdate, too. It’s okay once the indoor clock is
synched, but there isn’t any good programmatic way to tell when that
happens. Short of pulling ntpq apart and testing for the kinds of data that
“peers” displays, anyway.That’s the short of it, anyway. I had hoped to get a quick lead on a RTC,
but thanks for the discussion on NTP. By the way, isn’t the purpose of the
driftfile to reduce the “grooming” time after a source is acquired?
There are some weird things in this system, but I don’t think this is one
of them. I just didn’t do a very good job explaining the system. We provide
a means to simulate a satellite track when the satellite isn’t visible. In
order to do that, the time has to be shifted so that the satellite will
appear to be visible. Maybe that’s the virtual time that you mention. That’s
where the sync/resync problems crop up.
“ed1k” <ed1k@humber.bay> wrote in message
news:MPG.19dd79207b86c2559896fc@inn.qnx.com…
In article <bkvdeb$bmb$> 1@inn.qnx.com> >, > david.kuechenmeister@viasat.com
says…
“Rennie Allen” <> rallen@csical.com> > wrote in message
news:> 3F72FDF8.3010706@csical.com> …
[some history deleted]The time to synchronize is probably because of slew rate adjustments,
or
by
the initial clock “grooming” that the server is doing on XP. Both of
these
are good things ™. Why do you care if it initially takes 30
minutes to
sync (you could use ntpdate to force a rapid step change once the XP
servers
clock is groomed) ? Once the systems are synchronized they’ll stay
that
way.
Generally, our customers don’t expect this kind of lag. I think we are
pushing/exceeding the capability of NTP in this application. Here’s why.The indoor unit calculates satellite positions and, of course, that’s
very
time dependant for LEOs. In order to track a satellite that isn’t
visible,
we allow the customers to adjust the system time.What a weird design >
in variable instead of
system time? Actually, if you use some NORAD predict telegrams or similar
data for calculation,
calculation of satellite position isn’t a realtime task at all. It can be
done once a day or on any
other time basis, as a result of calculation you will have a schedule for
nearest period. This
schedule should be used for realtime part of system (which has precise
system time and never lose
it) in order to track passing sitellite (control of receiver, antenna
system etc.)And returning to precise system time - no, I don’t know any of RTC chips
quite reliable and precise
for this purpose. We used interrupts from external sync clock.Best regards,
Eduard.That’s why we need to
switch from the external servers to the local clock, and back to the
external server without excessive delays. A half-hour is way too long to
wait, especially if you have to catch that satellite pass that’s coming
up
in five minutes.I have experimented with ntpdate, too. It’s okay once the indoor clock
is
synched, but there isn’t any good programmatic way to tell when that
happens. Short of pulling ntpq apart and testing for the kinds of data
that
“peers” displays, anyway.That’s the short of it, anyway. I had hoped to get a quick lead on a
RTC,
but thanks for the discussion on NTP. By the way, isn’t the purpose of
the
driftfile to reduce the “grooming” time after a source is acquired?
In article <bl1l9c$1m5$1@inn.qnx.com>, david.kuechenmeister@viasat.com says…
There are some weird things in this system, but I don’t think this is one
of them. I just didn’t do a very good job explaining the system. We provide
a means to simulate a satellite track when the satellite isn’t visible. In
order to do that, the time has to be shifted so that the satellite will
appear to be visible. Maybe that’s the virtual time that you mention. That’s
where the sync/resync problems crop up.
Maybe I don’t understand your problem, and, of course, I don’t expect you to provide all details on
your system I dealt with some very closed system (it was HRPT channel from NOAA satellites) -
there are two ways to simulate a satellite track:
a) change local time;
b) change location (says if we were in Kiev and put into system our location is NY or LA - it’s
enough to track “virtual” satellite). Accepting of new coordinates takes an half of moment.
Cheers,
Eduard.