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.
Set the router clock with a GPS receiver for under $70
- Thread starter ASAT
- Start date
@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.
@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.
Code:
/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
Senior Member
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):
Code:
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
Code:
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
Last edited:
ASAT
Senior Member
I live on a 45-foot sailboat.
Last edited:
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.
Code:
~/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
Code:
~/ntpd/libcap-2.24$ diff libcap/Makefile libcap/Makefile.orig
46c46
< gcc $(BUILD_CFLAGS) $< -o $@
---
> $(BUILD_CC) $(BUILD_CFLAGS) $< -o $@
Cake
Senior Member
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....
My custom built ntpd has been running for over 40hours. It's stable like a rock. So is its memory usage:
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):
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:
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:
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?
Code:
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.confVIRT/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):
Code:
/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.522The 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:
Code:
/jffs$ cat /opt/var/log/ntp/ntp.drift
7.979A 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:
Code:
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.41The 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?
ASAT
Senior Member
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
Very Senior Member
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.
I am interested to try my Garmin again and see if it is as worthless as the time nerds say.
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:
Code:
#!/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
}1) I have to set up serial port first (as I remember):
Code:
stty -F /dev/ttyUSB0 raw ispeed 115200 ospeed 115200 cs8 -ignpar -cstopb eol 255 eof 255So, 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
Part of the Furniture
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
Part of the Furniture
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)...
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)...
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..
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..
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.
(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
Senior Member
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
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.
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
Code:
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.007The 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.
Last edited:
sfx2000
Part of the Furniture
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
Part of the Furniture
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
Senior Member
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).
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).
Last edited:
Similar threads
Similar threads
-
How to set upstream DNS but force clients to use the router for DNS?
- Started by chrisisbd
- Replies: 2
-
Attached drive not idling down as the firmware says and is set for- Started by skeal
- Replies: 6
-
-
-
can VPN Director be set to automatically use the wan for youtubeTV?- Started by 128bit
- Replies: 8
-
-
cipher is not set. OpenVPN versions before 2.5 defaulted to BF-CBC as fallback
- Started by atkinsom
- Replies: 2
-
WireGuard Server Clients Allowed IPs Not Getting Set
- Started by HarryMuscle
- Replies: 2
-