Although interfacing in general terms has been mentioned several times before, it is presented in a bit more detail here specifically in the context of these instrument projects.

Buy Someone Else's Hardware & Driver.

The instrument/gauge projects have been designed and built with one of two basic premises in mind.  The first is perhaps the easiest, but likely to be the more expensive.  It bases the interface on an analog control voltage and supposes the existence of some sort of analog output device like an EPIC gauge card.  This has the advantage that the interfacing issues have already been addressed and solved.  The hardware's there, the driver has been written, but the cost is high.

Build Your Own.

The other approach, which MAY be less expensive, is to use a serial port and write the interface software.  Whether it is indeed less expensive depends upon one's skills and available tools.  Without some programming knowledge and a compiler, it is probably fair to add at least a portion of the cost in time and cash in acquiring them to the total project cost.  For some, then, the code-it-yourself approach may be the more costly.

Learn a Little About Programming Windows.

Even starting from scratch, doing it yourself is not an insurmountable task. You don't need to be a wizard, only a moderately successful novice.  You'll need a basic knowledge of Windows, and some programming skills.  All the reference material is online care of Microsoft in the MSDN library.  Personally though, I'm simply not ready for the true paperless office and greatly prefer books.  Pretzold's Programming Windows and/or Schildt's Windows 98 Programming provide an adequate grounding in Windows.  For these projects, you don't really need to worry about differences between the different Windows operating systems.  The portion of the programming interface to Windows (the "Win32 API") that you will use is the same.

Although I have been given to understand that Visual Basic will work, I know for a fact that Visual C++ will, and much prefer it.  FS is written in C/C++, the examples in the Windows books are in C/C++ and the FS SDKs use C/C++.  The most recent standard MS VC++ compiler (the .NET version) is available for about $100US.  The professional version is only about $20US more.  You might also look at the somewhat restricted, student version which is less expensive and comes with a textbook.  Earlier versions of MSVC++ can probably be picked up for much less and will work just as well. (I'm using version 5).  

You don't have to use the Microsoft product, but if you are a novice there are advantages to doing so.  You'll be using a Microsoft compiler on a Microsoft platform to interface to a Microsoft game, and will be much less likely to run into compatibility issues. 

Talking With MSFS: the Panels SDK.

Having made the investment in software tools and knowledge, there are (at least) two viable approaches to gaining access to MSFS internal variables.  The first is to make use of proxy variables set up by the Microsoft Flight Sim team in support of the gauge and panel module.  These may be thought of as calls that return internal state information, such as speed and altitude.  There are a great many proxy variables, and you will find documentation on them in the panels SDK available as a free download from the MSFS2K2 web site.  Essentially you would write code for a custom gauge that makes calls for all the variables needed for your sim instruments, and transmits suitably scaled values to them.

This is a workable approach and has been successfully used, judging by posts on simulator forums.  There are a few shortcomings to consider, however.  Microsoft made significant changes in the panels module between FS2K and FS2K2.  An interface module developed for one likely will not function with the other.  Another issue is that this approach is a lot of work.  You will have to learn quite a bit about the structure of MSFS.  Doable, but time consuming.  Perhaps the biggest issue is that this is fundamentally a read only technique.  It does not provide a method for communicating values back into MSFS.  So switching frequencies on NAV/COM gear and turning OBS knobs will need another approach to become functionally connected.  Fortunately, the second approach addresses all of these issues.

Talking with MSFS: FSConnect.

Russel Dirks has produced a DLL that makes use of the Microsoft functions referred to in the Panels & Gauges SDK. The module is called FSConnect and is available as a free download from both the Avsim and Flightsim libraries. The download includes documentation and sample C and VB code along with the executable.

Talking With MSFS: FSUIPC.

Several years ago Adam Szofran developed an inter-process communication module called FS6IPC.  This is a DLL that becomes a part of the FS process when placed in the Modules folder of MSFS.  Szofran has moved on, but FS6IPC continues to grow.  Pete Dowson has picked up the development and support of this DLL, which is now called FSUIPC.

FSUIPC is perhaps best known for its functionality in modifying MSFS weather, mapping buttons and keys, and providing superior joystick assignment and calibration.  It also provides an easily accessible method of reading many and writing a few of MSFS internal variables.

Utilizing the I/O functionality of FSUIPC is made straightforward through use of a small chunk of code called FSUIPC_User.lib.  One simply links to this lib when compiling.  It provides five calls.  Two are used to open and close FSUIPC.  One is a request to queue a read.  Another is a request to queue a write.  The final call requests that the queued reads and writes be processed.

The specific variables in question (heading, altitude, etc.) are identified by "offsets" which were at one time indeed offsets in a large area in memory.  As MSFS has evolved, this utilization of memory has changed and variables are rather more dispersed.  As a part of his continuing support of FSUIPC, Dowson has configured it to fetch the variables from their new locations while maintaining the same user interface based on what are now often virtual offsets.  

The variables and their corresponding "offsets" are documented in "FSUIPC for Programmers (and Adventure Writers)", part of the FSUIPC SDK.  FSUIPC, the SDK and code examples, are available through Enrico Schiratti's site for a modest licensing fee.

Talking with the Hardware: The Serial Port.

If you're fairly new to writing code under Windows, you may have some confusion regarding using the serial port.  Many of the examples found online simply access the physical registers for the port and bang away.  This approach is dated, and does not work well under Windows.  For a variety of reasons (system stability being one) users are insulated from the hardware.  This abstraction of the hardware simply means you have to use the appropriate calls to the Win32 API.

The Win32 API makes the serial port look like a special type of file, so step one is to open the port using CreateFile().  CreateFile() returns a handle used to identify the port in subsequent API calls.  Although this call includes a few fields that partially configure the port, there are two important additional configuration steps to be taken.  The device configuration block (DCB) for the port should be created and loaded to set the baud rate, parity and number of bits options. Secondly, the CommTimeouts structure must be set as well.  In the absence of these two steps you are at the mercy of system defaults or the values leftover from the previous use of the port, and your code will behave unpredictably.  

Once configured, move data through the serial port utilizing ReadFile() and WriteFile().  As the serial port is much slower than the processor, you might want to consider isolating these two calls inside a separate thread.

Data should be sent to flight instruments several times a second.  Engine gauges can be serviced somewhat less frequently depending on type.  Fuel gauges tend to change slowly so can be updated at longer intervals while the potentially more rapidly changing tachometer needs a bit more frequent attention.  The Windows timer is a good utility to use for activating your code on a periodic basis.  Use the SetTimer() API call to tell Windows to send your code a wake up message (technically a WM_TIMER Windows message) every so often.

Get details on these Win32 API calls from the online Microsoft MSDN library.

Just Briefly, A Few Other Options.

Other Sims:

MSFS is not the only sim that allows access to internal data.  Falcon 4.0 data can be accessed through use of a program called Memreader.  See Martin Ingold's site for information.

X-Plane is another simulator you can peek inside.  See the "Hacking X-plane" section of the X-Plane site for information.

Other I/O Options:

The serial port is not the only method in and out of your computer.  While I am not a great fan of building hardware and software for what looks like a legacy port, you should be aware of the possibility of using the parallel port.  Although OS support of this port is fading in favor of USB, the parallel port is fast, easy to connect to hardware-wise, and freeware code exists that allows your program to access it.  A bit more information is available here.

USB is probably the interfacing avenue of the future for these simulated instrument projects.  The serial port has been used because it is so cheap and easy, and because there is an upgrade path utilizing the FTDI serial-to-USB chip and driver.  Still there is a small but growing number of micro controllers that incorporate a USB interface (Cypress Semiconductor,  Microchip, etc.), as well as some small board products such as the Gigatechnology USB I/O 24.  These are worth keeping an eye on.  More information on USB here.

You may already have multiple computers networked in support of your simpit.  Even if you don't, you almost certainly have a network card installed.  Winsock, the windows version of the network sockets library, is probably already on your system (or system disk).  There are a number of vendors offering development kits to "web-ify" virtually everything, and prices are reasonable. Given all this, plus the fact that it is fast, Ethernet is clearly a viable I/O candidate.  More information on Ethernet interfacing here.

It's possible that I'm not as smart as I think I am. (Occasionally, I have moments when I know this to be true. Fortunately the feeling passes quickly.) Although I have tried to make this information as accurate as I can, it is not only possible, but also quite likely, that errors lurk within. I cannot and do not warrant these pages to be error free and correct. Further I accept no liability for the use of this information (or misinformation). If, after reading this, you are still interested, please be aware that the contents of this site are protected by copyright (copyright © 2002, 2003, 2004, 2005, 2006, 2007, 2008 by John M. Powell). Nonetheless, you may copy this material subject to these three conditions: (1) the copyright notice is copied and presented along with the material, (2) the copy is used for non-commercial purposes, and (3) the source of the material is properly credited. And of course, you may link to this page.