FlightmechH3
Pre-takeoff checklist
- Joined
- Dec 30, 2021
- Messages
- 148
- Display Name
Display name:
FlightmechH3
Per the video, at least one light does seem to be active, but I see no others. That tower was just over 1000’ tall, so it should normally have plenty of lights, but I’m not sure how much or little of it we’re seeing in that video.How does this happen? The tower is lit.
10/073 - OBST TOWER LGT (ASR 1052552) 294527.00N0952020.00W (7.4NM NNW HOU) 1033.8FT (999.0FT AGL) U/S. 17 OCT 04:44 2024 UNTIL 31 OCT 23:59 2024. CREATED: 17 OCT 04:44 2024 |
Not all of the lights were lit--only the beacon at the top. They're flying in an urban area that is saturated with lights. Picking out a lone flashing light that might be blending in with lights on the horizon until you're right on top of it might be a challenge.How does this happen? The tower is lit.
I believe you're thinking of the older-style red lights -- flashing red at the top (AOL) and solid red side lights. This tower used strobes, which are on the same circuit. I'm a (mostly-retired now) broadcast engineer, and we shifted a bunch of towers to strobes to avoid the expense of painting the tower. The FAA and FCC will also permit you flash ALL lights nowadays, even with the older-style red lighting. We do it on WDJC FM in Birmingham. (Confused a lot of my fellow engineers when they saw it, too. "You done wired your lights wrong!")Generally, tower lights are two separate circuits, preferably from separate sources.
It kind of looks like it might be the top beacon, but at their presumed altitude of 600’, they would have been only a bit more than halfway up the tower. From that camera angle and looking at the horizon, it doesn’t look like that beacon is situated anywhere near another horizon-to-helicopter length above the helicopter’s impact point. One of three possibilities exists: that’s not the top light, the camera angle is deceptive, or the reported ADS-B altitude was off.only the beacon at the top.
Stupid question, but is there a FAA suggestion box?What happened here is tragic. This was one of my personal nightmares when I was active in the field, too. It's not easy keeping strobes in service on a 1,000' lightning rod. (Ask me how I know.) We religiously called in NOTAMS (within 15 minutes, under the rules) anytime our lights were out, and then prayed that pilots would notice them among all the other jabber and garbage in the NOTAM lists. I remember thinking, "this is the 21st century -- you'd think they could sort NOTAMs by priority somehow ..."
Additional detail on prior flights on 10/20:This flight path or similar was repeated very often, including several times prior on the night of the accident, and a dozen times during the week prior. A big loop from Ellington up to Pasadena, then following the Buffalo Bayou to Downtown, then south toward NRG and back to Ellington. This, along with the presence of a child, leads me to believe this is a sightseeing operation.
Every time they passed the KQUE tower previously, they gave it a 1000’ berth, sometimes north, sometimes south. Except this time, where they flew right into it.
As they were flying toward the north edge of downtown, I expect their forward visual would have been full of lights. Will be interesting to hear whether they had an operating and non-inhibited HTAWS.
Yes. And a flight late Saturday (technically Sunday AM UTC) went north of the tower, avoiding it by about the same distance as the other (successful) flights.Additional detail on prior flights on 10/20:
On the 1714 CDT flight, the track approaching the antenna was entirely south of Navigation Blvd, keeping the helo well clear of the antenna.
On the 1847 CDT flight, the track approaching the antenna crossed Navigation Blvd at Engelke and then crossed Engelke at Palmer, about one block from the antenna.
On the 1942 CDT accident flight, the approach to the area of the struck antenna was entirely to the north of Navigation Blvd.
I hope I didn't sound like I was blaming anyone involved -- more just exasperated. I also wondered about obstacle and terrain avoidance on-board.Will be interesting to hear whether they had an operating and non-inhibited HTAWS.
Thanks, I hadn't seen that one yet. Here's a link to the page with that video: https://www.click2houston.com/news/...ct-of-houston-helicopter-crash-that-killed-4/In a different video shown on KPRC, two tower lights can clearly be seen, one mid-height and the other near the top. As the accident helicopter approaches, you can see the beam of the landing light begin to illuminate the tower. As the distance closes, the light beam walks up the tower and shrinks in diameter. At impact, the light beam is small and bright, giving the appearance that the accident helicopter struck the tower dead center.
Ok, so that precludes the ADS-B error. I still hold that the light we saw in the original black and white video is not the top light. With the new video, there’s at least one even lower showing. So it’s possible they were in a degraded state - some but not all lights working? But yeah, that means they hit about the middle or maybe slightly higher of the mast.Not much in the audio, but sounds like they were intentionally staying at 600 feet.
Pilotless helis/eVTOLs will not make these kind of mistakes.
But their programmers might...Pilotless helis/eVTOLs will not make these kind of mistakes.
Maybe. But they would be equally capable of other types of errors with the same consequences.Pilotless helis/eVTOLs will not make these kind of mistakes.
It sounds like you've done a thorough analysis and accurately predicted the error rates for every scenario.Maybe. But they would be equally capable of other types of errors with the same consequences.
Not at all. Have just seen and repaired a lot of aircraft systems that would have caused the same end result if a pilot had not been onboard to intervene. My money is still on the carbon unit up front.It sounds like you've done a thorough analysis and accurately predicted the error rates for every scenario.
Politics and software: you don’t want to know how the sausage is made.I've been in the computer field for 30 years. Software is slower and less reliable than it's ever been, and in terms of reliability I mean less deterministic and less well understood by any given person. It's already typically being written by teams of people working in an intentionally sped up pace, driven more by schedule than product specification. No other industry I know of except the entertainment industry works quite that way. And the latest fad is automating the code generation. Stuff like this makes the guy repeatedly pressing the reset circuit breaker button on the fuel pump seem cautious by comparison.
How much experience do you have with DAL-A software and DO-178? In my experience (on the DAL-A side) most generic 'software' people are not aware of the extent of validation and verification that goes into flight-critical software. That does not mean there are not unforseen problems and consequences, but it's far from the code free for all some would have you believe.I've been in the computer field for 30 years. Software is slower and less reliable than it's ever been, and in terms of reliability I mean less deterministic and less well understood by any given person. It's already typically being written by teams of people working in an intentionally sped up pace, driven more by schedule than product specification. No other industry I know of except the entertainment industry works quite that way. And the latest fad is automating the code generation. Stuff like this makes the guy repeatedly pressing the reset circuit breaker button on the fuel pump seem cautious by comparison.
But it's probably better to know how the sausage is made before yelling about problems with how it's made.Politics and software: you don’t want to know how the sausage is made.
My observation has been that the cert authority also has a say in the design assurance level assigned to a system. PM can make a case for a lower DAL, but if the e.g. FAA says no it's not going to go the PM's way. Same goes for every other flight-critical component of an airplane, software or not. Of course we can all think of cases where software flaws have caused serious problems, but most of us can also think of catastrophic design 'escapes' not involving software.Below DAL A, the yelling starts when engineers may want for example a minimum of DAL C for something but the PM says not today. At least that’s been my observation. And there’s always a need for good faith in the process, otherwise it does devolve into politics.
I wasn't talking about the FAA. Think green suit.My observation has been that the cert authority also has a say in the design assurance level assigned to a system. PM can make a case for a lower DAL, but if the e.g. FAA says no it's not going to go the PM's way. Same goes for every other flight-critical component of an airplane, software or not. Of course we can all think of cases where software flaws have caused serious problems, but most of us can also think of catastrophic design 'escapes' not involving software.
Nauga,
contingent
I've through it on the mil side as well, more often and more extensively than the civil side. There is certainly more willingness to accept risk but it's still not as simple as people with no flight-critical software experience seem to believe, and the process and issues are not limited to software. I've also seen firsthand the changes that had to be implemented in control laws and V&V processes to lower the equivalent of the DAL at the time because the green-suited cert authority was unwilling to accept the risk. Quite understandably, IMO. We can all cite corner cases but neither civilian nor military flight critical software development processes (or even general design and development processes, for that matter) are as trivial as much of the general computer-savvy public seems to believe.I wasn't talking about the FAA. Think green suit.
That's the ticket, right there. And do that for mission equipment also. So it all plays like a symphony, except for that one guy that randomly bangs the kettledrum for no apparent reason.Nauga,
and his code walkthrough
None at all. But I'm pretty familiar with how people are taught to code coming out of college and in internships, and I'm quite familiar with the typical success of bolt-on standards, specifically around compliance, for software development in general. I won't argue that standards and verification can make things more reliable....but "generic software", including applications used in health care, finance, front and back end business systems and government ARE being done faster and with less oversight and accountability than ever. So while it may be possible for aerospace to carve out a special flow and system that will keep things reliable, my bet is that the rest of the industry is going to lead them down to their level.How much experience do you have with DAL-A software and DO-178? In my experience (on the DAL-A side) most generic 'software' people are not aware of the extent of validation and verification that goes into flight-critical software. That does not mean there are not unforseen problems and consequences, but it's far from the code free for all some would have you believe.
Nauga,
pushing and pulling