When Buses Talked to Lampposts: London’s Pre-GPS Miracle
Part 2 of 4: The Hidden Tech Running London's Buses
Picture this: it’s 1992.You’re standing at a London bus stop on a drizzly Tuesday morning. There’s no smartphone in your pocket-mobile phones are still the size of bricks and cost about as much as a used car. The internet exists, technically, but it’s mainly for academics and people who enjoy typing commands into black screens.
And yet, mounted on the bus shelter in front of you, there’s a digital display. It’s showing you, in glowing orange letters, exactly when your bus will arrive.
How on earth did they pull that off?
The World Before GPS
Here’s something that might surprise you: GPS existed in 1992. The US Department of Defence had launched the full constellation of satellites a year earlier. But there was a catch civilian access was deliberately degraded through something called “Selective Availability,” which made the system accurate to only about 100 metres.
For military use? Perfect. For telling you precisely when a bus would reach your stop? Useless.
So when London launched its first “Countdown” bus tracking system in 1992, GPS wasn’t really an option. They had to come up with something else entirely. And what they came up with was genuinely ingenious.
The Lamppost Solution
Imagine treating a bus route like a railway line.
On a railway, you don’t track a train continuously. Instead, you have signal boxes at fixed points along the track. A train enters a section, a signal registers its presence, and the system knows where it is -not constantly, but at specific checkpoints.
London applied the same logic to buses, but instead of signal boxes, they used lampposts.
Here’s how it worked: Transport for London (well, London Transport at the time) installed special boxes called “roadside checkpoints” on lampposts along major bus routes. Each box broadcast a unique radio signal, essentially saying “Hello, this is lamppost number 247 on the Route 38.”
Buses were fitted with receivers and radio transmitters. As a bus passed a checkpoint, its onboard system would detect the lamppost’s signal, recognise it, and automatically radio back to a central control centre: “Bus 4,532 just passed lamppost 247.”
The control centre would update its records, calculate how long it should take to reach the next few stops based on the typical journey time, and broadcast those predictions to the countdown displays.
Brilliant, right?
The Frustrating Reality
Well, sort of.
The system worked, technically. It was genuinely impressive for its time, a real pioneering effort that put London ahead of most other cities in the world. But the user experience could be... frustrating.
Here’s the problem: between checkpoints, the bus went dark. The system knew where it had been, but not where it was.
So you’d see “2 mins” on the display. Then you’d wait. And wait. The countdown would tick down to “due.” And then... nothing. The bus would vanish from the display entirely, because it was somewhere between checkpoints, invisible to the system.
Or worse, the bus had actually already gone past your stop, but the system hadn’t caught up yet. You’d watch “1 min” counting down whilst your actual bus sailed past three minutes ago.
Knowing that your bus was at a certain point four minutes ago didn’t always help you predict when it would arrive now. It created a strange kind of Schrödinger’s bus—simultaneously close and far away until it actually appeared.
The Invisible Database Revolution
But here’s where the story gets more interesting, because the real breakthrough of the early 2000s wasn’t about tracking buses better, it was about understanding bus stops.
This might sound boring, but bear with me, because it’s genuinely fascinating.
In the early 2000s, Transport for London faced a fundamental problem: every bus operator had their own way of recording where bus stops were. Different names, different reference numbers, different data formats, all for the exact same physical bus stop.
One operator might call it “High Street (Stop A).” Another might call it “High Street Stop.” A third might use “High Street NE-bound.” The computer systems couldn’t talk to each other because they weren’t speaking the same language.
The solution came from two groups with wonderfully bureaucratic names. First, there was the National Public Transport Access Nodes Database, mercifully shortened to NaPTAN, which is also what happens if you fall asleep in the sun.
NaPTAN gave every single bus stop in the country a unique identifier code and exact GPS coordinates. It was like giving every bus stop its own postcode. Suddenly, regardless of what anyone called it, bus stop NaPTAN code 490000001S was always, unambiguously, that specific stop.
Then the Realtime Information Group created standards for how this information should be stored and formatted, so that different systems could share data seamlessly.
The Foundation No One Thinks About
This database work was unglamorous. No one wrote newspaper articles about it. There were no ribbon-cutting ceremonies for a standardised data format.
But it was absolutely essential.
Without NaPTAN, the modern bus tracking systems we use today simply couldn’t exist. Every app that tells you when your bus is arriving—TfL Go, Citymapper, Google Maps, all of them—relies on this foundational work.
It’s the digital equivalent of agreeing on a common language. Before you can have a sophisticated conversation about where buses are and when they’ll arrive, you first need everyone to agree on what you’re even talking about.
The Unsung Engineers
There’s something quite lovely about this, actually.
Somewhere in the early 2000s, there were database engineers working on NaPTAN who probably never imagined their work would underpin the apps that millions of people now use every single day. They were just solving a boring, practical problem about data standards.
And yet, every time you check your phone and see that your bus is three minutes away, you’re benefiting from their work. Every time Citymapper calculates the fastest route across London, it’s using the foundation they built.
The lamppost system was clever, and it showed what was possible. But the database work? That’s what made the future possible.
The Gap Between Technology and Experience
Looking back, the early Countdown system represents a fascinating moment in the evolution of urban technology—the gap between what was technically possible and what created a good user experience.
The engineers in 1992 did something remarkable with the tools they had available. They created a system that tracked buses without GPS, without mobile data networks, without any of the infrastructure we now take for granted.
But they also revealed a truth that would shape every system that came after: it’s not enough to know where a bus was. You need to know where it is, right now, continuously.
And for that, London would need a different approach entirely.
What’s Coming Next
Next week, we’re jumping forward to the mid-2000s, when London finally got the tracking technology it needed. But the real story isn’t just about GPS, it’s about what happened when buses started talking to traffic lights.
Yes, you read that right.
Your bus is negotiating with the infrastructure around it, asking traffic lights to change, telling the network where it is and where it’s going. And the impact on journey times is genuinely surprising.
Part 1: Your Bus Stop Is Lying to You (But in a Good Way)
Next week: “Your Bus Is Negotiating With Traffic Lights (Yes, Really)”
Can you remember the old dot-matrix Countdown displays from the 90s and early 2000s? Did you ever experience one of those phantom buses that vanished from the screen? I’d love to hear your memories.