Strange GPS behavior

The app second crash yesterday occurred just under an hour after re-starting the app. It crashed to the IQ! and was immediately restarted and it performed without a hitch for the rest of the race, a further 1 ½ hours.

CIQ_LOG reported :
ERROR: Unhandled Exception
DETAILS: NONE
STORE_ID: 00000000000000000000000000000000
CALLSTACK:
 
WARNING: Error in positioning callback
STORE_ID: 00000000000000000000000000000000

Not very informative, but I still had some data in my log file which reported:

UnexpectedTypeException: Expected Number/Float/Long/Double, given null/Number
showWindShift in C:\alan\projects\raceQsGarmin\raceQs\source\engine.mc:1968
dispData in C:\alan\projects\raceQsGarmin\raceQs\source\engine.mc:1717
GPSData in C:\alan\projects\raceQsGarmin\raceQs\source\engine.mc:808

Line 1968 of my code is:

if (TWA < 0){// port tack
	if (PCPort == null){return;} // no Prevailing Course

Again, a piece of code frequently traversed and it's nigh on impossible for the variable TWA to become null, but I went looking for a scenario to cause this and went back to the where the crash occurred.
When I looked at the track recorded in Garmin Activity (unloaded to GPX and imported into Google Earth) after it restarted after the crash, I found some very unusual data:
The first point recorded after the app restart was incorrect by around 60 metres to the North.

The blue marks are the track recorded up to the crash, the green marks are the track recorded after the crash. The points were recorded at one second intervals. We were travelling at around 6kts (3 m/s or 6 mph) in a Northerly direction at the time.
I have been analyzing tracks for a long while and whilst I'm familiar with the occasional "excursion" I haven't seen one like this before.
Note, the watch didn't crash and the app restarted normally and re-acquired a GPS signal quite quickly. We were in open water with a great view of the sky.

I wonder if my app crash was in fact triggered by some event in the GPS sub-system.

jim_m_58 over 7 years ago

When looking at the GPS data, are you taking the accuracy into account? (the 5 levels available) Maybe there was a GPS dropout.

Alan.raceQs over 7 years ago

are you taking the accuracy into account?

This is the Garmin Activity (FIT) data, created by Record.createSession, which I only invoke once the signal strength >= 3.

I also log the GPS positions myself and get the same abberation in the track. So yes, I am taking signal strength into account.

Maybe there was a GPS dropout.

What, the satellites stopped transmitting? I went into a tunnel (in open water)?
Possible but unlikely.

travis.vitek over 7 years ago

It seems to me that TWA was null. Have you double-checked all of the places that assigned TWA to verify it could never become null? Maybe it would be a good idea to insert a check? If you do it this way the check will be compiled out in a release build...

Test.assertMessage(TWA != null, "TWA is null");
if (TWA < 0) {
    if (PCPort == null) {
        return;  // no Prevailing Course
    }
}

jim_m_58 over 7 years ago

What, the satellites stopped transmitting? I went into a tunnel (in open water)?
Possible but unlikely.

Watch on wrist, reach into metal cooler and search for the cold beverage of choice. No GPS...

What if you go below deck (maybe below the water line) with the watch? How good is GPS them?

What if the metal cooler is below deck, and you then search for a cold beverage?

Open water doesn't mean clean GPS 100% of the time to me... And something to consider as GPS accuracy is there to check, and should be used, for every reading used by your app.

Could this be connected to other bugs you are tracking down?

Alan.raceQs over 7 years ago

Watch on wrist, reach into metal cooler and search for the cold beverage of choice. No GPS...

Nope, no metal cooler on the boat (it's fibreglass, so GPS translucent), anyhow no consumption of cold beverages at the time.

What if you go below deck (maybe below the water line) with the watch? How good is GPS them?

Nope, anyway below deck on a racing boat is still above the waterline and there's a strong GPS signal through the thin cabin top.

What if the metal cooler is below deck, and you then search for a cold beverage?

Nope, fiberglass cooler is below deck and anyhow was not in use at the time.

Open water doesn't mean clean GPS 100% of the time to me...

Not claiming 100% but getting +/- 3 to 5 metres in normal usage when measuring against a second independent device.
So the 60 metres error is extraordinary.

And something to consider as GPS accuracy is there to check, and should be used, for every reading used by your app.

And I ignore any reading of less than 3

Could this be connected to other bugs you are tracking down?

Nope, totally different circumstances and different error

(But I did track the earlier one down. With your help, I found an obscure condition that caused me to store a null in the array.)

This is probably due to a null in the TWA variable as suggested, I'm working on chasing it down. This null handling in MC is a real pain!

The bizarre GPS report may be totally unconnected, but it's still a worry, especially as it occurred at the start or the app. It really makes me think something went wrong in the GPS system.

Former Member over 7 years ago

This GPS behavior doesn't surprise me much. When your app crashed, the GPS radio would have gotten switched off, and then it was switched back on when your app started. This required it to re-acquire its fix, and deviations like this for the first few seconds of a fix are pretty normal, especially with the "quick fix" technologies that are used on chips today.

If you are only requiring the fix to be >= QUALITY_USABLE (3), then there is no HDOP (horizontal dilution of precision) guarantee for that fix. To reach QUALITY_GOOD (4), we do check against a maximum HDOP.

Alan.raceQs over 7 years ago

This GPS behavior doesn't surprise me much. When your app crashed, the GPS radio would have gotten switched off, and then it was switched back on when your app started. This required it to re-acquire its fix, and deviations like this for the first few seconds of a fix are pretty normal, especially with the "quick fix" technologies that are used on chips today.

Makes perfect sense.

If you are only requiring the fix to be >= QUALITY_USABLE (3), then there is no HDOP (horizontal dilution of precision) guarantee for that fix. To reach QUALITY_GOOD (4), we do check against a maximum HDOP.

It's great to see some definitions being put to numbers.
I was working from values I was seeing from position::info::accuracy, and was seeing a reasonable fix at 3, so used that.
I hadn't seen this spelled out in the API Docs.
Could the API Docs be updated to reflect these values please?

jim_m_58 over 7 years ago

It already is there. This is from the 2.2.2 SDK API doc: (the oldest one I still have but this has been in the doc for a long time!)

QUALITY_NOT_AVAILABLE = 0
The QUALITY enum is used to represent the quality of GPS fix with which the Location information was calculated.

GPS is not available
Since:
1.0.0
QUALITY_LAST_KNOWN = 1
The Location is based on the last known GPS fix.
Since:
1.0.0
QUALITY_POOR = 2
The Location was calculated with a poor GPS fix. Only a 2-D GPS fix is available, likely due to a limited number of tracked satellites.
Since:
1.0.0
QUALITY_USABLE = 3
The Location was calculated with a usable GPS fix. A 3-D GPS fix is available, with marginal HDOP (horizontal dilution of precision)
Since:
1.0.0
QUALITY_GOOD = 4
The Location was calculated with a good GPS fix. A 3-D GPS fix is available, with good-to-excellent HDOP.
Since:
1.0.0

Are you using the defined names for this? It's much easier than recalling if 2 or 3 is ok! (Position.QUALITY_POOR means more than 2 to me!)

Alan.raceQs over 7 years ago

OK, I see it now.
Still coming to grips with the documentation conventions.
Thanks.