KEVOS
ArticlesServicesCase studiesAboutContact
ArticlesServicesCase studiesAboutContact
← ArticlesSignals and Standard Time: The Telephone Network and the Great ClockEngineering · ElectricalLesson 9/12← PrevNext →
GuidePublished 4 Aug 2026Updated 13 Aug 202611 min readBy Kevin JoginElectrical EngineeringTelecommunicationsDesign PracticeNetworks
On this page

Ask about this page

KEVOS AISignals and Standard Time: The Telephone Network and the Great Clock

KEVOS knowledge first · trusted web sources when needed

Knowledge LibraryEngineeringElectrical EngineeringKL-ENG-HIST-1628

Signals and Standard Time: The Telephone Network and the Great Clock

An escapement that isolates a pendulum from every upstream disturbance, and a network whose link count grows quadratically until hierarchy rescues it. Both are about distributing a shared reference.

Part 9 of 12 Period 1858-1876 Milestones 2 Reading 5 min Updated 2026-08-04

01Executive summary

A clock that keeps a city’s time and a network that carries a city’s voice are the same kind of engineering: both distribute a shared reference that nobody owns and everybody depends on.

The Great Clock at Westminster was installed in the late 1850s under Benjamin Hall as Commissioner of Works, and began keeping public time in 1859. Alexander Graham Bell’s telephone patent was granted in 1876. One is a mechanical regulator of remarkable accuracy; the other is a two-element transducer pair of almost trivial simplicity. What makes both significant is not the device but the infrastructure that grew around it.

~4.4 mPendulum length at Westminster, giving a period of about four seconds
0.4 s/dayRate adjustment from adding a single small coin to the pendulum bob
1876Bell telephone patent granted
n(n−1)/2Direct links needed to connect n subscribers without switching

02The escapement problem

Every mechanical clock faces one contradiction. The timekeeping element — the pendulum — must be as free as possible from external influence, because any disturbance changes its period. But it must also receive energy from somewhere, or friction and air resistance will stop it. The escapement is the mechanism that resolves this: it releases the gear train one increment at a time under the pendulum’s control, and simultaneously delivers a small impulse to keep the pendulum swinging.

The difficulty is that the impulse itself is a disturbance. If the impulse varies — because the driving weight changes, or the train binds, or wind loads the hands — the pendulum’s amplitude varies, and amplitude variation shifts the period. On a public clock with hands several metres long exposed to weather, this is not a theoretical concern.

The gravity escapement

The double three-legged gravity escapement, developed for the Westminster clock, breaks the link between train force and impulse. The train does not push the pendulum at all. Instead it raises small weighted arms, and those arms then fall under gravity to deliver the impulse. Since gravity is constant, the impulse is constant — whatever the train is doing, and whatever the weather is doing to the hands. It is a textbook example of isolating a precision element from an upstream disturbance, and the same reasoning underlies voltage regulation, pressure regulators and constant-current drivers.

Temperature, and why a coin is a control input

A pendulum’s period depends on its effective length, and metals expand with temperature. Longer pendulum, longer period, slow clock. The Westminster clock is trimmed by placing small coins on a tray part-way up the bob assembly. Adding mass above the centre of oscillation raises the effective centre slightly, shortening the effective length and speeding the clock — by roughly 0.4 seconds per day per coin. It is a beautifully proportioned adjustment: fine enough to be useful, coarse enough to be practical, and requiring no tools.

Time reference technologies and achievable stability
TechnologyReference elementIndicative stabilityPractical role
Public pendulum clockGravitational pendulumOrder of a second per dayCivil time for a city
Quartz oscillatorPiezoelectric resonatorOrder of seconds per monthConsumer and embedded timing
Atomic standardAtomic hyperfine transitionFar better than a second per human lifetimeTime scales, navigation, telecommunications
Network time distributionDisciplined local oscillatorLimited by path delay symmetrySynchronising distributed systems

The progression is not simply toward better clocks. It is toward shared time. A public clock synchronises a city; standard time zones synchronise a railway; network time protocols synchronise distributed computation. In each case the engineering value is in the agreement, not the accuracy.

03Telephony: the device was easy, the network was not

The original telephone is close to the simplest useful electrical device imaginable. A carbon granule microphone varies its resistance with acoustic pressure, modulating a direct current; an electromagnetic receiver converts that varying current back into motion of a diaphragm. A pair of wires and a battery complete it. Two instruments connected by a dedicated line work immediately.

The problem appears at the third subscriber. Connecting every subscriber to every other subscriber directly requires n(n−1)/2 links — ten subscribers need forty-five lines, a hundred need nearly five thousand. This growth is what forced the invention of the exchange, and the entire history of telecommunications engineering follows from that single combinatorial fact.

  1. Manual exchangeSubscriber lines terminate at a switchboard; an operator physically patches a connection on request.
  2. Automatic switchingElectromechanical selectors respond to dial pulses, removing the operator and cutting cost per call.
  3. Stored-program controlComputer-controlled exchanges add tone dialling, routing intelligence and supplementary services.
  4. Digital transmissionVoice is sampled and encoded; many channels share one path by time division, then by wavelength on fibre.
  5. Packet networksVoice becomes an application over a general-purpose packet network, and marginal call cost approaches nothing.

Hierarchy: the structural answer to combinatorial growth

The exchange does not eliminate the problem; it relocates it. Local exchanges serve subscribers, trunk links connect exchanges, and higher tiers connect regions. Each subscriber needs one line instead of thousands, and traffic between areas is concentrated onto shared paths sized by statistics rather than by worst case — because subscribers do not all call at once. That statistical concentration, and the mathematics of blocking probability that governs it, is the foundation of traffic engineering and applies equally to call centres, road networks, hospital beds and server capacity.

Pattern

Hierarchy tames scale

Any fully connected network grows quadratically and becomes unbuildable. Introducing intermediate concentration points reduces growth to something near linear. This is why distribution networks, organisational structures and data architectures all end up hierarchical.

Pattern

Cost falls in steps, not smoothly

Each switching generation produced a discrete drop in cost per call. Technology cost curves are usually a series of step changes at architectural transitions, not a smooth decline — which matters when forecasting.

Practice note — Australia

Australia’s telecommunications engineering has been shaped by extreme distance and low population density, which historically made per-subscriber infrastructure cost the dominant design variable. The National Broadband Network’s multi-technology mix — fibre to the premises, fibre to the node and curb, hybrid fibre-coaxial, fixed wireless and satellite — is a direct expression of that economics. For engineers, the practical touchpoints are cabling and customer premises equipment rules administered by the Australian Communications and Media Authority, and telecommunications cabling installed under AS/CA S009. Separation from electrical services and correct earthing remain the most common compliance failures in building work.

04Takeaways

Isolate the precision element

The gravity escapement protects the pendulum from upstream variation. Find the equivalent isolation in any precision system.

Count the connections

Before designing a network, work out how its link count grows. Quadratic growth demands hierarchy.

Statistics size the shared path

Trunks are sized on aggregate behaviour, not on the sum of individual peaks. Same for any shared resource.

Agreement is the deliverable

Standard time and dial plans are valuable because everyone uses the same one, not because either is optimal.

Previous in seriesRail survey, cable traction, tension wheelsNext in seriesECG, defibrillation and endoscopic surgerySeries indexMilestones of the Modern Era, 1845-1910

KL-ENG-HIST-1628 · KEVOS® Knowledge Library · Engineering / Electrical Engineering

  • Electrical Engineering
  • Telecommunications
  • Design Practice
  • Networks
  • Systems Engineering
  • History of Engineering

Original KEVOS® synthesis. Historical dates, attributions and device descriptions are drawn from general engineering history; the analysis, structure, standards commentary and Australian practice notes are our own. Figures are indicative and are given for teaching purposes — verify against the governing standard or manufacturer data before using them in design.

© KEVOS® — Precision to Vision. Prepared by Kevin Jogin.

Handbook application: from concept to controlled practice

Purpose. This expanded section turns the original page into a practical handbook. It preserves the supplied material and adds a repeatable way to apply, check and review Signals and Standard Time: The Telephone Network and the Great Clock. It does not replace a contract, legislation, a controlled standard, competent engineering judgement or specialist advice.

The operating aim is to carry the subject from function and assumptions through design evidence, verification and controlled release. Read the original explanation first, then use the workflow and checks below to convert knowledge into evidence.

Apply Signals and Standard Time: The Telephone Network and the Great Clock by beginning with the duty, not the component or software command. Convert the key ideas—network, time, clock, city's, hierarchy—into measurable requirements and interfaces. Record operating and non-operating environments, duty cycle, expected life, loads, energy sources, human interaction and reasonably foreseeable abnormal conditions. When a value is not a project requirement or verified supplier datum, identify it as an assumption or illustrative value.

Create a calculation and evidence trail that another competent person can audit. Every input should carry a source, unit, revision and uncertainty or tolerance where relevant. Every model should state its boundary conditions and limitations. Keep nominal capacity separate from design capacity, and keep verification margin separate from an arbitrary safety factor. If a code or standard governs the work, confirm the applicable edition and contractual status rather than copying a number from a secondary summary.

Design for manufacture, assembly, inspection, operation and maintenance at the same time. A technically valid geometry can still fail because it cannot be fixtured, measured, cleaned, guarded, reached or replaced. Review process capability, datum or reference strategy, tolerance accumulation, access, error-proofing and changeover. Where people interact with plant, apply the hierarchy of controls and consult those who will operate, clean, maintain and recover the equipment.

Plan verification before release. Define the characteristic, method, equipment, sample or test condition, acceptance criterion, record and responsible person. Validation then asks a different question: whether the resulting system is effective and suitable in the intended use context. A passed drawing check or analysis does not by itself validate usability, maintainability or production performance.

Step-by-step operating method

  1. Define the duty. Capture the required function, interfaces, operating environment, life, loads and unacceptable outcomes.
  2. Establish the model. Identify governing principles, units, material or process data, assumptions and uncertainty.
  3. Develop alternatives. Compare feasible concepts against performance, manufacturability, safety, maintainability and cost.
  4. Verify the design. Use analysis, test, inspection or demonstration with acceptance criteria defined before execution.
  5. Release and learn. Baseline the design, control changes, retain evidence and feed operating results into the next revision.

Illustrative design review record

Illustrative values only. Build a one-page record with the required function, input sources, assumptions, governing load or process condition, failure consequences, selected concept, verification method and acceptance criterion. Mark every numerical input as project requirement, verified supplier data, measured value, calculation output or assumption. Review the weakest evidence first. If an assumption can change safety, compliance, interchangeability or capacity, it must be resolved before release rather than buried in a calculation note.

Evidence classQuestionRelease expectation
RequirementWhat must the design do and under which conditions?Approved and traceable
InputWhere did the load, property, tolerance or process limit come from?Source, unit and revision recorded
AnalysisWhich model and assumptions connect input to result?Checkable calculation or simulation
VerificationHow will conformity be demonstrated?Method and acceptance criterion agreed
ValidationWill the solution work for intended users and conditions?Representative use evidence

Common failure modes and recovery actions

1. Watch for

Starting detailed design before interfaces and operating limits are agreed.

Recovery: Return to the governing definition or requirement and restate the decision in one sentence.

2. Watch for

Using catalogue or typical values as though they were certified project inputs.

Recovery: Separate evidence from assumption, assign an owner and set a date for validation.

3. Watch for

Checking nominal performance while ignoring tolerances, degradation and foreseeable misuse.

Recovery: Run a small counterexample, boundary test, pilot or independent check before proceeding.

4. Watch for

Confusing verification of requirements with validation of user need.

Recovery: Record the consequence, decision and rationale, then update the controlled baseline.

5. Watch for

Releasing drawings or procedures without configuration, inspection and change controls.

Recovery: Escalate when the issue affects safety, compliance, acceptance, material value or an agreed tolerance.

Review checklist

  • What function and failure consequence govern this decision?
  • Which inputs are measured, specified, assumed or illustrative?
  • How will conformity be demonstrated and recorded?
  • What change would invalidate the current evidence?
  • Are mandatory requirements distinguished from recommendations and illustrative values?
  • Are sources, assumptions, units, dates and versions recorded closely enough to reproduce the decision?
  • Have safety, legal, ethical, stakeholder and operational consequences been considered at the appropriate level?
  • Is there a named owner and a trigger for review, escalation, change or retirement?

Questions for deeper application

What is the most important distinction a practitioner must preserve when applying Signals and Standard Time: The Telephone Network and the Great Clock?

Answer with a fact or cited source where available. Where evidence is incomplete, record the assumption, consequence, responsible owner and next validation action.

Which assumption about network would change the result most if it proved false?

Answer with a fact or cited source where available. Where evidence is incomplete, record the assumption, consequence, responsible owner and next validation action.

What evidence would allow an independent reviewer to reproduce or challenge the conclusion?

Answer with a fact or cited source where available. Where evidence is incomplete, record the assumption, consequence, responsible owner and next validation action.

Which boundary, exception or failure case has not yet been tested?

Answer with a fact or cited source where available. Where evidence is incomplete, record the assumption, consequence, responsible owner and next validation action.

What must be handed over, monitored or reviewed after the immediate work is complete?

Answer with a fact or cited source where available. Where evidence is incomplete, record the assumption, consequence, responsible owner and next validation action.

Authoritative references and use notes

The sources below were selected as institutional or primary guidance for the broader practice. They support the handbook method; they do not imply that every statement or clause in a source applies to every project. Confirm the current edition, jurisdiction, contract and application before treating any requirement as mandatory.

  • NASA Systems Engineering Handbook — NASA. Used for requirements, design, verification, validation and technical management. Accessed 2026-08-13.
  • Identify, assess and control hazards — Safe Work Australia. Used for hazard identification, risk assessment, controls and review. Accessed 2026-08-13.

Continue learning

Networks of Movement: Transcontinental Rail, Cable Traction and the Great WheelGuide · Civil & StructuralNEXT LESSON →Biomedical Engineering Begins: The ECG, the Defibrillator and Keyhole SurgeryGuide · ElectricalBoring and Lifting: Tunnel Boring Machines and the Safety ElevatorGuide · Civil & StructuralFluids and Comfort: Powered Flight, Sailing Hydrodynamics and Air ConditioningGuide · Mechanical
KEVOS · Engineering, manufacturing and project improvement
ArticlesServicesCase studiesAboutContact
© 2026 KEVOS®