Hello Richard, >I think the most likely explanations for the 1 second offset are:
>1. somebody has set the time on the PC. >2. the ublox jumps its PPS after acquiring a fix >3. RT scheduling issues on the PC. I am certain on points 1 and 2 but I am unsure about the scheduling on my system. Thank you for pointing out possible explanations for these time jumps. Thanks - Jairaj On Wed, Sep 16, 2020 at 3:21 AM Richard Cochran <richardcoch...@gmail.com> wrote: > On Tue, Sep 15, 2020 at 08:49:13PM +0300, Vladimir Oltean wrote: > > No, I don't think those lines are _causing_ the issue. That is "garbage > > in, garbage out" type of code. It is an approximation written with a > > certain assumption in mind, which clearly does not hold true in this > > case. > > I think the most likely explanations for the 1 second offset are: > > 1. somebody has set the time on the PC. > > 2. the ublox jumps its PPS after acquiring a fix > > 3. RT scheduling issues on the PC. > > I have used a ublox with both "generic" ToD and NMEA. I was able to > get it to work just fine. I don't see any bug in the linuxptp code, > but if you see one, please post a fix with a proper root cause > analysis. > > Having said that, making a real GM does require a certain level of > engineering effort. You will need to invest time and effort into your > custom GM. > > I would start by running the ts2phc program with the --free_running=1 > option and analyze the output time stamps. > > Good luck, > Richard > -- YouTube: *https://youtu.be/Sn2-cZ_Ln9E <https://youtu.be/Sn2-cZ_Ln9E>*
_______________________________________________ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
