Continued problems with EL destination boards

[mrmartin]

These still aren't working properly. Yesterday at Paddington the indicators above the platform doors were showing something along the lines 1 min not in service, 5 min Abbey Wood, 5 min Abbey Wood, 10 min Shenfield. In reality the next train was in service and came in about 2mins (it corrected itself when it changed to 'arriving').

Even worse going back to paddington from TCR the screens at the gateline were only showing Maidenhead and Reading trains, making it look like there was no train for 15 minutes or so (which would have caused me to miss my connection at Paddington, so I was considering alternate routes, but couldn't understand the logic of being disruption which would end up like this).

Got down to the platform and realised that it was just totally wrong - there were loads of Paddington trains on the platform screen door displays.

Why is this still so broken? It's actually worse than just turning them off at this point, at least that TCR screen is completely misleading and I wouldn't be surprised if some people went on central line instead when they saw that.

 

[125Spotter]

the screens at the gateline were only showing Maidenhead and Reading trains, making it look like there was no train for 15 minutes or so

A bit of a tangent but even if that was the case, I don't understand why you would not board one of these and alight at Paddington? They all stop there. Unless you're worried about passenger loading?

 

[mrmartin]

A bit of a tangent but even if that was the case, I don't understand why you would not board one of these and alight at Paddington? They all stop there. Unless you're worried about passenger loading?

Because my train from paddington was in 20 minutes, so if there was a 15 minute delay I'd miss my connection?

 

[Horizon22]

These still aren't working properly. Yesterday at Paddington the indicators above the platform doors were showing something along the lines 1 min not in service, 5 min Abbey Wood, 5 min Abbey Wood, 10 min Shenfield. In reality the next train was in service and came in about 2mins (it corrected itself when it changed to 'arriving').

It 2 mins to where? "Not in service" would be a terminating train. This would align with the train 1 minute away because, for a passenger's perspective from Platform B, it is going no further.

Or was this Platform A? Sometimes there's a quirk where a train arrives additionally empty (i.e ad-hoc rather than planned timetable) and changes headcode in the platform, thus updating the CIS.

 

[125Spotter]

Because my train from paddington was in 20 minutes, so if there was a 15 minute delay I'd miss my connection?

I understand what you're saying. Sorry.

I interpreted that you were also saying the Maidenhead and Reading services were showing as arriving imminently. You're saying they were only showing according to the usual timetable while Pad ones were missing.

 

[mrmartin]

It 2 mins to where? "Not in service" would be a terminating train. This would align with the train 1 minute away because, for a passenger's perspective from Platform B, it is going no further.

Or was this Platform A? Sometimes there's a quirk where a train arrives additionally empty (i.e ad-hoc rather than planned timetable) and changes headcode in the platform, thus updating the CIS.

Westbound.

 

[Horizon22]

Westbound.

Okay so that is indeed expected behaviour (as I said) although you started talking about “Shenfield” and “Abbey Wood” which is eastbound so was confusing

 

[mrmartin]

Sorry, I meant Eastbound!

 

[Horizon22]

Sorry, I meant Eastbound!

Yes that is likely to be an ad-hoc ECS move which then changes headcode in platform and CIS changes. Not sure why the behaviour isn't linked to take this into account.

 

[stuu]

They are really strange. I have seen many times the first train arriving in 3 minutes and the second in 1 minute. Surely you would include in the code that the minutes for the second train cannot be lower than the first? I know very little programming but I could just about manage that, it's not hard

 

[mrmartin]

Yes I know. It was also doing that (showing stuff in wrong order).

It's the shoddiest system I've ever seen. I genuinely think most developers could do a better job in an afternoon with the NR API. Laughably bad.

 

[Horizon22]

They are really strange. I have seen many times the first train arriving in 3 minutes and the second in 1 minute. Surely you would include in the code that the minutes for the second train cannot be lower than the first? I know very little programming but I could just about manage that, it's not hard

I think the issue is integration with timings from the GWML and GEML and forecasting expected time from there. Building a bespoke system for a timetable that was always due to be integrated was a fairly poor idea.

 

[mrmartin]

You could just order the display of them by number of minutes. It's the most basic thing ever. I have no idea why you wouldn't do that.

 

[edgar13]

Even worse going back to paddington from TCR the screens at the gateline were only showing Maidenhead and Reading trains, making it look like there was no train for 15 minutes or so (which would have caused me to miss my connection at Paddington, so I was considering alternate routes, but couldn't understand the logic of being disruption which would end up like this).

Got down to the platform and realised that it was just totally wrong - there were loads of Paddington trains on the platform screen door displays.

I've noticed some TfL gateline displays (including tube) factor in the walking time to the platforms and put trains off a few minutes before they arrive, but in reality you could comfortably walk to the platfforms and still catch earlier departures. Presumably this is to discourage running through a crowded area?

 

[Horizon22]

You could just order the display of them by number of minutes. It's the most basic thing ever. I have no idea why you wouldn't do that.

I gather it is struggling (obviously) to do that based on where the train is.

 

[mrmartin]

I gather it is struggling (obviously) to do that based on where the train is.

It knows where the trains are clearly as it says how many minutes it is away. It's a bug and a one line fix in code to sort train departures by how far away they are!

 

[Horizon22]

It knows where the trains are clearly as it says how many minutes it is away. It's a bug and a one line fix in code to sort train departures by how far away they are!

And the issue being the minutes away is often an estimate and can be wrong.

 

[mrmartin]

And the issue being the minutes away is often an estimate and can be wrong.

Not sure if we are talking about the same thing. Often you'll have stuff like this:

Shenfield 5 minutes
Abbey Wood 3 minutes
Abbey Wood 10 minutes

It should be displayed on the board like this:

Abbey Wood 3 minutes
Shenfield 5 minutes
Abbey Wood 10 minutes

It's just a sorting display problem?

 

[Horizon22]

Not sure if we are talking about the same thing. Often you'll have stuff like this:

Shenfield 5 minutes
Abbey Wood 3 minutes
Abbey Wood 10 minutes

It should be displayed on the board like this:

Abbey Wood 3 minutes
Shenfield 5 minutes
Abbey Wood 10 minutes

It's just a sorting display problem?

I don't know exactly but it might be that the Abbey Wood train is not actually 3 minutes away. This is especially true at Paddington more than any other station due to the boundary with the GWML and how the software is interpretating arrivals, I would presume.

 

[Taunton]

It really is difficult to understand. TfL (probably their predecessors) were real pioneers a good while ago in 'Countdown' departure indicators, based on reality from the signalling system rather than the timetable, and got things pretty right from the word go, in situations more complex than this.

The recent Liz change actually seemed to make a range of things worse; the nonsense displayed at Paddington eastbound (into the core) varies from time to time, but trains arriving and departing there full and standing with proper destinations shown on the train, but Not in Service on the platform describer, and passengers on the platform shouting into the train asking where it is going, should surely be a situation readily able to be fixed.

My hunch is there is some contractual dispute, and while the errors are fully known there are issues on who is going to pay for fixing them.

 

[mrmartin]

I don't know exactly but it might be that the Abbey Wood train is not actually 3 minutes away. This is especially true at Paddington more than any other station due to the boundary with the GWML and how the software is interpretating arrivals, I would presume.

I think you're really overthinking this. I've worked in software dev for nearly 20 years - it's crap display software, end of story. There is absolutely no explanation for this. It's riddled with bugs and doesn't make any sense given realtimetrains works 99% of the time when the boards don't. RTT doesn't even have access to the underlying CBTC software! The boards aren't even consistent in the same station!

At one point when the EL opened all the staff were using RTT on their phones on the wifi to direct passengers because the boards didn't work. The point is they still don't work 2 years later, with at least 3 obvious bugs.

As @Taunton says probably a contractual dispute where Siemens (or whoever) are wanting £millions to fix it - for a couple of days of work, saying the original TfL spec was wrong (or something along them lines).

 

[pelli]

I don't know exactly but it might be that the Abbey Wood train is not actually 3 minutes away. This is especially true at Paddington more than any other station due to the boundary with the GWML and how the software is interpretating arrivals, I would presume.

Recently I had an experience like what you describe, not on the Elizabeth Line, but on Thameslink at Farringdon northbound. The next trains were "1st train Bedford 5 minutes / 2nd train Luton 6 minutes" when suddenly the two swapped order to "1st train Luton 6 minutes / 2nd train Bedford 5 minutes". The Bedford train continued to be shown as 2nd train but fewer minutes away, until around "1st train Luton 2 minutes / 2nd train Bedford 3 minutes", and eventually the Luton train did arrive first.

I infer that the Luton train got to Blackfriars first (after which it is not possible for the Bedford train to overtake) and the system recognised this to place the Luton train first in the list, but the arrival time estimates do not take this into account. Speculating further as to how the farther-away 2nd train can be predicted to be fewer minutes away, I presume the Luton train which was on time was displaying (and running to) times according to the timetable which includes generous dwell times, whereas the Bedford train which was late was displaying expected times according to minimal dwell times that could theoretically have been achieved were it not for the Luton train being in the way (and the pesky passengers wanting to get on and off the train in large numbers at peak time...).

 

[Minstral25]

Recently I had an experience like what you describe, not on the Elizabeth Line, but on Thameslink at Farringdon northbound. The next trains were "1st train Bedford 5 minutes / 2nd train Luton 6 minutes" when suddenly the two swapped order to "1st train Luton 6 minutes / 2nd train Bedford 5 minutes". The Bedford train continued to be shown as 2nd train but fewer minutes away, until around "1st train Luton 2 minutes / 2nd train Bedford 3 minutes", and eventually the Luton train did arrive first.

I infer that the Luton train got to Blackfriars first (after which it is not possible for the Bedford train to overtake) and the system recognised this to place the Luton train first in the list, but the arrival time estimates do not take this into account. Speculating further as to how the farther-away 2nd train can be predicted to be fewer minutes away, I presume the Luton train which was on time was displaying (and running to) times according to the timetable which includes generous dwell times, whereas the Bedford train which was late was displaying expected times according to minimal dwell times that could theoretically have been achieved were it not for the Luton train being in the way (and the pesky passengers wanting to get on and off the train in large numbers at peak time...).

They were probably both before Blackfriars and one can assume the system calculates a set time from each location, until the Bedford arrived at Blackfriars the times are based on it going straight through without delay. After Blackfriars the delay being behind the Luton is added into the calculations as it can no longer overtake.

Seen this at Farringdon a lot when waiting there.

 

[Horizon22]

I think you're really overthinking this. I've worked in software dev for nearly 20 years - it's crap display software, end of story. There is absolutely no explanation for this. It's riddled with bugs and doesn't make any sense given realtimetrains works 99% of the time when the boards don't. RTT doesn't even have access to the underlying CBTC software! The boards aren't even consistent in the same station!

Can't deny it's not riddled with bugs! Just trying to provide some context as to why it might be behaving the way it is. There is obviously an explanation or it wouldn't be happening.

== Doublepost prevention - post automatically merged: 28 Oct 2024 ==

Recently I had an experience like what you describe, not on the Elizabeth Line, but on Thameslink at Farringdon northbound. The next trains were "1st train Bedford 5 minutes / 2nd train Luton 6 minutes" when suddenly the two swapped order to "1st train Luton 6 minutes / 2nd train Bedford 5 minutes". The Bedford train continued to be shown as 2nd train but fewer minutes away, until around "1st train Luton 2 minutes / 2nd train Bedford 3 minutes", and eventually the Luton train did arrive first.

I infer that the Luton train got to Blackfriars first (after which it is not possible for the Bedford train to overtake) and the system recognised this to place the Luton train first in the list, but the arrival time estimates do not take this into account. Speculating further as to how the farther-away 2nd train can be predicted to be fewer minutes away, I presume the Luton train which was on time was displaying (and running to) times according to the timetable which includes generous dwell times, whereas the Bedford train which was late was displaying expected times according to minimal dwell times that could theoretically have been achieved were it not for the Luton train being in the way (and the pesky passengers wanting to get on and off the train in large numbers at peak time...).

Yes at the same thing potentially happens at Whitechapel or Paddington (for Westbourne Park) where the branches / service groups split/join.

 

[Spurs]

They're literally on rails. One is obviously in front of the other. Even if you're not certain exactly how many more minutes each take, it's not exactly complicated to figure that the one in front is gonna get there first and put them in the right order!

 

[Taunton]

There's nothing wrong with showing predictions based on two trains approaching a junction being shown in timetable order, then if that's changed doing a "Correction" notice. Underground has long done that, notably on the Northern Line with its various close headway merges. What is poor is not having the decision integrated with the PIS, let along fundamental boners like displaying them out of sequence. In programming that's about 6 lines of an IF clause in an SQL statement.

 

[Acton1991]

Have there been issues today with the data feed? Trainline this morning (and now this evening) showing delayed on all journeys. But there doesn’t seem to be any line issues noted by TfL… are things running normally?

 

[Horizon22]

Have there been issues today with the data feed? Trainline this morning (and now this evening) showing delayed on all journeys. But there doesn’t seem to be any line issues noted by TfL… are things running normally?

Yes a data feed issue apparently for the timetable. Should be resolved tomorrow.

 

[mathmo]

Today the Elizabeth Line boards are showing "Delayed" for any train which is currently on NR tracks - i.e. Stratford and east, or west of Paddington. Does look like it corrects when the train enters the core but it's not great...

 

[mrmartin]

Deary me. That's a new one to add to the list! What is pretty impressive is the way the boards seem to consistently make the service look much worse than it actually is. It used to be the other way round!