1 2 3 Previous Next

NexGen Flight Simuator

35 posts

sonic-cruiser-tiny.jpgThe Plan Part 3: Ok the interface card is now wired up and hooked to a computer so we get on checking the software switch states. So I hooked my arduino to my radio interface, added the jumpers and plugged in the interface cable and then generated a truth table from that data (see figures 1,  2).

int frac[] = {20, 5, 8, 2, 16, 4, 1, 9, 10, 18 };


int huns[20][2] = {

{13, 0}, {9, 108},{11, 109},

{5, 110}, {27, 111}, {16, 112},

{30, 113}, {2, 114}, {23, 115},

{8, 116}, {28, 117}, {1, 118},

{7, 119}, {4, 120}, {24, 121},

{20, 122}, {6, 123}, {18, 124},

{17, 125}, {10, 126}};

Figure 1
Radio Truth Tables

In truth tables I have declared two arrays the first is frac and is a single dimension array. The array contents of the array are the values and the index times 10 is what we display. In the second array is called huns and is a two dimension array with the second element the value to be displayed.


Figure 2
Radio Interface
Figure 3


I have included a little video clip of the radio interface which shows an overview of interface. I have also uploaded the pin-out of the C-3436A for your giggles, or edification as I could never locate one for myself.

The next steps is to get this talking to the RSS_IOP and with the information that is on the NavGroup broadcast and with line of slight calculations play the stations morse code identifier..

  Keep Tuned In, More to Come!

~~ Cris H.

THE PLAN (Step 2):  Well the first thing we need is a piece of Vector Board, about 4" x 4"  or about 10 x 10 cm ( Do not buy any cheap crap off of ebay.. It must be FR-4, glass-epoxy ).

Vector Board before for clean up
Figure 1

I need cut 2 holes in the board about  2" x .5" (Figure 1), or you can use a DB25 punch if you are lucky enough to own one, $$$$.  I cut the two holes with my Dremel mult-tool, but it is very hard to control, I now have to clean it up, any way, with my Dremel. If I had the right blade for the rotary tool it would have been easier. Then I need to mount the adapter plate(s)(Figure 2) to the Vector Board and the DB25(s) to them as well.


DB25 Adapter Plate

Figure 2

The next thing is to mount the three 16 pin IC sockets, a little dab of hot-glue, or crazy glue and that should do it. But remember to leave room for the 4 pin Molex connector  that is common on disk drives, and fans, Molex Part Number 15-24-4441, Molex Specification Sheet, and a relay that control the panel lamps.

I  really like this relay module I found on ebay (Figure 3) and the cool part is I don't have to build it. There is all so a 2 channel module as well. BTW they are cheaper than I can build them..lol
Now the only this to do is break out the Wire Wrap stuff and wire it up (Figure 4).

  Keep Tuned In, More To Come
~~ Cris H.

BTW Long to finish got sick anyway just finished now on to the next part.

I am having the adapter plates made  for me. Let me know if you think you can use them. I might get a small run of 100 made. My guess is they will be about 5 to 8 bucks each.

1 Channel Isolated 5V Relay Module

Figure 3

Interface board finished *
* The power connector, nor is the relay wired in yet..
Figure 4

                                                                                                                                                                                                                                                                                                                                                                  One more note: I have found some food containers used in the food business NR2402P-BLK my interface bolts right in. Oh yes the white dots in the photos in figure 4 are nylon 4-40 screws and nuts.

THE ANALYSIS: The radio head C-3436A was used in the 1960's. It is used for both VOR and ILS. It has three (3) ARC connectors in the rear. I had built some cables for the unit a few ago but then never did anything with it.  So I need to test the RSS so I pulled out this unit. I am going use the term "Hacking" loosely as I am not going to damage the Control Set in any way. 

Radio Control Set
Figure 1
The Radio Control Set Opened for Testing
Figure 2
Radio Control Set Interface
Figure 3


1. The first thing I had to do was ring out the connectors (Please see Figure 2) as I did not have the schematics as the TM 11-1520-211-35 Google Book  did not scan them properly. ( I have attached a sheet of the result of the ring out but as yet I do not have the weighting for each line.)

2. The next thing is to build an interface board to go between the Control Set, and an Arduino Mega2560. The board will have two (2) DB25F jacks to plug into my cables.  There are also two (3) 16 pin IC Sockets. As this interface board is a one off I will Wire-Wrap it.  There will be most likely a small relay to handle the lighting, and a Molex 4-pin connector for the power.

3. The next thing is to jumper the board to the Arduino via the rear header (Digital I/O Pins 21 through 53).

4. At this time I am not going to worry about the following items: Lights, Volume, nor Squelch.

  Keep tuned in, more to come!


sonic-cruiser-tiny.jpgSo what am I supposed to say; A time ago, in a different space, and time, I started designing  a new canard aircraft, The Phoenix2000. In New Orleans before I move to Dallas, Tx so it has to be over 20 years ago. My original web site for it has a date of 1998 but that's about 10 years after the fact. I had built a dual channel, redundant FADEC, Full Authority Digital Engine Control, connected to FORD Taurus 3.0 engine. This means no mixture controls, you don't have to worry about things like, EGT, mixture, temperature, etc.  Our EAA adviser in our chapter built RVs, and basically did not want to look at anything Digital Fly By Wire!! ( I left the EAA 96?)  Then in 2004 i found other crazies at SimPits(2k4) There have been the ups and downs. The biggest down was when I lost my house, and had to toss most of the aircraft stuff away..

My NOTAM #1 (Jan2K5) basicly laid out my problems with current flight simulators; Keyboard Decoders, Monolithic, No real communication (with the simulator/model).  This is where my simulator grew from.

My NOTAM #2 (Jun2K5) I created a demo program which fly's a Great Circle Route  between any two points. in a compressed time frame. So a flight from JFK to DFW is only a few seconds.. One small note and apologies to C purists, this demo was written in PERL. If you don't know PERL dose not have any fixed point notation it is all floating point.

So for the past few years I have been a living stable in a apartment, and I am back at work with several projects in the lab at one time.. current projects are:CDU_-_Simulator_Interface.png

    • embedded processors for a few radios heads.
    • Morse Code Generator
    • FAA DB
    • Communication between the IOP and the radio heads
    • communication between the SIMULATOR and the NAV_IOP and RSS_IOP  Ethernet & Protocols.

AND now I want to show it off at Cockpit Fest 2014!!  Groan!!

  Keep tuned in, more to come!


Ouch... Where do I start.. Questions:

  1. How many power plants? ie Engines, APU, RAT, etc.
  2. Is you system going to be AC or DC based?
  3. What will be the prime voltage? 12, 24, or 48 volts
  4. Is there a ground power port? (makes life easy)
  5. etc...


Well here is a overview of my airplane. You will notice that it is a twin. There are two alternators, and starters. You see  my alternators have had the diodes ripped out of them so the unit produces AC at 400Hz which is accomplished by applying a 400Hz sine wave on the Alternator Exciter. By engaging the ALT1 or ALT2 contact or we can turn on the DC rectifier.

When the two alternators are out putting at same voltage and phase we can turn on the TIE RELAY so that each alternators can split the load.  The AC TIE RELAY is used for isolation. That is if you have a alternator failure. The failed alternator can be isolated and its load can be support via the other alternator. (author CAH 17MAY2014)
There is also two other contactors one controls the EXTERNAL POWER  the other is the battery disconnect.

In this way you can't discharge your battery via the EXTERNAL POWER JACK.  The two Master Switches on the panel are a SPDT (Single Pole, Double Throw) with center off. So if both switches are in the EXTernal positions the 24vdc sense line is on only when the generator (external power) is on, which energizes the GROUND POWER RELAY, which in turn puts 24vdc on the BATTERY BUS.

So when you have the switches in GEN postilions, the alternator, is spinning happily, there is voltage on the BATTERY BUS from the DC rectifiers, controlling the battery when charging in flight or on the ramp.



  Tune in later, more to come!




  • What this diagram does not make clear is that both DC Rectifiers are attached to the Battery Charging Circuits via a diode so that you can not back feed the battery or the Chargers themselves.
  • Also not shown is the DC BUSS TIE RELAY which ties both out puts together
  • Also not shown is the BATTERY DC BUS TIE RELAY

sonic-cruiser-tiny.jpgOk I am going review some of the RSS as it is changing but in a good way..


Figure 1.
RSS Block Diagram

The RSS_IOP has a lot of jobs (review):

    1. Physical radios themselves.
    2. The radio's interface system  (arduino cards).
    3. Driving some intruments (flags, lights, etc)
    4. The interface to NavGroup intranet ( and decoding messages).
    5. Morse Code generator.
    6. FAA radio data base. (mySQL)
    7. Radio simulator.
    8. Line of sight calculations (between radios and aircraft)
    9. Crew audio station(s).
    10. Moving audio from different sources to the right audio line (LASA Patch Bay)

Currently we will only concern our selves with the radios functionality 1 and the interface system 2.

The radio model has been changed thankfully to a UML editor from Mentor Graphics.

The Analysis:

Figure 2.
RSS Radio Model

We can look at a radio in three (3) parts;

  1. The physical radio (common to all radios). This is the structure referred to as radios[]. This is an array of all the radios.
  2. The interface. This is was makes each radio unique.  This is the structure referred to as radio_XXXX.
  3. The tuner or tuners. The tuner is just that. It hold the tuned frequency, and its file descriptors. This is the structure referred to a tuner_XXXX.

Each one of the structures need a forward reference ie. a pointer to the next lower structure. So when we get a interrupt from one of the tuners, we can just grab the right tuner. But what if we have turn on/off in one of the upper structures? We added two (2) backwards references, or pointers in the tuner's structure.

The protocol between the interface card (arduino) and the RSS_IOP is as follows:

Between the arduino and the RSS_IOP: 3 bytes;  1 RADIO_ID, 2 SWITCH, 3 DATA. Then the RSS_IOP NAC's or ACC's back;

Between the RSS_IOP and the arduino; 3 bytes;  1 RADIO_ID, 2 OUTPUT, 3 DATA. Then the arduino NAC's or ACC's back;

Radio Head (Hardware):


Any radio head can be interfaced to the system, such as:

  • ARINC-410:  Decoding is done on the RSS_IOP
  • ARINC-429:  Separate interface card in the RSS_IOP 
  • MIL-1553:     Separate interface card in the RSS_IOP 
  • Custom:        You build it, well make it work

Keep tuned in, More to come

~~ Cris


NexGen: System Overview

Posted by phoenixcomm May 4, 2014

sonic-cruiser-tiny.jpgOk Now Lets all take a deep breath in an I will begin...

Ok I have been dissatisfied my the state of flight simulation. It really bugged me that most planes have on than one seat, ie.. pilot, copilot, reo, nave, weapons, etc. Then I remembered a game called Star Trek that we played on the TCNJ, a computer network in NJ. each team had a captain, weapons, helm, engineering, science, transporters, and a few others that my old brain can't recall. BTW all this was played on a PCxt and the big 360.... I have more power in one desktop than all that put together. And then of course now add in Microsoft Flight Simulator, and X-Plane, and a few others.. nah, all.

So here where my design objectives came from.

  1. The system should handle multi-seats with out problems.
  2. The above entails that you system must also handle multiple radios, instruments, etc. (so if you can write it for one (1) make it handle a few or more.
  3. Radios are a big part of a sim.. so we need all types.. and the faa frequency, and lat/long for all the towers, runways, etc. (oh, no)
    1. this needs a database
    2. Morse Code Simulator
    3. drive for some indicators such as RMI, HSI, VSI, and others. Plus all the flags
    4. a little math so while you are on the ramp at LAX you cant hear the tower at lets say JFK.
  4. The system should use mostly IP for our data.
  5. Instructors Console and Data Recorder.
  6. The simulation model should be on one (1) computer.
  7. The other parts of the system will be IOPs that is Input/Output Processors.
  8. All of the Hardware (Aircraft Parts) will talk with there perspective IOP ie RSS_IOP, NAV_IOP, DISPLAY_IOP, etc. via embedded microprocessors via USB.
  9. On Hardware (Aircraft Parts) rule 1. DO NO HARM. Before you work on a unit find manuals,  pin-outs, etc. GUTTING IS THE LAST RESORT!

And Just Remember This is Just a Start.

One of the things that help me with working on a new unit..  Write you own manual.. Personally I  have several

  • NexGen® 1252 CDU, Computer Display Unit
  • NexGen® Nav_IOP,  Navigation Input Output Processor
  • NexGen® RSS_IOP,   Radio Sub System Input Output Processor
  • NexGen® Protocols 

  Keep Tuned In More To Come


sonic-cruiser-tiny.jpgHere are some of the flight sim websites around... there are plenty more of them, but I only listed a few of them.


Name / URLAuthorTypeNotes
L1011 ProjectCurd ZecMistesterL-1011
737 Flight SimDavid C. AllenB737
2 Flaps Approach~~B737
F-15C EgaleGene BuckleF-15C
A Journey into MadnessK. LaFailleA-10C
Stranded DucklingGusA-10C
Building an Airbus CockpitNigel DoyleAB 3xx
Super Connie SimConstellation
NexGen / Phoenix 2000Cris Harrison


sonic-cruiser-tiny.jpgOk, it seems that we are back where we started from talking about the RSS_IOP. There have been so many changes that we may as well just start over.

So now I can share with you the major data structures  from here forward. So lets get started.

rss and tunerradio_xxxxx

typedef enum _Radio_Types {





  G4214 }Radio_Types;




struct rss_s {

  char * device_info;             // some thing about the radio NAV/COM/etc.

  char * device_model;         // the Manufactures part/model number.

  char * device_serial;          // the device's serial number..

  Radio_Types device_type; // Its device_type which is defined by the typedef above Radio_Types

  int power_48v;                   // power to the unit..

  int power_400hz;

  int panel_lamps;                // turn off or on the Panel Lamps only

  void * radio_info;

  void * tuner;

  int sub_devices;                // how many tuners are in this device.





enum fd_index {







typedef enum _tuned_units { // this is for numbers that have the form of nnn.ff (n= number) (f= fractions)










typedef struct tuner_s { // when we talk about 'sub-radios' we are really saying how many tuners are there??

  int power;

  int dial_lamp;

  char * device_name; // OS-name

  int fd[ FD_pair ]; // file descriptors

  int frequency[ tuned_units ];


// This is for the Collins G14L8 Adf head.

typedef enum _mode_sw_614L8 {

  OFF = 0,







typedef enum _loop_sw_614L8 {








struct radio_s_614L8 {

loop_sw614L8 loop_sw_614L8;

mode_sw614L8 mode_sw_614L8;

  int sw_band;

  int sw_bfo;

  int meter;




////   G1981 ATC  Transponder

//     As the ATC Transponder does not have a tuner

//     we can ignore the field 'int frequency[ tuned ];'



typedef enum _mode_sw_G1981 {








typedef enum _band_sw_G1981 {









struct radio_s_G1981 {

  mode_sw_G1981 mode_switch;

band_sw_G1981 band_switch;

  int sw_ATC;

  int sw_ident;

  int test_monitor;

  int alt_off;

  int squawk[ 4 ];



//// G-3717  this is a simple radio with 2 tuners.



struct radio_s_G3717 {

  int sw_VHF_NAV;

  int sw_VOR_TEST;

  int sw_DME_TEST;

  int sw_DME_STBY;

  int sw_UP;

  int sw_DOWN;






#include <stdio.h>



#include "rss.h"

#include "main.h"

#include "rss_init.h"



int main(int argc, char *argv[]){



  max_fd = 0;

  int ecode;

  // bus voltages

  int p400;

  int p48;



  // The Radio Tuners

  // ** Please note the "dev/stuff is not right and must be changed before testing.



static struct tuner tuner_G_3717[] = {

  { 0, 0, "/dev/tty0/usb1", },

  { 0, 0, "/dev/tty0/usb1", } };

static struct tuner tuner_C_614L8[] = {

  { 0, 0, "/dev/tty0/usb1", }};

  static struct tuner tuner_G_1981[] = {

  { 0, 0, "/dev/tty0/usb1", }};

static struct tuner tuner_G_4214[] = {

  { 0, 0, "/dev/tty0/usb1", }};

static struct tuner tuner_G_3490[] = {

  { 0, 0, "/dev/tty0/usb1", },

  { 0, 0, "/dev/tty0/usb1", },

  { 0, 0, "/dev/tty0/usb1", },

  { 0, 0, "/dev/tty0/usb1", }};



  // The Radio Details

static struct radio_s_G3713 radio_G_3713  = {

  { 0, 0, 0, 0, 0, 0 }};

  static struct radio_s_614L8 radio_C_614L8 = {

  { 0, 0, 0, 0, 0 }};

  static struct radio_s_G1981 radio_G_1981  = {

  { 0, 0, 0, 0, 0, 0, {0}}};

static struct radio_s_G3490 radio_G_3490  = {

  { 0, 0, 0, 0, 0, 0, 0 }};

  static struct radio_s_G4214 radio_G_4214  = {

  { 0 }};



  // The Radio(s) Master List



  static struct rss_s radios[] = {

  { "COM 1 & 2", "G-4214", "68", G4214,  0, 0, 0, & radio_G_4214,  tuner_G_4214,  DIM( tuner_G_4214 )  },

  { "VOR, DME", "G-3717", "81", G3717,  0, 0, 0, & radio_G_3713,  tuner_G_3713,  DIM( tuner_G_3713 )  },

  { "ADF", "614L8", "8384", C614L8, 0, 0, 0, & radio_C_614L8,  tuner_C_614L8, DIM( tuner_C_614L8 ) },

  { "ATC", "G-1981", "336", G1981,  0, 0, 0, & radio_G_1981,  tuner_G_1981,  DIM( tuner_G_1981 )  },

  { "5in1", "G-3490", "31", G3490,  0, 0, 0, & radio_G_3490,  tuner_G_3490,  DIM( tuner_G_3490 )  }, // Optional Radio








  int i, j;

  // loop over the installed Radios and sub radios

  for( i = 0; i < DIM( radios ); i++ ){

  if( rss_init( & radios[ i ] ) == ERROR ){

  perror( "Initialization failed");

  return( ERROR ); }





  ecode = 1;

  // test for power errors

    p400 = power_buss_400hz();

    p48 = power__buss_48v();

    if( p48 != OFF || p400 != OFF ){

  ecode = GO;}

  else {

  ecode = ERROR;

  if( !p400 )


  if( !p48 )





  // iop returns with error TBD!!





  }  while( ecode != ERROR );


So far so good. I have shown you what our data structures are now.  I will show you my main.c. You will notice that all of the radio components ie: radio[], tuners, and radios are all declared static, as their "lifetime or extent" extends across the entire run of the program.

Keep tuned in, more to come!

~~ Cris.

Apr 14, 2014

Changes just a few:

1)  struct radio_614L8 is now struct radio_s_614L8

     the radio_s_XXXX is the form that I will be using the _s_ stands for structure

     this changes the invocation of the radio in my main.c


     static struct radio_G3713 radio_G_3713


     static struct radio_s_G3713 radio_G_3713

2) power testing has been simplified:

      if ((( p400 = power_buss_400hz()) || ( p48 = power__buss_48v())) != OFF ){


    p400 = power_buss_400hz();

    p48 = power__buss_48v();

    if( p48 != OFF || p400 != OFF ){

Ok when I saw this last this last  2014 GMC Sierra "Cold Rolled Steel" add I could not believe my eyes. One of our subs in a TV commercial??!! Nah, I said to myself.... 

Then I started doingsome Google searches which ended with more commercials.. I was starting to doubt myself. so I changed my question to "which submarine was used in the GMC Sierra commercial?" and I found a link via Facebook to Spectral Motion. When I when to the link I found this and laughed my ass off.





Keep tuned in, more to come.




The H&R Block Aircraft Carrier commercials  where shot on the USS Hornet.. and Lots of CGI.
A quick phone call to the USS Hornet Museum verified this.

And here is a Facebook link.


PART 1: A Physics Lesson: or what you can get away with on television commercials. – part 1  October 22, 2011
PART 2: A Physics Lesson: or what you can get away with on television commercials. – part 2  November 6, 2011

and for flight simmers:

What you can get away with on TV – Pam Am: Unscheduled Departure November 14, 2011

SonicCruiser_icon.jpgOk, So here we are again. The RSS has raised it's head one last time.. This time we will slay it.. So onward and upward. 

First I have talked about this part of the puzzle more than a few times.. Well spurned on by my CDU_IOP, I thought that since the CDU_IOP was designed with modularity in mind I rewrote my RSS_IOP to take advantages of things that I have learnt along the way.


CODE SEGMENTS: First we have to talk about the model or the structure of the radios.


rss.hadd a few radiosOur main.c

struct rss_s {

    char * device_info;

    char * device_model;

    char * device_serial;

    int power_48v;

    int power_400hz;

    int panel_lamps;

    void * radio_info;

    int sub_devices;

    int panel_lamp;

    struct device_s {

        int fd[ FD_pair ];

        int frequency[ tuned ];

        int dial_lamp;



struct radio_G3713 {

  int sw_VHF_NAV;

  int sw_VOR_TEST;

  int sw_DME_TEST;

  int sw_DME_STBY;

  int sw_UP;

  int sw_DOWN;

  int vhf_dial_lamp;

  int nav_dial_lamp;



struct radio_G3490 {

  int sw_com1_test;

  int sw_com2_test;

  int sw_nav1_test;

  int sw_nav2_test;

  int sw_comm_sel;

  int led_nav1;

  int led_nav2;

  int dial_lamp_com1;

  int dial_lamp_com2A;

  int dial_lamp_com2B;

  int dial_lamp_nav1;

  int dial_lamp_nav2;


int main(int argc, char *argv[]){


    max_fd = 0;

    int ecode;


    static struct radio_G3713 G_3713;

    static struct radio_G3490 G_3490;


    static struct rss_s radios[] = {

      { "COM/NAV #1", "G-3717", "81",  0, 0, 0, & G_3713,  2, },

      { "5in1", "G-3490", "31",  0, 0, 0, & G_3490,  4, },




    int i, j;

  // loop over the installed Radios and sub radios

    for( i = 0; i < DIM( radios ); i++ ){ // RADIOS

      for ( j = 0; j < radios[i].sub_devices; j++  ) { // SUB DEVICES

          if( init( radios[i].sub_device[j] ) == ERROR ){

            perror( "Initialization failed");

            return( ERROR );




  // test for power errors

  /*if (( p400 = power_buss_400hz()) || ( p48 = power__buss_48v() != OFF )) {

    if( !p400 ){

    error_msg() }

  } */


  // iop retruns with error TBD!!

  }  while( ecode != ERROR );



You will notice that in rss_s structure is an array, and each array member is a radio, and each radio can have 'sub devices' that is one or more tuner(s). Lastly in the rss.h there is a pointer to radio_info but its a void type (this is a place holder only and we will have to cast it to one of the radios in column two).


Gables G-3713

Fig 1.

Well as you can see in Fig 1. and they looking at struct radio_G3713, you will notice a one to one instance between a switch and its description in the code segments. For instance if you look a Fig 1. and see the 'DME TEST' push button, in the lower right, and you see in the code above 'int sw_DME_TEST;' This is the same for every switch on the radio. The frequency dial is handled by ARINC-410 code which is a 2 out of 5 negative going code.

    Keep tuned in more to come

  ~ Cris




3/30/2114 Major changes to the rss data structures.

  1. removed this from rss.s: and added it to all of the  radio_ xxxxxx structure(s).
    struct device_s
            int fd[ FD_pair ];
            int frequency[ tuned ]
          int dial_lamp;}sub_device[];
  2. In main.c the second for loop has been eliminated.
    for ( j = 0; j < radios[i].sub_devices; j++  ) { // SUB DEVICES
  3. This also changes the next line of code from:
    if( init( radios[i].sub_device[j] ) == ERROR ){
    if( rss_init( radios[i] ) == ERROR ){

Oh well this is one of those things that has been sitting around doing nothing... And all I need to do is build yet another cable.. It was a prototype made by  Precision Display Technologies. Their part number is MPCDX-PROTO, which is for the F/A-18C/D.

Fig 1. F/A-18C/D MPCD prototype

The Analysis:  Well it looks like I need a VGA cable to go to a component input.. So what signals are in a VGA cable?  So a quick look and I found this picture (Fig 2). So I need a cable that will start as VGA cable and end up with 4 BNC connectors RGB+Sync.

Fig 2. Rear


The Plan:  Well getting a VGA Cable is a no-brainer there all over the place.. Next we need the other end. As I have lots of Sun Microsystems Cables, one of them is a DB13W3 to BNC cable.  So now all I have to do is cut the cables in half and put them back right? Sounds good.. The Bezel Control I/O will have to wait for another day.

Fig 3 VGA Pinout


VGA Pin and ColorVGA WireDB13W3 Wire
Table 1. VGA Connector


LATER:  Ok So I wired it up as per the above table and got this: (Fig 4)

  I have to download there software to adjust the CRT its all done with software...

Fig 4. Working monitor needing adjustment




MUCH LATER: Oh well my cable did not work right and the display would not lock vertically. During  a call  today  with John, at Precision Display Technologies,  he suggested that I need to use both syncs. As this unit will use three types of syncs:

  1. syncs(2) on green,
  2. combined syncs,
  3. separate syncs.


VGA Pin and ColorVGA WirePS3 Wire
13H SyncREDRed/Blk
14V SyncGRAYBlue/Blk
Table 2. Cable v2


So a quick jumper between the Gray sync wire and the VSync confirmed this. Table 1 is out and Table 2 is in.  It looks like I will need CABLE v2. So the DB13W3 is out as it only has 4 BNC connectors and I need 5;  RBG + 2 syncs. I remembered that I just picked up a PS3 Component Video Cable.. It sounds like I have my new sacrifice!!

Ok all ended well that is well and it all works..


Fig 5. Working monitor
I have to adjust the resolution..

  LATER: FEB 18, 2014  well here is the new cable, you will notice there is a DVI - VGA at the end of the cable. GROAN: Do you see whats wrong?? yup the ends are RCA-Phono not BNC connectors.... Looks like I need some adapters (see Fig 7)..

LATER:  It looks like there was a whisker shorting out the Blue.. GROAN: Ok the fix is painful. I have to cut down the shrink wrap and then the electrical tape and two layers of shrink wrap over the Blue it self.

Fig 6. The new cable.


















Fig 7.
RCA-Phono - BNC Adapter


Keep tuned in more to come

~ Cris

  BTW: The tools that I used to figure out this mess was a DVM to ring out the VGA cable and my old Tektronix 475A Oscilloscopeto get the syncs right..

This is not the post that I started to write. But I can't help myself.

Fig 1. - Commercial Aircraft Audio Panel

The Problem: You just bought a new Gables audio panel for your flight simulator from eBay, but you don't know anything about the panel, so before you do any kind of problem solving you grab your trusty simpers and start cutting.. ie.. It time for that rewire.. right?

Wrong.. You should have done a little investigation, made a few calls maybe even to Gables... Hey they have always been helpful with a pin-out diagram.  You just have to ask nice. That would have solved the problem of the the two connectors at the rear of the unit. ( See Fig 2.)

Fig 2. -  Rear of Audio Panel and the
Bendix Connectors

They are just standard Bendix type connectors that are very well understood.

Fig 3. -  Buchered Audio Panel

I am an engineer and you never want to reinvent the wheel!

If you play fast and loose with your cutters then you will end up with this: (See Fig 3.)


But with just a little bit of work you could have ended up like this (image below) Now doesn't this look much better with a whole less work! Just remember that this is for one channel, my ACP is taking its inputs from my RSS or Radio Sub System. In the aircraft you have a 'remote electronics unit' which is a distribution amplifier for 12 radios. Remember a pilot my have 4 or 5 radios in his ear, but can only talk on one radio at a time.

Fig 4. - Courtesy of David Allen

Keep tuned in more to come!

DESIGN GOALS: I have talked about the IOP before so I will review the design:


  1. The IOP can control multiple CDUs (dumb terminals) via an Ardunio's USB.
  2. The IOP listens to the NavGroup UDP broadcast for present position, etc.
  3. The IOP sends the PP/etc to be updated on the CDUs.
  4. All software will be written in C.
  5. We will standardize on the eclipse platform for software development.

CDU - IOP Software Protocol:

  • The CDU sends one character to the IOP. The IOP will respond with character string.
  • The IOP sends a command to the CDU. The IOP will respond with NAC.


CDU - IOP Software Review:  This IOP is built on on Linux platorm which performs the following functions:

  • handles all input via an internal command select(2)
  • All of the CDU's fuctions via a program called nav_iop.c
  • The software handles all keystrokes
  • The software handles the all the switches
  • The software handles the displays
  • As well as
    • listening to the NAV-GROUP network
    • Updating present position
    • Storing all the variables.
  • Multiple CDUs can be handled by using a array of structures to hold them. 
  • this is the definitions:


  • enum fd_index {
    • RD,
    • WR,
    • FD_pair };

  • struct cdu_s {
    •           // device info

    •           char * device_info;                    // something useful about the cdu

    •           char * device_name;                    // in the form of "dev/xxxxxxxxx"

    •           int fd[ fd_index ];                         // file descriptors

    •           // power flags

    •           int power;

    •           int power_48v;

    •           int power_400hz;

    •           int keybord_power;

    •           // keyboard state info

    •           unsigned short alpha_high;

    •           unsigned short alpha_low;

    •           unsigned short clear_flag;

    •           unsigned short keypad_power;

    •           unsigned short cursor;

    •           unsigned short keystroke;

    •           // switch state info

    •           unsigned short power_flag;

    •           unsigned short mode_sw;

    •           unsigned short display_sw;

    •           unsigned short dest_thumb_sw;

    •           unsigned short fly2_thumb_sw;

    •           // display info

    •           short display_cntl;

    •           short keyboard_cntl;

    •           char chars[displays][display_max + 1];

    • };


And this is how we invoke it.

static struct cdu_s cdu[] = {

                    { "Pilots", "dev/USBtty0", {O_R, O_W }, }          // Please note the the O_ option are for demonstration purposes only and are not correct.



ARDUINO Software Review: The Arduino has the following things to do:


  • One Arduino per CDU so each CDU has its own Device Name ie /dev/USBTTY0. This is important, so that the NAV-IOP O/S knows which CDU is requesting service.
  • Ps2 keyboard decoder, for the Keypad interface. There is a good article in the Arduino Playground.
  • One 16 bit I2C Bus expander, PCF8575C,
    • four switches (2 thumbwheel and 2 rotary).
  • Drive two relays:
    • Main Power
    • Keyboard Lights
  • Use two (2) MAX6955 Display Controlers via the I2C Bus, which drives the 16 and 7 segment displays.

Processor Shoot Out
USB Serial Device20 (RX) and 1 (TX)0 (RX) and 1 (TX)
External Interrupts22 (INT0) and 3  (INT1)

2 (INT0), 3 (INT1), 21 (INT2),

20 (INT3), 19 (INT4), 18 (INT5)

Ps2 Keyboard23 (INT1) and 4 (DATA)3 (INT1) and 4 (DATA)
I2C Interface2A4 (SDA) and A5 (SCL)20 (SDA) and 21 (SCL)
Display Switch*4N/A*22, 23, 24, 25
Mode Switch*426, 27, 28, 29
Thumbwheel Switch 1*430, 31, 32, 33
Thumbwheel Switch 2*434, 35, 36, 37
Keyboard Power Relay138
Display Power139
MEM LED, Red140
MEM LED, Green141
MAL LED, Red142
MAL LED, Green143
Arduino LED113 (LED)13 (LED)

*If the Duemilanove is used we need to use several I2C I/O Expander.


IOP (Linux) Software Review: The software is written using the Linux/Unix async communications with several devices (file handles) at the same time, that will include the USBtty, and UDP and TCIP connections at the same time. 






Keep Tuned In More to Come!!

This is the CP-1252/ASN-128 Navigation Computer Display.  The NCD was originally designed for Doppler  navigation, but will work in my application. I have reprinted the Analysis of this from my Wordpress Blog (22Apr2011)


The Analysis:  The NCD is comprised of 4 groups: Display, Keyboard, Rotary Switches, and Thumb Wheel Switches.  The Display is comprised of 4 16-segment and 13 7-segment PinLite lamps, and two LED's.  The keyboard is comprised of a 10 key number pad and 4 special keys, it also encodes A-Z. There are two rotary switches, and two thumb wheel switches as well. I also found a users guide, TM-1-1520-238-10 pages 3-34 through 3-46 on the web.


BTW I just found TM 11-5841-28-12 which is the Organizational Maintenance Manual for the unit, as a Google book. It has all of the neat error codes, and other cool stuff which will be helpful.



In it's dim past it had been converted to a flight sim, and the only thing left where: the display, switches, light plate, and lots of wire. Each component, had each of their connection(s) brought out in to a header.


The Plan: As it is almost impossible to find a 16-segment display driver, but I really found two parts MAX6954 (SPI or QSPI interface), and MAX6955 (I2C interface). Both devices have the same programing model and have a I/O expander which could handle the keyboard. I have chosen to use the I2C interface. I have broken down the NCD into the following sub-units:



  • Two MAX6955AAX+MAX6955AAX+:
    • one will handle the 4 16-segment displays.
    • one will handle the 13 7-segment displays.
  • The keyboard will be interfaced via a standard ps2 keyboard encoder that will be harvested from an old ps2 keyboard.
  • I will also need 2 bytes of I/O as well:
    • 1 byte of output to handle the two rotary switches, via two priority encoders (74LS148). 
    • 1 byte for both thumb wheel switches (they are encoded to 4 bit BCD).
  • And lastly I need a USB interface to talk back to the IOP (IO Processor)


I also need a embedded microprocessor, the NCD information does not need to be supper fast, as in reality it is only a dumb terminal, so an Arduino should be able to keep up with everything, if there are speed issues I will most likely switch to a TI Stellaris Launchpad module.   The NCD is ether taking key strokes from the pilot, or updating the display. In the words of the Outer Limits "There is nothing wrong with your television. Do not attempt to adjust the picture. We are now in control of the transmission. We control the horizontal and the vertical". In the scheme of things this unit will only be another end point on the IOP which is sending the key strokes or and knob turns to the simulation processor. And in turn the NCD in effect listens to the NavGroup via the IOP for present position, time to go etc.


Keep Tuned in More to Come!

NexGen Flight Simulator Blog Index