Re: [Linuxptp-devel] gpsd support in ts2phc

2021-05-14 Thread Lars Munch
On Fri, May 14, 2021 at 7:33 PM Richard Cochran
 wrote:
>
> On Thu, May 13, 2021 at 07:31:27PM +0200, Lars Munch wrote:
> > On Sat, May 8, 2021 at 8:47 PM Richard Cochran  
> > wrote:
> > >
> > > On Sat, May 08, 2021 at 02:57:30PM +0200, Lars Munch wrote:
> > >
> > > > 1. Use the time provided by gpsd to ntpshm. This can be implemented 
> > > > without
> > > > dependencies to gpsd.
> > >
> > > Doesn't sound aweful, but not great either.
> >
> > I kind of like the simplicity of this solution. No need for extra
> > daemons to pipe the
> > data from gpsd to ts2phc. The thing I do not like is the polling that
> > it would have to
> > do, but that's only a few times per second. Anything else that I have
> > missed which
> > is awful?
> >
> > Does this mean I should not waste my time implementing this as you can 
> > already
> > now say it will not be accepted?
>
> There are two design questions that need answering.
>
> 1. Will this work reliably?  That is, will the ntpshm (almost) always
>have correct time?  Or will this become a constant source of
>questions on the list to the tune of, "I used linuxptp as a GPS GM
>and it does not work ..."  I do NOT want to become a support
>channel for gpsd.
>
> 2. How can the GM logic determine whether the time in the ntpshm is
>verified to be globally correct or not?
>
> With the present solution using RMC, we have a simple flag (field 2 is
> either "A" or "V") that signals the validity.  It is practically
> impossible to determine generically whether the reading from a
> particular GNSS radio is valid.  For this reason we push the
> responsibility to an external program.

Thank you for taking the time to share your thoughts on the subject.
I will write an external program instead as the gpspipe | socat solution
is too flaky.

Regards
Lars


___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel


Re: [Linuxptp-devel] gpsd support in ts2phc

2021-05-14 Thread Richard Cochran
On Thu, May 13, 2021 at 07:31:27PM +0200, Lars Munch wrote:
> On Sat, May 8, 2021 at 8:47 PM Richard Cochran  
> wrote:
> >
> > On Sat, May 08, 2021 at 02:57:30PM +0200, Lars Munch wrote:
> >
> > > 1. Use the time provided by gpsd to ntpshm. This can be implemented 
> > > without
> > > dependencies to gpsd.
> >
> > Doesn't sound aweful, but not great either.
> 
> I kind of like the simplicity of this solution. No need for extra
> daemons to pipe the
> data from gpsd to ts2phc. The thing I do not like is the polling that
> it would have to
> do, but that's only a few times per second. Anything else that I have
> missed which
> is awful?
> 
> Does this mean I should not waste my time implementing this as you can already
> now say it will not be accepted?

There are two design questions that need answering.

1. Will this work reliably?  That is, will the ntpshm (almost) always
   have correct time?  Or will this become a constant source of
   questions on the list to the tune of, "I used linuxptp as a GPS GM
   and it does not work ..."  I do NOT want to become a support
   channel for gpsd.

2. How can the GM logic determine whether the time in the ntpshm is
   verified to be globally correct or not?

With the present solution using RMC, we have a simple flag (field 2 is
either "A" or "V") that signals the validity.  It is practically
impossible to determine generically whether the reading from a
particular GNSS radio is valid.  For this reason we push the
responsibility to an external program.

Thanks,
Richard


___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel


Re: [Linuxptp-devel] gpsd support in ts2phc

2021-05-13 Thread Lars Munch
On Sat, May 8, 2021 at 8:47 PM Richard Cochran  wrote:
>
> On Sat, May 08, 2021 at 02:57:30PM +0200, Lars Munch wrote:
>
> > 1. Use the time provided by gpsd to ntpshm. This can be implemented without
> > dependencies to gpsd.
>
> Doesn't sound aweful, but not great either.

I kind of like the simplicity of this solution. No need for extra
daemons to pipe the
data from gpsd to ts2phc. The thing I do not like is the polling that
it would have to
do, but that's only a few times per second. Anything else that I have
missed which
is awful?

Does this mean I should not waste my time implementing this as you can already
now say it will not be accepted?

> > I might also be able to use gpspipe and socat to get the NMEA sentences
> > from gpsd to ts2phc, but that is not very elegant.
>
> This is best approach IMO.  You can wrap gpspipe|socat in a systemd
> job to get automatic restarting and logging and so on.  If the
> gpspipe|socat combination is too flaky to keep running, then writing a
> little C or python program to read the UART and publish two sockets is
> pretty easy.

For the email archives; the following works as long as you do no
restart anything:
$ gpspipe -r | socat -u STDIN TCP4-LISTEN:9876,reuseaddr,fork,bind=127.0.0.1
and then configured ts2phc.nmea_remote_host, ts2phc.nmea_remote_port.

Thanks
Lars Munch


___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel


Re: [Linuxptp-devel] gpsd support in ts2phc

2021-05-08 Thread Richard Cochran
On Sat, May 08, 2021 at 02:57:30PM +0200, Lars Munch wrote:

> 1. Use the time provided by gpsd to ntpshm. This can be implemented without
> dependencies to gpsd.

Doesn't sound aweful, but not great either.

> 2. Use libgpsd to get the time, but that adds a dependency to gpsd

No, I won't use that library in linuxptp.  Before implementing the
current solution in nmea.c, I tried really hard to use gpsd, hoping
that it would "just work" because of the multiple different nmea and
binary protocols that it has.  That seemed like a compelling feature.
However, I couldn't get it to work with either a commodity gps or a
high end, survey quality gps.
 
> I might also be able to use gpspipe and socat to get the NMEA sentences
> from gpsd to ts2phc, but that is not very elegant.

This is best approach IMO.  You can wrap gpspipe|socat in a systemd
job to get automatic restarting and logging and so on.  If the
gpspipe|socat combination is too flaky to keep running, then writing a
little C or python program to read the UART and publish two sockets is
pretty easy.

Thanks,
Richard


___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel


Re: [Linuxptp-devel] gpsd support in ts2phc

2021-05-08 Thread Richard Hill
My experiences of gpsd are not good.  It didn’t (three years ago) have recovery 
in case it got out of sync with NMEA messages. When it stopped 

working, you had to kill it and restart

 

From: Lars Munch [mailto:l...@segv.dk] 
Sent: Samstag, 8. Mai 2021 13:58
To: linuxptp-devel@lists.sourceforge.net
Subject: [Linuxptp-devel] gpsd support in ts2phc

 

Hi

 

I have been using ts2phc directly to my GPS using serial connection to get NMEA 
sentences. This is working fine but then I cannot  get status from the GPS 
while ts2phc is running. Therefore I have been pondering on how to add gpsd 
support to ts2phc. There are several options, maybe more:

 

1. Use the time provided by gpsd to ntpshm. This can be implemented without 
dependencies to gpsd.

2. Use libgpsd to get the time, but that adds a dependency to gpsd

 

I might also be able to use gpspipe and socat to get the NMEA sentences from 
gpsd to ts2phc, but that is not very elegant.

 

Any suggestions?

 

Thanks

Lars

 

___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel


[Linuxptp-devel] gpsd support in ts2phc

2021-05-08 Thread Lars Munch
Hi

I have been using ts2phc directly to my GPS using serial connection to get
NMEA sentences. This is working fine but then I cannot  get status from the
GPS while ts2phc is running. Therefore I have been pondering on how to add
gpsd support to ts2phc. There are several options, maybe more:

1. Use the time provided by gpsd to ntpshm. This can be implemented without
dependencies to gpsd.
2. Use libgpsd to get the time, but that adds a dependency to gpsd

I might also be able to use gpspipe and socat to get the NMEA sentences
from gpsd to ts2phc, but that is not very elegant.

Any suggestions?

Thanks
Lars
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel