Location smoothing VA-HR

I'm not familiar with the filtering you are seeing, so I will try to ask our sensors group about it next week. However, my suspicion is that any filtering of this type that is going on is not likely to be happening at a level where ConnectIQ has any chance of accessing the "raw" data.

I spoke with our sensors group, and they don't think that there should be any lag as severe as you are describing. We do apply some filtering to our speed values, so you may see delayed values for any calculations that incorporate speed.

If you are having an issue with speed, you may have some luck deriving your own speed value from change in position.

ConnectIQ is accessing the most direct (only) GPS source available on these devices.

No, it's not related to speed at all. Your comment about the calculation of speed values really worries me but I'll address that as a separate issue.

I have prepared a video of a test case to demonstrate the reasons I believe there is filtering.
I'm walking on a playing field, displaying the distance from my current position to a line that I have defined by the location of the two ends. (It's to do with distance from the start line in a yacht race). The line is identified by a rope on the ground.

I believe that the video indicates that the position reports are being filtered for the following three reasons:

• The distance doesn't start reducing until about 3 seconds after I start moving. Without filtering the numbers would start moving as soon as I start moving.
  
• There is about a 3 second delay after I stop on the line before the position reports catch up with my position. Again this shows a lag in the response.
  
• Once stopped, the distance reports remain within +/- 1 metre of zero. I don't think that any manufacturer would claim their domestic GPS is capable of 1-metre accuracy.
  

The code uses basic trigonometry to determine the distance of a point from a line, and uses the position data directly from the Position object:https://youtu.be/CvMr9oP4Ni0
Position.enableLocationEvents(Position.LOCATION_CONTINUOUS, method(:GPSData));

I have no ax to grind on this issue, I'm just trying to get a conversation going on a subject that is dear to my heart.

I spoke some more with the sensors team. There is static mode filtering done by our solution to prevent "wandering" when stopped. This is what you are seeing when stopped and when starting movement.

The delay when reaching the end of the line, by my measurement of your video, is approximately 1.5 seconds, which is maybe a bit more than I'd expect from a 1Hz signal, but pretty close.

I've created a feature request ticket to investigate if anything can be controlled with regard to the static mode filter, but even if we allow ConnectIQ to control this, it would only impact the starting lag you see and stationary stability. The delay approaching the line would not be affected.

Thanks, Brian. The info on the static mode filtering is interesting and certainly explains the delay in starting.
I will do some further testing to see if I can more precisely quantify the delay that I'm talking about.

Re my concern about your comment.

If you are having an issue with speed, you may have some luck deriving your own speed value from change in position.

My experience with other GPS devices, is that speed and heading are generated quite independently of the position and time. They are not derived from change in position.
Some sources describe the derivation of speed and heading on the GPS chip from a "doppler" analysis of the satelite signal, but that's above my pay grade.
I have done many analyses, where I compare the track based on the position (lat/lon) data, with a "Dead Reckoning" (DR) track where I derive the next position by using the speed, heading and time interval reported from the GPS. (This is exactly the reverse of deriving speed and heading from change in position).
The DR track always generates a smoother track, but one which, not unexpectedly, diverges over time from the position. In a 90 minute yacht race, where the boats are travelling at 5-8 knots (~12 kps), and the yachts have traveled 6 or 7 Nm around a race course I have found that at the end of the race the tracks have diverged by as little as 200 metres.
The point here is that when analysing racing yacht performance, I am often more interested in speed and heading than in position, and that the GPS speed and heading provides a more accurate value than I can derived from position and time.

Could you please a dig out a fuller description of the derivation of speed and heading on the VA-HR please as it directly affects the performance algorithms in the app that I'm porting from pebble? I am really running out of time to work it out experimentally.

The speed provided by our device is not generated using change in position. I only suggested this as a "unfiltered" source of velocity data. The static mode filter would cause issues with a speed value derived that way, so it probably is not super useful.

I won't be able to provide any information about the details of speed derivation. The speed is determined by the GPS receiver. Our products may be doing fine tuning for the applications they are targeted to (e.g. Fitness). I think we had some issues previously with providing a speed value that was heavily filtered for the purposes of running pace, but I don't think you should be seeing that in the latest builds.

I don't have any reason to believe that heading should be different from any other GPS sources you have used, but if you see major discrepancies, I would be happy to share any reports with our sensor team.

I do wish we had a raw feed available and we could simply hook them up for CIQ, but right now, the devices we run on are purpose built for the applications they are designed to, and may contain optimizations that aren't ideal for other activities. Right now, what the product has is all we can work with, but we may be able to address this more as the platform grows.

I have just done some more field testing and am amazed (and pleased) with what I see.
https://youtu.be/cK5Y7gClBQ0
I was being blindsided by the "static mode" filtering. When I take that into account, I see only around a 1 second delay in the position reports plus a sub-two metre position accuracy.
That's amazing! Much more so for the fact it's being generated from such a tiny device.
Thank you for your reply on speed and heading, I'm much less concerned than I was about that now and will do some DR testing over the next few weeks.
My only niggling concern is that towards the end of my testing, after about 1/2 hr of messing about getting a working video, the position reports started to drift, as if the position of the line had moved around 5 metres further away. When I re-entered the line location it all went back to normal. I'll do some more testing.

One thing about heading (Brian, please correct me if I'm wrong!), is on devices with a HW compass (like the va-hr), it seems the HW compass is used below a certain speed, and then switches to using GPS if GPS is on. That speed is quite low - like if your walking at all. So if you stand still, the heading will reflect you turning around and have the watch in a different direction, but if you are moving, it's which way you are actually going.