2004-10-26: Authors of DGPS-IP client software need to make sure they read the Notes for Authors. In particular, the HELO line is no longer optional. Too many script kiddie port scanners were camping on the lines and not releasing them for dgpsip clients.
On a stationary GPS without a differential correction signal, you should see a 20m average radius "random walk" pattern. On the same receiver with DGPS corrections and a good view of the sky, the error should be reduced to approximately 2m average radius. If you've always wanted to see how clean the GPS signal is once the government-induced noise signal is removed but didn't want to spend the money for a DGPS radio, here is your big chance!
I'd like to announce a fun DGPS hack. I've written a small Un*x server and client for redistributing DGPS correction signals over the Net. Basically the server grabs the serial byte stream from my DGPS radio and sends it off over a TCP connection. The client does the same thing but in reverse. The result is that you can receive the local DGPS corrections from absolutely anywhere by using the Internet as the world's largest extension cord. You'll still need to be within 1000 miles or so of San Francisco, California, USA for best results. However, chances are better than not that the GPS error will still be reduced if you are within a 3000-mile radius. Several respondents from 2000 miles away have noted that the remote differential signals have diminished the selective availability (SA) induced position and velocity errors by approximately a factor of three. Here are some plots illustrating the reduction of SA-related wander at a site some 3,500 km away. The red traces are with dgps-ip, the green without. [1] [2] Thanks to Tom Dunigan for contributing this data.
I have a report from Andreas Borman in Witten, Germany that his GPS did in fact achieve a DGPS "3D-DIFF" lock when the same four satellites were visible from both our locations. The correction wasn't great (the result was an estimated position error [EPE] of 20 meters), but it is remarkable that the differential correction worked at all. A hypothetical small network of RTCM reference stations around the globe could generate a composite RTCM stream that would be useful anywhere for removing the selective availability portion of the positioning error.
If you have a Netbsd/Openbsd/Freebsd/Linux machine, then grab the following to run "dgpsip". The code is released under Gnu Public License (GPL). Release (1.32) contains a work-around for GPS's that don't checksum the NMEA data stream.
Mauro Venanzi has written a GPL-ed Linux GUI client based on Gtk for receiving and displaying the GPS data along with the differential corrections.
Jeff Thieleke (jthieleke@usa.net) has provided a very nice Win95/98/NT GUI port of DGPSIP. Thanks Jeff for a snazzy version of the Unix command-line program. A self-extracting archive of the executable and documentation is available below. The merged sources will be available shortly. This program will give you interactive service since it parses information returned from your GPS. It therefore is the recommended program for win95/98/NT users.
Andreas Bormann wrote the first Win95/98/NT GUI client for the DGPSIP server. Please note that unlike Jeff's program, this program does not parse returned information from your GPS and therefore permits only bulk service. Some more details and instructions are located in the WinDGPS-readme.txt below. Thanks Andreas for a really nice little program. We have a report from Greg Sousa that WinDGPS works just fine under NT40 sp4 also.
Martin Grossman has a free Delorme Tripmate/Earthmate GPS viewing program called VBSAT that can make use of the DGPSIP server. It is written in Visual Basic and runs on win95/98.
Derrick Brashear and Curt Mills added dgpsip support to gpsd. Gpsd is a Unix daemon that will allow one to read a remote GPS via a simple protocol. It is delivered as GPL-ed source.
If you have a non-Windows, non-Unix OS, you'll have to hack some code together yourself. It's not that hard. All you need to do is open a connection to dgps.wsrcc.com, TCP port 2101 and then feed the resulting data stream to your serial line. Potential authors of DGPS-over-the-Internet client software will want to read this note.
Stan Huntting has a cute graphical program called SAWatch for displaying and statistically analyzing the "Selective Availability" wanderings. It runs on win95/98/NT and can optionally make use of the DGPSIP server.
Karen Nakamura has sent word that she has added DGPSIP support to Global Mapping Systems' GPSy Pro -- Macintosh GPS Software.
The DGPSIP server is multithreaded and is currently configured to support up to 64 concurrent connections. The DGPS radio is outputting data at an average of 284 bits/sec. Normally the server sends out a packet roughly every second with 35 bytes of data and 40 bytes of IP header.
The server also transmits multicast UDP corrections (currently on 224.0.1.235 port 2101). This mode has been tested locally, and in theory the mrouted that I have running on this machine can redistribute this multicast on demand. Unfortunately I don't know how to arrange for broader Internet availability of this service. Suggestions and examples are welcome!
The GPS radio is a Garmin DBR-21 with firmware version 2.0. The antenna is a 1.3m "Loran/DGPS" fiberglass whip mounted on my roof with the antenna base approximately 5 meters above the ground level (or 30 meters above sea level). From this vantage point the antenna has a direct line of sight to the coastal mountain range. The radio is normally tuned to one of the following Coast Guard transmitters:
LINCOLN, CA Status: Operational RBn Antenna Location: 38° 50.77' N;121° 20.98' W REFSTA Ant Location (A): 38° 50.79042' N;121° 21.01318' W REFSTA Ant Location (B): 38° 50.79023' N;121° 21.03207' W REFSTA RTCM SC-104 ID (A): 210 REFSTA RTCM SC-104 ID (B): 211 REFSTA FIRMWARE VERSION: RE00-1C19 Broadcast Site ID: 764 Transmission Frequency: 314 KHZ Transmission Rate: 200 BPS Signal Strength: 100 uV/m AT 225 KM Distance from WSRCC: 95 miles PIGEON POINT, CA Status: Operational RBn Antenna Location: 37° 11.2' N;122° 23.4' W REFSTA Ant Location (A): 37° 11.22481' N;122° 23.39619' W REFSTA Ant Location (B): 37° 11.20943' N;122° 23.38603' W REFSTA RTCM SC-104 ID (A): 266 REFSTA RTCM SC-104 ID (B): 267 REFSTA FIRMWARE VERSION: RD00-1C19 Broadcast Site ID: 883 Transmission Frequency: 287 KHZ Transmission Rate: 100 BPS Signal Strength: 75uV/m at 180 NM Distance from WSRCC: 35 miles CHICO, CA Status: Operational RBn Antenna Location: 39° 25.8' N;121° 36' W REFSTA Ant Location (A): 39° 25.95802' N;121° 39.89677' W REFSTA Ant Location (B): 39° 25.97251' N;121° 39.89205' W REFSTA RTCM SC-104 ID (A): 256 REFSTA RTCM SC-104 ID (B): 257 REFSTA FIRMWARE VERSION: RD00-1C19 Broadcast Site ID: 878 Transmission Frequency: 318 KHZ Transmission Rate: 100 BPS Signal Strength: 75uV/m at 250SM Distance from WSRCC: 131 miles SPOKANE, WA Status: Operational RBn Antenna Location: 47° 31.16' N;117° 25.41' W REFSTA Ant Location (A): 47° 31.10105' N;117° 25.42097' W REFSTA Ant Location (B): 47° 31.10179' N;117° 25.40005' W REFSTA RTCM SC-104 ID (A): 68 REFSTA RTCM SC-104 ID (B): 69 REFSTA FIRMWARE VERSION: RD00-1C19 Broadcast Site ID: 848 Transmission Frequency: 316 KHZ Transmission Rate: 100 BPS Signal Strength: 75uV/m at 300 SM Distance from WSRCC: 724 miles POINT BLUNT, CA Status: Decommissioned RBn Antenna Location: 37° 51.19' N;122° 25.14' W REFSTA Ant Location (A): 37° 51.18291' N;122° 25.13584' W REFSTA Ant Location (B): 37° 51.1932' N;122° 25.16275' W REFSTA RTCM SC-104 ID (A): 268 REFSTA RTCM SC-104 ID (B): 269 REFSTA FIRMWARE VERSION: RD00-1C19 Broadcast Site ID: 884 Transmission Frequency: 310 KHZ Transmission Rate: 200 BPS Signal Strength: 100uV/m at 60 NM Distance from WSRCC: 33 miles SNR 30 db (night)
The Sprokane, WA site just showed up in the logs. I guess atmospheric conditions were just right one night.
IANA has assigned us an official TCP and UDP port number; port 2101.
The first releases of this client used a different port number which was a play on the official name of the protocol RTCM-SC104. Unfortunately that port had been officially assigned to another service. IANA has kindly assigned us the port 2101 (UDP and TCP) for DGPS service. Thank you, IANA.
If you have installed previous versions of this software with the old port number, please update your /etc/services file.
Currently there are two feeds for the following reference stations. To select the alternate feeds configure your client software to use the indicated host and port numbers.
![[1]](gps221.png){kind=link}
![[2]](cdf221.png){kind=link}
host: dgps.wsrcc.com
port: 2101
location: Pt. Blunt, CA USA 37.19 -122.39
type: Garmin GBR-21 w. 4ft. E-Field whip
host: gnssip.ing.uniroma1.it
port: 2101
location: Rome, Italy
(Courtesy of Mauro Venanzi, and the University of Rome
"La Sapienza")
European users can find information about European sites here, courtesy of Mauro Venanzi and his DGPS over IP server page.
The European reference station information can be found at the EUREF page.
If you have a spare RTCM radio or GPS reference station and would like to send a dgps correction stream to me for further redistribution from here please send mail to "dgpsip at wsrcc.com". I'm always looking to add new feeds. All you need is a full-time internet connection, a unix or Linux server and the single-client dgpipd server.
People connecting from sites that have slow or broken DNS servers will experience startup delays, or in extremely rare cases the startup will fail completely. Here's what's happening: the dgps-ip server starts off by attempting to look up the hostname associated with the IP address of the new connection. Start-up failure should only occur when your DNS is so botched that the server either can't reverse-map the name or can't get a lookup-failure notification within 15-30 seconds. If the connection is not accepted, you may want to make sure that there is a valid hostname associated with your IP address.
Some corporate sites have firewalls between the internal network and the Internet. The stated purpose is to keep evil hackers out. Unfortunately some firewalls are very badly misconfigured and will keep employees from sucessfully making connections to all but a few well-known ports (like www or ftp). If your corporate firewall blocks outgoing connections to port 2101, there isn't much the dgps-ip server can do. You'll probably have better luck connecting from an ISP.
The port 2101 server is a real Garmin radio, so it sends out the information to make the Garmin GPS's "INTERFACE" page happy. You should see the radio FREQ, RATE, DIST and SNR fields filled in.
The port 2103 server is directly attached to a real survey-grade GPS reference station without an intervening radio. There isn't any radio involved that could send the data that this page is looking for. This page should and will stay blank. This is not unexpected. To see if the GPS is in differential mode check the satellite status page. It should say "3D DIFF".
On most Garmin GPS's the EPE is the number on the top right of the satellite page. It says "EPE" just above a 2 or 3 digit number. The Garmin EMAP is a "feature-reduced" unit with some of the more math-oriented features deleted. It just won't tell you the EPE. To get a feel for the SA noise levels that you are seeing you'll have to run sawatch (see above) or dgpsip and look at the standard deviation numbers. You can also store a tracklog in memory and see how big the resulting "blob" is.
The dgps server tries to determine if the client code is attached to a GPS or if the client is just recording the data stream. The server is able to make this distinction only with certain versions of the client code. For an actual attached GPS-radio client, the server will send small timely interactive packets. For a recording client, the server tries to be much more efficient, and will buffer up the output until it has over 512 bytes and then send out the whole set of data out in one large packet. Since the small "interactive" GPS packets use up approximately twice as much internet bandwidth as a "bulk" packet, it is fairly important that we determine which kind of client is attached.
Currently the server will send 10 minutes worth of the more expensive interactive GPS packets. If in that time the client still hasn't sent any position reports, the server assumes that there isn't any GPS radio attached and will switch to bulk-mode packets. For those who are interested in the IP details, the server also switches the IP_TOS flag from "LOWDELAY" to "THROUGHPUT" at this time. This setting tells all the routers along the way that the packet under consideration isn't time-critical, and to use the same sort of efficient bulk-routing that ftp data gets.
Witten, Germany G12 4 sats EPE 66 ft rooftop Anchorage, Alaska USA GIII 5 sats EPE 46 ft Fremont, California USA G12xl 5 sats EPE 38 ft indoors Fremont, California USA G12xl 11 sats EPE 16 ft rooftop lowe ant Cambridge, Mass USA GII+ 4-5 sats EPE ~50 ft indoors Atlanta, Georgia USA G12 3 sats EPE 42 ft indoors Iowa Falls, Iowa USA G12 6 sats EPE 36 ft indoors Nenderson, Nevada USA GII+ 5 sats EPE 23 ft ? Seattle, Washington USA GIII+ 4-5 sats EPE 60 ft indoors Colorado Springs, CO USA G12 5 sats EPE 20 ft Dallas, Texas USA GIII+ 7 sats EPE 32 ft ext ant outside Graz, Austria GIII 4 sats EPE 100-170 ft roof window, mity-mouse ant Bethesda, Maryland USA GII+ 4 sats EPE 45 ft outdoors Minneapolis, Minn USA L-GM100 8 sats EPE 9 ft outdoors Columbia Falls, MT USA G12xl 5 sats EPE 20 ft ext ant indoors Idaho Falls, Idaho USA GII+ 6 sats EPE 34 ft indoors Carver, Mass USA G12XL 5-6 sats EPE 40 ft ext ant outdoor roof Medford, Oregon USA GIII 9 sats EPE 26 ft outdoors Calgary, Alberta Canada G12XL 7 sats EPE 26 ft indoors Santa Maria, Ca USA G12XL 5 sats EPE 22 ft indoors Portland, Oregon USA GII+ 5-6 sats EPE 51-60 ft indoors Muncie, Indiana USA G-ST-PLT 4 sats EPE 50 ft indoors Houston, Texas USA GIII - EPE 26 ft indoors Houston, Texas USA GIII 5-6 EPE 32 ft outdoors ext lowe ant Vancouver, BC Canada L-GNAV212 6-9 sats EPE 6-15 ft indoors window Broomfield, Colorado USA G12 7 sats EPE 23 ft Burlington, Onterio CAN L-GM100 8 sats EPE 4 ft indoors Bray, Ireland G12 3 sats EPE 82 ft Wallingford, CT USA G12XL 7 sats EPE 60 ft basement lowe ant Zeist, Holland G12CX 5 sats EPE 25 m indoors Sonora, CA USA G12 9 sats EPE 16 ft roof Global-link ant Adelaide, South Australia G12XL 3 sats EPE 36 metres Lowe ant outside (East wall) Metz, France G12XL 3 sats(2d) EPE 33-37meter rooftop Sunnyvale, California USA G12XL 8 sats EPE 21 ft rooftop Altus, Oklahoma USA GIIIPilot 4-6 sats EPE 20 ft indoors ext. amplified ant Chattanooga, Tennessee USA GIII+ 4 sats EPE 44 ft indoors Ancton, W. Sussex, England G12XL 3 sats EPE 42 ft Garage rooftop Manteca, CA, USA GIII+ 7 sats EPE 9 ft indoors Emden Germany GIII 4 sats EPE 34 ft external roof Walla Walla, WA USA eTrex 7 sats EPE 5 ft indoors Colorado Springs, CO USA GIII+ 9 sats EPE 7 ft rooftop (Lowe Ext Antenna)
An xearth/xglobe marker file and a Street Atlas 6.0 latlon file are available that shows where previous connections have come from. Here are small and large earth pictures with the locations of DGPSIP users plotted on them. Europe is visible at approximately the 1:30 position. To display the markers in SA6 import the file into SA6 with the "import lat-lon file" pull-down. From a unix shell use the following:
Please note, the xearth screenshot only shows the parts of the world that are within 90 degrees of longitude of the WSRCC reference station. While users on the opposite side of the world could in theory have a thin ring of satellites in common with us, the probability of that is vanishingly small. In practice, those users 90 degrees or more away in longitude already have severe problems with DGPSIP.
If you want to be included in the "User Reports" listing, please make sure that you are running either a recent version of the Un*x dgpsip client, Jeff's WinDGPS, or SAWatch. Also make certain that your GPS is set up to send NMEA data back to the client as outlined in the previously mentioned README. The server will then automatically log the approximate latitude and longitude of the remote user.
The 6-month dgps-ip server Usage Summary complete with client software, version info, and approximate lat/lon is available.
Enjoy and send EPE reports to dgpsip@charlotte.dontspam.wsrcc.com and bug reports to dgpsip-bugs@charlotte.dontspam.wsrcc.com
Due to popular demand, I've released a GPL-ed single-client server for Netbsd, Openbsd, Freebsd and Linux.
If you want to simultaneously use both the dgps-program and a third party mapping program you have a small dilemma. Both programs will want to have exclusive use of the com port and to talk to the GPS directly. If you have two free serial ports you can make a Y-cable and let each program have its own port. You will still need to set your GPS to send NMEA out and expect RTCM as input.
tx ------------ rx
dgps-program com port 1 gnd -------+---- gnd gps
rx -----+-|---- tx
| |
map-program com port 2 rx -----+ |
gnd -------+
If you don't have two free com ports, but have two computers with one free com port each then you can do the same thing by running the dgps-program on a second computer. Barring that, you'll have to push on your mapping program vendor to incorporate internet dgps into their program.
A retrospective of the first 1.3 years of running the dgpsip server.
I get these questions quite a bit, so I decided to save a bit of time and answer them here.
Q: How does DGPS work?
A: Plain GPS's work by measuring the distance to each visible GPS satellite (called the pseudorange). The GPS then calculates its own position using triangulation from these pseudoranges. Atmospheric distortions and intentional errors (in the case of Selective Availability) will add errors to the pseudorange measurements. DGPS reference stations sitting in precisely surveyed locations can measure these errors and then send out pseudorange corrections for each of the satellites visible to it. In DGPS mode, the GPS simply corrects its own pseudorange measurements by the amount the DGPS reference station indicates. The GPS then performs the triangulation calculations to work out its own position.
Q: I don't have an internet connection where I am going. Can I just use two GPS's and subtract the readings?
A: This is jokingly referred to as "Poor Man's DGPS". It doesn't work in practice.
Q: Can I download some corrective data from the internet after taking a field reading?
A: Yes, if you have the right kind of GPS. Survey grade GPS'S will record enough information to allow this kind of post processing. The only consumer grade GPS that is advertised to do this is the Delorme Earthmate GPS when used in conjunction with Delorme's "Post Pro" software and a portable computer.
In addition, some Garmin handheld units may also implement an undocumented garmin/garmin packet type that can be used to generate the pseudorange from. See Garmin async packet tools.
Q: I've heard some internet sites can post-process NMEA. Is there anything to that claim?
A: I've never seen a before and after plot of such data. Until independent test results are published on the net, I'm inclined to believe that this is simply a variation of the poor man's dgps -- something that works sometimes but can't be counted upon.
.
![[ Powered by Fedora Core ]](/icons/powered_by_fedora.png){kind=icon}
wolfgang.rupprecht+web@gmail.com
(Wolfgang S. Rupprecht)
WSRCC Home Page || Up One
Level
..