In this competition our time is millisSinceGpsEpoch, whilst the raw data time is in utcTimeMillis.
The UTC time used is the Unix time, which started on the 1 January 1970, meanwhile GPS time started on the 6 January 1980. So, to convert from UTC to GPS:
\n\n\n\n
GPS(ms) = UTC(ms) - 315964800000
However, nothing is ever that easy, and we will have to watch out for the leap seconds, as each satellite navigation system treats them in their own way; some take them into account, others do not, and it seems that our phones frequently switch between satellite constellations (ConstellationType).
See also: GPS Time Conversion Algorithm (PHP code from LIGO)
\nAll the best,
\ncarl
In this competition our time is millisSinceGpsEpoch, whilst the raw data time is in utcTimeMillis.
The UTC time used is the Unix time, which started on the 1 January 1970, meanwhile GPS time started on the 6 January 1980. So, to convert from UTC to GPS:
\n\n\n\n
GPS(ms) = UTC(ms) - 315964800000
However, nothing is ever that easy, and we will have to watch out for the leap seconds, as each satellite navigation system treats them in their own way; some take them into account, others do not, and it seems that our phones frequently switch between satellite constellations (ConstellationType).
See also: GPS Time Conversion Algorithm (PHP code from LIGO)
\nAll the best,
\ncarl
Hello, @carlmcbrideellis !
\nThanks a lot! This was helpfull
Just to add some info to your post:
\nLeap seconds is 18 or 19 based on sattelite (so add 18000 or 19000 to formula)
But basically logs data seems to match gt_csv from the start, so if someone just need merging to baseline, this should works for pair collection-phone:
\n(GPS_time_column - start_Baseline_time + 500) // 1000
And then aggregate and merge from start
", "rawMarkdown": "Hello, @carlmcbrideellis !\nThanks a lot! This was helpfull\n\nJust to add some info to your post:\nLeap seconds is 18 or 19 based on sattelite (so add 18000 or 19000 to formula)\n\nBut basically logs data seems to match gt_csv from the start, so if someone just need merging to baseline, this should works for pair collection-phone:\n\n`(GPS_time_column - start_Baseline_time + 500) // 1000`\n\nAnd then aggregate and merge from start", "votes": null }, { "id": "1336645", "postDate": "06/05/2021 05:34:32", "content": "@sivtsovdanil shouldn't we just use 18, as the leap seconds figure hasn't changed since 2016? (ref. https://endruntechnologies.com/support/leap-seconds)
", "rawMarkdown": "sivtsovdanil shouldn't we just use 18, as the leap seconds figure hasn't changed since 2016? (ref. https://endruntechnologies.com/support/leap-seconds)", "votes": null }, { "id": "1338561", "postDate": "06/06/2021 14:47:32", "content": "Hello, @jh8102 !
\nI also found number 18 when tried to search.
\nBut then I tried to merge data on time columns and find out that GPS and UTC time columns ranges are equal, but for some ranges bias is 18 and for other 19.
It can also be due to shift in data collection start/end. I will try to check it later, but now I believe it is due to different leap seconds
", "rawMarkdown": "Hello, @jh8102 !\n\nI also found number 18 when tried to search. \nBut then I tried to merge data on time columns and find out that GPS and UTC time columns ranges are equal, but for some ranges bias is 18 and for other 19. \n\nIt can also be due to shift in data collection start/end. I will try to check it later, but now I believe it is due to different leap seconds", "votes": null }, { "id": "1374143", "postDate": "07/03/2021 04:09:22", "content": "thank you your advice. I cound't converted. very helpfull.
", "rawMarkdown": "thank you your advice. I cound't converted. very helpfull.", "votes": null }, { "id": "1401346", "postDate": "07/27/2021 08:39:46", "content": "Thank you! I've been looking for for a long time
", "rawMarkdown": "Thank you! I've been looking for for a long time", "votes": null } ], "comments": [ { "id": 1327595, "author_name": "sivtsovdanil", "author_url": "", "post_date": "05/29/2021 12:52:51", "content": "Hello, @carlmcbrideellis !
\nThanks a lot! This was helpfull
Just to add some info to your post:
\nLeap seconds is 18 or 19 based on sattelite (so add 18000 or 19000 to formula)
But basically logs data seems to match gt_csv from the start, so if someone just need merging to baseline, this should works for pair collection-phone:
\n(GPS_time_column - start_Baseline_time + 500) // 1000
And then aggregate and merge from start
", "votes": null, "replies": [] }, { "id": 1336645, "author_name": "jh8102", "author_url": "", "post_date": "06/05/2021 05:34:32", "content": "@sivtsovdanil shouldn't we just use 18, as the leap seconds figure hasn't changed since 2016? (ref. https://endruntechnologies.com/support/leap-seconds)
", "votes": null, "replies": [ { "id": 1338561, "author_name": "sivtsovdanil", "author_url": "", "post_date": "06/06/2021 14:47:32", "content": "Hello, @jh8102 !
\nI also found number 18 when tried to search.
\nBut then I tried to merge data on time columns and find out that GPS and UTC time columns ranges are equal, but for some ranges bias is 18 and for other 19.
It can also be due to shift in data collection start/end. I will try to check it later, but now I believe it is due to different leap seconds
", "votes": null, "replies": [] } ] }, { "id": 1374143, "author_name": "tensorchoko", "author_url": "", "post_date": "07/03/2021 04:09:22", "content": "thank you your advice. I cound't converted. very helpfull.
", "votes": null, "replies": [] }, { "id": 1401346, "author_name": "taiyofuckyou", "author_url": "", "post_date": "07/27/2021 08:39:46", "content": "Thank you! I've been looking for for a long time
", "votes": null, "replies": [] } ], "raw_markdown_by_id": { "1308393": "In this competition our time is `millisSinceGpsEpoch`, whilst the raw data time is in `utcTimeMillis`.\n\nThe UTC time used is the [Unix time](https://en.wikipedia.org/wiki/Unix_time), which started on the 1 January 1970, meanwhile GPS time started on the 6 January 1980. So, to convert from UTC to GPS:\n\n> `GPS(ms) = UTC(ms) - 315964800000`\n\nHowever, nothing is ever that easy, and we will have to watch out for the [leap seconds](https://en.wikipedia.org/wiki/Leap_second), as each satellite navigation system treats them in their own way; some take them into account, others do not, and it seems that our phones frequently switch between satellite constellations (`ConstellationType`).\n\nSee also: [GPS Time Conversion Algorithm](https://www.andrews.edu/~tzs/timeconv/timealgorithm.html) (PHP code from LIGO)\n\nAll the best,\ncarl", "1327595": "Hello, @carlmcbrideellis !\nThanks a lot! This was helpfull\n\nJust to add some info to your post:\nLeap seconds is 18 or 19 based on sattelite (so add 18000 or 19000 to formula)\n\nBut basically logs data seems to match gt_csv from the start, so if someone just need merging to baseline, this should works for pair collection-phone:\n\n`(GPS_time_column - start_Baseline_time + 500) // 1000`\n\nAnd then aggregate and merge from start", "1336645": "sivtsovdanil shouldn't we just use 18, as the leap seconds figure hasn't changed since 2016? (ref. https://endruntechnologies.com/support/leap-seconds)", "1338561": "Hello, @jh8102 !\n\nI also found number 18 when tried to search. \nBut then I tried to merge data on time columns and find out that GPS and UTC time columns ranges are equal, but for some ranges bias is 18 and for other 19. \n\nIt can also be due to shift in data collection start/end. I will try to check it later, but now I believe it is due to different leap seconds", "1374143": "thank you your advice. I cound't converted. very helpfull.", "1401346": "Thank you! I've been looking for for a long time" }, "source": "meta" }