really slow PLL

I feel like there wasn't really a good relatively inexpensive standard for interfacing PC peripherals until USB. Serial and parallel were slow (occasionally some devices supported ECP, I remember having to enable it in the BIOS sometimes), and external SCSI wasn't really well-suited to anything but external disk drives.

I don't think you could hot-swap IEE-488 either but it seems like it was pretty fast and more amenable to a wide class of devices than SCSI, but just didn't seem to catch on outside the test equipment realm.

Oops I forgot about AppleTalk. I remember helping some students get their Mac SEs on the Internet (email and FTP and maybe some basic web browsing I can't recall) via some kind of Ethernet to AppleTalk adapter, it wasn't uncommon in the mid 90s for college students to be using hand-me-down Macs from the 80s, but I couldn't for the life of me now remember how I did it.

afaik Apple talk was just a serialport with an RS422 transceiver instead of RS232

Sounds right, for the physical layer. On the data link layer it was smarter than a raw serial port though, IIRC for simple configurations of peripherals it configured itself.

On a sunny day (Thu, 21 Jul 2022 14:52:44 +0200) it happened Gerhard Hoffmann snipped-for-privacy@arcor.de wrote in <tbbi6s$ghm7$ snipped-for-privacy@solani.org:

I have a 10 MHz rubidium reference from ebay (used) I think John has one too, he inspired me to buy one :-)

rubidium reference is on its side on the loft. It is not true GPS receivers are mostly software some counters will do, when GPS started not so much super computahs around.. I'v played some with it, including doing it in software only:

On a sunny day (Thu, 21 Jul 2022 12:35:52 -0400) it happened bitrex snipped-for-privacy@example.net wrote in <JffCK.582999$X snipped-for-privacy@fx18.iad:

Yea, used it every day back then :-) audio-video sync

"The Dollar stuff was the first stuff I really produced, after being in Yes in 1982, and by that time I had a rig. Very few people had rigs back then, but I had one and it consisted of a Roland TR808 and a set of Simmons drum modules.

Dave Simmons had modified my TR808 and put on a set of triggers so that the kick drum from the 808 would also trigger the Simmons kick drum. On top of that, I had a Roland sequencer. I've forgotten what serial number it was, but I've still got it somewhere. It had four buttons — 'A', 'B', 'C' and 'D'. You put lists of notes in it and it played the list of notes. You sent a trigger to it.

I used to use the cowbell from the 808 as a trigger — you sent it and it would play through the list of notes. So you might put four 'G's and an 'A' and a 'B', and however you played it, it would loop that list of notes. That sequencer was hooked up to a Minimoog that had CV and Gate on it.

And with that rig I thee wed! You know, those CV/Gate things were much tighter than MIDI. They were spot bollock on! Spot on. Much better feel than just your normal MIDI rig these days."

Exactly. It's weird really, since the GPS P code bit rate is 10.23Mbps, meaning the PRNG shift registers are being clocked with 10.23MHz. Perhaps the phase noise of the 10.23MHz clock isn't that critial...

At that rate, a 1-bit misalignment is 30m of distance. To get better accuracy you need a polyphase clock, and the correlation would move a shift register's clock to a clock which is forwards or back in phase from its current clock, rather than just skipping or adding clock pulses.

The Apollo ranging system used a bit rate around 1Mbps, but could resolve down to about 1m, or approximately 1 degrees of clock phase. If GPS could do that, it would be accurate to 10cm.

So anyhow, folk love their "GPSDO" 10MHz clock outputs often without really questioning the actual phase noise coming from the internal oscillator which synthesizes that output, and which ultimately isn't even the clock that's being used to recover the signals.

Clifford Heath.

If you're rolling your own PROPRIETARY protocol, you can design the stack so that really tight (limited by hardware layer) latencies are possible. E.g., if your protocol KNOWS that a "sync" will be "coming along shortly", the code can take steps to minimize the time required to detect and respond to that.

How else would you synchronize events generated (or DETECTED!) across boxes? Run a separate wire for each event?

Because standards try to address ALL POSSIBLE users of a particular feature/mechanism.

Done "as intended", PTP requires timestamping hardware in the NIC to note when the packets actually hit (or come off) the wire. With a good deal of care, you can get sub-microsecond synchronization between nodes. But, swap the switch or let network traffic change significantly (e.g., unconstrained) and all bets are off.

If all you are trying to do is synchronize some notion of time across devices, why take on all the overhead of an NIC, network stack, PTP protocol, etc. JUST for that?

How tightly must the time references be synchronized? How tightly must they REMAIN synchronized (local oscillators drift at different rates)?

OTOH, if those mechanisms are already present/needed in your product/design, then bolting PTP on top can make sense.

But, *how* you do that is your own decision -- if you don't need to "play nice" with other vendors' products, then why take on the cost of doing so? (why so many oddball "serial port" connectors and implementations, over the years? wasn't there ONE standard??)

[As to the "hack", you underestimate how powerful the notion of just being able to say "do this at t=X" is in designing a box!]

The biggest downside with shared resources -- esp ones that are as crucial as this -- is sorting out how to handle the situation when that resource fails or is unavailable. E.g., PTP allows a new master to be elected. Fine. But, implicit in that is the fact that the old master is now "not functional"... can you continue to operate under those conditions?

Interesting, thanks.

Some frequency synthesiser chips employ proprietary majick to reduce the phase noise associated with integer divide/multiply ratios. Polyphase oscillator and slipping by partial cycles I think. Perhaps they're doing something like closure against the different clock phases?

Clifford Heath

If you ever apply a command time setting once, and they have the same speed, they will stay aligned. It'd be an improvement over letting the clocks drift for a second at a time, then correcting. I'm not sure what 'measure the incoming period' has to do with it, though; just use an up/down counter to compare leader to follower, and D/A the count to trim the VCO.

All it takes to sense a frequency difference is a counter. Negative feedback nulls the difference.

"GPSDOs typically phase-align the internal flywheel oscillator to the GPS signal by using dividers to generate a 1PPS signal from the reference oscillator, then phase comparing this 1PPS signal to the GPS-generated 1PPS signal and using the phase differences to control the local oscillator frequency in small adjustments via the tracking loop."

That's what I meant: the 10M xo is locked to the 1 PPS GPS output.

The GPS 1 PPS is perfect (by definition) long-term but terrible short-term, so the XO or rubidium has to be very good itself, and the loop has to be very slow. Big flywheel.

I'll be doing something similar, locking my 40 MHz clock to some 1 PPS input, the difference being that I don't mind a few us of jitter, so I can lock quick and crude.

There should be a third BNC, or a D9 or something. Synchronizing boxes has et up all my general-puropse i/o's.

The design intended the outputs to be relay drivers with debounced schmitt-trigger inputs. So they are fairly slow. And lots of people have a 1 PPS GPS thing.

No, I can really time align long-term, after the first accepted 1 PPS pulse. I've presented that in another post. One BNC locks the timebases and the other starts sequences, all together.

It's only a power supply, so we don't need absolute timing to nanoseconds. Switchers alone add microsecond or even millisecond-scale uncertainty to the analog outputs.

GPS timing isn't completely perfect in reality. Antennas blow off roofs, contractors cut cables etc. Even losing sync for a minute is sort of a big deal. As you mentioned, jitter is the real problem. There are tradeoffs to making a flywheel thats too heavy so to speak.

For really fussy stuff, one might have multiple GPS receivers and a quorum of local 10Mhz oscillators. In fact, 10Mhz is a dinosaur relic for modern stuff too. We've got racks of 10Mhz oscillators and equipment to monitor any phase shift between local oscillators and GPS sources. It's all going to the dumpster when somebody finally notices it's been powered down and forgotten about.

Fairly accurate nS resolution timing is possible in computers these days, with the right tricks.

Do you have to worry about fun issues like an the timestamp of a signal being received before it was even transmitted between pieces of equipment?

I like the toggle switches on the USNO hydrogen masers:

They were originally made by some weird company called Sigma Tau. Somehow, Microchip owns them now. New models have a new paint job, but still look like they might be a transit case for a Dalek.

Quite probably - it has been known for a long time in radio astronomy first derived by Jennison in 1958 at Jodrell Bank for 3 antennae. This is the original ground breaking paper for anyone interested

(easier to understand versions exist today). WIki isn't bad:

It allows you to get a good phase observable uncontaminated by the phase error at each node for every distinct subset of 3 nodes. There is a corresponding closure amplitude for distinct subsets of 4 nodes.

Obviously the bigger N is the more useful observables you can get which is why the big dish telescopes sometimes stay on target and in the loop for perhaps longer than they really ought to in deteriorating weather.

This book reviews most of the classical tricks used in VLBI and interferometry from the period when they had just become routine:

Indirect Imaging: Measurement and Processing for Indirect Imaging Editor-J. A. Roberts 0 ratings by Goodreads ISBN 10: 0521262828 / ISBN 13: 9780521262828 Published by Cambridge University Press, 1984

Am 22.07.22 um 04:47 schrieb snipped-for-privacy@highlandsniptechnology.com:

No. The 1pps is asserted when the CPU thinks it's closest to the "right" clockcycle. It could be off by half a cycle. There is no need for 10 MHz, one could have chosen a nice multiple of the desired baud rate.

The 1pps does not control the clock, its the huge state vector in the CPU that does. 1pps is only an approximation, that's why it's so bad in the short term.

Locking an oscillator via 1pps is only done when there is nothing better available, outside the GPS box.

< >

Cheers, Gerhard