Today I am planning the code for the SEFNA HSI integration. As I described in my previous posting there are a three programs that will make up the HSI integration, they are: a) The Avionics Plugin in X-Code (TAP), b) the ARINC 429 Subsystem with UDP and c) the HSI device driver. Here is a more detailed description each oft he elements:
1. The Avionics Plugin (TAP)
The TAP plugin, as describe above, is meant to be very light weight on the simulator and should show a minimal impact on the frame rate produced by the simulator software. The code, in essence, extracts data and stores it away in a shared memory segment, upon update, the code also pulls a shared semaphore to indicate to the downstream process that the shared memory segment has been updated and processing is required. X-Plane has a really neat plugin facility that allows for dynamic loading and un-loading of the plugin.
Getting the data out of the simulator frequently and quickly will be essential to creating a smooth presentation of the data on the physical device. Therefore, I plan to offload the data from the flight simulator at a rate of 20 times per second or an update refresh time of 50ms. Of course this will not result in a 50ms refresh cycle all the way on the hardware device, since there are two more downstream programs and network latency to be considered. (More on computing, or pre-computing, the latency in my blog post tomorrow)
2. ARINC 429 Subsystem with UDP
The ARINC 429 Subsystem runs on the same system together with the core flight simulator software. The subsystem attaches itself to the same memory segment as TAP and waits for data from TAP. The X-Plane and Microsoft Flight Simulator FSX data is not in the correct format for ARINC 429 words. For example, angular data (such as heading) is described as a "float" number by X-Plane, however, the ARINC standard describes angular data in twos complement fractional binary notation (BNR). Once the data has been converted to the correct format it is made available on the Ethernet network via a UDP data stream. Clients, such as the HSI Device driver described below, will be able to connect to a specific UDP socket and receive the necessary data already in a format to be handed of to the local ARINC 429 hardware adapter.
The ARINC 429 conversion happens as soon as the TAP application raises the shared semaphore. So, at best new data is loaded into the shared memory segment every 50ms and has to be processed and put on the Ethernet in less than 50ms in order to be ready for the next data element to be worked on.
3. HSI Device Driver
The HSI device driver knows how to operate the specific device. So, to be exact, this is really the SFENA HSI device driver. Receiving words from the ARINC 429 Subsystem with UDP on the system that runs the flight simulator, the HSI device driver schedules the necessary ARINC 429 words on the 429 capable hardware and also sets digital I/O lines on the DI/O hardware.
The HSI drivers response time is really driven by a number of variables: a) the time it takes for the device driver to receive and assemble the UDP packets into a complete dataset, b) the time to schedule and/or update the ARINC 429 word on the hardware adapter and c) the time it takes for the driver to set the necessary digital I/O channels. Here, again, it will be critical to hold latency down to a minimum.
1. The Avionics Plugin (TAP)
 |
| Simplified TAP Flowchart |
The TAP plugin, as describe above, is meant to be very light weight on the simulator and should show a minimal impact on the frame rate produced by the simulator software. The code, in essence, extracts data and stores it away in a shared memory segment, upon update, the code also pulls a shared semaphore to indicate to the downstream process that the shared memory segment has been updated and processing is required. X-Plane has a really neat plugin facility that allows for dynamic loading and un-loading of the plugin.
Getting the data out of the simulator frequently and quickly will be essential to creating a smooth presentation of the data on the physical device. Therefore, I plan to offload the data from the flight simulator at a rate of 20 times per second or an update refresh time of 50ms. Of course this will not result in a 50ms refresh cycle all the way on the hardware device, since there are two more downstream programs and network latency to be considered. (More on computing, or pre-computing, the latency in my blog post tomorrow)
2. ARINC 429 Subsystem with UDP
 |
| Simplified ARINC 429 with UDP Flowchart |
The ARINC 429 Subsystem runs on the same system together with the core flight simulator software. The subsystem attaches itself to the same memory segment as TAP and waits for data from TAP. The X-Plane and Microsoft Flight Simulator FSX data is not in the correct format for ARINC 429 words. For example, angular data (such as heading) is described as a "float" number by X-Plane, however, the ARINC standard describes angular data in twos complement fractional binary notation (BNR). Once the data has been converted to the correct format it is made available on the Ethernet network via a UDP data stream. Clients, such as the HSI Device driver described below, will be able to connect to a specific UDP socket and receive the necessary data already in a format to be handed of to the local ARINC 429 hardware adapter.
The ARINC 429 conversion happens as soon as the TAP application raises the shared semaphore. So, at best new data is loaded into the shared memory segment every 50ms and has to be processed and put on the Ethernet in less than 50ms in order to be ready for the next data element to be worked on.
3. HSI Device Driver
 |
| Simplified HSI Driver Flowchart |
The HSI drivers response time is really driven by a number of variables: a) the time it takes for the device driver to receive and assemble the UDP packets into a complete dataset, b) the time to schedule and/or update the ARINC 429 word on the hardware adapter and c) the time it takes for the driver to set the necessary digital I/O channels. Here, again, it will be critical to hold latency down to a minimum.
No comments:
Post a Comment