... before it's enemy action?
https://www.telegraph.co.uk/news/2026/09/08/flights-heathrow-gatwick-grounded1/
On 08/09/2026 18:17, Joe wrote:I didn't read that anywhere in the article....
... before it's enemy action?
https://www.telegraph.co.uk/news/2026/09/08/flights-heathrow-gatwick-grounded1/
Well, we now the facts. It was a Biggles fat-finger fault. Own goal.
On 13/09/2026 22:34, Andrew wrote:
On 08/09/2026 18:17, Joe wrote:
... before it's enemy action?
https://www.telegraph.co.uk/news/2026/09/08/flights-heathrow-gatwick-
grounded1/
Well, we now the facts. It was a Biggles fat-finger fault. Own goal.
I didn't read that anywhere in the article....
The Natural Philosopher wrote:
On 13/09/2026 22:34, Andrew wrote:
On 08/09/2026 18:17, Joe wrote:
... before it's enemy action?
https://www.telegraph.co.uk/news/2026/09/08/flights-heathrow-gatwick- >>>>grounded1/
Well, we now the facts. It was a Biggles fat-finger fault. Own goal.
I didn't read that anywhere in the article....
Latest I've read is NATS are blaming spurious data from a military flight?
The Natural Philosopher wrote:
On 13/09/2026 22:34, Andrew wrote:
On 08/09/2026 18:17, Joe wrote:
... before it's enemy action?
https://www.telegraph.co.uk/news/2026/09/08/flights-heathrow-gatwick- grounded1/
Well, we now the facts. It was a Biggles fat-finger fault. Own goal.
I didn't read that anywhere in the article....
Latest I've read is NATS are blaming spurious data from a military flight?
On 14/09/2026 in message <ngpthgFlqu5U1@mid.individual.net> Andy Burns wrote:
The Natural Philosopher wrote:
On 13/09/2026 22:34, Andrew wrote:
On 08/09/2026 18:17, Joe wrote:
... before it's enemy action?
https://www.telegraph.co.uk/news/2026/09/08/flights-heathrow-gatwick- grounded1/
Well, we now the facts. It was a Biggles fat-finger fault. Own goal.
I didn't read that anywhere in the article....
Latest I've read is NATS are blaming spurious data from a military
flight?
Interesting, we have Chinooks over here quite frequently and their
actual location is always different to that shown by Flightradar 24 by a
few minutes, security?
Andy Burns wrote:
Latest I've read is NATS are blaming spurious data from a military
flight?
Interesting, we have Chinooks over here quite frequently and their
actual location is always different to that shown by Flightradar 24 by a
few minutes, security?
Jeff Gaines wrote:
Andy Burns wrote:
Latest I've read is NATS are blaming spurious data from a military
flight?
Interesting, we have Chinooks over here quite frequently and their
actual location is always different to that shown by Flightradar 24
by a few minutes, security?
I don't think the system that failed is the one that controls flight
levels and headings, but the one that accepts details of planned
flights from the airlines (and military) obviously one feeds into the
other.
Isn't all of flightradar24 delayed? You could buy a cheap RTL-SDR
and build an ADS-B aerial from a coke can and a stub of stiff wire,
receive the data yourself direct from the aircraft ...
On 14/09/2026 10:36, Andy Burns wrote:
The Natural Philosopher wrote:
On 13/09/2026 22:34, Andrew wrote:
On 08/09/2026 18:17, Joe wrote:
... before it's enemy action?
https://www.telegraph.co.uk/news/2026/09/08/flights-heathrow-gatwick- >>>> grounded1/
Well, we now the facts. It was a Biggles fat-finger fault. Own
goal.
I didn't read that anywhere in the article....
Latest I've read is NATS are blaming spurious data from a militaryI had heard third hand that it was bad data, but have seen no actual detailed explanation
flight?
Perhaps its time to fire up the Vulture...
...mmm. The scuttlebutt has it as a military flight. Posting
improbable data. Probably filing a flight plan above 64000 feet or
something
On 14/09/2026 10:36, Andy Burns wrote:
The Natural Philosopher wrote:I had heard third hand that it was bad data, but have seen no actual detailed explanation
On 13/09/2026 22:34, Andrew wrote:
On 08/09/2026 18:17, Joe wrote:
... before it's enemy action?
https://www.telegraph.co.uk/news/2026/09/08/flights-heathrow-
gatwick- grounded1/
Well, we now the facts. It was a Biggles fat-finger fault. Own goal.
I didn't read that anywhere in the article....
Latest I've read is NATS are blaming spurious data from a military
flight?
Perhaps its time to fire up the Vulture...
...mmm. The scuttlebutt has it as a military flight. Posting improbable data. Probably filing a flight plan above 64000 feet or something
On Mon, 14 Sep 2026 11:20:29 +0100
The Natural Philosopher <tnp@invalid.invalid> wrote:
On 14/09/2026 10:36, Andy Burns wrote:
The Natural Philosopher wrote:I had heard third hand that it was bad data, but have seen no actual
On 13/09/2026 22:34, Andrew wrote:
On 08/09/2026 18:17, Joe wrote:
... before it's enemy action?
https://www.telegraph.co.uk/news/2026/09/08/flights-heathrow-gatwick- >>>>>> grounded1/
Well, we now the facts. It was a Biggles fat-finger fault. Own
goal.
I didn't read that anywhere in the article....
Latest I've read is NATS are blaming spurious data from a military
flight?
detailed explanation
Perhaps its time to fire up the Vulture...
...mmm. The scuttlebutt has it as a military flight. Posting
improbable data. Probably filing a flight plan above 64000 feet or
something
And exactly the same fault as last screwed up ATC, a couple of years
ago.
I had heard third hand that it was bad data, but have seen no actual detailed explanation[this will probably paste with dodgy formatting]
Perhaps its time to fire up the Vulture...
...mmm. The scuttlebutt has it as a military flight. Posting improbable data. Probably filing a flight plan above 64000 feet or something
The Natural Philosopher wrote:
I had heard third hand that it was bad data, but have seen no actual[this will probably paste with dodgy formatting]
detailed explanation
Perhaps its time to fire up the Vulture...
...mmm. The scuttlebutt has it as a military flight. Posting improbable
data. Probably filing a flight plan above 64000 feet or something
<https://www.nats.aero/wp-content/uploads/2026/09/NATS-Preliminary-Investigation-Report-into-NAS-Incident-on-08-Sept-2026-Issued-16-Sept-2026.pdf>
The reason this scenario has not occurred before is because:
1. The defect existed in a specific subsection of code within a software module, with an exposure window estimated as approximately one millisecond.
2. For the fault to occur, a higher-priority request had to arrive
during that exact millisecond while the original request was part-way
through updating a value.
3. Had the higher-priority request arrived even one millisecond earlier or later, the update would have completed normally.
Post-incident investigation has identified that when processing of the
squawk allocation request resumed, the data associated with it had been corrupted and affected some subsequent flight data updates.
[END QUOTE]
So something assuming timestamp to the millisecond will be unique?
Surprised it didn't happen earlier ...
So something assuming timestamp to the millisecond will be unique?
In article <nh4vu2Fem8jU1@mid.individual.net>,
Andy Burns <usenet@andyburns.uk> wrote:
So something assuming timestamp to the millisecond will be unique?
Sounds more like a failure to lock a shared data structure.
The Natural Philosopher wrote:
I had heard third hand that it was bad data, but have seen no actual[this will probably paste with dodgy formatting]
detailed explanation
Perhaps its time to fire up the Vulture...
...mmm. The scuttlebutt has it as a military flight. Posting
improbable data. Probably filing a flight plan above 64000 feet or
something
<https://www.nats.aero/wp-content/uploads/2026/09/NATS-Preliminary-Investigation-Report-into-NAS-Incident-on-08-Sept-2026-Issued-16-Sept-2026.pdf>
[QUOTE]
the incident was caused by a legacy and previously unknown defect in a software module within the NAS which processes requests for the
allocation or reassignment of squawk codes. A squawk code is an identification code transmitted (squawked) by the aircraft during
flight, enabling air traffic control systems to match the aircraftrCOs altitude, speed and direction with its intended flight plan so that
flight progress can be monitored.
The incident was triggered by a valid manual request for a squawk code.
This manual request was made correctly and there was nothing abnormal or invalid about the associated flight plan.
While this request was being processed, the NAS received a message for a higher priority activity to be undertaken which resulted in the squawk
code allocation being paused while the system processed the higher
priority message. Switching between different activities in response to prioritised requests is a normal function of the system; however, when
the processing of the squawk allocation request resumed, the software
defect meant it did not resume correctly and the resulting output was corrupted.
The reason this scenario has not occurred before is because:
1. The defect existed in a specific subsection of code within a software module, with an exposure window estimated as approximately one millisecond.
2. For the fault to occur, a higher-priority request had to arrive
during that exact millisecond while the original request was part-way
through updating a value.
3. Had the higher-priority request arrived even one millisecond earlier
or later, the update would have completed normally.
Post-incident investigation has identified that when processing of the
squawk allocation request resumed, the data associated with it had been corrupted and affected some subsequent flight data updates.
[END QUOTE]
So something assuming timestamp to the millisecond will be unique?
Surprised it didn't happen earlier ...
On 18/09/2026 15:25, Andy Burns wrote:
The Natural Philosopher wrote:
I had heard third hand that it was bad data, but have seen no actual[this will probably paste with dodgy formatting]
detailed explanation
Perhaps its time to fire up the Vulture...
...mmm. The scuttlebutt has it as a military flight. Posting
improbable data. Probably filing a flight plan above 64000 feet or
something
<https://www.nats.aero/wp-content/uploads/2026/09/NATS-Preliminary-Investigation-Report-into-NAS-Incident-on-08-Sept-2026-Issued-16-Sept-2026.pdf>
The reason this scenario has not occurred before is because:
1. The defect existed in a specific subsection of code within a
software module, with an exposure window estimated as approximately
one millisecond.
2. For the fault to occur, a higher-priority request had to arrive
during that exact millisecond while the original request was part-way
through updating a value.
3. Had the higher-priority request arrived even one millisecond
earlier or later, the update would have completed normally.
Post-incident investigation has identified that when processing of the
squawk allocation request resumed, the data associated with it had been
corrupted and affected some subsequent flight data updates.
[END QUOTE]
So something assuming timestamp to the millisecond will be unique?
Surprised it didn't happen earlier ...
-aI'd read that as some of the code is not properly thread-safe.
In article <nh4vu2Fem8jU1@mid.individual.net>,
Andy Burns <usenet@andyburns.uk> wrote:
So something assuming timestamp to the millisecond will be unique?
Sounds more like a failure to lock a shared data structure.
-- Richard--
On Fri, 18 Sep 2026 15:30:46 -0000 (UTC)
richard@cogsci.ed.ac.uk (Richard Tobin) wrote:
In article <nh4vu2Fem8jU1@mid.individual.net>,
Andy Burns <usenet@andyburns.uk> wrote:
So something assuming timestamp to the millisecond will be unique?
Sounds more like a failure to lock a shared data structure.
I believe race hazards in hardware and software have been understood
for many decades. Was this programmed in COBOL?
| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 74 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 122:26:04 |
| Calls: | 1,194 |
| Files: | 1,352 |
| Messages: | 290,355 |