On Jan 19, 2014, at 9:00 PM, Hal Murray wrote: > >> All the embedded gear I've done runs on UTC. But it also has requirements >> for 'cold start' that are incompatible with GPS and couldn't be met if the >> system had been off across a leap second. It didn't deal with localtime, so >> DST insanity didn't matter so much... > > I can't quite figure out what that means. > > Where did it get leap-seconds info in the normal case?
In the normal case, we stored leap seconds in a file on the filesystem. This allowed us to program the value into the GPS so it didn't have to wait for the entire almanac to download before it could produce UTC time (old firmware). Newer firmware came out that stored this value such that we didn't have to download it to the GPS. But it was valid only as long as leap seconds are known, so if they were off for more than 6 months, we'd have no way of knowing the now-current value. Also, these systems were not on the internet, so downloading one of the many sources of TAI-UTC differences wasn't an option. > Was there a battery backed TOY/RTC? They typically have some (battery > backed) RAM on the same chip. Could you have stored the leap info there? It wasn't so much the inability to store the leap info that's current. We had a requirement that cold spares had to sit on the shelf for up to 5 years, and come up in a new system with the correct UTC time within 3 minutes of power being applied. If we'd been off < 6 months (not across a leap second opportunity we didn't have leap data for), we could be sure we knew the leap offset was. Otherwise, we had to wait for 25 minutes (old firmware) or 12.5 minutes (new firmware) for the almanac to be downloaded. Both of these figures was significantly longer than the 3 minutes we had to get "up" and running with the correct UTC time. The CPU and GPS were co-located in one module. Since we had a redundant system, we could meet this requirement if only one of the two systems was replaced, which helped make the customer much happier. But if we had a failure of both CPUs at the same time, we couldn't meet the requirement. This was eventually deemed acceptable to the customer given other issues that would be required to happen before a double failure like this was likely, and the time it would take to replace both CPUs, etc. Sorry if I was less than clear about these things. Warner _______________________________________________ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
