# GPS NMEA checksum questions

Discussion in 'Embedded Systems and Microcontrollers' started by wannaBinventor, Dec 3, 2010.

1. ### wannaBinventor Thread Starter Active Member

Apr 8, 2010
180
4
I'm trying to understand the method behind a GPS NMEA sentence checksum.

Most of what I can find on the net just says this:
Let's look at this in the context of the following NMEA sentence:

Code ( (Unknown Language)):
1. \$GPVTG,054.7,T,034.4,M,005.5,N,010.2,K*48
2.
Alright, so I'm doing an XOR on all of the ASCII characters between \$ and *. But what does that really mean?

First, please confirm for me that "48" represent HEX values, whereas everything between \$ and * are actually ASCII character values. Is this correct?

Okay, from here, assuming everything between \$ and * is in ASCII, G equals binary 01000111 and P equals binary 01010000.

So:
XOR G,X = binary 00010111

From here, are you supposed to XOR the result of an "XOR G,X with V?

Let's call the XOR of G and X "Dan." The binary value of ASCII "V" is 01110110.
So:
XOR Dan,V = binary 01100001

Do I just keep doing that step over and over again until I reach the ASCII asterisk and then compare the HEX value stored to my calculated checksum?

Does it matter what order I started XORing in -- would I get the same result?

Apr 5, 2008
17,159
3,015
Hello,

From a page that explains the NMEA data:

Here is the link to the full page:
http://www.gpsinformation.org/dale/nmea.htm

Bertus

3. ### thatoneguy AAC Fanatic!

Feb 19, 2009
6,357
720
If you have a string like 48,32,9,DE

The Checksum would be:
$4\oplus8\oplus,\oplus3\oplus2\oplus,\oplus9\oplus{D}\oplus{E}$

In RPN Stack Notation (HP Calc):
ASCII(4) <ENTER>
ASCII(8) <ENTER>
XOR (XOR of x which is 8 (0x38 ASCII), and y which is 4 (0x34 ASCII), result is 12(0x0C))
, <ENTER>
XOR (XOR of x, which is ','(0x2C ASCII) and y, which is 12(0x0C ASCII) from last operation)
ASCII(3) <ENTER>
XOR
.
.
.etc

The result will be a 2 digit Hex number.

4. ### wannaBinventor Thread Starter Active Member

Apr 8, 2010
180
4
Thanks. That clears it up a good bit.

I'm looking forward to try parsing that in an 8 bit PIC in assembly. Anyone have any suggestions?

The PIC16F1934 that I will be using can linearly address all RAM (except for the 16 bytes of RAM common to all banks), and this model has 256 bytes of RAM total. Specifically, it has 80 linearly addressable bytes in bank 3, which just so happens to be the maximum number of characters in a NMEA sentence.

Code ( (Unknown Language)):
1.
2. GPSDATA
3. MOVLW   120H
4. MOVWF   FSR0
5. BTFSS  PIR1, RCIF
6. GOTO  \$-1
7. MOVF   RECREG,W
8. SUBLW   *    ;ASCII *
9. BTFSS    STATUS,ZEROBIT
10. MOVWI   INDF0++