Ticket Created
over 3 years ago

WERETECH-10061

Wrong Activity.getActivityInfo().currentLocation on fenix 6 pro

I seems that Activity.getActivityInfo().currentLocation returns a position object with lat/lon coordinates of 0 (zero), instead of returning null.

In watch faces, Activity.getActivityInfo().currentLocation is used to get current or recent GPS position retrieved by GPS fix from last activity.

When GPS fix expired after some time, Activity.getActivityInfo().currentLocation should return null.

But on my fenix 6 pro it seems to return a position object with lat/lon coordinates of 0.

Code used in watch face:

var location;
var locationArray;

location = Activity.getActivityInfo().currentLocation;
if (location != null) {
   locationArray = location.toDegrees();
}
-
On my fenix 6 pro location var is not null and locationArray is [0.000000, 0.000000]
On my forerunner 645 location var is null, which is correct.
Simulator is also correct with fenix 6 (pro).
Makkas-CIQ
Parents
  • over 3 years ago in reply to jim_m_58

    I don't know. But it happened just once and the next call returned the right coordinates despite the fact there was no GPS fix. 

    I don't check for it, because it is not documented how to use it. Especially when QUALITY_NOT_AVAILABLE and when QUALITY_LAST_KNOWN is returned. When I tried to reverse-engineer it by debugging QUALITY_NOT_AVAILABLE was correct location was returned. 

    I have a hypotheses that the QUALITY_NOT_AVAILABLE might be returned when the location is acquired through the phone rather than a GPS fix. 

    But I really don't have clue how Garmin guys did this and I am not aware of any documentation of it. 

Comment
  • over 3 years ago in reply to jim_m_58

    I don't know. But it happened just once and the next call returned the right coordinates despite the fact there was no GPS fix. 

    I don't check for it, because it is not documented how to use it. Especially when QUALITY_NOT_AVAILABLE and when QUALITY_LAST_KNOWN is returned. When I tried to reverse-engineer it by debugging QUALITY_NOT_AVAILABLE was correct location was returned. 

    I have a hypotheses that the QUALITY_NOT_AVAILABLE might be returned when the location is acquired through the phone rather than a GPS fix. 

    But I really don't have clue how Garmin guys did this and I am not aware of any documentation of it. 

Children
  • over 3 years ago in reply to jim_m_58

    Yep. I wanted to point out the bugs that others might expect.

    To summarize known bugs: unknown position might be represented as any of: null, [0,0], [180,180] and who knows what else, so testing the range as you suggest might be a good idea. According to the report above, it can happen even with QUALITY_LAST_KNOWN. 

    It would be also great, if Garmin developers could fix it and document how the accuracy is set when the Toybox.Position is set from the phone rather than activity (if it really works like that as it seems). 

    End of report:) 

  • over 3 years ago in reply to myneur

    Notice the ">=" for Position.QUALITY_POOR.  It's not a ">".

    what you're seeming is simple to handle.  If you get a location with an accuracy less than that, or with a glaring issue (lat>90) don't use it, but have your last good location saved in Application.Storage.

    If you get something good, save it to Application.Storage.

    Then for sunrise/set, use what's in application storage.

    I do this all the time for things like sunrise/set and weather data.

  • over 3 years ago in reply to jim_m_58

    It could work when you want to know what is the current accuracy, but not if you need the nearest position approximation available. (e. g. for sunrise/sunset position or weather forecast). 

    In your proposal the watch wouldn't get the position: 
    a) when it was acquired recently, but not updated ever since
    b) when the guy moved back from an activity that was 100 kms away back to home and his position was updated by a phone location, not a GPS activity again. 

    According to my observation it seems that the Toybox.Position.Info.position returns a position even in these situation, although with [0,0] and [180,180] bugs. 

    Testing for Position.QUALITY_POOR would mean user won't get a sunrise/sunset position and weather forecast even when an approximate position is available. 

  • over 3 years ago in reply to myneur

    This is why accuracy/quality is available.

    A simple test if the location is really available, like

    if(info.accuracy>=Position.QUALITY_POOR) {

    The meanings are documented here: developer.garmin.com/.../Position.html