I'm playing with a GPS module (https://www.sparkfun.com/products/8975) that communicates at 57600 bps (I think this refers to bits per second, NOT bytes per second). Dividing by 8 gives 7200 bytes per second, and assuming a typical NMEA sentence of up to 85 characters, this means a full sentence can arrive in about 12 milliseconds. (please correct my maths if I've got this wrong)
The serial input buffer on the arduino Mega is 64 bytes (or 64 characters) so if it isn't checked very frequently, there's a danger that the buffer will fill and NMEA data will be lost in between read()s.
The GPS library that I've got works fine in all low level testing when the read()s are taking place every few milliseconds and the data can be processed quickly. I know that the data's good because I'm able to validate the NMEA checksum and confirm that more than 99% percent of the NMEA records are coming across correctly.
This library then gets used in a much bigger project where the arduino is also busy doing things like course correction, altitude calculation, logging and sending data. The result on the GPS library is that
• The port the gps module is connected to only gets read once every 20-50 milliseconds.
• The bytes awaiting processing each time a read occurs is between 80-100% of the buffer size (64 bytes).
• The percentage of NMEA sentences successfully validated drops from about 99% to 70% or less.
What's the solution? Would lowering the GPS bit rate work (if so, how is this done? I can't spot a way to set this on the datasheet), would it help if I increased the size of the buffer that I hold the NMEA data in before I attempt to process it (this is currently set to 120 bytes). Or perhaps I should create a lower level library that just reads the GPS data from the input port into a buffer, and then only processes that data when I actually need it?
I've not posted code because I'm not looking for a specific fix, more some general ideas on what to do.
Thanks