Fenix 3 HR GPS Timestap WHEN issue

Former Member
Former Member
Good evening,

I am retrieving data from my last GPS fix with the position class. The coordinates seem to be correct, however the UTC timestamp from "when" is incorrect.

I'm grabbing the "when" value and then getting day/month/year hour:minute:second with the gregorian class. The gregorian.info is supplied with the moment from the GPS "when" data. I'm getting a time of 21:14:07 and a date of 1/18/2038. Has anyone else had luck with this information or is it something I am calling wrong?

Thanks!
  • The unix timestamp for 2016-01-18T21:14:07 is 2147462047, which is exactly 21600 seconds (6 hours) off of the maximum representable timestamp (assuming a 32-bit signed integer representation). I'm guessing that you are actually in a timezone that is six hours west of UTC time (US Central Time?). If you print the value of the info.when as hex (Sys.println(info.when.format("%08X")) would do it), I'm betting that you'll see 0x7FFFFFF.

    If you do see that value, it seems that the fenix3 firmware is returning an invalid value for some reason. I'm not sure why it would do this, but it does seem like it would be a bug if the device failed to capture the timestamp of the last GPS fix (considering that you need to have a pretty accurate representation of the time to get a GPS fix).

    Travis
  • I assume you doing something like a
    Position.enableLocationEvents(Position.LOCATION_ONE_SHOT, method(:onPosition));

    or a
    Position.enableLocationEvents(Position.LOCATION_CONTINUOUS, method(:onPosition));


    In both cases, when "onPostion()" is called, "when" should always be "now", as they are live readings. By checking the accuracy in onPostion(), you can see if it's "QUALITY_LAST_KNOWN". It could be that "when" is only valid in that case (I've never tested it myself), otherwise, as Travis noted, it could just be "the max".

    BTW, there's a bug on the va-hr right now with "ONE_SHOT". See: https://forums.garmin.com/showthread.php?365217-LOCATION_ONE_SHOT-always-QUALITY_LAST_KNOWN

    Maybe a few details on what you're trying to do could help in figuring out a workaround (workarounds are discussed in the thread I linked to for that issue)
  • Yes, as Jim pointed out, I'm assuming that when is set to the current time or the time of the last good GPS fix. It is possible that the when value is only to be used if accuracy.equals(Position.QUALITY_LAST_KNOWN), but it isn't currently documented to behave that way and that just doesn't seem right to me.

    Travis