Shop OBEX P1 Docs P2 Docs Learn Events
Oncore GPS Checksums — Parallax Forums

Oncore GPS Checksums

ArchiverArchiver Posts: 46,084
edited 2003-03-02 21:02 in General Discussion
Jonathan-

It's spelled out in Chapter 3 of the Oncore doc's on page 3.26, and
described as "the exclusive-or of all message bytes after the @@ and
before the checksum". A checksum is formed by combining the
contents of a stream of data in some way. The receiver can verify
the integrity of the captured data by calculating the checksum again
and comparing it with the checksum value received. If they match,
chances are the data were received completely and without error. As
the name implies, this often involves just summing all bytes, but the
Motorola binary format does an exclusive-or (XOR) over the data
instead.

So to use the read date example, you send the following 11-byte
command:

"@@Ac",$ff,$ff,$ff,$ff,checksum,carriage return,linefeed

In this case, the data between the @@ and the checksum are the six
bytes "Ac",$ff,$ff,$ff,$ff. So the checksum could be formed by
XORing 'A', 'c', $ff, $ff, $ff and $ff. But if you look at how XOR
works, you'll see that you get the same result by merely XORing 'A'
with 'c', and you save program memory and typing if you use the
shortcut.

To request time, you send:

"@@Aa",$ff,$ff,$ff,checksum,carriage return,linefeed

The available shortcut in this case is to only XOR the $ff once.

The XOR operation is implemented in your Stamp via the ^ operator,
and is described in the manual better than I can do it. The
shortcuts above are based on the principles that anything XORed with
itself is zero, and anything XORed with zero is itself.


Regards,

Steve

On 2 Mar 03 at 13:02, Jonathan Peakall wrote:

> Hi All,
>
> Well, got the oncore hooked up and catching satallites. Thanks
> Steve! The code below works fine. Problem is, I don't understand how
> the checksum values are created...

Comments

  • ArchiverArchiver Posts: 46,084
    edited 2003-03-02 21:02
    Hi All,

    Well, got the oncore hooked up and catching satallites. Thanks Steve! The
    code below works fine. Problem is, I don't understand how the checksum
    values are created. They look like Greek to me! I looked in the data sheet,
    and I can see that the checksum has something to do with the number of bits
    returned for each command. A couple of examples are below.


    ' read date

    checksum = "A"^"c"

    SEROUT Gps_out,Bin_baud,[noparse][[/noparse]"@@Ac",$FF,$FF,$FF,$FF,checksum,CR,LF]

    DEBUG CR,"Date: "

    SERIN Gps_in,Bin_baud,[noparse][[/noparse]STR x\4,month,day,year.HIGHBYTE,year.LOWBYTE]

    DEBUG DEC month,"/",DEC day,"/",DEC year



    ' read time

    checksum = "A"^"a"^$FF

    SEROUT Gps_out,Bin_baud,[noparse][[/noparse]"@@Aa",$FF,$FF,$FF,checksum,CR,LF]

    DEBUG CR,"Time: "

    SERIN Gps_in,Bin_baud,[noparse][[/noparse]STR x\4,hour,minute,second]

    DEBUG DEC hour,":",DEC minute,":",DEC second



    Can someone explain the checksum stuff to me? In small words?

    Thanks,

    Jonathan

    www.madlabs.info
Sign In or Register to comment.