Sending commands to a GPS module

Apparently, anything that you send must be a valid NMEA - formatted string with a checksum at the end. Anything else will be ignored.

Try: $GPWPL,4807.038,N,01131.000,E,WPTNME*5C

So you get to format the string as a text file and then copy to comx:

Please let us know how you progress!

--Winston

most devices have a protocol you need to follow.... most have a CRC system to deduce error, and also, some have a way to get out/in data mode like in the olds of external modems... etc...

YOu need to read the data sheet on it..

Yup.

This one?

:)

--Winston

$PSRFxxx,x,x,x,x*xx

Is that what you're referring too?

P.S. Make sure you send the CR and LF at the end.. and of course, calculate the CRC, and there are no spaces.

I know the Doc's say Xor with characters between the $ and * how ever, they don't really give you an example. I can only assume they are Xoring each char maybe with FF and then summing..

Who knows.

(...)

I wasn't but I have an open mind. :)

I understood this to be a valid test string as well: $GPWPL,4807.038,N,01131.000,E,WPTNME*5C

I didn't know about the and but that sounds very plausible.

Not me! I was just practicing a little Google-fu.

--Winston

From the standard: "The checksum is the 8-bit exclusive OR (no start or stop bits) of all characters in the sentence, including "," and "^" delimiters, between but not including the "$" or "!" and the "*" delimiters." The GPWPL sentence example above has a correct checksum.

The OP's question may be answered by the "SSFXXXX series GPS module NMEA protocol reference manual." But the home site for those modules doesn't seem to have such a beast.

There is, however, a standard query sentence format that may be supported by the module. The format is:

$AABBQ,CCC*XX

AA is the talker identifier of the requesting system (the OP's identifier). We don't know if the module in question wants a particular identifier here but a logical one to use would be "II" (integrated instrumentation).

BB is the talker identifier of the device from which data is requested. In this case, "GP".

Q indicates a query sentence.

CCC is the sentence formatter for the requested sentence: ZDA.

and then the end-of-sentence stuff.

So, try sending "$IIGPQ,ZDA*35" (with the expected carriage return / line feed following) at the device's baud rate and see what happens.

Start with zero in a checksum variable, XOR each char with that variable and store result to the variable, convert checksum to a pair of hex digits (since it may contain non-printable or control characters).

Grant.

Well, that makes it easy. I've seen a variety of CRC's done ..

One I did recently involved adding a 1 to the results to reverse it.

oh well.

It is so much easier after the info is translated into English.

Thanks!

--Winston

Doubtlessly someone has written a VB script which generates the proper string (and checksum) based on pulldown menus and radio button selections, though my casual Googling doesn't reveal anything like that.

--Winston

Although i haven't actually ran a test program on the algorithm suggested here, there are plenty of example strings that one could test against in the supplied PDF that was posted.

My self, I used Delphi as my first language because its fast to code something simple.. Function ValidateCRC(CMDStr:string):Boolean; Var CRC,H:Byte; I,Y:Integer; H:String; Begin Result := true; // Incase it has no CRC in the string. Y := Pos('*',CMDStr); // Look for CRC marker. If Y = 0 Then Exit; CRC := 0; H := UpperCase(Copy(CMDStr,Y+1,2)); For I := 2 to Y-1 do CRC := CRC Xor ORD(CMDSTr[I]); Result := IntToHex(CRC,2) = H; End;

I just did that out of my head as a thought..

There's a few sorts of pre, post conditioning, XOR is only a parity check, weak.

You could have checksum ignoring overflow, then 16 or 32 bit CRC, or go even further to error locus and correction. Trouble with this XOR scheme is that it may allow two 'wrongs' to make a right :(

Grant.

(...)

Cool!

--Winston