Re: [time-nuts] How does sawtooth compensation work?

On Mon, 18 Jul 2016 22:01:01 -0700, you wrote: >> It would be interesting to look at the data to see if you can find the sort > >Hi Hal, > >There's lots of examples of sawtooth patterns at: >http://leapsecond.com/pages/MG1613S/ > >In particular there's this monster:

[time-nuts] Trimble 63090/73090/65256

All: Have seen these offered on Ebay, but was curious which model has the better specs and a overall better unit. Can't find much on the internet for datasheets. I assume the 73xxx is the later model?. Or maybe the boards are all the same and it's just the OCXO that has the different part

Re: [time-nuts] How does sawtooth compensation work?

> It would be interesting to look at the data to see if you can find the sort Hi Hal, There's lots of examples of sawtooth patterns at: http://leapsecond.com/pages/MG1613S/ In particular there's this monster: http://leapsecond.com/pages/MG1613S/tic-72-hour.gif It's simple for a

Re: [time-nuts] How does sawtooth compensation work?

On Mon, 18 Jul 2016 21:41:51 -0700, you wrote: >> Or use the sawtooth compensation value to control an external variable >> delay line circuit > >Hi Mark, > >Right, one example is https://datasheets.maximintegrated.com/en/ds/DS1020.pdf >or google for silicon delay line. Not sure they're in

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] How does sawtooth compensation work?

nsa...@kfu.com said: > Yes, that’s true. Given the facilities I have available with the present > hardware, I don’t believe I have much choice. I am not confident that I > could tell the difference between noise in the phase detection system and > PPS jitter variations that small. If the PA6H

Re: [time-nuts] How does sawtooth compensation work?

> Or use the sawtooth compensation value to control an external variable delay > line circuit Hi Mark, Right, one example is https://datasheets.maximintegrated.com/en/ds/DS1020.pdf or google for silicon delay line. Not sure they're in production still but you can find them at the reseller

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

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

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

[time-nuts] How does sawtooth compensation work?

Or use the sawtooth compensation value to control an external variable delay line circuit to move around the PPS signal from the receiver. This can get interesting to implement if the receiver can output negative values for the sawtooth compensation (hint: add a bias to the sawtooth value to

Re: [time-nuts] Lucent boxes

Thanks Bill. I can use the RTFGm-XO by itself though, right? I found a site with mods to extract the 10 MHz Signal rather than use the 15 MHz. Chris > On Jul 18, 2016, at 20:54, Bill Hawkins wrote: > > No, it does not work, unless you can reprogram the microprocessors.

Re: [time-nuts] How does sawtooth compensation work?

> On Jul 18, 2016, at 3:55 PM, Hal Murray wrote: > >> The systems gravitate towards PLL time constants that average it all away. > > You are overlooking hanging bridges. Yes, that’s true. Given the facilities I have available with the present hardware, I don’t

Re: [time-nuts] How does sawtooth compensation work?

> On Jul 18, 2016, at 4:20 PM, Bob Camp wrote: > > On a receiver with sawtooth correction, you have a manufacturer specific > message that gives > you information on the state of the receiver. It is defined as either > applying to the next pps > or to the pps that just came

[time-nuts] GPS message jitter (preliminary results)

My LEA-6T board came out of one of those cheap Chinese drone pucks. It has a ceramic patch antenna on board. I have it sitting on the floor of the lower floor of a two-story, stucco over wire mesh house (not close to any windows). Same for some Sirf, Venus, and standard Ublox receivers.

[time-nuts] GPS message jitter (preliminary results)

Yes, turning on the display filter only gives an indication that one could gain some some benefit if they were to use the message arrival timing to implement some sort of NTP-ish algorithm to their 1PPS-less clock. I have added some options to Lady Heather calculate the adevs of the message

Re: [time-nuts] Allan Deviation recipe?

Yo Tom! On Mon, 18 Jul 2016 18:42:39 -0700 "Tom Van Baak" wrote: > Lots of ways to do it. There are GUI tools; command line tools, in C > or Python or Matlab. Got some C or Python? > But to start with I highly recommend using John's TimeLab: >

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] Lucent boxes

No, it does not work, unless you can reprogram the microprocessors. I speak from experience. The older boxes used a GPS receiver that reported up to 6 satellites. The newer boxes report 8. The messages that report satellite health have different lengths. If the micro reports an error in the

Re: [time-nuts] Allan Deviation recipe?

Gary, Lots of ways to do it. There are GUI tools; command line tools, in C or Python or Matlab. But to start with I highly recommend using John's TimeLab: http://www.ke5fx.com/timelab/readme.htm Here's a sample 1PPS phase (time interval error) data file (from a hp 53132A):

[time-nuts] ✘Allan Deviation recipe?

Yo time-nuts! I have a lot of logs of PPS offset data. Basically system clock time and PPS offset pairs. Does it make sense to turn this data into an Allan Deviation plot? If so, does anyone have a script or program to prepare the data for gnuplot? TIA. RGDS GARY

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

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:

Re: [time-nuts] How does sawtooth compensation work?

> I've read Tom's page about sawtooth PPS jitter and I believe I understand > where it comes from. A GPS timing receiver solves a bunch of equations at least once a second and it ends up with a pretty good idea, numerically speaking, of what the time is internally, relative to its local

Re: [time-nuts] How does sawtooth compensation work?

Hi Nick, Let's use the example of a Ublox timing receiver.  In the TIM-TP data package, there is a qErr value, which is the quantization error of the *next* PPS pulse output by the receiver.  At the next PPS, you would subtract that from the unwrapped phase measurement your GPSDO makes and

Re: [time-nuts] How does sawtooth compensation work?

Hi The sawtooth process “picks” the closest clock edge and spits out the PPS based on it. If the internal TCXO is off of a point that divides to 1Hz, the edge guess changes fairly often and you can average it out. A drifting TCXO will (effectively) never be at a modulo 1 Hz frequency long

Re: [time-nuts] How does sawtooth compensation work?

> The systems gravitate towards PLL time constants that average it all away. You are overlooking hanging bridges. -- These are my opinions. I hate spam. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to

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

[time-nuts] How does sawtooth compensation work?

I've read Tom's page about sawtooth PPS jitter and I believe I understand where it comes from.My current GPSDOs ignore the phenomenon. Certainly at the moment, I'm satisfied with that. The systems gravitate towards PLL time constants that average it all away. What I'd like to understand

Re: [time-nuts] GPS message jitter (preliminary results)

> Most definitely... if I turn on Lady Hather's display filter (which does a > sliding average > of "n" readings) the standard deviation and jitter values drop dramatically. > Be careful here. We're using standard deviation here as a measure of the instability, or noise, or jitter of the

Re: [time-nuts] Lucent boxes

Chris, The RFTGm ("m" for miniature even though still a large box) is a later version of the RFTG line. The XO unit houses the GPS receiver which is essential for disciplining. Both boxes operate at 24 VDC and there is an interface cable drawing on line at KO4BB's web site. Never tried to hook

[time-nuts] GPS message jitter (preliminary results)

Most definitely... if I turn on Lady Hather's display filter (which does a sliding average of "n" readings) the standard deviation and jitter values drop dramatically. With a 60 second filter the deviation was down to around .15 msecs and the peak-peak jitter below a millisecond. Average

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

[time-nuts] GPS message jitter (preliminary results)

I have seen some reports of some Skylab GPS boards that had some rather sketchy GPS code. A friend had one that was off around 0.5 degrees in longitude... but only if your location was between +/- 90 degrees longitude. He was on the east coast and had the problem. He sent it to me (96

Re: [time-nuts] GPS message jitter (preliminary results)

Hi Very nice data !! Hmmm….. software averaging against the MCU (or FPGA) clock source … NTP seems to get some pretty good results down into the single digit ms (or lower) doing that based on some equally jittery inputs. Looking at the data by eyeball (maybe not the best way): A 10 to 30

[time-nuts] GPS message jitter (preliminary results)

That plot was from a 12 hour run. I've done 48+ hour runs and did not see anything strange. I'm not currently measuring the offset of the message from the 1PPS, just the stability/jitter in the timings of the last byte of the timing message. If the timing message offset time from 1PPS

Re: [time-nuts] GPS message jitter (preliminary results)

> most receivers get the time messages out within a window less than 50 > milliseconds > wide with a standard deviation of less than 10 milliseconds. Hi Mark, For comparison with your data, attached is the ADEV+MDEV plot [1] for the SkyLab / MG1613S GPS board [2], the one with the 350 ms

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 (preliminary results)

Yo Mark! On Mon, 18 Jul 2016 18:30:08 + Mark Sims wrote: > A few generalizations: most receivers get the time messages out > within a window less than 50 milliseconds wide with a standard > deviation of less than 10 milliseconds. How long did you run your tests? My

[time-nuts] GPS message jitter (preliminary results)

Ooops, that tboltjit.gif plot was actually from a Trimble Resolution-T SMT timing receiver running with an indoor antenna, not a Thunderbolt. The Thunderbolt with an outdoor antenna is about twice as good. I just added the ability to feed the timing jitter value to Lady Heather's real 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

[time-nuts] GPS message jitter (preliminary results)

I added the ability for Lady Heather to measure a plot the difference of the arrival times of each timing message (actually the time when Lady Heather receives the last byte of the timing message from the operating system). The end-of-message arrival time is time stamped to nominally

Re: [time-nuts] 5061B Service Manual, Page 8-57 (BEAM I, if LOW)

And there is a free app from Steve Gibson to flip the registry bits required to make sure you don't upgrade without agreeing. https://www.grc.com/never10.htm On 7/17/2016 3:31 PM, John Allen wrote: > Hi to all - If you have been updated to Windows 10, you have 30 days to go > back to your old

[time-nuts] Lucent boxes

Hi Everyone, I have two Lucent RFTG boxes in my workshop. The XO is a loaner. I'm curious if they will interface with each other or (most likely) they are a different series as the interface connectors on each have a different number of pins. One is marked RFTG-u REF 0 The other is

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 Antenna

Hi On Jul 17, 2016, at 2:35 AM, David J Taylor wrote: Why is the noise figure so high on these antennas (2.5 dB)? Is that some pre-filtering, perhaps? They are designed as timing antennas. That normally puts them in a “lots of RF” environment. (like a cell