Re: [time-nuts] GPS message jitter (was GPS for Nixie Clock)

Yo Mark! On Tue, 19 Jul 2016 21:29:24 + Mark Sims wrote: > The NMEA sentences for sending date and time were very poorly thought > out. Several different sentences can contain the time (maybe the > same time in different sentences with a group, maybe each sentence >

Re: [time-nuts] GPS message jitter (was GPS for Nixie Clock)

Very true. If your exchanging data for loose timing purposes (wall clock) over a UART whether it is binary coded or ASCII coded is immaterial. You will always introduce at least 1/16 of a bit time of jitter, if not one full bit time, allowing the uart to sync to start bit edge. In full honesty I

Re: [time-nuts] GPS message jitter (was GPS for Nixie Clock)

On Mon, Jul 18, 2016 at 10:44 AM, Scott Stobbe wrote: > I am happy to hear you issue was resolved. What I meant to say is the > problem could also be mitigated using the UART's flow control, this could > be done by the original GPS designers or by an end user if the CTS

Re: [time-nuts] GPS message jitter (was GPS for Nixie Clock)

On Tue, 19 Jul 2016 06:16:16 -0700, you wrote: >On 7/18/16 9:44 PM, David wrote: >> The aged 16550 has various timeouts so an interrupt is triggered with >> a partially full buffer even if it is below the interrupt threshold. >> For implementations which do not do that, I assume they intend for

Re: [time-nuts] GPS message jitter (was GPS for Nixie Clock)

John Ackermann N8UR wrote: > Long ago I measured the impact of the linux low_latency flag on a 16550 UART. > I don't know where that data is sitting now, but I remember that it made a > significant difference. > >> On Jul 18, 2016, at 9:59 PM, Hal Murray wrote: >> >>

Re: [time-nuts] GPS message jitter (was GPS for Nixie Clock)

On 7/18/16 9:44 PM, David wrote: The aged 16550 has various timeouts so an interrupt is triggered with a partially full buffer even if it is below the interrupt threshold. For implementations which do not do that, I assume they intend for the UART to be polled regularly. exactly... you have

Re: [time-nuts] GPS message jitter (was GPS for Nixie Clock)

Long ago I measured the impact of the linux low_latency flag on a 16550 UART. I don't know where that data is sitting now, but I remember that it made a significant difference. > On Jul 18, 2016, at 9:59 PM, Hal Murray wrote: > > > jim...@earthlink.net said: >>

Re: [time-nuts] GPS message jitter (was GPS for Nixie Clock)

From: Scott Stobbe I am happy to hear you issue was resolved. What I meant to say is the problem could also be mitigated using the UART's flow control, this could be done by the original GPS designers or by an end user if the CTS line is pined out. Gating the UART with a conservative delay, say

Re: [time-nuts] GPS message jitter (was GPS for Nixie Clock)

The aged 16550 has various timeouts so an interrupt is triggered with a partially full buffer even if it is below the interrupt threshold. For implementations which do not do that, I assume they intend for the UART to be polled regularly. On Mon, 18 Jul 2016 23:42:34 -0400, you wrote: >I can't

Re: [time-nuts] GPS message jitter (was GPS for Nixie Clock)

Sent: Monday, July 18, 2016 5:46 PM > Subject: Re: [time-nuts] GPS message jitter (was GPS for Nixie Clock) > > On 7/18/16 1:44 PM, Scott Stobbe wrote: > > Well, I suppose in the case of USB, the host hardware (consumer PC) is > not > > going to have any special hardware.

Re: [time-nuts] GPS message jitter (was GPS for Nixie Clock)

I can't speak for linux, but I have been bitten by FIFO watermark interrupts on micros before. If you set an interrupt for a 3/4 full FIFO, the last one or two characters will sit in the receive buffer and never trigger the RX interrupt. For a command -> response device which doesn't have a

Re: [time-nuts] GPS message jitter (was GPS for Nixie Clock)

jim...@earthlink.net said: > except that virtually every UART in use today has some sort of buffering > (whether a FIFO or double buffering) between the CPU interface and the bits > on the wire, which completely desynchronizes the bits on the wire from the > CPU interface. The idea was to

Re: [time-nuts] GPS message jitter (was GPS for Nixie Clock)

/groups/GFS-GPSDOs/info From: jimlux <jim...@earthlink.net> To: time-nuts@febo.com Sent: Monday, July 18, 2016 5:46 PM Subject: Re: [time-nuts] GPS message jitter (was GPS for Nixie Clock) On 7/18/16 1:44 PM, Scott Stobbe wrote: > Well, I suppose in the case of USB, the host

Re: [time-nuts] GPS message jitter (was GPS for Nixie Clock)

On 7/18/16 1:44 PM, Scott Stobbe wrote: Well, I suppose in the case of USB, the host hardware (consumer PC) is not going to have any special hardware. But, if a gps receiver implements a USB interface, in addition to standard NEMA data, it could also report the phase and frequency error of your

Re: [time-nuts] GPS message jitter (was GPS for Nixie Clock)

On 7/18/16 12:35 PM, David wrote: On Mon, 18 Jul 2016 11:43:32 -0700, you wrote: except that virtually every UART in use today has some sort of buffering (whether a FIFO or double buffering) between the CPU interface and the bits on the wire, which completely desynchronizes the bits on the

Re: [time-nuts] GPS message jitter (was GPS for Nixie Clock)

Well, I suppose in the case of USB, the host hardware (consumer PC) is not going to have any special hardware. But, if a gps receiver implements a USB interface, in addition to standard NEMA data, it could also report the phase and frequency error of your USB clock (since it has to recover it

Re: [time-nuts] GPS message jitter (was GPS for Nixie Clock)

On Mon, 18 Jul 2016 11:43:32 -0700, you wrote: >except that virtually every UART in use today has some sort of buffering >(whether a FIFO or double buffering) between the CPU interface and the >bits on the wire, which completely desynchronizes the bits on the wire >from the CPU interface. >

Re: [time-nuts] GPS message jitter (was GPS for Nixie Clock)

I am happy to hear you issue was resolved. What I meant to say is the problem could also be mitigated using the UART's flow control, this could be done by the original GPS designers or by an end user if the CTS line is pined out. Gating the UART with a conservative delay, say 500 ms from the time

Re: [time-nuts] GPS message jitter (was GPS for Nixie Clock)

Hi > On Jul 18, 2016, at 12:19 PM, David J Taylor > wrote: > > I suppose it is one of those cases where, the GPS designers decided you > shouldn't ever use the serial data for sub-second timing, and consequently > spent no effort on serial latency and jitter. >

Re: [time-nuts] GPS message jitter (was GPS for Nixie Clock)

On 7/18/16 8:51 AM, Scott Stobbe wrote: I suppose it is one of those cases where, the GPS designers decided you shouldn't ever use the serial data for sub-second timing, and consequently spent no effort on serial latency and jitter. Most UARTs I have come across have been synthesized with a 16x

Re: [time-nuts] GPS message jitter (was GPS for Nixie Clock)

I suppose it is one of those cases where, the GPS designers decided you shouldn't ever use the serial data for sub-second timing, and consequently spent no effort on serial latency and jitter. Most UARTs I have come across have been synthesized with a 16x baud clock and included flow control. It

Re: [time-nuts] GPS message jitter (was GPS for Nixie Clock)

I suppose it is one of those cases where, the GPS designers decided you shouldn't ever use the serial data for sub-second timing, and consequently spent no effort on serial latency and jitter. Most UARTs I have come across have been synthesized with a 16x baud clock and included flow control. It

Re: [time-nuts] GPS message jitter (was GPS for Nixie Clock)

Mark, Chris, Chris Albertson wrote: > Can't you take care of this in the build system? I never go near > Windows, the last version I used was Win 95. But on other systems I > always use something like the GNU Auto tools cmake or whatever and > part of the process is to check for the

Re: [time-nuts] GPS message jitter (was GPS for Nixie Clock)

You can also use the QueryPeformanceCounter and related functions for better precision. From: Mark Sims Heather's gotta work with XP (and maybe Win98)... too many people (including me) run it on old trashy laptops, so no fancy pants new fangled Windoze calls allowed... In the past I've

Re: [time-nuts] GPS message jitter (was GPS for Nixie Clock)

Can't you take care of this in the build system? I never go near Windows, the last version I used was Win 95. But on other systems I always use something like the GNU Auto tools cmake or whatever and part of the process is to check for the availability of each system call and library and then

Re: [time-nuts] GPS message jitter (was GPS for Nixie Clock)

From: Mark Sims I just added some code to Lady Heather to record and plot the time that the timing message arrived from the receiver (well, actually the time that the screen update routine was called, maybe a few microseconds difference). I am using my existing GetMsec() routine which on

Re: [time-nuts] GPS message jitter (was GPS for Nixie Clock)

Hi Mark, As one example of what you'll see, scroll down to the NMEA Latency/Jitter plot at: http://leapsecond.com/pages/MG1613S/ In that 900 sample (15 minutes) run, the mean latency was 350.2 ms with a standard deviation (jitter) of 10.7 ms. I'll dig out some other data I may have. It will