"Stable" time references

In my case, it's not a "lab" but, rather, a suite of products that all rely on "time" (and, sometimes even time-of-day) to varying degrees -- as dictated by their end users.

E.g., in the house, I don't really care that the "(wall) clocks" tell the *correct* time(-of-day). Rather, that they record the passage of time accurately. Over very long time intervals (ironically, tolerating more short term error than long!) So, in 3523453453 seconds, each timepiece should have advanced

3523453453 seconds (within my tolerances).

OTOH, when distributing audio/video, I probably want to be sure the rate at which the source material is being reproduced is relatively close to that at which it was recorded (not that my ear can discern the difference a 0.5% pitch represents). Rather, video being reproduced at one rate can loose sync with audio being reproduced at a different rate (wrt the video in terms of relative accuracy)

Different needs in a given environment.

Reply to
Don Y
Loading thread data ...

'Relatively Stable' is hopelessly vague. Some numbers are badly needed here. One man's stable, is another's hopeless..

Then you are talking about shipping with software that does calibration, and a user choice of what to connect, for that calibration.

Your calibrate SW end, should be adaptive and smart, and accept obvious candidate signals users can get with varying efforts like

  • 50/60Hz Mains
  • 1pps Pulse from GPS systems
  • Serial time codes, from a PC serial port.
  • Sound card output, stand alone, or from a NET connected PC
  • USB enumeration attempts, may give an intermediate-precision calibrate. (from memory USB timebase here was 200-300ppm high ?)

That would have a low cost connector, and the user makes the decision of precision and effort and what they spend. Software to manage ALL/ANY of that, is non trivial.

-jg

Reply to
j.m.granville

That's the whole point! The user should be able to set his level of "hopelessness"! The mechanisms shouldn't need to be designed differently for different types of "accuracy/precision" (within reason).

No. Software that accepts a "reference standard" against which it operates. If the reference sucks, so will the results -- and conversely.

Easy. Though also have to expect the mains to be a *lousy* frequency reference! (e.g., imagine kit operating off a genset in the middle of an empty field)

Not sure a PC is going to produce more detailed reference than anything I would use as a default. Just how accurate do you think stuff *in* the PC is? How deterministic are serial port transfers (pick your favorite OS, here, and quantify its latencies in the serial port driver, chipset, etc.)

Also, a serial port just to accommodate a PC is expensive. Let external convert data from a "serial source" into a reference pulse train -- why burden folks who don't want that sort of reference with its cost?

That's why you *just* pick a pulse train of "some frequency" as your external reference. No "protocols" involved, etc.

There was some concern in my mind that I should accommodate

*any* such reference -- i.e., provide a hook whereby the user can tell me what the characteristics of the reference are and adjust the servos accordingly.

However, that appears to be overkill. Pick a set of "common" references and autoidentify the likely candidate based on empirical estimates (~1 hz --> 1PPS; ~50Hz --> line frequency; ~10MHz --> 10MHz; etc.). Then, all that remains is optimizing for short or long term stability. (time constants on loops)

Reply to
Don Y

That presupposes a whole lot of technical understanding on your users' end of things. Users usually pay engineers (i.e. us) to spare them the need to acquire knowledge like that.

Well, when it's you saying it, "(within reason)" sometimes appears to be no limitation at all :-P

Frankly, I'm surprised you even recognize the concept of overkill. Most of what you're asking about here is already at that line, if not beyond.

Reply to
Hans-Bernhard Bröker

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.