Bristol to Kemble - Delay Repay rejected

[Will Mitchell]

Realtime Trains | 1A12 0724 Taunton to London Paddington | 30/06/2023

Real-time train running information for 1A12 0724 departure from Taunton to London Paddington on 30/06/2023. From Realtime Trains, an independent source of train running info for Great Britain.

www.realtimetrains.co.uk

I travelled from BRI to SWI on this service yesterday morning. The train arrived in Swindon well after 0930 and I missed my connection to Kemble, having to wait nearly an hour for the next one.

GWR are claiming I arrived at Swindon at 0919 and, according to RTT, that is indeed the case. However, this is not what happened in actual, observable reality. I did not get to Swindon until well after 0930. I know because I sent a rant message to my missus at 0931, complaining about the state of the railways, while still on the train.

I am beginning to suspect a conspiracy. How can RTT (or at least the underlying data) be rewriting history like this?

 

[JonathanH]

This source also indicates the timings in RTT. What time did you leave Bristol?

- - TrackIT!

However, not clear why there are times at both Thingley Junction and Bristol Parkway?

 

[sonic2009]

Train looks like it was diverted via Bristol Parkway instead of booked route via Chippenham.

But I can't see where the extra 11 mins the OP mentions are coming from?

 

[JonathanH]

But I can't see where the extra 11 mins the OP mentions are coming from?

No, there is no movement through Swindon from Bristol Temple Meads between 0920 and 1004.

Swindon (Wilts) - TrackIT!

(Not sure how long this will be available.)

 

[winks]

I’ve often found some of the data in real time trains incorrect. When I’ve looked on recent train times the info has been different !

What’s causing this issue ?

 

[The exile]

given the signalling issues between Keynsham and Saltford, a diversion via Parkway is quite likely. Whether under those circumstances a 31 minute timing to Swindon is equally likely, I’m not sure.

 

[The Puddock]

Realtime Trains | 1A12 0724 Taunton to London Paddington | 30/06/2023

Real-time train running information for 1A12 0724 departure from Taunton to London Paddington on 30/06/2023. From Realtime Trains, an independent source of train running info for Great Britain.

www.realtimetrains.co.uk

I travelled from BRI to SWI on this service yesterday morning. The train arrived in Swindon well after 0930 and I missed my connection to Kemble, having to wait nearly an hour for the next one.

GWR are claiming I arrived at Swindon at 0919 and, according to RTT, that is indeed the case. However, this is not what happened in actual, observable reality. I did not get to Swindon until well after 0930. I know because I sent a rant message to my missus at 0931, complaining about the state of the railways, while still on the train.

I am beginning to suspect a conspiracy. How can RTT (or at least the underlying data) be rewriting history like this?

For what it's worth internal railway systems show 1A12 arriving Swindon at 09:19 and departing at 09:22, at which time 1G07 08:31 Paddington to Cheltenham (the 09:29 Swindon to Kemble) was in the Shrivenham area between Didcot Parkway and Swindon. Here is a screenshot from the rail industry CCF, replay system which records data directly from the signalling system, which shows 1A12 in Swindon platform 3 at 09:19:38 -



The data is recorded automatically from the signalling system and cannot be altered subsequently. Is it possible you are mistaken about the time you sent the text message, or about which train you travelled on?

 

[louis97]

I’ve often found some of the data in real time trains incorrect. When I’ve looked on recent train times the info has been different !

What’s causing this issue ?

Are you assuming Realtime Trains is wrong because it is different to Recent Train Times, or do you have some examples? Saying it is wrong without examples is of no help to anyone and if you have some examples I'd be grateful if you could share them.

There are many different data sources and you can't always compare them together fairly.

 

[endofthetunnel]

The RTT data for this train (and the others in the area at the same time) shows most of the timings are directly recorded from the signalling systems as the train steps along its journey, and not in any way manipulated or altered. These times align with the CCF replays from Puddock above too.

 

[Deepgreen]

I have to say that I have never detected what I know to be a wrong timing on RTT, but that's not to say it never happens. I would say it's extremely unlikely and that the effort/risk required to manipulate certain trains' data just wouldn't be worth it from a 'Delay Repay' standpoint.

 

[Bluejays]

Of course there's no conspiracy. How utterly ridiculous. A mistake definitely, probably from yourself, maybe with the data. But the idea that there's a conspiracy to get around delay repay is ludicrous.

 

[43066]

Of course there's no conspiracy. How utterly ridiculous. A mistake definitely, probably from yourself, maybe with the data. But the idea that there's a conspiracy to get around delay repay is ludicrous.

Is the correct answer!

 

[Topological]

Assuming that the OP is right. How would the data get it wrong?

Presumably there is a way that a train could be wrong at one location, although that feels unlikely. Maybe one circuit detects something and makes an assumption but it was not actually a train (I do not know, these days an axle counter might even know which axles it was counting). To have a train wrong all the way along its path, including other timing points, seems particularly far fetched.

Things like the timing point not being when the train comes to a stand feel like a conspiracy, but then I haven't actually had any problems when the train comes to a stand at 30 seconds past the threshold for delay repay at Manchester Piccadilly.

 

[rower40]

I investigated an incident where the train's description stepped into the next berth, but stopped only just after passing the signal. ARS got the blame because, on CCF, it appeared that the onward route hadn't set. But in that case, ARS was programmed not to set the route until the train was nearly at the signal. So the TD steps didn't show the whole story.
It might be that the train in this incident passed the protecting signal outside Swindon, then stopped short of the platform.

 

[greatkingrat]

Are you sure you actually got off at Swindon? Maybe you got confused with the diversion and thought Swindon was Chippenham and actually got off at Didcot (at 0936).

 

[Topological]

I investigated an incident where the train's description stepped into the next berth, but stopped only just after passing the signal. ARS got the blame because, on CCF, it appeared that the onward route hadn't set. But in that case, ARS was programmed not to set the route until the train was nearly at the signal. So the TD steps didn't show the whole story.
It might be that the train in this incident passed the protecting signal outside Swindon, then stopped short of the platform.

I can see that the Cheltenham train used Platform 3 at 09:29 as planned. That is after the OP train had left, but the signal could have held the OP train outside Swindon to allow the Cheltenham to use Platform 3.

However, the conspiracy would have to thicken because a Swansea to London train came from Bristol Parkway and went through Platform 1 at Swindon around 09:25. I do not think there is a way for that Swansea to London to overtake and get into Platform 1?

 

[The Puddock]

It might be that the train in this incident passed the protecting signal outside Swindon, then stopped short of the platform.

It's possible but seems very unlikely. The dwell at Swindon recorded on TRUST for 1A12 was three minutes (09:19 to 09:22) and it passed Uffington six minutes later at 09:28 (all were auto-reports), so in reality it had certainly departed Swindon before 09:30. This is also borne out on the CCF replay. I would have expected the original poster to mention in their post if the train had stopped just outside the platform at Swindon for more than ten minutes.

Are you sure you actually got off at Swindon? Maybe you got confused with the diversion and thought Swindon was Chippenham and actually got off at Didcot (at 0936).

I'm now also wondering if this is what happened.

 

[IndianPacific]

The last few times I've been on a delayed train, the guard has made an announcement to look up the delay repay process.

How does the actual claim process work? Have they been made to start making these announcements?

My delay repay conspiracy is that TOCs were previously happy to get compensation for delays that they wouldn't necessarily pass on to travellers. Is that how it works?

For instance, if a train is delayed by an infrastructure fault (e.g. points failure near a station), does the TOC claim a bunch of compensation from NR then wait to see how many passengers claim delay repay (and therefore get to keep the rest)? Or can the TOC only pass on the bill for amount of delay repay actually claimed by passengers?

 

[DarloRich]

Of course there's no conspiracy. How utterly ridiculous. A mistake definitely, probably from yourself, maybe with the data. But the idea that there's a conspiracy to get around delay repay is ludicrous.

This is the correct answer. It looks like a standard RUK headloss over nothing!

There is no rewriting of history. Does the OP REALLY think train companies have enough resource (even if they had the inclination) to fiddle data relating to one insignificant train running between 2 nothing towns?

The effort would not be worth the reward!

 

[Clarence Yard]

The last few times I've been on a delayed train, the guard has made an announcement to look up the delay repay process.

How does the actual claim process work? Have they been made to start making these announcements?

My delay repay conspiracy is that TOCs were previously happy to get compensation for delays that they wouldn't necessarily pass on to travellers. Is that how it works?

For instance, if a train is delayed by an infrastructure fault (e.g. points failure near a station), does the TOC claim a bunch of compensation from NR then wait to see how many passengers claim delay repay (and therefore get to keep the rest)? Or can the TOC only pass on the bill for amount of delay repay actually claimed by passengers?

The Schedule 8 scheme with NR is completely separate to delay repay, which is not claimable off NR. There is no incentive for TOCs not to pay delay repay.

Schedule 8 is widely misunderstood. It is effectively a delay related liquidated damages scheme for the TOC, not just for paying passenger compensation.

 

[Mcr Warrior]

My delay repay conspiracy is that TOCs were previously happy to get compensation for delays that they wouldn't necessarily pass on to travellers. Is that how it works?

For instance, if a train is delayed by an infrastructure fault (e.g. points failure near a station), does the TOC claim a bunch of compensation from NR then wait to see how many passengers claim delay repay (and therefore get to keep the rest)? Or can the TOC only pass on the bill for amount of delay repay actually claimed by passengers?

Doesn't really help the OP with their query, but yes, have sometimes wondered that. Also, if the terms on which a TOC offers 'Delay Repay' to its delayed passengers (e.g. delays of 30 minutes or more) is similar to the delay threshold when receiving compensation from Network Rail or maybe another TOC whose train has broken down and blocked the line.

There is no incentive for TOCs not to pay delay repay.

Surely the main "incentive" (if that's the most appropriate word) is that they could then just pocket the money that would otherwise have had to be paid out?

 

[62484GlenLyon]

Has the OP got details of the train he was on, such as unit number, actual departure time, intermediate passing times, the actual time that HE arrived at Swindon?

RTT and TrackIT! show that 1A12 was replatformed to use no.7, whereas on the day before is used no.11, which seems to be the booked platform. RTT shows that yesterday 1A13 09.00 BRI - PAD departed right time from plat.12, as booked, 13 minutes behind 1A12.

Is it possible that 1A12 was advertised as using plat.11 when OP arrived at the station, was subject to a very late replatforming to no.7 that he didn't pick up on, and actually was on 1A13??

 

[Clarence Yard]

Surely the main "incentive" (if that's the most appropriate word) is that they could then just pocket the money that would otherwise have had to be paid out?

The TOCS don’t pocket the money these days - it effectively goes to the Government. So, as long as they are not going against the delay repay rules (which, if discovered on audit, could affect their contract performance fees), there is no financial incentive.

 

[D1537]

Has the OP got details of the train he was on, such as unit number, actual departure time, intermediate passing times, the actual time that HE arrived at Swindon?

RTT and TrackIT! show that 1A12 was replatformed to use no.7, whereas on the day before is used no.11, which seems to be the booked platform. RTT shows that yesterday 1A13 09.00 BRI - PAD departed right time from plat.12, as booked, 13 minutes behind 1A12.

Is it possible that 1A12 was advertised as using plat.11 when OP arrived at the station, was subject to a very late replatforming to no.7 that he didn't pick up on, and actually was on 1A13??

I wondered that as well, but 1A13 managed to drop 25 minutes between BRI and SWI, and didn't arrive until 10.08

 

[Falcon1200]

This source also indicates the timings in RTT. What time did you leave Bristol?

- - TrackIT!

However, not clear why there are times at both Thingley Junction and Bristol Parkway?

The Thingley time is odd, I can only think it is possibly a manual Trust input made in error?

Does the OP REALLY think train companies have enough resource (even if they had the inclination) to fiddle data relating to one insignificant train running between 2 nothing towns?

It would require NR to alter, manually, multiple automatic Trust reports, in effect from Swindon onwards, and such interference is an absolute, total, no-no.

Somebody with access to Trust will be able to check the reports for 1A12, which should have Fail to Stop inputs for Bath and Chippenham, and auto reports throughout its journey; Any such report which has been manually altered will have the suffix R (as opposed to A).

 

[crosscity]

I use Railcam and the info there for this train at Swindon is exactly the same as realtimetrains. No conspiracy as far as I can see.

 

[The Puddock]

Somebody with access to Trust will be able to check the reports for 1A12, which should have Fail to Stop inputs for Bath and Chippenham, and auto reports throughout its journey; Any such report which has been manually altered will have the suffix R (as opposed to A).

I checked this morning when I first saw this thread, both Bath and Chippenham are showing as FTS and there are no revised reports.

 

[AndrewE]

so how do all these explain

I travelled from BRI to SWI on this service yesterday morning. The train arrived in Swindon well after 0930 and I missed my connection to Kemble, having to wait nearly an hour for the next one.

You think he was on a later first train than he should have been?

 

[800001]

OP has gone very quite

 

[louis97]

The Thingley time is odd, I can only think it is possibly a manual Trust input made in error?

Signallers often put in reports to clear trains off a TRUST line up they have setup. You'll see it more commonly at locations with shunts to and from a depot which will sometimes have manual departure reports added when they don't run.