> Russell McMahon wrote: > > [...] > > However, I have been decoding selected sentences in BASIC (! :-( ) and it is > > a relatively trivial task due to the fact that for a given sentence, all > > fields are always present even when data is absent, with comma delimiters > > being provided for fields with null data. This means all you have to do is > > "count the commas" from the string identifier and then read everything from > > the comma of choice until the next comma. > > > > RMC and GGA are almost always nicely behaved with the absolute length of the > > fields not varying so that you can even just count N characters from the > > string identifier and then take a set number of characters as your data. > > > To write code that will work with any GPS receiver's NMEA output you > can't just count characters. The field width for the time can vary > dependent upon whether the receiver outputs seconds or not. The field > widths for latitude and longitude can also vary with 3 or 4 characters > after the decimal point. I'd suggest to anyone developing a general > NMEA parser to look at examples of NMEA data sentences as well as the > output from their own receiver. If you stick with the comma delimiters > then you avoid having to consider any of these differences. > > Kayode. > ________________________________________________________________________ > Visit http://www.stv5730a.co.uk and put your next PIC project on TV > with the 16F84 STV5730A on screen display project board. > You are correct Kayode. You must count commas, not the number of bytes that could be in a sentence because the number of bytes change. The number of commas do not. Thanks to all who responded to my original request for help on this thread. It is greatly appreciated. Its amazing how many people ask for my final code when I'm done. I'll let you guys know when I've completed it. Thanks, Charles -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email listserv@mitvma.mit.edu with SET PICList DIGEST in the body