On Fri, 2007-03-16 at 22:41 +0100, Carlos E. R. wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > The Friday 2007-03-16 at 20:30 +0100, Roger Oberholtzer wrote: > > > > rs232 <--> usb converters, that's the cheap way... > > > > Except that usb converters do not transfer all the modem control lines > > quickly. At least the ones I have tried.The pps signal is on a modem > > control line. The modem control lines are very quick - not related to > > the baud rate. > > True enough. And it probably rises an interrupt, so you can get almost > real time response. > > 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. > > > > > About the ntpd, if you are developing, I would think about your software > > > feeding data to ntpd, instead of the other way round. > > > > > > Or duplicate the data via a "splitter". Maybe there is a simple way. > > > > Another reason we want to avoid having ntpd running when we do our thing > > is that we do not want the time to change. And ntpd will always do tiny > > adjustments. > > 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. -- Roger Oberholtzer OPQ Systems / Ramböll RST Ramböll Sverige AB Kapellgränd 7 P.O. Box 4205 SE-102 65 Stockholm, Sweden Tel: Int +46 8-615 60 20 Fax: Int +46 8-31 42 23 -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
