Major Announcement: New software to to connect panels to DCS

[FSFIan]

Guys

 

Is DCS-Bios capable of displaying the CMSP output data onto a 20X2 transflective STN LCD

 

Yes.

[avidflyer]

Hi,

 

i checked Ian Bios with a Leonardo pro micro and it worked also.

[CodeToad]

Guys

 

Is DCS-Bios capable of displaying the CMSP output data onto a 20X2 transflective STN LCD or will I have to bin it and go with a viewport.? I am trying to do a proof of concept wiring diagram using an arduino mega before I start any soldering. Cheers

 

Don't see why not - as long as you have the code to drive the display from the Arduino.

Here are a couple of potentially useful Arduino libraries to drive character displays:

 

LiquidCrystal I have used this one, for the displays that commonly use the HD44780 chipset

LCDi2c for serial i2c displays

 

If you are new to character displays, you may find this general tutorial from Adafruit NYC about hooking them up to Arduinos useful.

 

Beyond that, connecting up to DCS BIOS is trivially easy thanks to Ian and you will find instructions for that both in his documentation and in this thread.

[weeb]

Don't see why not - as long as you have the code to drive the display from the Arduino.

Here are a couple of potentially useful Arduino libraries to drive character displays:

 

LiquidCrystal I have used this one, for the displays that commonly use the HD44780 chipset

LCDi2c for serial i2c displays

 

If you are new to character displays, you may find this general tutorial from Adafruit NYC about hooking them up to Arduinos useful.

 

Beyond that, connecting up to DCS BIOS is trivially easy thanks to Ian and you will find instructions for that both in his documentation and in this thread.

 

 

Cheers for that codetoad. I'm meticulously anal about drawing proof of concept diagrams and getting it all working on developer boards before I start soldering and cutting instrument panels. I can't help it, it's just who I am. Means that once I have it sussed I can post a step by step for others. I am sure there would be more cockpit builders if peeps would just take that jump into the unknown. If you are not going for a 1:1 replica of a pit, it's cheap as chips to grab a pile of components from Asia. As I have found, electronic circuits are not a problem for me, but coding is, it's totally alien to me. :thumbup:

[G00dnight]

LCD's in DCS-BIOS, sorry for camera phone.

http://vid59.photobucket.com/albums/g316/frapattack/NUMBER1/Cockpit_LCD.mp4

[Felm]

that's awesome goodnight, great job!

 

things are coming along nicely on my end as well. code for chained 74hc165 is done (no extern global variables). I tested it with 4 chips, i'll try with 8+ today to see if theres any issues. then i'll do chained max7219s and then give a shot to the cd4051 multiplexers for analog inputs.

[ArturDCS]

Anyone tried the COM handler program? Worky worky or not?

[avidflyer]

Hello,

 

I trieded the COM Handler with a quick steup and it worked!

My stepup was like that:

Micro Leonardo board with 1 LED for Gear up indication

Arduino Uno with 1 LED Left Gear down indication

I trieded it for a couple of minutes and toggled between up and down and it worked without any failures.

So now I dont have to run multiple copies of the bios COM Connector which comes with the DCS BIOS.

Some Questions:

1. Atrur can I use this also via LAN? (there is an exe which indicate the possibility)

2. Can some help with connection of multiple Arduinos via a USB HUB?

Every time I connect the Arduinos via the Hub I cant load a sketch on them.

I checked the ports and choose for each the right one but no loading possible.

 

kind regards

[ArturDCS]

Hello,

 

I trieded the COM Handler with a quick steup and it worked!

Nice! :thumbup:

 

1. Atrur can I use this also via LAN? (there is an exe which indicate the possibility)

I think so. You can configure DCS-BIOS with different IPs and you can set the IP also in the COM handler program. So yes I guess.

 

:joystick:

[Puma]

Wiring alternatives

 

Promising software. Looks great for LCD outputs which I plan on doing next.

 

I was surprised not to see RotaryEncoder implementations of radio frequencies. Looks like your pit might have had physical digit displays. That's cool, but not an option for me.

 

Could that be implemented? I would be happy to do the coding if you point me in the right direction!

[Deadman]

I just wanted to say your all making making great progress sorting through all of this Thanks to all

[CodeToad]

Promising software. Looks great for LCD outputs which I plan on doing next.

 

I was surprised not to see RotaryEncoder implementations of radio frequencies. Looks like your pit might have had physical digit displays. That's cool, but not an option for me.

 

Could that be implemented? I would be happy to do the coding if you point me in the right direction!

 

I am just working on a radio panel (pretty ghetto compared to other panelists) and I'm happy to share my arduino code, although it is work in progress (but perhaps you find it useful for your experiments already)

 

I have it working with adafruit rotary encoders so far (24 step per rotation + push button) but I am also getting sparkfun encoders which have an RGB LED lit shaft/button.

 

 

 

The basic hookup and rotation detection is fairly trivial. For the adafruit encoder: Connect the center pin on the rotary side and one of the pins on the pushbutton side to ground.

The rotary side left and right pins are called A and B in the code below. The other pushbutton pin is called push. You can connect these directly to 3 digital pins on the Arduino. No need for pull up resistors since we use internal pullups (see lines with INPUT_PULLUP) This does mean the logic is inverted ie push button pressed == LOW

 

Anyway heres the Arduino code (for brevity this is generic rotary encoder sample not DCSBIOS specific yet but that will be easy extension given DCSBIOS clean design)

 

int value = 120; // init to whatever
const int pin_A = 2;
const int pin_B = 3;
const int push  = 4;
unsigned char encoder_A;
unsigned char encoder_B;
unsigned char encoder_A_prev = 0;

// http://www.hobbytronics.co.uk/arduino-tutorial6-rotary-encoder

void setup()  {
 pinMode(pin_A, INPUT_PULLUP);
 pinMode(pin_B, INPUT_PULLUP);
 pinMode(push,  INPUT_PULLUP);
 Serial.begin( 115000 );
}

void loop()
{
 encoder_A = digitalRead(pin_A);    // Read encoder pins
 encoder_B = digitalRead(pin_B);
 if ((!encoder_A) && (encoder_A_prev)) // A has gone from high to low
 {
   value += encoder_B ? 1 : -1;  // see diagram on linked page: B hi=red=clockwise, B lo=blue=ccw
   Serial.println( value );
 }
 encoder_A_prev = encoder_A;     // Store value of A for next time

 // push button on encoder resets (optional obviously)
 if ( digitalRead(push) == LOW )
   value = 0;
}

 

I have not personally needed debouncing capacitors between pin_A and ground and pin_B and ground respectively, but if you see a lot of "noise" while turning the knob, put a .1 uF (104 package) capacitor each there.

 

 

For my actual panel, I will get a little more advanced and use the RGB LEDs for feedback. I will try to get 3 rotaries (UHF, VHF FM, VHF AM) and one 16x2 or 20x4 LCD display . Just so all the analog tuning stuff in DCS can be done with physical twiddles instead of the somewhat tedious rotation mode onscreen.

 

I am also implementing a "push for menu" capability where menu selection might be something like

- Frequency

- Volume

- Preset

- Mode

with each having an integer, float or set of strings to choose from. While selecting the menu, the LED will light up in some color for feedback. You select a menu item by rotating the knob. With a push of the knob you pick the currently selected menu item and can change the value.

 

Functionally similar to

but much simpler code.

 

 

I am also implementing "turn acceleration" for large range, high precision variables like frequencies. Whereas in a real A-10 cockpit for example you might have multiple dials, for the various digits of a frequency, I want a single rotary encoder for each radio.

Slow turns will be high precision. Fast turns will move in much larger increments, allowing zipping from 80.0 Mhz to 103.5 Mhz for example while maintaining precision of 0.1 Mhz with slow turns. (Otherwise each turn would only yield 24 * 0.1 = 2.4 Mhz and that would get old fast)

 

 

That code I am still cleaning up and documenting (and wrapping into a object oriented library so you dont have to see the guts and can use multiple rotaries from a single arduino sketch)

I will post it here, probably next week as I am traveling this week/end.

 

 

References just in case you want different approaches (I ended up not needing Arduino interrupts or bounce delays etc. and I like to keep code as short as possible, but your mileage may vary):

• 
  
• http://www.hobbytronics.co.uk/arduino-tutorial6-rotary-encoder
  
• 
  
• http://dev.tetrastyle.net/2012/08/blog-post.html
  
• https://github.com/medecau/QuadEncoder
  

 

PS: the sparkfun encoder has 5 pins on the RGB LED side (R,G,B, pushbutton, ground) and these are NOT the standard 0.1" separation but around 0.08", so they will not plug into a breadboard or protoboard nor will female jumpers connect (too tight). Grrr. Sparkfun sells a breakout board, but it is so big, that it makes breadboarding hard (see comments section on their product page) Still the LED is nice for signalling and price is good.

[FSFIan]

I was surprised not to see RotaryEncoder implementations of radio frequencies.

 

Switch your reference documentation to "Advanced" view to see the RotaryEncoder code snippet.

 

The "Simple" view will try to guess the "most appropriate" input interface to use and hide all the other options. Most of the controls support the fixed_step interface ("DEC" and "INC" actions) that allows you to connect a rotary encoder even if it makes no sense at all (e.g. push buttons).

 

The reason CodeToad does it in a more complex way is because he wants to have advanced features like turn acceleration and menus. For the simple case where one step of the rotary will always result in the same command to the sim, DCS-BIOS has you covered.

 

Looks like your pit might have had physical digit displays. That's cool, but not an option for me.

 

I don't have a proper simpit ;) Don't have the time, money or space (dorm room) to build one right now. DCS-BIOS was created because I wanted to help WarHog using Arduino boards with DCS and I didn't like the existing approaches at the time for various reasons. I wanted an open-source implementation that had an export protocol efficient enough to export the complete cockpit state over one serial connection, hid away all DCS implementation details like argument numbers, and was documented well enough so others could use it.

[WildBillKelsoe]

Probably good idea to start with system overview for the lay person, like me.

[FSFIan]

Probably good idea to start with system overview for the lay person, like me.

 

Please post specific questions that you would expect such a system overview to answer.

"System overview" can mean many things, from a pretty useless diagram like this

Switches <--> Arduino Board <--> USB cable <--> DCS computer

to something that includes so much detail that you can only read it if you already know everything it might be able to tell you.

 

Also, by "start with a system overview" do you mean we should start writing one or do you mean specifically that the first chapter of the User Guide should be such a system overview?

 

We tried our best to make sure that the User Guide does not assume any prior programming knowledge and very little electronics knowledge. It is intended to take a lay person from where they are to their first functioning switch panel. If you still have questions after reading through that, please ask away -- it can be difficult to anticipate every possible newcomer question if you have designed the thing (in my case) or you have already used it for a while (WarHog).

[Puma]

Ian;2316784']Switch your reference documentation to "Advanced" view to see the RotaryEncoder code snippet.

 

The "Simple" view will try to guess the "most appropriate" input interface to use and hide all the other options. Most of the controls support the fixed_step interface ("DEC" and "INC" actions) that allows you to connect a rotary encoder even if it makes no sense at all (e.g. push buttons).

 

The reason CodeToad does it in a more complex way is because he wants to have advanced features like turn acceleration and menus. For the simple case where one step of the rotary will always result in the same command to the sim, DCS-BIOS has you covered.

 

 

 

I don't have a proper simpit ;) Don't have the time, money or space (dorm room) to build one right now. DCS-BIOS was created because I wanted to help WarHog using Arduino boards with DCS and I didn't like the existing approaches at the time for various reasons. I wanted an open-source implementation that had an export protocol efficient enough to export the complete cockpit state over one serial connection, hid away all DCS implementation details like argument numbers, and was documented well enough so others could use it.

Yup, that's what I needed. That's a relief, roadblock averted!

 

Your dedication to the cause is admired and appreciated.

[Curly]

Sent a Ian a PM about adding LoGet functions to DCS BIOS. He asked that I post the conversation as he thought it may help others.

 

Ian']

Ian I'm looking for a way to send LoGetAccelerationUnits() to a arduino. I was looking DCS Bios for this purpose, but it currently lacks the functionality to do so. Is there a way I could mod DCS bios to do this?

 

Currently, I'm able to export G data in a usable format from DCS via UDP. Though sending the data to the serial port has been my issue. I've been attempting to build a serial bridge in VS but the results have been frustrated by my lack of programing skills.

 

I think adding a library of exports for the LoGet functions could be very useful. As they seem to be universal for all the DCS modules. My export of Acceleration Units will send data from all the modules I've tested so far. Let me know if there is anyway I could aid in such an endeavor and thanks for your time.

 

Curly.

 

Hi Curly,

thanks for your interest in DCS-BIOS!

 

Take a look at the code for the CommonData export module. It exports generic position/altitude/heading data using LoGet* functions.

 

Because DCS-BIOS only exports unsigned integers and strings, you will have to set some reasonable lower and upper bound and then map that to an integer range (I use 16-bit values, i.e. from 0 to 65535 for everything that involves floats).

 

If you choose to modify the CommonData module, also make sure that your plane has an entry in AircraftList.lua to ensure that the CommonData module gets activated.

 

Note that the CommonData module intentionally does not export everything that is available through LoGet* functions. The CommonData module will be activated in every aircraft DCS-BIOS knows about, so it has to work in all of them. I also have some concern about the volume of exported data. Exporting data that changes all the time but is not being used will still consume some processing power on connected microcontrollers.

 

The current things it export are justified by the "moving map" use case. For example, the pitch and bank angles are not being exported. DCS-BIOS does not aim to be a TacView replacement, and physical or virtual panels won't use this data when the position of the actual in-cockpit ADI is available, which takes into account the pitch adjustment dial, failure modes (broken instrument, power off), etc.

The correct place to export generic pitch and bank values would be a new "FC3" module that gets activated in all planes that don't have a clickable cockpit (or at least don't have their own DCS-BIOS export module yet). I think the same would apply to the acceleration value, as e.g. the A-10C and Ka-50 have separate G-meters.

 

 

PS: It occurs to me that I have just spent a few minutes writing an explanation that could also be useful to other people. Can you create a thread on the public boards to continue this so that this information, any follow-up questions and their answers are available to others?

[rocketeer]

After years of absence, I'm ready to resume my a10 cockpit. Then tried to buy Brydling's card but he doesn't sell anymore. Not keen on leo's card or open cockpits. then I saw Ian's DCS BIOS. Read his user guide so now less intimidated by arduino. It shows how we can copy and paste the code and it'd talk to all kinds of switches, encoders, LED, push buttons, pots etc. Blew my mind especially watching the youtubes!

 

Question: for those of us who will be wiring many panels and switches, is the mega the board with the most number of pins? Then there are variants: Mega, MegaADK, Due, Ethermega, Etherdue. Not sure what's the diff. I see most of the time when people say mega it seems to be the mega 2560 R3?

 

Can't wait to get one and try out dcs bios!

[CodeToad]

rocketeer:

Indeed "Mega" usually means "Mega 2560 R3" at least for now (Sparkfun - link below - also has some other Mega variants)

 

The Mega has 54 digital I/O pins (15 of which can be used for PWM) and 16 analog pins.

 

You may find this chart useful for more comparisons between different Arduino boards #digital, analog ,PWM pins:

 

http://arduino.cc/en/Products.Compare

https://learn.sparkfun.com/tutorials/arduino-comparison-guide

 

The next best (#pins wise) is the Arduino Leonardo (or Yun, or Micro) with 20 pins

Most of the other ones (Uno, Pro Mini) have 14 or fewer

[FSFIan]

If you are going to make many panels, you are going to have to decide on a way to work with multiple boards anyway. (Either use one USB connection per board, or have groups of boards where only one talks to the PC and connects the others via a bus like I2C).

 

The Pro Mini clones look like the best price/performance ratio. They are also small enough so you can hide one behind each panel. This means the wiring will be less of a mess and you can easily pull a single panel for maintenance.

 

EDIT: disregard that, the Mega is actually on the same page price/performance wise as the Pro Mini boards if you add the cost of a USB-to-serial cable for each Pro Mini. So the more important reason to go for the Pro Mini is that you will have pretty much one Arduino per panel, so it's easier to test on its own.

Edited February 14, 2015 by [FSF]Ian

[Felm]

hey guys sorry for not posting any updates, didnt havetime to work on stuff this week. Ill try to do it tomorrow.

 

I haven't tried to get rotary encoders working with the shift registers yet but I stumbled on a few posts here and there where people said it's not a good idea...not really explained why. Anyone have any opinions on this?

 

ED: I reread the posts I found and if I understood correctly it was about the potential of missing inputs from the encoders. I might be wrong but for our purposes this is surely annoying but not catastrophic, right? I guess this would be a serious issue for something like a motor or a CNC-style application.

Edited February 14, 2015 by Felm

[FSFIan]

In my first experiment, I used shift registers to read all nine encoders and did not have a problem. Unless you are building a motor controller or add some kind of gearing to turn the encoders really fast, I wouldn't worry about losing the occasional step.

[rocketeer]

Thanks Codetoad and Ian for your replies.

 

Ian, it's a good suggestion to have one Arduino per panel. Never thought of that. But I think some panels require many pins, and the pro mini does not seem to have enough inputs. In those cases I'd have to use a bigger board.

 

When you say pro mini clones, can you give a specific name as example, just in case I buy the wrong one.

[FSFIan]

Just search eBay for "Arduino Pro Mini", apply "Buy It Now" and "Price + Shipping, Lowest first" filters and pick the first hit.

 

Here's an example.

 

Make sure to get a matching USB-to-serial converter as well, e.g. this ($0.88) or this ($1.58, has a DTR pin so you don't have to press the reset button manually when programming) or this ($1.65, includes / is built into USB cable).

[rocketeer]

Assuming most of the time the pro mini has enough pins to cover all the switches in each panel, can you explain again how to daisy chain the boards to create this I2C bus? I saw your youtube video on multiple boards together but lots of wires going in different directions.

And additional code is required to make the boards talk?

 

I saw in google this chainduino, daisy chaining boards with cat5 cables. what do you think of that?