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 wire
from the CPU interface.
Determinism in UART timing between the CPU bus interface and the "bits
on the wire" has never been something that is specified. You can go
back to venerable parts like the 8251, and there's no spec in the data
sheet.
( there's a tCR specified as 16 tCY for the read setup time from CTS*,
DSR* to READ* assert. And tSRX (2 usec min) and tHRX (2 usec min) for
the setup and hold of the internal sampling pulse relative to RxD. And
20 tCY as a max from center of stop bit to RxRDY, and then whatever the
delay is from the internal RxRDY to the bus read)
Long ago I remember seeing a circuit design or application note using
an 8250 or similar where the UART start bit was gated so that the
leading edge could be used for precision synchronization.
And it probably depended on idiosyncratic behavior of the 8250 and
fooling with the transmit clock input to the chip. That is, a part
that claimed "8250 emulation" may or may not work the same. Sort of
like Printer ports on IBM PCs.. they'd all work with a unidirectional
Centronics printer, some would work as a bidirectional port, some wouldn't.
As soon as you get to parts that have the baudrate generator internally
or which are highly integrated multiprotocol chips (like the Zilog do
everything dual serial port) it gets much trickier.
I had a terrible time a couple years ago getting a synchronous RS422
interface (1 pair with clock at symbol rate + 1 pair with data) that
would easily interface to a PC. Most of the "synchronous RS422"
interfaces out there use one of the multiprotocol chips which support
BiSync, HDLC, etc. and they try to find sync characters or stuff flags,
etc. but not very many support "raw synchronous"
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 USB clock (since it has to recover it
anyways to get the usb data).
The USB interface timing is going to be buried deep, deep inside some
microcontroller or ASIC. Imagine a FTDI part, for instance. I can't
imagine a GPS mfr caring enough about this to spend any money on trying
to figure out how to do it.
Interestingly enough, the Ublox LEA series of timing receivers has a USB port which you can connect directly to a USB cable. Of course you want to use an ESD device, etc.
Bob
-----------------------------------------------------------------
AE6RV.com
GFS GPSDO list:
groups.yahoo.com/neo/groups/GFS-GPSDOs/info
From: jimlux <jimlux@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 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
anyways to get the usb data).
The USB interface timing is going to be buried deep, deep inside some
microcontroller or ASIC. Imagine a FTDI part, for instance. I can't
imagine a GPS mfr caring enough about this to spend any money on trying
to figure out how to do it.
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Bob, Thanks for the nudge towards Ublox. USB was a bit of blue sky thinking.
I took a look at the LEA-M8F module which by default includes a VCTCXO.
Will also take care of disciplining an (VC)OCXO provided a DAC is included.
What was interesting to me is you can "exchange" time it, copied from the HW
Integration Manual
https://www.u-blox.com/sites/default/files/products/documents/LEA-M8F_HIM_%28UBX-14000034%29.pdf
1.6.3 FREQ_PHASE_IN0 / EXINT0, FREQ_PHASE_IN1 / EXTINT1 These two
frequency/phase inputs are provided for connecting an external source of
phase (pulse stream) or frequency reference into the module. The pulse
stream can be derived from a frequency reference or external
synchronization source. The module will measure and report the phase or
frequency offset of this input with respect to the current synchronization
source and optionally steer the related oscillator to bring the externally
derived pulses into alignment
On Mon, Jul 18, 2016 at 7:28 PM, Bob Stewart bob@evoria.net wrote:
Interestingly enough, the Ublox LEA series of timing receivers has a USB
port which you can connect directly to a USB cable. Of course you want to
use an ESD device, etc.
Bob
AE6RV.com
GFS GPSDO list:
groups.yahoo.com/neo/groups/GFS-GPSDOs/info
From: jimlux <jimlux@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 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
anyways to get the usb data).
The USB interface timing is going to be buried deep, deep inside some
microcontroller or ASIC. Imagine a FTDI part, for instance. I can't
imagine a GPS mfr caring enough about this to spend any money on trying
to figure out how to do it.
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
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 500 ms from the
time mark or PPS signal. The serial string would just sit in the transmit
buffer until the fixed delay expires and the UART starts transmitting.
It was a Garmin problem, and they released updated firmware after some
badgering.
Again, it's nothing to do with serial communication, but CPU loading.
Many GPS devices can only just send the default information at default speed
(typically 4800/9600), so the UART would need quite a lot of buffering for
such a scheme to work. For any serious use, the PPS line is the way to go.
Cheers,
David
SatSignal Software - Quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-taylor@blueyonder.co.uk
Twitter: @gm8arv
On Mon, Jul 18, 2016 at 10:44 AM, Scott Stobbe scott.j.stobbe@gmail.com 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 original GPS designers where sending NMEA-0183 data out to devices
that accept and use NMEA data. GPS was not the first to work with
NMEA. Lots of other instruments also output NMEA. I doubt they ever
would have envisioned people using NMEA data for precision timing.
Typically if you want to do precision timing you's use a GPS that
outputs some binary data format. NMEA-0183 does not have flow control
--
Chris Albertson
Redondo Beach, California
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 have never read the official NMEA-0183 specification.
Just a sample from an unoffical NMEA0183.pdf
http://www.tronico.fi/OH6NT/docs/NMEA0183.pdf
ZDA Time & Date – UTC, Day, Month, Year and Local Time Zone
$--ZDA,hhmmss.ss,xx,xx,xxxx,xx,xxhh*
So for a GPS or a timing unit on a NMEA-0183 bus, do they report their best
estimate of time to the nearest 10ms when the packet is sent? (since a PPS
line isn't shared)
On Tue, Jul 19, 2016 at 1:17 PM, Chris Albertson albertson.chris@gmail.com
wrote:
On Mon, Jul 18, 2016 at 10:44 AM, Scott Stobbe scott.j.stobbe@gmail.com
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 original GPS designers where sending NMEA-0183 data out to devices
that accept and use NMEA data. GPS was not the first to work with
NMEA. Lots of other instruments also output NMEA. I doubt they ever
would have envisioned people using NMEA data for precision timing.
Typically if you want to do precision timing you's use a GPS that
outputs some binary data format. NMEA-0183 does not have flow control
--
Chris Albertson
Redondo Beach, California
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.