Re: Additional pps-gpio

Achim Gratz via devel writes: > Achim Gratz via devel writes: >> PPS line discipline via USB virtual serial works and produces the >> expected ~1ms offsets due to the USB poll interval. > > Actually, that 1ms offset was due to the fact that the serial interface > uses negative logic and I really

Re: Additional pps-gpio

Achim Gratz via devel writes: > I've configured all GPS to produce at least 10ms long pulses as I found > that the rasPi 1B+ would otherwise sometimes miss a pulse. I think the > reason is that while the interrupt itself is generated on the edge of > the pulse, the code in the handler actually

Re: Additional pps-gpio

Hal Murray via devel writes: > You can build your own with PPS by adding a few wires to the combination of a > GPS breakout board and a USB-serial with breakout on the serial side. There > is at least one USB-serial chip available on a breakout that polls at 1/4 ms. > I'll look up part

Re: Additional pps-gpio

> I've just tried that again with both the uBlox-6 and uBlox-8 and while I can > attach the PPS line discipline to the interface, no PPS ever gets generated > on that device. If they can actually do that, I'd be interested in how to > enable that capability. You can build your own with PPS by

Re: Additional pps-gpio

Yo Achim! On Wed, 31 Jan 2018 20:14:00 +0100 Achim Gratz via devel wrote: > Gary E. Miller via devel writes: > > Bus 001 Device 016: ID 067b:2303 Prolific Technology, Inc. PL2303 > > Serial Port > > > > Just a plain old uBlox 6 connected to a plain old PL2303. > > That

Re: Additional pps-gpio

Gary E. Miller via devel writes: > Bus 001 Device 016: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port > > Just a plain old uBlox 6 connected to a plain old PL2303. That confirms my suspicion that they're not using the built-in USB interface. So it's likely one of those Macx-1

Re: Additional pps-gpio

Yo Achim! On Wed, 31 Jan 2018 19:47:30 +0100 Achim Gratz via devel wrote: > Gary E. Miller via devel writes: > > I'm comparing SkyTraq PPS to the u-blox 6 USB PPS. > > I'm still curious about that "uBlox-6 USB PPS", do you happen to know > what chipset is actually in there?

Re: Additional pps-gpio

Gary E. Miller via devel writes: > I'm comparing SkyTraq PPS to the u-blox 6 USB PPS. I'm still curious about that "uBlox-6 USB PPS", do you happen to know what chipset is actually in there? What's the USB ID? Some members of that family do have built-in USB interfaces, but to the best of my

Re: Additional pps-gpio

Yo Achim! On Tue, 30 Jan 2018 22:45:39 +0100 Achim Gratz via devel wrote: > Gary E. Miller via devel writes: > > I have some u-blox 6 that are USB mice. I get under 2 uS jitter on > > a RasPi, but I have not compared them directly to a GPIO PPS. I > > should add that to my

Re: Additional pps-gpio

Gary E. Miller via devel writes: > I have some u-blox 6 that are USB mice. I get under 2 uS jitter on a > RasPi, but I have not compared them directly to a GPIO PPS. I should > add that to my long list. It takes a few days for the clocks to settle > in. Both my NaviSys stick (uBlox6) and puck

Re: Additional pps-gpio

Hal Murray via devel writes: >> PPS line discipline via USB virtual serial works and produces the expected >> ~1ms offsets due to the USB poll interval. It should be possible to remove >> that shift by doing a loopback measurement via RTS/CTS eventually. Jitter >> is roughly on par with the

Re: Additional pps-gpio

Yo Achim! On Tue, 30 Jan 2018 21:58:57 +0100 Achim Gratz via devel wrote: > It seems to converge pretty nicely and with > jitter around 40µs now (around the same as LAN jitter). I have some u-blox 6 that are USB mice. I get under 2 uS jitter on a RasPi, but I have not

Re: Additional pps-gpio

Achim Gratz via devel writes: > PPS line discipline via USB virtual serial works and produces the > expected ~1ms offsets due to the USB poll interval. Actually, that 1ms offset was due to the fact that the serial interface uses negative logic and I really need to align to the clear edge, not

Re: Additional pps-gpio

> PPS line discipline via USB virtual serial works and produces the expected > ~1ms offsets due to the USB poll interval. It should be possible to remove > that shift by doing a loopback measurement via RTS/CTS eventually. Jitter > is roughly on par with the local stratum-1 over network. The

Re: Additional pps-gpio

Achim Gratz via devel writes: > I've ordered a bunch of RS232 converters and USB UART today along wth > another rasPi 3B and Tinkerboard, so I should be able to tell how much > better things get exactly when you use line disciplining on a virtual or > real serial port on these and also a PC soon.

Re: Additional pps-gpio

Trevor N. via devel writes: > If you're also going to test on a PC, you might be interested in > a Linux parallel port PPS driver I modified a while back to add > low-latency loopback echo and a mode that uses polling instead of > interrupts for pulse capture. Also, on load the driver measures IO

Re: Additional pps-gpio

Hal Murray via devel writes: >> But maybe I don't understand what you're after. > > I'm interested in learning whatever we can about the timing in the kernel PPS > area. Sorry, that's still too vague for me to try to help. But for the Linux kernel it all starts and ends here, I think:

Re: Additional pps-gpio

> But maybe I don't understand what you're after. I'm interested in learning whatever we can about the timing in the kernel PPS area. There is another approach that might be interesting. Use a loopback on some modem control signals or gpio pins. Then a test program can grab the time,

Re: Additional pps-gpio

Hal Murray via devel writes: > It may be easier to experiment with a real serial port since it would be easy > to pick one of the output modem control signals. Well, that assumes you do have a serial port available that even has these signals connected. > With gpio we could make the dtoverlay

Re: Additional pps-gpio

devel@ntpsec.org said: > As far as I understand the sources, setting up an echo allows a PPS client > to register a callback function with the PPS device to be called when a PPS > event happens. The default echo function simply outputs "echo: assert" or > "echo: clear". I guess one could indeed

Re: Additional pps-gpio

Hal Murray via devel writes: > I'm not sure what you mean by "_creating_ a PPS". What I had in mind was what the Parport PPS generator does, only with output through a GPIO. Since no LPT is there on the rasPi, this doesn't exist for it unfortunately, but the source code could serve as a

Re: Additional pps-gpio

Hal Murray via devel writes: > I'm not sure what you mean by "_creating_ a PPS". Set up a periodic high-resolution absolute kernel timer to toggle a GPIO. > One approach would be to flap a modem control signal from userland. You can do that via highres timers (caution: they won't work with the

Re: Additional pps-gpio

devel@ntpsec.org said: > Well, maybe if I can think about a use of that measurement I might do it, > but _creating_ a PPS from the rasPi and then measuring it externally with a > TIC of sufficient resolution would be much more useful than teasing out this > or that internal delay that is going to

Re: Additional pps-gpio

Hal Murray via devel writes: >> Well if I'm going to do that I'd use a time interval counter and >> not the rasPi. > > I was thinking of measuring the timings inside the Pi rather than the pulse > width. > > If you feed the same pulse to two pins, I'd expect to get readings of T and > T+x where

Re: Additional pps-gpio

>> I'd expect another step if the timing difference between >> pulses is such that it changes from 1 interrupt to 2. The two >> interrupt case will add the time to return from an interrupt >> and take the second one. Maybe a one-shot with a >> knob so you can adjust the delay and plot the

Re: Additional pps-gpio

Hal Murray via devel writes: > You might learn something by connecting the same PPS signal to two pins and > comparing the time stamps. The difference is a lower bound on the latency. If I find the time, yes. > Most GPSDOs produce a narrow pulse, 10 or 20 microseconds. You might learn >

Re: Additional pps-gpio

> For starters, the two PPS pulses should be close enough together to trigger > a back-to-back queued interrupt, so the second will have to wait for the > first handler to complete. You might learn something by connecting the same PPS signal to two pins and comparing the time stamps. The

Re: Additional pps-gpio

Gary E. Miller via devel writes: > Looking forward to your results. I suspect we'll be surprised by > something in there. For starters, the two PPS pulses should be close enough together to trigger a back-to-back queued interrupt, so the second will have to wait for the first handler to

Re: Additional pps-gpio

Yo Achim! On Wed, 24 Jan 2018 21:48:48 +0100 Achim Gratz via devel wrote: > Now I'll have to modify the NaviSys puck to get the hidden > PPS out and connect it as a second PPS. Looking forward to your results. I suspect we'll be surprised by something in there. RGDS GARY

Re: Additional pps-gpio

Gary E. Miller via devel writes: > As of two mins ago, the improvement to allow multiple pps-gpio is > now in git head. Wonderful. I wish all that devicetree magic was better documented, though… Now I'll have to modify the NaviSys puck to get the hidden PPS out and connect it as a second PPS.

Re: Additional pps-gpio

Yo Achim! > > Bug filed with the Raspberry Pi kernel folks: > > https://github.com/raspberrypi/linux/issues/2352 > I've asked that is be added to git head. As of two mins ago, the improvement to allow multiple pps-gpio is now in git head. Many thanks to Phil Elwell for the fast work!

Re: Additional pps-gpio

Yo Achim! On Wed, 24 Jan 2018 19:22:46 +0100 Achim Gratz via devel wrote: > Gary E. Miller via devel writes: > > So, how about you file a bug with the RasPi kernel people? > > I think that should go straight to upstream kernel development. > However I'm not sure if that

Re: Additional pps-gpio

Yo Achim! On Wed, 24 Jan 2018 19:02:52 +0100 Achim Gratz via devel wrote: > Gary E. Miller via devel writes: > > So the problem is with the RasPi kernel. Go ahead and nag them for > > us. > > If you go back and actually read what I wrote at the beginning of the > thread,

Re: Additional pps-gpio

Gary E. Miller via devel writes: > So the problem is with the RasPi kernel. Go ahead and nag them for us. If you go back and actually read what I wrote at the beginning of the thread, it is a problem with the gpio-pps driver. It only allows a single GPIO to be configured for PPS. Both the

Re: Additional pps-gpio

Yo Achim! > > Agai, the problem > > is not using multiple such devices, it's with actually getting them > > configured in the kernel. > > How about this on a RasPi: > > # Uptraonics on gpio 18 > dtoverlay=pps-gpio,gpiopin=18 > # adafruit HAT > dtoverlay=pps-gpio,gpiopin=4 Ah, now I see the

Re: Additional pps-gpio

Yo Achim! On Tue, 23 Jan 2018 22:26:07 +0100 Achim Gratz via devel wrote: > Gary E. Miller via devel writes: > > Sure it does. gpsd works with the /dev/ppsX devices, which are > > kernel timestamped. I use that on all my RasPi GPS. > > Yeah. Now show me how you can get

Re: Additional pps-gpio

Gary E. Miller via devel writes: > Sure it does. gpsd works with the /dev/ppsX devices, which are > kernel timestamped. I use that on all my RasPi GPS. Yeah. Now show me how you can get more than one GPIO connected to a /dev/pps*, expecially on the raspberryPi where neither a serial device or

Re: Additional pps-gpio

Yo Achim! On Tue, 23 Jan 2018 22:04:42 +0100 Achim Gratz via devel wrote: > Gary E. Miller via devel writes: > >> As noted before I've been wondering how to get a second (or third) > >> gps-ppio device configured. > > > > gpsd would have no problem with that. It is actually

Re: Additional pps-gpio

Yo Achim! On Tue, 23 Jan 2018 21:08:00 +0100 Achim Gratz via devel wrote: > As noted before I've been wondering how to get a second (or third) > gps-ppio device configured. gpsd would have no problem with that. It is actually too easy to do with gpsd. Sometimes gpsd sees