This is mine. I am still working on it. https://time.kml.lol/
just updated to https://ntp.kml.lol/ i think its better now on its own site
Just noticed these NTP220/270 devices.
Ordered me one, as they are pretty cheap.
€ 175 is pretty low for a standalone NTP+PPS with backup RTC.
And I do like the ports it has, so you can e.g. connect it to a PC and use it via USB.
Good one to test as it costs next to nothing, it’s worth to try it.
This is what I use to connect the pps to usb. I seen great stuff from it. It has like microseconds latency that I offset it in chrony. I use a n97 pc i got for 120 few years ago as my ntp server. It is also what is hosting it here.
It has it’s own 100mbit output.
As it do not have more then 30mbit upload, I’m going to see what it does for my STR1 server.
I wonder…
Most devices that do the same without PPS cost 150 euro, and with PPS mostly 400+
This little thing is cheap, can’t wait to play with it. But for standalone.
This is from my ai that been working on my network services.
What it is: A 5V FTDI USB-to-UART cable (FT232H chipset), ordered from Newark.
Purpose: GPS PPS refclock input for smolnut’s chrony, fed from the NTP270 GPS appliance’s terminal block.
Wiring:
- NTP270 terminal pin
O(PPS out) → white wire (DCD#) - NTP270 terminal pin
G(GND) → black wire (GND)
System config:
- Device:
/dev/ttyUSB0(FT232H),/dev/pps0via ldattach - ldattach service:
/etc/systemd/system/ldattach-pps.service(enabled, BindsTo=dev-ttyUSB0.device) - udev rule:
/etc/udev/rules.d/99-pps.rules- setspps0group to_chrony, mode0640, and reduces FTDI latency timer to 1ms - Chrony:
refclock PPS /dev/pps0 precision 1e-7 poll 4 refid PPS trust offset 0.1in/etc/chrony/chrony.conf(NOT in sources.d - that wasn’t picked up)
Key gotchas:
offset 0.1is required - the NTP270 terminal block PPS has ~100ms hardware delay; without it, smolnut runs 100ms fast and pool score tanksfilter 10was tried and removed - FT232H jitter is already low and filter reduced update frequency, making std dev worse- ldattach service appearing
inactive (dead)is normal - it daemonizes and pps0 keeps working - USB 2.0 HS ceiling: ~12µs std dev; can’t go lower without GPIO (smolnut’s ACEMAGIC N97 has none)
Result (as of 2026-06-05): Stratum 1, ~890ns system offset, 1.5µs RMS offset, 0.019 ppm skew, PPS selected as #*.
NTP270 as a source:
| Metric | Value |
|---|---|
| Current offset | +72-74 µs |
| Estimated error | ±1,088 µs |
| Std dev (sourcestats) | 5,379 ns (~5.4 µs) |
| Freq error | +0.007 ppm |
| Samples | 19 points over 1,161s |
| State | ^? - not selected (PPS is better) |
NTP270 is showing ^? (unusable/not selected) because PPS is authoritative - NTP270 is still polled as an epoch reference but chrony deprioritizes it.
PPS (via C232HD-EDHSP-0) - the actual winner:
| Metric | Value |
|---|---|
| Adjusted offset | +9,230 ns |
| Measured offset | +11 µs |
| Std dev | 9,531 ns (~9.5 µs) |
| Freq skew | 0.014 ppm |
| Samples | 64 points over 1,009s |
System tracking:
- Stratum 1, system time 965 ns fast, RMS offset 844 ns, skew 0.015 ppm
So the NTP270 UDP path has ~72 µs offset with ~5.4 µs jitter - that’s your network/software latency from the NTP270 to smolnut over VLAN40. The PPS wire path (the FTDI cable) is what actually disciplines the clock at ~9.5 µs std dev, with the offset 0.1 correction baked in to account for the NTP270’s ~100ms hardware PPS delay.
The USB port on the NTP270 (CON on the back panel) is an out-of-band serial console:
- Connector: Micro-B USB
- Chip: WCH CH340 UART-to-USB
- Settings: 115200 baud, N81, no flow control
- Auth: required if an admin password is set
- Purpose: device config and network troubleshooting independent of the network interface
On Linux the ch341-uart module is usually built in (minicom works). On Windows you’d need the CH340 driver from WCH + PuTTY.
The 270 is poe and 220 isnt but i wouldnt use it on here since it has a 10k limit on clients thats why im using my n97 pc.
Those CenterClick NTP220 and NTP 270 devices are interesting - @Bas - when yours comes in - do you mind uploading some high resolution photos of the boards - would love to be able to identify the chips they’re using
It’s not clear to me if they use any temperature compensating techniques
Any idea what RTC/Oscillator they use?
Looks like the GPS Module is Quectel L76-L
They are limited to 10,000 packets per second (not sure if thats full-duplex or simplex) - I see that packet rate @ ~ 6 mbps on my pool server (10 kpps rx & 10 kpps dx)
Zone: north-america us
Net speed: 3 Gbit
Are you sure this is hardware delay? It is rather high for that, and the value looks suspiciously like a typical pulse width, pointing to a potential polarity issue (i.e., triggering on the wrong edge of the pulse) rather than actual delay.
you were correct, it is a polarity issue. The offset 0.1 is compensating for triggering on the wrong edge. The cleaner fix would be switching chrony to use the CLEAR event instead of ASSERT, which would capture T.000 directly and eliminate the need for the offset entirely. That said, offset 0.1 achieves correct time either way - it’s just not the ideal solution.
Up to you obviously, but seems strange to me to go through all the trouble of trying to get as good as possible of a solution, and then compromise at this point. Especially when the “fix” would be as easy as replacing the “offset 0.1” stance in the configuration by appending “:clear” to the PPS device path.
The leading edge is what indicates the top of the second with high accuracy. I doubt the length of the pulse would be guaranteed to be accurate enough to make the trailing edge (plus offset) as accurate as the leading edge.
But in the grand scheme of things, it probably doesn’t matter in comparison to the unknown latency and jitter that is introduced by the serial-to-USB bridge, even if the high-speed FT232H is much better in this respect than the more common full-speed FT232R.
You were right - it was a polarity issue. Applied the fix by appending :clear to the PPS device path in chrony (/dev/pps0:clear). Offset went from ~100ms to -474ns. Thanks for pushing on it.
Still waiting to arrive, they forgot to process my order.
I hope to have it next week.
It brought it down a lot!!
Reference ID : 50505300 (PPS)
Stratum : 1
Ref time (UTC) : Sat Jul 04 14:31:26 2026
System time : 0.000000114 seconds slow of NTP time
Last offset : -0.000000139 seconds
RMS offset : 0.000000290 seconds
Frequency : 0.911 ppm fast
Residual freq : -0.000 ppm
Skew : 0.005 ppm
Root delay : 0.000000001 seconds
Root dispersion : 0.000020887 seconds
Update interval : 16.0 seconds
Leap status : Normal
https://dreamstation.systems/ntpstats.txt
chronyd logs, a nftables packet counter, and some data munging with bash / awk
That’s a really neat page, thanks for sharing!
I do all of my logging and monitoring via Grafana, which is great for experiments and documentation, but I love how lightweight your page is.
My Centerclick.com NTP220 device uses a very nice http-monitor page.
That for just a 200 USD/EURO device, that includes everything except an UTP-cable 
I ordered another one for my server in Holland, so I can upgrade it to Str1.
@ccb056, it can track 100.000 clients, does 10.000 requests per second.
But can handle 1.000.000 clients not-tracked.
For me that is by far enough.
As for the GPS module, yes it is.
LAN connection is 100Mbit, should be enough to keep your network from being overloaded.
Sorry but that is 10000 clients/second that it can handle, and it can track 100000 clients.
But it can handle non-tracked 1000000 clients.
I have seen 3G speed settings and they don’t get near 10000 requests a second.
My friend in Leuven has set 3G and he barely gets 2000/sec.
Oh, okay. I’m getting about 460,000 to 500,000 a minute on mine n97.
10.000/s x 60seconds = 600.000 a minute, well within your limits.
So yes it can do it, it’s on the edge, but it can handle it.