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:

"The checksum field consists of a '*' and two hex digits representing an 8 bit exclusive OR of all characters between, but not including, the '$' and '*'."

Let's look at this in the context of the following NMEA sentence:

$GPVTG,054.7,T,034.4,M,005.5,N,010.2,K*48

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?

 

Hello,

From a page that explains the NMEA data:

Each sentence begins with a '$' and ends with a carriage return/line feed sequence and can be no longer than 80 characters of visible text (plus the line terminators). The data is contained within this single line with data items separated by commas. The data itself is just ascii text and may extend over multiple sentences in certain specialized instances but is normally fully contained in one variable length sentence. The data may vary in the amount of precision contained in the message. For example time might be indicated to decimal parts of a second or location may be show with 3 or even 4 digits after the decimal point. Programs that read the data should only use the commas to determine the field boundaries and not depend on column positions. There is a provision for a checksum at the end of each sentence which may or may not be checked by the unit that reads the data. The checksum field consists of a '*' and two hex digits representing an 8 bit exclusive OR of all characters between, but not including, the '$' and '*'. A checksum is required on some sentences.

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

Bertus

 

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.

 

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.

So, I think I'm gonna start with RAM address 120h, then do the following:

GPSDATA
MOVLW   120H
MOVWF   FSR0
BTFSS  PIR1, RCIF
GOTO  $-1
MOVF   RECREG,W
SUBLW   *    ;ASCII *
BTFSS    STATUS,ZEROBIT
MOVWI   INDF0++
.......ADDITIONAL CODE

Anyone see any problems with that?

Also, most GPS modules have a PPS pin. Does a pulse on the PPS (one pulse per second) pin come right before NMEA data is sent?