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

[sfx2000]

The challenge, back then, was that the FTDI chips in our application - USB to Serial for IS707 CDMA data services, they certainly were not consistent/reliable with regards to on/off state transitions, and DCD, many times, was in an uncertain state - the PL and KLSI chips were much more reliable, if more spendy...

Remember that USB at a phy level is pretty basic with USB1/1,1 5 lines- Tx +/-, Rx +/-, and ground, so DTR, DCD, RTS/CTS lines where all in the COM emulation via the CDC endpoint, and state transitions were critical to make it work properly...

CDC wasn't really a priority compared to HID and Mass Storage back in the day.. with GPS devices, and specifically with PPS, seems like this is pretty important unless the GPS device does native USB, which many don't.

Anyways, thanks for refreshing the memory banks...

 

[kvic]

Congrats! Finally hearing from you

     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.

The numbers look very nice, orders of magnitude better than from time servers. I guess that's the reward of sourcing from stratum 0!

Jitters could be coming from system interrupts. At the moment of a spike, higher priority interrupts perhaps preempted your usb-to-serial data.

I also see jitter spikes in my setup from time to time:

What is your steady state ntp.drift value? Mine top off around 8.3 ppm

 

[kvic]

Anyways, thanks for refreshing the memory banks...

U reflashed my memory..lol. In the beginning of this century, serial ports started to disappear on notebooks. It was not easy to find a good usb-to-serial adaptor. Finally settled with a prolific.

 

[sfx2000]

Yep - Prolific back in the day was the best solution out there - nice thing is that they had Win98 and Win2K drivers that were pretty well sorted...

The Bafo BF-810 was the reference that we used to build new cables for our field guys (logging/provisioning/flashing cell phones)

 

[ASAT]

What is your steady state ntp.drift value?

cat /jffs/ntp/ntp.drift
5.868

 

[ASAT]

I decided to be brave and fix the problem myself. Here's my Asuswrt-Merlin backport of Paul Chavent's FTDI-PPS patch 2013-09-16 to Linux kernel 3.13.1.

Asuswrt-Merlin FTDI-PPS patch:

diff --git a/release/src-rt-6.x.4708/linux/linux-2.6.36/drivers/usb/serial/ftdi_sio.c b/release/src-rt-6.x.4708/linux/linux-2.6.36/drivers/usb/serial/ftdi_sio.c
index 79a8633..2b34bc9 100644
--- a/release/src-rt-6.x.4708/linux/linux-2.6.36/drivers/usb/serial/ftdi_sio.c
+++ b/release/src-rt-6.x.4708/linux/linux-2.6.36/drivers/usb/serial/ftdi_sio.c
@@ -1868,7 +1868,19 @@ static int ftdi_process_packet(struct tty_struct *tty,
           are only processed once.  */
        status = packet[0] & FTDI_STATUS_B0_MASK;
        if (status != priv->prev_status) {
-               priv->diff_status |= status ^ priv->prev_status;
+               char diff_status = status ^ priv->prev_status;
+               priv->diff_status |= diff_status;
+        
+               if (diff_status & FTDI_RS0_RLSD) {
+                       struct tty_struct *tty;
+
+                       tty = tty_port_tty_get(&port->port);
+                       if (tty)
+                               usb_serial_handle_dcd_change(port, tty,
+                                               status & FTDI_RS0_RLSD);
+                       tty_kref_put(tty);
+               }
+        
                wake_up_interruptible(&priv->delta_msr_wait);
                priv->prev_status = status;
        }

diff --git a/release/src-rt-6.x.4708/linux/linux-2.6.36/drivers/usb/serial/generic.c b/release/src-rt-6.x.4708/linux/linux-2.6.36/drivers/usb/serial/generic.c
index e4db5ad..32500f0 100644
--- a/release/src-rt-6.x.4708/linux/linux-2.6.36/drivers/usb/serial/generic.c
+++ b/release/src-rt-6.x.4708/linux/linux-2.6.36/drivers/usb/serial/generic.c
@@ -492,6 +492,16 @@ void usb_serial_handle_dcd_change(struct usb_serial_port *usb_port,
        dbg("%s - port %d, status %d", __func__, usb_port->number, status);
+       if (tty) {
+               struct tty_ldisc *ld = tty_ldisc_ref(tty);
+
+               if (ld) {
+                       if (ld->ops->dcd_change)
+                               ld->ops->dcd_change(tty, status, NULL);
+                       tty_ldisc_deref(ld);
+               }
+       }
+
        if (status)
                wake_up_interruptible(&port->open_wait);
        else if (tty && !C_CLOCAL(tty))

Now my Asuswrt-Merlin kernel is PPS aware. Check it out:

/jffs/bin/ppstest /dev/pps0

trying PPS source "/dev/pps0"
found PPS source "/dev/pps0"
ok, found 1 source(s), now start fetching data...
source 0 - assert 1444056824.073274327, sequence: 1288 - clear  1444056822.973244956, sequence: 1287
source 0 - assert 1444056825.073302054, sequence: 1289 - clear  1444056822.973244956, sequence: 1287
source 0 - assert 1444056826.073329729, sequence: 1290 - clear  1444056822.973244956, sequence: 1287
source 0 - assert 1444056827.073356417, sequence: 1291 - clear  1444056822.973244956, sequence: 1287
source 0 - assert 1444056828.073260151, sequence: 1292 - clear  1444056822.973244956, sequence: 1287
source 0 - assert 1444056829.073286372, sequence: 1293 - clear  1444056822.973244956, sequence: 1287
source 0 - assert 1444056830.073313089, sequence: 1294 - clear  1444056822.973244956, sequence: 1287
source 0 - assert 1444056831.073340522, sequence: 1295 - clear  1444056822.973244956, sequence: 1287

AND, most importantly my NTPD is PPS aware because I remembered to copy timepps.h to /usr/include before building NTPD.

/jffs/bin/ntpq -pn

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
x127.127.20.0    .GPS.            0 l    3   16  377    0.000    1.243   0.072
x127.127.22.0    .PPS.            0 l    2   16  377    0.000    1.246   0.078

 

[ASAT]

An "o" means it's using my router clock as a PPS reference? This is really good news to me. I'm not noticing any jitter spikes either, but time will tell.

"The peer has been declared the system peer and lends its variables to the system variables. However, the actual system synchronization is derived from a pulse-per-second (PPS) signal, either indirectly via the PPS reference clock driver or directly via kernel interface."

/jffs/bin/ntpq -pn

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
o127.127.20.0    .GPS.            0 l   11   16  377    0.000    0.025   0.024

SOURCE: http://doc.ntp.org/4.1.1/ntpq.htm


I imagine the only improvement here would be to use the router's GPIO interface for PPS signal input instead of the USB port? Can the router's WDS button be re-purposed for PPS input?

Who doesn't love this kind of precision?

 

[kvic]

I thought the PPS signal comes from your GPS receiver which in turn derives the signal from GPS data? PPS kernel driver reads PPS signal from an external source, and applies additional filters to reduce jitters caused by hardware interrupts and other latencies on the router's operating system. If there is an PPS signal, indeed it should be used. It makes counting more accurate regardless the kind of time source such as RTC, time server, GPS or atomic clock..

I find these two references interesting 127.127.22.0 and 127.127.20.0, especially the first one. Distant spacecrafts and orbitors run NTP too. Isn't it amazing we can have it on home routers?

Nice work.

 

[sfx2000]

Nice work.

Concur - well done

 

[ASAT]

the PPS signal comes from your GPS receiver which in turn derives the signal from GPS data?

The PPS output of my GPS module is connected to the DCD pin of the FTDI usb-to-serial converter. Be aware that some FTDI modules do not break out all the pins. The ones I bought two years ago do not have a DCD pin. The PL2303 modules are the same way. Before you purchase, be sure you can see a hole or pin marked DCD on the FT232RL. And be sure the GPS module has a hole or pin marked PPS.

On the FTDI module, I soldered in a yellow LED between DCD and GND to visually see the pulse from the GPS module. So my yellow blinky light is a precise approximation of the pulse from the Cesium oscillators on those GPS satellites. Apparently, these GPS pulses are all precisely synchronized to the same moment in time.

The newer GPS satellites probably have 2 or 3 of these units on board.
OSA 3235B Cesium Clock
http://www.oscilloquartz.com/product-osa-3235b-cesium-clock-1123-64

I'm suprised that the FTDI driver included with Linux 2.6.36 is not a complete implementation. My patch enables the DCD pin for the USB-FTDI driver and it also enables the PPS event for USB. Even if you've rebuilt the kernel with PPS enabled, you still need my simple patch to get the PPS events to come through to user mode.

Soon I will post my RRD plots.

 

[RogueSpear]

I've been following this thread with interest even though I never really had any intention to implement a solution based on the topic. An alternative solution just hit me last week though and it seems to be working fine.

I have an old Moto Razr M (XT907) that is bootloader unlocked and rooted, but still SIM locked to Verizon. I haven't had a SIM card in it for years, but let it quietly operate as an SSH server and perform some other odd duties with Tasker, AutoRemote, and Vera Alerts. What occurred to me is that the app Servers Ultimate Pro which I use for my SSH server, also has an NTP server component. Even without a SIM, the phone still says it's on the Verizon network - just that it can only make emergency calls. Well I think it's getting it's time from Verizon even in a SIM-less state. Either that or its getting the time from the GPS that I have on all the time. Either way, I pointed my AC3200 at it as the time source and it seems to be working great. Just thought I'd throw it out there in event someone finds it useful.

Sent from my LG-D850 using Tapatalk

 

[Nullity]

I've been following this thread with interest even though I never really had any intention to implement a solution based on the topic. An alternative solution just hit me last week though and it seems to be working fine.

I have an old Moto Razr M (XT907) that is bootloader unlocked and rooted, but still SIM locked to Verizon. I haven't had a SIM card in it for years, but let it quietly operate as an SSH server and perform some other odd duties with Tasker, AutoRemote, and Vera Alerts. What occurred to me is that the app Servers Ultimate Pro which I use for my SSH server, also has an NTP server component. Even without a SIM, the phone still says it's on the Verizon network - just that it can only make emergency calls. Well I think it's getting it's time from Verizon even in a SIM-less state. Either that or its getting the time from the GPS that I have on all the time. Either way, I pointed my AC3200 at it as the time source and it seems to be working great. Just thought I'd throw it out there in event someone finds it useful.

Sent from my LG-D850 using Tapatalk

That reminds me that I never fully investigated the GPS capabilities of my unused XT912.

I had not considered NTP. Interesting.

Do you know the accuracy? (I do not know how to check, off-hand)

 

[kvic]

That's good use of an old phone!

Accuracy wise I would expect within a few milliseconds. My setup could be taken as a sample point for such a setup. Routers will be using a stratum 1 source (the phone or in my case the time server). What's minimised is the uncertainty in network latency.

 

[RogueSpear]

Well I sort of fell on my face with this one. I haven't tracked down how it's doing it yet, but on boot up, the router wants time way before my phone connects via WiFi. I hardcoded the IP address of the phone into the GUI, but it's still managing to grab the time beforehand - maybe from the entries in my hosts.add. Well I'm going to give this a shot with my Asus TF700T which has a USB to ethernet adapter and see if I fair better.

Sent from my LG-D850 using Tapatalk

 

[ASAT]

The GPS module is put in a weatherproof plastic box and it is up on the roof of the building. Use Silicone sealant with UV protection to seal the plastic box. Be sure it is very dry inside the box before sealing it. Do not seal the box on a very humid day. Usage of dessicant bag inside the box is recommended?

Use pieces of 1-inch PVC pipe and PVC elbows to make a nice adjustable mount, fixed to a sturdy structure with zip ties.

The GPS module is connected to the USB-to-serial module (at the router) over a run of CAT6 unshielded cable about 35 meters long. It's the best cable to use because it has eight wires for whatever you want and it's very cheap. No Ethernet here, just use the wires for 9600 baud serial data communications.

The RY725AI has a 7-day rechargeable lithium battery built-in with flash memory. Takes less than 30 seconds to re-acquire the GPS satelletes. I've got a strong fix on 8 to 10 satellites right now. Operating temperature range is -40C to +85C. Designed for harsh environment and people.

Here's my plots:

 

[ASAT]

Here are the other plots. I don't know the reason for the spike.

 

[kvic]

The dispersion from GPS is very impressive. Also two orders better when compared to my setup. The offset is very good. One order better.

Nice

EDIT:

Advertise in your local community. Invite ppl to use your time server. It's stratum 1 !! Very good community service..

 

[Nullity]

EDIT:

Advertise in your local community. Invite ppl to use your time server. It's stratum 1 !! Very good community service..

I will not be doing that.

The threat of having my NTP server used in a DDoS is too great. The config of the official NTP daemon has never made sense to me, especially the encrypted/secure peering.

Within the past year, Cloudflare was hit by a 400Gbps (!?!?) DDoS that employed NTP amplification.

 

[sfx2000]

That's good use of an old phone!

Accuracy wise I would expect within a few milliseconds. My setup could be taken as a sample point for such a setup. Routers will be using a stratum 1 source (the phone or in my case the time server). What's minimised is the uncertainty in network latency.

CDMA handsets are pretty accurate - they might drift a bit in sleep mode, but they do have "back to the future" catchup when going from sleep to idle - they will always bit a minor bit time late, due to chip delay from the serving cells/sectors, but they are very constant because they must be to keep synced with the CDMA 2G network.

CDMA cellsites are all synced to GPS time independently...

Phones need to acquire a GPS fix very quickly during E911 to get a decent area of uncertainty/probability... so they don't have that huge amount of time to search for SV's (there is a network PDE function that takes into account the AFLT cell-site rough fix to limit the SV search to get that quick-fix). So time is very important, not just for general CDMA call processing, but for E911 requirements in the US (and perhaps other countries)

Because of this, old mobile phones can be a decent time-reference, even without an active subscription...

 

[sfx2000]

Here are the other plots. I don't know the reason for the spike.

Interesting on the spike, as it tracks across the different plots...

Any ability on the GPS to change integration times - many default to short, so they can get a good fix on the SV's, but this also increases time instability across them with a 3d fix (4 SV's)... get noise in there (terrestrial or other - solar flares can knock out on SV due to noise, so average changes based on existing SV's)...

One getting a good 2d (3sv's) or a 3d (4sv's) fix, then one can extend integration time to refine the solution for the AOU/AOP, and as such, since this time dependent, get a solid solution...

And if the GPS receiver can do WAAS, that's even more awesome as a solid time source..