Using the GPS12 for precise (sub-meter) accuracy


Introduction


Nowadays all handheld GPS recievers are provided with an RS232 connection enabling upload/download of data between receiver and computer. A well known standard protocol coming from the world of boats and ships is NMEA. Most people will use this serial connection to connect to automatic onboard steering gear, radar, fishfinders or small computers dispaying onscreen position and routes for use in autonavigation. But all Garmin GPS types are able to communicate to the outside world of bits and bytes in their own brandspecific way: the Garmin protocol. Parts of this protocol are published but information on certain formats of records in this protocol is not available.

But nowadays we have internet as a medium to bring people with the same interest together. So literally bit by bit most of the meaning of the bits and bytes in certain types of records was discovered in due time. Programs were made and tested so that now we can get the following kind of data out of a Garmin GPS like mine GPS12: pseudoranges and phase, Doppler shift data and broadcast ephemeris (navigational messages). This is the kind of data that is needed to use postprocessing techniques. Software is available to convert this Raw Garmin Data to standard RINEX files that are usable in most surveyer-type postprocessing software like Geogenius (now Total Control) from Trimble/Terrasat or OMNI (free MS-DOS software).
Also I found out that the old program from Magellan with the name MSTAR is also useable.

My setup


I use a Garmin GPS12 with software version 4.58. Data is collected on the RS232 port of an old NEC desktop running MS-DOS. Batteries can keep this computer going for 1 1/2 hour so this sets the maximum observation timeduration. Raw data is first written in memory (RAM-disk) and - on the end of the observation period - read, converted to RINEX and written to harddisk. This results in RINEX files of a few megabyte for each session.

The University of Delft was so kind to give me free access to the data of the Reference Station DELFT. This way I have baselines of about 15-20 km. This distance is considered short to medium by professionals.

Measurements


I started with measuring a corner of my roof. To the south the view is blocked for about 30 degrees and in the North-west direction for 20 degrees. North and East have a free view.
All positions are converted with help of the CC40 calculator (follow link 'download') to the RD-system and heights to the RDNAP plane. Some of my first results are:
Date/time Timespan (sec) Easting Northing HeightBadness
21/02/2002 3600093397.828463353.0299.7306.2
27/02/2002 8700093397.835463353.2708.23731.4
27/03/2002 1800+900+600+600093397.473463352.9139.77721.5
10/04/2002 3x1200093397.762463353.0559.55331.1
12/04/2002 960+D093397.954463353.0929.465231.8
17/04/2002 3600093397.484463353.8979.64230.4
20/04/2002 3x5400093397.847463353.1729.7733.0
20/04/2002 2x7200093399.767463351.9459.390646.6
20/04/2002 5400093397.855463353.0329.6535.3
23/04/2002 6000093397.875463353.1439.7463.2
25/04/2002 5400093397.856463353.1499.8016.4
25/04/2002 1800+D093398.200463353.0279.876128.4
01/05/2002 5400093397.776463353.1269.99812.3
07/05/2002 5400093397.909463353.1249.75712.3
13/05/2002 2x5400093397.909463353.1619.7363.8
26/06/2002 5400093397.770463353.1199.68910.5
02/07/2002 5400093397.816463353.1509.6807.9
17/07/2002 5400093397.833463353.1229.6708.4
29/08/2002 3x3600093397.745463353.1239.7249.1
10/10/2002 5400093397.787463353.0979.6766,3

Some explanation for this table of Double Difference (Float) results (so they call this solution):


A closer look at the data


  1. Every time I tried to get Doppler Data out, a lot of reading errors were reported. After 50 errors the logging program shuts down. So on 12/04/2002 only 16 minutes were gathered and on 25/04/2002 I was lucky to get 1800 seconds of data (with 49 read-errors in it: fragmented data!). These are also very short observationtimes (compared to other observations). In both cases there was a big 'Badness' reported. This 'badness-number' is reported by Geogenius on the Project Plot and is given in mm. What this number represents exactly is not clear to me.
  2. We live in a time of much solar activity. Sometimes we have bad weather in space. This results in all kind of noise in the data. Very clearly this is the case on 20/04/2002. I would expect that two consecutive series of 7200 seconds (two times two hours!) would give a nice result. but no, the badness is an awfull 646.6 and does not diminish when the two are taken separately. A view of the data shows
    spacestorm hits
    a lot of yellow markers. These indicate loss of lock and the red makers indicate uncorrected cycleslips. And that happened a lot making the data useless. These data were taken in the evening after 18.00 local time. Maybe also a spaceweather effect is responsible for the results on 01/05/2002 where 21 cycle slips occured and 10 could not be repaired. An indication of trouble gives the 'triple difference solution'. There is nearly always no residuals after two iterations: now there were 4 iterations and the solution started converging from a long way off.
  3. Before the storm on the same day the data from 13.00 hour onwards gave a badness of only 5.3 but nearly all cycle slips (there were a few) could be repaired.
  4. In the 1 hour data of 17/04/2002 there were a total of 21 cycle slips and only 9 were repaired. You see that 'cycle slip fixing' is a very important task. It resulted in a badness of 30.4.
  5. Good data has to have a badness of about 10 or less and not many unrepaired cycle slips.
  6. There surely is a multipath problem. There are flat metal surfaces around but only inspection of the data of individual satellites will give an indication when this problem rears it ugly head. I have not done this yet.

Are my results relevant?


A good way to verify the results is: go to a place that was measured by professionals. I found such a quiet place with good view all around: RD-stone 319330 Zuiddijk Hazerswoude is part of the GPS KernNet and the accurate position was given to me in ETRS89 coordinates. (Is about the same as WGS84)
A period of 55 minutes on the 24 of april was used to gather data from this point. Subseqent postprocessing revealed me a position of
100824.378 / 456543.373 while in reality it is
100824.367 / 456543.432 so that fits very well. The 'Badness' was 10.7 so a very reasonable quality solution was obtained.
The full report can be seen here.

To get an independent verification of the used mathematics the data was also postprocessed bij P4 (of Gringo, the postprocessing software of the Univ. of Nottingham). The best solution (type carrier phase) this software came up with is: 100824.327 / 456543.412 an indication that no big errors were made in all the computations and Geogenius can be used for further measurements.

A short report by P4 and some pictures are available here.

Also I had for a short time the GrafNav/GrafNet software from Waypoint Consultion Inc (Canada) available. After some initial hassles I could get 3 results. The first is the float solution of
100824.427 / 456543.344 and the next is what is called a Quick Static Solution. 'If you have bad data, try a Quick Static. This method is less sensitive to loss of lock etc.' tells the manual. This method gives (nearly) the same result as the float solution. To my surprise also a "Fixed Static" was possible. But this method has much trouble with bad data. And that is the case here also:
100824.137 / 456543.134 is way off in the red as the program indicated. For those wanting to see more: here is a page with more text and nice graphics.

It should not come as a surprise that the same observation data gives different positions. It is a well known fact that there are small lies, big lies and statistics.
I did - nearly a month later on the 17 of may - a second measurement for 1 1/2 hour and the result was:
100824.244 / 456543.355 what leads me to remark: with the first measurement I was lucky: only 11 / 59 mm off mark. This second result is with 123 / 77 mm much worse.

Another useable surveyed point found

By being physically on the spot when two surveyers with a professional Leica measured a hollow positioningtube between pavement stones (pure coincidental meeting) in nearby Leiderdorp, I came to know (by asking them) the exact position (within about 2 1/2 cm I was told) of this point. It was
095715.722 / 464995.207
Photographs of this place on the earth are here.
The next morning of the 26 of june 2002 I went back there and took measurement for an hour. It did not look well: very few satellites were available: 4 only and sometimes 5 for a short while, so I did not expect any good results. And it became more bad. Inspecting the station results of Delft I saw that during the second half of the time of my measurements data collection in Delft was intermittently on/off fifty percent of the time. But sometimes you are in luck, and that was the case here. I found as position:
095715,748 / 464995,217 and that is only centimeters off with a badness of 19.2. So a possible error in the Northing of only 26 mm and the Easting of 10 mm. That is within the possible errorrange of 25 mm. of the 'real' position. Of cause, one is only one times lucky.
Another measurement of 1 hour on the 17 of juli in the evening before sunset gave a different result:
095715.783 / 464995.297 and a badness of 16.2. So now I am 61 mm and 90 mm off.
To make it 3 times I did measurement of 1 hour on sept 12 in the middle of the day. That measurement gave a position of
095715.619 / 464995.246 with a badness of 15.1 and this is a difference to the know positition of 103 mm / 39 mm only.

Finding outriders

The first important thing to mention is: you need a good view of the sky. No trees around and no walls or buildings blocking part of the sky resulting in only a few (4/5) visible satellites. What goes for treebranches (they give intermittant satellite reception!) also goes for people. It is very nice to have attention and questions of passersby but their bodies block reception very effectively. A way to prevent this source of error from happening is: put the GPS above head-height.
Then there are solar storms (we are in a 11-year solar maximum at the moment) hitting the earth, there are planes passing overhead making maybe multipath signals, etc. The 'badness' that GeoGenius gives is a good indicator. An inspection of the number of cycle-slips and not-recovered locks gives me a handle on the reason for the badness. All in all I can be quite sure in my decision that a given observation will be within a 20 cm of the real position or not.
When I make a plot of all the observated positions I see this:

On the x-axis the spacing is 50 cm between the lines and on the y-axis it is also 50 cm. When if I take out all measurements that have a badness of 30 or higher I get the following plot:

On the x-axis the lines are separated with a distance of 10 cm and on the y-axis it is 5 cm. The point that is way out from the others is the observation of 27 febr. when 4 short measurements were taken during an afternoon. So surely this is not a way to go.

Conclusion

When there is a good view of the sky, there are no obstacles blocking reception for short times, more than 5 satellites in view all the time and the observations have a timespan of 1 to 1 1/2 hour, then I expect with reasonable confidence that my measured position will be within 20 cm of the real position.

Last remark

I have no software that can solve for half-wavelength ambiguities and do a fixed solution. So maybe there is much more in the data than meets my eye.
Also there are not many observations left to do statistics with. No statistical significant numbers can be given for the confidence levels of the 2-dimensional distribution.
Concerting measurement of height: a simple look at the table of observations shows for the 'valid' ones a range of about 40 cm up/down. This is not a surprise because a rule of thumb says: 'the vertical is at least two times worse off then the horizontal'.

Thanks

My thanks go to the following persons, firms and organizations that made these experiments possible:

Ronald J. van der Kamp