Article: 101787 of sci.geo.satellite-nav From: Antonio Tabernero Galan Newsgroups: sci.geo.satellite-nav Subject: Fractional Phase in Garmin GPS12 Date: Fri, 23 Jun 2000 12:48:02 +0200 Organization: Universidad Politecnica Madrid Lines: 133 Message-ID: <39534062.A4E81916@fi.upm.es> NNTP-Posting-Host: hyundai.ls.fi.upm.es Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: panoramix.fi.upm.es 961757396 23388 138.100.10.50 (23 Jun 2000 10:49:56 GMT) X-Complaints-To: news@panoramix.fi.upm.es NNTP-Posting-Date: 23 Jun 2000 10:49:56 GMT X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.10 i686) X-Accept-Language: en Path: b4.mv.meer.net!Usenet!feed2.newsfeeds.com!newsfeeds.com!newsfeed.direct.ca!look.ca!newsfeed.icl.net!newsfeed.icl.net!newsfeeds.belnet.be!naxos.belnet.be!news.belnet.be!news.rediris.es!news-2.rediris.es!138.100.251.9.MISMATCH!news.upm.es!panoramix.fi.upm.es!not-for-mail Xref: b4.mv.meer.net sci.geo.satellite-nav:101787 Recently I wrote a small report and programs (to be found in http://artico.lma.fi.upm.es/numerico/miembros/antonio/async/ about how to get raw data from a Garmin GPS12 or XL (by the way I would be interested if people owning other models such as the GIII+, Emap, etc. could confirm if this also works for them). In that report I wrote, concerning a field in the 0x1a record: Name ??? Position bytes 3-4 Type unsigned int Description (??) Seems to vary randomly. Only 11 bits are used. Jose Maria hinted that the GPS25 used that format for the fractional phase, but it seems an unlikely place for that info. I thought it an unlikely place because all the interesting data seemed to be in records 0x38 properly time-tagged. Records 0x1A, on the other hand, don't have a time stamp, and without that the phase info would be useless. However, by examining the data stream sent by the GPS12, I realized that a 0x1a record always followed a group of 0x38's. Moreover, there is a field (signal_strenth) that appears in both records. If there has been no missing records, the signal_strenth field (one for each channel) of the 0x1a record mirrors the signal_strenth field of the preceding 0x38 records. Therefore, it was now possible, by monitoring this signal_strenth field, to time-tag this hypothetical fractional phase. I decided to give it a try, adding the fractional phase to the already known integer phase in record 0x38 (in those cases where the signal_strength field was the same). Next I run the following test to verify that the result was good. I don't know that much about GPS data postprocessing so I would appreciate if someone more familiar with this subject detects a major flaw in my reasoning. I got the basics from "Understanding GPS" (Artech House, 1996, E.Kaplan, Ed.). Two GPS12 (actually a 12 and a 12XL, both using their internal antennas) were placed about 15 mt apart, and using the above mentioned programs, I got the phase measurements every second for about 5 minutes. I obtained singles differences by subtracting for each tracked satellite the phase measurements at both locations (thus removing the sat clock bias): Repeat for all sats and for all epochs: sd_phase[sat k] = phase_2[sat k] -phase_1[sat_k] Then I chose a sat with good elevation (actually prn 1) and computed double differences: dd_phase[sat k] = sd_phase[sat_k] - sd_phase[sat 1] for each epoch (removing the combined clock error of both receivers). Now to the results. I performed the above procedure with only the integer phase and with the integer phase + the fractional phase (as deduced from the 0x1a field). The following link (12K) points to a figure displaying the results: JPG http://artico.lma.fi.upm.es/numerico/miembros/antonio/phase/fig1.jpg EPS http://artico.lma.fi.upm.es/numerico/miembros/antonio/phase/fig1.eps The figure shows the double differences between sat 4 and sat 1 for the integer phase (left). To the right, the same double differences when the fractional phase is added. Note the 20 cm (L1 wavelength) jumps in the left side. In the right side, the jumps disappear, and the resulting curve is quite smooth (except for a small jump of about 15 cm, maybe a cycle slip??). In order to appreciate what kind of improvements we could be obtaining if this info could be used in phase DGPS I repeated the same procedure for the pseudorange info, thus obtaining the pseudorange or code double differences. The following figure displays on the same scale the three results: DD integer phase (green), DD fractional phase (red), and DD pseudo ranges: http://artico.lma.fi.upm.es/numerico/miembros/antonio/phase/fig2.jpg http://artico.lma.fi.upm.es/numerico/miembros/antonio/phase/fig2.eps It is clear the much more noisier nature of the pseudorange info. Remember that only that info is used in common DGPS (pseudorange DGPS). Based on these results I would rewrite the above description as: RECORD 0x1A: --------------------------------------------- Name fractional_phase Position bytes 3-4 Type unsigned int (only uses 12 bits) Description A number between 0 and 2047. Divided by 2048 it represents the fractional phase at the receiver time indicated in the previous bunch of 0x38 records. Sure enough, I could be wrong (remember that a couple weeks ago I was thinking that this should not be the fractional phase). However, the results of the double differences (similar results were obtained for the other sats) seem quite conclusive to me (again, since that's not a big assurance, I'd sure appreciate comments from more knowledgeable people). Next step would be to incorporate this info in my RINEX generator program and see what we can do with the results. Regards, Antonio -- Antonio Tabernero Galan E-mail: ant@fi.upm.es Facultad de Informatica (UPM). Article: 102157 of sci.geo.satellite-nav From: Sam Storm van Leeuwen Newsgroups: sci.geo.satellite-nav Subject: Re: Fractional Phase in Garmin GPS12 Date: Mon, 26 Jun 2000 09:56:08 +0200 Organization: National Aerospace Laboratory NLR Lines: 156 Message-ID: <39570C98.250EE554@nlr.nl> References: <39534062.A4E81916@fi.upm.es> NNTP-Posting-Host: pcvo050a.nlr.nl Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: simian.nlr.nl 962006170 715812 137.17.196.228 (26 Jun 2000 07:56:10 GMT) X-Complaints-To: mvdberg@news.nlr.nl NNTP-Posting-Date: 26 Jun 2000 07:56:10 GMT X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en Path: b4.mv.meer.net!Usenet!feed2.newsfeeds.com!newsfeeds.com!news-peer.gip.net!news.gsl.net!gip.net!newsfeed.mathworks.com!newsfeed2.news.nl.uu.net!sun4nl!surfnet.nl!news!not-for-mail Xref: b4.mv.meer.net sci.geo.satellite-nav:102157 Hi Antonio, This is where version numbers may give different results. In my 12XL v 3.62 the data in 0x1a bytes 3-4 behaves different. I found however in a zero baseline test (both the 12XL and a geodetic quality reference receiver connected to the same antenna via a splitter) that message 0x38 bytes 1-4 give integrated phase cycle count AND fraction (convert the 4 bytes as an unsigned longint, then didivde by 2048 or 2^11, the result rolls over at 2097152 or 2^21). Forming double differences in a zero baseline setup should give constant numbers, which was the case, and the numbers should be cloe to an integer value, which unfortunately was NOT the case. Some double differences converge to an integer, some to half an integer (half cycle ambiguity). I observed this behaviour also with the 25LP OEM boards. But to make thing worse, I also saw some double difference converge to 0.3 and others to 0.8. And this is where my understanding fails! Sam Antonio Tabernero Galan wrote: > Recently I wrote a small report and programs (to be found in > > http://artico.lma.fi.upm.es/numerico/miembros/antonio/async/ > > about how to get raw data from a Garmin GPS12 or XL (by the > way I would be interested if people owning other models such > as the GIII+, Emap, etc. could confirm if this also works > for them). > > In that report I wrote, concerning a field in the 0x1a record: > > Name ??? > Position bytes 3-4 > Type unsigned int > Description (??) Seems to vary randomly. Only 11 bits are used. > Jose Maria hinted that the GPS25 used that format > for the fractional phase, but it seems an unlikely > place for that info. > > I thought it an unlikely place because all the interesting data > seemed to be in records 0x38 properly time-tagged. Records > 0x1A, on the other hand, don't have a time stamp, and without > that the phase info would be useless. > > However, by examining the data stream sent by the GPS12, I > realized that a 0x1a record always followed a group of 0x38's. > Moreover, there is a field (signal_strenth) that appears in > both records. If there has been no missing records, the > signal_strenth field (one for each channel) of the 0x1a > record mirrors the signal_strenth field of the preceding 0x38 > records. Therefore, it was now possible, by monitoring this > signal_strenth field, to time-tag this hypothetical fractional > phase. > > I decided to give it a try, adding the fractional phase to > the already known integer phase in record 0x38 (in those cases > where the signal_strength field was the same). > > Next I run the following test to verify that the result was > good. I don't know that much about GPS data postprocessing > so I would appreciate if someone more familiar with this > subject detects a major flaw in my reasoning. I got the basics > from "Understanding GPS" (Artech House, 1996, E.Kaplan, Ed.). > > Two GPS12 (actually a 12 and a 12XL, both using their internal > antennas) were placed about 15 mt apart, and using the above > mentioned programs, I got the phase measurements every second > for about 5 minutes. > > I obtained singles differences by subtracting for each tracked > satellite the phase measurements at both locations (thus removing > the sat clock bias): > > Repeat for all sats and for all epochs: > > sd_phase[sat k] = phase_2[sat k] -phase_1[sat_k] > > Then I chose a sat with good elevation (actually prn 1) and > computed double differences: > > dd_phase[sat k] = sd_phase[sat_k] - sd_phase[sat 1] > > for each epoch (removing the combined clock error of both > receivers). > > Now to the results. I performed the above procedure with > only the integer phase and with the integer phase + the > fractional phase (as deduced from the 0x1a field). > > The following link (12K) points to a figure displaying the results: > > JPG http://artico.lma.fi.upm.es/numerico/miembros/antonio/phase/fig1.jpg > > EPS http://artico.lma.fi.upm.es/numerico/miembros/antonio/phase/fig1.eps > > The figure shows the double differences between sat 4 and sat 1 > for the integer phase (left). To the right, the same double > differences when the fractional phase is added. > Note the 20 cm (L1 wavelength) jumps in the left side. > In the right side, the jumps disappear, and the resulting curve > is quite smooth (except for a small jump of about 15 cm, maybe a > cycle slip??). > > In order to appreciate what kind of improvements we could be > obtaining if this info could be used in phase DGPS I repeated the > same procedure for the pseudorange info, thus obtaining the > pseudorange or code double differences. > > The following figure displays on the same scale the three results: > DD integer phase (green), DD fractional phase (red), and DD pseudo > ranges: > > http://artico.lma.fi.upm.es/numerico/miembros/antonio/phase/fig2.jpg > http://artico.lma.fi.upm.es/numerico/miembros/antonio/phase/fig2.eps > > It is clear the much more noisier nature of the pseudorange info. > Remember that only that info is used in common DGPS (pseudorange > DGPS). > > Based on these results I would rewrite the above description as: > > RECORD 0x1A: > --------------------------------------------- > Name fractional_phase > Position bytes 3-4 > Type unsigned int (only uses 12 bits) > Description A number between 0 and 2047. Divided by 2048 it > represents the fractional phase at the receiver > time indicated in the previous bunch of 0x38 > records. > > Sure enough, I could be wrong (remember that a couple weeks > ago I was thinking that this should not be the fractional phase). > However, the results of the double differences (similar > results were obtained for the other sats) seem quite > conclusive to me (again, since that's not a big assurance, > I'd sure appreciate comments from more knowledgeable people). > > Next step would be to incorporate this info in my RINEX > generator program and see what we can do with the results. > > Regards, > > Antonio > -- > Antonio Tabernero Galan > E-mail: ant@fi.upm.es > Facultad de Informatica (UPM).