GPS fix bug on Fenix 7 and some other newer models

If the Position.hasConfigurationSupport() method is available, you should use that to detect available constellation sets.

MobileDriveway said:

I'm using the code provided by Travis.ConnectIQ, so they should either fix the code or firmware.

The code snippet I provided stopped trying configurations as soon as one that worked was found. I would not expect you would have problems if you were using that code. From the sound of it, you are not stopping once you have a usable configuration, which results in the GPS subsystem being started and stopped asynchronously multiple times. That sounds like a bug. Again, you can avoid it with hasConfigurationSupport, but only on devices that have firmware support for that method.

That said, this problem has probably existed since the GPS module was introduced. It has just been exacerbated by the addition of the various constellation options without giving users a way to safely check availability of the constellations at runtime until now.

Thanks Travis.ConnectIQ. There are still a few issues with your suggestion:

• There is no guarantee that devices that don't support hasConfigurationSupport will not have the same issue
• The issue comes up even if a user quickly cycles through available GPS modes (by pressing a button for example), so some kind of delay is still A MUST.
• In general, there is no indication on whether the Start GPS command was accepted - it just quetly does nothing. The issue is not documented in the official documentation either.

Yes, I'm simply pointing out that the code snippet that you say you copied should not exhibit the problems you describe because it stops calling Position.enableLocationEvents() as soon as one call passes.

MobileDriveway said:

There is no guarantee that devices that don't support hasConfigurationSupport will not have the same issue

Absolutely. This issue certainly exists for all devices with and without Position.hasConfigurationSupport(). I'm simply suggesting that if you have access to that method on a device, you should use it. It was created for this exact reason... we need to provide a way for developers to determine what GPS configurations are available without having to run an operation that may result in the system starting or stopping GPS.

MobileDriveway said:

The issue comes up even if a user quickly cycles through available GPS modes (by pressing a button for example), so some kind of delay is still A MUST.

Yes. You should not need to invent your own delay for the case where you have just enabled GPS and you are trying another configuration. If no exception was thrown by the call, you should wait until the position callback has been invoked at least once before you try and change the GPS state again. I can easily add a documentation ticket to ensure this is communicated to developers.

Unfortunately, if you are disabling GPS we don't really have a mechanism to tell you when the asynchronous operation completed. You might need to use a timer to do a delay in that case.

MobileDriveway said:

In general, there is no indication on whether the Start GPS command was accepted - it just quetly does nothing. The issue is not documented in the official documentation either.

The GPS system that we call to is asynchronous, and doesn't provide any error if the call fails, so we have nothing to report to you at that time. The system should be detecting errors before we call into the GPS system. If you run into a case where you make a call to enable GPS and it doesn't throw or start the GPS, that is clearly a bug and should be reported as such.

I can file a bug for the issue you describe above, but I think it may be helpful to see some code to reproduce. It sounds like you are saying that if I make many calls to Position.enableLocationEvents() to enable/disable GPS the GPS isn't always put into the state that was last requested. i.e., something like this??

hidden var _timer as Timer or Null;
hidden var _expect_gps_state as Boolean = false;
hidden var _actual_gps_state as Boolean = false;

function onSelect() as Boolean {

    // stop paying attention to GPS as the state has changed again
    if (_timer != null) {
        _timer.stop();
        _timer = null;
    }

    // change the gps state
    if (_expect_gps_state) {
        Position.enableLocationEvents(Position.LOCATION_DISABLE, null);
        _expect_gps_state = false;
    } else {
        Position.enableLocationEvents(Position.LOCATION_ONE_SHOT, self.method(:onPosition));
        _expect_gps_state = true;
    }

    _actual_gps_state = false;

    // check to see if we got a position callback in a few seconds
    _timer = new Timer.Timer();
    _timer.start(self.method(:onCheckGpsState), 5000, false);
}

function onPosition(posn as Position.Info) as Void {
    _actual_gps_state = true;
}

function onCheckGpsState() as Void {
    if (_actual_gps_state != _expected_gps_state) {
        System.println("error!");
    }
}

If you call Position.enableLocationEvents a few times in a row with different configurations or even old fashioned GPS ONLY call (regardles of whether you call Position.enableLocationEvents(Position.LOCATION_DISABLE) in between), it results in the issue above. Specifically, the issue is that GPS is just disabled or behaves identical to being disabled - :onPosition is never called. If you still have questions, I can do provide a short test code later when I have time.

It can't be reproduced in the simulator - only on the real device like Fenix 7.