On Sat, 2007-03-17 at 18:13 +0100, Roger Oberholtzer wrote:
On Fri, 2007-03-16 at 19:15 -0400, Doug McGarrett wrote:
We already do all this. My original question was not really about gps at all. It was simple about a computer keeping time correct across boots. Not changing the time by, say, 8.3 hours. The gps discussion has been an aside. Which is what I thought you were asking in the first place. So was it a
problem with the /etc/adjtime file? We've been using GPS per-second pulse for years, and usually involves phase-locking a clock. (Simulcasting and HDTV, for example. To the point of calculating the delay site-to-site for location AND elevation.) Sounds like you are on that path, but I haven't heard you mention a "master-car-clock" you would then sync all your equipment to. There are even stand-alone time servers you could install in each vehicle, referenced to GPS and serving the in-car lan (not necessarily Ethernet-type, but your sensor "network") . Each device would "learn" its inherent delay and compensate accordingly, if the lan was synchronous and predictable. Include the time pole concurrently with your other sensor polling. Your "get-data" loop would know precisely how many cycles it took, assuming it didn't get interrupted. Perhaps you actually need TWO clocks, one known stable to very tight tolerance (short-term), and the other phase-locked to the GPS so you would know the GPS variance to apply, compensating for the movement your sensors detect. Sounds like you are caught in an "oops" mode and trying to avoid an earlier oversight in the plan stage, necessitating a major re-write? ...no offense intended. If you are really pushing the envelope, then BEST of luck, and have FUN. Tom in NM -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org