You would have lower systematic error after lockin if you made the adjustments by reading the full width counter as a two's compliment number when the synch pulse arrives (and using a 2^N counter).
Unless you are very wedded to base 10 it might well work better to use a hardware 16 or 24 bit counter and allow it to free run. The master clock time pulses could be at some suitable power of 2^N x 0.1us.
Under software control you could even do quick corrections in the first second to get the basic frequency of all clocks approximately right.
The master could produce a set of pulses that were 1/16s, 1/8s, 1/4s,
1/2, 1s long at the outset. That would speed up the lock in time.
If you want to get the clocks on the various boxes as close to in synch as possible then it makes sense to correct any errors quickly.
Power of 2 steps decreasing to some floor level being most favourable.
There were bidirectional parallel ports that could run fairly quick. A parallel port interface for a CD drive was just about doable on a bog standard PC parallel port.
SCSI was quite good for external bulk data devices like scanners too. It's disadvantage was cost.
I recall early versions of USB 1.x very unfondly. ISTR the acronym was originally take to be Unusable Serial Bus (cf Firewire implementations). It slowly improved with successive Doze versions to become merely Unstable Serial Bus. Firewire easily left it standing.
formatting link
USB eventually won out by being cheaper. Much like VHS vs Betamax - the superior technology was effectively sidelined by popularity of the rival. Even today there are USB peripherals that never come back when a PC goes into sleep mode without being unplugged and plugged in again.
GPIB and HPIB was fairly common on desktop computers in the early 80's.
HP and Commodore used it for their external disk drives. We hacked an interface for the Commodore hard disk drive but the HP harddrive blinded the bus analysers of the day and by the time we had hacked it cheaper options were already available. It survived as a niche instrumentation bus until the turn of the century and is possibly still used by some. The instruments using it still being pretty good kit.
Token ring WAN over cheap twisted pairs took over for a while in my neck of the woods before truly fast Ethernet really got going. (it was an academic predecessor of IBM's token ring offering)
Early fast ethernet distribution was on expensive thick heavy coax cable marked up with where to tap into them. The cost difference for wiring up was enormous. Physically manhandling the cable was a PITA.
But old ports (without queues) were a bitch for the processor to service.
And cable length. Aside from differential (even costlier), you were stuck to "arm's reach". At least serial and USB can be pushed to longer lengths (despite limitations of their respective standards).
IBM's suffered from the same sort of costs as SCSI with their big, klunky connectors.
Ah, yes. "Orange hose" and vampire taps. I suspect one could make a pretty little structure (think: Lincoln Logs) out of lengths of that! A likely factor in its lack of ubiquity.
I rely on network connectivity for an increasing number of appliances, now. Scanners (direct network connections or USB to SBC host), disks (iSCSI), printers (direct network connections or dedicated print server appliance), other computers, etc.
But, all of the T/TX technologies make cabling a PITA. Every cable has to travel all the way to a switch, even if some other networked device is nearby (e.g., 10Base2 would tolerate device insertion with just a short length of coax -- though the entire network was disrupted in the process!) I have thick bundles of CAT5e affixed to the undersides of my workbenches as the cables from each device (on or under the bench) join the bundle as it travels to the east or west switch. Add a new device? Ugh!
IMO, most interfaces fall down (in practical terms) when it comes to the choice of connector. Either too cheap (flimsy) or too costly. The RJ45/8P8C wins in terms of cost... but is a nuisance when the locking tab inevitably breaks off (even if "guarded"): "Great! Now I either repair the cable or replace it!"
And, inevitably, connectors require a bit of "fiddling" to ensure oriented correctly and mated well. How many times do you discover a bent pin on a HD SCSI cable only because the interface refuses to run properly? (and trying to repair said pin is essentially impossible).
And, of course, the wide choice of "standards" (SCSI cables being among the worst for lack of uniformity: Old Sun, Apple, SCSI, SCSI2, SCSI3, VHDCI, etc.)
The ideal connector wouldn't have a top or bottom (etc.) Something like a phone plug where all you have to do is line up plug to hole and jam it home. Considering most connectors reside on the backs of equipment, expecting the user to be able to VIEW the mate while attempting to connect is wishful thinking!
Yes, I discovered the perils of blind plugging when I tried to plug something in deep inside a rack cabinet. My finger discovered an unguarded fan and it initially felt like an electric shock. I pulled my arm back so fast I hit my face and got a nosebleed! John
I had a similar experience groping for the right place to plug a device and happened upon an exposed bus bar. Only 12V (at 100A) but sufficient to vaporize the leads on the device I was plugging!
And, cause me to retract my arm in utmost haste -- whacking my elbow in the process.
Moral of story: shut down power before making changes (even if that sequence takes a fair bit of time to complete!)
Yes, it could evaluate the magnitude of the time error and close a classic almost-analog control loop. The plant is already an integrator so it could be a simple proportional loop.
My xo is 40 MHz and 1 PPS is convenient, GPS compatible.
The loop will be software, once an FPGA provides the measurements. All the VCXOs will park, open-loop before we try to lock, at some calibrated nominally correct frequency, not many PPM off absolute.
It's only a power supply!
If it takes 10 seconds to achieve dither-lock, starting 10 PPM out, the worst time error is still way under a millisecond.
I triggered a scope from a very good ovenized XO and looked at the rising edge of a rubidium. The edge looked solid, as if it was internal triggered. Checking every 20 minutes or so, it ws slowly creeping across the screen, at 5 ns/cm.
I believe they somehow pair the rubidium clocks with another quartz crystal, even in those new tiny physics modules. I've not had a chance to tear apart a rubidium clock yet, or the ovenized stuff. They come in little metal boxes, that remind me of TV tuners.
You were also asking about timestamping in other posts. Not entirely sure what you're upto in the end, but it might be interesting.
What he's trying to say is it may not be perfect 10 million cycles between every 1PPS pulse. For most stuff, this is good enough. For the metrology folks, using strong words like exactly or in this case "locked" will always cause an argument.
Ever read the actual 488 spec? There is a state diagram that could wreck your sleep for a week.
488 has a hardware "accepted" line, but for some reason SCPI in other contexts is send-and-pray.
488 is rare on new instruments, which are ethernet and USB. A Rigol scope makes a great USB power supply for fans and charging phones.
The rubidium physics/optics is noisy and nasty short-term. It usually disciplines a very good VCO or VCOCXO. I have a schematic somewhere around here; I'll look for it.
Trying to get multiple power supplies and loads to act together so people can run, say, a modestly complex power sequence and load test on some gear and loop that for days or weeks and stay coordinated. Each box has 8 plugins, which naturally share the same timebase, but I want to extend time coordination to multiple boxes. So, time lock their XOs long-term, and start all the individual sequencers simultaneously.
My customers complain about how nasty it is to organize a heap of purchased ac and dc supplies and dummy loads and relay drivers, to millisecond resolution, with a mess of weird interfaces.
No, the 1 PPS is sometimes generated by uP code, and sometimes jumps back and forth around ticks of some other clock. It's like a rubidium, ugly and nasty but long-term average excellent. I get the impression that a GPS box that outputs 10 MHz, gets the 10M by locking to the 1 PPS.
The nasty 1 PPS is the bottom line of the GPS frequency standard.
Real stability on less-than-weeks time frames comes from the flywheel effect of a very good 10 MHz oscillator and a very slow control loop.
Which is my problem, absolutely time locking a bunch of 40 MHz oscillators from a 1 PPS pulse generated by, essentially, a relay driver.
Yes, exactly. And the drift between two reasonably good clocks is slow, so the correction need not and should not be all that fast.
What I've done in real applications is to periodically measure the offset between when the external 1PPS is predicted to happen and when it actually does, and adjust the VCO frequency such that in say 50 seconds of roughly linear convergence they will coincide (and keep on going). The process is repeated every few seconds (exact interval not important as it is measured).
This is roughly the algorithm a helmsman uses while steering a sailboat, where effect is very much delayed from action.
In many computer systems it is quite difficult to do anything on a strict time mark, but easy to measure that actual elapsed time, using the actual clock that is being steered - it all still converges, so long as one doesn't try too hard.
So, in your example, the local clock would come from a 40 MHz VCO of good manufacture (probably needs to be a TCXO of some sort). The 40 MHz output would be fed to a divider that puts out a 1PPS pulse train.
During initialization, when the first external 1PPS leading edge is received, reset the divider, and start counting 40 MHz cycles. Maybe wait for things to stabilize.
Thereafter, measure signed offset between external and internal 1PPS leading edges, and compute how much change (plus or minus) in current VCO frequency is required for zero offset to occur in say 50 seconds (make this time-to-zero an adjustable parameter), and change the VCO control voltage accordingly.
A few seconds later (also an adjustable parameter), repeat the above adjustment process, again looking 50 seconds into the future from now. Repeat forever.
Steering to within one microsecond should be easy. Any number of units can be following this external 1PPS signal without knowing that one another even exist.
Beware of one thing: The 1PPS coax output from many GPS receivers is designed to drive a 50-ohm *resistor*, not a 50-ohm transmission line. You may need a 3dB pad right at the GPS Receiver chassis between 1PPS output and coaxial cable to get sharp leading edges at the far end of the coaxial cable. The classic symptom of trouble is when an o'scope cannot sync reliably to the 1PPS.
Also, I'd lose the BNC connectors. Threaded connectors like SMA, TNC, and Type N are far better.
Or use shielded twisted pair to carry the 1PPS pulses. This would work better over a backplane.
This is good advice. Even though the lazy guy within me never truly gives up his fight to take the easy way out with BNC. Twisted pair (TP) sounds even easier than BNC. So, what's the "catch" with TP? Where's the "gotcha" to make TP harder than BNC? Danke,
fredag den 22. juli 2022 kl. 22.37.08 UTC+2 skrev Joe Gwinn:
isn't that kind how NTP works?, speeding up or slowing down over some period to sync time with the server without big jumps and always increasing (except possibly at start up)
come to think of it, some closed loop servo systems (and step generators) for things like CNC machine work similarly at a fixed interval, say a few kHz, current target and actual position is compared, from that (usually with a PI loop) the speed of the motor (or frequency of steps) is set so the position will hit the next target at the next timer tick
"Her" clock is not necessarily as stable as the 1PPS. How quickly does it need to converge? Is this just a "make it a wee bit better" thing or do you have a specific jitter spectrum in mind?
"... and the other is a time-locked loop in the 1023 bit code space domain with the goal of tracking both the code and carrier phases for that signal."
formatting link
That sounds suspiciously like what I did ( in software ) for a terrestrial radio system once. The FPGA gave me a few bits of tuning data and it was a state machine. I *think* the output was a counter-delta value back to the FPGA. That was in the long ago.
I put trimpots in the management plane , put those in a GUI and let the FPGA guy tune it. He was ecstatic and it beat him running back and forth.
He tested it over coax; never did understand why this was needed at all unless you were over air/free space. The analog PLLs should have handled it. I think the RF amps we were using were pretty awful and not being run in a very linear range. System leaned heavily on some bandlimiting ( SAW ) filters.
A second is a long time. GPS is a couple of nanoseconds per day to a few msec. Yer average computer will go off to see the wizard and back in a day.
It felt more like a "goalie" algorithm than a PLL. But it did show a measurable improvement. It's not really even an algorithm. It's a "bang bang" controller. Nine pound hammer in software.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.