On Wed, 2008-08-27 at 20:46 +0200, Per Jessen wrote:
Roger Oberholtzer wrote:
inertial navigation system. The PPS signal is on one of the GPS control lines. We had considered a serial->USB converter. They do work fine with the GPS - but no PPS signal.
How do you get an accurate PPS off a serial line if you have to keep polling it? Can't you let it pull an interrupt line or something? (sorry, I didn't mean to start a redesign of your system).
The information is available via two different interfaces. The location data (NMEA strings with time) is received via read() and the PPS is via an ioctl() that waits for a change in the state of specified serial port lines before returning: ioctl(nmeaPort, TIOCMIWAIT, TIOCM_RI); When this returns, the line in question (ring indicator, which is where Trimble receivers put the PPS signal) has just had a transition. Of course, there are process scheduling issues with this that still introduce error, but we are happy with how the Linux kernel is letting us know of the line transition. The read() call lives in a thread (where my problem occurs) that does nothing but read the GPS and write it to a file. It also parses the string, saving the most recent ZDA record and seeing what the most recent PPS PC time was. To put all this together, I read the NMEA strings as fast as they arrive (my problem code). We use 10 Hz receivers, and we only take the required NMEA strings, so there is no trouble with staying rather up to date reading. But, of course, there are numerous delays imposed on this NMEA data along the way. Some are in the GPS receiver, and so ultimately, we have no control over them. One NMEA record (called ZDA) is sent at 1 Hz. The PPS signal tells exactly when the time in the ZDA record was determined in the GPS receiver. I need to record the PC time when this ioctl() returns. Combining this time with the time in the very next ZDA record lets me sync my PC clock with the GPS clock. In our app, all times recorded are from the PC clock. Using the above method, we can tell what the corresponding GPS time is. This allows us to tell where we were at any given time, and thus locate all data in space. In fact, the GPS is combined with a high resolution distance measurement device and couple gyroscopes and inclinometers to improve location accuracy. Our system gets a bit more complicated in that we have DSPs that are also recording low level transducer data, and their time is only synchronized with the PC time at less frequent points. Gez, I guess I said more than you probably wanted to know... -- Roger Oberholtzer OPQ Systems / Ramböll RST Ramböll Sverige AB Kapellgränd 7 P.O. Box 4205 SE-102 65 Stockholm, Sweden Office: Int +46 8-615 60 20 Mobile: Int +46 70-815 1696 And remember: It is RSofT and there is always something under construction. It is like talking about large city with all constructions finished. Not impossible, but very unlikely. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org