Is there a "GPS reading" complete type of bit? I could use that to delay calling the servo function until the GPS is finished it's process.
The most reliable indicator is gps.available(). Once that happens, you know the GPS is going to be quiet for "a while". But how long will it be quiet?
That depends on two things: the GPS baudrate and the number of sentences it must send. In your case, you have enabled 2 sentences (~140 characters). At 9600, 140 characters take ~140ms to be transmitted. If the update rate is 1Hz, you have 1000ms - 140ms = 860ms to do Other Things.
You could set a timestamp when the GPS quiet time starts (immediately after gps.available):
if (gps.available()) {
fix = gps.read();
fixCount++;
lastGPStime = millis();
Then you can test it elsewhere, to see if GPS data is going to start arriving again:
if (millis() - lastGPSTime < 860) {
// *probably* no GPS chars yet, it's ok to do something
Or, if you know how long a task will take, don't start unless there's plenty of time left:
if (millis() - lastGPSTime < 860-EST_TASK_TIME) {
// *probably* no GPS chars yet, it's ok to do something
For example, printing 100 characters will take about 100ms. But the first 64 happen immediately, and the last 36 block for 36ms, while the first 36 characters are removed from the TX buffer. Your estimated time for that "task" would be:
const uint32_t EST_TASK_TIME = 100 - 64; // 36ms
I'm not sure about your question, though. Because you are using HardwareSerial, it saves up to 64 characters, even if you never call read() (or gps.available()). So during that 140ms time window when receiving GPS characters, you only need to check once.
Another way to look at it: If you start a task close to the next update, it must complete within 64ms of that start time. So you could wait as late as:
if (millis() - lastGPSTime < 860-EST_TASK_TIME+64) {
// *probably* no GPS chars yet, or they're getting buffered, it's ok to do something
If it starts getting messy, just make sure that no task ever takes longer than 64ms. Break the task up into smaller steps if necessary. And make sure that all task timing is running off of the gps.available "clock".
"Controlling a servo" isn't really a dedicated process is it? Don't you just set the "value" (PWM) and then continue? When a new value comes in over Xbee, you set it again.
Perhaps sending a reply could take a while? If you send the reply immediately after gps.available, it will surely complete long before a new GPS update begins.
Note: You can very quickly write up to 64 characters in all Serial devices, one after the other. All of this data will fit in the separate TX buffers, so it's very fast. It's the 65th character on any device that will make the sketch block for 1ms. Yawn.
There are some additional tips at the bottom of the Troubleshooting page.