Article: 137644 of sci.geo.satellite-nav Sender: wolfgang@capsicum.wsrcc.com Newsgroups: sci.geo.satellite-nav Subject: Re: Garmin-Garmin protocol vs NMEA References: <00a1bc3d.7376463a@usw-ex0110-076.remarq.com> <06f57f7b.a4b91803@usw-ex0110-075.remarq.com> From: Wolfgang Rupprecht Message-ID: Organization: W S Rupprecht Computer Consulting, Fremont CA Lines: 59 User-Agent: Gnus/5.08 (Gnus v5.8.3) Emacs/20.5 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 20 Mar 2000 05:16:09 GMT NNTP-Posting-Host: 24.1.65.208 X-Complaints-To: abuse@home.net X-Trace: news1.frmt1.sfba.home.com 953529369 24.1.65.208 (Sun, 19 Mar 2000 21:16:09 PST) NNTP-Posting-Date: Sun, 19 Mar 2000 21:16:09 PST Path: news1.meer.net!news3.best.com!news1.best.com!sdd.hp.com!enews.sgi.com!news.idt.net!feeder.via.net!24.0.94.134.MISMATCH!newshub1.home.com!news.home.com!news1.frmt1.sfba.home.com.POSTED!not-for-mail Xref: news1.meer.net sci.geo.satellite-nav:137644 fcm writes: > Thanks for your reply. It's exactly what I'm looking for. I > already decoded a few 0x1C responses. > Do you have other tokens/sentences to share? You're welcome. If I had any more info I would certainly share it. I have some hunches that the following are the pseudorange and clock offsets but I'm not very good at decoding stuff like this. Unknown Packet Type 0x38, Len 37. 0b 78 80 8e 00 63 55 ff aa 7b 0f d0 11 01 f7 85 d5 f5 ef 13 50 41 88 d0 2e 3c 4b 06 39 66 65 5c 14 7d ee 40 19 Unknown Packet Type 0x37, Len 33. 18 20 00 00 f8 1f b7 7b 5d 07 1f 1e 03 e5 e0 0f 81 41 88 d0 2e 3c 39 66 65 5c 14 7d ee 40 01 00 19 Unknown Packet Type 0x38, Len 37. c8 7f 23 68 00 26 dc fe 9a 86 6f 04 ad 00 cf d4 27 1b 07 e7 4a 41 88 d0 2e 3c 62 06 39 66 65 5c 14 7d ee 40 07 Unknown Packet Type 0x37, Len 33. 16 20 00 00 87 10 a6 86 0d 01 7b 4a a0 76 66 90 80 41 88 d0 2e 3c 39 66 65 5c 14 7d ee 40 01 00 07 type: 0x36, len 9. 10 36 09 / 3e bf 11 00 / 67 7a ee fc / 10 (10) d8 / 10 03 10 36 09 / 3e bf 11 00 / d8 fa 87 fc / 16 48 / 10 03 10 36 09 / 3e bf 11 00 / 85 cd 60 fc / 05 00 / 10 03 (10,16,05 were the sv's with non-zero signal strenghts) > I want to "clear" the GPS Tracks, Waypoints and Routes by > software. I don't think garmin thought of that need. Garmin is not shy about using their undocumented commands in their own programs when they see a need. I wouldn't imagine that they would not add that obvious capability to mapsource if their current GPS's allowed for it. > I know that some aviations products can even > accept a map uploading. Some of the handheld ones do too now. > The "events" (PID 13. 0x0D) are also interesting; can the > be sent back to the unit? I don't know. I've never played with it. It would be interesting if one could simulate keypresses and clear the waypoints that way. -wolfgang -- Wolfgang Rupprecht http://www.wsrcc.com/wolfgang/ DGPS signals via the Internet http://www.wsrcc.com/wolfgang/gps/dgps-ip.html Article: 138100 of sci.geo.satellite-nav From: "Jose María Muñoz" Newsgroups: sci.geo.satellite-nav Subject: RE: Garmin protocol and pseudoranges Date: Fri, 24 Mar 2000 14:09:49 +0100 Organization: Universidad de Valladolid - Spain Lines: 42 Message-ID: <8bfpcn$egb$1@simancas.uva.es> References: <38D7861C.1270E689@cru.fr> <38D7A46A.6756B955@cwnet.com> <38D89CBB.1ADC2E3B@cru.fr> <3sdhdskegmet24s0vvtct38va76l93rl7o@4ax.com> NNTP-Posting-Host: gauss.ele.cie.uva.es X-Trace: simancas.uva.es 953903319 14859 157.88.41.126 (24 Mar 2000 13:08:39 GMT) X-Complaints-To: usenet@news.uva.es NNTP-Posting-Date: 24 Mar 2000 13:08:39 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Path: news1.meer.net!news3.best.com!news2.best.com!news.maxwell.syr.edu!newsfeeds.belnet.be!naxos.belnet.be!news.belnet.be!news.rediris.es!news.uva.es!not-for-mail Xref: news1.meer.net sci.geo.satellite-nav:138100 Wolfgang Rupprecht writes: > > The commands may turn out to be strikingly similar in the data layout, > but they are not the same. The 25/35 uses command 0x29 len 0xE2. The > other garmins don't. My suspicion is that on the other garmins its a > combination of async commands 0x36, 0x37, 0x38. Anyone with access to > a real gps that outputs pseudorange might be able to spot which > long-word in these messages corresponds to the current psuedoranges. > > -wolfgang > -- My work with a Garmin GPS12. (Firmware revision: 4.53 ) confirms partially your ideas: I think that this unit ouputs pseudoranges AND both phase and integrated phase info. All these data are contained in asyncronous messages sent from the unit when enabled. The best way to test them is to enable all async events. With a lot of guess, I think I have found the following data: Message: Data 0x16 pseudorange and perhaps doppler info 0x1A elevation, phase and signal quality 0x33 Position, velocity, time 0x36 a 50Hz counter and some obscure data (for each tracked satellite) 0x38 Pseudorange, integrated phase, signal strength, Time of week, 1KHz counter and 511500Hz counter (Half of the bit rate of the C/A code ) There is a lot of data not yet analyzed. Of course, more info on this subjet is wellcome. Jose María. jmmm@ee.uva.es Article: 138131 of sci.geo.satellite-nav Sender: wolfgang@capsicum.wsrcc.com Newsgroups: sci.geo.satellite-nav Subject: Re: Garmin protocol and pseudoranges References: <38D7861C.1270E689@cru.fr> <38D7A46A.6756B955@cwnet.com> <38D89CBB.1ADC2E3B@cru.fr> <3sdhdskegmet24s0vvtct38va76l93rl7o@4ax.com> <8bfpcn$egb$1@simancas.uva.es> From: Wolfgang Rupprecht Message-ID: Organization: W S Rupprecht Computer Consulting, Fremont CA Lines: 24 User-Agent: Gnus/5.08 (Gnus v5.8.3) Emacs/20.5 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Date: Fri, 24 Mar 2000 19:17:29 GMT NNTP-Posting-Host: 24.1.65.208 X-Complaints-To: abuse@home.net X-Trace: news1.frmt1.sfba.home.com 953925449 24.1.65.208 (Fri, 24 Mar 2000 11:17:29 PST) NNTP-Posting-Date: Fri, 24 Mar 2000 11:17:29 PST Path: news1.meer.net!news3.best.com!news2.best.com!news.maxwell.syr.edu!newshub2.home.com!news.home.com!news1.frmt1.sfba.home.com.POSTED!not-for-mail Xref: news1.meer.net sci.geo.satellite-nav:138131 "Jose María Muñoz" writes: > Message: Data > 0x16 pseudorange and perhaps doppler info > 0x1A elevation, phase and signal quality > 0x33 Position, velocity, time > 0x36 a 50Hz counter and some obscure data (for each tracked > satellite) > 0x38 Pseudorange, integrated phase, signal strength, Time of > week, 1KHz counter and 511500Hz counter (Half of the bit rate of the C/A > code ) Jose, this is very impressive! Thanks for posting this. Quite a few folks have expressed interest in postprocessing garmin data. I don't know if you saw it but there is some source code available for post-processing. http://callisto.worldonline.nl/~samsvl/software.htm -wolfgang -- Wolfgang Rupprecht http://www.wsrcc.com/wolfgang/ DGPS signals via the Internet http://www.wsrcc.com/wolfgang/gps/dgps-ip.html Article: 138804 of sci.geo.satellite-nav From: "Jose María Muñoz" Newsgroups: sci.geo.satellite-nav Subject: About Garmin protocol Date: Thu, 30 Mar 2000 14:07:33 +0200 Organization: Universidad de Valladolid - Spain Lines: 273 Message-ID: <8bvg2h$lp2$1@simancas.uva.es> NNTP-Posting-Host: gauss.ele.cie.uva.es X-Trace: simancas.uva.es 954418065 22306 157.88.41.126 (30 Mar 2000 12:07:45 GMT) X-Complaints-To: usenet@news.uva.es NNTP-Posting-Date: 30 Mar 2000 12:07:45 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Path: news1.meer.net!news3.best.com!news1.best.com!su-news-hub1.bbnplanet.com!news.gtei.net!newsfeed.berkeley.edu!ptdnetP!newsgate.ptd.net!newsfeed00.sul.t-online.de!t-online.de!newsfeeds.belnet.be!naxos.belnet.be!news.belnet.be!news.rediris.es!news.uva.es!not-for-mail Xref: news1.meer.net sci.geo.satellite-nav:138804 In the last few weeks, it seems that some people is interested in the Garmin proprietary communications protocol. In particular in the extraction of raw GPS data from "low end" handheld units. With some work, a lot of guess and with a reduced set of data, I have obtained this information. Some data that I have considered constant, may not be so constant (mainly the high bytes of some counters) due to the above said narrow time slot used. Of course!, I am in no way related to Garmin, and all this information is ONLY my opinion about the meaning of the stream of data. First of all, I want to thank William Soley for the compilation of his document about the undocumented commands. http://playground.sun.com/pub/soley/garmin.txt My preliminary observations on the more or less documented features of the Garmin protocol start in the above document and are: Unit: GPS12. Software revision: 4.53 When the unit is connected the first time, it sends periodically few packets, but after sending to the unit a message type 1C (EnableAsyncEvents) with data FF FF, it starts sending at least the following: (This status is not cleared by a power (off - on) cycle.) The types with * will be analyzed in more detail type Len(dec.) comment: 0x00 4 ? 0x01 4 ? 0x02 4 ? 0x0D 8 Event * 0x14 84 Time/Latitude/Longitude ...* 0x16 21 ? (one per satellite) * 0x17 52 Position error and more * 0x1A 96 Satellite status * 0x27 2 ? 0x28 4 ? 0x33 64 Position, Velocity, Time * 0x36 9 ? (one per satellite) * 0x37 33 time and ? * 0x38 37 sat. info (one per sat.) * 0x39 35 ? In addition: 0x0A 2 to be sent to the unit. Request * *************************************************** Message 0x0D (8 bytes) Similar to the message shown in the Soley document, except the time information. bytes type comment 1-2 int Event type. Not yet analyzed in detail 3-4 int Subtype 5-8 long GPS clock time. Increments 1000 /s ---------------------------------------------------- Message 0x14 (84 bytes) Seems to be a mixture of position - time information bytes type comment 1-2 int type of fix. (2D, 3D, etc) 3-4 int repeated the above information (always the same number) 5-12 double Time of Week (seconds and fractions from 00:00 of Sunday) 13-20 double repeated the above information (always the same number) 21-24 long counter 1000/s (approx.) 25-28 long counter 515500/s 29-36 double latitude in radians 37-44 double longitude in radians 45-48 float altitude over the ellipsoid * 49-52 float speed in the east direction 53-56 float speed in the north direction 57-60 float? speed up ? 61-64 ? ? 65-68 ---- always FF 69-76 double? ??? 77-80 float? ??? 81-84 float? ??? * The altitude and speeds are the same as in message 0x33 (PVT) documented in the Garmin info. The type of the last items are only a guess. I don't know the contents, but the way they change suggest the types shown. ----------------------------------------------------------- Message 0x16 (21 bytes) one for each tracked satellite, sent successively bytes type comment 1-4 long ? (1) 5-8 ? ? byte 5 always 0, byte 8 near 0x3c or 0xBE 9-16 double pseudorange 17-20 ? ? byte 20 similar to byte 8 21 byte satellite number minus 1 I don't know if the pseudorange is corrected for ionospheric or other retardation in some way. (1): The information in the 1-4 bytes varies coherently for all the satellites (speed or Doppler? ) My observation site has a clear sky only in the north- northwest direction. One can expect mainly that the radial speed of all the satellites have the same sign? More research in necessary. ---------------------------------------------------------------- Message 0x17 (52 bytes) bytes type comment 1-4 float Estimated Horizontal Position Error 5-8 float Estimated Vertical Position Error 9-12 float Estimated Position Error 13-52 ? ? 33-36 and 41-44 seems to change from a constant value to a variable one with the first 3D fix. The information shown was obtained comparing this message with the 0x33 (Position- Velocity-Time) as documented in Garmin manuals. ------------------------------------------------------------------ Message 0x1A (96 bytes) Array of 12 (0x0C) blocks of data Each block has the following structure: bytes type comment 1 byte satellite number minus 1 2 byte elevation 3-4 word phase info? (1) 5-6 int signal quality 7 byte tracking? 8 byte some type of flag (2) (1): byte 4 takes values from 0 to 7 byte 3 fluctuates apparently at random if we take bytes 3 and 4 as a unsigned int., then we have 11 bits of changing data. The same data length can be found in the phase info from GPS25 boards. And the values change almost randomly... This is only a tentative idea... (2): Byte 8 takes only 0-1 values (mainly 0) byte 7: 1->? 2-> no tracking 4-> tracking ------------------------------------------------------------------- Message 0x33 (64 bytes) PVT (position, velocity, time) data bytes type comment 1-4 float altitude over the ellipsoid 5-8 float Estimated Position Error 9-12 float Estimated horizontal Position Error 13-16 float Estimated vertical Position Error 17-18 int type of fix (2D, 3D, diff.) 19-26 double Time of week 27-34 double Latitude 35-42 double Longitude 43-46 float East velocity 47-50 float North velocity 51-54 float Up velocity 55-58 float ellipsoid height above sea level 59-60 int dif. between GPS and UTC times 61-64 long start of week day number All of these data are explained in "Garmin GPS interface specification", taken from the Garmin website. In the same manual, Garmin says "None of the products in the table (including GPS12) implements PVT Data transfer" !! ---------------------------------------------------------------- Message 0x36 (9 bytes) one for each tracked satellite, sent successively bytes type comment 1-2 word counter 50/s 3 byte always 0x81 ? 4 byte some flags ? 5-8 ? seems to vary randomly 9 byte satellite number minus one Nothing know about bytes 5-8 -------------------------------------------------------------------- Message 0x37 (33 bytes) bytes type comment 1-22 ? ? 23-30 double Time Of Week 31-33 ? ? ---------------------------------------------------------------------- Message 0x38 (37 bytes) one for each tracked satellite, sent successively bytes type comment 1-2 ? ? 3-4 word increases 900 - 1100/s 5-8 long? (1) 9-10 word (2) 11-14 long Number of cycles (Integrated phase) (3) 15-22 double Pseudorange 23-26 long Counter (4) 27-28 word S/N ratio or signal strength 29-36 double Time of week 37 byte satellite number minus one (1): For the satellites with best signal, the value is almost constant. For the weak ones, fluctuates. If we consider it as a unsigned (double word), the values are close to 1.5E7 or close to 1E9. If we suppose a signed long integer, the values seem to group around +-1.5E7 or -3.4E6. On the other hand, all of this can be wrong and byte 8 (values only 00 and FF) can be a flag. (2): Varies slowly, with some noise (greater in the weak satellites), increasing or decreasing, but most of the time, increasing. In average, 1 unit each 2 seconds. (3): If the bytes 15-22 are actually the pseudorange, then bytes 11-14 must be the accumulated phase. If we calculate the wavelength (change in pseudorange / change in accumulated phase) we obtain 0.1903 for all the satellites. The correct value (in vacuum) is 0.1902936.. I think is enough. (4): The same value for all the satellites in each group of messages. Counts from the start of acquisition at (511500+-3)/s Half of the bit rate of the C/A code ---------------------------------------------------------------------- Requests sent TO the GPS12. In addition to the (more or less) documented ones, I have found the following: Bytes sent Action 0x0F 0x00 GPS sends 121 messages type 0x27 with 22 bytes each. 0x11 0x00 GPS sends 4? message(s) type 0x28 with 6 bytes 0x20 0x00 GPS sends a lot of messages type 0x45 with 15 bytes 0x2F 0x00 GPS sends messages type 0x55 of 91 bytes, type 0x1B of 2 bytes, 0x23 of 60 bytes, and then RESETS itself, erasing all the stored data and starts "searching the sky". At this point I stopped sending things to te GPS for obvious reasons. None of these messages are analyzed, and probably their type, number and length may vary depending the amount of data stored in the GPS. -------------------------------------------------------------------- And, of course, some or all of this information may be totally wrong. -------------------------------------------------------------------- One interesting set of data not yet found is the ephemeris. Probabily the unit will send these data in response to a command, but which one?. For the GPS25 is (according to manual) type 0x0D, len. 4, data: 0x02,0x0C,0x00,0x00 but in the GPS12 does not work. Is interesting to note that is a "event" message, not a "request" one. Article: 138829 of sci.geo.satellite-nav From: "Keith Monahan" Newsgroups: sci.geo.satellite-nav References: <8bqsm5$i4l$1@trumpet.uni-mannheim.de> Subject: Re: Garmin protocol Lines: 94 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Message-ID: Date: Thu, 30 Mar 2000 15:25:31 GMT NNTP-Posting-Host: 209.119.238.112 X-Complaints-To: abuse@digex.net X-Trace: dca1-nnrp1.news.digex.net 954429931 209.119.238.112 (Thu, 30 Mar 2000 10:25:31 EST) NNTP-Posting-Date: Thu, 30 Mar 2000 10:25:31 EST Organization: Intermedia Business Internet - Beltsville, MD Path: news1.meer.net!news3.best.com!news1.best.com!newsfeed.mathworks.com!feeder.qis.net!dca1-hub1.news.digex.net!intermedia!dca1-nnrp1.news.digex.net.POSTED!not-for-mail Xref: news1.meer.net sci.geo.satellite-nav:138829 Hi Daniel, Daniel Probst wrote in message news:8bqsm5$i4l$1@trumpet.uni-mannheim.de... > even if breaking the map encoding with which Garmin Mapsource Maps are > encoded is difficult: how about following idea: > > 1) mapsource maps segments seem to be encoded as "img" files on the R&R CDs. They sure are. > 2) img files seem to be use both for display on the PC Mapsource screen, or > for downloading to a III+/12Map/Emap. Yes, and as a matter of fact, there is a considerable amount of data that is never sent to the GPS. It seems as though there is a lot of data that is used only by the Mapsource proggie. > 3) if one could decode the downloading sequence by analysing what happens > before a certain img file is transfered First, understand a couple things. The MapSource program does some transformations of the actual disk file. It decrypts the file, first, using some very weak encryption. This is probably just a lame security through obscurity method -- which for most passerby's will be enough to say, "bah humbug" and pass it by. Second, despite popular yack about it, I don't believe the file is compressed at all before it is sent. The size of the data sent is indeed smaller than the original disk file, BUT this isn't due to compression (because most of the data sent = data unencrypted from the HD) but due to what I said earlier -- some data is simply used for mapsource program ONLY(ie to display maps) > 4) one could save these img files on different OSes, e.g. one could save the > complete 50 MB Germany R&R on an axxPac Smartmedia module on a Palm pilot > and download them on road without access to a pc. If the only packets being sent were parts of the decrypted original, then, yes it would be that easy -- the problem is that there are other packets using undocumented packet id's and who knows what the hell they are doing. The disk file isn't simply uploaded directly, there are other packets that are created by Mapsource, probably using some data from the original map file. And it is going to be a challenge to figure out which data is removed from the file and used to generate the new packets. Here is where we need someone familiar with machine code like a typical game copy protection hacker. Those guys can do magic with softice. That really is the only catch I can think of. And I don't mean packets that actually SEND the data, those are easy to figure out, of course because they repeat throughout the transmissions. I'm talking about packets that prepare the unit for a new upload. Packets which force the GPS to delete the old maps, which get the unit ready for upload, etc. And the whole problem is, let's say it's figured out -- who is going to lend their GPS to be the test victim. I know I'd be pretty paranoid locking my unit up indefinitely. And if you think Garmin is going to HELP here, you are wrong. Perhaps once or twice, but after that it'll probably be considered out of warranty work and the standard repair charge will be applied, I would think. > > does this sound reasonable? It's DEFINITELY reasonable. What I like to call a "replay attack" is possible too. For the most part, the GPS just sends ACK's saying it has received the packets from the mapsource software -- it is certainly possible to write another program on a different computer (or same computer, different com port) to send fake ACK's to MapSource, and buffer the entire transmission. That transmission could be stored on a palm pilot, and then retransmitted directly to the GPS, without the need for the palm pilot to understand the protocol. Now, let's hope that no rs-232 communication errors happen during either of the two transmissions, because our dumb application would not know how to retransmit, or even have a concept of a packet of data. This is the el-cheapo way, of course, but it could be an effective way prior to decoding the entire protocol. > -dan Keith Article: 138933 of sci.geo.satellite-nav From: Christian Claveleira Newsgroups: sci.geo.satellite-nav Subject: Re: About Garmin protocol Date: Fri, 31 Mar 2000 12:08:30 +0200 Organization: CRU Lines: 59 Message-ID: <38E4791E.A7DE4565@cru.fr> References: <8bvg2h$lp2$1@simancas.uva.es> NNTP-Posting-Host: quilu.cru.fr Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: French, fr, en CC: Jose =?iso-8859-1?Q?Mar=EDa=20Mu=F1oz?= Path: news1.meer.net!news3.best.com!news1.best.com!nntp.primenet.com!nntp.gctr.net!newsin.iconnet.net!netnews.com!isdnet!grolier!MGN!jussieu.fr!news!univ-rennes1.fr!not-for-mail Xref: news1.meer.net sci.geo.satellite-nav:138933 "Jose María Muñoz" wrote: [...] > With some work, a lot of guess and with a reduced set of data, I have > obtained this information. Some data that I have considered constant, > may not be so constant (mainly the high bytes of some counters) due > to the above said narrow time slot used. Congratulations for this excellent work ! I began to analyse packets from my GPSII+ and that confirm your observations : [...] > Message 0x16 (21 bytes) idem for II+ [...] > Message 0x1A (96 bytes) Not seen on my II+ [...] > Message 0x37 (33 bytes) > > bytes type comment > 1-22 ? ? > 23-30 double Time Of Week > 31-33 ? ? Idem for II+ > Message 0x38 (37 bytes) > > one for each tracked satellite, sent successively > > bytes type comment > 1-2 ? ? > 3-4 word increases 900 - 1100/s > 5-8 long? (1) > 9-10 word (2) > 11-14 long Number of cycles (Integrated phase) (3) > 15-22 double Pseudorange > 23-26 long Counter (4) > 27-28 word S/N ratio or signal strength > 29-36 double Time of week > 37 byte satellite number minus one Idem for II+ I'm not sure the signal strength is on a word (one byte is enough and on GPS35 it's coded on one byte) -- Christian Article: 137468 of sci.geo.satellite-nav From: Paul Breed Newsgroups: sci.geo.satellite-nav Subject: Help with post procesing... Date: Fri, 17 Mar 2000 19:50:48 -0500 Lines: 84 Message-ID: <38D2D2E7.DA3F1C29@Rasdoc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: 38kz18IPD6b1ZbxcaCH0pshAsspoA+BNsIxvhYpUQjA= X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 18 Mar 2000 01:44:27 GMT X-Accept-Language: en X-Mailer: Mozilla 4.51 [en] (Win98; U) Path: news1.meer.net!news3.best.com!news2.best.com!feed1.news.rcn.net!rcn!not-for-mail Xref: news1.meer.net sci.geo.satellite-nav:137468 I've read Sams S/W pages: http://callisto.worldonline.nl/~samsvl/software.htm And I'm just not quite there on figuring out what to do... I am working on a project where I am trying postprocess an altitude measurment. This is a private project that is funded out of my own limited personal funds. I am using an Ashtech G8 and the onboard system is capable of querying and recording the raw data messages from the G8. I've gathered the big picture items from Sam's S/W pages, but I am still not quite clear enough on the details. The G8 Raw outputs: System: GPS receive time in milliseconds. Clock offset (units of meters????) For each received SV: PRN Psuedo-Range Doppler My specific questions: 1)What is, and what do I do with the Clock offset term? 2)Do I have to record and store the ephemeris data reported by the G8, or can I recreate this data on the ground using stored history files available from???? 3)I've heard that RINEX (I have no idea what that stands for) data exists that will give me corrections SA, ephemeris , and other error terms. Where can I find this data, and is the format described somewhere? Is this set of data sufficient to generate a position with a vertical accuracy of 10 to 20m? An example data frame from the G8: Data recorded at ~ 00:55 UTC March 18 2000 GPS receive time in milliseconds: 521958000 Clock offset in meters : 204198.46 Number of SV's: 08 GPS reported position: 42.5382814 N 71.0405475 W The Raw number is reported first, then my calculated engineering units number. Psuedo-Range is reported scaled by 3.0E10 Doppler is reported as Hz scale =5.0E4 offset = 3.0E4 PRN Raw Psuedorange PsuedoRange(secs) Doppler (Raw) Corrected Doppler (Hz) 8 2423860249 0.080795342 1186705398 -6265.89204 6 2153122016 0.071770734 1245039367 -5099.21266 26 2169478190 0.07231594 1111430511 -7771.38978 13 2240575481 0.074685849 1369291076 -2614.17848 24 2188151310 0.072938377 1365045318 -2699.09364 17 2412374113 0.08041247 1102124404 -7957.51192 10 2082854264 0.069428475 1328199462 -3436.01076 27 2477115960 0.082570532 1220884094 -5582.31812 These Doppler numbers are all negative???? I would have expected them to be both + and -?? Thanks you again for any assistance you can provide . Paul The beginnings of my project page: http://www.rasdoc.com/splinter/brain.html Article: 137860 of sci.geo.satellite-nav From: Christian Claveleira Newsgroups: sci.geo.satellite-nav Subject: Re: Garmin protocol and pseudoranges Date: Wed, 22 Mar 2000 11:13:15 +0100 Organization: CRU Lines: 31 Message-ID: <38D89CBB.1ADC2E3B@cru.fr> References: <38D7861C.1270E689@cru.fr> <38D7A46A.6756B955@cwnet.com> NNTP-Posting-Host: quilu.cru.fr Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: French, fr, en Path: news1.meer.net!news3.best.com!news2.best.com!news.maxwell.syr.edu!netnews.com!isdnet!ciril.fr!univ-angers.fr!univ-rennes1.fr!not-for-mail Xref: news1.meer.net sci.geo.satellite-nav:137860 Dale DePriest wrote: > > I do not believe the information is available on these units. However there's at least one software who uses these informations : Gringo at http://www.nottingham.ac.uk/iessg/gringo/ Authors say they use undocumented Garmin records and they sell their software, so I suppose these informations exist and are valid... > > dale > > Christian Claveleira wrote: > > > > Who knows how to get raw pseudoranges from GPS 12, 48, II+... via > > Garmin protocol ? > > > > Thanks, > > > > Christian > > -- > For GPS data see: Joe -- http://joe.mehaffey.com > Peter -- http://www.vancouver-webpages.com/peter/ > Karen -- http://www.gpsy.com/gpsinfo/ > Dale -- http://users.cwnet.com/dalede -- Christian Article: 138804 of sci.geo.satellite-nav From: "Jose María Muñoz" Newsgroups: sci.geo.satellite-nav Subject: About Garmin protocol Date: Thu, 30 Mar 2000 14:07:33 +0200 Organization: Universidad de Valladolid - Spain Lines: 273 Message-ID: <8bvg2h$lp2$1@simancas.uva.es> NNTP-Posting-Host: gauss.ele.cie.uva.es X-Trace: simancas.uva.es 954418065 22306 157.88.41.126 (30 Mar 2000 12:07:45 GMT) X-Complaints-To: usenet@news.uva.es NNTP-Posting-Date: 30 Mar 2000 12:07:45 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Path: news1.meer.net!news3.best.com!news1.best.com!su-news-hub1.bbnplanet.com!news.gtei.net!newsfeed.berkeley.edu!ptdnetP!newsgate.ptd.net!newsfeed00.sul.t-online.de!t-online.de!newsfeeds.belnet.be!naxos.belnet.be!news.belnet.be!news.rediris.es!news.uva.es!not-for-mail Xref: news1.meer.net sci.geo.satellite-nav:138804 In the last few weeks, it seems that some people is interested in the Garmin proprietary communications protocol. In particular in the extraction of raw GPS data from "low end" handheld units. With some work, a lot of guess and with a reduced set of data, I have obtained this information. Some data that I have considered constant, may not be so constant (mainly the high bytes of some counters) due to the above said narrow time slot used. Of course!, I am in no way related to Garmin, and all this information is ONLY my opinion about the meaning of the stream of data. First of all, I want to thank William Soley for the compilation of his document about the undocumented commands. http://playground.sun.com/pub/soley/garmin.txt My preliminary observations on the more or less documented features of the Garmin protocol start in the above document and are: Unit: GPS12. Software revision: 4.53 When the unit is connected the first time, it sends periodically few packets, but after sending to the unit a message type 1C (EnableAsyncEvents) with data FF FF, it starts sending at least the following: (This status is not cleared by a power (off - on) cycle.) The types with * will be analyzed in more detail type Len(dec.) comment: 0x00 4 ? 0x01 4 ? 0x02 4 ? 0x0D 8 Event * 0x14 84 Time/Latitude/Longitude ...* 0x16 21 ? (one per satellite) * 0x17 52 Position error and more * 0x1A 96 Satellite status * 0x27 2 ? 0x28 4 ? 0x33 64 Position, Velocity, Time * 0x36 9 ? (one per satellite) * 0x37 33 time and ? * 0x38 37 sat. info (one per sat.) * 0x39 35 ? In addition: 0x0A 2 to be sent to the unit. Request * *************************************************** Message 0x0D (8 bytes) Similar to the message shown in the Soley document, except the time information. bytes type comment 1-2 int Event type. Not yet analyzed in detail 3-4 int Subtype 5-8 long GPS clock time. Increments 1000 /s ---------------------------------------------------- Message 0x14 (84 bytes) Seems to be a mixture of position - time information bytes type comment 1-2 int type of fix. (2D, 3D, etc) 3-4 int repeated the above information (always the same number) 5-12 double Time of Week (seconds and fractions from 00:00 of Sunday) 13-20 double repeated the above information (always the same number) 21-24 long counter 1000/s (approx.) 25-28 long counter 515500/s 29-36 double latitude in radians 37-44 double longitude in radians 45-48 float altitude over the ellipsoid * 49-52 float speed in the east direction 53-56 float speed in the north direction 57-60 float? speed up ? 61-64 ? ? 65-68 ---- always FF 69-76 double? ??? 77-80 float? ??? 81-84 float? ??? * The altitude and speeds are the same as in message 0x33 (PVT) documented in the Garmin info. The type of the last items are only a guess. I don't know the contents, but the way they change suggest the types shown. ----------------------------------------------------------- Message 0x16 (21 bytes) one for each tracked satellite, sent successively bytes type comment 1-4 long ? (1) 5-8 ? ? byte 5 always 0, byte 8 near 0x3c or 0xBE 9-16 double pseudorange 17-20 ? ? byte 20 similar to byte 8 21 byte satellite number minus 1 I don't know if the pseudorange is corrected for ionospheric or other retardation in some way. (1): The information in the 1-4 bytes varies coherently for all the satellites (speed or Doppler? ) My observation site has a clear sky only in the north- northwest direction. One can expect mainly that the radial speed of all the satellites have the same sign? More research in necessary. ---------------------------------------------------------------- Message 0x17 (52 bytes) bytes type comment 1-4 float Estimated Horizontal Position Error 5-8 float Estimated Vertical Position Error 9-12 float Estimated Position Error 13-52 ? ? 33-36 and 41-44 seems to change from a constant value to a variable one with the first 3D fix. The information shown was obtained comparing this message with the 0x33 (Position- Velocity-Time) as documented in Garmin manuals. ------------------------------------------------------------------ Message 0x1A (96 bytes) Array of 12 (0x0C) blocks of data Each block has the following structure: bytes type comment 1 byte satellite number minus 1 2 byte elevation 3-4 word phase info? (1) 5-6 int signal quality 7 byte tracking? 8 byte some type of flag (2) (1): byte 4 takes values from 0 to 7 byte 3 fluctuates apparently at random if we take bytes 3 and 4 as a unsigned int., then we have 11 bits of changing data. The same data length can be found in the phase info from GPS25 boards. And the values change almost randomly... This is only a tentative idea... (2): Byte 8 takes only 0-1 values (mainly 0) byte 7: 1->? 2-> no tracking 4-> tracking ------------------------------------------------------------------- Message 0x33 (64 bytes) PVT (position, velocity, time) data bytes type comment 1-4 float altitude over the ellipsoid 5-8 float Estimated Position Error 9-12 float Estimated horizontal Position Error 13-16 float Estimated vertical Position Error 17-18 int type of fix (2D, 3D, diff.) 19-26 double Time of week 27-34 double Latitude 35-42 double Longitude 43-46 float East velocity 47-50 float North velocity 51-54 float Up velocity 55-58 float ellipsoid height above sea level 59-60 int dif. between GPS and UTC times 61-64 long start of week day number All of these data are explained in "Garmin GPS interface specification", taken from the Garmin website. In the same manual, Garmin says "None of the products in the table (including GPS12) implements PVT Data transfer" !! ---------------------------------------------------------------- Message 0x36 (9 bytes) one for each tracked satellite, sent successively bytes type comment 1-2 word counter 50/s 3 byte always 0x81 ? 4 byte some flags ? 5-8 ? seems to vary randomly 9 byte satellite number minus one Nothing know about bytes 5-8 -------------------------------------------------------------------- Message 0x37 (33 bytes) bytes type comment 1-22 ? ? 23-30 double Time Of Week 31-33 ? ? ---------------------------------------------------------------------- Message 0x38 (37 bytes) one for each tracked satellite, sent successively bytes type comment 1-2 ? ? 3-4 word increases 900 - 1100/s 5-8 long? (1) 9-10 word (2) 11-14 long Number of cycles (Integrated phase) (3) 15-22 double Pseudorange 23-26 long Counter (4) 27-28 word S/N ratio or signal strength 29-36 double Time of week 37 byte satellite number minus one (1): For the satellites with best signal, the value is almost constant. For the weak ones, fluctuates. If we consider it as a unsigned (double word), the values are close to 1.5E7 or close to 1E9. If we suppose a signed long integer, the values seem to group around +-1.5E7 or -3.4E6. On the other hand, all of this can be wrong and byte 8 (values only 00 and FF) can be a flag. (2): Varies slowly, with some noise (greater in the weak satellites), increasing or decreasing, but most of the time, increasing. In average, 1 unit each 2 seconds. (3): If the bytes 15-22 are actually the pseudorange, then bytes 11-14 must be the accumulated phase. If we calculate the wavelength (change in pseudorange / change in accumulated phase) we obtain 0.1903 for all the satellites. The correct value (in vacuum) is 0.1902936.. I think is enough. (4): The same value for all the satellites in each group of messages. Counts from the start of acquisition at (511500+-3)/s Half of the bit rate of the C/A code ---------------------------------------------------------------------- Requests sent TO the GPS12. In addition to the (more or less) documented ones, I have found the following: Bytes sent Action 0x0F 0x00 GPS sends 121 messages type 0x27 with 22 bytes each. 0x11 0x00 GPS sends 4? message(s) type 0x28 with 6 bytes 0x20 0x00 GPS sends a lot of messages type 0x45 with 15 bytes 0x2F 0x00 GPS sends messages type 0x55 of 91 bytes, type 0x1B of 2 bytes, 0x23 of 60 bytes, and then RESETS itself, erasing all the stored data and starts "searching the sky". At this point I stopped sending things to te GPS for obvious reasons. None of these messages are analyzed, and probably their type, number and length may vary depending the amount of data stored in the GPS. -------------------------------------------------------------------- And, of course, some or all of this information may be totally wrong. -------------------------------------------------------------------- One interesting set of data not yet found is the ephemeris. Probabily the unit will send these data in response to a command, but which one?. For the GPS25 is (according to manual) type 0x0D, len. 4, data: 0x02,0x0C,0x00,0x00 but in the GPS12 does not work. Is interesting to note that is a "event" message, not a "request" one. Article: 138829 of sci.geo.satellite-nav From: "Keith Monahan" Newsgroups: sci.geo.satellite-nav References: <8bqsm5$i4l$1@trumpet.uni-mannheim.de> Subject: Re: Garmin protocol Lines: 94 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Message-ID: Date: Thu, 30 Mar 2000 15:25:31 GMT NNTP-Posting-Host: 209.119.238.112 X-Complaints-To: abuse@digex.net X-Trace: dca1-nnrp1.news.digex.net 954429931 209.119.238.112 (Thu, 30 Mar 2000 10:25:31 EST) NNTP-Posting-Date: Thu, 30 Mar 2000 10:25:31 EST Organization: Intermedia Business Internet - Beltsville, MD Path: news1.meer.net!news3.best.com!news1.best.com!newsfeed.mathworks.com!feeder.qis.net!dca1-hub1.news.digex.net!intermedia!dca1-nnrp1.news.digex.net.POSTED!not-for-mail Xref: news1.meer.net sci.geo.satellite-nav:138829 Hi Daniel, Daniel Probst wrote in message news:8bqsm5$i4l$1@trumpet.uni-mannheim.de... > even if breaking the map encoding with which Garmin Mapsource Maps are > encoded is difficult: how about following idea: > > 1) mapsource maps segments seem to be encoded as "img" files on the R&R CDs. They sure are. > 2) img files seem to be use both for display on the PC Mapsource screen, or > for downloading to a III+/12Map/Emap. Yes, and as a matter of fact, there is a considerable amount of data that is never sent to the GPS. It seems as though there is a lot of data that is used only by the Mapsource proggie. > 3) if one could decode the downloading sequence by analysing what happens > before a certain img file is transfered First, understand a couple things. The MapSource program does some transformations of the actual disk file. It decrypts the file, first, using some very weak encryption. This is probably just a lame security through obscurity method -- which for most passerby's will be enough to say, "bah humbug" and pass it by. Second, despite popular yack about it, I don't believe the file is compressed at all before it is sent. The size of the data sent is indeed smaller than the original disk file, BUT this isn't due to compression (because most of the data sent = data unencrypted from the HD) but due to what I said earlier -- some data is simply used for mapsource program ONLY(ie to display maps) > 4) one could save these img files on different OSes, e.g. one could save the > complete 50 MB Germany R&R on an axxPac Smartmedia module on a Palm pilot > and download them on road without access to a pc. If the only packets being sent were parts of the decrypted original, then, yes it would be that easy -- the problem is that there are other packets using undocumented packet id's and who knows what the hell they are doing. The disk file isn't simply uploaded directly, there are other packets that are created by Mapsource, probably using some data from the original map file. And it is going to be a challenge to figure out which data is removed from the file and used to generate the new packets. Here is where we need someone familiar with machine code like a typical game copy protection hacker. Those guys can do magic with softice. That really is the only catch I can think of. And I don't mean packets that actually SEND the data, those are easy to figure out, of course because they repeat throughout the transmissions. I'm talking about packets that prepare the unit for a new upload. Packets which force the GPS to delete the old maps, which get the unit ready for upload, etc. And the whole problem is, let's say it's figured out -- who is going to lend their GPS to be the test victim. I know I'd be pretty paranoid locking my unit up indefinitely. And if you think Garmin is going to HELP here, you are wrong. Perhaps once or twice, but after that it'll probably be considered out of warranty work and the standard repair charge will be applied, I would think. > > does this sound reasonable? It's DEFINITELY reasonable. What I like to call a "replay attack" is possible too. For the most part, the GPS just sends ACK's saying it has received the packets from the mapsource software -- it is certainly possible to write another program on a different computer (or same computer, different com port) to send fake ACK's to MapSource, and buffer the entire transmission. That transmission could be stored on a palm pilot, and then retransmitted directly to the GPS, without the need for the palm pilot to understand the protocol. Now, let's hope that no rs-232 communication errors happen during either of the two transmissions, because our dumb application would not know how to retransmit, or even have a concept of a packet of data. This is the el-cheapo way, of course, but it could be an effective way prior to decoding the entire protocol. > -dan Keith Article: 138446 of sci.geo.satellite-nav Sender: wolfgang@capsicum.wsrcc.com Newsgroups: sci.geo.satellite-nav Subject: Re: garmin-garmin protocol References: <0a288596.2e425fe4@usw-ex0110-075.remarq.com> From: Wolfgang Rupprecht Message-ID: Organization: W S Rupprecht Computer Consulting, Fremont CA Lines: 26 User-Agent: Gnus/5.08 (Gnus v5.8.3) Emacs/20.5 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 27 Mar 2000 18:06:38 GMT NNTP-Posting-Host: 24.1.65.208 X-Complaints-To: abuse@home.net X-Trace: news1.frmt1.sfba.home.com 954180398 24.1.65.208 (Mon, 27 Mar 2000 10:06:38 PST) NNTP-Posting-Date: Mon, 27 Mar 2000 10:06:38 PST Path: news1.meer.net!news3.best.com!news1.best.com!newsfeed.mathworks.com!howland.erols.net!newshub2.home.com!news.home.com!news1.frmt1.sfba.home.com.POSTED!not-for-mail Xref: news1.meer.net sci.geo.satellite-nav:138446 fcm writes: > I want to join a group of programmers with information to > exchange about the non-NMEA protocol in Garmin products. > The Garmin PDF spec is a very good basic startup, also > http://playground.sun.com/pub/soley/garmin.txt however now > this is incomplete. (There are multiple copies of the same > doc in the net). > I'm willing to create a garmin-garmin FAQ if not available. > Any pointer will be appreciated. There are several programmers that hang out here looking for the keywords 'garmin protocol' in the subject line. This is not a bad place to start. The known universe doesn't extend much past the soley document (from the sun playground machine). Just to add to the multiple copies mess I'll put my marked up copy at: http://www.wsrcc.com/wolfgang/ftp/garmin-prot-soley.txt -wolfgang -- Wolfgang Rupprecht http://www.wsrcc.com/wolfgang/ DGPS signals via the Internet http://www.wsrcc.com/wolfgang/gps/dgps-ip.html Article: 137860 of sci.geo.satellite-nav From: Christian Claveleira Newsgroups: sci.geo.satellite-nav Subject: Re: Garmin protocol and pseudoranges Date: Wed, 22 Mar 2000 11:13:15 +0100 Organization: CRU Lines: 31 Message-ID: <38D89CBB.1ADC2E3B@cru.fr> References: <38D7861C.1270E689@cru.fr> <38D7A46A.6756B955@cwnet.com> NNTP-Posting-Host: quilu.cru.fr Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: French, fr, en Path: news1.meer.net!news3.best.com!news2.best.com!news.maxwell.syr.edu!netnews.com!isdnet!ciril.fr!univ-angers.fr!univ-rennes1.fr!not-for-mail Xref: news1.meer.net sci.geo.satellite-nav:137860 Dale DePriest wrote: > > I do not believe the information is available on these units. However there's at least one software who uses these informations : Gringo at http://www.nottingham.ac.uk/iessg/gringo/ Authors say they use undocumented Garmin records and they sell their software, so I suppose these informations exist and are valid... > > dale > > Christian Claveleira wrote: > > > > Who knows how to get raw pseudoranges from GPS 12, 48, II+... via > > Garmin protocol ? > > > > Thanks, > > > > Christian > > -- > For GPS data see: Joe -- http://joe.mehaffey.com > Peter -- http://www.vancouver-webpages.com/peter/ > Karen -- http://www.gpsy.com/gpsinfo/ > Dale -- http://users.cwnet.com/dalede -- Christian