On Fri, 2007-03-16 at 15:40 +0000, Dave Howorth wrote: > Roger Oberholtzer wrote: > > The values are over a serial port. These are high-end Trimble receivers. > > The reason for the serial port is that there is a pulse-per-second > > signal that tells when certain calculations in the receiver were done. > > We are striving for sub-meter accuracy in a vehicle traveling up to 110 > > km/h. Any transmission delay from when something is calculated to when > > it is received is a source of error. The pps signal helps eliminate > > this. > > gpsd appears to know about PPS signals.
Which is good. But it does not propagate them. We sync with other external systems when we get the pps signal. So, we really want it! On Linux, there is an ioctl() that returns when the serial port line changes. It is rather quick. We checked this by manipulating the line from the same computer's parallel port. The time from when we toggled the line to when our ioctl() returned were usually on the order of 20 microseconds, according to gettimeofday(). We also use this with photocells to precisely locate control measurements. As serial and parallel ports go away in modern computers, I wonder how this functionality will be maintained. Expensive I/O cards will now be required. > > I would be very happy if there was an ethernet or usb receiver > > that still had all these features. Unfortunately, they typically are > > geared for less demanding location requirements and so do not provide > > these extra signals. We keep looking and hoping. There are some > > PCI-based models that look interesting. > > > >> The gpsd man page has a section on 'use with ntp', for example. > > > > I would be happy if the ntp daemon could be told when to use the > > receiver, and when not to use it. But I do not think this is the way it > > is. The GPS will give bad/old/misc times when there are no receivers. > > Like in a garage. Which is where the measurement systems often are > > started. > > So the GPS is connected to your software and that is deciding whether > the signals are good? So why not set the system time from your software, > either by starting and stopping ntpd appropriately or by directly > setting the time? We do not run as root. And, we do not want the time to change when we are up and running. Only when we start. I am sure something could be cobbled together. We are not requiring that the PC time be in sync with the GPS. Our software figures out what the differences are and happily sorts that out. The main annoyance is that data file access and all does not have the proper time. Files that were created in the future are problematic for some software. Not to mention poor data control droids. Also, if you reboot in a garage without gps availability, you have the odd times. The question is still, why does a reboot cause a messed up time. -- 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]
