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
> has a different time).
A lot of GPS receivers either don't support the ZDA message, or turn it off by
default. And many (most?) that do send it send the time with millisecond
resolution.
The NMEA sentences for sending date and time were very poorly thought out.
Several different sentences can contain the time (ma
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 h
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 line is
> pined out.
The o
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 th
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:
>>
>>
>> jim...@earthlink.net sai
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 some
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:
>> except that virtually every UA
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 5
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 sp
an ESD device, etc.
> Bob
> -
> AE6RV.com
>
> GFS GPSDO list:
> groups.yahoo.com/neo/groups/GFS-GPSDOs/info
>
> From: jimlux
> To: time-nuts@febo.com
> Sent: Monday, July 18, 2016 5:46 PM
> Subject: R
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 constan
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 redu
/groups/GFS-GPSDOs/info
From: jimlux
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 hardware (consumer PC) is not
>
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 U
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 wire
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
anywa
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.
>
>De
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 m
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.
>
> Most UARTs I have come across
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
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
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 w
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 availability
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 avo
Very few people have the ability to build Lady Heather for Windoze from
source... pretty much everybodyl uses the binary. Having people build from
source is not an option (except on Linux, it's relatively painless and the
tools are easily available and free, plus Linux users tend to know what
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 the
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 avoided the use of QueryPerformanceCounter due to potential
issues with AMD processors, multi-core processors a
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 Wind
illisecond or even microsecond time interval resolution.
/tvb
- Original Message -
From: "Mark Sims"
To:
Sent: Saturday, July 16, 2016 12:13 PM
Subject: [time-nuts] GPS message jitter (was GPS for Nixie Clock)
>I just added some code to Lady Heather to record and plot the
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 Windoze actually ha
31 matches
Mail list logo
