Shepherds Bush still on BST

That would be the Uxbridge road warp in the space-time continuum.

The clocks at both ends of the eastbound platform at Gloucester Road on the SSR have both been exactly one minute slow to the second since at least 2000 when it became my local station. They do however adjust perfectly for daylight saving each clock change.

The other day, for me, it said Eastbound Trains: District & Circle Lines. But to be fair, most screens do this

Even if they are not particularly useful, it is quite bizarre behaviour.

1. If the clocks were free running, how come they are continually set incorrectly every time they need resetting (power failures, drift, BTS changes)?
2. If they were synchronised by a per second pulse from a central location, pretty much the same question applies as above.
3. If they receive the entire time every second, or once a day (or other time period), and then free run - how do they manage to keep getting it wrong in exactly the same way?

Speed of light? Long platform is it? Strong magical field perhaps?

For an analogue clock, the explanation is simple.

However, the OP clearly states the clock is digital.

I thought I was going mad reading the last few posts, until I checked said OP. (Not that I recollect any analogue displays at SB Central Line).

Oops. Sorry, I just noticed we’d moved on from Shepherds Bush and digital displays.

I mentioned all this, in somewhat less detail, several posts back.

The first of your explanations (and the second of mine, upthread) is, I would have thought, unlikely.

It would mean that every time there is a power failure, or the clocks change, someone would need to reset the clock exactly right. (And station clocks do seem to be, in the main, exactly right, according to my radio synched watch [yes, I know it's pointless, but the technology fascinated me].) Also, pulses inevitably get lost, so the clocks would tend to drift.

In the full synch each second case, it's even harder to see how this could happen. If there was a fault with the least significant bit on the minute register (or the path that sets it), then, if the bit was permanently up, or down, the minutes would jump by 2 every two minutes, and if the bit was inverted, the minutes would run: 1, 0, 3, 2, 5, 4 ...

But the reason I was so surprised by the OP was that, according to the poster, this has been going on for 22 years. I would think it's moderately unusual for clocks to run that long with no maintenance, let alone maintain a one minute error for such a long period.

The fact that the clocks in question are very close together certainly indicates that the problem is with a synch signal, rather than being within the clocks themselves. (Unless they have 'nudge' buttons and some LU employee at SB Central Line thinks it's funny to have the clocks perpetually running slow  )


Whilst I'll certainly bow to your superior knowledge of LU technology, As a systems designer, I have a lot of experience with all sorts of fault tolerance and data integrity issues, and I still find this particular case bizarre.)


ETA:

I think I may have inferred the system employed.

Given that the OP says he saw this in 2000, then it is at least this old, and quite possibly older. That means the system was probably specified in the early nineties. Back then, no one would have considered linking things like station clock via the internet, and electronics/computers were more expensive and less capable, so bunging encoded time signals around would not have been a likely solution.

What they probably did was us a one second pulse sync, with a separate 'reset' signal that would reset the clock from the master, every 24 hours. Cheap, and pretty robust. So long as pulse loss was reasonably rare, the clocks should not drift for more than a few seconds for a day or two.

That just leaves the problems of why two clocks, that are physically close, both exhibit exactly the same behaviour, and how something can reset a minute behind the correct time (a second ahead is reasonably easy).

Still being on BST I can't answer. At least not without knowing what device it is and to what it is connected (if at all). A problem here is is a clock goes faulty and is replaced that is simple; if it has data cabling to it and the cabling is faulty, the cost and effort of addressing that cabling with all the station access issues are a subject in itself.

(Not to do with clocking but I have heard of one relatively minor project with a current +3 year (and increasing) delay due to expense of and no funding providing one CAT5 cable route - through fire containment. )

Clock permanently 1 sec adrift even after a power cut is explainable. If there is a propogation delay to the device, then no matter what signal or pulse you send it, it will be received delayed. Once power is restored, the very next real time pulse, or resync pulse, will attempt to set the right time - but if the time offset is always 1 sec, so takes 1 sec longer than the real world, then your clock is always 1 sec slow. It is not an accumulative lag if any sync pulse is rcvd, just the same offset lag.

As I said, I once encountered a 5 sec delay; admittedly in a complex part of the fibre network that went through too many mux mountains (since gone); nonetheless these things do occur out there.

A delay makes perfect sense, and explains why two co-located clocks both suffer exactly the same error.

However, I don't think it's a propagation delay. It's far too big, and 'exactly one minute' seems like way too much of a coincidence.

I suspect it's the pulse generation that's the problem.

Given the age of the installation, this is almost certainly done in hardware.

The clock is most likely six cascaded BDC counters (e.g. 74LS90) feeding six BCD to decimal decoders(e.g. 74LS32). If you take the 'zero' outputs from each decoder and nand them all together, you would get a pulse whose leading edge you could use to trigger the reset.

If the minute signal was taken from the 'one' line rather than the 'zero', you would get the behaviour exhibited here. Of course, it would imply that the pulse logic had been patched onto the main circuit board, because if the whole thing was one PC it would be hard to see how just one station's master would be mis-wired.

Sorry, my fault. I forgot that what I was referring to was a subsidiary comment located five posts down from the top, by roman80.

I've been banging on about clocks being a minute slow since 2000 at Gloucester Road, when the thread was about BST at Shepherd's Bush.