[Top][All Lists]

[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


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)
 .. 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...



reply via email to

[Prev in Thread] Current Thread [Next in Thread]