On 12.07.2020 3:57, jimlux wrote:
On 7/11/20 1:30 PM, Steven Sommars wrote:
Using GPIO with an RPi is a good direction, of course. That wasn't my
question. Some data may help explain.
Configuration =
RPi4 (raspbian buster)
Uputronics RPi GPS board (includes PPS) connected to GPIO pins.
This
is the time of day source for the RPi4. (via GPSD+chrony).
Navisys USB GR701 (includes PPS and Integrated serial->USB
conversion). Contains integrated Prolific Technology, Inc. PL2303
The observed PPS variation on the Uputronics PPS is a few microseconds.
(ppstest was used for measurements). Using a PPS to drive NTP's computer
clock disciplining, which is in turn used to measure the same PPS
makes for
a dubious circular measurement. It is comforting though to see that
the
variance is in the ~1-3 microsecond range. One must also add Trent's
interrupt latency measurement (3 microseconds). With the GPIO
connection
the RPi time base should be within say 10 microseconds of UTC.
The USB-connected Navisys fares worse.
[image: image.png]
By the time the PPS reaches the OS there is about 1 msec of variance with
an average offset of a bit over 0.6 msec.
I suspect the 1 msec USB polling is the largest latency contributor,
though
there are other sources as mentioned by Tim.
I'd like to reduce the USB polling contribution by polling at 125
microseconds as the Linux PPS folks suggest
(http://linuxpps.org/doku.php/technical_information) Would an
FTDI-based
USB convertor do the trick?
Why bother with GPS/USB? Sometimes I use laptops. Few laptops today
directly support PPS/serial.
I just checked with Dell and found zero laptops with native RS232.
I would not expect another kind of USB to serial converter to do better.
The problem is higher up in the way that Linux handles USB devices. The
USB hardware can certainly handle higher rates (and does), but the
"software interrupts" as the event travels up the stack limits the
timing resolution.
I beg to differ. With correct USB convertor I achieve sub millisecond
variance (see attached screenshot fro FTDI232RL chip). I get similar
results on other computers too.
All Prolific chips I saw claimed to be USB 2.0 Full-speed. That means
they are polled only once in 1ms and there is no way how to change it
(poll rate is selected at hardware level).
Petr Titera
You might want to look into one of the "real time" linux kernels or
other similar implementations - they might have "turned some of the
knobs" to improve the handling of device data.
USB device handling in Linux (and Windows, and Mac OSX) is quite
complex, if only because USB itself is quite complex in that it has to
support multiple "kinds" of devices with wildly varying properties (HID,
Mass Storage, Isochronous data, etc.) - Not to mention all the
complexities associated with hot plugging and unplugging and
"enumeration" and "power control".
You might also want to delve into the handling of USB request Blocks
(URBs) which is how Linux handles USB related events.
https://www.oreilly.com/library/view/linux-device-drivers/0596005903/ch13.html
https://www.kernel.org/doc/html/v4.12/driver-api/usb/index.html
The above document describes a variety of ways to get at USB devices in
non-standard ways, through the USB API.
Another interesting alternative might be to modify the low level
interrupt handler for your Prolific chip (or whatever you're using) -
you could probably snapshot the system timer in the IRQ. But then you're
faced with the challenge of propagating that time to where you need it,
and hopefully in a way that doesn't break Linux.
In any case, your problem is not that it's USB. Your problem is that
Linux has some compromises in how it handles USB devices that
essentially imposes a 1kHz quantization on it.
There is a reason why USB support was late in coming to Linux compared
to other devices. And there's a reason why everyone curses at serial
interfaces, particularly over USB. Their character at a time behavior
fits real well for read() and write() in most OSes, but the ioctl() call
tends to be very, very complex. And getting high speed or deterministic
behavior is always a challenge.
I feel your pain. All of my serial interfaces stopped working when I
went from Mavericks to Mojave... I finally got a SiLabs interface
working, and one instance of a FTDI device. The Prolific PL2303, not
yet. I was seriously contemplating making Ethernet to USB interfaces on
an Arduino, where there's no OS involved.
I have so many pieces of equipment with USB interfaces, all a bit
different, all sort of using a serial port model.
_______________________________________________
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.
