time-nuts@lists.febo.com

Discussion of precise time and frequency measurement

View all threads

Re: [time-nuts] ``direct'' RS-232 vs. RS-232 via USB vs. PPS decoding cards

HM
Hal Murray
Tue, Feb 14, 2017 6:42 AM

Hi, generally speaking, what are the performance differences between the
following: 1. direct RS-232 (i.e., what I believe is a standard PCI card
offering RS-232---essentially UARTs interfaced more-or-less directly to  the
PCI bus); 2. RS-232 via USB; 3. PPS decoding PCI cards (which might  also
have an IRIG input or even an onboard GNSS receiver).

You didn't say what you are trying to do.

Most OSes can grab a time-stamp when a modem control signal changes.  (I know
nothing about Windows.)

Latency will depend on the IO hardware, CPU architecture,, the interrupt
software, and what the CPU is doing: other interrupts, cache faults, and
stuff like that.

With RS-232 on PCI, the latency in the hardware should be low, as in sub
microsecond.

USB is polled.  That adds the noise/jitter of the polling interval and the
opportunities for hanging bridges.
http://www.leapsecond.com/pages/m12/sawtooth.htm
(That page shows the interaction between the PPS and the GPS receiver clock.
You get similar graphs with the interaction between PPS and USB clock.)

Most low cost RS-232/USB units are old/slow USB 1.  That polls at 1 ms.
There is at least 1 chip (FTDI FT232RL) that uses USB 2 which is 8 times
faster.
I got a breakout board (TTL levels, not RS-232) from Sparkfun.
https://www.sparkfun.com/products/12731
Adafruit has USB-RS232 version.  I haven't tried one.
https://www.adafruit.com/product/18

I don't know of any advantages of putting the GPS receiver on the PCI card.  (other than the obvious of one less lump that needs space on a shelf)

If you have custom logic on a PCI chip, it should be reasonable to get better timing.  The simple approach would be to just put a DDS style counter out there so reading the clock is as simple as an IO read.  But IO reads are slow.  There should be a way to calibrate how slow that is and then use that to calibrate normal time keeping.

albertson.chris@gmail.com said:

I said "two orders of magnitude"  it might even be three orders.

3 seems reasonable.  That's milli-second to micro-second.


I think the Linux PPS code has an option to flap a pin on the printer port when it sees a PPS.  The idea is that you can measure the latency with a scope: trigger on PPS and see how long until the printer pin changes.  I haven't tried it.

--
These are my opinions.  I hate spam.

rnabioullin@gmail.com said: > Hi, generally speaking, what are the performance differences between the > following: 1. direct RS-232 (i.e., what I believe is a standard PCI card > offering RS-232---essentially UARTs interfaced more-or-less directly to the > PCI bus); 2. RS-232 via USB; 3. PPS decoding PCI cards (which might also > have an IRIG input or even an onboard GNSS receiver). You didn't say what you are trying to do. Most OSes can grab a time-stamp when a modem control signal changes. (I know nothing about Windows.) Latency will depend on the IO hardware, CPU architecture,, the interrupt software, and what the CPU is doing: other interrupts, cache faults, and stuff like that. With RS-232 on PCI, the latency in the hardware should be low, as in sub microsecond. USB is polled. That adds the noise/jitter of the polling interval and the opportunities for hanging bridges. http://www.leapsecond.com/pages/m12/sawtooth.htm (That page shows the interaction between the PPS and the GPS receiver clock. You get similar graphs with the interaction between PPS and USB clock.) Most low cost RS-232/USB units are old/slow USB 1. That polls at 1 ms. There is at least 1 chip (FTDI FT232RL) that uses USB 2 which is 8 times faster. I got a breakout board (TTL levels, not RS-232) from Sparkfun. https://www.sparkfun.com/products/12731 Adafruit has USB-RS232 version. I haven't tried one. https://www.adafruit.com/product/18 I don't know of any advantages of putting the GPS receiver on the PCI card. (other than the obvious of one less lump that needs space on a shelf) If you have custom logic on a PCI chip, it should be reasonable to get better timing. The simple approach would be to just put a DDS style counter out there so reading the clock is as simple as an IO read. But IO reads are slow. There should be a way to calibrate how slow that is and then use that to calibrate normal time keeping. albertson.chris@gmail.com said: > I said "two orders of magnitude" it might even be three orders. 3 seems reasonable. That's milli-second to micro-second. -------- I think the Linux PPS code has an option to flap a pin on the printer port when it sees a PPS. The idea is that you can measure the latency with a scope: trigger on PPS and see how long until the printer pin changes. I haven't tried it. -- These are my opinions. I hate spam.