Just an idle question, does anyone know why all the GPS modules I can find have a data interface which still uses RS232 at very low baud rates?
The last time I used RS232 was to interface to a Hayes 9600 Baud modem as I recall in 1984.
If you know of any out there which support I2C please let me know.
does anyone know why all the GPS modules I can find have a data interface which still uses RS232 at very low baud rates?
Because the GPS data rate is low? Fixes are calculated at a rate between 1Hz and 10Hzzzzzz. Most GPS modules support changing the baud to 115200 with a configuration command. And some GPS modules support SPI (e.g., ublox).
Combined with the inherent error, getting the fix data faster doesn't help very much. If it's timing you're after, the PPS pin is the most accurate.
Perhaps the biggest improvement you can get, for the least cost, is fast software. My NeoGPS library is almost twice as fast as other libraries out there, and can save you hundreds of bytes of RAM and thousands of bytes of program space. I also have companion serial libraries that allow the GPS data to be parsed during the serial interrupt, saving even more time. This makes 10Hz SD logging almost trivial.
Cheers,
/dev
I understand the slow sample rate.
But the badly phrased question was not about increasing it, just the futility of having to check and parse a text string to obtain the numerical values, and include extra code and libraries to handle the protocol.
Futility? That's just dealing with a smart device.
I am working with a GPS/GSM module where I request the GPS info and then pass it on as a text (vehicle tracking).
The text is sent periodically, like every half hour or hour.
So, once an hour I send a GPS request,
at+cgpsinf=4
Then I wait for a response that ends with OK and store the received data in an array:
if (Serial1.available()>0){
inGPS = Serial1.read();
// 13, 10, 32 ignore CR, LF, Space
if ((inGPS !=13) && (inGPS !=10) && (inGPS !=32)){
dataGPS[y] = inGPS;
if ((dataGPS[y-1] == 'O') && (dataGPS[y] == 'K')){
Serial.print("Case 1,received: ");
for (x=0; x<(y+1); x=x+1){
Serial.print (dataGPS[x]);
}
Serial.println("");
y=0; // set up for next message
}
else {
y=y+1;
}
}
}
Then the tricky part - the data can come back multiple ways, so you have to be able to handle it. My unit sends out one of these:
at+cgpsinf=44,0.000000,N,0.000000,E,031323.598,V,AOK
at+cgpsinf=44,4222.033483,N,7131.739679,W,040711.000,A,AOK
at+cgpsinf=44,4222.033483,N,10031.739679,W,040711.000,A,AOK
consisting of latitude (north/south), longitiude (east/west), and time
The first part just repeat the command, at+cgpsinf=44, you should confirm that is correct to make sure a valid response is received.
The latitude/longitude can vary - I see all 0s when GPS signals aren't being received yet.
If good data is coming in, there can be 3 or 4 digits before the periods for latitude, depending on where you are from 0 (close to equator) to 90 (close to poles) degrees, and 3,4,5 digits for longitude.
In the US, the range is around 40xx.xxxxxx (east coast) to 125xx.xxxxxx (west coast) for latitude, and
25xx.xxxxxx (Mexico) to 45xx.xxxxxx (Canada border) for longitude
so you need to be able to handle those variations.
What I did was look at the specific locations to see where the periods where, and then parsed the data up based on which of the 3 was received; the all 0, the 4 digits each of latitude & longitude, or the 4 digits of latitude and 5 digits of longitude.
Anyway, I got pulled aside a couple times while creating this message. Requesting a data read and receiving the data is n't hard, deciding if what you get back is good and then understanding it is trickier.
You can do similar based on where you expect to be using your GPS.
Or you can make it more generic to handle world wide, in which case you also need to handle the N/S and E/W indications.
If you want to put the data into google maps, then W is a negative number, for example in the Boston area entering 42.22, -71.31 will get you a cemetery in Norfolk.
Thank you,
I fully understand how it does work, I was just wondering if there was some obscure reason that the interface protocol has not been updated over time as more efficient ways have become available.
just the futility of having to check and parse a text string to obtain the numerical values, and include extra code and libraries to handle the protocol...
I was just wondering if there was some obscure reason that the interface protocol has not been updated over time as more efficient ways have become available.
Serial vs. I2C is a transmission medium question, and is independent from the messages that are exchanged. Serial is still very common and is (usually) much simpler to use instead of the I2C protocol. RS-232 is a further distinction of the voltage levels used to indicate the serialized 0 and 1 bits. Arduinos are not at RS-232 levels, they are "TTL" or "Logic" levels, 5V or 3.3V, depending on the Arduino. 
If you're complaining about NMEA messages (aka "sentences"), welcome to the club. The original messages are not designed very well, so many manufactures add their own proprietary NMEA messages with better combinations of information.
That's also why many GPS manufacturers have their own binary protocol that doesn't require quite so much parsing as NMEA messages. For example, the ublox GPS devices have a binary UBX protocol that is fairly easy to "pour" sequentially-received bytes into a C struct. For the most part, you can simply use the structure members directly. UBX has message framing, a header and a checksum, so there is some protocol handling. A full implementation has to handle UBX messages acknowledgements, which is much more complicated than the line-oriented NMEA text message. Fortunately, Arduinos are Little Endian like the UBX messages.
BTW, NeoGPS has some C structure definitions in the ublox subdirectory. It shows techniques for mapping the message format onto a C structures, if you want to go down that path.
But as I said, the GPS update interval is very long when compared to the processing time it takes to parse a message. For example, NeoGPS can parse an NMEA sentence in ~800us, which is two orders of magnitude faster than the shortest GPS update interval of 100ms. At 9600 baud, that's less than the time it takes to transmit one character of the ~80 character sentence.
Cheers,
/dev
Thank you for your response, I actually have a spare ublox GPS from one of my drones, I shall do some research!