On Wed, Jul 15, 2020 at 7:25 PM jimlux wrote:
>
> I use teensy boards (pjrc.com) for this kind of thing (Arduino sort of,
> but much, much more - much faster processor with more resources, and
> physically smaller).
>
> I've used Teensy 3.1s and 3.2s - but a Teensy LC for $12 might do it.
>
recise time and frequency measurement
> , hmur...@megapathdsl.net
> Subject: Re: [time-nuts] Raspberry Pi NTP server
> Message-ID:
> <20200715125912.4e422406...@ip-64-139-1-69.sjc.megapath.net>
> Content-Type: text/plain; charset=us-ascii
>
>
> tpie...@gmai
On 7/15/20 5:59 AM, Hal Murray wrote:
tpie...@gmail.com said:
It seems like it would not be that hard to get the USB frame sequence phase
locked to the system clock. One would need a way to measure the phase offset
of the USB S-o-F vs the system clock, and then it's a standard process to
On 7/15/20 5:16 AM, Petr Titěra wrote:
On 15.07.2020 0:13, Trent Piepho wrote:
On Mon, Jul 13, 2020 at 4:52 PM Hal Murray
wrote:
Is there any way for a USB device to synchronise with the CPU clock
(perhaps
via the USB framing) so that a special-purpose device could
timestamp the PPS
tpie...@gmail.com said:
> It seems like it would not be that hard to get the USB frame sequence phase
> locked to the system clock. One would need a way to measure the phase offset
> of the USB S-o-F vs the system clock, and then it's a standard process to
> phase lock, with the necessary
On 15.07.2020 0:13, Trent Piepho wrote:
On Mon, Jul 13, 2020 at 4:52 PM Hal Murray wrote:
Is there any way for a USB device to synchronise with the CPU clock (perhaps
via the USB framing) so that a special-purpose device could timestamp the PPS
occurrence with respect to CPU time ?
It seems
Hi
> On Jul 14, 2020, at 6:13 PM, Trent Piepho wrote:
>
> On Mon, Jul 13, 2020 at 4:52 PM Hal Murray wrote:
>>> Is there any way for a USB device to synchronise with the CPU clock (perhaps
>>> via the USB framing) so that a special-purpose device could timestamp the
>>> PPS
>>> occurrence
On Mon, Jul 13, 2020 at 4:52 PM Hal Murray wrote:
> > Is there any way for a USB device to synchronise with the CPU clock (perhaps
> > via the USB framing) so that a special-purpose device could timestamp the
> > PPS
> > occurrence with respect to CPU time ?
It seems maybe this was thought
> Is there any way for a USB device to synchronise with the CPU clock (perhaps
> via the USB framing) so that a special-purpose device could timestamp the PPS
> occurrence with respect to CPU time ?
If you were designing a special purpose device, just add a counter to measure
the time from
Is there any way for a USB device to synchronise with the CPU
clock (perhaps via the USB framing) so that a special-purpose device could
timestamp the PPS occurrence with respect to CPU time ?
On Mon, Jul 13, 2020 at 9:51 PM Trent Piepho wrote:
> On Mon, Jul 13, 2020 at 8:54 AM Petr Titěra
On Mon, Jul 13, 2020 at 8:54 AM Petr Titěra wrote:
>
> All Prolific chips I saw claimed to be USB 2.0 Full-speed. That means
> they are polled only once in 1ms and there is no way how to change it
> (poll rate is selected at hardware level).
Looking at the UHCI specification, for USB 1.1 HCIs,
Petr,
Is the variance plot based on PPS timestamps, or on NTP's smoothing of the
timestamps?
Have you measured the offset?
On Mon, Jul 13, 2020 at 10:54 AM Petr Titěra wrote:
> On 12.07.2020 3:57, jimlux wrote:
> > On 7/11/20 1:30 PM, Steven Sommars wrote:
> >> Using GPIO with an RPi is a
On 12.07.2020 3:57, jimlux wrote:
On 7/11/20 1:30 PM, Steven Sommars wrote:
Using GPIO with an RPi is a good direction, of course. That wasn't my
question. Some data may help explain.
Configuration =
RPi4 (raspbian buster)
Uputronics RPi GPS board (includes PPS) connected to GPIO
On Sun, Jul 12, 2020 at 11:51 AM jimlux wrote:
>
> Is the PPS via USB CTS stamped at interrupt time? or is it stamped
> higher up in the stack?
>
> I started tracing this out, but then decided I'm not going to be writing
> Linux USB drivers any time soon, so gave it up.
>
> I could easily
On Sun, Jul 12, 2020 at 5:08 AM Matthias Welwarsky
wrote:
>
> If you think about using an AM3358, there's zero reason to use a GPIO for PPS
> input. There are much better options, like the gptimer inputs or the eCAP
> engine, which runs on a 200MHz clock and is therefore able to create much more
time-n...@welwarsky.de said:
> However, those quantization errors are in a range of 10s of nanoseconds,
> maybe 100ns or so, ...
There is another level of sawtooth/bridge that happens as the 1 ms ticks from
the USB clock shift relative to the PPS.
--
These are my opinions. I hate spam.
On Sonntag, 12. Juli 2020 16:15:20 CEST Hal Murray wrote:
> Don't forget hanging bridges. I don't know of any NTP software that knows
> about them.
If you're referring to the "sawtooth" on the 1PPS from the GPS, the NTP
software shouldn't need to know. It's for whoever provides the PPS
e.
-Tim
> Date: Sat, 11 Jul 2020 18:57:39 -0700
> From: jimlux
> To: time-nuts@lists.febo.com
> Subject: Re: [time-nuts] Raspberry Pi NTP server
> Message-ID: <8a28aabb-e419-190f-37a6-e1a147637...@earthlink.net>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
On 7/12/20 7:15 AM, Hal Murray wrote:
stevesommars...@gmail.com said:
I'd like to reduce the USB polling contribution by polling at 125
microseconds as the Linux PPS folks suggest (http://linuxpps.org/doku.php/
technical_information)Would an FTDI-based USB convertor do the trick?
It
stevesommars...@gmail.com said:
> I'd like to reduce the USB polling contribution by polling at 125
> microseconds as the Linux PPS folks suggest (http://linuxpps.org/doku.php/
> technical_information)Would an FTDI-based USB convertor do the trick?
It depends on which FTDI chip you use.
On Sonntag, 12. Juli 2020 12:35:54 CEST Trent Piepho wrote:
> That interrupt line does not go straight to the processor. It goes to
> an interrupt controller, such as the ARM GIC or a proprietary
> controller. The AM3358 uses a TI controller. This controller deals
> with priority of interrupts,
On Sat, Jul 11, 2020 at 7:37 PM jimlux wrote:
>
> You might want to look into one of the "real time" linux kernels or
> other similar implementations - they might have "turned some of the
> knobs" to improve the handling of device data.
The real time kernel primarily is about trying to get
On Fri, Jul 10, 2020 at 12:17 PM Tim S wrote:
>
> I believe the issue is arising from the understanding of "what" is being
> interrupted.
>
> When a UART or GPIO is triggering an interrupt - for the UART it's a FIFO
> notice that data is available to be pulled out, for the GPIO it's
>
From: Steven Sommars
[]
Why bother with GPS/USB? Sometimes I use laptops. Few laptops today
directly support PPS/serial.
I just checked with Dell and found zero laptops with native RS232.
Thanks for posting your measurements, Steven.
If you can find a laptop with
On 7/11/20 1:30 PM, Steven Sommars wrote:
Using GPIO with an RPi is a good direction, of course. That wasn't my
question. Some data may help explain.
Configuration =
RPi4 (raspbian buster)
Uputronics RPi GPS board (includes PPS) connected to GPIO pins. This
is the time of day
saying that the NMEA messages must
> have such low latency however - in general they merely must arrive in time
> before the next 1PPS, so USB serial is fine for that traffic.
>
> -Tim
>
> On Thu, Jul 9, 2020 at 9:00 AM wrote:
>
> > Message: 4
> > Date: Wed, 8 Ju
frequency measurement
>
> Subject: Re: [time-nuts] Raspberry Pi NTP server
> Message-ID:
> atz...@mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> My RPi4 (Raspbian Buster) has a GPS+PPS/USB. Serial->USB uses Prolific
>
Driving the NTP software from a GPS w/PPS requires 1) bringing the NMEA
(typically) bytes to the computer.
Timing is not critical, USB polling at 1 msec is fine. 2) bringing the
PPS signal into the computer *is *timing critical. There's only one bit
of information.
If the PPS is brought to a
On 7/9/20 2:14 AM, Petr Titěra wrote:
Just one note. Most USB to serial chip claim USB2.0 support but they
only provide Full-Speed data transfers. That is data communication
protocol based on USB1.1 parameters with 1ms polling interval. You have
to specifically look for High-Speed (i.e
Just one note. Most USB to serial chip claim USB2.0 support but they
only provide Full-Speed data transfers. That is data communication
protocol based on USB1.1 parameters with 1ms polling interval. You have
to specifically look for High-Speed (i.e 480mbps) transfers when going
trough chip
USB:
The raw BPS are between the device and the host controller - all of
this is implemented in hardware.
USB Low-Speed, Full-Speed and Hi-Speed use a single twisted pair in
half-duplex operation. The half-duplex link multiplexes all
implemented EPs (End Points). EP0 is for link management and
I don't want to hijack Andrew's thread. Just wanted to add to Achim's
comments about jitter and offset.
USB2 devices should accept polls every 125 microseconds. [My USB knowledge
is limited.]
I have two devices. One is the Navisys GR701 which I suspect you're
familiar with; it is an
USB 1.0/Low-Speed: 1.5 Mbps
USB 1.1/Full-Speed: 12 Mbps.
USB 2.0/Hi-Speed: 480 Mbps.
USB 3.0/SuperSpeed: 5 Gbps.
USB 3.1/SuperSpeed: 10 Gbps.
This is the actual bitrate for these serial interfaces.
Bill
On Wed, Jul 8, 2020, 5:16 PM jimlux wrote:
> On 7/8/20 4:40 PM, Hal Murray wrote:
> >
> >
On 7/8/20 4:40 PM, Hal Murray wrote:
stevesommars...@gmail.com said:
My RPi4 (Raspbian Buster) has a GPS+PPS/USB. Serial->USB uses Prolific
PL2303, which supports USB 2.0
which means 1 msec polling of the PPS signal. I've been unable to poll more
frequently
As far as I know, the
On 7/8/20 4:40 PM, Hal Murray wrote:
stevesommars...@gmail.com said:
My RPi4 (Raspbian Buster) has a GPS+PPS/USB. Serial->USB uses Prolific
PL2303, which supports USB 2.0
which means 1 msec polling of the PPS signal. I've been unable to poll more
frequently
As far as I know, the
stevesommars...@gmail.com said:
> My RPi4 (Raspbian Buster) has a GPS+PPS/USB. Serial->USB uses Prolific
> PL2303, which supports USB 2.0
> which means 1 msec polling of the PPS signal. I've been unable to poll more
> frequently
As far as I know, the PL2303, 067b:2303, is an old/slow chip.
My RPi4 (Raspbian Buster) has a GPS+PPS/USB. Serial->USB uses Prolific
PL2303, which supports USB 2.0
The PPS jitter is 1 msec (e.g., using ppstest). lsusb -v shows:
Bus 001 Device 008: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial
Port
bInterval 1
which means 1
On Dienstag, 7. Juli 2020 18:27:01 CEST Petr Titěra wrote:
> Timing on USB need not to be so horrible. Below is stats from my server
> with GPS connected using FT232H chip (supporting high speed transfers on
> USB). Yes, the jitter is far greater than on other computer where PPS is
> connected
Timing on USB need not to be so horrible. Below is stats from my server
with GPS connected using FT232H chip (supporting high speed transfers on
USB). Yes, the jitter is far greater than on other computer where PPS is
connected directly but it is a lot less than that 500microseconds you
get
Hi
> On Jul 6, 2020, at 11:43 AM, Matthias Welwarsky
> wrote:
>
> On Samstag, 4. Juli 2020 16:49:11 CEST David J Taylor via time-nuts wrote:
>
>> Matthias, my feeling is that if you want a precision source, neither BB not
>> the RPi is a good solution. Maybe with all the tweak you
On Samstag, 4. Juli 2020 16:49:11 CEST David J Taylor via time-nuts wrote:
> Matthias, my feeling is that if you want a precision source, neither BB not
> the RPi is a good solution. Maybe with all the tweak you mentioned the BB
> approaches precision (for some values of precision). I see the
ists.febo.com
> Cc: David J Taylor
> Subject: Re: [time-nuts] Raspberry Pi NTP server
>
> A puzzle (so I hope) I'm in the correct place.
>
> I've built myself, many years ago an NTP server, on a RPi 1, which not
> sure if ever ran properly.
>
> It uses a u-blox6 boa
On 03/07/2020 13:56, Andrew Hancock wrote:
But here's the weird thing, it starts out okay, from what I can tell, and I get
377 for both GPSD and PPS
remote refid st t when poll reach delay offset jitter
On 7/3/20 8:56 AM, Andrew Hancock wrote:
GPS 3D fix is fine, using an outside aerial, there are no issues here reported
with cgps -s or gpsmon, but recently I've racked mounted all my PIs in a
network rack.
Have you ruled out thermal issues with the Pi being in a rack?
: [time-nuts] Raspberry Pi NTP server
A puzzle (so I hope) I'm in the correct place.
I've built myself, many years ago an NTP server, on a RPi 1, which not sure if
ever ran properly.
It uses a u-blox6 board, connected to the Pi correctly, and PPS to GPIO,
compiled NTP to include kernel PPS
] Raspberry Pi NTP server
andrew.hanc...@cyrus-consultants.co.uk said:
> So I cannot use HaTs anymore, so I cobbled together a GPS ublox6 (same
> module) but using a FT232RL, and connected all the pins correctly, and
> DCD so I can get PPS.
FT232R is a USB chip. Timing over USB is "interes
On 7/4/20 7:49 AM, David J Taylor via time-nuts wrote:
David,
I've seen your comparison in the list archives. However, none of the
approaches I have seen published so far (including yours) exploit all the
possibilities I mentioned.
The Raspi having better community support doesn't help if the
David,
I've seen your comparison in the list archives. However, none of the
approaches I have seen published so far (including yours) exploit all the
possibilities I mentioned.
The Raspi having better community support doesn't help if the platform
itself
is unfit for the purpose. It might be
On 7/4/20 2:30 AM, David J Taylor via time-nuts wrote:
... and it has much less general support
... and it generates more RF interference
... and it costs money as the OP already has the Raspberry Pi
I have both Pis and BB Blacks and Greens and Green wireless.
I'm interested in the RF
On Samstag, 4. Juli 2020 11:30:01 CEST David J Taylor via time-nuts wrote:
> From: Matthias Welwarsky
> []
> Forgive me chiming in with a recommendation: Drop the Raspberry Pi and get a
> Beaglebone Black instead. It is the much better platform for timekeeping
> experiments.
[snip]
> BR,
>
From: Matthias Welwarsky
[]
Forgive me chiming in with a recommendation: Drop the Raspberry Pi and get a
Beaglebone Black instead. It is the much better platform for timekeeping
experiments.
Firstly, it has capture-mode timers that will give much more stable
timestamps
for the 1PPS kernel
On Freitag, 3. Juli 2020 19:44:48 CEST Hal Murray wrote:
> andrew.hanc...@cyrus-consultants.co.uk said:
> > So I cannot use HaTs anymore, so I cobbled together a GPS ublox6 (same
> > module) but using a FT232RL, and connected all the pins correctly, and DCD
> > so I can get PPS.
>
> FT232R is a
A puzzle (so I hope) I'm in the correct place.
I've built myself, many years ago an NTP server, on a RPi 1, which not sure
if ever ran properly.
It uses a u-blox6 board, connected to the Pi correctly, and PPS to GPIO,
compiled NTP to include kernel PPS support.
GPS 3D fix is fine, using an
andrew.hanc...@cyrus-consultants.co.uk said:
> So I cannot use HaTs anymore, so I cobbled together a GPS ublox6 (same
> module) but using a FT232RL, and connected all the pins correctly, and DCD so
> I can get PPS.
FT232R is a USB chip. Timing over USB is "interesting". Do you know about
54 matches
Mail list logo
