“maybe” that qualifies all of that. Welcome to the real world, all sorts of bad stuff happens. Bob > On Jan 30, 2023, at 6:18 PM, S McGrath via time-nuts wrote: > > Driving Pin1 only works with a ‘real’ serial port on a dedicated IRQ. a > USB interface will add unpredictable latency > > On Mon, Jan 30, 2023 at 6:16 PM Lux, Jim via time-nuts < > time-nuts@lists.febo.com> wrote: > >> On 1/30/23 12:28 PM, S McGrath via time-nuts wrote: >>> Most common way of getting 1PPS into a computer without a dedicated 1PPS >>> interface is to drive a RS-232 port’s Carrier Detect pin (pin 1 on DB-9) >>> with the 1PPS signal >> >> >> >> back in the day when that tied directly to an interrupt with consistent >> latency, that works pretty well. >> >> >> These days, though, there's often USB hosts in the way, or some other >> intermediate interfaces that increases the uncertainty in timing of >> "when software does something" in response to "external event" >> >> >> _______________________________________________ >> time-nuts mailing list -- time-nuts@lists.febo.com >> To unsubscribe send an email to time-nuts-leave@lists.febo.com > _______________________________________________ > time-nuts mailing list -- time-nuts@lists.febo.com > To unsubscribe send an email to time-nuts-leave@lists.febo.com

ncy and jitter. A PCI-E network card generating an interrupt still needs to send a MSI packet over the PCI-E network bus to the PCI-E controller, which then needs to send it on the CPU through some other kind of internal network. But that's not even the bad part. Once the CPU gets an interrupt, there is still a lot of stuff that needs to happen in software before a timestamp is generated. The CPU must context switch, new cachline loads from RAM for data and code, the base kernel interrupt dispatching, etc. With tests I did a while back with GPS PPS on an embedded Linux board, this was the largest source of error. Despite hardware timestampers being common on microcontrollers, SoCs that can run Linux never seem to have them. I wonder if one could make a useful USB timestamper with a common USB microcontroller board. These have hardware counters that can timestamp a PPS. It would be easy to send these timestamps over USB. Not sending events about a PPS, but sending the actual timestamp of the PPS. USB has, comparatively, terrible timing jitter, so timestamping the arrival of a USB packet is of course no good. With a bit of thought, we might think this is a step back. We have GPS with an accurate clock that sends NMEA timestamps to us over an inaccurate UART. Now we have a microcontroller with a semi-accurate clock sending timestamps to us over an even more inaccurate USB interface. Same problem, but worse. But there is a difference! Typically the clock in an USB connected microcontroller can use USB clock recovery. It's disciplined to the 1kHz USB SOF signal from the host computer. This lets them meet the USB timing spec with a cheap internal resonator. So the clock in the microcontroller that gives us timestamps is in fact tracking our clock. Does that make a difference? We can infer that the error in the timestamps we get reflects a matching error in the host clock we are trying to discipline with the PPS. On Mon, Jan 30, 2023 at 4:01 PM S McGrath via time-nuts < time-nuts@lists.febo.com> wrote: > Driving Pin1 only works with a ‘real’ serial port on a dedicated IRQ. a > USB interface will add unpredictable latency > > On Mon, Jan 30, 2023 at 6:16 PM Lux, Jim via time-nuts < > time-nuts@lists.febo.com> wrote: > > > On 1/30/23 12:28 PM, S McGrath via time-nuts wrote: > > > Most common way of getting 1PPS into a computer without a dedicated > 1PPS > > > interface is to drive a RS-232 port’s Carrier Detect pin (pin 1 on > DB-9) > > > with the 1PPS signal > > > > > > > > back in the day when that tied directly to an interrupt with consistent > > latency, that works pretty well. > > > > > > These days, though, there's often USB hosts in the way, or some other > > intermediate interfaces that increases the uncertainty in timing of > > "when software does something" in response to "external event" > > > > > > _______________________________________________ > > time-nuts mailing list -- time-nuts@lists.febo.com > > To unsubscribe send an email to time-nuts-leave@lists.febo.com > _______________________________________________ > time-nuts mailing list -- time-nuts@lists.febo.com > To unsubscribe send an email to time-nuts-leave@lists.febo.com

entation Scott On Mon, Jan 30, 2023 at 8:15 PM Trent Piepho wrote: > Even if you have a real serial port, still common in embedded SoCs that > run Linux if not on PCs, and even if it still has a CD line to generate an > interrupt, there are still issues. > > Modern CPUs are complex, and while the serial port might even be on the > same chip as the CPU, they are connected through an internal network like > an AXI bus that adds latency and jitter. A PCI-E network card generating > an interrupt still needs to send a MSI packet over the PCI-E network bus to > the PCI-E controller, which then needs to send it on the CPU through some > other kind of internal network. > > But that's not even the bad part. Once the CPU gets an interrupt, there > is still a lot of stuff that needs to happen in software before a timestamp > is generated. The CPU must context switch, new cachline loads from RAM for > data and code, the base kernel interrupt dispatching, etc. > > With tests I did a while back with GPS PPS on an embedded Linux board, > this was the largest source of error. > > Despite hardware timestampers being common on microcontrollers, SoCs that > can run Linux never seem to have them. > > I wonder if one could make a useful USB timestamper with a common USB > microcontroller board. These have hardware counters that can timestamp a > PPS. It would be easy to send these timestamps over USB. Not sending > events about a PPS, but sending the actual timestamp of the PPS. USB has, > comparatively, terrible timing jitter, so timestamping the arrival of a USB > packet is of course no good. > > With a bit of thought, we might think this is a step back. We have GPS > with an accurate clock that sends NMEA timestamps to us over an inaccurate > UART. Now we have a microcontroller with a semi-accurate clock sending > timestamps to us over an even more inaccurate USB interface. Same problem, > but worse. > > But there is a difference! Typically the clock in an USB connected > microcontroller can use USB clock recovery. It's disciplined to the 1kHz > USB SOF signal from the host computer. This lets them meet the USB timing > spec with a cheap internal resonator. > > So the clock in the microcontroller that gives us timestamps is in fact > tracking our clock. Does that make a difference? We can infer that the > error in the timestamps we get reflects a matching error in the host clock > we are trying to discipline with the PPS. > > On Mon, Jan 30, 2023 at 4:01 PM S McGrath via time-nuts < > time-nuts@lists.febo.com> wrote: > >> Driving Pin1 only works with a ‘real’ serial port on a dedicated IRQ. a >> USB interface will add unpredictable latency >> >> On Mon, Jan 30, 2023 at 6:16 PM Lux, Jim via time-nuts < >> time-nuts@lists.febo.com> wrote: >> >> > On 1/30/23 12:28 PM, S McGrath via time-nuts wrote: >> > > Most common way of getting 1PPS into a computer without a dedicated >> 1PPS >> > > interface is to drive a RS-232 port’s Carrier Detect pin (pin 1 on >> DB-9) >> > > with the 1PPS signal >> > >> > >> > >> > back in the day when that tied directly to an interrupt with consistent >> > latency, that works pretty well. >> > >> > >> > These days, though, there's often USB hosts in the way, or some other >> > intermediate interfaces that increases the uncertainty in timing of >> > "when software does something" in response to "external event" >> > >> > >> > _______________________________________________ >> > time-nuts mailing list -- time-nuts@lists.febo.com >> > To unsubscribe send an email to time-nuts-leave@lists.febo.com >> _______________________________________________ >> time-nuts mailing list -- time-nuts@lists.febo.com >> To unsubscribe send an email to time-nuts-leave@lists.febo.com > >

pins: > No soldering on the main apu board. If you are interested, I can send you > the gerber-files and BOM. It should also fit the apu3-series (and possibly > yours, too) and allows convenient SMA-access through the front panel to > the SDP pins of two of the NICs. This sounds really interesting and looks like it would be a nice option for a small-form factor NTP/PTP server. I would love to be able to buy one of these. Are there companies that will take a gerber file and a BOM and a modest amount of money, and send me a completed PCB? (I am a software person, and know very little about the hardware side of things.) > As I > wanted to verify that the lock is working, and maybe later use the PHC also > for PTP, I also wanted the PHC to follow the external time, I also wanted this. > Therefore it seems that a two-step approach works better: First I make sure > that using ts2phc the PHC is locked to the 100ms-1PPS input on SDP0: > > # ----------[contents of /etc/linuxptp/ts2phc.conf]------------------------- > # run with ts2phc -c eth3 -s generic -l 7 -f /etc/linuxptp/ts2phc.conf -m -q I have found it quite tricky to get this approach to startup robustly. There's a dependency circularity: - ts2phc -s generic depends on chrony to have set the system clock - chrony with the PHC refclock depends on ts2phc to have set the PHC I have tried a couple of approaches to deal with this. phc2sys has a -E ntpshm option. With this option, instead of phc2sys modifying the system clock directly, it feeds samples into the SHM used by the chrony SHM refclock. This provides a bit more flexibility over using the chrony PHC refclock directly: if phc2sys is not running then chrony will ignore the SHM refclock. We can then startup in stages: 1. Run chrony with the SHM refclock; do not yet start phc2sys -E ntpshm. Chrony will then set the system time using other NTP servers or using the NMEA messages from a GPS receiver via gpsd if there is no network connectivity (which would mean the time is very rough). 2. Run ts2phc -s generic. This will set the PHC very accurately, using the less accurate system time from chrony. 3. Start phc2sys -E ntpshm. Now that the PHC is correct, we can let chrony use the samples from the PHC. Another approach is to use a pps option (not the extpps option) with the PHC refclock. This will make chrony ignore the time-of-day information in the PHC, and just use the PPS information. > For this to start up properly, you need to make sure the clocks are roughly correct, > i.e. you need to set your system time (e.g. with ntpdate, ntp, chrony) and then > sync your PHC to system time by letting > > # Locking the PHC of eth3 (ptp3) to CLOCK_REALTIME > phc2sys -c eth3 -s CLOCK_REALTIME -O +37 -m -q > > run for a few seconds. As far as I remember, ts2phc can handle the PHC being wrong. If you want to do a one-shot setting of the PHC from the system clock, you can do phc_ctl eth0 "set;" adj 37 This works immediately, although it is not as accurate as phc2sys. > The intel cards always give timestamp events on both pulse edges. The pulse-width and > the roughly correct clock are necessary such that ts2phc can ignore the wrong pulse edge. > From the source code it seems that ts2phc only considers edges falling within ±pulsewidth/2 > around the expected time valid and discards the rest. So for a 100ms-1PPS pulse you should > get the clock precise to 50ms before you start. As my pps is originally only µs long, I needed extra > hardware to stretch it. I am writing code (which will be released as open source) that amongst other things tries to deal better with receiving timestamp events for both pulse edges. Does the i210/i211 generate two events for the original µs pulse? In your use case, do you have a GPS receiver providing time-of-day information or do you just have the PPS? James

tions, its not good enough for a ‘time nuts’ > implementation I daresay that finding a motherboard with a "real" serial port is pretty challenging. And even if you plugged in a serial expansion card of some sort, modern mobos probably aren't going to have a clean deterministic IRQ behavior. The idea of a (potentially inexpensive) standalone box that can do it is intriguing.  But we started with networking - So what is being discussed is something like a USB Ethernet dongle with time stamping.

f seems to indicate otherwise, saying: > > > width width > > This option specifies the width of the pulses (in seconds). It is used to filter PPS samples when > > the driver provides samples for both rising and falling edges. Note that it reduces the maximum > > allowed error of the time source which completes the PPS samples. If the duty cycle is > > configurable, 50% should be preferred in order to maximise the allowed error. > > which, maybe incorrectly, implied to me that there was no smarts for highly asymmetric > pulse-to-not-pulsing time. I think your analysis is correct, since https://chrony.tuxfamily.org/examples.html#_server_using_reference_clock_on_nic says "The offset option of the SHM 0 refclock compensates for the delay of messages received on the USB port. It needs to be measured carefully, e.g. against a known good NTP server. A wrong offset could cause the server to be off by an integer multiple of 62.5 milliseconds (1/16s)." I've been writing a program to sync the PHC from a GPS and it includes the obvious smarts to distinguish the rising and falling edges based on the time between. I have been testing with the i210 and it seems to work fine. With these smarts, 50% duty cycle is the worst possible configuration, since it prevents the smarts from working. James

s from a decade ago or > so (model 107224, but finding them could be fun) that have (on SMA > connectors) PPS in & out, which were there to get PPS in or out of > PTP. > > Cheers > _______________________________________________ > time-nuts mailing list -- time-nuts@lists.febo.com > To unsubscribe send an email to time-nuts-leave@lists.febo.com

lutions/gtcf21/networking/data-processing-unit/gtc-fall-21-networking-overall-dpu-technical-overview-firefly.pdf I'm really interested in precision PTP over Ethernet over fiber. Kinda related... Meta is looking at timebeat and I recently posted about the new cards they're selling with MEMS DCOCXO SiT5721 for holdover. https://engineering.fb.com/2022/11/21/production-engineering/precision-time-protocol-at-meta/#network Seems the future of Ethernet timing sync time stamping is developing well right now. Fiber is the way to go though. Bill On Mon, Jan 30, 2023, 9:18 PM Lux, Jim via time-nuts < time-nuts@lists.febo.com> wrote: > On 1/30/23 5:31 PM, S McGrath via time-nuts wrote: > > All your points are good ones, My point was this is the common lowest > > cost approach, better approaches exist and they range from tens of > dollars > > to thousands depending on the accuracy needed. > > > > Driving the CD line with a ‘real’ serial port is good enough for > ‘standard’ > > NTP timing applications, its not good enough for a ‘time nuts’ > > implementation > > > I daresay that finding a motherboard with a "real" serial port is pretty > challenging. And even if you plugged in a serial expansion card of some > sort, modern mobos probably aren't going to have a clean deterministic > IRQ behavior. > > The idea of a (potentially inexpensive) standalone box that can do it is > intriguing. But we started with networking - So what is being discussed > is something like a USB Ethernet dongle with time stamping. > > > _______________________________________________ > time-nuts mailing list -- time-nuts@lists.febo.com > To unsubscribe send an email to time-nuts-leave@lists.febo.com

order, and I plan to put a mini PCIe GNSS receiver in it - of course, the options for miniPCIe GNSS receivers are pretty bad, so I've designed my own and should get them in two weeks or so, but I am very interested in coupling one with your design for a very tidy solution that doesn't require soldering. Compiling testptp with a static library worked, of course, and I'm a little bit disappointed in myself for not thinking of this - I'm pretty rusty at this, go figure. In any case, it seems to be working fine - most of the time. I can use it to list capabilities, list pin configuration, and set/get PTP time, no problem, and I can see that SDP0 is configured for "external time stamp". Sometimes when I try and run it to view timestamp events (e.g. ./testptp -e 10) I get a cryptic "device in use" type error but I'm not quite sure what is hanging it up. In the following command: > ts2phc -c eth3 -s generic -l 7 -f /etc/linuxptp/ts2phc.conf -m -q i assume the contents of ts2phc.conf are the "[global] ... " that you posted below it, is that correct? Thanks very much for all your info, this is very exciting! Regards, John > On Feb 2, 2023, at 1:32 PM, Jürgen Appel via time-nuts wrote: > > Dear John, > > On Wednesday, 1 February 2023 19:38:18 CET John Miller via time-nuts wrote: > >> Hi Matt, >> This is excellent information, thank you - after reading through all the >> responses in the thread (wow, this is a wild topic!) and trawling around >> online a bit, I think that using the SDP pins on the i210 to feed a PPS >> signal into an x86 PC is what I want to do right now. > >> I have read Dan Drown's blog post on using the APU2 to achieve this, and >> while it's more or less exactly what I want to replicate, for now, there >> are a few gaps I need to fill in - and you may be able to help me do so. I >> don't have a PC Engines APU2 board yet, but I suspect I'll order one once I >> have the software side of things ironed out, because I really like their >> form factor. > > I'm currently testing an APU6b4 unit and made a small adaptor PCB that gets > clicked into the Mini-PCIE slot and touches to the main pcb via some pogo-pins: > No soldering on the main apu board. If you are interested, I can send you > the gerber-files and BOM. It should also fit the apu3-series (and possibly > yours, too) and allows convenient SMA-access through the front panel to > the SDP pins of two of the NICs. > >> What I'm using right now is a Portwell NANO-6050[1], and it has i210 and >> i218 NICs. The SDP pins on the i210 aren't broken out into nice pads like >> the APU2 has, but with some magnet wire and a steady hand I was able to >> connect directly to one of the pins. Where I am struggling right now is >> ironing out the software configuration side of things. I'm not interested >> at all in PTP yet, right now the focus is purely on feeding the PPS into >> chrony via the SDP pins. > >> The GNSS I'm using is a Sparkfun uBlox NEO-M9N >> GNSS receiver in its default configuration, connected to the computer over >> USB. PPS pin connected to the i210's SDP0. PPS pulse is 3v3 for 100ms. > That should work fine. > >> I have tried using refclock strings from chrony's examples page[2] as a >> jumping-off point, but it doesn't make much sense to me. > > To me it seems that chrony is just using the timestamps on the PHC of that > network interface and not actually locking the PHC to the PPS input. As I > wanted to verify that the lock is working, and maybe later use the PHC also > for PTP, I also wanted the PHC to follow the external time, and running > both chrony and phc2sys to make the phc follow system time ended in chaos. > > Therefore it seems that a two-step approach works better: First I make sure > that using ts2phc the PHC is locked to the 100ms-1PPS input on SDP0: > > # ----------[contents of /etc/linuxptp/ts2phc.conf]------------------------- > # run with ts2phc -c eth3 -s generic -l 7 -f /etc/linuxptp/ts2phc.conf -m -q > [global] > use_syslog 0 > verbose 1 > logging_level 6 > ts2phc.pulsewidth 100000000 > max_frequency 1000000 > step_threshold 0.05 > [eth3] > ts2phc.channel 0 > ts2phc.extts_polarity both > ts2phc.pin_index 0 > ts2phc.extts_correction -32 > > For this to start up properly, you need to make sure the clocks are roughly correct, > i.e. you need to set your system time (e.g. with ntpdate, ntp, chrony) and then > sync your PHC to system time by letting > > # Locking the PHC of eth3 (ptp3) to CLOCK_REALTIME > phc2sys -c eth3 -s CLOCK_REALTIME -O +37 -m -q > > run for a few seconds. > > If you also output the PHC timer on SDP1 by > testptp -d /dev/ptp3 -L1,2 -p 1000000000 > you can see a falling edge right when SDP0 has a rising edge input > with only a few nanoseconds jitter. > (if anyone know how to invert the 1PPS output on i211 interfaces, let me know...) > Sidenote: The interfaces /sys/class/ptp/* seem to be broken with my kernel. > I can configure PPS output there, but every time I do that I get random > frequencies for ~10 seconds before the output actually starts... > > > When the PCH is locked to the 1PPS, I can have chrony use the PHC as clock input > with this chrony.conf line: > > refclock PHC /dev/ptp3 tai refid PTP3 dpoll -4 poll -2 > > I do _not_ use the "extpps" option here, as ts2phc is already reading and consuming > the time stamps. If there are two time-stamp readers, my chrony just hangs. > >> I have not been able to use the testptp tool on this system yet - building >> it on another machine and running the copied-over executable fails, citing >> too old a version of glibc, and when I try and build it locally it fails >> for reasons that are unknown to me (I am very much not a C developer). > > Maybe try making a static library: gcc -static testptp.c -o testptp > so that it has it's current glibc version linked in. > >> I am going to continue to fiddle with this - I think getting testptp working >> such that I can verify that I'm actually getting a pulse on SDP0 is the >> most important thing to confirm right now. > > The intel cards always give timestamp events on both pulse edges. The pulse-width and > the roughly correct clock are necessary such that ts2phc can ignore the wrong pulse edge. > From the source code it seems that ts2phc only considers edges falling within ±pulsewidth/2 > around the expected time valid and discards the rest. So for a 100ms-1PPS pulse you should > get the clock precise to 50ms before you start. As my pps is originally only µs long, I needed extra > hardware to stretch it. > > The result: > > watch -n 0.5 'chronyc -m "sources -v" "sourcestats -v" "selectdata -v"' > > .-- Source mode '^' = server, '=' = peer, '#' = local clock. > / .- Source state '*' = current best, '+' = combined, '-' = not combined, > | / 'x' = may be in error, '~' = too variable, '?' = unusable. > || .- xxxx [ yyyy ] +/- zzzz > || Reachability register (octal) -. | xxxx = adjusted offset, > || Log2(Polling interval) --. | | yyyy = measured offset, > || \ | | zzzz = estimated error. > || | | \ > MS Name/IP address Stratum Poll Reach LastRx Last sample > =============================================================================== > #* PTP3 0 -2 377 0 +2ns[ +2ns] +/- 195ns > ^- sth1-ts.nts.netnod.se 1 8 377 83 -449us[ -450us] +/- 5331us > ^- sth2-ts.nts.netnod.se 1 8 377 213 -461us[ -463us] +/- 5322us > ^? ptbtime1.ptb.de 1 8 377 21 -46us[ -46us] +/- 5489us > ^? ptbtime2.ptb.de 1 7 377 19 -60us[ -60us] +/- 5505us > ^- polarx5tr.time.internal 1 8 377 147 -41us[ -43us] +/- 12ms > .- Number of sample points in measurement set. > / .- Number of residual runs with same sign. > | / .- Length of measurement set (time). > | | / .- Est. clock freq error (ppm). > | | | / .- Est. error in freq. > | | | | / .- Est. offset. > | | | | | | On the -. > | | | | | | samples. \ > | | | | | | | > Name/IP Address NP NR Span Frequency Freq Skew Offset Std Dev > ============================================================================== > PTP3 9 7 2 +0.000 0.005 +0ns 2ns > sth1-ts.nts.netnod.se 25 11 31m +0.060 0.044 -483us 28us > sth2-ts.nts.netnod.se 22 10 29m +0.097 0.031 -419us 16us > ptbtime1.ptb.de 25 12 32m +0.071 0.031 -43us 23us > ptbtime2.ptb.de 21 5 23m +0.097 0.053 -5339ns 26us > polarx5tr.time.internal 25 14 30m +0.038 0.153 -41us 104us > .-- State: N - noselect, M - missing samples, d/D - large distance, > / ~ - jittery, w/W - waits for others, T - not trusted, > | x - falseticker, P - not preferred, U - waits for update, > | S - stale, O - orphan, + - combined, * - best. > | Effective options ------. (N - noselect, P - prefer > | Configured options -. \ T - trust, R - require) > | Auth. enabled (Y/N) -. \ \ Offset interval --. > | | | | | > S Name/IP Address Auth COpts EOpts Last Score Interval Leap > ======================================================================= > * PTP3 N ----- --TR- 0 1.0 -194ns +199ns N > D sth1-ts.nts.netnod.se Y ----- --TR- 83 1.0 -5780us +4891us N > D sth2-ts.nts.netnod.se Y ----- --TR- 213 1.0 -5769us +4888us N > T ptbtime1.ptb.de N ----- ----- 20 1.0 -5515us +5458us N > T ptbtime2.ptb.de N ----- ----- 19 1.0 -5564us +5448us N > D polarx5tr.time.internal N --TR- --TR- 147 1.0 -12ms +11ms N > > > Cheers, > Jürgen > _______________________________________________ > time-nuts mailing list -- time-nuts@lists.febo.com > To unsubscribe send an email to time-nuts-leave@lists.febo.com

/pps-gmtimer was the closest fork to working for me, but it still required some fiddling around with DeviceTree etc. ). It tries to pull the somewhat clever trick of switching the system's clock source to the capture timer, and then copying the capture value directly into the PPS report, which in theory should be about as good a capture as you could get - no polling the kernel timestamp or the input pin. I've been running this for a while with a GPSDO as PPS source, and while the average offset reported by chrony is single-digit ns, there are occasional spikes to 100s of ns. The NIC also does have hardware timestamping functionality for PTP. On Mon, 30 Jan 2023 at 18:26, Trent Piepho via time-nuts < time-nuts@lists.febo.com> wrote: > Even if you have a real serial port, still common in embedded SoCs that run > Linux if not on PCs, and even if it still has a CD line to generate an > interrupt, there are still issues. > > Modern CPUs are complex, and while the serial port might even be on the > same chip as the CPU, they are connected through an internal network like > an AXI bus that adds latency and jitter. A PCI-E network card generating > an interrupt still needs to send a MSI packet over the PCI-E network bus to > the PCI-E controller, which then needs to send it on the CPU through some > other kind of internal network. > > But that's not even the bad part. Once the CPU gets an interrupt, there is > still a lot of stuff that needs to happen in software before a timestamp is > generated. The CPU must context switch, new cachline loads from RAM for > data and code, the base kernel interrupt dispatching, etc. > > With tests I did a while back with GPS PPS on an embedded Linux board, this > was the largest source of error. > > Despite hardware timestampers being common on microcontrollers, SoCs that > can run Linux never seem to have them. > > I wonder if one could make a useful USB timestamper with a common USB > microcontroller board. These have hardware counters that can timestamp a > PPS. It would be easy to send these timestamps over USB. Not sending > events about a PPS, but sending the actual timestamp of the PPS. USB has, > comparatively, terrible timing jitter, so timestamping the arrival of a USB > packet is of course no good. > > With a bit of thought, we might think this is a step back. We have GPS > with an accurate clock that sends NMEA timestamps to us over an inaccurate > UART. Now we have a microcontroller with a semi-accurate clock sending > timestamps to us over an even more inaccurate USB interface. Same problem, > but worse. > > But there is a difference! Typically the clock in an USB connected > microcontroller can use USB clock recovery. It's disciplined to the 1kHz > USB SOF signal from the host computer. This lets them meet the USB timing > spec with a cheap internal resonator. > > So the clock in the microcontroller that gives us timestamps is in fact > tracking our clock. Does that make a difference? We can infer that the > error in the timestamps we get reflects a matching error in the host clock > we are trying to discipline with the PPS. > > On Mon, Jan 30, 2023 at 4:01 PM S McGrath via time-nuts < > time-nuts@lists.febo.com> wrote: > > > Driving Pin1 only works with a ‘real’ serial port on a dedicated IRQ. a > > USB interface will add unpredictable latency > > > > On Mon, Jan 30, 2023 at 6:16 PM Lux, Jim via time-nuts < > > time-nuts@lists.febo.com> wrote: > > > > > On 1/30/23 12:28 PM, S McGrath via time-nuts wrote: > > > > Most common way of getting 1PPS into a computer without a dedicated > > 1PPS > > > > interface is to drive a RS-232 port’s Carrier Detect pin (pin 1 on > > DB-9) > > > > with the 1PPS signal > > > > > > > > > > > > back in the day when that tied directly to an interrupt with consistent > > > latency, that works pretty well. > > > > > > > > > These days, though, there's often USB hosts in the way, or some other > > > intermediate interfaces that increases the uncertainty in timing of > > > "when software does something" in response to "external event" > > > > > > > > > _______________________________________________ > > > time-nuts mailing list -- time-nuts@lists.febo.com > > > To unsubscribe send an email to time-nuts-leave@lists.febo.com > > _______________________________________________ > > time-nuts mailing list -- time-nuts@lists.febo.com > > To unsubscribe send an email to time-nuts-leave@lists.febo.com > _______________________________________________ > time-nuts mailing list -- time-nuts@lists.febo.com > To unsubscribe send an email to time-nuts-leave@lists.febo.com