[LinuxPPS] PPS via FTDI 232 doesn't work, many questions

[Cirilo Bernardo]

On Fri, Nov 18, 2011 at 6:48 AM, Ben Adler
<adler at informatik.uni-hamburg.de> wrote:
> Hello list!
>
> I'm trying to get Linux PPS working on an embedded system running ubuntu
> 10.10 with linux 2.6.35. Although I'd love to use a real UART, parallel
> port or GPIO pin, the board only features USB ports and two serial ports
> behind an FTDI 232RL USB<->RS232 converter.
>
> Instead of the GPS device, for now a function generator is connected to
> the DCD line of /dev/ttyUSB1, and its signal goes from high (5V) to low
> (0V) every second, staying low for about 100msec.
>
> On the same port, RX and TX are shorted, so when I open minicom and hold
> down a key, I see it printed repeatedly, with the online-indicator in
> the lower-right corner jumping from OFFLINE to ONLINE and back every
> second for 100msec - but only as long as I hold down any key.
>
> For low latency on the usb-serial-port, I check
> $ cat /sys/bus/usb-serial/devices/ttyUSB1/latency_timer
> 1
>
> I thought 16ms was the default, but this value is always 1 on my system.
> Even if I write e.g. 16 into it, it stays 1. The value is the amount of
> milliseconds that bytes are allowed to stay in FTDI232's buffer before
> being passed on to the host.
>

The USB specification requires that all devices are polled once per
millisecond, and if there is a response then the device can send many
data packets in the allowed period.

> # modprobe pps_core
> dmesg says:
> [  223.190630] LinuxPPS API ver. 1 registered
> [  223.190639] Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo
> Giometti <giometti at linux.it>
>
> # ldattach -d PPS /dev/ttyUSB1
> ldattach:opened /dev/ttyUSB1
> ldattach:set to raw 0 ---: cflag=0xcbd
> ldattach:line discipline set to 18
>
> dmesg says:
> [  277.853871] PPS line discipline registered
> [  277.854707] new PPS source usbserial1 at ID 0
> [  277.854762] PPS source #0 "/dev/ttyUSB1" added
>
> # ls -l /dev/pps*
> crw------- 1 root root 250, 0 2011-11-17 17:54 /dev/pps0
>
> # setserial /dev/ttyUSB1 hardpps
> # setserial /dev/ttyUSB1
> /dev/ttyUSB1, UART: unknown, Port: 0x0000, IRQ: 0, Flags: hardpps
> low_latency
>
> # ./ppstest /dev/pps0
> trying PPS source "/dev/pps0"
> found PPS source "/dev/pps0"
> ok, found 1 source(s), now start fetching data...
> time_pps_fetch() error -1 (Connection timed out)
> time_pps_fetch() error -1 (Connection timed out)
> time_pps_fetch() error -1 (Connection timed out)
> time_pps_fetch() error -1 (Connection timed out)
> ...
>
> And this is my problem, the last line is repeated forever.
> # cat /sys/class/pps/pps0/assert always contains:
>
>     0.000000000#0
>
> and nothing ever happens. So, my questions are:
>
>  - Why isn't this working?
>

The port must be opened, so use minicom in a different virtual
terminal and open the port. As soon as you quit minicom, the driver
essentially disables the device.

>  - Is it possible to use /dev/ttyUSB1 for other communications while
> its CD line is used for PPS? Can I simply use the port as if it weren't
> used already? I gather that people usually use RX and TX for NMEA to
> sync the non-second parts of time, but my clock is already precise to
> about 20ms and I want to use PPS for even better precision.
>

No, you can't reliably multiplex the device unless you write a custom driver.

>  - What's the precision/lag I can expect when using a usb to serial
> converter? Are there any experiences?
>

USB specification requires polling once per millisecond; this means a
latency of up to 1ms. If that is good enough for your purposes then
there are no issues. It is impossible to achieve better than 1ms
precision on your PPS if you are using a USB port due to the design of
the USB protocol. (Well, not technically impossible but that would
require creating a USB-RS232 converter hardware and driver which
violate the USB specification.)

>  - Is xPPS supported, i.e. can I tell my GPS device to output PPS e.g.
> every 2,5 or 10 seconds and it'll also work?
>

That is not the purpose of PPS. I do not know the internal details of
NTP if the PPS is polled intermittently or at least every second, but
in either case the most control you could possibly have is to specify
a parameter value that affects the NTP polling.

>  - Should the PPS signal be high and dip low on every full second, or
> the other way around?
>

That depends on the specific hardware; read the manual for your FTDI
converter to see what the expected voltages are to signal the modem
line you are interested in; I think there may also be a parameter to
pass to the PPS driver in which case it will be documented. I haven't
worked with PPS for a very long time now, but as far as the UART
hardware is concerned you can usually configure whether the line will
respond to high, low, or up and down transitions. Also keep in mind
that in the original RS232 electrical specification you have +/-; with
some hardware +/0 will work, but this is not required by the
specification.


>  - How long should that pulse be? Is the answer a function of the
> port's baudrate? Can the pulse be too long?
>

The pulse cannot really be too long.  The minimum required pulse
depends on the hardware you are using; you will need to read the FTDI
documentation. One of the reasons is that some hardware is polled (in
which case the minimum duration has some relation to the bitrate
clock) while other hardware uses a different detection scheme and can
detect pulses as short as a few ns.  In all hardware I had worked
with, the duration of the GPS PPS signal is sufficient.

>  - Is the "kernel consumer" the same as "hardpps"? From what I
> understand, hardpps directly adjusts the clock in kernel-space, whereas
> using /sys/class/pps/pps0/{assert,clear} means that I'd need a running
> ntp-server to interpret these files and work the clock. Is that right?
>

Using NTP is the best way to discipline your system clock.

>  - Is the latency_timer value above also relevant for state changes on
> CD or just for data bytes?
>
>  - Is it possible for hardpps to change the status of another line X on
> the serial port after it has received a PPS signal on the CD line? I'd
> like to use this to measure the time from PPS clock on CD line to the
> status change on line X using an oscilloscope. I hope this would allow
> me to approximate a latency between the real PPS and the time hardpps
> thinks it is.
>
> These are my questions after reading about LinuxPPS for a day - I hope
> that you can enlighten me on at least a few of them. Thanks for reading
> to the end!
>
> Ben Adler
>
> _______________________________________________
> LinuxPPS mailing list
> LinuxPPS at ml.enneenne.com
> http://ml.enneenne.com/cgi-bin/mailman/listinfo/linuxpps
> Wiki: http://wiki.enneenne.com/index.php/LinuxPPS_support
>

I can't find references to "Hard PPS" (is that the old obsolete Hard
PPS project?) Anyway, to change a status line you will need to modify
the PPS driver.

- Cirilo