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

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 <strom...@nexgo.de> 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 -- time-nuts@lists.febo.com
To unsubscribe, go to
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

_______________________________________________
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.



_______________________________________________
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

Reply via email to