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
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
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
> 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
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
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
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?
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
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
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
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
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
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
> 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
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.
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
>Hal Murray hmurray at megapathdsl.net
>Sun Jan 28 07:37:05 UTC 2018
>
>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,
>flap the pin, and grab the time, then read the PPS time.
>
>Things
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:
> 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,
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
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
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
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
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
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
>> 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
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
>
> 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
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
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
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.
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!
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
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,
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
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
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
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
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
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
As noted before I've been wondering how to get a second (or third)
gps-ppio device configured. It turns out that the mainline driver
really doesn't allow to do that with or without a correct device tree,
but someone has figured out how to add another device anyway:
41 matches
Mail list logo