The GPS time on the VA-HR runs 5% slow.

It seems the GPS time on the VA-HR is running about 5% slow (1 second in 20) and catches up by skipping a second every 20 or so.
I have created a 10-second of the demo I used in my previous bug report (Note the date is 1997-01-28, 20 years -1 day out)
The replay starts at 07:48:25, and runs to 07:48:33, but skips 07:48:31.
https://youtu.be/yGTkDTlxz7Y
I first noticed this in my development app and suspected it was being influenced by the background processing, but find it's occurring in the very simple demo of the "Garmin time" bug I reported yesterday.

function onShow() {		

		Position.enableLocationEvents(Position.LOCATION_CONTINUOUS, method(:GPSData));	  

    }



    // Update the view

    function onUpdate(dc) {

 		dc.clear();

		var timestruct = Gregorian.info((new Time.Moment(timeSecs )), Time.FORMAT_SHORT);

 		 

		formattedReportTime = timestruct.year +"-"+

			timestruct.month.format("%02u") +"-"+

			timestruct.day.format("%02u") +"\n"+

			timestruct.hour.format("%02u") 

	    	+ ":" + timestruct.min.format("%02u")

	    	+ ":" + timestruct.sec.format("%02u");

		dc.setColor(Graphics.COLOR_BLACK, Graphics.COLOR_WHITE);

		dc.drawText(70, 45, Graphics.FONT_SYSTEM_MEDIUM,formattedReportTime, Graphics.TEXT_JUSTIFY_CENTER);

    }

    

		function GPSData(positionInfo){

			timeSecs = positionInfo.when.value();//in whole seconds

			Ui.requestUpdate(); // display new data fields

   }

Coleman.Apps over 8 years ago

Hey,

Thank you for reporting it. We should be looking at this shortly.

-Coleman

Alan.raceQs over 8 years ago

(Image removed to recover Forum image space)
(see following post for explanation)

Alan.raceQs over 8 years ago

...continued
I reported this issue two months ago and haven't had any update, so I thought I would have another go and update my report with an image and some supporting detail.
I had previously reported that the GPS position callback appeared to run slowly and skip a report every 20 seconds or so, so I modified my app to record time, latitude and longitude in the LOG file to compare the resulting data (which I refer to as APP Data) with what appears in the FIT file (FIT Data).
Unfortunately the Garmin Connect replay doesn't give enough detail so I used gpsvisualizer.com to convert the FIT file to a GPX format and then pasted the LOG file data into the GPX file as a separate <trk> and loaded it into Google Earth.
(I have been working with GPX files and Google Earth for many years, so this was quite a simple task. )
continued...

Alan.raceQs over 8 years ago

...continued
I have pasted the analysis into the attached image which shows:

The APP data misses one point every 20 seconds or so (I show one example at 00:31:26Z)
After missing that point, it mis-labels the timestamp of the following points by 1 second. ( Example: from 00:31:26 to 00:31:32)
And around seven seconds later, it re-synchronizes by skipping a second. (Example from 00:31:32 to 00:31:34 - missing 00:31:33)

The points are labeled in the image.

I also reiterate the issue with the timestamps being 30 years less 1 day early (1997-03-27 not 2016-03-26)

Alan.raceQs over 8 years ago

And here are the files (remove the .txt extension before use...required to enable the upload!)
20170325173415-00242.gpx.txt is the GPX file
GPSReport.kmz.txt is the converted Google Earth KMZ file

Coleman.Apps over 8 years ago

Hey,

Thanks for the updated information. Sorry about all of the issues getting the information posted in the forum. I've done another check on this. This ticket has been moved to the device team to work on and they have a fix planned in there release schedule. I don't have access to know when this will be fixed, but wanted to let you know that the fix has been planned.

Thanks,
-Coleman

Alan.raceQs over 8 years ago

Is anyone working on this?
I have more findings about the timing issues with the location updates from the Position Module on the VA-HR which appear to result in missing and inaccurate data in the Location object.
When looking at the updates, I am finding a "cycle" of around 20 seconds (+/- 5) during which the location update is triggered increasingly late, eventually being a whole second late at which point the Info.when value skips a second to re-synchronize.
Analyzing the Location coordinates, during each and every "cycle":

one location gets missed, and
one pair of successive locations have a two second time delta.

The result is that if I compare the reported speed (positionInfo.speed ) with a calculated speed (from from successive Location coordinates and Info.when) I get tremendous differences that I have charted in the attached image.

The blue line is the reported speed, the red is the calculated speed. The peaks coincide with the missing location (1 above) (twice the distance in one second) and the troughs, with the skipped second (same distance in twice the time) (2 above).

I also suspect that the reported speed is around 5% slow, but I'm still short conclusive evidence. The graph would indicate that is the case and I have field reports that the speed reported in my watch app (raceQs) which I derive from positionInfo.speed is lower that what is reported from hand-held GPS units.

I have detailed material supporting these findings, but before putting in the effort of assembling then into a structured paper I would like to know if the problem is already known and I'm preaching to the converted.

Brandon.ConnectIQ over 8 years ago

Yes, this has been investigated and discussed quite a bit between the device team, the Connect IQ team, and the core technology team that maintains GPS. I can't get into a lot of detail here, but there are a couple of possible explanations, and it's not clear whether this can be attributed to root cause or is a confluence of multiple factors. I'll include your latest comments on the ticket, but you may consider this a known issue and we recognize there is something odd occurring. Once we have things narrowed down, we'll post back here with updates.

Alan.raceQs over 8 years ago

Thanks for the prompt reply.
Please let me know if there is anything I can add to the pot to get an early resolution.
It's causing me considerable problems as my app is trying to detect movement patterns at the limits of the GPS resolution, and these inaccuracies are messing with my algorithms.

Alan.raceQs over 7 years ago

Location.Info.when is NOT the "GPS time stamp of fix"

As I have noted above, the date part of the timestamp is 20 years + 1 day slow (shows 1997-05-10 when it's really 2017-05-09) but I have come to suspect the time part as well, so I did some checking and found that if I change the time to manual and set the clock ½ hr slow, then the time reported in Location.Info.when is also ½ hr slow.

So, contrary to what the doco on #when says, Location.Info.when is NOT the "GPS time stamp of fix", it is the internal clock time of the watch.

This is a major oversight asthe time of a GPS location isjust as important as the coordinates.

And, as I have said above, the time runs around 5% slow and catches up every 20 seconds or so by skipping a second.

We all know that the GPS subsystem in the watch has to synchronize its clock with the satellites, and will therefore be accurate within microseconds or less, so why is it not being reported at least to millisecond precision?

My app is working at the limits of accuracy of the coordinates around 3-5 metres (it operates on water so always has a great view of the satellites) . At a normal sailing speed of around 6 knots (~3 metres/sec), a 1/2 second error in the position report adds a further 1-2 metres error on the position report. This really compromises the hard work I'm doing.

Is there any progress in getting it fixed?