Is there any fix coming to this as it appears not be working in January 2015? Same data collected by GPS Tag with 10 min intervals, track is shown correctly in old GPS Trace software orange_1_0_shows_data_correctly.JPG174.08KB0 downloads but the new 2.0 does not show all data points orangegps_2_0_missing data points after 9_02.JPG120.38KB4 downloads. And the fix should not be "try using 30 sec intervals as 1) it will drain the smartphone's battery faster and 2) the GPS Tag setting advises using MINIMUM interval of 5 minutes.

It also looks like the battery level indicator in the tooltip shows almost empty battery when in the battery was actually full.

OK, I think I found a workaround for the above "feature". In Unit settings there's the tracks -button which allows to select the track parameters -button (which looks like a pencil). Behind that are the checkboxes and changing the default trip detector, i.e. DESELECTING (clearing) the check mark from the Trip Detection and saving the changed parameters, will then show the track as it is expected to be shown with e.g. 10 minute timeout operation mode.

I do not know if this is the right way to get the track visible, though. What is the actual purpose for the trip detector and how is it supposed to work?

Same drive route today 2014Jan4th,10 minute timeouts with Tag GPS. With Trip Detector enabled, no track at all is shown. With trip detector disabled, track is shown on the map.

It seems also that disabling the trip detector will reveal erraneous avg speed calculation. When data points are missing or inconsistent, the time traveled shown may be way too short and accordingly thee avg speed calculation is all over the place. For example, yesterday's data shows worst case max speed 73 MPH and Avg speed 983 MPH!tripdetector screws avg speed calculation.JPG63.65KB0 downloads

Probably this would not be detected if the data points were sampled and consistently recorded every 10 seconds or so. But with longer intervals and sometimes missing the data, the software does not handle the inconsistencies correctly?

I will attach another snapshots of the inconsistent data to the next post below.

With today's data I saw a "teleport" effect. This seems to be due to writing GPS data without GPS yet having fix. When starting GPS Tag and GPS, Tag seems to record lat/lon data (probably also speed?) when there is no GPS fix yet. It can be seen in data since the # of satellites shown is one so there is no fix. So when the GPS has not acquired fix yet, it probably returns to GPS Tag the last known coordinates it had. But recording those to database (or the GPS Trace 2.0 not filtering those out in post processing) leads to showing on the map the "instant teleporting" from a previous location to the actual location in two seconds.1st data without GPS fix yet so it has old coordinates.JPG98.45KB0 downloads

Another peculiarity in messages log is the random number of data lines by Tag. Using 10 minute timeouts, I can see none (i.e. data missing), one, two, three (typically) and also four lines with a few seconds between their timestamps. Just strange. Here a snapshot of four, two and one data line in successive ten minute timeouts:4 and two and one data lines shown.JPG88.93KB0 downloads

I guess post processing may not know that this kind of data files are generated by timeout mode so filtering the messages in postprocessing may be tricky if there is no information about the timeout mode. So would it make sense to have GPS Tag do some preprocessing and sending only one data line out instead of sending multiple raw data lines, to make the data more consistent looking?

Basically those issues are co-related, i mean the trip detector was implemented to cut those GPS-jumps and other data which may be invalid. It has some restrictions in terms of minimal distance, speed and time, which may really affect the track, So you tested both modes and one without trip detector seemed more reliable for you, which is OK, that means your GPS-receiver sends the valid data.

As for your suggestions about preprocessing it may make sense, but i think the best way is to post-process them on the server while requesting tracks in order to save your smartphone battery and other resources, so we're doing this via trip detector right now as per parameters i mentioned before. If you can propose the most advanced criterias we'd be happy to considerate them.

Hello, mates.
Could you please advice how to Turn ON Tracks.
Here it is my screen - http://prntscr.com/a40fgc
I can't find any button any configuration which can activate this.
Thanks in advance.
Regards.