using an inexpensive microcontroller to interface hardware with DCS

after viewing all the posts related to cockpit building I notice a large gap in what technology will be used to make all the panels "work" with DCS. I have been experimenting with Opencockpits.org's IOcards and while they were very flexible the lack of current docs and the cost importing to the US became a large hindrance. Being an enthusiast of micro controllers (uC) I started looking into how difficult it would be to replace the IOCards gear with my own home grown solution.

In order to make real components work you really only need to implement a few basic things:

multiple switches

multiple 7 segment displays

multiple encoders

multiple character based displays

how to get data from the uC to the sim

how to get data from the sim to the uC.

I figured for an initial proof of concept i would start with the Tacan display as it has displays (outputs) and encoders(inputs)

I have implemented a single rotary encoder with two 7 segment displays to interface with the tacan 10s digit control and display in the sim. After a few days of working on this in my spare time i got it to work. A schematic of the poc hardware follows.

I have attached a schematic of the diagram that shows the hardware side of things. I will post a video of it working and more details. Sorry if it appears that I am rambling as i have so much info to convey and not sure how much interest people may have and how detailed to get.

My plans are to get all the basic components to work and then to go down two paths.

1. go the opencockpits like route and produce specs and hardware for "primitive" types (e.g a display controller, a switch controller,etc)

2. create unique specs and hardware for "plug and play" types of components (e.g. a tacan,a cdu,etc)

please let me know if anybody is interested in this as i can go a detailed as you like, just ask

Will

Overview: how to get data from the uC to the Sim

from a high level this is pretty simple. The data flows as follows:

uC>>Computer>>Sim.

From the uC to the computer:

currently im using integrated serial over USB for the communication from the uC to the Computer. the data currently flows in 1byte messages. This can easilly be sent from the uC without any problems. each message byte is different depending on the device being controlled. example the rotary encoder has a possible 7 high bits for an address and one low bit for increment up or increment down. A 0 means increment down. A 1 means increment up. e.g 00010101 means encoder 5 incremented up 1 step. This message is written out via the serial port. The computer basically listens for the message on the defined com port and decodes the address and the value.

From the computer to the sim:

This part is probably what everyone is the most familiar with. I wrote a udp client/server in python that takes the message above and just sends a command to the sim. In order to make this simple I used the format that Helios uses. The software looks for addresses that it cares about and when a message comes in on the associated com port it takes the value and creates a string based on the address then sends it to the sim via udp.

A couple pointers as I've been doing the same thing recently.

The main problem is interfacing to the computer, getting a micro-controller to read and control these items is pretty easy. The ATMEGA chip you have has Serial IO, which can be brought to the computer via a USB->Serial controller but that get's unmanageable when you realize that you have approximately 25 panels which will need serial ports (actually you'll need more micro-controllers or a lot more circuitry as well since each ATMEGA only has approx. 16 IO pins per chip.) For reference it will take over 100 IO pins for the front panel alone to drive all the switches, LEDs, and stepper motors for a physical pit.

You'll either have to switch to a USB chip or come up with a panel to panel bus structure with a master interface card. Unfortunately both those are a little troublesome with the ATMEGA chips. The only USB capable ATMEGA controllers are surface mount components. I hate the fact that PIC requires you to buy a compiler to program the chips your buying from them unless you want to write assembly. I'm also looking into VUSB which is a software implementation of low speed USB using a raw ATMEGA chip to bridge to a RS-485 bus between boards.

Second you need to deal with power management. LEDs take up to 20ma each and you'll need ALOT of them especially if you are backlighting your panels. That can eat up power quick and you'll need to deal with expensive switching voltage regulators, or have a dedicated power source just for your LEDs. Regular linear voltage regulators get REALLY hot quickly if you are down stepping 100ma. I was planning on running a 12volt bus for everything for simplicity since my LCDs run off it, but I'm back tracking to dual regulator power supply 5v and 12v.

Third figure out how to deal with IO expanders check out the MCP23017 chips. This will let you read many more inputs with one micro-controller. There are higher speed serial ones but they take more IO pins to drive.

I have the circuit for a 32 input, 1 stepper out, 16 dimmable led out board I'll post in a bit.

Serial controller but that get's unmanageable when you realize that you have approximately 25 panels which will need serial ports (actually you'll need more micro-controllers or a lot more circuitry as well since each ATMEGA only has approx. 16 IO pins per chip.)

That is why im on the fence with either doing dedicated "plug and play" devices for each panel or just doing what OC did and have generic cards. With the generic cards you can get a much higher density since they only do one thing.

Also on the board of todo's is the 32u4 which has built in USB

Second you need to deal with power management. LEDs take up to 20ma each and you'll need ALOT of them especially if you are backlighting your panels. That can eat up power quick and you'll need to deal with expensive switching voltage regulators, or have a dedicated power source just for your LEDs. Regular linear voltage regulators get REALLY hot quickly if you are down stepping 100ma. I was planning on running a 12volt bus for everything for simplicity since my LCDs run off it, but I'm back tracking to dual regulator power supply 5v and 12v.

for pwr management i plan on using a seperate bus for power. In my example since im running only two and the duty cycle is so low they only consume 4ma which is below the 40ma limit for the pin. Also plan on having back lighting on a separate bus as well

Third figure out how to deal with IO expanders check out the MCP23017 chips. This will let you read many more inputs with one micro-controller. There are higher speed serial ones but they take more IO pins to drive.

already working on serial/parallel shift registers and some interrupt enabled expanders

i plan on using 74HC595s for multiplexing leds. Should be able to get 4-5 7segments on each one of those and use another 595 for multiplexing the commons but im still investigating that. If that works well i should be able to drive 8 seven seg displays easily with 3 74hc595s and only using aprox 6 pins.

I will look into the MCPs as they could be more appropriate than the ones i currently have

With regards to surface mount im not too afraid of that...used to do it when i was an avionics tech in the military

I have the circuit for a 32 input, 1 stepper out, 16 dimmable led out board I'll post in a bit.

I would love to check it out and am open to any collaboration. I also noticed that Helios was opened up a but and was thinking of speaking with you about using it as the integration point. No sense reinventing the wheel.

one more thing...its ugly but a pc can accommodate 25 virtual com ports (I have no plans to go that route though)

I'd be interested in starting up a group project on this. The PHCC seems to have died out and I'd really really like a modular system where we only have to run a few wires between panels. PHCCC needed two or three levels of break out boards to work.

I'd be interested in starting up a group project on this. The PHCC seems to have died out and I'd really really like a modular system where we only have to run a few wires between panels. PHCCC needed two or three levels of break out boards to work.

just say the word and ill be down for it

Overview: how to get data from the Sim to the uC

this is basically the opposite of the uC to sim overview except the data flow is reversed:

Sim>>Computer>>uC

From the Sim to the Computer:

Once again this is the part most people are familiar with. I will not go into details on configuring the export.lua as that is well documented. In my example case i am exporting the Tacan displays from the sim to the computer. The export.lua sends this data via UDP (im using the default helios export) to a udp listener on the computer. In my case im using python. The python script once again listens for data via udp with an address that it cares about.

From the Computer to the uC:

The listener program above does the opposite of what it did when receiving data from the uC. It takes the message from the sim and converts it to a message the uC will understand.

In my example the data format for LCDs is the high nibble is the address of the display and the low nibble is the value to be displayed. The udp script then sends out this byte to the uC on the appropriate port. The uC is listening for messages on the port and when one is received it sets the appropriate display to the appropriate value.

About the uC:

in the case of the 7 segment displays the uC firmware has an array of 10 bytes that correspond to lighting 0-9 on the display. the value received can be 0-16 as we are using 4 bits (but currently only implements 10). Since the array holding the display patterns is indexed 0-9 its just a matter of setting the segment pins of the display to the appropriate value. once that is done the display is quickly turned on ...then turned off. then the steps are repeated for each display. This is an example of miltiplexing the displays as each uses the same segments but are turned on and off at different intervals ( so fast you cant see it). this is suitable for this poc but in future iterations I will use hardware based multiplexing to reduce pin counts and control current draw from the displays

I'm currently doing something very similar with an Xilinx FPGA.

http://forums.eagle.ru/showthread.php?t=73075

In regards to limitations of IO ports, have you considered multiplexing all SimPit switches into the chip. Sure this would require several MUX chips and output selection signal and logic high to each switch, but integrating the deMUX is surely easier then using multiple uC's

Me too, :) I have been using the ATmega and the 74hc595's to drive some leds based on the fact that they are _dirt_ cheap.

I was also thinking of a master/slave arrangement but for my own purposes it was going to be the master that handled the comms to the PC and slaves while each slave was more or less dedicated to a single panel, e.g. cdu, ufc, am radio, fm radio etc.

I am now just waiting for Gadroc to talk more about how he is going to open up helios to this sort of thing :) I have done the software for interfacing to dcs in the past but I also run helios and it seems like a good thing if I can keep it all together in one export.

I'm working on it. I've sorted some of the new rendering engine issues. Next up is getting the network eventing system in place and then I'll start some sandcastle for the API docs.

Yeah, I have some work of my own to do before things are ready to hookup anyway.

Than after the electronics are done I have to jump over to the cnc and machines to get the enclosures made. So, I wont be done tomorrow :)

sandcastle for the API docs.

I got no idea what you mean by that, LOL

I don't know to much about HELIOS or outputting data from DCS KA-50 but it dose interest me. Ideally I would like a small command prompt window, either as an alt tab solution or use a second monitor input and just change back and forth from DVI to VGA input, to push all switch states out to the micro controller (FPGA) and run a diagnostics to make sure the SimPit switches are identical to KA-50 at mission load.

The hardware is the easy part for me, I'm an electronic and computer systems Engineer, and we used VHDL on Xilinx chips more many projects, shift registers, MUX's, ALU's, and CPU's. I also know a bit of C# and C++ but it's not my specialty. So if you have trouble with Integrated Circuit design I'm willing to help.

I plan on using a series MUX's from all SimPit switch states on one PCB and serial port with the data line, MUX select, and logic high, and clcok from the FPGA. The FPGA will be an integrated deMUX and higher level of keyboard drivers. MUX states will be buffered and only data sent to windows when any bit of the latched buffer changes. The latched bit will be transcribed to ASCI and sent to windows looking like various keyboard key presses (not a constant key press).

But I would love to hear about you helios data output from KA-50 so that i can run a diagnostic switch state check at mission load.

Jasper, I think you should keep an eye out around the helios forums for this discussion although it hasnt started as of yet.

I don't think you want your hardware to look like a keyboard as it is too limiting. DCS can map a lot of things but they dont always work and it's only one way communication in to the application with no feedback.

The DCS products have fairly good ways to export the aircraft information and helios has already implemented that. What Gadroc is going to do is create a specification to get that information from helios in to our hardware systems and vice versa.

This will save you having to do all the integration in to the game or any other future games that helios will support.

I am interested in something you said, or at least its implication 'o push all switch states out to the micro controller (FPGA) and run a diagnostics to make sure the SimPit switches are identical to KA-50 at mission load. '

Thinking about it now, you probably mean to put the game in the state of your physical switches, if you mean the other way around I would like to know your source of reasonably priced switches that can have their positions flipped, that would be the ultimate. Load up DCS and see half a dozen of my physical switches flip in to the correct position :) $$$ :)

Gadroc, I dont know what you mean by that either? Are you planning to implement an sdk layer that runs inside a sandbox you you need to finish that before publishing the docs?

Sorry. Sandcastle is a tool which generates the API documentation from my code comments. If you've ever looked at the MSDN documetation for the .net library, its the tool the generates that.

Dont you need sleep? I am not sure if you haven't got to bed yet or if you are getting up early :)

push all switch states out to the micro controller (FPGA) and run a diagnostics to make sure the SimPit switches are identical to KA-50 at mission load.

Let me explain this a little better, I think you misunderstood me.

What I'm planning is a program to run in the background to DCS. It will run once, only at the start of a new mission loading. Each of the physical switch positions will have a unique bit code. And when the microchip gets the aircraft switch positions from DCS, not sure how yet, the buffer (register) on the microchip for switch positions will compare the data to that of the data pushed from DCS to check what state each switch is in.

I think you understand the correctly.

Now when DCS's push data dose NOT match the physical SimPit switch configuration. Say you complete a mission and shutdown the aircraft completely so it is dark, but the next mission you load the communications is on and engines in idle. You alt tab to the background program and it pauses, and names the switch that is not in the correct state, even a image of the cockpit with the unsynchronised switch in a highlighted displayed so that you can change it. The switches are NOT automatic. The background program just helps you synchronise the physical SimPit to what the DCS has loaded for the mission. Once everything is sunchronised, the background program either closes or stays open for the next mission load, after outputting that the system is synchronised.

I never considered making them automatic, I don't even know if a switch like that is possible. But I do like where you took my idea. I imagine if they exist they would be expensive and large, as they would need some kind of mechanical mechanism. But I will do some research as cost analysis.

The way i originally planned would also help you member where whats switches are, because I'm nowhere near starting a dark chopper in 30 seconds.

This is the board i plan on using:

AES-S6MB-LX9-G

It has 12 IO pins to control the CLK, MUX select, Logic High out, Data In, and any other stuff like you 7 seg display and LEDs.

The MUX chips to get all switch states and a PCB's will be daisey chained to the FPGA IO ports.

CD74HC4067

That seems like a pretty hefty chip to do some simple interfacing with, especially as you will need to either get more of them or plenty of other ic's to expand it's input/output capabilities.

Thats the nice thing with the atmel avr's I am using, they are cheap ~$6USD so I can throw one on each board I do, i.e. radio, cdu, ufc etc without breaking the bank.

I am still looking at how I may do some of the input/output but it will probably use a number of shift registers in serial to minimise pin usage and then whatever works after that with either multi digit led segment drivers or individual ones depending on features like built in PWM for brightness etc..

This has really got me in the hacking frame of mind right now lol so I am gutted my oscilloscope has gone MIA as I was about to go all rambo with ideas :)

I was going to start with something else but I now think I might get a radio working, it's simple and gets me to make up my mind on the displays. If I decide soon I can get an order in for some parts to arrive for the weekend and get something going.

That seems like a pretty hefty chip to do some simple interfacing with, especially as you will need to either get more of them or plenty of other ic's to expand it's input/output capabilities.

IT's CALLED MULTIPLEXING - each data input uses the same circuit line and active for (1/n) of the CLK frquency for "n" inputs.

have another look. I don't need more of them, just a few MUX chips.

The FPGA is like a master to interface with the PC, and there will only be ONE data line in as all the switches will be multiplexed with select lines controlled by the FPGA.

As for your input/output shift registers can be integrated onto the FPGA with some VHDL code. So controlling a seven segment display with this FPGA is an option too, just add a MUX line out the the display for serial data and enable the output after all bits are loaded onto the 7 seg display bit register.

hope you understand, i really should be be doing my uni work and not playing with these toys. I plan on putting a PDF together to show the schematics.

Q: Do you know how many unique switch states there are in the DCS KA-50 cockpit? i read it some where but can;t find it agian.

Hi Jasper, yes I am aware of how you will need to do it, I think I said it in that sentence you quoted - by adding additional ic's to increase it's IO.

At some point that get's messy though, especially if you are trying to hang a full pit off a few io lines at the fpga. I dont know what you are doing though, it may only be a handful of buttons, no gauges etc.

Apart from how you write the logic for the fpga the rest of the design will look similar to anything using a mcu, you may use shift registers, 7segment driver ic's, additonal pwm ic''s etc so I get all that.

I just thought that it was a bit overkill for monitoring switches :) buy hey, if thats what you want to do and using them is probably part of your current course material then why not? It sure doesn't hurt and I am interested in your progress.

Soz bro, I hope what i said didn't sound arrogant.

I'll probably need about a dozen MUX's and chain them through out the pit.

As I'm planning on using 46" monitors I'm going to use the gauges displayed on them, and fix switch panels around the seat and over the monitor switch display, will also disable head bob.

Also I plan on using hte PFGA for other home projects so I don't mind the extra cost for it

Jasper,

The point is FPGAs are WAY overkill to use just to mux a bunch of digital i/o channels. That board is $90 for still having to add several IO Expander chips to. You can do the EXACT same thing with a ATMega or PIC chip based board for 1/3 of the cost.

In addition for LED outputs you'll have to be very careful about power management to not run a huge amount of current through the system.

Soz bro, I hope what i said didn't sound arrogant.

 

I'll probably need about a dozen MUX's and chain them through out the pit.

 

As I'm planning on using 46" monitors I'm going to use the gauges displayed on them, and fix switch panels around the seat and over the monitor switch display, will also disable head bob.

 

 

Also I plan on using hte PFGA for other home projects so I don't mind the extra cost for it

Your board wont support 12 of those CD74HC4067's

They dont support spi or i2c so you need to give each one 4 lines which is 3 boards. They are not feed serially with a latch pin either so I am not sure how you can daisy chain them to get 12?

Unless you are going to say you will hang one off the fpga, then 4 off that, then... dont say youre going to do that :)

Q: what makes a good KA-50 SimPit with todays options?

Mano posted this, looks good.

for I/O card look at this:

http://www.poscope.com/search.php?q=PoKeys55-T

 

I've bought it and I'm successfully using it for PVI-800 keyboard, Datalink overhead panel and ABRIS commands.

Actually I'm interfacing with 25 momentary pushbuttons (PVI-800) + 13 (Datalink) + 5 (ABRIS) + 2 Encoder (ABRIS rotaries) and 1 2-pos switch (ABRIS On-Off).

All this with only one board.

 

Actually I don't know if you can use it for outputs too, but it can be programmed (has C libraries) so I think there could be some ways to let her communicate with the sim.

 

Inputs are arranged in a matrix, except for the 2 encoders that require individual channels (2 per encoder + GND).

I'm planning now to add the weapon mode panel (left panel), autopilot commands and UV-26.

 

The board can manage an LCD display too (and 2 LED block matrix displays). I've successfully lighted up an LCD 16x2 but I didn't get into it very much because I'm not a programmer and I couldn't program it.

 

I think that with 2 of these boards you can easily have a very immersive cockpit.

Now, with the 3 panels I've built + my Saitek X52PRO (fully configured with 2 modes) I don't have to touch my keyboard.

 

good luck!

Also these guys if you a looking at that type of interface

http://www.u-hid.com/home/overview_board.php