Flight data recorder

[Richard McDonald Woods]

Will PSX contain an FDR? If not, how should I go about recording, say,100 variables per second from PSX in real-time?

[Hardy Heinlin]

Good evening,

PSX sends out data through a standard TCP/IP network. You would have to write a program in your preferred language that reads the data you want. The data are written in ASCII text format. There'll be a comprehensive documentation describing which data have which identifier etc.

Some data are sent out only when their values have changed, other data are sent continuously, e.g. position and attitude data are sent out at 5 Hz. There's also a high speed network bus, but that would fill your recorder with gigabytes in the long run. The high speed bus is mainly for external scenery generators.


Cheers,

|-|ardy

[Richard McDonald Woods]

Hi Hardy!
Great. I shall have to wait until the documentation is available.
My ideas are currently based on the CAA CAP 739: Flight Data Monitoring document. Perhaps to produce some of the measurements for a flight would be interesting.

[Hardy Heinlin]

CAA CAP 739 -- So, aside from recording the data, you also want to evaluate them and put together some "event codes" like, for example, on page 63 of this PDF?

http://www.caa.co.uk/application.aspx?catid=33&pagetype=65&appid=11&mode=detail&id=1002


|-|

[Richard McDonald Woods]

Yes, that was the intention. Perhaps to score the flight with explanations about unsafe situations.

I also have dreams of being able to produce something as in the graphic at www.swiss49.com/docs/s49%20FDM%20Booklet%20for%20Crew.pdf page 18.

But as I am no programmer, I would have to do a lot of learning to enable myself. Or perhaps do the design work, of which I am capable, and to find someone who could try to turn it into something workable.

I hope that I am not just dreaming.

[Hardy Heinlin]

For the visualisation of the flightdeck and instruments during the flight recorder "playback" one can again use PSX. Just inject the data back in, in the right timing and sequence. Arrange the PSX layout so that it looks like a flight recorder visualisation.


|-|

[Jeroen Hoppenbrouwers]

The flight data recorder for PS1 could be easily updated for PSX.

http://www.hoppie.nl/fdr/

Obviously the web page is somewhat lacking, but the software is finished.

As a nice side note: today I worked with exactly such a flight data stream coming off the 429 bus of an Embraer 135, and when I plotted the GPS position a few minutes after powerup, the following picture came out:



Familiar technology ... just applied to a slightly different technical environment!


Jeroen

[Richard McDonald Woods]

Well done again, Hoppie and Hardy!

It would therefore be best for the existing FDR to be updated to use PSX for both flight data recording and PSX playback. It would be great if the playback could be from a given time in the flight. Perhaps both the recording and playback  could be controlled from the PSX instructor panel?

This would leave me with the tasks of analysis of that flight data as per CAP 739 and maybe anything else I discover. I imagine that the analysis would give safety violations, with exact times, in a .pdf file to enable the pilot to move the playback to the appropriate point.

So, all I require is the layout of the PSX flight data record when it is decided.

[Jeroen Hoppenbrouwers]

The recorder likely will "just" save the complete PSX data stream with time stamps, exactly as PSX sent to what it thought was a slave PSX. So playback is trivial.

Jeroen

[Hardy Heinlin]

Aside from the timestamps, you would also have to save situation files every x seconds or minutes. These files would allow you to jump directly to a point in the middle of a flight. Without them, you would always have to start the playback from the beginning in order to calibrate the starting point of those variables which are sent only when they have changed (only some variables are sent continuously at 5 Hz)..


Cheers,

|-|ardy


P.S.: I have on my plan a "Film" feature, but I'm not sure if I'll get it done for PS version 10. There are some major design problems. One of them is the requirement that on the Instructor all situation related checkboxes, entry fields, sliders etc. have to be greyed out during playback. There are many! Then there is network management, network inhibits etc. Then frame rate management, i.e. the recording shouldn't have more FPS than the playback machine can play in real-time. The "Film" feature would use the high speed stream, too, that's the problem (one of many). -- I call it Film to distinguish it from "video". A video in the traditional sense has a small screen in low resolution and lots of compression artefacts, whereas a PSX Film is simply a macro without any graphical data, the resolution can be as high as that of the playback PSX.

[Richard McDonald Woods]

Or the FDR records would contain ALL of the variables required by the situation files so that each record could be used to restart the playback i.e. each record would be a copy of the previous with any changed variables overwritten. Agreed that this solution may reduce the frequency of record creation.

[Jeroen Hoppenbrouwers]

PSX does not put out all variables continuously, so the FDR would not be able to capture them if it was started too late.

Instead of the situation file approach, another alternative which I think the PS1 variant does is to spit out all known variables when playback starts, using an accumulation of everything known to the recorder up to the point of playback. Since the PS1 Broker already implements the only-if-changed approach, this startup process was already included.

It is very much alike syncing up a slave when it connects. Maybe I should just stuff the FDR into the Router... 90% of the code is already there.


Jeroen

[Richard McDonald Woods]

FDR in the Router sounds logical.

Will you be creating a 'full' record at each timeslice, with all changes to the respective fields applied? This would make use of the data the easiest for add-on developers, like me, who then do not have to individually construct an FDR record each time.

[Hardy Heinlin]

Instead of the situation file approach, another alternative which I think the PS1 variant does is to spit out all known variables when playback starts, using an accumulation of everything known to the recorder up to the point of playback.

In PS1 a video consistst of a *.VDS file (the start situation) and a *.VDR file (the stream of position data, and the records of mouse events).

That's the very problem. PS1 videos must be started from the beginning. Jumping is not possible.

In PSX it would be nearly the same as in PS1 -- plus additional situation files in certain intervals which allow jumping back and forth.

A PSX situation file is ca. 20 to 30 kB in size.


|-|


P.S.: Since the Router has a cache of all current data, the Router can, on request, send out all data anytime.

[Richard McDonald Woods]

A 30kB record, say each 5 secs, would create around 21.6 mB per hour, and 260mB during a 12 hr flight.

[Jeroen Hoppenbrouwers]

Hardy: yes, this was my idea -- to have the Router, or the dedicated FDR, use internal calculations and buffers to provide the "instant situation" capability. This works for PS1. I remember even including some positioning delay for the scenery generator, which gets a few full frames, then is allowed to slew into position before the real motion starts.

Richard: real aircraft flight data recorders are measured in 64, 128, 256, 512, 1024, 2048, 4096, or 8192 words per second. Each word is 32 bits, 4 bytes, so we are looking at "normal" data rates (up to 512 wps) of 512*4*60 = 123 Kb per minute, * 60 = 7 Mb per hour. This is what we regularly absorb into our flight data recorders at work. Anything more than this is currently considered "very high data rate" in the real aircraft. These rates are not stored for more than about an hour of flight.

As a side note, imagine an intercontinental aircraft doing a 12-hour leg, accumulating 84 Mb of data, and then having a one-hour stopover to push all this data out over a 3G link. A tough call, by any means. And then add that the operator does not want to pay roaming data rates and simply accumulates 168 Mb of data with, of course, the same one-hour stopover back home ... the fun of airlines    :mrgreen:

So your calculations are correct, but not in line with what real stuff currently does. They record much faster (10-50 frames per second) but by far not all the variables on an aircraft (thousands). The crash analysis recorders do only what is regulatory required. The quick access recorders like ours do more, but they have a data limit as well, so the non-interesting variables are left out. They basically do what operators need to fine-tune equipment and operations, and to predict maintenance actions ahead of component degradation or failure. This data crunching business is BIG, I tell you.

It also pays off big time once in a while. Recently one of our turboprop customers had a rough landing due to bad weather, which was reported by the pilots as potentially exceeding airframe limitations. Normally, this meant declaring the aircraft not airworthy, finding another one for the next leg, and sending engineers over to at least retrieve the flight recorder and have it read out on a shop bench. With quick access recorders, it can be done by a quick download to a PC or picking up an SD card, but still somebody has to go there and it takes at least an hour before the analysis can begin. In our case, as soon as the techs learned about the pilot's report (basically immediately after landing), they went to the data server. And lo and behold, the aircraft had already phoned home and all the data they needed was there, ready for analysis. The thing had not even shut down yet. Within 20 or so minutes, it was declared airworthy again, and flying an hour later. Which saved the company probably 100k. Good investment, a QAR  :mrgreen:


Jeroen

[Richard McDonald Woods]

Jeroen,  thanks for the real world FDR/QAR background. Most interesting.

As I see it, you will need far more variables in order to support flight replay than I will require for flight data analysis. This then requires a decision on whether the FDA function will share direct access to the FDR data or a specified subset of those variables.

To define a subset will require me to choose from the FDR record layout those variables required to produce the analysis.

Either way, I expect to have to wait for PSX to become more complete so that you can publish an FDR record layout. Am I correct in this?

In the meantime, I shall set up an Eclipse JDE and start learning how to write the Java language.

[Jeroen Hoppenbrouwers]

Something tells me that we'll end up building something that could feed into real-world FDRs and analysis packages...

[Richard McDonald Woods]

I understand but, at whose expense?

[Hardy Heinlin]

Richard, I see it as you do; a complete reproduction of a PSX flight or flight phase will require all data, whereas your CAA type of analysis just needs some.

If you really want to start learning Java, I think that's great, not only for the PSX stuff. You're obviously a creative man and you seek for challenges.


Cheers,

|-|ardy


P.S.: In the final PSX package there'll be a free sample addon written in Java. The code may be reused and extended or modified by the users. It will have the network connection functions and some read/write examples already implemented. Since it is in Java, it runs on Windows, Mac, Linux ...