>Yo Achim!
>
>On Tue, 28 Aug 2018 19:28:32 +0200
>Achim Gratz via devel wrote:
>
>> Gary E. Miller via devel writes:
>> > We probably need to work with linuxpps, but we may have an easier
>> > time working with the folks that maintain the Raspberry Pi fork.
>> > The last time I asked for a dtb
Yo Achim!
On Tue, 28 Aug 2018 19:28:32 +0200
Achim Gratz via devel wrote:
> Gary E. Miller via devel writes:
> > We probably need to work with linuxpps, but we may have an easier
> > time working with the folks that maintain the Raspberry Pi fork.
> > The last time I asked for a dtb change it
Gary E. Miller via devel writes:
> We probably need to work with linuxpps, but we may have an easier time
> working with the folks that maintain the Raspberry Pi fork. The last
> time I asked for a dtb change it took one day to get in git head.
The only thing that linuxpps would be the correct
On 27-08-18 23:47, Gary E. Miller via devel wrote:
On Thu, 23 Aug 2018 20:39:37 +0200
Achim Gratz via devel wrote:
if anybody has any
concrete questions I'll relay them when I get back.
I was also out, and now back.
We probably need to work with linuxpps, but we may have an easier time
Yo Achim!
On Thu, 23 Aug 2018 20:39:37 +0200
Achim Gratz via devel wrote:
> if anybody has any
> concrete questions I'll relay them when I get back.
I was also out, and now back.
We probably need to work with linuxpps, but we may have an easier time
working with the folks that maintain the
MLewis via devel writes:
> Exactly! It's been on my todo list for a couple of years, but I wasn't
> motivated to get into a LKM to get to kernel space to make it
> worthwhile. Although I suspected that even from user space, the result
> would be better than some PPS.
Well, it sure avoids the
Achim,
On 20/08/2018 1:35 PM, Achim Gratz via devel wrote:
.. Unless I'm missing something, your implementation would do
something I proposed a few weeks ago, namely skip dealing with PPS in
altogether and correlate kernel and GPS time via timestamping on the GPS.
Exactly! It's been on my
Udo van den Heuvel via devel writes:
> What else could we do with the timemark functionality?
> See what is suggested at
> https://lists.ntpsec.org/pipermail/devel/2018-August/006447.html ?
Well, actually this suggestion was highly rasPi specific: The hardware
PWM is clocked directly off the
MLewis via devel writes:
> I believe it should be a driver as a Loadable Kernel Module.
Yup.
> I'm working on one now. Selectable triggers of Timemark 1, rising and
> falling, and Timemark 2, rising and falling, providing up to four
> timestamps for calculating four offsets, observing noise,
Udo van den Heuvel via devel writes:
> I'd see a setup with a USB connection for the data part of the setup.
> PPS goes to LPT (ack pin).
> LPT strobe could be used to send pulse to the ublox(*1).
Yup.
> At the ntpd level I could use the pps driver for pps reception, this
> should work with LPT
Udo van den Heuvel via devel writes:
> On 19-08-18 18:22, Achim Gratz via devel wrote:
>> The trouble with GPIO is that it's either only
>> available on a few boards that aren't very widespread and PCI(-e) cards
>> (aside from the LTP cards)
>
> So LPT cards would be acceptable, usable?
> If so:
Repeat. Didn't go out in text format.
On 20/08/2018 10:22 AM, MLewis via devel wrote:
Udo,
On 20/08/2018 9:43 AM, Udo van den Heuvel wrote:
Michael,
What else could we do with the timemark functionality?
See what is suggested at
Udo,
On 20/08/2018 9:43 AM, Udo van den
Heuvel wrote:
Michael,
What else could we do with the timemark functionality?
See what is suggested at
https://lists.ntpsec.org/pipermail/devel/2018-August/006447.html ?
With
Michael,
On 20-08-18 15:35, MLewis via devel wrote:
I believe that a kernal patch is not the correct way to do that. It's
too specific as it's only for some ublox modules.�
Weirder hardware has a driver in the kernel.. :-)
But I see no problem in the Loadable Kernel Module approach:
I'm
I believe that a kernal patch is not the correct way to do that.
It's too specific as it's only for some ublox modules.�
I believe it should be a driver as a Loadable Kernel Module.
This also allows people to easily modify the source to their own
needs, without
On 20-08-18 04:33, Udo van den Heuvel via devel wrote:
On 19-08-18 18:22, Achim Gratz via devel wrote:
The trouble with GPIO is that it's either only
available on a few boards that aren't very widespread and PCI(-e) cards
(aside from the LTP cards)
So LPT cards would be acceptable, usable?
On 19-08-18 18:22, Achim Gratz via devel wrote:
The trouble with GPIO is that it's either only
available on a few boards that aren't very widespread and PCI(-e) cards
(aside from the LTP cards)
So LPT cards would be acceptable, usable?
If so: are they supported already for what we want to do?
As this is likely for a dedicated timeserver, why not have some
dedicated stand-alone software deal with an M8T (or others with
Timemark) and discipline System Time, then have nptsec use System
Time as a reference?
On 17/08/2018 6:37 AM, Udo van den
Heuvel via
On 17-08-18 12:08, Udo van den Heuvel via devel wrote:
On 15-08-18 15:12, Udo van den Heuvel via devel wrote:
I will test if the patches apply to Linux and ntpd.
Kernel patch complains about arm-related files.
I guess we need x86/x86_64 equivalent changes?
Without the arm-related pach the
On 15-08-18 15:12, Udo van den Heuvel via devel wrote:
I will test if the patches apply to Linux and ntpd.
Kernel patch complains about arm-related files.
I guess we need x86/x86_64 equivalent changes?
Also I will test linux-rt kernel against current setup to see if it
helps improve numbers.
Yo Achim!
On Thu, 16 Aug 2018 20:04:33 +0200
Achim Gratz via devel wrote:
> Gary E. Miller via devel writes:
> > u-blox has an app note:
> >
> > https://www.u-blox.com/sites/default/files/products/documents/GPS-Antenna_AppNote_%28GPS-X-08014%29.pdf
> >
> > In Section 5.1.1 they recommend a
Gary E. Miller via devel writes:
> u-blox has an app note:
>
> https://www.u-blox.com/sites/default/files/products/documents/GPS-Antenna_AppNote_%28GPS-X-08014%29.pdf
>
> In Section 5.1.1 they recommend a 50mmm to 70mm square ground plane
> under a patch antenna. They do not recommend anything
Udo van den Heuvel via devel writes:
> While searching I cam across this page:
> http://www.tallysman.com/index.php/gnss/products/antennas-gpsbeidougalileoglonass/
>
> It has a few choices, even the `puck` type GPS is present; with some
> documentation even.
You should look further down that page
On 16-08-18 16:06, MLewis via devel wrote:
Do note that that the 4722 and 2712 are the pre-filtered versions.
"The TW4722 is the pre-filtered version of the TW1721. The pre-filter
provides protection from near frequency or strong harmonic interfering
signals."
TW2920: High rejection
Do note that that the 4722 and 2712 are the pre-filtered versions.
"The TW4722 is the pre-filtered version of the TW1721. The
pre-filter provides protection from near frequency or strong
harmonic interfering signals."
On 16/08/2018 9:33 AM, Udo van den
On 15-08-18 15:12, Udo van den Heuvel via devel wrote:
What antenna can cope with these requirements?
While searching I cam across this page:
http://www.tallysman.com/index.php/gnss/products/antennas-gpsbeidougalileoglonass/
It has a few choices, even the `puck` type GPS is present; with
Yo Udo!
On Wed, 15 Aug 2018 15:12:04 +0200
Udo van den Heuvel via devel wrote:
> Question: So what antenna would we need?
>
> One that covers multi GNSS, i.e.: GPS, Glonass, Galileo, Beidou, etc,
> etc.
Much easier said than done. Technically GPS L1 and GALILEO E1 use the
same frequency:
Udo van den Heuvel via devel writes:
> On 14-08-18 21:03, Achim Gratz via devel wrote:
>> If you have a GPS antenna with SMA connector then you'll want this
>> module instead:
>
> No antenna yet but SMA looks more robust...
Certainly, but it's still quite delicate.
> Question: So what antenna
On 14-08-18 21:03, Achim Gratz via devel wrote:
If you have a GPS antenna with SMA connector then you'll want this
module instead:
No antenna yet but SMA looks more robust...
Question: So what antenna would we need?
One that covers multi GNSS, i.e.: GPS, Glonass, Galileo, Beidou, etc, etc.
Yo Achim!
On Tue, 14 Aug 2018 21:15:54 +0200
Achim Gratz via devel wrote:
> Whether or not the EXTINTx is usable on any particular board that uses
> the module you will have to find out via the board manufacturers
> documentation.
Yup, that's the big problem.
> You said you have an M8T. I
Yo Udo!
On Tue, 14 Aug 2018 06:52:42 +0200
Udo van den Heuvel wrote:
> https://www.csgshop.com/product.php?id_product=240 is cheaper and has
> EXTINT0 and EXTINT1 document in the pictures.
> Now: how to set the serial ports using USB?
USB sorta defeats the purpose here.
>, to be rs232
Gary E. Miller via devel writes:
> CAre to be more specific on which u-blox support EXTINT0?
All of them, literally.
> Been there, done that, many variants not in your reference.
This is the documentation for the uBlox-8 modules (the little
rectangular bugger with the uBlox sticker on top), not
Udo van den Heuvel via devel writes:
> On 13-08-18 22:10, Gary E. Miller via devel wrote:
> Found an LEA-M8T at https://www.csgshop.com/product.php?id_product=200
> but this one has TIME1 and TIME2 besides power and RX/TX pairs.
You've probably found it out by now, but this one has the two
Udo,
A little more and you can have the USB already available through #217 below.
I believe the #218 and #240 are the M8T boards of theirs that have the
full pinouts accessible for "Output avail for use Time Pulse 1, Time
Pulse 2, Interupt 0, Interuprt 1, all pins for SPI, UART, USB, I2C
On 14-08-18 05:57, Udo van den Heuvel via devel wrote:
On 13-08-18 22:10, Gary E. Miller via devel wrote:
Again, no -- you could easily read the documentation, though or you
can go over to the uBlox Forum if you don't believe me.
CAre to be more specific on which u-blox support EXTINT0?
On 13-08-18 22:10, Gary E. Miller via devel wrote:
Again, no -- you could easily read the documentation, though or you
can go over to the uBlox Forum if you don't believe me.
CAre to be more specific on which u-blox support EXTINT0?
Found an LEA-M8T at
Yo Achim!
On Mon, 13 Aug 2018 22:06:50 +0200
Achim Gratz via devel wrote:
> Gary E. Miller via devel writes:
> > I've emailed Lucas for the driver code. No response.
>
> Uh, it's in the Git repository he linked to, which is a fork of NTP
> classic with his driver added. What else are you
Yo Achim!
On Mon, 13 Aug 2018 21:55:16 +0200
Achim Gratz via devel wrote:
> Gary E. Miller via devel writes:
> > Dunno, I have no info on that GPS. It does need access to the
> > EXTINT0 pin on the u-blox. I think EXTINT0, for timing, is only
> > available on the FTS variants of the u-blox.
Gary E. Miller via devel writes:
> I've emailed Lucas for the driver code. No response.
Uh, it's in the Git repository he linked to, which is a fork of NTP
classic with his driver added. What else are you looking for?
> So, just guessing, from what I think I understand in the pdf:
>
> Needs
Udo van den Heuvel via devel writes:
> Also: how could we interface these clocks to x86* hardware in the best way?
There's a bunch of boards that bridge between the "normal" PC and the
embedded world that actually have proper GPIO which is supported in the
Linux kernel. Aside from these anything
Gary E. Miller via devel writes:
> Dunno, I have no info on that GPS. It does need access to the EXTINT0
> pin on the u-blox. I think EXTINT0, for timing, is only available on
> the FTS variants of the u-blox.
Again, no -- you could easily read the documentation, though or you can
go over to
Yo MLewis!
On Mon, 13 Aug 2018 13:54:56 -0400
MLewis via devel wrote:
> Have I missed something along the way and that we're not looking to
> do what the thesis did and are on to something else?
I have no idea... For now, I'll wait for Lucas to respond.
With luck someone can reproduce
Yo Gary
My bad. I didn't think the M8F did Timemark as I missed it in the
M8F docs and didn't see EXTINT0 nor EXTINT1 pins in the pin list for
the M8F. Apparently it uses the FREQ_PHASE_IN as EXTINT for
Timemark.
The first email you sent out had text that
Yo MLewis!
On Mon, 13 Aug 2018 13:16:44 -0400
MLewis via devel wrote:
> If I understand what was used, it was the EXTINT0 and EXTINT1 inputs
> that cause the GPS module to take a Timemark (timestamp), which is
> output as UBX-Tim-TM2 messages. See page 69 of the M8T manual.
The part in
I don't think so. I don't see the pin outs for the Timestamps on that
board. I haven't checked if that module has them.
If I understand what was used, it was the EXTINT0 and EXTINT1 inputs
that cause the GPS module to take a Timemark (timestamp), which is
output as UBX-Tim-TM2 messages. See
Yo Udo!
On Mon, 13 Aug 2018 18:46:32 +0200
Udo van den Heuvel wrote:
> On 11-08-18 23:03, Gary E. Miller via devel wrote:
> > pin on the u-blox. I think EXTINT0, for timing, is only available
> > on the FTS variants of the u-blox.
> >
> > I've never found a good list of which products are
On 11-08-18 23:03, Gary E. Miller via devel wrote:
pin on the u-blox. I think EXTINT0, for timing, is only available on
the FTS variants of the u-blox.
I've never found a good list of which products are FTS. I think the
LEA-M8F, LEA-M8T and NEO-M8T are FTS. Likely a few others, but not the
On Sun, Aug 12, 2018 at 5:50 PM Gary E. Miller via devel
wrote:
> I'll be happy if we can get a copy of his code.
>
old(?) kernel (etc) patches for linux:
https://gitlab.cs.fau.de/snippets/28/raw?inline=false
& freebsd: https://gitlab.cs.fau.de/snippets/29/raw?inline=false
incompatible refclock
Yo Achim!
On Sun, 12 Aug 2018 08:27:47 +0200
Achim Gratz via devel wrote:
> Gary E. Miller via devel writes:
> >> And will it work with the Navisys TR units?
> >
> > Dunno, I have no info on that GPS. It does need access to the
> > EXTINT0 pin on the u-blox. I think EXTINT0, for timing, is
Yo Achim!
On Sun, 12 Aug 2018 09:33:36 +0200
Achim Gratz via devel wrote:
> > The results are an average PPS jitter of 222 ns!
>
> Well, yes -- if you measure and eliminate the interrupt latency, which
> by far dominates the jitter in the normal PPS processing, then the
> residual jitter
Yo Udo!
On Sun, 12 Aug 2018 11:05:20 +0200
Udo van den Heuvel wrote:
> On 11-08-18 23:03, Gary E. Miller via devel wrote:
> > I've never found a good list of which products are FTS. I think the
> > LEA-M8F, LEA-M8T and NEO-M8T are FTS. Likely a few others, but not
> > the basic NEO-M8L, M, N,
On 11-08-18 23:03, Gary E. Miller via devel wrote:
I've never found a good list of which products are FTS. I think the
LEA-M8F, LEA-M8T and NEO-M8T are FTS. Likely a few others, but not the
basic NEO-M8L, M, N, Q or S variants.
Interesting info!
Also: how could we interface these clocks to
Gary E. Miller via devel writes:
>> And will it work with the Navisys TR units?
>
> Dunno, I have no info on that GPS. It does need access to the EXTINT0
> pin on the u-blox. I think EXTINT0, for timing, is only available on
> the FTS variants of the u-blox.
No. The EXTINTx function (these
Yo Mark!
On Sat, 11 Aug 2018 13:31:05 -0700
Mark Atwood wrote:
> Can we port this driver to NTPsec?
No idea. I sent an email to Lucas.
> And will it work with the Navisys TR units?
Dunno, I have no info on that GPS. It does need access to the EXTINT0
pin on the u-blox. I think EXTINT0,
54 matches
Mail list logo
