L-1011 Trainer Installation: COM Radio Power-Up

L-1011 COM Radio Power-Up

After almost a month away from the L-1011, due to work constraints and other museum projects, it is finally time to get back into it. Today we powered up the first few elements of the aft electronics panel on located just aft of the throttle quadrant. To be exact, we powered up the 3 VHF/HF COM radio combinations.

L-1011 COM Radio Without Backlight

The radio faces operate of 3 difference 24VDC sources. The VHF1 radio receives power from the BATTERY bus, the VHF 2 radio uses the GROUND SERVICE bus and the VHF3 radio receives power from the NO.2 RADIO BUS. I have extensively blogged about these Gables Engineering devices before and you can find more info on them when you search for Gables Radio Heads here on the blog.

Below is an image of the radio face under low light conditions with back plate and display illumination.

L-1011 COM Radio With Backlight

These radio faces are ARINC 429 devices and will be controlled by ARINC 429 interface. 

Avionics Bending: Collins DLC-800 Interactive Display Unit (IDU)

Collins DLC-800 IDU

Powered the Collins DLC-800 up today. Thanks to Edo for helping me find the pinout for the Interactive Display Unit! The L-1011 has one of these installed on the aft electronics console (center pedestal) and is used to interact with the SatCom system. The display uses the ARINC 429 protocol for data exchange.

Collins DLC-800 IDU

Of course, all of the display logic will need to be programmed. I might also be able to to design a few pages that will allow general control of the flight simulator. This unit will replace the paper-mockup of the IDU in the image below:

L-1011 Trainer - IDU

Below is the general device pinout:

A ... 115V AC 400Hz (H)
B ... 115V AC 400Hz (C)
C ... Chassis Ground
T ... IDU Data Out (ARINC A)
U ... IDU Data Out (ARINC B)
H ... IDU Data In (ARINC A)
J ... IDU Data In (ARINC B)

Avionics Bending: Inertial Navigation System (INS) - Part 7

The simulation of the Litton INS system would not be complete without the simulation of the INS alignment. The Litton LTN-72 uses ultra precise gyroscopes with ring-lasers that need to be aligned with a known position prior to aircraft movement. The status of this alignment process is indicated by an "ALIGN" indication on the status page of the LTN-72RL CDU. The image above shows the the Mode Control Unit (MCU) that is typically mounted on the overhead panel of the aircraft. It is put there so it is out of the way because it really only needs to be touched during alignment prior to aircraft movement. 

The INU starts the process once the switch is lifted out of a locked Standby (STBY) position and moved to the Alignment (ALIGN) position. In the image below you can see that the process starts with a status of 90 and counts down to a status of 2. The INU also estimates the time for alignment to be 14.6 minutes. This value also counts down as we work towards status 2. For the simulation it is important that the simulator does not report aircraft movement or the alignment will not complete or will be wrong. 

Once the INU reaches Status 2, the last alignment status, the green READY NAV light comes and indicates that the INU can now be put into navigation mode. Navigation mode should not be entered until we are ready to move the aircraft. 

Once the INU is in navigation mode (see image below) the timer starts counting up to give us an indication for how long the INU has been running. For a precision INU, such as the LTN-72, i think the average error is 2NM over a 4 hour period. 

Below is the display sequence as published by Litton in the LTN-72 Pilots Operating handbook.

Avionics Bending: Inertial Navigation System (INS) - Part 5

Litton LTN-72RL Instrument Data

Worked on the implementation of the Instrument Data page. The instrument data page shows the INS data that is sent from the INS to the flight displays. There are still a bunch of challenges with the display refresh method ... i am thinking about using line blanking which is available to the CDU via a specific data label.

Litton LTN-72RL Data Field Examples

The instrument data page can show heading and track data as Magnetic or True. All speed data is shown in Knots. Here is the data page from the Litton manual showing the flow of ANS data to the HSI as well as the layout of the first 5 lines of the Instrument Data page:

Litton ANS Data and the HSI (from Litton LTN-72 Pilot Reference)

Litton LTN-72 Instrument Data Page (from Litton LTN-72 Pilot Reference)

Below is a short video showing the Instrument Data page in action:

Avionics Bending: Inertial Navigation System (INS) - Part 4

First Litton LTN-72RL CDU  Integration with X-Plane 

So far all of the data you have seen on the Litton LTN-72RL CDU was test data. Today I finally got around to integrate the Litton CDU with X-Plane. For this first setup i chose the data that is displayed on the POSITION DATA page of the CDU; this data is Latitude, Longitude and time in GMT (or Zulu).

Here are the X-Plane data refs that I feed to the CDU via the ARINC 429 interface using ARINC 575 data words:

gLongitude = XPLMFindDataRef("sim/flightmodel/position/longitude");

gLatitude = XPLMFindDataRef("sim/flightmodel/position/latitude");

gZuluHR = XPLMFindDataRef("sim/cockpit2/clock_timer/zulu_time_hours");

gZuluMIN = XPLMFindDataRef("sim/cockpit2/clock_timer/zulu_time_minutes");

gZuluSEC = XPLMFindDataRef("sim/cockpit2/clock_timer/zulu_time_seconds");

While X-Plane does not directly talk to the CDU (it talks to a CDU device driver that does the ARINC formatting and data transfer via UDP) I still chose to implement the data extraction out of X-Plane following the ARINC 429 label standard. The labels are 0310, 0311 and 0150. Below is the code snipped from the X-Plane plugin that builds the extract data:

    // Label 310 - Present Position Latitude

    sbuf.label = 0310;

    sbuf.value = XPLMGetDatad(gLatitude);

    msgsnd( msqidOut, &sbuf, 9,0);

    

    // Label 311 - Present Position Longitude

    sbuf.label = 0311;

    sbuf.value = XPLMGetDatad(gLongitude);

    msgsnd( msqidOut, &sbuf, 9, 0);

    

    // Label 150 - UTC

    sbuf.label = 0150;

    sbuf.value = XPLMGetDatai(gZuluHR)*10000 + XPLMGetDatai(gZuluMIN)*100 + XPLMGetDatai(gZuluSEC);

    msgsnd( msqidOut, &sbuf, 9, 0);    

Lets put all this in motion. Watch the short video below to see the LTN-72RL CDU display the LAT, LNG and GMT data from X-Plane in real time via the ARINC 429/575 data stream:

ARINC 429/575 Interface Development - Kickstarter

Commercial ARINC 429 interfaces tend to be be very expensive, therefore, myself and my team mates Javier and Himar in Spain are developing an ARINC 429 interface (it will also do ARINC 575 words) for the consumer market as a Kickstarter project. Our proposal is to develop a low-cost way of connecting ARINC 429 devices such as the ones you saw in many of my postings throughout this year. We are lovingly calling it the "ARINC42911" interface and it connects to x-plane and FSX via Ethernet. Please visit our project link on Kickstarter and support us! The site has a short video that shows the features of the interface and how it will enable you to use real world avionics in your home simulator setup.

http://www.kickstarter.com/projects/1753938984/flight-simulator-interface-to-real-avionics-instru

Avionics Bending: Inertial Navigation System (INS) - Part 1

Area navigation on the L-1011 was accomplished by the use of an Inertial Navigation System. Some L-1011s also used the now dismantled OMEGA system for area navigation. OMEGA was more or less the first global position indication system that used a network of terrestrial antennas to create signals that could be triangulated into a position with roughly 8 NM accuracy. OMEGA was replaced by the public version of GPS around 1996.

Inertial Navigation Systems (INS) are still very much in use today. I will not go too much into detail on how INS technology works, but trust me, it is super cool. Read about it on Wikipedia by following the link. Present day Inertial Reference Units (IRUs) use lasers and are ultra precise. One of the main manufactures of INS and OMEGA systems was Litton Aero Products which got acquired by Northrop Grumman in 2001. 

The image below, taken from airliners.net, shows three Litton CDUs installed in the RAF L-1011 tanker. 

from. airliners.net (C) Duncan Monk

Over the next few weeks I will be creating a simulation of the Litton LTN-72RL INS. The LTN-72RL CDU basically acts as a terminal for the INS unit and in a triple system installation, as in the image above, all 3 INS units can be synchronized with each other. Here is the test setup on the workbench:

Litton LTN-72RL CDU and INS MODE SELECTOR on DZUS Rails

Litton LTN-72RL CDU and INS MODE SELECTOR on DZUS Rails

Litton LTN-72RL CDU and INS MODE SELECTOR on DZUS Rails

Litton LTN-72RL CDU and INS MODE SELECTOR on DZUS Rails

For this series of avionics bending I will be using the ARINC 575 protocol format. ARINC 575 is electrically identical to ARINC 429 however the general word format is different. ARINC 575, just like ARINC 429, uses an 8bit label and a 24bit data filed. However, unlike ARINC 429 the 575 format does not compute parity, does not have a SID or a defined SSM filed. The Litton CDU uses ARINC 575 words for data between the CDU and the INS unit in both directions. In the next posting we will take a look at the general system architecture and how I will go about creating and INS system and then integrating it with x-plane. 

Avionics Bending: VHF/HF COM Radio Integration with X-Plane (Part 9)

Gables Radio Controller, Audio Panel and Lexicon Multi Channel Audio Interface

Up until now all the audio you heard on the previous blog postings had been live streaming ATC traffic from the Internet. While that is very cool, it is not really useful in the simulator. In the sim we want to be talking to real air traffic controllers. The good thing is that there are several large virtual flight traffic controller communities out there and VATSIM is one of them. Vatsim is a very active community, especially here around Atlanta, and you can connect to it from many different flight simulators. For this blog posting I use X-Plane as the simulator and the XSquawkbox plugin to connect to VATSIM. The video below shows a short demonstration of the end-to-end implementation of the actual flight hardware made by Gables using ARINC 429, the Laminar Research X-Plane simulator and XSquawkbox:

Avionics Bending: VHF/HF COM Radio Integration with X-Plane (Part 6)

The Gables G6984 multi function radio head transmits 3 different ARINC 429 label. The labels are:

• Label 030 - VHF Frequency
• Label 205 - HF Frequency
• Label 207 - Additional Software information

For the flight simulator integration, only Label 030 and 205 are of interest to me right now. There are three (3) VHF frequencies and two (2) HF frequencies on the radio. Here are the details on the labels:

Label 205 - HF Word - From ARINC 429 Specification

Label 030 - VHF Word - From ARINC 429 Specification

All three VHF and both HF frequencies that can be set on the radio head are transmitted on the ARINC 429 bus with the same label. Each radio is identified with a unique SDI in the ARINC 429 word. The SDI is a 2 bit field.

VHF SDIs

01 -- VHF Radio 1
10 -- VHF Radio 2
11 -- VHF Radio 3

HF SDIs

01 -- HF Radio 1
10 -- HF Radio 2

Below is a short video that shows the radio head transmitting ARINC 429 data to a test program. Currently the ARINC data is read by a debug code and output to the screen. Over the next two days I will connect the Radio head data to the x-plane flight simulator.

Avionics Bending: VHF/HF COM Radio Integration with X-Plane (Part 3)

Now that I have decided on a basic architecture for the audio integration it is time to do a power up test of both the Gables radio head as well as the audio selector panel. Both components take 24-28VDC power input. I am driving them with 24VDC and that works just fine.

Gables Radio Head and Audio Selector Powered

At this point the radio head is powered but not yet connected to an ARINC 429 receiver or transmitter. The audio panel is powered and the built in amplifier and "Voice Only" selector are working. I also cabled a temporary L-1011 Headphone and Hand-Mike break-out panel ... this way I am able to connect the David Clark headset for testing. 

Original L-1011 Hand-Mike and Headset Connector Panel

Below is a short video that show the setup in action. I connected a scanner radio listening to Atlanta Center to the Gables Audio Selector's VHF-1 input. The audio is not yet coming from the simulator. 

Avionics Bending: VHF/HF COM Radio Integration with X-Plane (Part 1)

Now that we have at least one primary flight instrument, the HSI, under our belt (see the previous 15 postings) I will now move on to something very interesting, which is radio integration into X-Plane. Here is the stack that I will be working with for the next few weeks:

Gables Multi Function Radio Head and Gables Audio Selector Panel

The two instruments in the picture above are a GABLES G6984 radio head and a GABLES G2930 audio selector panel. The G6984 uses the ARINC 429 protocol for radio data and is a perfect next step for the ARINC 429 work I have been doing lately. Unlike the the HSI, which only required sending ARINC 429 data to the device, the G6984 will require bi-directional traffic; radio frequencies from the radio and FMS data to the radio head.

In the L-1011 cockpit there are three identical audio selector and radio head combinations; one for the Pilot, one for the First Officer and One for the Second Officer. For the test setup I will also use a Hand Mike and a David Clark Headset (rather have a Telex, but I don't have access to one). Below is a picture of the input and output:

Gables VHF COM, Hand Mike and David Clark Headset

The L-1011 cockpit has two overhead speakers that can be used for monitoring audio without the need for a headset. For the test setup I will only use one of the two speakers. The speaker is powered and has an amplifier built in.

Original L-1011 Cockpit Overhead Speaker

Tomorrow, we will look at t detail analysis of the audio signals needed for a realistic integration of X-Plane and a simulated ATC system.

Avionics Bending: Digital to Synchro Conversion

Perhaps one of the bigger challenges in using older avionics is that most of them are deeply rooted in analog technology. More precisely, many avionics instruments form the 70s and 80s extensively use synchros and resolvers. Here is a picture of what a typical set of synchros in an instrument from the early 70s looks like:

Synchros are actually pretty old technology but are super resilient to noise and other external factors. They are still pretty common on just about all aircraft today, however, digital avionics have pretty much pushed them out of the cockpit. However, for the L-1011 sim project I will need a lot of synchro input to drive the avionics with. The good thing is that there are quite a lot of digital to synchro converters out in the surplus market that can be used for testing. The ultimate goal, of course, is to build some basic converters.

Below is a short video of my reference Digital to Syncrho converter. It's made by Shadin and actually designed to drive DME indicators ... however, it can be bent to control just about any synchro. It takes ARINC 429 data packets on one side and outputs an X, Y, Z synchro signal on the other side. What you see in the video is Label 251 data from 0 to 360".  The really tall wave (enlarged by a factor of 2x) is the reference wave, I use it to trigger the scope with. The two small waves show the phase shift on the X and Y phase:

L-1011 Avionics Bending: SFENA HSI and ARINC 429 - Part 15 (Final)

In this last video for the ARINC 429 integration of the SFENA HSI with Laminar Research X-Plane I get a chance to demonstrate the dual HSI setup in flight. The software now allows for the Captain and the First Officer to select different display data as well as different (simulated) instrument sources. The video below concludes the deep dive into the HSI and next we will be looking into integrating the L-1011 Tank Panel and Altimeter.

The video today shows a short demonstration flight out of Seattle-Tacoma International airport using x-plane 10. The ARINC 429 Labels integrated for this video are:

Label 320, 012, 101, 162, 222, 100, 

      314, 114, 116, 117, 001 and 270

L-1011 Avionics Bending: SFENA HSI and ARINC 429 - Part 14

SFENA HSI - Dual Setup - ARINC 429

Now that one of the HSIs is working fine I am looking into integrating both the Captain's HSI as well as the First Officer's HSI with the Flight simulator. The cool thing is that because of the ARINC 429 protocol we really only need a total of 3 channels to simulate the 12 channels that instrument required when it was deployed on the actual aircraft.

Below is a short video the shows both HSIs receiving the same ARINC 429 test data. The data labels sent to the instruments for the test are:

• Label 320 .. Magnetic Heading as a full 360º circle
• Label 100 .. Selected Radial as a full 360º rotation
• Label 222 .. Omnibearing from a VOR in a full 360º circle

During the roll of the Radial and the Omnibearing the TO/FROM pointers are changing directions as the simulated VOR moves from the front to the back of the simulated aircraft.

L-1011 Avionics Bending: SFENA HSI and ARINC 429 - Part 13

The next stop on the ARINC 429 label integration between x-plane and the SFENA HSI is ARINC 429 Label 162 for the Automatic Direction Finder (ADF). The ADF is a relatively basic but very powerful instrument. What it does, in essence, is that it points to a Non-Direction Beacon (NDB). It does so, relative to the nose of the aircraft. Well, you know how an ADF and NDB works .. i don't need to go into too much detail here. From an integration perspective, it is important that the HSI shows the bearing to the NDB correct with respect to the aircraft nose ... regardless of the actual magnetic or true heading of the aircraft.

The video below shows the integration of ARINC Label 162 which is encoded as a BNR and uses the same 32bit word encoding I showed you in my blog posting a few days ago that explained BNR as a data payload in the ARINC 429 word.

NDB navigation is fun but can be a bit tricky. I promise that once the simulator is all put together we will fly some non precision approaches using an NDB! By the way, the airport code for San Francisco International is of course KSFO not KFSO as i wrongly stated in the video :)

Avionics Bending: X-Plane Float to BCD ARINC 429 Label Conversion Example

Two postings ago I showed you how I convert the floating point numbers that I receive from the x-plane SDK into ARINC 429 compatible BNRs. Today I will show you with and example how I convert the numbers into Binary Coded Decimals (BCD).

For this blog posting I will used the Distance-To-Go in Miles indicator that I have on the SFENA HSI that I have been working on for the last two weeks. Let's say we are traveling from the Seattle-Tacoma International Airport to the San Francisco International Airport. The distance with the aircraft still on the ground in Seattle is about 590.5 NM.

A BCD in ARINC 429 can encode 5 digits, and here is the format description for a generic BCD label:

BCD Word Format (No Discretes), ARINC Specification 429 Part1, p. 78

The label used for the Distance-To-Go is ARINC 429 Label 001, and, as you have probably seen in some of my previous postings, the HSI has one decimal. So the distance of 590.5 can be encoded with the 5 BCDs available. As a matter of fact, the SFENA HSI has no way of displaying a distance-to-go further than 999.9 NM. Here is how BCD encoding works:

from: Wikipedia, Binary-coded decimal

So, let's encode the BCD characters for our example of 590.5 NM.

BCD Character 1: 0000   (this is the leading zero)
BCD Character 2: 0101   5
BCD Character 3: 1001   9
BCD Character 4: 0000   0
BCD Character 5: 0101   5

When we place the BCDs into the 32bit ARINC 429 word they look as follows:

P   SM   Data                  SD   Label
0 | 00 | 0000101100100000101 | 00 | 00000001

The total number of bits set in the example above is odd (7) ... so, no parity bit for odd-parity is required. The ARINC 429 word transmitted for distance-to-go label 001 is therefore 0x01641401. What is interesting in an ARINC 429 general format BCD word is that that the BCD on the MSB side of the data payload is only 3 bit wide ... hence the largest number it can encode is 7 ... therefore, for a distance-to-go instrument that can show 4 digits on the left side of the decimal point the further distance to go would be 7999.9 NM (assuming at least one decimal).

Below is a code snipped that shows Float to BCD encoding for the ARINC 429 to UDP conversion module:

1:  /*  
2:   * Convert an Integer to ARINC 429 BCD format with 4 digits output. If a decimal  
3:   * number are to be displayed in BCD encoding, the input number has to be  
4:   * multiplied by 10 to encode the digits to the right of the decimal point. This  
5:   * function performs full 4 bit BCD encoding and  will not work for certain  
6:   * ARINC 429 words such as the BCD encoding for the ATC Transponer code.   
7:   *  
8:   * numberDigtis - number of BCDs to the left of the decimal  
9:   * numberDecimal - number of BCDs to the right of the decimal  
10:   */  
11:  unsigned int float2BCD4 ( float value, int numberDigits, int numberDecimal ) {  
12:    /* BCD Conversion */  
13:    unsigned int bcdField = 0x00;  
14:    int work   = 0;  
15:    char digit   = 0x00;  
16:    int bcdDigits = 0;  
17:    if ( numberDecimal ) {  
18:      work = (int) (value*pow(10,numberDecimal));  
19:    } else {  
20:      work = (int) value;  
21:    }  
22:    do {  
23:      digit = work%10;  
24:      bcdField |= (digit&0x0F)<<(bcdDigits*4);  
25:      work /= 10;  
26:      bcdDigits++;  
27:    } while ( bcdDigits != (numberDigits+numberDecimal) );  
28:    /* ARINC 429 Adjustment */  
29:    bcdField = (bcdField<<2) & 0x1FFFFC;  
30:    return( bcdField );  
31:  } // end integer2BCD4  

Avionics Bending: X-Plane Float to BNR ARINC 429 Label Conversion Example

Still busy working on the SFENA HSI integration with x-plane. I thought it could perhaps be interesting to you to see how I convert a label from the x-plane floating point output to the ARINC 429 format. For the example I will use a BNR formatted ARINC 429 word.

Taking Magnetic Heading Information from X-Plane to ARINC 429 Label 320

The magnetic heading information computed by Austin's x-plane software can be exported via the XSquawkBox SDK as a floating point number. On Apple OSX, a floating point number is a 4 byte (32 bit) number using standard floating point based real number approximation. So, strictly speaking, the SDK exported magnetic heading information from x-plane has a lot more resolution than the SFENA HSI requires to rotate the magnetic heading card to the right spot.

The SDK will output an approximate heading of 060º as a floating point number of about 60.000001 which is what I will continue to use for the remainder of this posting.  Lets look at the ARINC 429 word next.

The ARINC 429 Label 320 for Magnetic Heading has the following format:

BNR Word Format (No Discretes), ARINC Specification 429 Part1, p. 78

The be more exact, the Magnetic heading is expressed in units of DEG/180 and typically has either 15 or 10 significant bits in the data field. Hence, giving it a resolution of either 2^15 or 2^10 or 32768 and 1024 respectively. The SFENA HSI uses a resolution of what I think are 18 bit ... which is quite high.

The value of 60º as computed by x-plane now needs to be converted into the basic ARINC 429 information. I do so by applying a compensation factor in order to keep the computational load down on the machine. Here are the steps:

1. Apply the correction factor for the bit depth and angular encoding. That correction factor is:

DEGFACTOR = 0.000686644

         HDGXPLANE
HDGBNR = ----------------
        DEGFACTOR

The value for HDGBNR after this step is 0x20000.

2. Adding the SSM and the Parity

The BNR requires adding the SSM of '11' in bit locations 31 and 30. As well as computing the parity across the 31 remaining bits of the ARINC 429 word. So here it is in bits:

Empty ARINC Label 320

P   SM   Data                 SD   Label

0 | 00 | 100000000000000000 | 00 | 11010000

add 0x20000

0 | 00 | 100001000100000000 | 00 | 11010000

set the SM to 11

0 | 11 | 100000000000000000 | 00 | 11010000

compute the parity (there are 6 bits set so it requires a bit to make odd parity)

1 | 11 | 100000000000000000 | 00 | 11010000

The data portion of the ARINC 429 word now has the value of 0xE80000. Tomorrow I will walk through the conversion of a floating point number from x-plane to an ARINC 429 compatible BCD. Below are some code snippets:

1:  /*  
2:   * Convert a floating point Degree number to a BNR without format  
3:   * correction.  
4:   */  
5:  unsigned int floatDEG2BNR ( float value ) {  
6:    unsigned int work = 0;  
7:    value = ( value / DEGFACTOR);  
8:    work = 0x600000 | ( (int) value )<<2;  
9:    return( work );  
10:  } // End floatDEG2BNR  

Not the most elegant parity computation below, however, the label and data section of the unassembled word are in different structure pieces:

1:  /*  
2:   * Compute odd partity and set MSB of the ARINC429 word as the odd parity bit  
3:   */  
4:  void parityOdd( unsigned int *value, unsigned int *label ) {  
5:    unsigned int x;  
6:    unsigned int parity = 0;  
7:    for (x=0;x<8;x++)  
8:      if ( *label & 0x1<<x )  
9:        parity++;  
10:    for (x=0;x<23;x++) {  
11:      if ( *value & 0x1<<x )  
12:        parity++;  
13:    }  
14:    if ( ((parity & 0x1) == 0) )  
15:      *value |= 0x800000;  
16:  } // End parityOdd  

L-1011 Avionics Bending: SFENA HSI and ARINC 429 - Part 11

The work on the SFENA HSI continues. By the way, SFENA later became Sextant Avionique which then became part of the french Thales Group. Awesome products and very neat engineering that went into this device. In the video below you can see the integration of the following X-Plane parameters

1. Magnetic Heading
2. VOR OBS Setting
3. VOR Omnibearing
4. Autopilot Heading Select 
5. Ground Speed 

There are a few more ARINC 429 labels to go but I do think that I will have pretty much all the components working by the end of the week. Then its on to the fun stuff ... making the HSI work with alternate, pilot selectable, sources and driving both the pilot as well as the first officer's HSI from X-Plane.

L-1011 Avionics Bending: SFENA HSI and ARINC 429 - Part 10

Good progress on the SFENA HSI integration work. All software pieces are now in place and the HSI can be controlled via x-plane.

HSI Software Integration

While today's posting does not integrate all of the ARINC 429 labels required to run the entire instrument, it uses Label 320 which describes "Magnetic Heading from AHARS".  For the magnetic heading data to arrive at the HSI the following steps have to be taken:

1. The magnetic heading data is extracted from the x-plane flight simulator and stored in a shared memory segment by the TAP process as a floating point number.
2. The ARINC 429 to UDP subsystem picks up the float and converts it to an ARINC 429 encoded BNR. The parity for the ARINC 429 data is computed and the data together with the label sent on via UDP to the HSI driver
3. The HSI driver takes the label and the already ARINC 429 converted data from the UDP packet and queues it to the ARINC 429 adapters high-speed (100Kb/sec) transmit channel
4. The HSI logic translates the data into motor movements and rotates the heading hard to the correct position

All of the above happens once every 50ms to create a smooth movement of the HSI instrument.

The video below is a short demonstration of the end-to-end integration of the SFENA HSI:

Over the next few days I will work on the complete integration of all the data needed to operate all the features of the SFENA HSI. 

L-1011 Avionics Bending: SFENA HSI and ARINC 429 - Part 9

Worked on the data transfer between the ARINC 429 Subsystem with UDP software and the HSI driver component.

In the video below you can see a sequence of Label 320 (Magnetic heading from AHARS) test data being sent via UDP from the ARINC 429 Subsystem to the HSI Driver.

The next step will be to connect X-Plane itself to the shared memory segment. This work will start tomorrow. Again, I will post the code (and a link to github) for all this at the end once the HSI is fully integrated.