Mailinglist Archive: opensuse (2162 mails)
| < Previous | Next > |
Re: [opensuse] Long standing serial port issue in openSuse
- From: Roger Oberholtzer <roger@xxxxxx>
- Date: Thu, 28 Aug 2008 08:56:59 +0200
- Message-id: <1219906619.10325.23.camel@xxxxxxxxxxxx>
On Wed, 2008-08-27 at 20:46 +0200, Per Jessen wrote:
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@xxxxxxxxxxxx
For additional commands, e-mail: opensuse+help@xxxxxxxxxxxx
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@xxxxxxxxxxxx
For additional commands, e-mail: opensuse+help@xxxxxxxxxxxx
| < Previous | Next > |