Set the router clock with a GPS receiver for under $70

[petter5]

A router is not like a drone though...it can't fly nor sail. What good would it be for the position readings? Interesting stuff. Just that I haven't fully understood the picture..

Usage is for a large vessel to have simple GPS wifi stream available for informative putposes ( pc's tablets etc) independent of the main navigation system. Also, a lot of sailors nowadays use a lot of wifi equipment with a router onboard, very handy to be able to plug a GPS directly into the router to make things simple.

 

[kvic]

@petter5 you enlightened my day.

@ASAT I found the trick to compile libcap. Also upon looking closer, we actually don't need libcap for asuswrt as everything is run with root privilege. So I disabled it together with a few other big features such as crypto, pthread and debugging. The binary now looks lean to me.

ntpd VIRT 1280 RES 1184
ntp VIRT 6108 RES 1256

The ntpd performs essential functionalities of keeping router's clock damn accurate (as well as serving time requests from LAN if people want to).

Looking back at the stock ntp... it's a simple/dumb infinite loop but yet uses more resource. Shame on Asus. LOL

Some output from my running ntpd with "remote" edited.

/jffs$ bin/ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*ts0.itc.chk.e  .GPS.            1 u   56   64  377    2.096    1.229   0.213
+xxx.xxx.x.xx   .MRS.            1 u   69   64  276    4.560    0.864   0.625
+yyy.yyy.y.yy   .MRS.            1 u   44   64  377    3.053    0.743   4.080

 

[ASAT]

What's your command line/makefile for building libcap

HACK: build a libcap static library

Maybe someone else could do it a better way, if the full version is needed for ARM router? Libcap is for determining the Linux capabilities? For some reason, the Entware package maintainers deemed it necessary to compile in Libcap support, so I followed their lead.

How I did it (hack method):

cd libcap-2.24
cp -p ~/ipset-dns/libmnl/libtool .  # copy libtool from another project
make clean
make # there will be linker errors
cd libcap  # so link it manually with libtool

/bin/bash ../libtool  --tag=CC  --mode=compile arm-brcm-linux-uclibcgnueabi-gcc -DHAVE_CONFIG_H -I. -I.. -I$HOME/ntpd/libcap-2.24/libcap/include  -D_FILE_OFFSET_BITS=64 -D_REENTRANT -I../include  -Wall -Waggregate-return -Wmissing-declarations  -Wmissing-prototypes -Wshadow -Wstrict-prototypes  -Wformat=2 -pipe -fvisibility=hidden -static -ffunction-sections -fdata-sections -O3 -pipe -march=armv7-a -mtune=cortex-a9 -fno-caller-saves -mfloat-abi=soft -Wall -fPIC -std=gnu99  -MT cap_alloc.lo -MD -MP -MF $depbase.Tpo -c -o cap_alloc.lo cap_alloc.c

/bin/bash ../libtool  --tag=CC  --mode=compile arm-brcm-linux-uclibcgnueabi-gcc -DHAVE_CONFIG_H -I. -I.. -I$HOME/ntpd/libcap-2.24/libcap/include  -D_FILE_OFFSET_BITS=64 -D_REENTRANT -I../include  -Wall -Waggregate-return -Wmissing-declarations  -Wmissing-prototypes -Wshadow -Wstrict-prototypes  -Wformat=2 -pipe -fvisibility=hidden -static -ffunction-sections -fdata-sections -O3 -pipe -march=armv7-a -mtune=cortex-a9 -fno-caller-saves -mfloat-abi=soft -Wall -fPIC -std=gnu99  -MT cap_extint.lo -MD -MP -MF $depbase.Tpo -c -o cap_extint.lo cap_extint.c

/bin/bash ../libtool  --tag=CC  --mode=compile arm-brcm-linux-uclibcgnueabi-gcc -DHAVE_CONFIG_H -I. -I.. -I$HOME/ntpd/libcap-2.24/libcap/include  -D_FILE_OFFSET_BITS=64 -D_REENTRANT -I../include  -Wall -Waggregate-return -Wmissing-declarations  -Wmissing-prototypes -Wshadow -Wstrict-prototypes  -Wformat=2 -pipe -fvisibility=hidden -static -ffunction-sections -fdata-sections -O3 -pipe -march=armv7-a -mtune=cortex-a9 -fno-caller-saves -mfloat-abi=soft -Wall -fPIC -std=gnu99  -MT cap_text.lo -MD -MP -MF $depbase.Tpo -c -o cap_text.lo cap_text.c

/bin/bash ../libtool  --tag=CC  --mode=compile arm-brcm-linux-uclibcgnueabi-gcc -DHAVE_CONFIG_H -I. -I.. -I$HOME/ntpd/libcap-2.24/libcap/include  -D_FILE_OFFSET_BITS=64 -D_REENTRANT -I../include  -Wall -Waggregate-return -Wmissing-declarations  -Wmissing-prototypes -Wshadow -Wstrict-prototypes  -Wformat=2 -pipe -fvisibility=hidden -static -ffunction-sections -fdata-sections -O3 -pipe -march=armv7-a -mtune=cortex-a9 -fno-caller-saves -mfloat-abi=soft -Wall -fPIC -std=gnu99  -MT cap_flag.lo -MD -MP -MF $depbase.Tpo -c -o cap_flag.lo cap_flag.c

/bin/bash ../libtool  --tag=CC  --mode=compile arm-brcm-linux-uclibcgnueabi-gcc -DHAVE_CONFIG_H -I. -I.. -I$HOME/ntpd/libcap-2.24/libcap/include  -D_FILE_OFFSET_BITS=64 -D_REENTRANT -I../include  -Wall -Waggregate-return -Wmissing-declarations  -Wmissing-prototypes -Wshadow -Wstrict-prototypes  -Wformat=2 -pipe -fvisibility=hidden -static -ffunction-sections -fdata-sections -O3 -pipe -march=armv7-a -mtune=cortex-a9 -fno-caller-saves -mfloat-abi=soft -Wall -fPIC -std=gnu99  -MT cap_proc.lo -MD -MP -MF $depbase.Tpo -c -o cap_proc.lo cap_proc.c

/bin/bash ../libtool  --tag=CC  --mode=link arm-brcm-linux-uclibcgnueabi-gcc -Wall -Waggregate-return -Wmissing-declarations  -Wmissing-prototypes -Wshadow -Wstrict-prototypes  -Wformat=2 -pipe -fvisibility=hidden -static -ffunction-sections -fdata-sections -O3 -pipe -march=armv7-a -mtune=cortex-a9 -fno-caller-saves -mfloat-abi=soft -Wall -fPIC -std=gnu99  -Wl,--version-script=./libmnl.map -version-info 1:0:1 -Wl,--gc-sections -o libcap.la cap_alloc.lo cap_extint.lo cap_text.lo cap_flag.lo cap_proc.lo

arm-brcm-linux-uclibcgnueabi-ar cru libcap.a  cap_alloc.o cap_extint.o cap_text.o cap_flag.o cap_proc.o

arm-brcm-linux-uclibcgnueabi-ranlib libcap.a

~/libcap-2.24/Make.Rules

FAKEROOT=$(DESTDIR)

# Autoconf-style prefixes are activated when $(prefix) is defined.
# Otherwise binaries and libraries are installed in /{lib,sbin}/,
# header files in /usr/include/ and documentation in /usr/man/man?/.
# These choices are motivated by the fact that getcap and setcap are
# administrative operations that could be needed to recover a system.

INDENT=| true
PAM_CAP=no
LIBATTR=no
DYNAMIC=no
lib="lib"

ifndef lib
lib=$(shell ldd /usr/bin/ld|egrep "ld-linux|ld.so"|cut -d/ -f2)
endif

ifdef prefix
exec_prefix=$(prefix)
lib_prefix=$(exec_prefix)
inc_prefix=$(lib_prefix)
man_prefix=$(prefix)/share
else
prefix=$(HOME)/usr
exec_prefix=
lib_prefix=$(exec_prefix)
inc_prefix=$(prefix)
man_prefix=$(prefix)/share
endif

# Target directories

MANDIR=$(FAKEROOT)$(man_prefix)/man
SBINDIR=$(FAKEROOT)$(exec_prefix)/sbin
INCDIR=$(FAKEROOT)$(inc_prefix)/include
LIBDIR=$(FAKEROOT)$(lib_prefix)/$(lib)
PKGCONFIGDIR=$(FAKEROOT)$(prefix)/$(lib)/pkgconfig

# common defines for libcap
LIBTITLE=libcap
VERSION=2
MINOR=24
#

# Compilation specifics

KERNEL_HEADERS := $(topdir)/libcap/include/uapi
IPATH += -fPIC -I$(KERNEL_HEADERS) -I$(topdir)/libcap/include

AR=arm-brcm-linux-uclibcgnueabi-ar
CC=arm-brcm-linux-uclibcgnueabi-gcc
GCC=arm-brcm-linux-uclibcgnueabi-gcc
AS=arm-brcm-linux-uclibcgnueabi-gcc -c -static -ffunction-sections -fdata-sections -O3 -pipe -march=armv7-a -mtune=cortex-a9 -fno-caller-saves -mfloat-abi=soft -Wall -fPIC -std=gnu99
LD=arm-brcm-linux-uclibcgnueabi-gcc
NM=arm-brcm-linux-uclibcgnueabi-nm
CXX=arm-brcm-linux-uclibcgnueabi-g++
RANLIB=arm-brcm-linux-uclibcgnueabi-ranlib
STRIP=arm-brcm-linux-uclibcgnueabi-strip
OBJCOPY=arm-brcm-linux-uclibcgnueabi-objcopy
OBJDUMP=arm-brcm-linux-uclibcgnueabi-objdump
SIZE=arm-brcm-linux-uclibcgnueabi-size
CFLAGS=-static -ffunction-sections -fdata-sections -O3 -pipe -march=armv7-a -mtune=cortex-a9 -fno-caller-saves -mfloat-abi=soft -Wall -fPIC -std=gnu99
CXXFLAGS=-static -ffunction-sections -fdata-sections -O3 -pipe -march=armv7-a -mtune=cortex-a9 -fno-caller-saves -mfloat-abi=soft -Wall -fPIC -std=gnu99
LDFLAGS=

#CFLAGS += -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64

BUILD_CC := gcc
BUILD_CFLAGS := $(IPATH)

WARNINGS=-Wall -Wwrite-strings \
        -Wpointer-arith -Wcast-qual -Wcast-align \
        -Wstrict-prototypes -Wmissing-prototypes \
        -Wnested-externs -Winline -Wshadow

#SYSTEM_HEADERS = -I$HOME/asuswrt-merlin/release/src-rt-6.x.4708/toolchains/hndtools-arm-linux-2.6.36-uclibc-4.5.3/arm-brcm-linux-uclibcgnueabi/sysroot/usr/include
INCS=$(topdir)/libcap/include/sys/capability.h
LDFLAGS += -L$(topdir)/libcap
CFLAGS += -Dlinux $(WARNINGS)

# When installing setcap, set its inheritable bit to be able to place
# capabilities on files. It can be used in conjunction with pam_cap
# (associated with su and certain users say) to make it useful for
# specially blessed users. If you wish to drop this install feature,
# use this command when running install
#
#    make RAISE_SETFCAP=no install
#
RAISE_SETFCAP := $(LIBATTR)

# Global cleanup stuff

LOCALCLEAN=rm -f *~ core
DISTCLEAN=@find . \( -name '*.orig' -o -name '*.rej' \) | xargs rm -f

 

[ASAT]

a lot of sailors nowadays use a lot of wifi equipment with a router onboard, very handy to be able to plug a GPS directly into the router to make things simple.

I live on a 45-foot sailboat.

 

[kvic]

HACK: build a libcap static library

My trick. Add below changes in makefiles, then "make". This gets both static and shared libraries cross compiled...albeit without pam & attrib. We actually don't need libcap to run ntpd in asuswrt. I removed this dependency by adding "--disable-linuxcaps" in ntpd build.

~/ntpd/libcap-2.24$ diff Make.Rules Make.Rules.orig
51c51
< CC := arm-brcm-linux-uclibcgnueabi-gcc
---
> CC := gcc
55,56c55,56
< AR := arm-brcm-linux-uclibcgnueabi-ar
< RANLIB := arm-brcm-linux-uclibcgnueabi-ranlib
---
> AR := ar
> RANLIB := ranlib
70c70
< PAM_CAP := no
---
> PAM_CAP := $(shell if [ -f /usr/include/security/pam_modules.h ]; then echo yes ; else echo no ; fi)
73c73
< LIBATTR := no
---
> LIBATTR := yes

~/ntpd/libcap-2.24$ diff libcap/Makefile libcap/Makefile.orig
46c46
<     gcc $(BUILD_CFLAGS) $< -o $@
---
>     $(BUILD_CC) $(BUILD_CFLAGS) $< -o $@

 

[Cake]

A router is not like a drone though...it can't fly nor sail. What good would it be for the position readings? Interesting stuff. Just that I haven't fully understood the picture..

I bet he is a sailor. With other crewman using opencpn and wishing for nmea data over there wifi. (Merchant ships or Fishing)
nevermind my comment everybody beat me to it....

 

[kvic]

My custom built ntpd has been running for over 40hours. It's stable like a rock. So is its memory usage:

PID   USER      PRI  NI  VIRT   RES   SHR  DATA S CPU% MEM%   TIME+  Command
24617 admin      20   0  1280  1184   932   308 S  0.0  0.5  0:00.31 ntpd -c /jffs/etc/ntp.conf

VIRT/RES/DATA never moved a bit. For all the hard work (*cough*) done to keep accurate time, ntpd only consumes 0.31s of CPU time over the 40+ hour of service.

Let's look at the running status and time accuracy ("remote" edited below):

/jffs$ bin/ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*ts0.its.chk.e   .GPS.            1 u  532 1024  357    2.082   -0.646   0.439
+xxx.xxx.xxx.x   .MRS.            1 u  176 1024  313    4.792   -1.158   1.089
+yyy.yyy.yy.yy   .MRS.            1 u  304 1024  375    3.005   -0.710   3.522

The time server with a GPS reference clock (as in "refid" column) is my current primary source (hence with an asterisk) which ntpd monitors and switches dynamically. The other two with MRS* are standby. Hence the "+". All these three are stratum 1 as indicated under "st" column. Stratum 1 time server is the best you could get for free. Go for it if there is one near you..

ntpd starts with a polling period of 64s and gradually prolongs to 1024s (the "poll" column) as it gets confidence. Over the course of 40+ hours, drift increases slightly from 7.3-ish to 7.979 as of this writing:

/jffs$ cat /opt/var/log/ntp/ntp.drift
7.979

A drift value is the current clock deviation observed on my AC56U. It's in the unit of "parts per million". 7.979 PPM translates into 0.69s per day (or 57.5ms every two hour). Is that accurate enough for daily use? I believe so...in fact I'm more interested in the drift value sticking with its words. I dug out my old script from its coffin and took an observation every two hours. Here is the result:

TIMESTAMP DEVIATION (us)
15091720  3630.37
15091722  1164.09
15091800  605.96
15091802  87.96
15091804  1.69
15091806  50.45
15091808  -155.63
15091810  664.57
15091812  48.85
15091814  13.55
15091816  -233.66
15091818  505.59
15091820  -423.84
15091822  -278.00
15091900  422.04
15091902  484.62
15091904  -157.48
15091906  -960.09
15091908  -1109.47
15091910  -630.18
15091912  -403.41

The deviation is in unit of micro-seconds e.g. the first reading 3630.37us = ~3.63ms. When ntpd starts, it polls time servers more frequent and adjust the system clock accordingly. Observant folks might see the slow ramp up (i.e. reduction in deviation) in the first few hours. I believe that's intended since I enforced "always slew adjustment" in my build (with --enable-slew-always) and ntpd need time to slew..through I think.

If we eliminate the first two as outliers, then the worst deviation per two hour is at 15091908 with ~1.11ms. If we treat this as worst drift, then it translates to 13.3ms per day (1.11*12). Bravo! In reality it seems working much better than anticipated.

It's great to have ntpd on my AC56U. I think this 1184KiB memory is well spent. Note that the stock yet dumb ntp consumes more memory than that.

@ASAT Will your setup output a refid of .GPS. or .PPS.?
@Cake You bump into all walks of life here..that's fun.

*for a moment, I wondered... what was .MRS. Wish I could get one of them...maybe a PCI card from ebay?

 

[sfx2000]

NTP is pretty cool - see below, this is off one of my servers in the data center:

We have our own timesource based on GPS/Glonass time as a reference, and we sync the data center to it..

 

[kvic]

@sfx2000, is that a chart from ntp statistics? Two things are puzzling. Why the offset is consistently in one direction? And somehow the graph forms sort of an "eye" pattern. Is there an interesting story behind..?

 

[ASAT]

@ASAT Will your setup output a refid of .GPS. or .PPS.?

I think it will be .PPS only. The PPS line discipline option, I have already enabled in my Asuswrt-Merlin kernel. Still waiting for the pieces to arrive, then we will see. It comes with software to configure the GPS module. I'm only interested in NEMA sentences for the current time. It may be harmful to know one's current position every second? The GPS module's chip and software is by U-Blox.

http://www.reyax.com/Module/GPS/RY725AI/RY725AI.pdf

 

[Nullity]

I once tried to use my Garmin eTrex for this but ran into the apparenctly sub-par PPS thing. Seemed like it would have worked though. My sub-par ADSL seems to be capable enough when I am not disconnecting my network.

I am interested to try my Garmin again and see if it is as worthless as the time nerds say.

 

[ryzhov_al]

This project is not for the faint of heart. However, I will try this.

Here's the pieces you need and how to build it:
http://atoomnet.net/time-server-using-1pps-gps-receiver/

You must have a working Linux build environment for compiling the Asuswrt-Merlin firmware because you need to rebuild the Linux kernel with these changes. Will it work?

As for me, I've tried to build RTC from cheap DS1302 module and Arduino nano as a USB adapter I used this sketch with light modifications, so I managed to set/get time from shell:

#!/bin/sh
PORT=/dev/ttyUSB0

load_from_rtc()
{
    echo 'T' > $PORT
    read -t 2 resp < $PORT
    echo RTC time is $resp
}
save_to_rtc()
{
    echo 'S' > $PORT
    sleep 1
    date +"%Y,%m,%d,%H,%M,%S" > $PORT
}

But, the devil in the details, as usual.
1) I have to set up serial port first (as I remember):

stty -F /dev/ttyUSB0 raw ispeed 115200 ospeed 115200 cs8 -ignpar -cstopb eol 255 eof 255

2) I've get kernel panic couple of times while unloading ftdi_sio module.

So, it works, but I can't call this solution graceful. Too many steps required to get it work.
Also, I was surprised how system time is inaccurate, it drifts continuously behind and ahead from RTC.

 

[sfx2000]

@sfx2000, is that a chart from ntp statistics? Two things are puzzling. Why the offset is consistently in one direction? And somehow the graph forms sort of an "eye" pattern. Is there an interesting story behind..?

Using Xymon - and the charting range is off a bit - it's a bug in the RRD config, just never got around to fixing config file there...

Going to the chart itself, yeah, this one drifts quite a bit fast and slow - over time it's good, but we sync it to NTP to keep the logs straight - it's one of 8 blades in a chassis...

 

[sfx2000]

This is a fun thread - I've got a couple of Pharos iGPS 500 USB modules that'll output NMEA stanzas - one I use with my WiFi toolkit for position and time tracking, but I've got a spare - it's a SIRF III chip, which acquires pretty quick on a cold start as long as the almanac is current, otherwise, it'll take about 12 minutes to locate enough SV's to get a 3D fix, but once it updates the internal almanac, restarts are fast...

Pretty easy to configure with gpsd - didn't have to tweak anything on the build, just updated the config file for NMEA at 4800bps and it was good to go...

They're easy to come by on eBay and the list from Craig.. as they were used with MS Streets and Trips package as the bundled GPS unit - that's why on the second hand market they're pretty cheap...

They don't do Glonass or BeiDu, but if I recall, they might support WAAS (I know many Garmin's do)...

 

[kvic]

A few charts from me (not as fancy as those above).

I use scripts from this gentleman with little adaptation. The scripts create rrdb, collect stats and plot the charts to a web page. Perhaps they were written many years ago but still functional and very lightweight.

The offset is mostly below 2ms with a jitter on the same order. It certainly amazes me that a home router's clock can be tuned to this level of accuracy... for free. I don't know what happened on the sudden spark. My first guess would be network issue...second maybe a knee jerk action from linux kernel. Have to see if it'll be an ongoing concern..

Dispersion (rootdisp in the RFC) is something I don't quite get it. First look appears bad news as it's one order bigger than the offset. So if rootdisp is the maximum error wrt the reference source, then what's good in an offset of 1ms but max error 50ms in the estimate? But it's quite stable..I guess stability is by all means good in this kind of thing. A sinusoid or colourful skylines seem both are pleasing to look at..

 

[kvic]

Another chart from me...rrdtool is fun
(Thanks to Entware..the package is available for easy installation.)

This chart combines two curves: hw clock jitter (cjit) and change in hw clock frequency (wander). A wander value of 0 is a little bit suspicious..

The clock jitter began a beautiful decline from 1.4ms and lasted until Monday night (not shown in the above chart). Then it oscillates between 0.2-0.4ms as seen above. Perhaps that's the best jitter it could achieve on AC56U with the stock linux kernel.

From here, I wonder time sources of higher resolution will be of any extra benefit to a home router (or even PC) as the hardware is not capable enough. Looking forward to the results from ASAT's GPS clock once it's ready and also that from Nullity with his Garmin.

I think the Garmin will get much better time than that from Nullity's ADSL. A reflection on his charts, fluctuation in network latency maybe prevent NTPD from performing its job.

 

[ASAT]

Success. My router can now set its clock from the GPS receiver. However, the PPS events are not coming through to the Linux kernel on the router. This just means I won't get nanosecond precision. No problem.

Unfortunately, the FTDI driver included with Asuswrt-Merlin does not report PPS, even though I have enabled it in the kernel. My usb-to-serial converter did not report PPS because it is an FT232RL usb-to-serial converter.

However, you can check if your usb-to-serial driver supports PPS by searching the Asuswrt-Merlin source code for a function call: "usb_serial_handle_dcd_change". I see that it's supported in drivers/usb/serial/pl2303.c, so I will try this project again with a PL2303 usb-to-serial converter. OR, maybe if I'm brave, I will try adding this support in drivers/usb/serial/ftdi_sio.c myself.

Anyway, it still works fine without the PPS. My RT-AC68U boots up and sets its clock from the satellite. No Internet connection is required to set the router clock now.

/jffs/bin/ntpq -pn

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*127.127.20.0    .GPS.            0 l   13   16  377    0.000    0.088   0.007

The jitter will sometimes spike for unknown reason.

My GPS receiver is an RY725AI. This unit has flash memory. I tell it to send only the $GPZDA NEMA message. So it sends only the current time without the location information. The flash memory remembers this setting.

And I have the GPS receiver running at 9600 baud because the slower speed is recommended for better reliability when doing time synchronization. This setup can easily do 115200 baud, but that's not necessary.

The only strange thing is unplugging and plugging the GPS receiver makes a new /dev/ttyUSBn and things stop working. So the router needs a reboot if I unplug the GPS receiver. My NTPD configuration is hard wired to use serial port#0 only.

 

[sfx2000]

Success. My router can now set its clock from the GPS receiver. However, the PPS events are not coming through to the Linux kernel on the router. This just means I won't get nanosecond precision. No problem.

Unfortunately, the FTDI driver included with Asuswrt-Merlin does not report PPS, even though I have enabled it in the kernel. My usb-to-serial converter did not report PPS because it is an FT232RL usb-to-serial converter.

However, you can check if your usb-to-serial driver supports PPS by searching the Asuswrt-Merlin source code for a function call: "usb_serial_handle_dcd_change". I see that it's supported in drivers/usb/serial/pl2303.c, so I will try this project again with a PL2303 usb-to-serial converter. OR, maybe if I'm brave, I will try adding this support in drivers/usb/serial/ftdi_sio.c myself.

Wow, shaking out really old memories - back from the 2001-2003 timeframe - and this goes back to FTDI vs. Prolific...

It had to do with FTDI and how they implemented RS-232, and we had hella problems with that chip back in the day, we eventually moved to the Prolific chips just for that reason, as we needed all the pins on RS232...

 

[sfx2000]

Wow, shaking out really old memories - back from the 2001-2003 timeframe - and this goes back to FTDI vs. Prolific...

It had to do with FTDI and how they implemented RS-232, and we had hella problems with that chip back in the day, we eventually moved to the Prolific chips just for that reason, as we needed all the pins on RS232...

Drive our field engineers nuts for single port configs - for the production lines, we landed on the Kawasaki LSI KL5USB105's, which were USB to 4 RS-232 UART's - spendy, but reliable for NT/DOS/*nix drivers at the time...

 

[ASAT]

There is a fix to this FTDI driver issue to support PPS, as of Linux 3.13.1. The Asuswrt-Merlin kernel is Linux 2.6.36.4. Here is the fix:

2013-09-26, USB: serial: call handle_dcd_change in ftdi driver, by Paul Chavent
https://git.kernel.org/cgit/linux/k...c?id=d14654dff7a3520b5220367b848732a0a8ccdabe

Here is a note from the author:

PPS with USB to serial devices
------------------------------

It is possible to grab the PPS from an USB to serial device. However, you should take into account the latencies and jitter introduced by the USB stack. Users has reported clock instability around +-1ms when synchronized with PPS through USB. This isn't suited for time server synchronization.

If your device doesn't report PPS, you can check that the feature is supported by its driver. Most of the time, you only need to add a call to usb_serial_handle_dcd_change after checking the DCD status (see ch341 and pl2303 examples).