Skip navigation

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 CablePS3 Cable
13H SyncREDRed/Blk
14V SyncGRAYBlue/Blk
Table 2. VGA to 4 BNC Cable
Salvaged from a PS3 Game Cable
Fig 8. PS2/3 Psyclone 12 foot video Cable

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( Figure 8 )... 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..


Fig 6. The new cable thats shorted...

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)..

A Few Days 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.

LATER: AUG 31, 2014 Well I had some problems at Cockpit Fest with the Cable as you guessed I never fixed the *** Cable, so its time to do something about it..  I really want this to be pro. so I just cut the cable in half time to start over and just do it right.


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 Oscilloscope to get the syncs right..


8 Sept 2014 - Re-added back lost photos..

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

Vybrid controller solutions are built on an asymmetrical-multiprocessing architecture. Freescale-Tower.jpg The other night I went to the Avent/Freescale Vybird roll out, I figured that since it was taking place at a bar, I could score a few beers, and get some info. We to my supprise I won is the TWR-VF65GS10 (CPU), TWR-SER, and the TWR-ELEV. The TWR- parts are parts of a tower system.  The CPU card has two processors, an ARM® Cortex™-A5 and Cortex™-M4. The A5 comes with a Linux distro on a SSD card. The M4 run a RTOS such as MQX™.  All of the software is downloaded from freescale. Tower kits run from about $100 to $300.


  • Dual heterogeneous core: ARM® Cortex™-A5 at 500 Mhz
  • and Cortex™-M4 at 167 Mhz
  • Dual USB 2.0 OTG with integrated PHY
  • Dual Ethernet 10/100 MAC with L2 switch
  • Video/Camera Interface Unit with optional OpenVG accelerator
  • Display controller supporting resolutions up to XGA (1024x768)
  • High-assurance boot with Crypto Acceleration
  • Up to 1.5 MB on-chip SRAM and Dual SDIO
  • 1 Gb x 16  DDR3
  • 2 Gb x 16 NAND
  • Dual Quad-SPI with eXecute-In-Place (XIP)
  • Dual 12-bit ADC and DAC
  • Accelerometer



There seems to be a solid 3rd party support for both the hardware and the software as well as a user fourm.   It seems that this kit might be in my future.


Keep Tuned in More to Come!

NexGen Flight Simulator Blog Index



There are many types of synchros, Rx, Tx, and Resolvers. But what you have to remember that they are all just motorssyncrho.jpg. As you can see this is  really just  a 3 phase motor, that is the three (3) Stators, are 120 degrees apart. But you ask what is the Rotor winding for? Well if alternator diagram.jpgyou look at the picture of your cars alternator with out the diodes it kind of does the same thing as the Drive winding on the alternator. So if you took the diodes out of the alternator, and you put a 400 Hz sine wave on the Drive winding, remember you have to spin it,  you will get 400 Hz 3 phase power, just what I need for my plane.

Duh Now What

So now I have you all throughly confused. Right?
In a perfect synchro world you will have a Tx (like on a flap), and the Rx (in the cockpit) which is inside a indicator,  both Rotors are driven in parrallel. So when the flap is moved, the changes on the 3 Stators windings are impressed from the Tx, to the Rx and if by magic the needle in the indicator moves with the flap.
I will not bore you with the math behind this, but this is a question?

What would happen if you put on the 3 Stators, a 400hz, 3 phase, that is each one of the phase are 120 degress apart, sine wave???

But wait, what about the rotor?? Ok that's the key. Remember what we did with that alternator? We do the same thing here. But we don't have to spin the syncrho, we spin it, or move it electrically!

Digital Resolution of Angular Displacement
Bitsn2 Degrees BAM

Remember those 3 phases that you put on the Stators well if we call the unshifted signal the reference and you apply it also to the Rotor winding. Your indicator should point to 0. Ok so far?
Now if you phase shift the signal 90 degrees on the Rotor winding your indicator should move to 90 degrees.

Wow this is simple shit, right?

Lets get down to business. You can see a  with your eyes about a ½ degree movement. Don't believe me look at your analog watch's second hand. 1 second is 1/60 of a circle.  So you need about 1/10 of a degree so the indicator will float. So by checking the table you will see you only need 12 bits of resolution. I have also indicated a column for 16 bit BAM, as they are much easier to deal with, than degrees. And I don't have to use the Trig functions. To understand how to calculate the BAM please look at the link below. One more thing about a BAM it only represents part of a circle.  I know I hear the question but we only need 12 bits so why use 16 and through away 4 bits? Well remember the is a computer and it likes things in 8 bit chunks, so getting a 16 bits on a 32 bit embedded CPU is no problem.

Here are two 16 bit functions, I wrote them as that you will need:

#define TO_BAMS16(x)    (((x)/360.0) * 65536)
#define TO_DEGS16(b)    (((b)/65536.0) * 360)

**you will notice that I wrote them as a #define and I let the preprossor take care of it, rather than making them a formal function, that way I can avoid the call and return time. You will also notice the 16 at the end of the name, as I also have 32 versions of the functions.The 16 bit version is fine for the instruments  but with the 32 bit version, I can resolve down to a postage stamp size any where in the world!.




Keep Tuned In More To Come

Cris H~





NexGen Flight Simulator Blog Index

G-1981.JPGRemember when I was talking about Protocols and the RSS? Well then this will fit right in.


The Analysis: First we have to find all of the I/O in the Gables G-1981 ATC Transponder Panel and find out what they do. First a little background about ATC Transponders:

"is an electronic device that produces a response when it receives a radio-frequency interrogation. Aircraft have transponders to assist in identifying them on radar. Air traffic control towers use the term squawk when they are assigning an aircraft a transponder code,  Squawk 7421"


The code is 4 octal numbers. What's octal? Octal is 0 through 7 coded in 3 bits. So 4 octal numbers = 12 bits.

Function SwitchPositionsBits
Function Switch42
Mode Switch42
ATC TR Switch21
Test / Monitor Switch32
ALT Switch33
Code Switches x 47 x 412
Panel Lamps

Dial Lamps

Monitor Lamp

Total Bits Needed:23

So now we have all of the outputs.

The inputs are much easier you only have: panel lamps, dial lamps, and the Monitor lamp.


The Plan: is really two parts:

Plan what embedded microprocessor to use. And for a change its really a no brainier. I am going to use a Arduino Mega as it has lots of I/O.

A) Design both sides of the protocol.

The output of the Arduino is 23 packed bits, +1 bit for packing  giving me 3 packed Bytes plus house keeping of 1 Start Byte, plus one Radio_ID Byte, making the total of 5 Bytes.

A.1) Write to Arduino to the IOP.

A.2) Write from the IOP to the Arduino

A.3) Write the Linux driver in the IOP

A.4) Write the Linux IOP to the Arduino.

B) Test in stages.

B.1) Use the serial monitor to see outbound traffic from the Arduino

B.2) All of the ATC head inputs must come from the Interface Card as it requires 5vdc for the various lamps.

B.3) Make sure that the ATC Transponder does not need to be hacked. If so note it and fix it.

B.4) Now I can build the I/O Cable.

B.5) Install into the RSS and verify that every switch is functioning properly.

C) Go Flying!


Keep Tuned In More To Come

Cris H~


BTW I wish to thank the folks a Gables Engineering for there great support and documentation of the various control heads that we are using.


NexGen Flight Simulator Blog Index

Gees, Last month I sent in an entry to the "Why is it Great to be an Engineer?" So I entered the old tale of the conversation that God and the Devil had one day, and it goes like this, to my recollection:


One day God called up the Devil, and asked what was going on down there?

The Devil replied: "We got this engineer and he put in central air, flush toilets, and elevators".

And then God said: "And just where did you get this engineer?"

The Devil replied promptly:"In the last shipment of course."

God then said: "It was a mistake send him back right away."

The Devil said after a minute: "Nah, we like him down here, he is going to stay!"

God then retorted: "Send him back or I'll sue!"

The the Devil retorted: "And just where are you going to get a lawyer?!"


Would you beleave I got this email the other day:


Cristina Harrison,


You’re one of the winners of our “Why is it Great to be an Engineer?” blogging contest!  You’ve won a Microchip chipKIT EDU Bundle! Would you mind if we post your user-name on our Element14 Community?  And, would you please share a shipping address with us so we can send you your prize?  Send your contact information to: Thank-you!

Ken Kaminski, Marketing Manager
Newark element14




Cris H.



UPDATE 17Apr13 I just got the dev kit! Now I just have to find something to use it for! CAH

For the past few years, hey its been more like a decade. I have been working on an experimental aircraft the Phoenix2000 which was to have flown in, yup you guessed it, thirteen years ago. Well we can all dream a little. In my currently reduced circumstances I can not build the airframe, hey there is only so much crap you can get into a two bedroom apartment. So a few years ago I decided to write a simulation of the aircraft. As it turns out building the plane is much easier than getting all the software correct. And since this is a FBW that is FLY BY WIRE ie no cables from the controls to the surfaces, the software MUST BE RIGHT! Well so I wanted to build a repository for all my documents, part numbers, drawings, etc. so that people could comment on my work.

Most of my software is PROPRIETARY, but the APIs are PUBLIC. I will release software only via the SUN MICROSYSTEMS Licence, and with the proper NON-DISCLOSURE AGREEMENT in place. Also let me say this: This is not for Microsoft Windows© This system will only run under UNIX / Linux, so please don't ask for a Windows distro.


To this end I have published parts of the invtory system.



Keep Tuned In More To Come

Cris H~

If you can remember last time I said that I would describe the Control program running on the Linux box. Well its rather simple once you understand the signal(2) command. This is the mechanism which receives the interrupt and then sends it the right handler or function.


This diagram is a simplified block diagram of RadioControl running on the LinuxPc.


So lets assume that the pilot changed the frequency on the Radio #2 on that Gables head.

DATA TO RadioControl from the Slave

  • The Slave will send a 5 byte stream.
  • The first byte is 0xFF as to tell the HOST that a message is ready.
  • The second byte's first nibble is the 'helper' to that tells RadioControl which of the RadioControl_xxx programs to send the packet to.  So now the RSS has the information so what is it going to do with it.

DATA TO Simulation Possessor FROM RSS.

DATA TO RSS FROM Simulation Possessor


    • It could do nothing but ACK this transmission and then the RSS would run as if every thing is normal
    • Then the RSS would have to calculate the Slant-Range and update the required instruments.
    • If the audio is on or not the Morse Code Generator will have to pump out the stations ID (if required)
    • The Host will also have to send DME (miles) + TO/FROM flag.


    • It could say that the radio is dead. (fault) and tell the RSS to change the flags.
    • It could say that the radio power circuit breaker is blown.  (fault) and tell the RSS to change the flags.


Pease Note. That calculation of the Slant-Range, along with the station ID is part of a FAA Database look up, and or knowing where the aircraft is part of the RSS NAVGROUP network listener.


Keep Tuned in More To Come

Cris H~