derived.csv files contains two times - one is current time in milliseconds, other one is nanoseconds when the signal was sent.
\nThere are first line from data\\train\\2020-05-14-US-MTV-1\\Pixel4\\Pixel4_derived.csv
\nmillisSinceGpsEpoch receivedSvTimeInGpsNanos
\n1273529464442 1273529463363060000
\nor 1273529464.442
\nand 1273529463.36306
\nin seconds
\nSo the signal traveled more then one second
\nBut that means distance more than 300 000 000 meters though aproximate psevdorange is just 23 794 983.73 (based on same line)
\nHave anybody understanding, how can it be?
Thank you
\nIlya
derived.csv files contains two times - one is current time in milliseconds, other one is nanoseconds when the signal was sent.
\nThere are first line from data\\train\\2020-05-14-US-MTV-1\\Pixel4\\Pixel4_derived.csv
\nmillisSinceGpsEpoch receivedSvTimeInGpsNanos
\n1273529464442 1273529463363060000
\nor 1273529464.442
\nand 1273529463.36306
\nin seconds
\nSo the signal traveled more then one second
\nBut that means distance more than 300 000 000 meters though aproximate psevdorange is just 23 794 983.73 (based on same line)
\nHave anybody understanding, how can it be?
Thank you
\nIlya
Looks like there is a leap second
\n1273529464.442
\nminus
\n1273529463.36306
1.07894
\n0.07894 - is almost correct delta for signal traveling time
\n0.07894 * 299 792 458 = 23665587.85
\nwith rawPrM 23794983.73
It is much more accurate, but there is still 100km delta
\nAnd I still have not idea of that delta
Hi IIya,
\n The time difference not only includes the signal travel time, but also the clock bias between the phone and the satellite. The travel time is usually 70-80ms, and the rest is the receiver clock bias that needs to be estimated. This is an interesting application of GNSS by the way, because solving this clock bias can synchronize your receiver's clock with accurate global GNSS time. \nHope this helps,
\nMichael
Yes, but pseudorange (not the geometric range) should include this time bias as error. Pseudorange is just a time difference multiplied to the speed of lights, nothing more. But time difference from csv file is not match pseudorange from same file. It would be nice to know, how you calculate rawPrM column, because it is not match C1C mesuarment from rinex files too.
", "rawMarkdown": "Yes, but pseudorange (not the geometric range) should include this time bias as error. Pseudorange is just a time difference multiplied to the speed of lights, nothing more. But time difference from csv file is not match pseudorange from same file. It would be nice to know, how you calculate rawPrM column, because it is not match C1C mesuarment from rinex files too.", "votes": null }, { "id": "1325264", "postDate": "05/27/2021 15:51:38", "content": "I think that millisSinceGpsEpoch is based on the phone time (receiver time), and receivedSvTimeInGpsNanos is based on gps time (satellite) time - so the receiver clock is off by nearly a second there, and that clock bias needs to be solved for (or will be solved for by solving for distance at the same time)
\nSo in this case, the phone time is nearly a second different than the satellite time
", "rawMarkdown": "I think that millisSinceGpsEpoch is based on the phone time (receiver time), and receivedSvTimeInGpsNanos is based on gps time (satellite) time - so the receiver clock is off by nearly a second there, and that clock bias needs to be solved for (or will be solved for by solving for distance at the same time)\n\nSo in this case, the phone time is nearly a second different than the satellite time", "votes": null }, { "id": "1325324", "postDate": "05/27/2021 16:43:04", "content": "More then second differense for modern smartphone looks strange.
\nEven if it so, I stil can not undertsand how calculated rawPrM
There is a differense for first train track for GPS L1 satalites
\n", "rawMarkdown": "More then second differense for modern smartphone looks strange.\nEven if it so, I stil can not undertsand how calculated rawPrM \n\nThere is a differense for first train track for GPS L1 satalites\n\n![ https://cloclo51.cloud.mail.ru/weblink/view/UGQX/cYL3sZr87?etag=092D2587A31B95FF68B0F626D66EE9BDAA406438 ]", "votes": null }, { "id": "1354562", "postDate": "06/17/2021 16:57:49", "content": "Hi llya, the Tip 1 at https://www.kaggle.com/gymf123/tips-notes-from-the-competition-hosts may be relevant to your doubt here.
", "rawMarkdown": "Hi llya, the Tip 1 at https://www.kaggle.com/gymf123/tips-notes-from-the-competition-hosts may be relevant to your doubt here.", "votes": null }, { "id": "1354760", "postDate": "06/17/2021 20:46:09", "content": "Thank you!
", "rawMarkdown": "Thank you!", "votes": null } ], "comments": [ { "id": 1322198, "author_name": "ielenik", "author_url": "", "post_date": "05/25/2021 09:07:21", "content": "Looks like there is a leap second
\n1273529464.442
\nminus
\n1273529463.36306
1.07894
\n0.07894 - is almost correct delta for signal traveling time
\n0.07894 * 299 792 458 = 23665587.85
\nwith rawPrM 23794983.73
It is much more accurate, but there is still 100km delta
\nAnd I still have not idea of that delta
Hi IIya,
\n The time difference not only includes the signal travel time, but also the clock bias between the phone and the satellite. The travel time is usually 70-80ms, and the rest is the receiver clock bias that needs to be estimated. This is an interesting application of GNSS by the way, because solving this clock bias can synchronize your receiver's clock with accurate global GNSS time. \nHope this helps,
\nMichael
Yes, but pseudorange (not the geometric range) should include this time bias as error. Pseudorange is just a time difference multiplied to the speed of lights, nothing more. But time difference from csv file is not match pseudorange from same file. It would be nice to know, how you calculate rawPrM column, because it is not match C1C mesuarment from rinex files too.
", "votes": null, "replies": [] }, { "id": 1325264, "author_name": "chris62", "author_url": "", "post_date": "05/27/2021 15:51:38", "content": "I think that millisSinceGpsEpoch is based on the phone time (receiver time), and receivedSvTimeInGpsNanos is based on gps time (satellite) time - so the receiver clock is off by nearly a second there, and that clock bias needs to be solved for (or will be solved for by solving for distance at the same time)
\nSo in this case, the phone time is nearly a second different than the satellite time
", "votes": null, "replies": [] }, { "id": 1325324, "author_name": "ielenik", "author_url": "", "post_date": "05/27/2021 16:43:04", "content": "More then second differense for modern smartphone looks strange.
\nEven if it so, I stil can not undertsand how calculated rawPrM
There is a differense for first train track for GPS L1 satalites
\n", "votes": null, "replies": [] } ] }, { "id": 1354562, "author_name": "gymf123", "author_url": "", "post_date": "06/17/2021 16:57:49", "content": "Hi llya, the Tip 1 at https://www.kaggle.com/gymf123/tips-notes-from-the-competition-hosts may be relevant to your doubt here.
", "votes": null, "replies": [ { "id": 1354760, "author_name": "ielenik", "author_url": "", "post_date": "06/17/2021 20:46:09", "content": "Thank you!
", "votes": null, "replies": [] } ] } ], "raw_markdown_by_id": { "1321675": "derived.csv files contains two times - one is current time in milliseconds, other one is nanoseconds when the signal was sent.\nThere are first line from data\\train\\2020-05-14-US-MTV-1\\Pixel4\\Pixel4_derived.csv \nmillisSinceGpsEpoch\treceivedSvTimeInGpsNanos\n1273529464442\t1273529463363060000\nor 1273529464.442\nand 1273529463.36306\nin seconds\nSo the signal traveled more then one second\nBut that means distance more than 300 000 000 meters though aproximate psevdorange is just 23 794 983.73 (based on same line)\nHave anybody understanding, how can it be?\n\nThank you\nIlya", "1322198": "Looks like there is a leap second\n\n\n\n1273529464.442\nminus\n1273529463.36306\n___________________\n1.07894\n\n0.07894 - is almost correct delta for signal traveling time\n0.07894 * 299 792 458 = 23665587.85\nwith rawPrM 23794983.73\n\nIt is much more accurate, but there is still 100km delta\nAnd I still have not idea of that delta", "1325201": "Hi IIya,\n\n The time difference not only includes the signal travel time, but also the clock bias between the phone and the satellite. The travel time is usually 70-80ms, and the rest is the receiver clock bias that needs to be estimated. This is an interesting application of GNSS by the way, because solving this clock bias can synchronize your receiver's clock with accurate global GNSS time. \n\nHope this helps,\nMichael", "1325227": "Yes, but pseudorange (not the geometric range) should include this time bias as error. Pseudorange is just a time difference multiplied to the speed of lights, nothing more. But time difference from csv file is not match pseudorange from same file. It would be nice to know, how you calculate rawPrM column, because it is not match C1C mesuarment from rinex files too.", "1325264": "I think that millisSinceGpsEpoch is based on the phone time (receiver time), and receivedSvTimeInGpsNanos is based on gps time (satellite) time - so the receiver clock is off by nearly a second there, and that clock bias needs to be solved for (or will be solved for by solving for distance at the same time)\n\nSo in this case, the phone time is nearly a second different than the satellite time", "1325324": "More then second differense for modern smartphone looks strange.\nEven if it so, I stil can not undertsand how calculated rawPrM \n\nThere is a differense for first train track for GPS L1 satalites\n\n![ https://cloclo51.cloud.mail.ru/weblink/view/UGQX/cYL3sZr87?etag=092D2587A31B95FF68B0F626D66EE9BDAA406438 ]", "1354562": "Hi llya, the Tip 1 at https://www.kaggle.com/gymf123/tips-notes-from-the-competition-hosts may be relevant to your doubt here.", "1354760": "Thank you!" }, "source": "meta" }