Re: [time-nuts] NCOCXO anyone?

rich...@karlquist.com said: > Also in 1996, phase microsteppers were already legacy technology and didn't > have a good reputation for spectral purity. Another non-panacea. What is a phase microstepper and/or how does it compare to a DDS? (Google gets lots of hits, but they all refer to

[time-nuts] LeoNTP Networked Time Server now available

You might be interested in the LeoNTP Networked Time Server, which is now available: https://store.uputronics.com/index.php?route=product/product_id=92=ntp "LeoNTP is a Stratum 1 time server with GPS synchronised clock source designed from the ground up with the sole purpose of providing

Re: [time-nuts] NCOCXO anyone?

On Thu, 21 Jul 2016 18:47:24 -0700, you wrote: >On 7/21/2016 4:56 PM, Nick Sayer via time-nuts wrote: > >> Oh my. That’s a bit more than I was originally considering… What I had in >> mind was adding a DAC front end to an OCXO so that you could tune the EFC >> with serial commands rather than

Re: [time-nuts] LSEM (Leap Second Every Month)

On Thursday, July 21, 2016, Michael Wouters wrote: > Apropos Bob's comments, the problem of ambiguous timestamps during a > leap second, at least with current operating systems, is only made > worse by more frequent leap seconds. > > Making critical systems run on a

Re: [time-nuts] NCOCXO anyone?

On 7/21/2016 4:56 PM, Nick Sayer via time-nuts wrote: Oh my. That’s a bit more than I was originally considering… What I had in mind was adding a DAC front end to an OCXO so that you could tune the EFC with serial commands rather than analog and calling that a product. 20 years ago when

Re: [time-nuts] NCOCXO anyone?

Hi Ideally a phase micro stepper would have an ADEV floor that is lower than anything you would run through it. That way the ADEV in would be the same as the ADEV out. Since there are things out there that are lower ADEV than an OCXO, that’s not a good thing to put in the middle of the beast.

Re: [time-nuts] NCOCXO anyone?

Hi > On Jul 21, 2016, at 7:17 PM, Poul-Henning Kamp wrote: > > > In message <4763643485B04450A76F7C04BA8CFB63@pc52>, "Tom Van Baak" writes: > >> There are highly-prized commercial instruments that do this. But >> no amateur has tried yet. > > It would be more

Re: [time-nuts] NCOCXO anyone?

Oh my. That’s a bit more than I was originally considering… What I had in mind was adding a DAC front end to an OCXO so that you could tune the EFC with serial commands rather than analog and calling that a product. A simple version of what you seem to be describing, however, *sounds* to me

Re: [time-nuts] Leap second to be introduced at midnight UTC December 31 this year

On Thu, Jul 21, 2016 at 5:27 PM, Tom Van Baak wrote: > Time to mention this again... > > If we adopted the LSEM (Leap Second Every Month) model then none of this > would be a problem. The idea is not to decide *if* there will be leap second, > but to force every month to

Re: [time-nuts] LSEM (Leap Second Every Month)

Hi A leap millisecond …. there’s an idea to explain to grandma. If you accept the idea that we need a leap second ever year or three, it’s not going to be a millisecond. Something messy would be required if you went below 100 ms. 100 ms would (barely) accommodate a “once a year” leap

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

Yes, I know about those. I think the ubloc line has a version that does this but it is made for the automotive roadmap type display. I think the way to learn is to jump in and make one. Start by re-implementing an example filter then go the next step and the next. On Thu, Jul 21, 2016 at 7:34

Re: [time-nuts] LSEM (Leap Second Every Month)

Apropos Bob's comments, the problem of ambiguous timestamps during a leap second, at least with current operating systems, is only made worse by more frequent leap seconds. Making critical systems run on a leap second free time scale like TAI, for example, just shifts the problem to the interface

Re: [time-nuts] LSEM (Leap Second Every Month)

> If UTC time was adjusted every month would stick with one full second? Or > some smaller quantity? Hi Scott, The LSEM month suggestion retains the UTC policy of leaps being exactly +1 or -1 second, never larger, never smaller. There's a world of hurt if anyone even dreamed of shifting UTC by

Re: [time-nuts] NCOCXO anyone?

In message <4763643485B04450A76F7C04BA8CFB63@pc52>, "Tom Van Baak" writes: >There are highly-prized commercial instruments that do this. But >no amateur has tried yet. It would be more precise to say that no amateur has been willing to talk about their results yet. I personally know

Re: [time-nuts] [LEAPSECS] Leap second to be introduced at midnight UTC December 31 this year

On 7/21/2016 2:53 PM, Steve Allen wrote: > On Thu 2016-07-21T10:27:57 -0700, Tom Van Baak hath writ: >> Time to mention this again... >> Every UTC-aware device would 1) know how to reliably insert or >> delete a leap second, because bugs would be found by developers within >> a month or two, not

Re: [time-nuts] NCOCXO anyone?

Hi Nick, There may be several threads in the time-nuts archives related to your question. The greater concept is a phase microstepper (aka microphase stepper). Imagine a small board that takes =10 MHz in and puts ~10 MHz out. Using RS232 (or SPI or I2C) you control the phase, or even the phase

Re: [time-nuts] LSEM (Leap Second Every Month)

But would it really solve your problems, Jim?  The problem is essentially that periodically, there are two different clock times that represent the same moment in time.  For telescopes, stock markets, spread spectrum, time-based encryption, etc that's a big problem.  Would it not be better to

Re: [time-nuts] [LEAPSECS] Leap second to be introduced at midnight UTC December 31 this year

> This idea pushes extra complexity into every implementation of low > level kernel-space software, firmware, and hardware. That's nice as a > policy for full employment of programmers, but it's hard to justify by > any other metric. Instead those low level places should be as simple > as

Re: [time-nuts] LSEM (Leap Second Every Month)

If UTC time was adjusted every month would stick with one full second? Or some smaller quantity? On Thursday, 21 July 2016, Brooke Clarke wrote: > Hi Tom: > > I like this idea. I addresses the lesson from Y2K that something done > often works much better than something done

Re: [time-nuts] Leap second to be introduced at midnight UTC December 31 this year

Hi Tom, > Does your proposal allow for a Zero leap second Nope, LSEM avoids the zero leap second situation. That's the idea: to always have a leap second. Either an add or a delete, at the end of every month. The beauty is that it wouldn't violate how UTC is already defined. Leap seconds

Re: [time-nuts] LSEM (Leap Second Every Month)

The idea is the same as my local telco and their main exchanges. Every month they walk up to the main circuit breaker and cut the power to the entire building. All the UPSs and diesel generators get tested in anger. This leap second solution is the best I've heard so far. Personally I now hate

Re: [time-nuts] [LEAPSECS] Leap second to be introduced at midnight UTC December 31 this year

Steve Allen wrote: > This idea pushes extra complexity into every implementation of low > level kernel-space software, firmware, and hardware. That's nice as a > policy for full employment of programmers, but it's hard to justify by > any other metric. Instead those low level places should be as

Re: [time-nuts] [LEAPSECS] Leap second to be introduced at midnight UTC December 31 this year

I was inclined to agree, cynically reasoning that many implementations would argue that the leapseconds would average out in most applications and they could ignore them. But actually, it would be good for programmers to properly separate the concepts of elapsed time and clock-time. If elapsed

Re: [time-nuts] [LEAPSECS] Leap second to be introduced at midnight UTC December 31 this year

On Thu 2016-07-21T10:27:57 -0700, Tom Van Baak hath writ: > Time to mention this again... > Every UTC-aware device would 1) know how to reliably insert or > delete a leap second, because bugs would be found by developers within > a month or two, not by end-users years or decades in the future,

[time-nuts] LSEM (Leap Second Every Month)

Hi Tom: I like this idea. I addresses the lesson from Y2K that something done often works much better than something done only occasionally. That's way you see the firetruck at the local store, because it's used all the time and so is more likely to work when needed. -- Have Fun, Brooke

Re: [time-nuts] Leap second to be introduced at midnight UTC December 31 this year

Hi If you have a “zero option” then nothing ever gets tested. It always sits at zero and gets ignored. If you dither back and forth +/- 1 second, it’s tested every month. The faulty system that does not follow the signal gets spotted and fixed. Bob > On Jul 21, 2016, at 3:03 PM, Tom Holmes

Re: [time-nuts] Leap second to be introduced at midnight UTC December 31 this year

Hi Tom... Does your proposal allow for a Zero leap second, or does it require either plus or minus 1 to work? Seems like you could stay closer to the true value if you also have a zero option. Might also cause less consternation for some services, like the finance and scientific worlds, that

[time-nuts] 1 second timing error re leap second

I saw no problems with Ublox Neo 6M, LEA-5T, LEA-6T, Ublox 7, or Ublox 8 receivers. A Synergy M12+ did not report the leap pending in the @@Bj message, but did in the @@Gj message. - Anyone know if the M12T or Lea Bloc GPS chips have the same problem as the

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

I bit bang serial all the time... it is much easier if to do if you are only banging serial output. Reading serial streams at higher bit rates while doing other useful stuff can be challenging... particularly if you don't have a timer handy. I once coded up a PIC to output a time code /

Re: [time-nuts] Seiko watch "leap second enabled"

The watch is fine. Ive intentionally set it to be off time to have it automatically recover with essentially leap second precision. On 21 Jul 2016 3:25 p.m., "Mike Cook" wrote: > While I was googling for reports of other misbehaving GPS chips, I > discovered the existence

Re: [time-nuts] 1 second timing error re leap second

Hello, Anyone know if the M12T or Lea Bloc GPS chips have the same problem as the Trimble products Regards Martyn = Do you mean ublox LEA6T? Ublox chips have generally been OK in the past, although I've not checked the LEA 6T. David -- SatSignal

Re: [time-nuts] [LEAPSECS] Leap second to be introduced at midnight UTC December 31 this year

Hi Tom, This message is an excellent example of why we invited you to speak at the Science of Time symposium ;-) It was a shame you couldn’t make it, since you would have made an excellent meeting even stronger. But future meetings in the series seem very likely and let me register an

Re: [time-nuts] Leap second to be introduced at midnight UTC December 31 this year

Every year... always makes me wonder, do these vendors even test this themselves? I know at least one vendor who disn't have GPS simulators and relied on Trimble's built-in test mode - which gives you 13-bit week counters, whereas the satellites give you 10-bit counters. So the vendor assumed

Re: [time-nuts] Leap second to be introduced at midnight UTC December 31 this year

Time to mention this again... If we adopted the LSEM (Leap Second Every Month) model then none of this would be a problem. The idea is not to decide *if* there will be leap second, but to force every month to have a leap second. The IERS decision is then what the *sign* of the leap second

[time-nuts] 1 second timing error re leap second

Hello, Anyone know if the M12T or Lea Bloc GPS chips have the same problem as the Trimble products Regards Martyn ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and

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

Here is an interesting discussion of Kalman filtering. http://math.stackexchange.com/questions/173901/why-use-a-kalman-filter-instead-of-keeping-a-running-average Thomas D. Erb t...@electrictime.com / Electric Time Company, Inc. Office: 508-359-4396 x 117 / Fax:

[time-nuts] NCOCXO anyone?

Would anyone see any value in a board that had an OH300 with a serial interface for tuning? I had a thought perhaps to make one starting with my GPSDO and just ditching the GPS part and possibly adding an RS-232 level converter. I could conceivably bring it all out to a DB9 and emulate an

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

> On another note, I did some jitter measurements on Jupiter-T and Jupiter-T > Pico receivers. > I can't imagine how they do it, but those things are insanely good. Running > at 9600 baud, > their message jitter into a hardware serial port is less than a millisecond > peak-peak! > Somebody

Re: [time-nuts] Leap second to be introduced at midnight UTC December 31 this year

> On Jul 21, 2016, at 5:23 AM, Hal Murray wrote: > > > noah.ro...@gmail.com said: >> Discovered that my commercial GPS appliances opted to *apply* yesterday's >> pending leap second, which has made for an interesting day. > > Could you please say more? > > How are

Re: [time-nuts] Syncing Tom's PICDivs to 1PPS

Some models support synchronization to a external (PPS) reference. Take a look at http://leapsecond.com/pic/picdiv.htm Edésio On Thu, Jul 21, 2016 at 10:05:15AM -0400, Scott Stobbe wrote: > I think you will have to decided if you want both your xo (presumably 10 > MHz) and PPS to be phase

Re: [time-nuts] Syncing Tom's PICDivs to 1PPS

Hi Bob, Many of the PIC divider programs that I wrote include an arm-sync feature, which is useful to capture a 1PPS and align the divider to UTC. The source code to most of them are at http://leapsecond.com/pic/src/ and you can use it as a model. These make use of the fact that PIC

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

If your not bean counting for a commercial product you can take a look at particle filtering, its like a real-time monte-carlo simulation. The location estimate in NEMA is also heavily filtered and referenced to its utc time estimate (PPS). Conceivably could be filtered to a bandwidth of Fs/2,

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

A lot of the newer GPS modules can accept "dead reckoning" data from external sensors and integrate that into their location solutions. The receiver does all the Kalman filtering foo for you. Also you can get receivers with up to 50Hz position updates (you have to run the com link at very

Re: [time-nuts] Syncing Tom's PICDivs to 1PPS

I think you will have to decided if you want both your xo (presumably 10 MHz) and PPS to be phase aligned to UTC. No matter which way you go you will have propagation delay across a clock divider. If you just want your PPS to be on phase, you can steer your xo. On Thu, Jul 21, 2016 at 12:11 AM,

Re: [time-nuts] Leap second to be introduced at midnight UTC December 31 this year

noah.ro...@gmail.com said: > Discovered that my commercial GPS appliances opted to *apply* yesterday's > pending leap second, which has made for an interesting day. Could you please say more? How are you working around it? Vendor? Model? Can you take the cover off (or peer in through the

Re: [time-nuts] Leap second to be introduced at midnight UTC December 31 this year

Trimble Res-SMT-GG GNSS receivers are affected; in my case, they're installed in Spectracom SecureSyncs. And yes, the extra second got into system time which broke 1 or 2 things. --n > On Jul 20, 2016, at 5:26 PM, Gary E. Miller wrote: > > Yo Noah! > > On Wed, 20 Jul 2016