Major Announcement: New software to to connect panels to DCS

You can connect an Arduino board to a CAN bus if you add additional transceiver and controller chips.

However, the CAN bus is just the transmission medium (like a serial port). You need to program your Arduino to send/receive the right messages over the CAN bus.

If you want to design your own system, you can come up with your own message format.

If you want to interoperate with another system like simparts, you will need to know their message format.

Either way, you won't get far without being able to or willing to learn Arduino programming.

do you or anyone know if it is possible to have more than one lcd screen on a single arduino ?.

do you or anyone know if it is possible to have more than one lcd screen on a single arduino ?.

For character LCDs: no problem at all.

If you are talking about graphical displays (like a 128x64 pixel OLED), the Arduino may not be fast enough to process that much data.

Oh great, so can you enlighten me as to how to script more than one, I have a 16x2 working showing cmsc, how do I add another to that script to show cmsp. Thanks.

Oh great, so can you enlighten me as to how to script more than one, I have a 16x2 working showing cmsc, how do I add another to that script to show cmsp. Thanks.

Google "arduino liquidcrystal multiple displays".

Click the first result.

Be enlightened.

For the CMSP, you may want to go with a 20x2 display instead of 16x2 because you need 19 characters to have spaces between the groups of four characters on a line.

Thanks Ian I have a 20x4 for it. I did a google but got no hits til I tried yours now I am enlightened, woohoo.

stay tuned for the next dumbass question there must be one I haven't thought of yet..

Ian! Thank you for this wonderful program. I just rigged up an electrical panel with DCS BIOS.

Everything works great. Almost. My emergency flood light switch is not working.

The arduino sees the switch, it sends a proper signal for the flood lights over the com port (visible in the cmd window), but in the game itself nothing actually happens.

Any insight as to what I'm doing wrong? Have I found a bug?

Any insight as to what I'm doing wrong? Have I found a bug?

You found a bug (that switch is the only one on that panel that doesn't use the ELEC_INTERFACE device, it uses LIGHT_SYSTEM instead -- I must have missed that when I built A-10C.lua).

I fixed it and released v0.2.2.

For future reference (because there are probably a few similar errors still in there):

if you can't operate the control from the

Thank you! It's working now.

I'm now staring at a 16 channel multiplexer on sparkfun, and trying to figure out how to make it work with DCS bios. If I'm going to make an armament panel, I'll need 15 different signals, and the arduino uno only has 13 I/O's

I can use a mux with DCS bios right? I'm assuming it's possible to write some code that will let it interpret the 4 signal wires from the mux, but I haven't even started looking into how to accomplish it.

On the Arduino Uno, you have 14 digital pins and 6 analog pins. You can't use pins 0 and 1 (serial RX/TX), you shouldn't use pin 13 for input purposes (you'd have to disconnect the on-board LED first), but you can use the analog pins as digital ones, e.g.:

DcsBios::Switch2Pos ahcpCicu("AHCP_CICU", A2);

(BTW, this does not work on the Pro Mini for pins A6 and A7.)

That leaves you with 11 useable digital pins + 6 analog pins, which is enough for the AHCP.

If you want to save pins, the most inexpensive solution is probably to wire it up as a 4x4 button matrix (using 8 pins) and add $0.15 worth of diodes ($1.00 for 100 pieces on eBay) to prevent ghosting.

To understand what to send over the serial port, read the "Import Protocol" section in the Developer Guide and play around with the interactive control reference documentation.

Another good learning resource is to read and understand the LED, Switch2, Switch3, etc. classes in the DCS-BIOS Arduino library.

I deliberately kept the Arduino library as simple as possible (it does not support normally-closed switches or rotary encoders with two instead of four pulses per step, for example).

If you use an external I/O expander, you should be able to write your own version of these classes that work together with an Arduino library for your I/O expander.

If you do, please publish your code so others can learn from it.

I would recommend using a Centipede Shield from Macetech: http://macetech.com/store/index.php?main_page=product_info&cPath=4&products_id=23

This is what I'm using to drive the master caution panel in the F-15.

The Centipede will give you up to 128 general purpose I/O pins that use the I2C interface. That should give you piles of switch inputs that you don't have to diode isolate.

g.

You know Ian, many have tried doing this. A few have even made something operational. But you are one of the very very few that have not only put something out there and not only made it usable for us Arduino ignorant, but have supported it all the way and constantly improving it.

I just wanted to personally thank you for that.

If Boltz has said that he will begin using it over his own A2DCS, than you know it has to be good! I wish you would take something for your own personal hard work with this. I know it's a collaboration, but you are the public face and very active in not only answering questions, but wanting to make it better. So if there is anything we as a group that uses this, or I in particular, can do for you, please, just ask.

I would recommend using a Centipede Shield from Macetech: http://macetech.com/store/index.php?main_page=product_info&cPath=4&products_id=23

 

This is what I'm using to drive the master caution panel in the F-15.

 

The Centipede will give you up to 128 general purpose I/O pins that use the I2C interface. That should give you piles of switch inputs that you don't have to diode isolate.

 

From their website, it looks like each Centipede shield gives you 64 additional GPIO pins and you can combine up to four of them for a total of 256 pins.

At $25 for 64 GPIO pins, I would only recommend that board if you want to populate the optional voltage regulator and take advantage of the fact that it can drive a lot of current.

If you don't need to drive that many outputs (or drive your outputs through a separate IC like a 74HC595 shift register or the MAX7219 LED controller), here are some other options in the same price range:

• For $20 + shipping, the Tiva C Connected Launchpad offers about 80 GPIO pins, an Ethernet port and a powerful ARM processor. Disadvantage: each pin can drive at most 12 mA, so you cannot even drive a single LED directly from an I/O pin. The board runs at 3.3V, which may be good or bad depending on what you want to connect to.
   
  
• If you can get an Arduino Pro Mini for less than about $6.25 (chinese clones are less than $3), it is cheaper to use multiple Arduino boards instead. This option is also more flexible, because you can use some of the pins for analog input and your pins are spread out over four boards, so you won't have to route that many wires to one central location.
   
  Disadvantage: more devices on the I2C bus mean less allowed wire length before you run into problems (you lose about 0.3m of wire length for each additional device, although this is the result of a theoretical calculation and I don't really know what I am talking about here -- I am no electrical engineer).
   
  
• At $6.25 per board, you could even afford to add an ESP8266 Serial to Wifi module to every single board
  

You know Ian, many have tried doing this. A few have even made something operational. But you are one of the very very few that have not only put something out there and not only made it usable for us Arduino ignorant, but have supported it all the way and constantly improving it.

 

I just wanted to personally thank you for that.

 

If Boltz has said that he will begin using it over his own A2DCS, than you know it has to be good! I wish you would take something for your own personal hard work with this. I know it's a collaboration, but you are the public face and very active in not only answering questions, but wanting to make it better. So if there is anything we as a group that uses this, or I in particular, can do for you, please, just ask.

Use it to build something awesome, then document the result for others to use as an example.

As long as I live in a dorm room, building any serious simpit is out of the question for me. The great thing about building the software part is that I can do it without requiring a lot of space.

Once I finish the developer guide and get some other things in my life back on track again, I may have enough time to start accepting donations to fuel my dev board addiction. There are many interesting boards out there I'd like to play with at some point, but I can never justify buying them because I already have four MSP430 Launchpads, two Stellaris Launchpads, and one STM32F0 Discovery board in my parts drawers mostly gathering dust.

Wow, I hooked up an Arduino and followed your DCS-BIOS video example, and had stuff flowing onto my lcd display first time (same with a TACAN test button and LED)

Also tried your very handy live preview extension for Chrome and again, success.

Gotta love German engineering - very good code, documentation and videos !

A few issues:

1.

MetaDataStart/Aircraft name documentation is missing a hex constant:

void onAcftNameChange(char* newValue) {

/* your code here */

}

DcsBios::StringBuffer<16> AcftNameBuffer( RIGHT HERE, onAcftNameChange);

2.

Commondata heading, lat, long etc. do not follow the common pattern of declaring a event handler function and a buffer. Instead these have an if statement. How to incorporate that into the Arduino code ? In the main loop ?

EDIT: reminded myself to RTFM and i think the answer is:

void onDcsBiosWrite(unsigned int address, unsigned int value) {

if (address == 0x040a) {

unsigned int hdgDegValue = (value & 0x01ff) >> 0;

String s = hdgDegValue + " ";

lcd.setCursor(0,3);

lcd.print( s );

}

}

3.

Servos are my next experiment and I will try Commondata::Altitude MSL

I see you have conveniently shown how to do that in the docs:

DcsBios::ServoOutput altMslFt(0x0408, PIN, 544, 2400);

If I wanted instead to catch the altitude integer for display on my LCD is this what I should do:

void onDcsBiosWrite(unsigned int address, unsigned int value) {

if (address == 0x0408 ) {

unsigned int altMslFtValue = (value & 0xffff) >> 0;

/* your code here */

}

}

4.

your chrome extension shows string values (like CSMC text, digital clock digits) coming through just fine.

On my LCD I see hiccups like frequent umlauts or other strange characters instead of digital clock numerals. Sometimes strings seem to be null terminated early (for example, if CSMC switches from ACTIVE to OFF I may see "OFTIVE" in the lcd meaning only the first two chars changed.

Could my serial port hardware be screwing up for the arduino (I haven't changed the Serial.begin(500000); in the arduino code or the serial port settings in your connect-serial-port.cmd) ?

I should probably test on another USB socket perhaps there is too much other traffic on that particular USB controller and bits get dropped/corrupted ?...gotta find an empty one on my rig...not easy :)

My computer is not sweating: DCS is at 100 fps. Perhaps the updates are coming TOO FAST ?

I attach the Arduino code for reference although it is vanilla, following your examples.

arduinoCockpit.zip

Codetoad and Ian,

I as just going to post on this I did a bug report on Github about the offtive thing he has put null-terminated in some places, I have tried what Ian said on there and the Serial port command script won't run I have double checked the changes.

I have CMSP, CMSC & UHF with Clock running on 3 LCD's, I do understand the principal of having to write to all squares every time but cannot make it do it.

I am a total arduino noob and have found DCS_BIOS very easy to do.

next I am onto UFC I already have the LED and import/export working.

I do have a suggestion as regards donations, would you Ian accept a module key for an aircraft or do you have them all?..

1.

MetaDataStart/Aircraft name documentation is missing a hex constant:

 

void onAcftNameChange(char* newValue) {

/* your code here */

}

DcsBios::StringBuffer<16> AcftNameBuffer( RIGHT HERE, onAcftNameChange);

Thanks, that was a bug in the display function (it did not work if the value was zero because it included "if (!number) return;" in its error checking part). Fixed in current master branch.

2.

Commondata heading, lat, long etc. do not follow the common pattern of declaring a event handler function and a buffer. Instead these have an if statement. How to incorporate that into the Arduino code ? In the main loop ?

 

EDIT: reminded myself to RTFM and i think the answer is:

 

void onDcsBiosWrite(unsigned int address, unsigned int value) {

if (address == 0x040a) {

unsigned int hdgDegValue = (value & 0x01ff) >> 0;

String s = hdgDegValue + " ";

lcd.setCursor(0,3);

lcd.print( s );

}

}

Correct.

3.

Servos are my next experiment and I will try Commondata::Altitude MSL

I see you have conveniently shown how to do that in the docs:

DcsBios::ServoOutput altMslFt(0x0408, PIN, 544, 2400);

That value is not really meant for a servo (although the reference documentation does not know better). For the altimeter needle, you want A-10C/ALT_100FT ("100 ft Pointer").

If I wanted instead to catch the altitude integer for display on my LCD is this what I should do:

 

void onDcsBiosWrite(unsigned int address, unsigned int value) {

if (address == 0x0408 ) {

unsigned int altMslFtValue = (value & 0xffff) >> 0;

/* your code here */

}

}

Correct.

If you are displaying integer values on your LCD, consider using something like this to convert it to a fixed-length string:

char buf[6]; // max. Length 5 ("65535") + null terminator
sprintf(buf, "%5d", altMslFtValue);
lcd.setCursor(0,0);
lcd.print(buf);

Also note that the altitude in the CommonData module is the one returned by LoGetSelfData(), not the one displayed on your altimeter (i.e. it does not take the barometric pressure setting or altimeter failure into account).

4.

your chrome extension shows string values (like CSMC text, digital clock digits) coming through just fine.

On my LCD I see hiccups like frequent umlauts or other strange characters instead of digital clock numerals. Sometimes strings seem to be null terminated early (for example, if CSMC switches from ACTIVE to OFF I may see "OFTIVE" in the lcd meaning only the first two chars changed.

The "OFTIVE" thing should be fixed in the latest version.

The most likely reason for strange characters on the LCD (if the other LCDs are fine) is a "loose wire" on one of the data lines (for example a bad solder joint or loose connector).

My computer is not sweating: DCS is at 100 fps. Perhaps the updates are coming TOO FAST ?

DCS-BIOS limits updates to 30 per second independent of your FPS -- this is to ensure that transmissions fit over a 115200 bps serial connection. In a situation where a 115200 bps connection would be overwhelmed, DCS-BIOS will skip an update, although that has never happened in my tests (that's what the Update Skip Counter counts).

The baud rate only defaults to 500000 bps because it is the fastest that the Arduino can support and if we can reduce latency by a few ms we might as well do so. If you have longer lines from your USB-to-serial converter to the Arduino board in the future and experience problems, you can safely lower it to 115200.

Wow, great job Ian! This is really amazing. :thumbup: Big thanks for all the effort, very much appreciated.

I read that you were working on the code for using 7seg digits with MAX7219 drivers, how is that going? I can't wait to start exporting radio frequencies to 7segments especially since you made rotary encoders so easy to implement.

Speaking of inputs, what are the plans for shift register or multiplexer integration? For example the 74hc165 for inputs and 74hc595 for outputs . I'm running out of pins on my 2 megas and was wondering if I should start working on a 74hc165 based circuit (or buy another mega?). For analog like pots there's also the cd4051 multiplexer which can increase analog ports.

One last thing, I noticed that you didn't include some stuff that are not in the cockpit per se like night vision goggles on/off, their gain, the eject button. Everyone wants an eject button!

Sorry if I missed them.

Again, thanks for all this!:thumbup:

Ian, the Centipede boards I have only allow two to stack - it's nice to see he's changed that.

I use a custom designed board that allows me to drive 16 high-draw outputs each. I use a TIP125 as the driver. I needed something that could power a pile of incandescent lamps. :)

g.

I read that you were working on the code for using 7seg digits with MAX7219 drivers, how is that going? I can't wait to start exporting radio frequencies to 7segments especially since you made rotary encoders so easy to implement.

The UHF repeater WarHog has built seems to only work intermittently, but that could be a hardware problem. We'll get example code out there when we have ruled out that it's a bug in the software.

Speaking of inputs, what are the plans for shift register or multiplexer integration? For example the 74hc165 for inputs and 74hc595 for outputs . I'm running out of pins on my 2 megas and was wondering if I should start working on a 74hc165 based circuit (or buy another mega?). For analog like pots there's also the cd4051 multiplexer which can increase analog ports.

The DCS-BIOS Arduino library has two goals:

• To enable people without any programming background to use simple controls (switches, push buttons, rotaries, pots), so they can replace joystick interface boards with low-cost Arduinos and take advantage of the improved control synchronization and easier configuration (no editing of input lua files) that DCS-BIOS provides.
  
• To be a simple reference implementation of the DCS-BIOS communication protocol to study along with the developer guide.
  

The library cannot possibly cover all the different I/O expanders etc. out there, so it does not sacrifice simplicity trying to do that.

If you want to use shift registers or a button matrix, you also cannot read and write individual pins independent of another.

If you want to use displays, stepper motors, shift registers, I2C I/O expanders, etc. you will have to know C++. For these cases, it is much easier to write a sketch that is specialized for your particular panel than it is to write a library that is generic enough to cover all the different use cases and then document such a library in a way that can be understood by someone who doesn't know C++ (because if they did, they would have written that specialized sketch in the time it takes to read the documentation).

I think that for the MCP23017 16-bit I2C I/O expander you could write a version of the DCS-BIOS Arduino library that depends on the Adafruit_MCP23017 library and accepts an Adafruit_MCP23017 instance and pin number instead of an Arduino pin number. However, I have no plans to write, document and maintain such a library myself.

One last thing, I noticed that you didn't include some stuff that are not in the cockpit per se like night vision goggles on/off, their gain, the eject button. Everyone wants an eject button!

Sorry if I missed them.

 

Again, thanks for all this!:thumbup:

Those are things that are not found in the clickablecockpit.lua file. They are "generic" commands that work in any airplane and are triggered by calling LoSetCommand().

I have plans to add a DCS-BIOS module that allows you to trigger all commands in this list.

Ok thanks for the info!

Are you and Warhog working only on a UHF repeater or also on the other radios? Just asking because I noticed that you can already export the repeater to an 16x2 (or whatever size) lcd with DCS-BIOS but not the vhf fm/am values. Is that possible? How hard would it be link with the max7219 library?

I agree with you that shift registers add a lot of unnecessary complexity that can very easily be bypassed with an extra board. I was thinking of using them because I have a lot lying around but it's smarter to just get a new mega or uno and link them like you showed in your video.

I was not saying that you shouldn't use shift registers (although for input purposes I personally can't be bothered to solder all the pull-up resistors). My point was that the DCS-BIOS Arduino library does not provide specific support for shift registers, so you will have to write some code yourself.

What makes you think that the VHF frequencies cannot be exported using DCS-BIOS?

It makes all the info you need available, not just as a single string (because the displays are divided into several small "windows" for each selector knob in the real aircraft).

In the control reference documentation, take a look at the "VHF AM Radio" and "VHF FM Radio" categories in "Advanced" view and look at the available outputs for the Frequency Selector 1 through 4. If you want to display the frequency as a string on a LCD, you will have to piece the frequency together yourself. There is no separate "frequency string" export because the information is already available from other controls.

Technically, you could do the same to piece together the UHF frequency from the selector positions. However the UHF frequency string exported by DCS-BIOS has a slightly different meaning than just concatenating the selector positions, because it is the actual content of the UHF frequency display. It will be empty when the power is off and show "***.***" when the radio is initializing or the "display test" button is pressed.

I'm ok with building the circuit (true on the resistors though, it's a pain) but I'm not sure my coding skills are up to the task of implementing the shifting without taking a silly amount of time. Even conceptually it's difficult to see how to shift in the data from a single pin when DCS-BIOS is expecting different pins to trigger. I'm ok-ish with cannibalising code and making small modifications but I don't think I can write it from zero or make very complicated additions.

Thanks for the advice on the radio freqs, I completely missed that part! So I can get the position of the frequency selector as an integer(string?) output. Now I have to figure out a way to send it to the ledcontrol library so the max7219 can drive the correct leds, right?.

I will hopefully get some time to look a bit better at the libraries and reference documents tomorrow night. It will probably help me understand better what I have to do.

Have a look at this site, prices are not too bad and they have code for most of their stuff. http://www.embeddedadventures.com/ .

Even conceptually it's difficult to see how to shift in the data from a single pin when DCS-BIOS is expecting different pins to trigger. I'm ok-ish with cannibalising code and making small modifications but I don't think I can write it from zero or make very complicated additions.

DCS-BIOS itself (i.e. the part that runs inside DCS and communicates with your Arduino over a network connection or -- with the help of socat -- a serial port) does not make any assumptions about your hardware design or even what microcontroller you use.

The Arduino library also shifts a lot of responsibility and choice to the user.

Your first responsibility is to get the export data to the DCS-BIOS ProtocolParser and provide a sendDcsBiosMessage() function that gets a message back to DCS-BIOS. The Arduino library provides template sketches to do this over a serial port or an Ethernet shield.

Once you have that, you can use onDcsBiosWrite() to react to changes of specific values (e.g. the position of the UHF 10 MHz selector) and use sendDcsBiosMessage() to send commands to DCS (e.g. sendDcsBiosMessage("AHCP_CICU", "1") to switch the CICU switch to ON).

It is this level of abstraction that you would use when working with other ICs like shift registers, displays or I/O expanders. In most cases you would also include another Arduino library that makes it easier to interface with your IC (e.g. the LiquidCrystal library to talk to the LCD).

The StringBuffer class takes care of combining write accesses to multiple addresses into a longer string and calling a callback function with the complete string when it changes.

The rest of the Arduino library (classes like Switch2, LED or ServoOutput) are there to handle the simplest possible case (a dedicated Arduino pin for each button, etc) in a way that can be used by people who only know how to copy and paste and have no programming background whatsoever. Because it does not require any kind of "deeper understanding" from the user, its flexibility is also very limited.

But nothing forces you to use it.

For example, in my PS/2 CDU keyboard example (code here), I am not even including the DcsBios library.

Have a look at this site, prices are not too bad and they have code for most of their stuff. http://www.embeddedadventures.com/ .

They have some cool stuff there, thanks! I already have my displays and chips though but I will keep them in mind for my next project.

Ian;2292207']DCS-BIOS itself (i.e. the part that runs inside DCS and communicates with your Arduino over a network connection or -- with the help of socat -- a serial port) does not make any assumptions about your hardware design or even what microcontroller you use.

 

The Arduino library also shifts a lot of responsibility and choice to the user.

Your first responsibility is to get the export data to the DCS-BIOS ProtocolParser and provide a sendDcsBiosMessage() function that gets a message back to DCS-BIOS. The Arduino library provides template sketches to do this over a serial port or an Ethernet shield.

 

Once you have that, you can use onDcsBiosWrite() to react to changes of specific values (e.g. the position of the UHF 10 MHz selector) and use sendDcsBiosMessage() to send commands to DCS (e.g. sendDcsBiosMessage("AHCP_CICU", "1") to switch the CICU switch to ON).

 

It is this level of abstraction that you would use when working with other ICs like shift registers, displays or I/O expanders. In most cases you would also include another Arduino library that makes it easier to interface with your IC (e.g. the LiquidCrystal library to talk to the LCD).

 

The StringBuffer class takes care of combining write accesses to multiple addresses into a longer string and calling a callback function with the complete string when it changes.

 

The rest of the Arduino library (classes like Switch2, LED or ServoOutput) are there to handle the simplest possible case (a dedicated Arduino pin for each button, etc) in a way that can be used by people who only know how to copy and paste and have no programming background whatsoever. Because it does not require any kind of "deeper understanding" from the user, its flexibility is also very limited.

But nothing forces you to use it.

 

For example, in my PS/2 CDU keyboard example (code here), I am not even including the DcsBios library.

Thank you for all the advice! it's really great that you are helping people do what they want with your software. Hopefully I will be able to contribute back by figuring out how to do it and posting it here for other people to use in the future.

Right now my priority is to export the radio frequencies to 7seg leds driven by the max7219. Then I will look into the shift register thing. I also have a few 16x2 lcsd lying around but I will leave those for last.

I will let you know how it goes, I will definitely have many more questions once I get into it. :joystick: