Announcement
Collapse
No announcement yet.
We have analysed the raw data from the transponder of #4U9525 and found some more dat
Collapse
X
-
Is there any way to improve the raw data buffering on the FR24 boxes? Would it help to plug a usb memory stick in? If so what capacity and how should it be formatted? (FAT, FAT32, NTFS etc)
If this is not currently supported then could it be implemented in the next firmware update?
I am sure many who host the boxes would be happy to do this.
Ben.
Leave a comment:
-
Originally posted by Mike View PostWe normally never upload this data to FR24 as it would consume too much data traffic for hosts (and for us). But after MH370 we learned that the raw data could have a very big value afterwards, and since live uploading of the raw data is not an option, we store it in the FR24 receiver for as long as possible. Depending on coverage we can store last received data for about 4-10 hours. If something happens we can go back and download the data from a receiver, and this is what we did with the receivers near 4U9525 when we heard about the accident.
As the data cannot be easily identified it took us almost 2 days to make the analysis and find the autopilot data.
and on-request hold / release for analysis purposes should be implemented by all ADS-B monitoring device / software manufcturers. Hobbyist ADS-B monitoring
is a bit gray area in many countries. This kind of accident analysis support could help making hobbyist ADS-B monitoring activity more accepted to the authorities.
Some development ideas:
-support development of the receiver base (other than already supperted FR24/Radarcape) to provide GPS-timestamped data
-encourage local buffering of the full feed to the internal memory maximum of the receiver platform
-mechanism for FR24 to request a hold and dump of all stored data frames of a spesific HEX (this might be a type of request that would require an OK by the
receiver owner for the data to be delivered, the release request could contain a reasoning for the request)
Spesifically related to Radarcape..as the hardware base is very similar / identical to the FR24 receiver, this type of full feed buffering and HEX-based release request
should be quite easy to implement. Maybe something to consider together with FR24 and Radarcape?
I really would like to see crowdsourced ADS-B monitoring to be universally accepted from legislation point of view. Internet aviation enthusiast community has already proven to provide valuable data. There are also other areas where crowdsourced sensor networks could provide added value: weather monitoring and thunderstorm detection are good examples.
Leave a comment:
-
@Mike, if you are not too busy giving interviews to CNN could you maybe check the 4th/5th data subfield in the BDS40h message register? Like from any BDS40h message around 09:33. This would tell which vertical mode was engaged on the autopilot (V/S, EXPEDIATE, OPEN DESCENT,etc).
BDS40h
MCP MODE (A320):
bit-48 STATUS OF MCP MODE BITS
bit-49 MANAGED VERTICAL MODE
bit-50 ALT HOLD MODE
bit-51 APPROACH MODE
ALTITUDE SOURCE:
bit-54 STATUS OF ALT SOURCE BITS
bit-55
--- I --- = 2-bit value
bit-56
Leave a comment:
-
I extracted the course change and corresponding ALT data:
09:18:19Z.244 ROLL: 0ºR TTRACK: 66º TAS: 458kt 30000
09:21:11Z.791 ROLL: 0ºR TTRACK: 42º TAS: 446kt 32075
09:30:15Z.542 ROLL: 0ºL TTRACK: 41º TAS: 448kt 38000
09:30:20Z.539 ROLL: 0ºL TTRACK: 40º TAS: 450kt 38000
09:30:22Z.831 ROLL: 0ºL TTRACK: 39º TAS: 450kt 38000
09:30:25Z.545 ROLL: 0ºL TTRACK: 38º TAS: 450kt 38000
09:30:27Z.756 ROLL: 0ºL TTRACK: 37º TAS: 450kt 38000
09:30:32Z.682 ROLL: 0ºL TTRACK: 36º TAS: 450kt 38000
09:30:36Z.513 ROLL: 0ºL TTRACK: 34º TAS: 450kt 38000
09:30:40Z.295 ROLL: 0ºL TTRACK: 33º TAS: 452kt 38000
09:30:42Z.535 ROLL: 0ºL TTRACK: 32º TAS: 450kt 38000
09:30:47Z.461 ROLL: 0ºL TTRACK: 30º TAS: 450kt 38000
09:30:50Z.559 ROLL: 0ºL TTRACK: 29º TAS: 452kt 38000
09:30:55Z.570 ROLL: 0ºL TTRACK: 28º TAS: 450kt 38025
09:30:57Z.311 ROLL: 0ºL TTRACK: 27º TAS: 450kt 38025
09:30:59Z.248 ROLL: 0ºL TTRACK: 26º TAS: 450kt 38000
09:31:07Z.164 ROLL: 0ºL TTRACK: 25º TAS: 450kt 37950
09:34:24Z.063 ROLL: 0ºR TTRACK: 26º TAS: 446kt 28050
09:34:40Z.358 ROLL: 0ºL TTRACK: 25º TAS: 450kt 26875
09:36:15Z.159 ROLL: 0ºR TTRACK: 26º TAS: 458kt 20350
09:38:17Z.046 ROLL: 0ºL TTRACK: 26º TAS: 414kt 13700
If your a data wonk, this is interesting.
This is a summary of 247 ttrack records
Leave a comment:
-
How is it possible that a co pilot is authorized to change manual the altitude from 38000 ft to 13.000 ft to 96 ft leading to the middle of an alp in three seconds by his own? Why not authorized this strange pattern by head pilot or ATC is restricted?
Leave a comment:
-
09:30:17Z.905 ROLL: 0ºL TTRACK: 41º TAS: 450kt
The autopilot initiated a course change from 420to 250 30 seconds before ALT was manually changed.
New course of 250 was achieved as AC began descent.
09:38:17Z.046 ROLL: 0ºL TTRACK: 26º
last ttrack data transmit at 13700 ft.
Leave a comment:
-
thanks, Mike.
to you and your analysts. You all did a good but timeconsuming job
Leave a comment:
-
@Mike the altitude in the kml file for the placemarks seems incorrect. For example at the highest point it's listed as 3800 meters in stead of 38000 feet. So there seems to be a zero missing and it is in Meters in stead of Feet. The other placemarks seem to be affected as well.
Just wanted to let you know, thanks for all the data and effort, it's much appreciated!
Leave a comment:
-
I have attached .kml file with full ADS-B data of flight 4U9525
5d42675.kml
Alternative link https://dl.dropboxusercontent.com/u/5175572/5d42675.kml
and .txt file with ADS-B + ModeS data of flight 4U9525 with MACH, IAS, TAS, ROLL, VRATE
GWI18G_mode_s+adsb.txt
Alternative link https://dl.dropboxusercontent.com/u/...e_s%2Badsb.txt
Please note that we are only 99% sure that IAS data has been correctly decoded.
Leave a comment:
-
Originally posted by henningz View PostHe needed two seconds (actually three) to turn the button on the autopilot from 38000 ft to zero...
The MODE switch would be turned clockwise to 1000 (if it wasn't already selected), the ALT dial would be turned counter clockwise 2 times, landing on 13008ft during the first twist, then 100ft on the second. No doubt this is being replicated in a simulator somewhere.
Leave a comment:
-
Using "raw" data (*) taken from this site, I was able to reconstruct following 3d scene, which can be downloaded as a Google Earth KML file:
Looking closer, it looks like there's a discrepancy between expectdc impact site and actual impact site, which could lead to think to a final attempt to regain altitude:
But it can also depend on too coarse and approximate data. If exact altitude, longitude, latitude and time (with seconds) was available, I could reconstruct a much more precise scene.
(*) click on chart, write down altitude&speed, click on other point, write down,... and eventually grabbing data from HTML sources and manually converting them to suitable format...
Leave a comment:
Leave a comment: