Flight data recorder

[Richard McDonald Woods]

Some thoughts...

To support a PSX replay process, Broker will have to record a log of all PSX events and maybe occasional checkpoints to provide replay start points.

For Broker, it seems that translating a mass of high-frequency TCP messages, representing all changes that occur during a PSX flight, into a flow of DFD records for the flight data monitor (FDM) is also quite a challenge.

My current notional design for the FDM is for Broker to provide a stream of DFD records to an agreed format. This data set can then be the source for FDM and for controlling Broker's FDM playback to PSX from the PSX events log.

For FDM, the DFD dataset records would be accessed, using a direct access method, to determine the beginning and end times of each flight phase. FDM would then produce the required measurements for each flight phase. The pilot would be able to choose any measurements which are safety issues and request Broker to replay the flight from just before that point.

Outstanding questions

- With what frequency could we expect DFD records to be produced by Broker?
- Is this frequency sufficient to provide the granularity required for FDM?
- Are we expecting an unreasonable workload on Broker to record both the PSX events log and the DFD in real-time in addition to supporting VisualPSX?
- Deciding when a flight starts may be a problem (end of flight is simply an EOF condition). Assuming that FDM will monitor all pilot actions from preliminary cockpit preparation through to battery switch off at leaving the airplane, what DFD should be recorded if the pilot establishes external electrical power and is then called to go shopping by his/her partner?
- Are we biting off more than we can chew?

PS See http://www.tc.faa.gov/its/worldpac/techrpt/ar04-44.pdf

[Hardy Heinlin]

- With what frequency could we expect DFD records to be produced by Broker?

Aircraft attitude and position data: At 5 Hz.

For all other variables: A value is updated over the network only when it has changed.

- Is this frequency sufficient to provide the granularity required for FDM?

5 Hz should be enough for an attitude and position animator that uses interpolation.

For your data reader, I don't recommend to use the 32 Hz high speed channel, that's too fast. This channel runs in parallel and is not designed for Broker/Router, it's for direct feeding of scenery generators only, like VisualPSX etc.

- Deciding when a flight starts may be a problem

A value is updated over the network only when it has changed. Only the 5 Hz  attitude/position data run continuously. It could be stopped by pausing the sim.


Cheers,

|-|ardy

[Jeroen Hoppenbrouwers]

There still is an implicit design decision in all this: why translate the (delta) data stream from PSX to absolute fixed-value frames in the first place? Each frame can be reconstructed from the delta stream. Only when you absolutely must have all data available in each frame, you go for frames, as they force you to throw away 99% of the data you have in delta stream format.

For crash-reconstruction data recorders, I understand why a frame approach is useful. But for our purposes, it isn't really needed.

By the way I am currently programming a translator from two 512 word per second ARINC 429 input channels into 5 Hz framed output for a flying weather station, and the workload for all this is invisible on a normal PC, and no problem for a low-end embedded CPU.


Jeroen

[Richard McDonald Woods]

Is there any reason not to read the PSX feed directly, rather than the Broker feed?

[Jeroen Hoppenbrouwers]

The Router (not the Broker, that's PS1 technology) is just and only there to relieve PSX from multiple client load. It also assists in debugging and add-on development, but for production it is not at all required in terms of data format or functionality. For a client PSX or add-on, there is no difference between being connected to the PSX server or to a Router.

In fact, you can chain Routers in a hierarchy.

http://www.hoppie.nl/psxrouter/arch.html


Jeroen