F Great Eastern
Established Member
There's been a continuous problem with the 482 Ipswich to London route where one or two journeys on there often don't track a all or someone seemingly logs on to the wrong journey on the ticket machine which gives a load of nonsense on bustimes.org or their own coach tracker. This especially seems to effect peak time journeys on a Friday etc to the airport, which is less than helpful when you really need to know if you need to book a taxi because of extreme late running.
This very much seems to be isolated to a bus/driver rather than a global thing because it doesn't happen to every duty every day and when it does happen it seems to only effect duties operated by a single vehicle that day and normally on back to back runs. For example everything operated by BF68 LCK looks normal today, but everything operated by BF68 LCE looks really weird in terms of tracking.
For example, tonight's 17:10 by BF68 LCE from Ipswich has this nonsensical rubbish on the coach tracker at 17:55, where it shows it already going past Colchester at 18:00, despite the fact the screenshot was only taken at 17:55. It then somehow shows a massive delay for the next stop, which makes no sense coupled with the that it's showing already passed Colchester EARLY.
If we look at BF68 LCE on Bustimes.org, the 17:10 journey isn't listed at all but it's logged into the 08:15 journey still and the map looks really odd because of the way the tracking seems to keep being turned on and off which is probably confusing the hell out of the National Express coach tracker.
From what I can see about that journey, the tracking works at Ipswich, goes off until it gets to Colchester, comes back on, then goes off again upon leaving Colchester. During this time the coach icon of the live position vanishes from the NX site and the vehicle also disappears off bustimes.org like someone has disabled the tracking. No doubt this is playing havoc with the NX tracker like it is playing havoc with the bustimes.org map.
If you look through weeks of bustimes.org data on the 482 and my own observation of taking the services as I travel for work every other week, it's a regular pattern that repeats over and over again in terms of some duties having strange tracking and info like the above. But then there are sometimes a period of 2/3 days where everything works right for both vehicles on that route and there are no tracking problems whatsoever.
To me, the fact that you get periods of 2-3 days where everything works fine and then the same pattern emerges where things don't track properly points to it being a driver issue, since I assume that those days they are off so the problem stops and returns again. Although it does seem odd that 90% of the time the vehicle involved is BF68 LCE, but it may simply be rigidly allocated to those particular runs.
Does anyone know how I would go about bringing this to the attention to NX? Seems to be either a staff or tracking device issue.
Update 18:39
And since making this post, magically the bus started tracking again just a couple of minutes before arriving into Marks Tey, then stopped tracking again, before again starting to track just before stopping in Braintree and the bus now shows on time on the NX App.
Really does look to be intentional disabling of tracking between stops or some faulty equipment.
This very much seems to be isolated to a bus/driver rather than a global thing because it doesn't happen to every duty every day and when it does happen it seems to only effect duties operated by a single vehicle that day and normally on back to back runs. For example everything operated by BF68 LCK looks normal today, but everything operated by BF68 LCE looks really weird in terms of tracking.
For example, tonight's 17:10 by BF68 LCE from Ipswich has this nonsensical rubbish on the coach tracker at 17:55, where it shows it already going past Colchester at 18:00, despite the fact the screenshot was only taken at 17:55. It then somehow shows a massive delay for the next stop, which makes no sense coupled with the that it's showing already passed Colchester EARLY.
If we look at BF68 LCE on Bustimes.org, the 17:10 journey isn't listed at all but it's logged into the 08:15 journey still and the map looks really odd because of the way the tracking seems to keep being turned on and off which is probably confusing the hell out of the National Express coach tracker.
From what I can see about that journey, the tracking works at Ipswich, goes off until it gets to Colchester, comes back on, then goes off again upon leaving Colchester. During this time the coach icon of the live position vanishes from the NX site and the vehicle also disappears off bustimes.org like someone has disabled the tracking. No doubt this is playing havoc with the NX tracker like it is playing havoc with the bustimes.org map.
If you look through weeks of bustimes.org data on the 482 and my own observation of taking the services as I travel for work every other week, it's a regular pattern that repeats over and over again in terms of some duties having strange tracking and info like the above. But then there are sometimes a period of 2/3 days where everything works right for both vehicles on that route and there are no tracking problems whatsoever.
To me, the fact that you get periods of 2-3 days where everything works fine and then the same pattern emerges where things don't track properly points to it being a driver issue, since I assume that those days they are off so the problem stops and returns again. Although it does seem odd that 90% of the time the vehicle involved is BF68 LCE, but it may simply be rigidly allocated to those particular runs.
Does anyone know how I would go about bringing this to the attention to NX? Seems to be either a staff or tracking device issue.
Update 18:39
And since making this post, magically the bus started tracking again just a couple of minutes before arriving into Marks Tey, then stopped tracking again, before again starting to track just before stopping in Braintree and the bus now shows on time on the NX App.
Really does look to be intentional disabling of tracking between stops or some faulty equipment.
Last edited:
