Now that's a train delay Upminster with which London travellers shall not put Welcome to another in the The Register's inexplicably long-running series of sickly signage and distressed displays. Spotted on the platforms of London's Gunnersbury station by Register reader Julian, the display looks innocuous enough at first glance. However, something is amiss within the bowels of the UK capital's Transport …
If it's the same for the tube as it is for overground, these displays will use the same or similar publicly accessible API and datasets as everyone has access to and it would likely be an error in the data rather than a display malfunction. The data is not safety critical and errors do occur with inconsistencies between data fields. The order of departure seems correct even though the time was way off.
As for "an error... which we worked to fix as soon as possible" - I find that hard to believe given it would have auto-fixed itself in around 5 minutes, as soon as the scheduled departure was no longer displayed.
That's just another 'by rote' response. Honesty really doesn't seem to exist these days.
> error in the data rather than a display malfunction [...] order of departure seems correct even though the time was way off.
(Could be the data, or it could be processing of the data? I'd err on the side of "timestamp displayed erroneously as an estimate" rather than "but that's *tomorrow*" as per the article - but I'm here to mention a related bork, not speculate on this one...)
Relatedly in the case of our local bus stop displays, you can see the last bus shown some time after it's definitely gone. Interesting cases (other than "it's an estimate, meh") include nights the clocks change; I'd hazard that the data's timestamp is in the new timezone at times the receiving terminals aren't (yet).
Two possibilities that spring to mind for the Upminster fiasco. Either the linked-list that the track circuit the train is currently sitting on has a data error on its "transit time", or the train is leaving the station and has not yet caused the entry signifying its presence to be struck off the train queue. With overground signalling this can be possible - the starter signal may turn red after the last carriage has fully departed because traditionally the guard travelled in the back carriage and would check that the signalman had not flagged an emergency stop for some reason. Some old LT train describers would delete trains off the train queue in the moment when the trainstop was down (safe to go) and the signal was red: a momentary situation, but one that was often used. So why the large number of minutes? In the system designed, that might(?) represent minus one minutes, they've simply ignored the signed nature of the integer (I can imagine someone saying it's impossible to have minus one minutes, so lets's not bother checking for it). I'm pretty sure these things have moved on a lot since I worked for them (I think independent proximity detectors are often used now, which cut out a lot of cabling and relay contacts).
I'm not familiar with the signalling at Gunnersbury to say for sure, as it was not under LT control when I worked for them.
===
In other news "they" have fixed the problem on the Queens Park to Harrow & Wealdstone stretch of the Bakerloo line where the next southbound station after Queens Park on the Bakerloo line was announced as Elephant & Castle, whereas on the overground Kilburn High Road and South Hampstead were deemed important enough to be mentioned.
The fix now is to say, I think, "all stations to <terminus>"
ot, this reminds me of a Polish song, Wars wita was!, loosely translated as "welcome to Wars!". Sadly, the "wars" bit was / is nothing more than, once infamous in the commie times, a brand of dining cars on Polish railways. Anyway, one verse, in the form of station announcement, went something like this:
"A slow train from Warsaw West do Gdynia Central has increased its delay to approximately 4688 minutes and has been officially declared missing. The state of being missing can increase or decrease..."
And, years later, when communism was over, but the railways in Poland still remained in their goode olde state of mind, one warm summer, I did happen to wait for this particular (night) train at that particular station in Warsaw. And it was delayed and delayed, and eventually came about 6 hrs late, instead of late night it appeared around 5 a.m. already after dawn, when we were supposed to arrive at the destination. While it was a particularly warm night, people on the platform were not amused, particularly parents with kids slumped over their shoulders.
That said, I'm pretty sure people waited a couple of days (and nights) for a train in Europe c. 1945 so I can see some progress :D
Up until a few years ago, the displays at Richmond (just down the line) would regularly display 'next underground/overgound train' as one that would/should have left hours ago, so they've obviously had to replace some kit with something that's missing a few updates.
(the networkrail site would also sometimes show an impossible District line journey to Dagenham East)
I once heard a DLR 'train captain' being asked why he was having to manually drive the automatic train. He replied it was because the system currently showed his train as being on the other track, travelling in the opposite direction!
"I once heard a DLR 'train captain' being asked why he was having to manually drive the automatic train"
A very near head-on miss in the UK this week. The reference to "damage to points" suggests one should have stopped at a signal earlier.
There is a Libre clever monitoring sensor that sticks on your upper arm to monitor glucose in the interstitial fluid. Quite discreet and painless to affix - it's only when you remove it that you notice the size of the vampire tap probe. The sensor unit has NFC communication for an occasional "flash" scan from either a dedicated Reader or a smartphone app. The sensor holds 8 hours of effectively continuous glucose readings. The NFC allows them to be uploaded to the reader/smartphone - hopefully before the sensor buffer cycles. The values are stored in the Reader for 90 days with their correct wall-clock time stamp reported in the Reader's graphs. Any sensor buffer overrun gap is shown at the correct time period for which it lost buffered values.
As the probe is an electo-chemical sensor it has a pre-defined period of active use of 14 days. On the 14th day you get a regular count-down to the time when it will stop monitoring.
It gets interesting if you use both a Reader and a smartphone for scans. The Reader activates the sensor initially - and the smartphone then gets associated with the sensor afterwards.
This week the Reader interrogated the sensor - and was correctly indicating about 30 minutes left. However - the smartphone app said it had already expired. Scratching my head on that - both the Reader and smartphone wall-time clocks appear to be in reasonable UK DST sync.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
