Conwy Valley false delays

[Bletchleyite]

Was up on the Conwy Valley line this weekend, and I noticed that basically every train comes up as "delayed" once it's passed Llanrwst, which is really causing people a lot of confusion. It appears to be because the 197s are perhaps not fitted with the GPS kit that I think was being trialled before to give more accurate running times, or it isn't working consistently? Therefore the only reports that are going on are those made manually by Llanrwst box and between Llandudno Junction and Llandudno.

Does anyone know how long this has been going on (it's been a while since I was up there) and if there's a plan to fix it? At least they'd be best off configuring the system to only expect reports at Llanrwst box and not to consider the train delayed if it hasn't been reported elsewhere unless someone specifically enters that it is. There were a lot of very confused tourists looking quite alarmed at the display - I wandered round explaining it to them all and that it wasn't really delayed (it wasn't, it was on time) but it really isn't ideal, particularly for a line that is so heavily tourist and occasional user oriented.

(Otherwise I still think the feel the line has these days is great, with the Swiss-like livery and new trains giving it a much more upbeat feel than rotting 150s and 153s - and there were decent numbers of passengers too)

 

[Vexed]

Seems it's been going on a while - I had a look at some Darwin message data I have from November 2024 and had a look at this service which had no GPS reports. The Charlwood House link shows the TRUST reports.

The Darwin data I have shows Darwin receiving an on time departure from Llandudno from TRUST at 13:17:14. Then at 13:32:01 it starts forecasting a 1 minute delay for Glan Conwy onwards, which increases minute by minute until it switched to just "Delayed".

If I was to guess, Darwin expects to get a time from TRUST of the departure from Llandudno Junction - I can see arrival and departure reports exist on Charlwood House. Darwin only got the arrival report, so I assume Darwin thinks it never left Llandudno Junction until it gets told otherwise.

I've had a quick look and I can't find any others without GPS to see if this is a repeated pattern.

Unfortunately my database filled up in February and I never got around to fixing it so I don't have more recent examples to hand. The data does exist somewhere.

No idea about GPS on the 197s - they almost certainly have it installed but I don't know if it's linked to Darwin/TRUST yet.

---

Darwin = "single source of truth" for live passenger information, forecasts expected delays, powers station departure boards and most live train apps. Gets data from different sources including TRUST and GPS
TRUST = Network Rail's records of train running

 

[JKCK]

I know at Chester that the Departure Boards will show the train as on time, then various stages of losing time, then delayed and finally back on time on Services from Birmingham to Holyhead/Manchester via Wrexham. Chester staff say it is down to no real time updates between Ruabon and Chirk, so works on the time it left Gobowen and then doesn't get an update until Wrexham.

 

[sheff1]

Is this a Welsh thing ? I noticed the same happening at Shrewsbury, another Transport for Wales managed station.

 

[Horizon22]

This would seem to be an issue with a lack of availble berths / TD data as mentioned. If the data isn't entered manually, or it has reached the last reporting point after 3 minutes the train is presumably going to think it is delayed.

No idea about GPS on the 197s - they almost certainly have it installed but I don't know if it's linked to Darwin/TRUST yet.

I wasn't sure GPS on trains fed live location data around the network, but happy to be corrected.

 

[Vexed]

I wasn't sure GPS on trains fed live location data around the network, but happy to be corrected.

Internally the data exists from most trains, sadly it just isn't widely used in public-facing systems. It's a system called CIGP or TLMS, I'm not sure what isn't actually called now as there's so little information publicly available!

An example of where it is used is this, if you hover over the Realtime reports quite a few say TRUST (GPS) as opposed to TRUST (SDR) which is a manually entered report.

Realtime Trains | 2D16 1315 Llandudno to Blaenau Ffestiniog | 31/03/2025

Real-time train running information for 2D16 1315 departure from Llandudno to Blaenau Ffestiniog on 31/03/2025. From Realtime Trains, an independent source of train running info for Great Britain.

www.realtimetrains.co.uk

It appears to be because the 197s are perhaps not fitted with the GPS kit that I think was being trialled before to give more accurate running times, or it isn't working consistently?

Also the above answers the question of whether 197s have GPS, as RTT shows the service linked has both has GPS reports and is operated by a 197. So as long as there is a reliable mobile data connection to report back the GPS and no hardware or software issues, Darwin should be broadly accurate.

 

[Horizon22]

Internally the data exists from most trains, sadly it just isn't widely used in public-facing systems. It's a system called CIGP or TLMS, I'm not sure what isn't actually called now as there's so little information publicly available!

An example of where it is used is this, if you hover over the Realtime reports quite a few say TRUST (GPS) as opposed to TRUST (SDR) which is a manually entered report.

Ah makes sense, didn't realise you could see the differentiation, thanks!

So as long as there is a reliable mobile data connection to report back the GPS and no hardware or software issues, Darwin should be broadly accurate.

I imagine this might be one of the issues. Just like how on-train wi-fi is patchy in places because it is still reliant on mobile signal.

 

[Bletchleyite]

I wasn't sure GPS on trains fed live location data around the network, but happy to be corrected.

There was a specific project a while back to introduce that on the Conwy Valley, as the only reporting point south of Llandudno Jn is (or was) Llanrwst box.

Is this a Welsh thing ? I noticed the same happening at Shrewsbury, another Transport for Wales managed station.

It's a thing on some lines with traditional signalling and few signal boxes. Imagine it might occur to some extent on the S&C?

 

[louis97]

I know at Chester that the Departure Boards will show the train as on time, then various stages of losing time, then delayed and finally back on time on Services from Birmingham to Holyhead/Manchester via Wrexham. Chester staff say it is down to no real time updates between Ruabon and Chirk, so works on the time it left Gobowen and then doesn't get an update until Wrexham.

This sounds like a configuration issue, partly caused by the more widespread use of GPS reports now.

If GPS reports are working as they should, you shouldn't get any false reporting of the train being "delayed", as at each station you'll get a report of some kind.

However, soon as you get a train with a fault causing the GPS reports not to be provided, you'll end up with "delayed" because of the expected GPS report not being made.

I think its possible to mark locations in Darwin(?) as to whether a report is manual or automatic, if it is manual the system won't flag up "delayed" as its possible the manual report is just delayed in being entered. However I suspect since the rollout of GPS reports locations are being switched to automatic reporting configuration. This works fine if the GPS is working correctly on the train, however soon as you get a train where it isn't you get the "delayed" message unless a manual report is entered.

 

[Krokodil]

No idea about GPS on the 197s - they almost certainly have it installed but I don't know if it's linked to Darwin/TRUST yet.

I wasn't sure GPS on trains fed live location data around the network, but happy to be corrected.

They do (and so do TfW's 15x) but it can be unreliable. Take 2D15 today:

Realtime Trains | 2D15 1137 Blaenau Ffestiniog to Llandudno | 31/03/2025

Real-time train running information for 2D15 1137 departure from Blaenau Ffestiniog to Llandudno on 31/03/2025. From Realtime Trains, an independent source of train running info for Great Britain.

www.realtimetrains.co.uk

Reported leaving Blaenau, then no reports for the three request stops (even if not requested they should still show a passing time) before starting to work again from Betws onwards.

Llanrwst box appear to have forgotten the manual entry there, which seems to be the reason that the train was showing "delayed" until it arrived at Llandudno Junction. Interestingly it was showing this even after it had self-reported as being on time at Tal-y-Cafn.

Stupidly there is no way of overriding this part of the CIS manually, either locally or by Control. It's possible to manually add delays on, but no way of removing them. So until they fix this (which has been going on for months) any route where the Train Describer berths don't automatically update the train's progress has been having this issue.

 

[Llandudno]

They do (and so do TfW's 15x) but it can be unreliable. Take 2D15 today:

Realtime Trains | 2D15 1137 Blaenau Ffestiniog to Llandudno | 31/03/2025

Real-time train running information for 2D15 1137 departure from Blaenau Ffestiniog to Llandudno on 31/03/2025. From Realtime Trains, an independent source of train running info for Great Britain.

www.realtimetrains.co.uk

Reported leaving Blaenau, then no reports for the three request stops (even if not requested they should still show a passing time) before starting to work again from Betws onwards.

Llanrwst box appear to have forgotten the manual entry there, which seems to be the reason that the train was showing "delayed" until it arrived at Llandudno Junction. Interestingly it was showing this even after it had self-reported as being on time at Tal-y-Cafn.

Stupidly there is no way of overriding this part of the CIS manually, either locally or by Control. It's possible to manually add delays on, but no way of removing them. So until they fix this (which has been going on for months) any route where the Train Describer berths don't automatically update the train's progress has been having this issue.

I guess it must be easy to omit to input the manual data at Llanrwst box as it must be a such a stressful job with so many trains to oversee….!

We were planning to catch a train on the Conwy Valley line last week, saw that the outbound train was delayed so didn’t bother!

 

[Falcon1200]

I know at Chester that the Departure Boards will show the train as on time, then various stages of losing time, then delayed and finally back on time on Services from Birmingham to Holyhead/Manchester via Wrexham.

The same thing happened recently at Wrexham; Train to Chester shown delayed, albeit not by how much, only for it to roll in right on time! Surely there is a simple fix to only show a train delayed when it actually passes a reporting point late, not just because of a lack of reports?

 

[Purple Train]

Is this a Welsh thing ? I noticed the same happening at Shrewsbury, another Transport for Wales managed station.

GWR Didcot-Paddington services show as "delayed" at Slough during the (booked) 15-minute stop at Reading, and then show as "on time" thereafter. A version of the same issue, I guess, and hopefully not the most difficult thing to resolve!

 

[Horizon22]

GWR Didcot-Paddington services show as "delayed" at Slough during the (booked) 15-minute stop at Reading, and then show as "on time" thereafter. A version of the same issue, I guess, and hopefully not the most difficult thing to resolve!

Long dwells do tend to complicate the system, as can attaching/detatching. Especially if the headcode changes.

 

[Krokodil]

Surely there is a simple fix to only show a train delayed when it actually passes a reporting point late, not just because of a lack of reports?

Yes, the system used to work that but then someone decided that something which wasn't broken needed fixing!

 

[Horizon22]

Yes, the system used to work that but then someone decided that something which wasn't broken needed fixing!

The CIS is taking that as one and the same though. If a train doesn't pass a certain TD/berth after 3 minutes, it will appear "Delayed" (+999/+995 on a Worldline system). In this case, a manual report IS the comparative TD/berth, so if no reports are recieved and there are no / few intermediate reporting points, then unit it reaches that next intermediate point it will be "Delayed"; the system can't presume anything. So the manual report is important in this instance (when not supplanted by train GPS data).

 

[Krokodil]

The CIS is taking that as one and the same though. If a train doesn't pass a certain TD/berth after 3 minutes, it will appear "Delayed" (+999/+995 on a Worldline system). In this case, a manual report IS the comparative TD/berth, so if no reports are recieved and there are no / few intermediate reporting points, then unit it reaches that next intermediate point it will be "Delayed"; the system can't presume anything. So the manual report is important in this instance (when not supplanted by train GPS data).

It never used to in an area without TD automatic reporting. It always used to assume that the train was on time until the train either self-reported passing a timing point late using GPS or a manual report was made by the signaller. The system changed at some point last year and spurious delays started appearing en masse.

 

[Lewisham2221]

The same thing happened recently at Wrexham; Train to Chester shown delayed, albeit not by how much, only for it to roll in right on time! Surely there is a simple fix to only show a train delayed when it actually passes a reporting point late, not just because of a lack of reports?

Wouldn't you then have situations where a train comes to a stand between reporting points - let's say there's a tree branch causing an obstruction - and despite having been at a standstill for 10+ minutes is still showing as on time? Weren't people complaining about similar instances fairly recently? That said, something needs doing, as the current set-up is far too "sensitive" and is causing all manner of confusion.

 

[Krokodil]

Wouldn't you then have situations where a train comes to a stand between reporting points - let's say there's a tree branch causing an obstruction - and despite having been at a standstill for 10+ minutes is still showing as on time?

Yes, but the best thing to do in that situation is for Control to add delays manually. This is not something that frequently happens in manual/GPS reporting areas so this wouldn't be an excessive extra workload.

 

[Lewisham2221]

Yes, but the best thing to do in that situation is for Control to add delays manually. This is not something that frequently happens in manual/GPS reporting areas so this wouldn't be an excessive extra workload.

Oh I totally agree, just pointing out that it wouldn't be without its own "false" information - albeit far less often the current set-up displays false delays.

 

[nwales58]

My impression is that there was a change to the heuristics on when to show 'delayed' some time in 2024. I don't know the IT infrastructure though so that is a guess. Or is it due to more precise location data being partly available and what happens when not?

You see 'delayed' far more often than previously. For example at Bangor a train shows on time when it should leave Holyhead then delayed sometimes for a long time, then on time again as it gets close.

For the general public it would be better to show the last status with an implied question mark, e.g. 'On time (4 mins ago)'

 

[Krokodil]

For example at Bangor a train shows on time when it should leave Holyhead then delayed sometimes for a long time, then on time again as it gets close.

It will show on time when Valley signalbox makes a manual entry. If the GPS fails to record passing/calling time at Rhosneigr then the system will start counting the phantom delay. Only if/when it successfully records a passing time at a later recording point or Gaerwen signal box remembers to make an entry there will the system sort itself out. It's quite a long section between Valley and Gaerwen so "Delayed" will be stuck on the boards for some time before it is corrected.

The most annoying part is that there is no ability to remove the "delay" manually.

 

[Bletchleyite]

I guess it must be easy to omit to input the manual data at Llanrwst box as it must be a such a stressful job with so many trains to oversee….!

We were planning to catch a train on the Conwy Valley line last week, saw that the outbound train was delayed so didn’t bother!

Thing is it probably wasn't, it cross pollinates onto the next train the "delayed" one works too. It really is a mess.

 

[Krokodil]

Thing is it probably wasn't, it cross pollinates onto the next train the "delayed" one works too. It really is a mess.

And often the one after that. We have been complaining about this for something in the region of six months.

Yet when a mainline train was running late the system hadn't connected this to its back working. I was travelling in to work, waiting at the terminus and ended up phoning Control to ask them to manually add a ten minute delay to the back working, so that the train didn't disappear from the screen.

 

[Falcon1200]

Wouldn't you then have situations where a train comes to a stand between reporting points - let's say there's a tree branch causing an obstruction - and despite having been at a standstill for 10+ minutes is still showing as on time?

True, but most trains are not delayed, so the number of trains wrongly shown on time is far outweighed by those shown delayed when they are not!

 

[Wilts Wanderer]

Given the current national focus on the performance of the railway etc, a badly designed system that is persistently falsely advertising delays really should be addressed without, erm, delay. Talk about shooting yourself in the foot!

 

[teethduck]

Borderlands Line also does this rather frequently, so not sure if its a TfW issue

Borderlands Line also does this rather frequently, so not sure if its a TfW issue

Couldn’t make it up… I’m at Hawarden Bridge as we speak and it’s just happened again !