Thinking about it I realise that in the last decade I haven't been using serial ports, but serial-over-usb. My GNSS receiver has only an USB-C connector and talks to gpds. If you can generate NMEA sentences, serial-over-usb will work.

--

Ruben

Erik,

Erik Kaashoek via time-nuts wrote:

If I understand this correctly, you have a USB device that provides a
GPS receiver, and you want to use this as reference time source for your
computer that runs ntpd.

Normally, such USB devices can't be accessed via the network. The device
is a so-called reference clock (refclock), and the way your computer can
use the USB device as reference time source depends on the type of USB
device, and which protocol(s) it supports, e.g. some NMEA or binary
protocol.

A common solution is to use gpsd to periodically read the time from the
USB device and feed it into a shared memory (SHM) segment. Then
configure ntpd to use the shared memory (SHM) refclock driver to read
the time from the SHM. With this setup, your computer will become a
stratum-1 server.

However, please keep in mind that time transfer via USB provides some
jitter, so the resulting accuracy is usually less than with a GPS PCI
card or a receiver that also provides a 1 PPS hardware signal.

Martin

Serial <-> USB converters can be used to deliver PPS with ~microseconds
accuracy.
USB endpoint version matters.  My best results used a Sabrent convertor.
USB load testing is probably a good idea.

On Fri, Jan 9, 2026 at 11:37 AM David C. Partridge via time-nuts <
time-nuts@lists.febo.com> wrote:

As others have said the inherent jitter on USB may be (is likely) an
issue.

What type of USB connection? and I'm guessing you want 'ultimate
precision' for you project...

If Type-C be aware that if you are able to negotiate pin function; you
can force the connection into either 'debug-accessory' mode (via
resistors) or an 'alternate mode' (via PD). In 'debug-accessory' mode
all the Type-C pins are available to be reassigned to custom purpose,
which could be anything you want....

There's also 'audio accessory' mode which might offer a way to bypass
USB jitter, in favour of ADC jitter in the connected device.

Cheers,
Simon.

On 2026-01-09 04:10, Erik Kaashoek via time-nuts wrote:

David C. Partridge via time-nuts writes:

Well, it depends a lot by what you mean by "precise" and how long time
you have ?

The USB delays follow a well defined statistical distribution, not
symmetric unfortunately, but something you can filter and average
out in relevant timescales.

But if you are just after milliseconds, you should be fine.

--
Poul-Henning Kamp      | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG        | TCP/IP since RFC 956
FreeBSD committer      | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

Hi

One option might be to steal an idea from 1588:

Send lots of packets from the device to the PC. Each one has a “device clock” time stamp.

Reply to every packet with one from the PC. Each one has a “PC clock” time stamp.

Eventually work out the offset between the two clocks.

Since USB can’t hardware time stamp packets, there are indeed limits to doing this. Does it get you to microseconds rather than miliseconds? It might.

Bob

Don't forget that the bit rate for USB-2 is ~ 2ns. If you are receiving 9600 or even 115200 bits per second, the jitter and latency introduced by the USB connection are very, very small compared to the glacial pace of your emulated RS-232.

regards,

--

Ruben

On Fri, 09 Jan 2026 10:18:56 -0800
simon--- via time-nuts time-nuts@lists.febo.com wrote:

Isochronous mode is a well supported method for handling time sensitive
streams across a USB bus:
https://beyondlogic.org/usbnutshell/usb4.shtml#Isochronous

USB-2 goes up to 480 Mbps, but still has the 125 microsecond frames.   There are a lot of bits in that 125 microseconds, but no guarantees about where your bits are in the frame. I suppose you could set up an isochronous channel - that constrains the signalling of those particular bits. To my knowledge, the typical "Serial over USB" doesn't use isochronous channels.  Perhaps if your device was doing "audio or video streaming" (or used those protocols) - then you can get fairly decent low-ish jitter timing - probably way better than a microsecond.
 

On Fri, 9 Jan 2026 23:36:24 +0100, Rsec Van der leij via time-nuts time-nuts@lists.febo.com wrote:

Don't forget that the bit rate for USB-2 is ~ 2ns. If you are receiving 9600 or even 115200 bits per second, the jitter and latency introduced by the USB connection are very, very small compared to the glacial pace of your emulated RS-232.

regards,

--

Ruben

time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe send an email to time-nuts-leave@lists.febo.com
 

Yo Jim!

On Mon, 12 Jan 2026 10:28:47 -0500
Jim Lux via time-nuts time-nuts@lists.febo.com wrote:

Almost all GNSS receivers are USB 2, of one sort or abother.  PPS from a
GNSS receiver will arrive i nthe same one of 1024 slots every second, so
you get a very stable pulse every 1 milli second.  That will jitter due
to the USB clock jitter, much worse than the PPS jitter.o

Many people consider 1 mill second good enough.  If not, you go to NTP
over ethernet and get close to 10 micro seconds jitter.  To do better
than that you go to PTP, or a PCIe bassed GNSS receiver.

"Most" is misleading.  Older GNSS receivers opearate at the specified
baud rate  (/dev/ttySBx).  Newer ones use /dev/ttyACM, which is fully
abstract.  You can set the baud on most ttyACM to anything you want and
it changes nothing.

U-block even puts two serial channels down a ttyACM.

I find 115.2 very rare for /dev/ttyUSB.  A ndmenaingless with
/dev/ttyACM.

Newer receivers ttyUSB commonly can get up to 4Mbps.

RGDS
GARY

Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
gem@rellim.com  Tel:+1 541 382 8588

    Veritas liberabit vos. -- Quid est veritas?
"If you can't measure it, you can't improve it." - Lord Kelvin

This is not true, most devices are USB2 which use 8kHz micro-frames.

Yes there is jitter (at 125µsec) and it is worse than the GPS PPS output, but like anything it depends what you want it for.

For synchronising PC time a USB GPS engine is more than adequate, if you want more then it is necessary to know the limits of the application.

For the application of synchronising a PC clock I think the following thread is very informative:
https://lists.freebsd.org/pipermail/freebsd-arm/2019-August/020263.html https://lists.freebsd.org/pipermail/freebsd-usb/2019-August/016078.html

Ian Lepore was (RIP) working for MicroSemi and involved in timing solutions as his day job so I think he knew his stuff.

For what it is worth I have replicated similar performance with a Beaglebone Black (using input capture for 1PPS) and a PC via USB connected to a uBlox M8T.

--
Daniel O'Connor
"The nice thing about standards is that there
are so many of them to choose from."
-- Andrew Tanenbaum

Yo Daniel!

On Tue, 13 Jan 2026 12:18:36 +1030
Daniel O'Connor darius@dons.net.au wrote:

The details do not matter.  The reality is that PPS over USB comes out
at 1024 times a second.  I have boxes of GNSS receviers here that work
that way.  If they have PPS at all.  I would be happy to sell you a
few.

The jitter does not care what you want it for.  It is what it is.

NTP limits out a one nano second.  PC clocks max out around 50 nano
seconds. With care, some inexpesinve GNSS can approach that.  But PPS
over USB maxes out at around 1 micro second. I would be happy to
supplong time (1 week) ntpviz plots to match my assertion.

Nothing there contradicts what I said.  It matches my expectattions.
For short periods of time.  But much better to present the data with
long term ntpviz plots.

As I said, I disagree with nothing he said.  I still claim he did
not dig deep enough, using more advanced techniques.

I have repeated his experiment, continuously for a decades, on over
a dozen clocks.  Way more going on than he shows with a 2 munute
snap shot.

In one very long running experiment,, I compare the PPS over USB, using
NTP, with an onbourd Meinberg PCIe GPS clock.  Then take a weeks data
into ntpviz.  Then you see the 1 milli second barrier.

Sure, anyone can get those results.  One millisecond is easy.  0.02
millisecond for two minutes is easy.  54 microseconds for a week is
hard.

RGDS
GARY

Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
gem@rellim.com  Tel:+1 541 382 8588

    Veritas liberabit vos. -- Quid est veritas?
"If you can't measure it, you can't improve it." - Lord Kelvin

Good afternoon!

On Tue, 13 Jan 2026 12:18:36 +1030
Daniel O'Connor via time-nuts time-nuts@lists.febo.com wrote:

I think I have to add here a few more details about how confusing USB
and its nomenclature is.

The protocol version (1.x, 2, 3,x, 4) defines how the logical
protocol looks like and what speeds are available. The key word
here is "available".

The speed rate says how quickly you can shove your data through
the wires. Currently defined are:
Low-Speed (LF):   1.5 Mbps
Full-Speed (FS):  12 MBps
High-Speed (HS):  480 MBps
Super-Speed (SS): 5-80 GBps

LF and FS were the original speed ratings introduced in USB 1.0.
USB 2.0 added HS and USB 3.0 added SS.

LF was originally intended as a low-cost option for slow devices that
didn't need high data rates, like keyboard and mice. FS was for everything
else. HS and SS were introduced, because we always have a need for
more speed.

As I wrote above, the key word is available. This means you can have
an USB 4 devices that runs only at the 1.5 Mbps of LF. It just supports
the changes to the logical protocol (bits in the varios descriptor tables
stored on the device) according to the USB 4 standard. It doesn't mean
it supports 80 Gbps. I.e. saying a mouce is USB 2 doesn't mean it transfers
data at 480 Mbps. Thus it is very very important, to distinguish these two
things. Yes, it is totally the fault of the USB-IF and manfacturers to make
this so confusing to consumers. But live is this way.

Almost all USB devices sold since ~2002 are USB 2 and USB 3 devices.
Meaning they support the protocol version 2 or 3. This includes everything
from mice, over weird gadgets that vibrate and beep all the way to
SDR radios and harddisk/SSD.

To repeat: What speed these devices support is independent of the protocol
version!

Next we need to talk about frame length. or rather its timing.
LF and FS have a 1ms frame and HS a 125µs frame. (I don't remember
what frame length SS had and can't find it at the moment). The frame
length is tied to the speed rating the device supports, not to the
protocol version or what the host supports. I.e. an USB 3 device that
runs at FS that is connected to a host supporting USB 4 SS will run
with a frame length of 1ms, because that's what the speed rating it
can run at dictates.

With few exceptions, almost all usb serial devices run FS, independent
of the usb protocol they support. This is mostly a cost trade-off.
You get 12Mbps which is quite a bit faster than any of the intended data
sources can produce. Which means, we get a +/-0.5ms jitter. when we use
an USB serial device for timing.

There are µC and serial dongles that support HS and these will have
a 125µs frame length and thus a +/-62.5µs jitter. But they are not that
common.

The speed rating a device runs on is negotiated between the host and
the device. You will always end up with highest common speed that
the host, the device and all the hubs inbetween support.

To know what speed rating your device runs at, you need to ask your OS.
E.g on linux that would be lsusb -v in the "Negotiated Speed" line.

To summarize and emphasize again: If you are talking about data transfer
rate or timing uncertainty, the speed rating of the device is the thing
you need to quote, not the protocol version number.

Please be careful with thsese results. They are not transferable to most people.
Note that Ian Lepore used an NXP i.mx6 SoC (think of it as a better version
of the Raspberry pi). This µP has a very different architecture how its USB
peripheral is connected to the CPU core. It is a lot more direct and thus
has a lot less delay and timing uncertainty. On a PC, there is not only
lot more between the USB host-interface and the CPU (it's a PCI-e device
that connects through multiple PCI-e bridges to the CPU and is usually located
in a low-speed/low-performance corner of the system... at least for USB2).
Additionally to that, on the mainboard you usally have a USB hub
between the USB host-interface and the actual connector, sometimes even
more than one USB hub. Of course, these add more delay and timing uncertainty.

Also be aware that the jitter NTP reports is a lower estimate of the uncertainty
that USB timing delivers. Part is the hanging bridges problem, that I haven't
touched on at all (see the mail by Hal Murray on Fri, 09 Jan 2026 23:21:21 -0800
for details). Another part is that you have no way of knowing how much delay
there is between the connector and the CPU and whether that changes over time
(the PC can reconfigure some of the interconnects on the mainboard)

I hope these clarifies some of the points raised in the discussion and
why different people see different results.

		Attila Kinali

--
Science is made up of so many things that appear obvious
after they are explained. -- Pardot Kynes

I recreated the low tech PPS test.  Host is a RPi-5 running 64-bit
Raspberry Pi OS. The RPi5 is sync'd to UTC(GPS) using an Uputronics  GPS
HAT  (Ublox module)  connected via the GPIO pins. A Garmin LVC18 is powered
by an AC adapter and goes to an FTDI serial-USB adapter. FTDI Part
No.:US232R-500-BULK  [The Sabrent adapter I mentioned previously was not
the best performer.]  The USB connects to the Rpi.  The Garmin GPS is not
used for host synchronization.

The Uputronics serial interface (NMEA or binary) is handled by gpsd
(Thanks, Gary and team!)  The PPS signal is handled by the Linux PPS driver
(which also feeds gpsd) and is used by chrony to synchronize the host.

The PPS driver provides a utility, ppstest, to display the PPS timing.  I
monitored both GPS's for over 24 hours, see Figure 1. The two GPSs have
fairly narrow peaks.  The Uputronics GPS provides the host timing, so
naturally the offset is near 0.
The Garmin+USB was surprisingly narrow, but there are some outliers, see
Figure 2.  7% of the points have offsets over 20 microseconds.  The
Garmin+USB offset over time shows lots of structure, see FIgure 3.

Steve

[image: image.png]
[image: image.png]

[image: image.png]

On Tue, Jan 13, 2026 at 2:56 PM Attila Kinali via time-nuts <
time-nuts@lists.febo.com> wrote: