i am wondering, which timer would be better to use for my app, millis or gps.

Heh, heh. It depends on what you're using the timer for...

If you are blinking an LED, just use

millis(). As we know, this GPS device does not provide the fixes at an exact 50ms interval. The

fix information is spaced at 50ms intervals, but they are

*received* at irregular intervals. So if your timed task needs

*regularity*, and/or it's a fairly simple task, just use

millis().

If you are doing something "expensive" (e.g., printing, writing to an SD card, or reading a sensor) or something that happens when you get new GPS information (e.g., speed limit, geofence, or lap timer), coordinate it with the

fix arrivals to balance the CPU load. When a new

fix becomes available, the GPS quiet time has started. That's the best time to do the heavy lifting.

i think that millis is a better choice, as i think is closer to real .050's of time comparing to messages number received. but this is also kind of overkill as gps messages are also more accurate than 50ms.

Yes,

millis() is definitely better for relative times where accuracy isn't important AND when you're doing something simple. Conversely, the GPS times are atomically accurate absolute times, and they come in batches at irregular intervals.

i have saved the lat lon of a track finish line, and if the position i am at the moment is less than 0.0004 in decimal degrees both lat long, i reset the lap and save the last one... but what happens if a message is lost? ... then i will miss a whole 50ms.

Yes, that is why I pointed you to

this thread. It calculates the crossing time by "intersecting" the vehicle path segment (two GPS fixes) with the finish line segment (two locations from Google maps):

When you use a "line-crossing" calculation, it doesn't matter if you lose an update. The math uses the timestamp in the fixes to calculate the intersection time. The code is in reply #15; here's the juicy bits:

`static void Intersection()`

{

s1_x = p1_x - p0_x; // Finish line segment is p0-p1

s1_y = p1_y - p0_y;

s2_x = fix.longitudeL() - lastFix.longitudeL(); // Vehicle path segment is fix-lastFix

s2_y = fix.latitudeL() - lastFix.latitudeL();

s = (-s1_y * (p0_x - lastFix.longitudeL()) + s1_x * (p0_y - lastFix.latitudeL())) / (-s2_x * s1_y + s1_x * s2_y);

t = ( s2_x * (p0_y - lastFix.latitudeL()) - s2_y * (p0_x - lastFix.longitudeL())) / (-s2_x * s1_y + s1_x * s2_y);

// see if they intersect (t and s both between 0 and 1)

if ((0 <= s) && (s <= 1) && (0 <= t) && (t <= 1)) {

// Intersected!

i_x = p0_x + (t * s1_x); //Intersection Longitude

i_y = p0_y + (t * s1_y); //Intersection Latitude

dt = lastFix.dateTime_cs - fix.dateTime_cs;

if (dt < 0)

dt += 100;

i_t = s * dt; // Intersection Time as 0.01s offset from lastFix.

}

lastFix = fix; // save it for next time

} // Intersection

BTW, that sketch uses the older character-oriented methods (decode). You should stick with the fix-oriented methods (available and read).

i couldnt get the fix.latitude() or fix.longitude() to display.

Show. Code.

Or look at NMEAsimple.ino. Maybe the Digole library does not support floating-point output?

couldnt convert them to string

I'm sure you mean a C string, aka

char arrays, 'cuz nobody should use the

String class. There is a way, but why do you need a string? Everything you've mentioned so far could use a

print method. It's always better to print the pieces than to put all the pieces in one big string, and then print the big string.

does neogps give distance travelled? if not, i have to calculate it through lat lon

No, and correct. Like this.

`float odo; // km`

void loop()

{

if (gps.available()) {

fix = gps.read();

if (fix.valid.location && lastGoodFix.valid.location) {

odo += fix.location.DistanceKm( lastGoodFix.location );

lastGoodFix = fix; // save for next time

}

You may want to skip this when the speed < 5kph. GPS "wanders" all the time, so if you're stationary you'd be adding up the jitter, accumulating distance.

Cheers,

/dev