Experimental Physics and
Industrial Control System

[email protected] (Nick Rees) · Thu, 23 Mar 95 15:38:53 HST

John,

> I think the APS would like to do a similar thing, I have written a driver
> for a GPS board that has a pretty nasty interface on it.  Given that it looks
> as if it was made in 'Joe Nobody's Basement Board House' I did not stop too
> long to wonder why.

It is interesting to hear you might want to do it. If you do, use a
Bancomm 635/637 since that is what we all have.

> The trouble I had is/was:
> 
> 	The device ONLY provided the number of milliseconds into the current
> 	calander year.  Therefore I could not figure out what year it is.  A 
> 	rather nasty problem for an IOC that should otherwise be self contained.
> 	I figure that I could always ask a Unix box for the time and assume it is
> 	close ehough to get the year right.

This is a problem which is very common and arises because the standard
way for ditributing time is IRIG B, which is a serial BCD format which
doesn't understand years. However, most GPS boards have an on board
RTC, (most IOC's do too) which can give a guess at the year. I am
trying to ensure that Bancomm uses this clock to provide the year.

This is only a problem if you get time from IRIG B. GPS broadcasts the
year information, so if your board is hooked directly to an antenna,
rather than via IRIG B to central GPS groundstation, the year
information is available.

Typical setups are:

        _______________________
       | GEOS or GPS reciever. |
       | (may be a VME crate)  |
       |_______________________|
                   |
                   |________________________________________ .....
                           |       IRIG B        |
                           |                     |
                     ------------          ------------
                    | VME CPU #1 |        | VME CPU #2 |
                    | - Force 30 |        | - MVME 167 |
                     ------------          ------------ 
                           |                     |
     ________________________________________________________________
    |           |           |               |           |           |
 -------     -------     -------         -------     -------     -------
| Vax 1 |   | Sun 1 |   | VME 3 | ..... | Vax n |   | Sun m |   | VME l |
 -------     -------     -------         -------     -------     -------

So the receiver knows the year, but everything else has to guess at it since
IRIG B doesn't propagate it.

> 	This also posed a problem with the handling of leapseconds -- not that 
> 	they exist... but how to represent them on a system that does not account 
> 	for them -- EPICS.  You see, sice EPICS keeps the time in nanoseconds
> 	since 1990, and the GPS does it since last New Year's eve... how do I
> 	figure out time it was (in EPICS-speak) at midnight last New Years eve?
> 	The days*24*60*60 plus leap years is simple, but how many leap seconds 
> 	passed since then... they should be included because otherwise 
> 	there will be a one-second loop in time at midnight on new years eve if
> 	there was one encountered in the past year.

GPS can provide two types of time. They are UTC and GPS time. UTC is
the familiar everyday sort of time and has those horrible leap seconds.
GPS time does not have leap seconds - it is always a fixed delta from
atomic time - and was the same as UTC on 6 January 1980. It is now 10
seconds different from UTC and diverging at a bit less than 1 second/year.

What I am going to do is run the whole network on GPS time and provide
the 10 second time error as an interesting conversation piece. Anyone
who really needs UTC can convert easily - GPS->UTC is easy, it is only
the other way round that is hard.

Apparently various standards committees have also has turned a blind eye
to this one and, I am told, the C time routines HAVE to ignore leap
seconds. Thus you do get the time you expect when you try and print it.

All this propogates fine over IRIG B since it tells you days through
seconds every second. If would quite happily support 60, 61 or 99
seconds in any minute. But the only way of detecting a leap second is
to make sure you check for that 61'st second every time...

It also propogates over NTP (I think) because all it does (I assume) is
to look for strange 1 second errors. If it sees one, it tries to
correct it and get everything sorted out after the event. Very messy.
If you use a time without leap seconds it just doesn't have this
problem. The only thing you have to ensure is that no machines on your
network actually get their time from a UTC server. That will confuse
everyone.

Bancomm also sell a dedicated NTP server called a TYMSERV 2000. If you
buy the GPS option, they are quite happy to arrange that it provides
either GPS or UTC time. However, we need a different GPS groundstation
for other reasons, and so what I am trying to provide is a cheap NTP
server via the VME crates which will know the time.

Cheers,

Nick

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System