nbul 2004
li]
server
invia al client
—
ct, uses a
streaming
plications,
he former
s the true
)ermanent
'er on the
; to it the
st, a free
ing media
chitecture
ers (even
signed to
listing all
in supply
the client
Id system
'er" GPS
software
mn whose
1e); then,
d | starts
receiver
International Archives of the Photogrammetry, Remote Sensing and Spatial Information Sciences, Vol XXXV. Part B2. Istanbul 2004
Permanent Station
Receiver
Y
PC
NTRIP DGGI
Server Server
RTCM RTCM
1/3/16/18/19/31 1/31
Figure 3. Scheme of The Permanent Station with the RTCM
Servers
3. THE CLIENT/ROVER
3.1 Client Architecture
The client is based on a GPS receiver, which can be of geodetic
class (if a sub-decimeter precision is required) or hand-held (if
|-meter precision is enough). In the former case the RTK or
DGPS mode will be used, in the latter the DGPS mode only.
3.2 Client for the RTK Tests
The first solution is based on a Javad-Topcon GPS+GLONASS
L1L2 geodetic receiver with a LegAnt antenna. The receiver can
apply code and phase differential corrections, having a
RTK/OTF positioning engine with centimetric precision. The
receiver is connected to a notebook PC, in turn connected to the
Internet by a GSM-GPRS modem. The built-in RTK engine can
operate in “delayed” or “extrapolated” mode. In “delayed”
mode, the observations are processed regardless of the
correction latency time, by using an internal buffer storing up to
6 observations preceding the current one (based on the rover
time), waiting to receive from the “base” a correction with the
same time tag. This positioning mode (which could be defined
"near-real-time") produces spatially precise positions, like the
ones obtained from post-processing, but temporally delayed by
a time equal to the latency of the corresponding corrections. If
the latency is over 6 seconds, a single-point solution is
produced. The current rover position can be improved by
adding a trajectory model which allows to bring the position up
to date. As the latency time increases, so decreases the precision
of the coordinates. There is no precision loss for static-type
positioning, thus this mode is better suited for topographic
applications, such as "stop-and-go" surveys, where the operator
can stop on a point until the receiver fixes the position with a
adequate precision.
The "extrapolated" mode is useful for navigation and real-time
precision positioning, rather than topographic applications. In
this mode the RTK engine tries to extend the validity of the
previous corrections, by using the range rate correction and
extrapolating the correction (or observation) up to the current
time tag. The advantage of this mode is having an up-to-date
position (the determined position at every time is the current
one according to the receiver time), but less precise spatially.
The positioning precision depends on the decorrelation in time
of the observations, so to a greater latency corresponds a lesser
precision. Beyond a certain latency (usually 15 seconds), the
RTK engine is no longer able to fix the ambiguities, which
remain in "float" state. In this mode, the NMEA output from the
receiver reports the latency of each correction, giving a way to
evaluate the quality of the coordinates. In “extrapolated” mode,
better results are reached if the receiver can use the RTCM 20
and 21 messages, rather than 18 and 19, due to the better
temporal stability of the phase range corrections when
compared with the raw data.
3.3 Client for the DGPS Tests
The DGPS tests were carried out with GPS+GLONASS
recciver Legacy/E Topcon (the same model used at the
permanent station) with a LegAnt 2 antenna; we also used an
iPAQ hand-held PC with GPRS mobile phone for the Internet
connection, and a Compaq Presario notebook PC with the
ArcView-ArcTracking software to display real-time path.
Tests on DGPS were also performed using a Trimble
GeoExplorer hand-held GPS receiver with an integrated
Windows CE computer. The receiver works in DGPS mode
and the corrections can come from an external station in RTCM
format, or directly from the WAAS system. Internet-based
corrections are downloaded by an iPaq hand-held PC with
GSM-GPRS modem card, and sent to the GeoExplorer through
a serial cable connection. The ESRI ArcPad GPS software runs
directly on the GeoExplorer.
4. FIELD TESTS
4.1 RTK Tests
RTK tests with the receiver in static postion were planned both
in “delayed” and “extrapolated” modes, at various distances
from the master station; the former with the purpose of testing
the infrastructure quality, the latter in order to measure the
latency of the corrections. Distances from the permanent station
were fixed at (about) 10 m, 3 km, 6 km, and 15 km. In order to
avoid differences in satellite configurations, all tests were
scheduled at almost the same time every day. The transmission
media used for all tests was the Internet (via GSM and GPRS
mobile connections); for the 10 m test we also used a direct
Ethernet connection (within the same LAN as the server station)
for comparison. The systems for broadcasting the corrections
over the network were the NrripServer with the RTCM 3/18/19
messages, and the DGGI server with two RTCM message sets:
3/18/19 and 3/20/21. Table 1 collects all tests planned for this
experimentation, not all of which were actually performed. The
experiments used a receiver-specific routine to compare the
three components of the actual base-rover baseline (obtained
from a 1-hour static survey) with those computed in RTK mode
during the tests. If the difference on each component falls under
6 cm, the position is considered correct. Each test comprised a
set of at least 30 fixings, where the RTK engine was
reinitialized after each fixing.
| Client/Server — [Ntrip | DGGI — | Modem -
| Lan - Ethernet 18/19 | 18/19, 20/21
| GPRS - Internet | 18/19 | 18/19, 20/21
GSM - Internet 18/19 | 18/19, 20/21
| Modem 18/19,
| 20/21
Table 1. Planned Tests
