• Replies 4 replies
  • Subscribers 17 subscribers
  • Views 555 views
  • Users 0 members are here
Options
Related

Simulator position sometimes returning 180.000, 180.000

Former Member
Former Member over 9 years ago
Has anyone bumped into this?

The simulator is occasionally giving me a position of 180.000, 180.000 when I give it a .fit file (tried with multiple, verified correct .fit files).

It's giving me a quality of 1 which is QUALITY_LAST_KNOWN - fine but obviously 180/180 is not the last known position...
  • over 9 years ago
    I believe this is working correctly, but I'll have to verify. I know that the simulator will return 180,180 for a start location. I suspect that we're also using that for the last known position rather than returning null.
  • over 4 years ago in reply to Brandon.ConnectIQ

    no it's not working correctly. Still getting this bug in the simulator.
    And because I didn't know it can return [180, 180] even with QUALITY_POOR, it prevented a location to be acquired by user this weekend and I have to do another fix of Garmin developer's QUALITY_POOR work.

  • over 4 years ago in reply to myneur

    What's happening is that's what you see when playing back a fit file in the sim where GPS was lost (in a tunnel for example).  With the sim, the quality doesn't change in that case.  I first saw this years ago when playing back a fit from someone who had gone through a tunnel, and I have code in the app for just such a case with the sim.  This only happens in the sim, not on a real device, as there the quality does change.

  • over 2 years ago in reply to Brandon.ConnectIQ

    OK, I know it's been a while, but it's still an issue. When you feed this bogus 180/180 location in something like this:

    l

    		var myLocation = new Position.Location({:latitude=>myloc[0], :longitude=>myloc[1], :format=>:degrees});
		var myMoment = new Time.Moment(someUnixTime);
		var myLocal = Gregorian.localMoment(myLocation, myMoment);
		timeOffsetDays = myLocal.getOffset().toDouble() / 86400.0d;

    it blows up with an uncatchable "unexpected type" exception. The only way around this is to put in code to catch and replace the bogus location with some default before you let it go downstream. It seems like the location should be null instead so the usual test for it can work as designed. As this is now a second test is needed to validate the location.