Yes, I managed to get caught up in this mess today,
Whilst I have every sympathy with those caught-up in yesterday's fiasco, shouldn't we give NR/EC some credit for even attempting to run a service?
As far as I can see, the alternative would have been a total blockade and bustitution from Stevenage to Biggleswade, or even further north.
Then the complaints would have come rolling in!
So to summarise, the root cause of the problem is that 365s have an AWS related issue when coasting with pan(s) down? It causes an unecessary brake application that drivers cannot rectify - have I understood that?
And this is a known problem with history behind it?
How long was the coasting section? From where to where?
I do seem to remember 365s having this problem coasting in the past (having been on one that kept stopping, and the PIS restarting multiple times). Is there a particular reason they didn't go for 317s/321s this time?
cl365's were originally equipped with 2 AWS receivers - one for AC operation and one for DC operation.
Same control box, sunflower, push button etc but the voltage selection system set up from pressing the "Pan down/DC select" or "Pan up/AC select" caused different relays to energise and brought the appropriate receiver into use.
When the whole fleet ended up on the AC there was a solid state AWS receiver modification being developed, which did away with the 2 separate receivers for one common one.
It is possible that, as it isn't possible for the cl365's to go back and run on the DC due to certification issues and the fundamental lack of DC current collection equipment, the need for an operational DC AWS receiver was overlooked or discounted.
If this is the case; as the unit is coming out of the live OHL section and the driver presses Pan down/DC select to bring the pan off the dead OHL the unit goes into DC mode. This causes the AWS system to self test, but it will fail self test if there isn't a DC receiver present (or the relays/wiring haven't been modified to use the single receiver) and the brakes will apply and cannot be released without either selecting Pan up/AC select - which can't be done due to the OHL isolation - or isolating the AWS.
And as usual, an utter lack of communication from FCC about what was going on, which was irritating passengers far more than the delays themselves.
As seems to be the case every single time. It seems FCC has a good bunch of people that can help work to get people going again, even laying on bus replacements at fairly short notice on many occasions. They can crack on with all the hard stuff, then let everyone down because they can't provide information to people!
Surely the information provision is the easy bit? Twitter has helped a lot, but not everyone knows about, or uses, Twitter so they're still stuck on platforms or in their offices/homes wondering what's going on. The departure boards also do their very best to convey incorrect information and the 'on time' nonsense.
One bit of information we can be sure to get is that 'FCC takes this very seriously and will investigate what happened to make sure it doesn't happen again'.
I thought the screens on the 317/1s (as fitted by Wagn) were supposed to be able to convey 'live' information. One ONE single occasion I remember hearing on a FCC service an announcement about the train being late running, but I can't for the life of me remember what the wording was.
Now, the driver might have manually set that - or the software was set to detect the service was late (which means it knew the working timetable) so it might not be the case that it was sent any info from outside of the train (does anyone know if they have any form of data connection to the outside world?). Whatever the case, I'm quite sure that FCC did say once that they expected to provide realtime info onboard - including the tube status. That would have to be fed to the train somehow.
As has been suggested many times, FCC (or the industry in general) needs to tie-up services so that a service formed of a delayed inbound train doesn't show as 'on time' simply because it isn't due to leave yet (then immediately switching to Delayed, or worse still - the dreaded Estimated <time> + 1 minute that counts up indefinitely). When it keeps saying a time, people justifiably wait for it when it doesn't actually exist. After a long wait, chances are control will officially cancel it and that delayed train comes off the boards (if it's suitably late) which angers people even more. You've just waited ages for a train and it's gone? Where has it gone? You were lying to us all along. You don't have a clue.. etc.
If they could see the train that is coming in to form that service doesn't exist, more accurate information could be given automatically - leaving the TOC to concentrate on more detailed info on special services etc.