Driving the NTP software from a GPS w/PPS requires 1) bringing the NMEA (typically) bytes to the computer. Timing is not critical, USB polling at 1 msec is fine. 2) bringing the PPS signal into the computer *is *timing critical. There's only one bit of information.
If the PPS is brought to a RPi GPIO pin, then PPS timing involves interrupt latency/jitter. This is in the microsecond range on an RPi, I'm told. If the PPS is connected to RS232 DCD pin (this is common) and connected to a computer with a native RS232 connection, we're again dealing with interrupt latency/jitter. See David Taylor's GPS wiring diagram https://www.satsignal.eu/ntp/FreeBSD-GPS-PPS.htm If the PPS is connected to RS232 DCD pin, and then that RS232 signal is fed to the computer (e.g., RPi) via RS232-USB conversion, the PPS accuracy is dominated by the USB polling time. Note: The typical GPS PPS signal level isn't a direct match for RS232. In practice it works well. On Thu, Jul 9, 2020 at 1:33 PM jimlux <[email protected]> wrote: > On 7/9/20 2:14 AM, Petr Titěra wrote: > > Just one note. Most USB to serial chip claim USB2.0 support but they > > only provide Full-Speed data transfers. That is data communication > > protocol based on USB1.1 parameters with 1ms polling interval. You have > > to specifically look for High-Speed (i.e 480mbps) transfers when going > > trough chip specification. Not all manufacturers have such chips and no > > all chips from manufacturers who provide them have such capability. > > > > To this day I was able to find only one such chip family and that is > > FTDI FT232H (that H suffix specifies High-Transfer rate). > > > > Petr Titera > > > I suspect the 1ms is not limited by the chip (after all, they all have > to support 8kHz schedules for isochronous audio, even if the serial port > doesn't use it). > > I suspect it's more an artifact of how Linux (or whatever) OS deals with > the interrupt handling. Linux isn't designed as a "real time fast > response" operating system. It depends on devices doing big transfers, > so a 1 ms response time is fine. > > That is, you set up a DMA transfer to a disk drive at 100 Mbps, but > since you're transferring 100 kByte buffers, you only need to service > the event 125 times/second. > > You'll easily see this on high speed serial links through USB if you do > "character at a time" operations. You cannot get 50kbps with character > at a time with buffer flushes between characters. > > Try it with a USB serial dongle and a loopback from TxD to RxD. > > > Most serial software that runs at high speed (>9600 bps) assumes a > slightly smarter device (maybe a 16550 style) with a FIFO, so it > "bursts" bytes to/from the device. Rather than hang a "read one > character" io call, they'll do a "read up to N characters, with a > timeout of 10 milliseconds" and put that in the loop instead. > Similarly, they'll accumulate characters to be sent, and do the io_write > call with all the characters in the buffer. > > I've done a fair amount of high speed USB serial stuff between arduinos > and PCs, and you always wind up with some scheme for buffering on both > sides. > > > Since you're not going to be transferring (batches of) bytes any more > frequently than 1 millisecond, there's not much point in sending the > "modem control" signals (RTS/CTS) through faster. Any high speed > protocol handler has to account for the fact that if RTS/CTS handshaking > is implemented, you can't overrun the transmit FIFO - That is, if the > far end drops CTS, the near end doesn't send, and bytes pile up in the > FIFO. So you just need to tell the device driver to stop sending soon > enough that the FIFO doesn't overflow. If the FIFO is, e.g., 16 deep, > and you're sending at 56 kbps (7 kBytes/sec), the FIFO will overflow in > about 2 milliseconds. So a 1 millisecond response time to the CTS > changing state is fine. > > For the other modem control signals (RI, CD, DSR, DTR) they're even > slower. DSR and DTR are basically "my power is on" and don't change > state. RI is "seconds" - the signal the modem is detecting is a 20Hz > audio tone. CD is likewise "many milliseconds" depending on the > modulation being used. A Bell 103 or 202 is a hundreds of bits/second > device, so carrier acquisition/detect is typically 10s of bit times. For > fancier modems with multitone signalling and coding, it could be many > seconds for the speed negotiation to complete. > > TL;DR - there's no reason for a USB-Serial adapter manufacturer to have > a faster than 1ms response time, nor for an operating system to be > faster than 1ms. > > > > > > > > On 08.07.2020 22:02, Steven Sommars wrote: > >> My RPi4 (Raspbian Buster) has a GPS+PPS/USB. Serial->USB uses Prolific > >> PL2303, which supports USB 2.0 > >> The PPS jitter is 1 msec (e.g., using ppstest). lsusb -v shows: > >> > >> Bus 001 Device 008: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial > >> Port > >> bInterval 1 > >> > >> which means 1 msec polling of the PPS signal. I've been unable to poll > >> more frequently, that seems to require driver changes. > >> Petr, what polling rate do you see? Has anyone been able to poll USB > @ > >> 125 µsec on a stock RPi? > >> > >> With the 1 ms polling the PPS reaches the OS between 0 and 1 ms late, > >> in an > >> unpredictable pattern. Although the PPS jitter is 1 msec, > >> ntpd/chrony on > >> my RPi4 typically reports low dispersion: 50-150 µsec. The zero-mean > >> assumption Achim mentioned is unlikely to be valid. Running chrony + > >> GPS+PPS/USB I see a ~640µsec offset compared to a GPS+PPS directly > >> connected to the GPIO pins. That offset will fluctuate, of course. > >> > >> Steve Sommars > >> > >> > >> > >> > >> > >> On Wed, Jul 8, 2020 at 12:57 PM ASSI <[email protected]> wrote: > >> > >>> On Dienstag, 7. Juli 2020 18:27:01 CEST Petr Titěra wrote: > >>>> Timing on USB need not to be so horrible. Below is stats from my > server > >>>> with GPS connected using FT232H chip (supporting high speed > >>>> transfers on > >>>> USB). Yes, the jitter is far greater than on other computer where > >>>> PPS is > >>>> connected directly but it is a lot less than that 500microseconds you > >>>> get with common USB convertors. > >>>> > >>>> remote refid st t when poll reach delay offset > >>>> jitter > >>>> > ======================================================================= > >>>> o127.127.22.0 .PPS. 0 u 7 16 377 0.000 -0.019 > 0.033 > >>>> *192.168.3.240 .GPSD. 1 u 24 64 377 0.377 0.187 > 0.026 > >>>> +192.168.3.246 .PPS. 1 u 28 64 377 0.643 0.181 > 0.028 > >>> > >>> The reason you're seeing this with the newer FTDI chips that support > >>> USB2.0 > >>> highspeed rates is that the frame rate got increased 8x for highspeed > >>> USB, > >>> so > >>> the expected frame jitter is now 125µs when and if the interface as > well > >>> as > >>> the full protocol stack support and enable it. But you seem to have > >>> missed > >>> the point that Hal was trying to make: The jitter you are going to > >>> see has > >>> deterministic components and some of these can create bias when you > >>> try to > >>> filter with the usual assumption of a stationary zero-mean random > >>> sampling. > >>> In other words, you don't necessarily converge to the true time and > >>> where > >>> your > >>> filter tries to converge varies over time. > >>> > >>> > >>> Regards, > >>> Achim. > >>> -- > >>> +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ > >>> > >>> DIY Stuff: > >>> http://Synth.Stromeko.net/DIY.html > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> time-nuts mailing list -- [email protected] > >>> To unsubscribe, go to > >>> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com > >>> and follow the instructions there. > >>> > >> _______________________________________________ > >> time-nuts mailing list -- [email protected] > >> To unsubscribe, go to > >> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com > >> and follow the instructions there. > >> > > > > > > _______________________________________________ > > time-nuts mailing list -- [email protected] > > To unsubscribe, go to > > http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com > > and follow the instructions there. > > > _______________________________________________ > time-nuts mailing list -- [email protected] > To unsubscribe, go to > http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com > and follow the instructions there. > _______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
