On old system i have all correct tracks but on new i have only a part of all.
On both the same day.
Jump to content
Posted 28 July 2014 - 11:33 AM
i guess the problem is in the timespan between messages, a trip detector applied on the new service by default. Try to set the frequency like every 1min or 30sec and request a track then.
You mean changing the upload interval on the tracker?
Have you tried my TLT-2H Easy Setup App?
Posted 03 January 2015 - 23:02 PM
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
0 downloads but the new 2.0 does not show all data points
orangegps_2_0_missing data points after 9_02.JPG 120.38KB
4 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.
I am using GPS Tag 1.8.83 in Android.
Posted 04 January 2015 - 00:52 AM
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?
Thanks for the great free product anyways!
Posted 05 January 2015 - 00:51 AM
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.JPG 63.65KB 0 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.
Posted 05 January 2015 - 01:23 AM
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.JPG 98.45KB
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.JPG 88.93KB 0 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?
Posted 05 January 2015 - 07:49 AM
thank you for your great research and suggestions!
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.
0 members, 0 guests, 0 anonymous users