Gps serial decoding

Apothus

Hi

It has been A while since i have used microcontrollers and getting back into the swing of things is a little tricky. I'm trying to get my propeller demo board to receive the NEMA data stream from a gps module (http://www.sparkfun.com/commerce/product_info.php?products_id=168 , similar module but with 2 com ports)

I recieve an NEMA string such as
$GPGGA,XXXXXX.XX,XXXX.XXXX,S,XXXX.XXXX,E,1,06,1.68,00024,M,-029,M,,*52 (im from aus hence the SE heading)

i have been using some code off this forum provided by Perry James Mole, (attached)

I understand the principals of what he is doing but i am still rather confused.
as i understand in gps_IO_mini(slightly modified some array references that may be wrong)
(if gps_buff[noparse][[/noparse]0] == "G") it is looking to see if element 0 in the byte array off gps_buff is equivalent to the symbol "G"
then it goes on checking the other elelents

the parts that have me confused is how the different pieces of data are seperated out such as latitude and longitude, and the general operation of the copy_buff routine

Any help would be much appreciated, i have lost about 5 nights to this now :P

Regards
Andrew

Post Edited (Apothus) : 7/24/2008 1:46:55 PM GMT

Paul_H

Hi Andrew,

I had the same questions when I started using Perry's code so I hope this will help you out.

Perry's code accepts stings into a temporary buffer (@gps_buff). This can be any string that comes along. One we determine what particulate string we are dealing with , the code copies to a space reserved to that data. This way $GPRMC is stored in an are separate from $GPGGA. The copy_buffer(Dest,Source) just moves the data, byte by byte.

Her's a detailed description of what is going on:

Let's start by saying that the GPS data you are receiving _is_a_string_! There are no numbers present, only ascii strings. This is important to remember. you have it right talking of them as symbols. Lets use the following as our example from your string below: "E,1" (thats - ascii Eee Comma One) and pretend that is the entire string received.

Look at the ascii table: http://www.asciitable.com/ and you will see that

E => ascii  69 => binary 01000101
' => ascii  44 => binary 00101100 == replaced by "00000000" in the code
1 => ascii  49 => binary 00110001
null => ascii  0 => binary 00000000

The prop needs know where the data ends and has to terminate strings (and this is the part that threw me!) with a NULL value which is really a binary zero and not a ascii zero. This is frequently called "zero terminated string" because they are speaking in binary (those geeks!), but to us mortals it is an ascii NULL . Thats what i show as the last value above.

What Perry's code does as its captured is replace any sting commas (b00101100) with NULLs (b00000000). Note the comma is in quotes, and the zero on the next line is not. This lets the prop natively read multiple strings the next time is goes through. Perry indexes the position of the new strings so when you need to read a value GPGGAa[noparse][[/noparse]0] it goes to what was the first item [noparse][[/noparse] at the zero'th point - we start with zero not 1] and reads until it sees a NULL termination.

Lastly, when you read the "1" that we saved above, dont try to do math to it. Its a string. If you add 10 to it thinking you will get 11, you won;t know why you get a semicolon (ascii 59 = acsii 49+that 10 you wanted to add)


I hope i got that right! Anyone care to comment?
Paul

Praxis

An easy way to convert a numeric string character to a numeric value is to subtract 48 decimal (hex 30).