• Replies 8 replies
  • Subscribers 18 subscribers
  • Views 1011 views
  • Users 0 members are here
Options
Related

Time stamp for accelerometer data are all the same

8649264
over 1 year ago

Hi everyone,

I am making an app that saves accelerometer data at 25Hz for a period of 4 seconds, but I don't understand why the time stamp (the highlighted number) for each set of accelerometer data is the same.

Is the number displayed in UTC not representing the time stamp for when each data cycle was saved? If yes, how do I correct my issue to get the correct time? if not, where can I find the time stamp for when each cycle of data was saved?

Top Replies

All Replies

  • over 1 year ago

    Looks like the time is in seconds, and based on 25hz. I wouldn't expect them to change in 1/25th of a second

    Normal unix time stamps are the number of seconds since midnight, Jan 1, 1970 UTC.  Internally, Garmin uses "Garmin Time" which is similar, but based on midnight Jan 1, 1990 UTC. (when Gamin started) so about 20 years different.  If I use a unix to human readable converter, the number you show relates to Late May 2003, so about 20 years.

  • over 1 year ago in reply to jim_m_58
    jim_m_58 said:
    Internally, Garmin uses "Garmin Time" which is similar, but based on midnight Jan 1, 1990 UTC

    According to Garmin itself, the Garmin/FIT epoch is defined to start on midnight (*) December 31, 1989 UTC.

    (*) From context, here "midnight" refers to the beginning of the day, not the end.

    https://developer.garmin.com/fit/cookbook/datetime/

    The FIT Profile defines the date_time type as an uint32 that represents the number of seconds since midnight on December 31, 1989 UTC*. This date is often referred to as the FIT Epoch.

    ...

    Most programming languages provide a way to create dates based on the Unix Epoch, which is 1970–01–01T00:00:00Z.

    To use FIT Epoch values with any of these methods, the value needs to be offset by either 631065600 seconds or 631065600000 milliseconds, depending on the method.

    It's easy to confirm that 1970–01–01T00:00:00Z + 631065600 seconds  = 1989–12–31T00:00:00Z

  • over 1 year ago in reply to jim_m_58

    Thank you for letting me know about Garmin's unique Unix time stamp - solved another issue I had.

    Unforchantly, the screenshot shown was from a 4hr activity, and every timestamp for accelerometer data is the same :( 

    I guess my question now has changed, in the community's opinion, is this a bug for how long the activity was? and how reliable is the timestamp for any activity?

  • over 1 year ago in reply to FlowState

    Thank you so much for your help!! For readers of this forum, here is my C# code that converts the timestamp to either/both a short date or time (CST with or without daylight savings):

        public static string epoch2DateString(string utcString)
        {
            int utcInt = int.Parse(utcString);
            utcInt = utcInt + (20*31556926); //garmin time is 20 years behind
            return new DateTime(1970, 1, 1, 0, 0, 0, DateTimeKind.Utc).AddSeconds(utcInt).ToShortDateString();
        }
        static private string epoch2Timestring(string epoch, string milliseconds)
        {
            int utcIntS = int.Parse(epoch);
            utcIntS = utcIntS - 3600;
            int millisecondString = int.Parse(milliseconds);
            TimeZoneInfo crtTimeZone = TimeZoneInfo.FindSystemTimeZoneById("Central Standard Time");
            DateTime utcDateTime = new DateTime(1970, 1, 1, 0, 0, 0, DateTimeKind.Utc).AddSeconds(utcIntS).AddMilliseconds(millisecondString);
            DateTime crtDateTime = TimeZoneInfo.ConvertTimeFromUtc(utcDateTime, crtTimeZone);


            if (crtTimeZone.IsDaylightSavingTime(crtDateTime))
            {
                TimeZoneInfo.AdjustmentRule[] adjustmentRules = crtTimeZone.GetAdjustmentRules();
                TimeSpan dstOffset = TimeSpan.Zero;


                foreach (var rule in adjustmentRules)
                {
                    if (rule.DateStart <= crtDateTime && rule.DateEnd >= crtDateTime)
                    {
                        dstOffset = rule.DaylightDelta;
                        break;
                    }
                }


                crtDateTime = crtDateTime.Add(dstOffset);
            }


            return crtDateTime.ToString("hh:mm:ss.fff tt");
        }


        static public string ConvertEpochToFullDateTime(string fieldTimeStampUTC, string possibleMS)
        {
            string fullTime = epoch2DateString(fieldTimeStampUTC) + " " + epoch2Timestring(fieldTimeStampUTC, possibleMS);
            return fullTime;
        }
  • over 1 year ago in reply to 8649264

    No worries, but as I mentioned, the offset is neither exactly "20 years" (whatever that means *), nor is it the length of time between midnight 1970-01-01 and midnight 1990-01-01 (as incorrectly stated above.)

    (* Is a "year" 365 days or 365.25? Time units like years and months aren't well-defined in absolute terms as opposed to taking the difference of two dates.)

    The offset is literally the length of time between midnight 1970-01-01 (Unix epoch) and midnight 1989-12-31 (Garmin epoch). As per Garmin, the offset is exactly 631065600 seconds (which is not the same as 20*31556926).

    Again, you can easily verify this by:

    1) Opening a Unix timestamp converter site such as: https://www.unixtimestamp.com/

    2) Entering 631065600

    3) Noting that the resulting date and time is December 31, 1989, 00:00:00

  • over 1 year ago in reply to 8649264
    8649264 said:
    Unforchantly, the screenshot shown was from a 4hr activity, and every timestamp for accelerometer data is the same :( 

    Yeah, looking at your screenshot, it seems that the timestamps for all the "normal" records (interleaved with the accel records) are sensible, so it def seems to be a bug. Given that FIT records are written sequentially, you could try to guess the "real" timestamp of an accel record based on the neighboring non-accel records...

  • over 1 year ago in reply to FlowState

    Thank you so much! I'll look into the neighboring times.

  • over 1 year ago in reply to jim_m_58
    jim_m_58 said:
    Looks like the time is in seconds, and based on 25hz. I wouldn't expect them to change in 1/25th of a second

    If you look closely at the screenshot:

    - each accel data record is sandwiched between 2 "normal" activity records whose timestamps are 1 second apart and are both much later than the accel record's timestamp

    - each accel data record has multiple values

    - based on the previous points, no records are being written 25 times per second (is that even possible?). it looks more like each accel data record is written about once per second, with multiple values per record

    e.g. From the top of the screenshot

    accelerometer_data -> 1054052592
    record -> 1054052849
    accelerometer_data -> 1054052592
    ...
    record -> 1054052850
    accelerometer_data -> 1054052592

    1054052849 and 1054052850 are one second apart, and 1054052849 (the first record) is over 4 minutes after 1054052592 (the timestamp on accel data which was written *before* and *after*)