Changing GPS co-ordinates into Degrees-Minutes-Seconds


Closed Thread
Results 1 to 19 of 19

Hybrid View

  1. #1


    Did you find this post helpful? Yes | No

    Question

    Quote Originally Posted by scalerobotics View Post
    OOPS. My bad.

    Did you really mean that you only want Degrees Minutes and Seconds? Or do need to convert to deg.deg ?

    If you just need the digits, its the ASCII -48 = digits.
    Yes thats correct. I only need to convert the lat & long to degrees minutes and seconds and display it on my pc screen.

  2. #2
    Join Date
    Feb 2006
    Location
    Gilroy, CA
    Posts
    1,530


    Did you find this post helpful? Yes | No

    Default

    Well, then...........

    There are a couple different ways to do it. I'm going to show you the Serin2 example, because that is the gps example that MeLabs gives.
    Another good way to do it is to read the entire NMEA sentence into an array like this, then worry about parsing it later:
    Code:
    HSerin 200, Main, [WAIT("$GPRM"), STR gpsdata\MAXDATA\13]
    but we will stick with serin2 for now.

    Here is MeLabs gps example for reading speed.
    http://melabs.com/resources/samples/...d/read_gps.bas

    You would have to adjust to get degrees minutes and then do a conversion for seconds
    For instance, their ...
    Code:
    SerIn2 GPSin,baudGPS,Timeout,Nogps,[wait("$GPRMC"),skip 34,DEC1 tens,DEC1 digits,skip 1,DEC1 tenth]
    means wait till it sees $GPRMC that begins the NMEA sentence, skip 34 characters to the speed tens digit, put it in variable "tens", then read next speed digit and put in variable called "digits", then skip the "." and read the last decimal into a variable called "tenth".

    You would have to adjust the skips to match the digits you want to get.
    Code:
    $GPRMC,123519,A,4807.038,N,01131.000,E,022.4,084.4,230394,003.1,W*6A
    
    Where:
         RMC          Recommended Minimum sentence C
         123519       Fix taken at 12:35:19 UTC
         A            Status A=active or V=Void.
         4807.038,N   Latitude 48 deg 07.038' N
         01131.000,E  Longitude 11 deg 31.000' E
         022.4        Speed over the ground in knots
         084.4        Track angle in degrees True
         230394       Date - 23rd of March 1994
         003.1,W      Magnetic Variation
         *6A          The checksum data, always begins with *
    If your NMEA sentence was similar to above (some add more resolution and are of slightly different format), then you could use:
    Code:
    SerIn2 GPSin,baudGPS,Timeout,Nogps,[wait("$GPRMC"),skip 11,DEC2 lat_deg,DEC2 lat_min,skip 1,DEC3 lat_min_dec ... then same for longitude]
    Now, you need to convert decimal minutes to seconds .... am I right this time? Because the GPS will output in decimal minutes, not seconds.

    So, to convert decimal minutes into seconds:
    lat_seconds = lat_min_dec * 6
    so, using the NMEA sample above: 038 * 6 = 228

    When you print this out to your computer, you print a "." in between the twos
    and get 2.28 seconds. This part just prints the seconds out through the serial port.
    The dig specifies which digit you want to print of the variable called seconds. Rightmost digit is 0
    Code:
    DEBUG DEC lat_seconds dig 2,".",DEC lat_seconds dig 1, DEC lat_seconds dig 0,13,10
    Last edited by ScaleRobotics; - 27th October 2009 at 08:05.
    http://www.scalerobotics.com

  3. #3


    Did you find this post helpful? Yes | No

    Question

    Ok, thanks for your time in writing a detailed explanation, BUT little bit of confusion still left. I have the following string :

    $GPRMC,123339.000,A,5134.2770,N,00007.8480,E,1.14, 254.38,271009,,*09

    Can you please show me as to how to convert "5134.2770" & "00007.8480" into degrees - minutes - seconds in PBP + speed to Km/H.
    I have done this online and the answer is
    Degrees, Minutes & Seconds
    Latitude - Longitude
    N51 34 16 - W0 07 50 and 2.111 Km/Hr (Though it should be 0 Km/Hr as Module is stationary)

    Also what is checksum? and what it is used for?

    Your effort will be much appreciated. Many Thanks

  4. #4
    Join Date
    Feb 2006
    Location
    Gilroy, CA
    Posts
    1,530


    Did you find this post helpful? Yes | No

    Default

    You are using one of the newer GPS's with a little higher resolution. With any handheld gps, there will be a little wandering of the output. You will see slight position changes, even though you are standing still. This will result in a display of speed, although it will be very low speed.

    The checksum is used to ensure the device reading the gps doesn't receive faulty input. If it is important for your application, the Pic chip can be made to perform a checksum on the sentence, and compare it to the one the gps calculated. If it differs, the data read from the gps is corrupt, and must be read again.

    To convert Knotts to km/h, multiply by 1.852. Since PICs don't do decimal, we will have to make our own. A close enough approximation of knotts x 1.852 is (knotts x 2048)/11, but remind yourselft that your result will have two digits past the decimal point. If you want whole numbers for km/h then divide by 100, or do (knotts x 2048)/1100. A handy tool to figure these fractions out is a download at the very bottom of this page: http://www.miscel.dk/MiscEl/miscel.html

    To convert, you follow my earlier example, but insert skips to match the format of your NMEA sentence.

    For your:
    Code:
    $GPRMC,123339.000,A,5134.2770,N,00007.8480,E,1.14, 254.38,271009,,*09
    it would be something like:
    Code:
    SerIn2 GPSin,baudGPS,Timeout,Nogps,[wait("$GPRMC"),skip 14,DEC2 lat_deg,DEC2 lat_min,skip 1,DEC3 lat_min_dec ....]
    you should be able to enter the rest for longitude now....

    The degrees and whole minutes are already in the format you want. We just need to convert decimal minutes into seconds. To do this, we use the same conversion I showed you in the previous example (except you will see that I forgot to add another digit for the seconds result). Here you have .2770 minutes. We only care about the first three digits. In fact, we might care about even fewer digits, but since we used three of the digits in the last example, lets just use three again.

    The following will multiply your 277 by 6. This will give you a result of 1662, which really is 16.62, but again, the PIC can't do decimal, so we will use the whole number, and just format it for output.
    Code:
    lat_seconds = lat_min_dec * 6
    DEBUG DEC lat_deg," deg ",DEC lat_min," min ",DEC lat_seconds dig 3,DEC lat_seconds dig 2,".",DEC lat_seconds dig 1, DEC lat_seconds dig 0," sec",13,10
    That would print out:
    "51 deg 34 min 16.62 sec", which matches pretty well with the 51 34 16 that you converted on line.
    Last edited by ScaleRobotics; - 27th October 2009 at 16:08.
    http://www.scalerobotics.com

  5. #5


    Did you find this post helpful? Yes | No

    Question

    Quote Originally Posted by scalerobotics View Post
    The checksum is used to ensure the device reading the gps doesn't receive faulty input. If it is important for your application, the Pic chip can be made to perform a checksum on the sentence, and compare it to the one the gps calculated. If it differs, the data read from the gps is corrupt, and must be read again.
    Thanks a lot. I think I need to sit down with the manual for sometime to learn about different conversions and decimal substitutes. Seems little complicated for now.

    But I still wanted to ask you that how do I checksum the data in PIC? I mean my PIC gets everything in a string which is comming from the GPS in the first place. Why it is a number, what does this number do?

    Can you please put up the code you have done as it will be far far easier to understand somthing working than perform a reverse engineering technique on it. From a beginners point of view what you explained above about checksum has gone past way above my head.

    Thanks

  6. #6
    Join Date
    Feb 2006
    Location
    Gilroy, CA
    Posts
    1,530


    Did you find this post helpful? Yes | No

    Default

    Quote Originally Posted by FromTheCockpit View Post
    ...Seems little complicated for now.

    But I still wanted to ask you that how do I checksum the data in PIC? I mean my PIC gets everything in a string which is comming from the GPS in the first place. Why it is a number, what does this number do?

    Can you please put up the code you have done as it will be far far easier to understand somthing working than perform a reverse engineering technique on it. From a beginners point of view what you explained above about checksum has gone past way above my head.
    Well, I didn't post my code because I do something a little different. I convert from deg min.min to deg.deg so I can perform some math on the waypoints. My code is very ugly and sometimes confuses me.

    I think it is very helpfull for people to be able to write code, and "make it their own". That is the only way they will be able to progress, and really make the code do things they want. So I try to give enough data for people to start playing around with the parts of code. The link to MeLabs sites GPS code is a fully functional code that will not have to be reverse engineered. Only needs to be edited slightly to read different digits by changing the skip 34, and a few other small things.

    I suggest you ignore pretty much everything I have written below this line for now, and get your hands fully around the above code by playing around with the serin2 command, and seeing what you can get to print out to your computer.

    This is NOT the code that I suggest playing around with, but if you must see it, here is a snippet. Darrell and others would probably say they needed a lot of toilet paper and a few Amodiums to go with it. If after seing it, you don't get sick to your stomach, I will try to explain the garbage. I would not say it is advanced. It is just too messy to explain properly. There are a couple errors I need to fix, with a few parenthesis in the wrong place, etc.

    This is assuming you use an array called gpsdata.....
    Code:
            IF gpsdata[char_A] = "A" Then              'was 9, Needs to be 13 for EB-85A                                       
                lathome_hi = ((gpsdata[char_A+2] - 48) *10)+((gpsdata[char_A+3] - 48))
                lathome_low = ((((gpsdata[char_A+4] -48)*1000)+((gpsdata[char_A+5]-48)*100)+((gpsdata[char_A+7]-48)*10)+(gpsdata[char_A+8]-48))*5)/3
                    lathome_min = ((((gpsdata[char_A+9]-48)*10) + (gpsdata[char_A+10]-48))*5)/3    'lathome_min
                    lathome_min = lathome_min + 33*((((gpsdata[char_A+4] -48)*1000)+((gpsdata[char_A+5]-48)*100)+((gpsdata[char_A+7]-48)*10)+(gpsdata[char_A+8]-48))*5)//3
                    tempbyte = lathome_min /100
                    lathome_low = lathome_low + tempbyte
                    lathome_min = lathome_min //100
                if gpsdata[char_A+12]=78 then north =1         '="N"
                lonhome_hi = ((gpsdata[char_A+14]-48)*100)+((gpsdata[char_A+15]-48)*10)+(gpsdata[char_A+16]-48)
                lonhome_low = ((((gpsdata[char_A+17]-48)*1000)+((gpsdata[char_A+18]-48)*100)+((gpsdata[char_A+20]-48)*10)+(gpsdata[char_A+21]-48))*5)/3
                    lonhome_min = ((((gpsdata[char_A+22]-48)*10) + (gpsdata[char_A+23]-48))* 5)/3
                    lonhome_min = lonhome_min + 33*((((gpsdata[char_A+17]-48)*1000)+((gpsdata[char_A+18]-48)*100)+((gpsdata[char_A+20]-48)*10)+(gpsdata[char_A+21]-48))*5)//3
                    tempbyte = lonhome_min/100
                    lonhome_low = lonhome_low + tempbyte
                    lonhome_min = lonhome_min//100
                if gpsdata[char_A+25] = 87 then west = 1 'check to see if we are W or E char 87 = "W"

    Ok, now you got that, have your wife or girlfriend grab you another roll of toilet paper, and we will move on to checksums.....

    I also, purposely did not go into check sums. You really only need to worry about checksums if your life, or your equipment is at risk because of the way you are using your GPS data. The reason it can be important, is that the NMEA sentences can be rather long. The one you are working with is in the neighborhood of 70 to 80 characters, though I have not counted. There are plenty of chances that by transmission through wires, or wireless, that one bit here or there could be missed, giving you a completely different location. Your equipment might not realize there was an error, unless it compared the checksum from the gps to its own calculated checksum on the data received.

    Basically, the checksum is a sum of all the data in the NMEA sentence. It does something similar to adding up all the ascii codes.

    I have some example code from an RCAP autopilot project, but this too is not really important if you are not making an autopilot, a hazard avoidance product, etc. So it can pretty much be left out of the equation for most applications.

    Code:
    DoCS:
        i = 0                             ' Initialize the position counter
                    
        While gpsdata[i] != "*"           ' Count everthing until the *
            cs = cs ^gpsdata[i]           ' XOR for checksum
            i = i + 1                     ' Increment position counter
        Wend
    
        ' A quick and easy atoh function
        ' Make it a seperate label if we add more atoh conversions in the future
        LookDown gpsdata[i+1],["0123456789ABCDEF"],tempbyte
        gpscs = tempbyte * 16        
        LookDown gpsdata[i+2],["0123456789ABCDEF"],tempbyte                
        gpscs = gpscs + tempbyte
            
        ' Flag bad data "V" if checksum doesn't add up. 
        ' Or if the sentence is less then 20 chars long
        ' Which means there is no active waypoint to go to.
        ' Should be "A" otherwise.
        IF (cs != gpscs) OR (i < 20 )Then 
              gpsvalid = 0
        Else 
              gpsvalid = 1
        EndIF  
    
    Return
    Last edited by ScaleRobotics; - 27th October 2009 at 19:01.
    http://www.scalerobotics.com

  7. #7


    Did you find this post helpful? Yes | No

    Question

    You are right. Toilet paper is over now. I am going to play with the code for next day or two and will put my findings and problems here. Thanks for the advise.

Similar Threads

  1. GPS $GPRMC to PIC16F684. Need help with SERIN2
    By xnihilo in forum mel PIC BASIC Pro
    Replies: 5
    Last Post: - 27th November 2009, 10:47
  2. Virtual LED Clock For Windows By Trent Jackson
    By T.Jackson in forum Code Examples
    Replies: 8
    Last Post: - 10th November 2009, 09:20
  3. new and need help
    By smeghead in forum mel PIC BASIC Pro
    Replies: 5
    Last Post: - 3rd November 2008, 21:19
  4. GPS clock timing !
    By bethr in forum mel PIC BASIC Pro
    Replies: 11
    Last Post: - 3rd July 2008, 21:11
  5. DS1994 Memory/Time iButton
    By NavMicroSystems in forum mel PIC BASIC Pro
    Replies: 47
    Last Post: - 22nd October 2006, 12:55

Members who have read this thread : 1

You do not have permission to view the list of names.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts