Indonesian aircraft missing off Jakarta
Join Date: Jan 2008
Location: Dxb 30L
Posts: 53
Likes: 0
Received 0 Likes
on
0 Posts
"Hundreds of gigabytes"? per aircraft? I seriously doubt this, the cost of sending this amount of data over sat links would be prohibitive.
Hope it's not optional, either, as the option not installed in MH370 that made investigators rely on dataless pings to dig out locations.
Hope it's not optional, either, as the option not installed in MH370 that made investigators rely on dataless pings to dig out locations.
" ONS file server. The ONS file server is the hub of the 737 MAX onboard network. Housed in the electronics equipment bay, the ONS file server connects to a
large set of data-rich 737 systems, houses hundreds of gigabytes of mass data storage, sends maintenance data to flight deck displays, and hosts onboard and offboard data processing functions. Direct connection to the ONS file server via the airline’s maintenance device is provided by a flight deck Ethernet port or by optional connectivity systems. The ONS file server is available on the Next‑Generation 737"
Join Date: Sep 2018
Location: Laredo, TX
Posts: 133
Likes: 0
Received 0 Likes
on
0 Posts
From the MAX FCOM 9.20.8:
Speed Trim System
The Speed Trim System (STS) is a speed stability augmentation system designed to improve flight
characteristics during operations with a low gross weight, aft center of gravity and high thrust
when the autopilot is not engaged. The purpose of the STS is to return the airplane to a trimmed
speed by commanding the stabilizer in a direction opposite the speed change. The STS monitors
inputs of stabilizer position, thrust lever position, airspeed and vertical speed and then trims
the stabilizer using the autopilot stabilizer trim. As the airplane speed increases or decreases
from the trimmed speed, the stabilizer is commanded in the direction to return the airplane to the
trimmed speed. This increases control column forces to force the airplane to return to the trimmed
speed. As the airplane returns to the trimmed speed, the STS commanded stabilizer movement is
removed.
STS operates most frequently during takeoff, climb and go-around. Conditions for speed trim
operation are listed below:
• STS Mach gain is fully enabled between 100 KIAS and Mach 0.60 with a fadeout to zero by Mach 0.68
• 10 seconds after takeoff
• 5 seconds following release of trim switches
• Autopilot not engaged
The Speed Trim System (STS) is a speed stability augmentation system designed to improve flight
characteristics during operations with a low gross weight, aft center of gravity and high thrust
when the autopilot is not engaged. The purpose of the STS is to return the airplane to a trimmed
speed by commanding the stabilizer in a direction opposite the speed change. The STS monitors
inputs of stabilizer position, thrust lever position, airspeed and vertical speed and then trims
the stabilizer using the autopilot stabilizer trim. As the airplane speed increases or decreases
from the trimmed speed, the stabilizer is commanded in the direction to return the airplane to the
trimmed speed. This increases control column forces to force the airplane to return to the trimmed
speed. As the airplane returns to the trimmed speed, the STS commanded stabilizer movement is
removed.
STS operates most frequently during takeoff, climb and go-around. Conditions for speed trim
operation are listed below:
• STS Mach gain is fully enabled between 100 KIAS and Mach 0.60 with a fadeout to zero by Mach 0.68
• 10 seconds after takeoff
• 5 seconds following release of trim switches
• Autopilot not engaged
From Boeing AERO NEWS
" ONS file server. The ONS file server is the hub of the 737 MAX onboard network. Housed in the electronics equipment bay, the ONS file server connects to a
large set of data-rich 737 systems, houses hundreds of gigabytes of mass data storage, sends maintenance data to flight deck displays, and hosts onboard and offboard data processing functions. Direct connection to the ONS file server via the airline’s maintenance device is provided by a flight deck Ethernet port or by optional connectivity systems. The ONS file server is available on the Next‑Generation 737"
" ONS file server. The ONS file server is the hub of the 737 MAX onboard network. Housed in the electronics equipment bay, the ONS file server connects to a
large set of data-rich 737 systems, houses hundreds of gigabytes of mass data storage, sends maintenance data to flight deck displays, and hosts onboard and offboard data processing functions. Direct connection to the ONS file server via the airline’s maintenance device is provided by a flight deck Ethernet port or by optional connectivity systems. The ONS file server is available on the Next‑Generation 737"
Join Date: Jan 2008
Location: Dxb 30L
Posts: 53
Likes: 0
Received 0 Likes
on
0 Posts
Yes, I think we've now established that the suggestion in the original post (which didn't quote the source, but is presumably this: ABC News: Even as Lion Air jet's black box is found, some answers may be back in the United States) that the flight could have been sending loads of FDR-type data that would be helpful to investigators via satcom in real time is almost certainly a red herring.
Join Date: Jun 2001
Location: Rockytop, Tennessee, USA
Posts: 5,898
Likes: 0
Received 1 Like
on
1 Post
This picture of the chief of the national SAR agency holding the unit was taken by Muhammad Adimaja for Reuters. It looks to me like the non-volatile memory container and the acoustic pinger. Any clue whether it is the CVR or the FDR?
According to the Straits Times
https://www.straitstimes.com/asia/se...-boxes-in-java
And the Reuters report said
airsound
https://www.straitstimes.com/asia/se...-boxes-in-java
The one recovered on Thursday is the flight data recorder, Transportation Minister Budi Karya Sumadi said.
The device, identified as the flight data recorder,....
Last edited by airsound; 1st Nov 2018 at 15:38. Reason: adding Reiuters
Join Date: Aug 2008
Location: Dublin
Posts: 3
Likes: 0
Received 0 Likes
on
0 Posts
What even is MBps? Megabytes per second? Or do you mean Megabits per second - Mbps - the more universal measurement?
The result is 0.222222222 Megabits / second (or 0.0277777777 Megabytes / second if that's what you're into), many orders of magnitude different - less - to what you quote above.
Join Date: Jan 2008
Location: Dxb 30L
Posts: 53
Likes: 0
Received 0 Likes
on
0 Posts
Last edited by bobdxb; 1st Nov 2018 at 16:54. Reason: Brand name corrected
Join Date: Dec 2014
Location: Schiphol
Posts: 475
Likes: 0
Received 0 Likes
on
0 Posts
Some remarks about LOC.
Based on a dataset of over 1500 accident and incident cases for the 1960-2018 period (based on accident reports and complemented with validated public and other data) I would say:
- that the absolute number of cases with LOC as a factor has not changed much over the years. An average number is about 2.75 per year.
- relatively speaking, compared to the huge increase in traffic, this means that the probability of LOC as a factor has significantly decreased,
- that the absolute number of LOC fatalities increased from the 1960s onward, peaked in the 1990s, and then decreased.
- relatively speaking, compared to the huge increase in traffic, this means that the probability of fatalities has significantly decreased,
- that the percentage of LOC cases fatalities which are "all-fatal" decreased from the 1960s onward, found a bottom in the 1990s, and then increased again.
- so the probability today that you end up in a LOC situation has significantly decreased, but if you are in such a situation that the "all-fatal" probablity has increased.
You have to take statements like this as a rough indication, no more no less.
Accident reports over the years and between countries are not very precise in providing consistent comparable and detailed data.
Accident reports are not always publicly available. Recent cases have no report yet.
Another thing is cause. Aerospace accidents never have a single cause. And LOC is even more an outcome than a causal factor.
etcetera.
Based on a dataset of over 1500 accident and incident cases for the 1960-2018 period (based on accident reports and complemented with validated public and other data) I would say:
- that the absolute number of cases with LOC as a factor has not changed much over the years. An average number is about 2.75 per year.
- relatively speaking, compared to the huge increase in traffic, this means that the probability of LOC as a factor has significantly decreased,
- that the absolute number of LOC fatalities increased from the 1960s onward, peaked in the 1990s, and then decreased.
- relatively speaking, compared to the huge increase in traffic, this means that the probability of fatalities has significantly decreased,
- that the percentage of LOC cases fatalities which are "all-fatal" decreased from the 1960s onward, found a bottom in the 1990s, and then increased again.
- so the probability today that you end up in a LOC situation has significantly decreased, but if you are in such a situation that the "all-fatal" probablity has increased.
You have to take statements like this as a rough indication, no more no less.
Accident reports over the years and between countries are not very precise in providing consistent comparable and detailed data.
Accident reports are not always publicly available. Recent cases have no report yet.
Another thing is cause. Aerospace accidents never have a single cause. And LOC is even more an outcome than a causal factor.
etcetera.
Join Date: Sep 1999
Posts: 541
Likes: 0
Received 0 Likes
on
0 Posts
A lot to discuss and no real hard information.It can get confusing and counter-productive.We have the write up by commander of previous flight and the
ADSB data.
Its not confirmed that this write up is genuine but we do have Lionair's own admission of a tech problem on previous flight.We can reasonably take it
as being a genuine(if illegal) leak.What does it tell us?a)They had a "single side" only UAS event b)the Captains side(ASI ALT) was corrupted with bad data c)control was handed over to the FO and flight continued with good side data d)STS operated during the identification phase of the UAS...STS only operates when AP is NOT engaged.Therefore CAPT was PF and he was flying manually during the UAS discovery.
What can we reasonably infer from the write up?a)That the UAS was not detectable on the takeoff roll(otherwise they would have aborted).b)The ALT DISAGREE confirms disagreement between CAPT and FO altimeter following takeoff ie CAPT's altimeter stuck(or lagging) vs FO altimeter normal.Prime suspect static vent left side.The inference of (b) is supported by (a).Static vent blockage is not discoverable on takeoff roll.c)IAS DISAGREE not reported....CAPTs ASI would be underreading but they would have to climb/accelerate before discrepancy between the 2 ASIs triggers the IAS DISAGREE warning.Control is handed over to the FO before that trigger is activated.
UAS comes in all shapes and sizes.Total,partial,intermittent,insidious etc You can fly into icing in the cruise and lose all ASI data(ie zero...ram air blocked but drain holes unblocked)) with AP siren suddenly awakening you out of your slumber.You can be climbing through icing and get a steadily increasing ASI with an overspeed warning.If you pull back you can end up stalling.You can be descending through icing and get a steadily decreasing ASI followed by stick shaker.If you increase speed you can end up overspeeding,overstress the aircraft with loss of control.You can be in the cruise and ASI just freezes and be totally unaware that you have UAS(total pitot blockage ram air + drain holes) You can enter a hail storm,lose the radome and end up with UAS..And then there are the non-icing events....insects,covers left on etc.A whole myriad of possibilities..
Boeing gives you the UAS NNC.They have changed it recently in an attempt to cover the murky waters.They did this because the onset of UAS may go unnoticed and the automation may place the a/c into an unstable flight regime prior to identification of the need to run the NNC.The new checklist starts with the assumption that the a/c is in unstable flight.With flaps up you fly 4 degrees and set 75% N1,with flaps down you fly 10 degrees and set 80% N1.Its a compromise,a prescription to cover all possibilities.However,like all compromises,it isnt always the best corrective action.Its never wrong but isnt always the "best" thing to do.If a pitot static anomaly is detected after liftoff and it is total(both sides affected),you are already in a stable flight regime(takeoff thrust 15 degrees) and you know categorically that you have lost basic airspeed/altitude data and it isnt coming back(not icing but maintenance issue),then it is not only not the "best" thing to do but a "bad" thing to do.You dont want to go flying under these conditions.The air is your enemy now.
I think the Lionair undoubtedly had a UAS,it was either a repeat of the previous flights scenario but this time control was not handed over to the FO,or following maintenance work both static vents were now affected,they had an overspeed and lost control of the aircraft.It would not surprise me if it was done with the AP engaged right after takeoff.
ADSB data.
Airspeed unreliable and alt disagree shown after take off. STS was also running to the wrong direction, suspected because of speed difference. Identified that CAPT instrument was unreliable and handover control to FO. Continue NNC of Airspeed Unreliable and ALT disagree. Decide to continue flying to CGK at FL280, landed safely rwy 25L
as being a genuine(if illegal) leak.What does it tell us?a)They had a "single side" only UAS event b)the Captains side(ASI ALT) was corrupted with bad data c)control was handed over to the FO and flight continued with good side data d)STS operated during the identification phase of the UAS...STS only operates when AP is NOT engaged.Therefore CAPT was PF and he was flying manually during the UAS discovery.
What can we reasonably infer from the write up?a)That the UAS was not detectable on the takeoff roll(otherwise they would have aborted).b)The ALT DISAGREE confirms disagreement between CAPT and FO altimeter following takeoff ie CAPT's altimeter stuck(or lagging) vs FO altimeter normal.Prime suspect static vent left side.The inference of (b) is supported by (a).Static vent blockage is not discoverable on takeoff roll.c)IAS DISAGREE not reported....CAPTs ASI would be underreading but they would have to climb/accelerate before discrepancy between the 2 ASIs triggers the IAS DISAGREE warning.Control is handed over to the FO before that trigger is activated.
UAS comes in all shapes and sizes.Total,partial,intermittent,insidious etc You can fly into icing in the cruise and lose all ASI data(ie zero...ram air blocked but drain holes unblocked)) with AP siren suddenly awakening you out of your slumber.You can be climbing through icing and get a steadily increasing ASI with an overspeed warning.If you pull back you can end up stalling.You can be descending through icing and get a steadily decreasing ASI followed by stick shaker.If you increase speed you can end up overspeeding,overstress the aircraft with loss of control.You can be in the cruise and ASI just freezes and be totally unaware that you have UAS(total pitot blockage ram air + drain holes) You can enter a hail storm,lose the radome and end up with UAS..And then there are the non-icing events....insects,covers left on etc.A whole myriad of possibilities..
Boeing gives you the UAS NNC.They have changed it recently in an attempt to cover the murky waters.They did this because the onset of UAS may go unnoticed and the automation may place the a/c into an unstable flight regime prior to identification of the need to run the NNC.The new checklist starts with the assumption that the a/c is in unstable flight.With flaps up you fly 4 degrees and set 75% N1,with flaps down you fly 10 degrees and set 80% N1.Its a compromise,a prescription to cover all possibilities.However,like all compromises,it isnt always the best corrective action.Its never wrong but isnt always the "best" thing to do.If a pitot static anomaly is detected after liftoff and it is total(both sides affected),you are already in a stable flight regime(takeoff thrust 15 degrees) and you know categorically that you have lost basic airspeed/altitude data and it isnt coming back(not icing but maintenance issue),then it is not only not the "best" thing to do but a "bad" thing to do.You dont want to go flying under these conditions.The air is your enemy now.
I think the Lionair undoubtedly had a UAS,it was either a repeat of the previous flights scenario but this time control was not handed over to the FO,or following maintenance work both static vents were now affected,they had an overspeed and lost control of the aircraft.It would not surprise me if it was done with the AP engaged right after takeoff.
Last edited by Rananim; 1st Nov 2018 at 15:57.
A re-post of a comment on a different LOC incident: The confusion amongst the pilots in the 1996 crash of Birgenair Flight 601 was exacerbated by contradictory warnings (overspeed plus stick-shaker). Even if they had successfully recovered (using sensible pitch/thrust settings) they would have had to contend with the distraction of continued overspeed warnings. It's worth knowing which CBs to pull in the event of false overspeed or stick-shaker warnings so this distraction can be removed.
For the B757/767 the CBs are:
AURAL WARNING: B16 & H35
STICK SHAKER: C11 & J21
For the B757/767 the CBs are:
AURAL WARNING: B16 & H35
STICK SHAKER: C11 & J21
And, just to complicate matters, that L3 FA2100 FDR comes in two versions - a long and a short one - the latter being exactly the same overall dimensions as the CVR, although I think the enclosure at the opposite end to the pinger is larger on the CVR as it contains an extra audio compression PCB. But that's missing from the recovered recorder, so it could still be either.
I think the Lionair undoubtedly had a UAS, it was either a repeat of the previous flights scenario but this time control was not handed over to the FO, or following maintenance work both static vents were now affected,they had an overspeed and lost control of the aircraft.
Join Date: Jun 2001
Location: Rockytop, Tennessee, USA
Posts: 5,898
Likes: 0
Received 1 Like
on
1 Post
Here's a Reuters report about the earlier flight where a Pan was declared after which the plane proceeded to its destination of Jakarta.
https://www.usnews.com/news/world/ar...revious-flight
Exclusive: Pilot Radioed Alert on Doomed Indonesian Jet's Previous FlightBy Gayatri Suroyo and Agustinus Beo Da Costa
JAKARTA (Reuters) - The pilot of a Lion Air flight from Indonesia's Bali island on Sunday made a radio alert minutes after take-off due to technical problems, but they were overcome and he pushed on to Jakarta. The same jet crashed on another flight hours later, killing all 189 people on board.
Herson, chief of the airport authority for the Bali-Nusa Tenggara area, told Reuters that after the alert the pilot updated the control tower to say that the plane was flying normally and he would not return to the airport as requested.
"The captain himself was confident enough to fly to Jakarta from Denpasar," said Herson, who goes by one name, speaking by phone from Bali and referring to the resort island's airport.
The pilot of another plane that was approaching Bali just after the Lion Air jet had taken off said he was ordered to circle above the airport and listened in to a radio conversation between the Lion Air pilot and air traffic controllers.
"Because of the Pan-Pan call, we were told to hold off, circling the airport in the air," said the pilot, who declined to be named because he was not authorized to speak to the media.
"The Lion plane requested to return back to Bali five minutes after take-off, but then the pilot said the problem had been resolved and he was going to go ahead to Jakarta."
Pilots use 'Pan-Pan' calls to flag urgent situations. They are a step down from 'Mayday', which signals severe distress.
The Denpasar-Jakarta flight landed at the Indonesian capital's airport at 10:55 p.m. local time on Sunday.
The same Boeing 737 MAX jet took off at 6:20 a.m. the next morning, bound for Bangka island, off Sumatra, and plunged into the sea 13 minutes later. Just before the crash, the pilot had made a request to return to base.
A Lion Air spokesman declined to comment when asked about the alert on the earlier flight, citing the ongoing crash investigation.
The budget airline's CEO, Edward Sirait, said earlier this week that a technical problem had occurred on the Denpasar-Jakarta flight but it had been resolved "according to procedure".
Amid media speculation over the airworthiness of the aircraft, the transport minister suspended Lion Air's technical director and three other officers on Wednesday to facilitate the crash investigation.
The suspended technicians "issued the recommendations for that (final) flight", the ministry said in a press release. It did not say how many technicians had been suspended.
ERRATIC FLIGHT
During its earlier flight from Bali on Sunday, JT43, the aircraft flew erratically and its airspeed readings were unreliable, according to an accident investigator and a flight tracking website.
According to data from FlightRadar24, the jet displayed unusual variations in altitude and airspeed in the first several minutes of flight - including an 875-foot drop over 27 seconds when it would normally be ascending - before stabilizing and flying on to Jakarta.
However, the pilots kept the plane at a maximum altitude of 28,000 feet compared with 36,000 feet on the same route earlier in the week.
National Transport Safety Committee (NTSC) deputy chief Haryo Satmiko told reporters on Tuesday there were technical problems on the flight, including unreliable airspeed readings.
Divers on Thursday retrieved a flight data recorder from the plane that lay shattered on the muddy sea floor off the coast of Jakarta. The NTSC said it would examine the device to get a clearer picture of what happened on the flight from Bali on Sunday in addition to the flight that crashed on Monday.Herson, the airport authority chief in Bali, said the aircraft had encountered a "speed and altimeter" problem but the captain was confident that it was airworthy and pressed on.
"He requested to return to the airport for RTB (return to base) but ... they updated and flew to Jakarta. The pilot double-checked to ensure that they could fly," he said.
Two passengers from Sunday's flight posted on Instagram, reporting that they had been concerned about problems with the air conditioning system and cabin lighting before the plane left Bali nearly three hours late.
Another passenger on JT43 described, in a talkshow broadcast by Indonesia's TVOne, a turbulent flight during which the seatbelt signs were never turned off.
"When the plane took off, it climbed and then went down. It rose again, and then dropped again violently, shaking," said Diah Mardani. "Everyone in the plane shouted Allahu Akbar (God is Greatest), Subhanallah (Glory to God). We recited every prayer we knew."
Nov. 1, 2018, at 8:54 a.m.
JAKARTA (Reuters) - The pilot of a Lion Air flight from Indonesia's Bali island on Sunday made a radio alert minutes after take-off due to technical problems, but they were overcome and he pushed on to Jakarta. The same jet crashed on another flight hours later, killing all 189 people on board.
Herson, chief of the airport authority for the Bali-Nusa Tenggara area, told Reuters that after the alert the pilot updated the control tower to say that the plane was flying normally and he would not return to the airport as requested.
"The captain himself was confident enough to fly to Jakarta from Denpasar," said Herson, who goes by one name, speaking by phone from Bali and referring to the resort island's airport.
The pilot of another plane that was approaching Bali just after the Lion Air jet had taken off said he was ordered to circle above the airport and listened in to a radio conversation between the Lion Air pilot and air traffic controllers.
"Because of the Pan-Pan call, we were told to hold off, circling the airport in the air," said the pilot, who declined to be named because he was not authorized to speak to the media.
"The Lion plane requested to return back to Bali five minutes after take-off, but then the pilot said the problem had been resolved and he was going to go ahead to Jakarta."
Pilots use 'Pan-Pan' calls to flag urgent situations. They are a step down from 'Mayday', which signals severe distress.
The Denpasar-Jakarta flight landed at the Indonesian capital's airport at 10:55 p.m. local time on Sunday.
The same Boeing 737 MAX jet took off at 6:20 a.m. the next morning, bound for Bangka island, off Sumatra, and plunged into the sea 13 minutes later. Just before the crash, the pilot had made a request to return to base.
A Lion Air spokesman declined to comment when asked about the alert on the earlier flight, citing the ongoing crash investigation.
The budget airline's CEO, Edward Sirait, said earlier this week that a technical problem had occurred on the Denpasar-Jakarta flight but it had been resolved "according to procedure".
Amid media speculation over the airworthiness of the aircraft, the transport minister suspended Lion Air's technical director and three other officers on Wednesday to facilitate the crash investigation.
The suspended technicians "issued the recommendations for that (final) flight", the ministry said in a press release. It did not say how many technicians had been suspended.
ERRATIC FLIGHT
During its earlier flight from Bali on Sunday, JT43, the aircraft flew erratically and its airspeed readings were unreliable, according to an accident investigator and a flight tracking website.
According to data from FlightRadar24, the jet displayed unusual variations in altitude and airspeed in the first several minutes of flight - including an 875-foot drop over 27 seconds when it would normally be ascending - before stabilizing and flying on to Jakarta.
However, the pilots kept the plane at a maximum altitude of 28,000 feet compared with 36,000 feet on the same route earlier in the week.
National Transport Safety Committee (NTSC) deputy chief Haryo Satmiko told reporters on Tuesday there were technical problems on the flight, including unreliable airspeed readings.
Divers on Thursday retrieved a flight data recorder from the plane that lay shattered on the muddy sea floor off the coast of Jakarta. The NTSC said it would examine the device to get a clearer picture of what happened on the flight from Bali on Sunday in addition to the flight that crashed on Monday.Herson, the airport authority chief in Bali, said the aircraft had encountered a "speed and altimeter" problem but the captain was confident that it was airworthy and pressed on.
"He requested to return to the airport for RTB (return to base) but ... they updated and flew to Jakarta. The pilot double-checked to ensure that they could fly," he said.
Two passengers from Sunday's flight posted on Instagram, reporting that they had been concerned about problems with the air conditioning system and cabin lighting before the plane left Bali nearly three hours late.
Another passenger on JT43 described, in a talkshow broadcast by Indonesia's TVOne, a turbulent flight during which the seatbelt signs were never turned off.
"When the plane took off, it climbed and then went down. It rose again, and then dropped again violently, shaking," said Diah Mardani. "Everyone in the plane shouted Allahu Akbar (God is Greatest), Subhanallah (Glory to God). We recited every prayer we knew."
https://www.usnews.com/news/world/ar...revious-flight
Join Date: Jan 2008
Location: Dxb 30L
Posts: 53
Likes: 0
Received 0 Likes
on
0 Posts
A lot to discuss and no real hard information.It can get confusing and counter-productive.We have the write up by commander of previous flight and the
ADSB data.
UAS comes in all shapes and sizes.Total,partial,intermittent,insidious etc You can fly into icing in the cruise and lose all ASI data(ie zero...ram air blocked but drain holes unblocked)) with AP siren suddenly awakening you out of your slumber.You can be climbing through icing and get a steadily increasing ASI with an overspeed warning.If you pull back you can end up stalling.You can be descending through icing and get a steadily decreasing ASI followed by stick shaker.If you increase speed you can end up overspeeding,overstress the aircraft with loss of control.You can be in the cruise and ASI just freezes and be totally unaware that you have UAS(total pitot blockage ram air + drain holes) You can enter a hail storm,lose the radome and end up with UAS..And then there are the non-icing events....insects,covers left on etc.A whole myriad of possibilities..
I think the Lionair undoubtedly had a UAS,it was either a repeat of the previous flights scenario but this time control was not handed over to the FO,or following maintenance work both static vents were now affected,they had an overspeed and lost control of the aircraft.It would not surprise me if it was done with the AP engaged right after takeoff.
ADSB data.
UAS comes in all shapes and sizes.Total,partial,intermittent,insidious etc You can fly into icing in the cruise and lose all ASI data(ie zero...ram air blocked but drain holes unblocked)) with AP siren suddenly awakening you out of your slumber.You can be climbing through icing and get a steadily increasing ASI with an overspeed warning.If you pull back you can end up stalling.You can be descending through icing and get a steadily decreasing ASI followed by stick shaker.If you increase speed you can end up overspeeding,overstress the aircraft with loss of control.You can be in the cruise and ASI just freezes and be totally unaware that you have UAS(total pitot blockage ram air + drain holes) You can enter a hail storm,lose the radome and end up with UAS..And then there are the non-icing events....insects,covers left on etc.A whole myriad of possibilities..
I think the Lionair undoubtedly had a UAS,it was either a repeat of the previous flights scenario but this time control was not handed over to the FO,or following maintenance work both static vents were now affected,they had an overspeed and lost control of the aircraft.It would not surprise me if it was done with the AP engaged right after takeoff.
However looking at the FR24 info (if correct), they struggled with climb for 13 min or so to end up stalling the plane?? I doubt and if I am allowed to suggest to the authorities, to start looking for tail section of that plane for clues why it dropped from the sky so quick...