-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Friday 2007-03-16 at 23:19 +0100, Roger Oberholtzer wrote:
Then you will have to get port pci cards, but if you are using portables, you are out of luck. pcmcia then?
No laptops. They do not survive regular use in road measurement. We already use PCI serial port cards. But they are so much more than a nice 16550-ish chip. Seems like a bit of overkill.
Well... it is what happens using out of the self hardware.
Very true. You have to wait till the clock is synced, but even then, it will be very slightly nudged now and then. But I suppose you can use the gps clock directly, instead of system time.
As a result of our synchronization, we do that: read the system clock and, using the offset determined at sync time, convert that to the gps time. So we never really require that we get gps data over the serial port in a deterministic fashion. Of course, if the PC system clock drifts, we are screwed.
I thought you were using the data message from the gps unit to get both position and time stamp to use in your calculations, ignoring computer system time. At least, that's how I would try to do it. The system time without ntpd will surely drift, but constantly, no variation (hopefully). With ntpd it is supposed to be kept in sync with the "real world perfect time", but of course, you have to check if it is synced, and it will be slowed or accelerated now and then: thus variable drift. If the source for ntpd sync is a gps unit, it should be able, after a stabilization time, to keep almost perfect sync. Should. You would have to do measurements to ensure this is really so, I guess. Or study the source code to check what variations you cold be getting. And/or read ntpd documentation: I don't suppose they had precision measurements in mind when they designed it, but... maybe the did consider it and wrote about that somewhere.. The cmos clock drift and adjtime file is a completely different matter. It is only considered during boot and halt sequences; the intention is to set the system clock as accurately as possible, once: during start up. Unfortunately, it can misfire. I wrote a small description of how suse handles this. It was included in the old unofficial suse faq, somewhere in sourceforge, time ago. You might find it interesting. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFF+zuXtTMYHG2NR9URAm3FAJ9t7OmO3E4CybCyZVQDkNLJ0j1qcQCglhOW Qld5OvaPQ/eexHeKDGnhB0s= =zdsb -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org