[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[gpsd-users] ntpshm_link_activate failing for pty source devices
From: |
David Thornley |
Subject: |
[gpsd-users] ntpshm_link_activate failing for pty source devices |
Date: |
Wed, 16 Aug 2017 05:22:13 +0000 |
Hi Everyone,
I am currently using gpsd through kplex with a uBlox receiver via RS232 (via
USB). I am using kplex as I need to share the raw NMEA stream with other
'systems' that don't talk to gpsd directly.
Our hardware lacks a realtime clock and we were planning to use the built in
GPS for this, however I found that I couldn't get the time synchronisation
working either through SHM or SOCK modes with chrony. I did work with the
serial port directly, but not through kplex.
After looking through the logs I noticed differences between ttyACM4 (serial
port - source_type 3) and ttyGPS2 (kplex pty - source_type 6) : -
gpsd:INFO: opening GPS data source type 3 at '/dev/ttyACM4'
gpsd:INFO: PPS:/dev/ttyACM4 ntpshm_link_activate: 1
vs
gpsd:INFO: opening GPS data source type 6 at '/dev/ttyGPS2'
gpsd:INFO: PPS:/dev/ttyGPS2 ntpshm_link_activate: 0
Digging through the code I noticed the following : -
void ntpshm_link_activate(struct gps_device_t *session)
/* set up ntpshm storage for a session */
{
/* don't talk to NTP when we're running inside the test harness */
if (session->sourcetype == source_pty)
return;
.. snip ..
I figured that this filter condition for source_type == source_pty is the
culprit. I just patched my build (running from openwrt/lede distro) by
commenting out the condition and it looks like SHM and PORT are now working on
the kplex pty port.
Should I submit this patch to the group, or given how trivial it is, would the
core dev's be able to evaluate it and supply a formal fix? I'm not sure if this
will break the "test harness" as mentioned in the comments.
Thank in advance...
Regards,
David.
- [gpsd-users] ntpshm_link_activate failing for pty source devices,
David Thornley <=