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 ne
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 loo
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 numbers
> 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 ad
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 confirms my suspicion t
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 modificat
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? What's the USB ID
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
kno
Yo Achim!
> I just added a u-blox 6 GPS mouse, and split the SkyTraq PPS to go
> into GPIO 4 and GPIO 18. So three PPS on one RasPi. I'll post
> results later today, first I finish to compiling the new kernel with
> the new multiple PPS patch.
I'm comparing SkyTraq PPS to the u-blox 6 USB PPS.
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 long list. It takes
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 local
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 compared them directly to
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
asse
> 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 U
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 may
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:
https://
> 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,
flap
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 li
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
template.
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
d
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 diffe
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
> somet
> 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 diffe
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 complete.
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!
RGDS
Yo Achim!
> Bug filed with the Raspberry Pi kernel folks:
> https://github.com/raspberrypi/linux/issues/2352
Already an answer:
Take this overlay:
https://drive.google.com/file/d/1SRirIMwqLDgNHc3YTyUlB-rUuQtdtTym/view?usp=sharing
Apply to 4.9.19 or newer.
Add this to /boot/config.txt:
dtove
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 subsystem is still in
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 subsystem is still in active development, the
mailing list is more or less dormant. So, go ahead and try to f
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, it is a problem with
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 seria
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 pr
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 more than one GPIO c
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 p
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 too easy to do
> >
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 too easy to do
> with gpsd. Sometimes gpsd sees two serial ports and tries to use
> both as GPS.
That doe
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 two serial ports and
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:
https://github.com/hans-mayer/
45 matches
Mail list logo
