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
    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
    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.

    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.
    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?
  2. bertus


    Apr 5, 2008

    From a page that explains the NMEA data:

    Here is the link to the full page:

  3. thatoneguy

    AAC Fanatic!

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

    The Checksum would be:

    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>

    The result will be a 2 digit Hex number.
  4. wannaBinventor

    Thread Starter Active Member

    Apr 8, 2010
    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:

    Code ( (Unknown Language)):
    2. GPSDATA
    3. MOVLW   120H
    4. MOVWF   FSR0
    5. BTFSS  PIR1, RCIF
    6. GOTO  $-1
    7. MOVF   RECREG,W
    8. SUBLW   *    ;ASCII *
    10. MOVWI   INDF0++
    11. .......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?