Major Announcement: New software to to connect panels to DCS

[FSFIan]

Peter: thanks for sharing.

You have a good point: just because the spec says 128 doesn't mean your specific hardware combination can do it. Reality trumps theory once again!

 

I don't know if the USB-IF requires an actual test with 128 devices to be certified. (I assume you were using powered hubs all the way, so it couldn't have been a power issue.)

 

You say UDP requires address management -- have you tried simply sending to the broadcast address and having your devices get an IP address through DHCP? In that case, the only address to manage is the static IP of your DCS computer.

 

PS: I have released v0.2.4, which fixes the FLAPS_SWITCH in the A-10C and some indicator lights in the UH-1H.

[Gadroc]

I noticed a mega clone is about $22. It has 54 pins vs mini pro's 14. So it'd cut down the number of usb cables by 4 times. If I have to go the usb route instead of i2c then i'd get a bunch of mega clones.

 

Having one board per panel is ideal, but if i2c chaining too many board is not good and using one usb per board is too many cables, then using mega is a compromise to reduce cable count and using mega clone to reduce cost instead of arduino brand.

 

Mini pros have 20 available pins for use. Digital Pins 0 & 1 are required for communications so they can't be used which leaves 12 digital pins. Analog Pins A0-A5 can also be used as digital pins which gives you 6 more. And if you look on the board it has A6-A7 also there just doesn't have pins soldered in for them which gives you two more.

 

By the same math Megas have 52 digital available + 16 analog/digital for 68 pins.

 

There are a few more things to consider than just total number of pins.

1) How do I repair or modify parts of the pit individually?

2) Do I want to be able to add functionality later to a panel?

3) What is my power draw? Only so much current can flow through the microprocessor at once. How many of those 68 pins can be active at once.

4) How do I manage ground connections? While the mega and mini have 20-68 inputs they only have 2-3 ground pins. Every switch will require a pin and a ground connection. What is your wiring harness going to look like.

5) How much are all my connectors going to cost? If you have central wiring don't forget to include the cost of D-Sub or other connectors at each panel.

6) Am I going to do back-lighting? If so you're not going to drive it straight off the arduinos. A single panel back-light is approximately 200-300ma of current based on my experimentation. This quickly adds up and you really need to worry about power management.

 

There are more and if people want I'll spend some more time later this week doing some write ups. I feel like I'm the downer on this thread, but that's not my intent. I just want people to plan ahead. Not thinking this through all the way because one panel was easy is going to lead to a lot of wasted money and time. Ian has done a tremendous job of making getting started easy and I'm ecstatic about the activity driving forward.

[Deadman]

Guys Thanks for the tremendous amount of work and thought going it to this!!

Your productive dissuction has brought up pros and cons for severial systems and educated all of us. Ian you have opened up cockpit building to what it truly can be. Gadroc any time you can spare to expand the system is greatly appreciated. Guys thanks again

[FSFIan]

I feel like I'm the downer on this thread, but that's not my intent. I just want people to plan ahead. Not thinking this through all the way because one panel was easy is going to lead to a lot of wasted money and time. Ian has done a tremendous job of making getting started easy and I'm ecstatic about the activity driving forward.

 

I appreciate the effort you put into this! Getting advice from someone who has actually built some of this is invaluable.

 

One reason for starting DCS-BIOS was that I saw that the existing software approaches wouldn't scale up to a full simpit (that's why I created the binary export protocol). I had ruled out Helios at the time because it wasn't open source yet.

 

I thought my simple "shared serial TX for export, I2C for import" approach would be (a) sufficient to scale the hardware side of things to a full pit and (b) reliability issues could be avoided with the "once you have problems, start a new I2C bus" approach and it would be justified by the decrease in costs.

I now realize that this argument is fundamentally flawed, because it does not take intermittent errors into account. Also, RS-485 transceivers are a lot less expensive than I thought :)

 

Let's come up with a "DCS-BIOS over half-duplex RS-485" standard.

 

In that context, the TI Tiva C Connected Launchpad looks very interesting. With its Ethernet port and 8 UARTs, once you add RS-485 transceivers, it could easily connect up to eight RS-485 buses to DCS-BIOS.

(I always wanted an excuse to buy one, now I have it.)

 

Other less expensive candidates (when you only need to connecting a single RS-485 bus):

• Any Arduino with an Ethernet shield
  
• Arduino Mega or Leonardo (both have two UARTs, so one can talk to the PC and one can talk to the RS-485 bus)
  
• A RS-485 transceiver connected to a USB-to-serial converter, with suitable PC software (could you control the output enable on the transceiver with one of the extra RS-232 signals?)
  

[bnepethomas]

Ian;2320464']Peter: thanks for sharing.

You have a good point: just because the spec says 128 doesn't mean your specific hardware combination can do it. Reality trumps theory once again!

 

I don't know if the USB-IF requires an actual test with 128 devices to be certified. (I assume you were using powered hubs all the way, so it couldn't have been a power issue.)

 

You say UDP requires address management -- have you tried simply sending to the broadcast address and having your devices get an IP address through DHCP? In that case, the only address to manage is the static IP of your DCS computer.

 

PS: I have released v0.2.4, which fixes the FLAPS_SWITCH in the A-10C and some indicator lights in the UH-1H.

It did my head in until I worked out it was a USB limitation, and yeap siree I using powered USB hubs. Had to install a second USB card in the PCI slot to fully operational.

 

On addressing, with the Ethershields, yes you could look at multicast or broadcast, I'm planning to run with fixed addresses, that will enable me to throw data at the right IO (more O than I) card, and reduce the amount of error handing to deal with.

 

I must admit I haven't followed all the posts in the thread, so these points could have already been discussed, but here's some learnings I'm applying after building a few pits.

 

1: Open Source Software and Hardware is a real good thing. It does mean you aren't stuck with a pit that you can't go forward with. My F16 was built around the Beta Innovations I/O infrastructure. Quality of both Hardware and S/W is very good, but when they shut their doors, development stops, which is a real bummer. If I can get the same component from different vendors I'll choose that over a card that only comes from one supplier.

 

2: Where possible on input side of things emulate a joystick. Its relatively easy to convert a joystick button press to a bunch of things, harder to do it the other way. This way you can more easily move between sims. It may be that you break he pit into zones so you have several controllers.

 

3: Dedicate Arduinos (or whatever you choose) to given functions. Hardware is relatively cheap, and compared to the fun found when troubleshooting 'last mile stuff' (like I2C), it really nice to not destroy existing working code for other instrument functions. I've got one Arduino supporting OLED displays, another one driving steppers, and yet another driving steppers that need a zero position sensing. A second benefit is if something goes wrong electrically, hopefully(!) you have a smaller damage domain. For reasons that still puzzle me, I had an I2C device do something completely funky to a card, fortunately it only impacted a single mux card and not the entire pit.

 

Some random thoughts :)

 

Cheers

 

Peter

[0414 Wee Neal]

Hi

I have an uneducated question, would this software solution work with a POKeys card?

 

Sorry for the silly question!

 

Neal

[FSFIan]

Hi

I have an uneducated question, would this software solution work with a POKeys card?

 

Well, I have never heard of those, so DCS-BIOS has never heard of those, so that's a no. You would have to write a piece of software that translates between the two.

[agrasyuk]

Hi

I have an uneducated question, would this software solution work with a POKeys card?

 

Sorry for the silly question!

 

Neal

 

Hi Neal, Take a look at this:

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

[ramzessii]

It was absolutely mind blowing to read through the whole of this thread. I didn't want to ask anyquestions before I do so.

Now I'd like to ask.... Can DCS-BIOS synchronise the state of switches on startup of A10C in DCS?

 

Thanks.

 

Regards,

Janis

[Gadroc]

Hi

I have an uneducated question, would this software solution work with a POKeys card?

 

Sorry for the silly question!

 

Neal

 

Nope. POKeys are not arduino compatible micro controllers.

[Gadroc]

It was absolutely mind blowing to read through the whole of this thread. I didn't want to ask anyquestions before I do so.

Now I'd like to ask.... Can DCS-BIOS synchronise the state of switches on startup of A10C in DCS?

 

Thanks.

 

Regards,

Janis

 

No not right now... And this is a very non-trivial exercise. I've written up some of challenges before.

[FSFIan]

Now I'd like to ask.... Can DCS-BIOS synchronise the state of switches on startup of A10C in DCS?

 

Right now it cannot. That was a deliberate design decision:

• If you join a "hot start" plane with the switch in the wrong position, you may for example inadvertently turn off your battery power switch. If the switches are not synced at startup, you can simply switch your physical battery power switch to ON after the fact -- from that point on, it is synced to the game.
  
• It would have added more complexity to the Arduino library. One of the design goals was to avoid complexity where feasible to make a system that can be explained to and understood by someone with no programming experience and a minimal background in electronics.
  

 

If you know C++, you can program a modified version of the Arduino library that checks the exported switch state from DCS-BIOS and sends a command to correct it if it is out-of-sync with the real switch.

[WildBillKelsoe]

Ian;2316819']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).

 

No, I mean a video telling lay persons (like me, ehem) what is arduino, what is DCS panels, what is the benefit of having one, a diagram like the scibble up there^^, what type of experience is needed, etc... I mean not all audience here are math wizards(including me), sort of like a 3 minutes video.

[FSFIan]

Have you read the first post in this thread?

 

Have you watched the

That shows you hands-on what DCS-BIOS can do.

 

After that, have you checked the website and clicked the link to the latest version of the User Guide?

 

If, after that, you have an actual question that can be answered, feel free to ask away.

 

what is arduino

http://www.arduino.cc

http://en.wikipedia.org/wiki/Arduino

 

what is DCS panels, what is the benefit of having one

If you have to ask that question, you may be in the wrong subforum. Scroll through the various build threads on this forum. If, after that, your first reaction (before you have thought about money, time, or other constraints) is not "wow!", followed by "I want to have something like this, too", you are beyond help.

 

I mean not all audience here are math wizards(including me), sort of like a 3 minutes video.

If you are implying that to understand the existing documentation you need to know math, please show me the location where that documentation confronts you with any math at all.

 

 

Sorry, but until you start asking actual questions, I can't help you.

At this point, I can't tell if you are (a) trolling, (b) there is a language barrier, or © you didn't even try to understand the existing documentation and google things for yourself.

 

If (a), go back under your bridge!

If (b), instead of saying "there should be better/more documentation", ask actual questions so we know which ones the current docs don't answer.

If ©, I can tell you now that DCS-BIOS may not be for you. If the Leo Bodnar boards are the helicopter ride to the top of the mountain, DCS-BIOS is the hiking trail that allows people without rock climbing experience who can't afford the helicopter to also reach the summit. But no matter how shallow we make the slopes on that path, you will still have to walk it yourself.

[ramzessii]

No not right now... And this is a very non-trivial exercise. I've written up some of challenges before.

That is fine, thanks for the answer. I do understand the implications and the fact that it's safe only on cold and dark start, I just thought I've seen it mentioned somewhere in user guide but I might be wrong.

No, I don't know C++ at all. All I know is at most 2% of VBA. I've been with sim world for years now namely MSN and P3D nowadays but just recently been introduced to DCS and it's community and this is where I finally realised that I want to build myself a cockpit. So last few months I've been busy gathering info and still do. Thanks to dedicated guys like you cockpit building becomes possible to many of us.

[ramzessii]

I have noticed (whilst playing with my 16x2 and 20x4 character LCD's) that they both work great whilst displaying CMSP display lines 1 & 2. There is no response delay at all. When (just for testing purposes) I tried to send CDU display lines to my 20x4 character LCD there was a delay. Right after starting up DCS it was probably a second or two before LCD displayed 4 lines of CDU content also I noticed that every now and then content of some of the lines changes (it doesn't in the virtual cockpit) but on LCD few characters do and then change back to what they are supposed to be.

 

I don't know why it is like that.

 

Also I am guessing that character LCD is no good for displaying CDU content as there are symbols it won't display: arrows, cursor, square brackets etc.

 

What sort of display would I need in order to display CDU content?

 

 

Regards,

Janis

[agrasyuk]

I have noticed (whilst playing with my 16x2 and 20x4 character LCD's) that they both work great whilst displaying CMSP display lines 1 & 2. There is no response delay at all. When (just for testing purposes) I tried to send CDU display lines to my 20x4 character LCD there was a delay. Right after starting up DCS it was probably a second or two before LCD displayed 4 lines of CDU content also I noticed that every now and then content of some of the lines changes (it doesn't in the virtual cockpit) but on LCD few characters do and then change back to what they are supposed to be.

 

I don't know why it is like that.

 

Also I am guessing that character LCD is no good for displaying CDU content as there are symbols it won't display: arrows, cursor, square brackets etc.

 

What sort of display would I need in order to display CDU content?

 

 

Regards,

Janis

 

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

[ramzessii]

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

 

So what are you saying - it can only be done using Rpi?

There is no way of getting CDU dispay to work using Arduino?

Asking simply because I don't know - it's all - it's currently still one big Chinese dictionary for me.

[FSFIan]

So what are you saying - it can only be done using Rpi?

There is no way of getting CDU dispay to work using Arduino?

Asking simply because I don't know - it's all - it's currently still one big Chinese dictionary for me.

 

It can be done with a character LCD (but most people choose a graphical one because there are no 24x10 character LCDs on the market). IIRC the controllers in those character displays have a way to define custom symbols. Google "hd44780 custom characters".

[Felm]

shift register code is done using multiple 64bit variables for the shift in, 8 chips at a time. I took a look on how to perform bitshift operations on >64bit but my brain melted a bit so I gave up. Will sanitize and document the code by the end of the weekend hopefully.

Edited February 20, 2015 by Felm

[mblackham]

A little confused

 

@Ian:

 

Tried using your suggestion to only update LCD when MetadataEnd (0xfffe) gets encountered.

 

Did not fix the problem. Still seeing junk bytes, strings too short (like empty HH/MM/SS), very rare updates (possibly due to corrupted stream => missing MetadataEnd packets) and likewise TACAN test light on wrong (which is independent of LCD mechanics, pointing to a software rather than hw updating issue)

 

Code pasted below.

Tricky to debug because I can't use Serial.print because the serial port is obviously being used by the socat cmd.

Is there a way to "debug dump" what is being sent over the serial port by socat ?

 

Additional info:

I verified again that your chrome extension with live data display shows the data coming from your DCS BIOS export correctly, so the issue is likely downstream of that.

 

Curiously I noticed that when I put the A10 into autopilot flying straight, things start looking better on the LCD soon after: updates happen more frequently and the text looks more correct !

Could it be that if I fly manually that causes more cockpit display data changes and thus more required updates and that may flood socat or my serial interface ?

This is reversible: if I go out of autopilot, I once again get more garbage chars, fewer updates.

 

 

 

----------

 

Second, following up on your suggestion that the LCD might be overwhelmed w too many updates, I also looked into that a little bit, and to save others this particular trip down debugging lane:

 

My LCD display, a 20x4 liner (http://www.adafruit.com/products/198) is based on the HD44780 chip which is also used by many other character displays.

They all have similar pinouts:

VSS, VDD, V0, RS, RW, E, D0, D1, D2, D3, D4, D5, D6, D7, LED+, LED-

 

General info and hookup instructions can be found here.

 

The tutorials all show a wire & pin conserving 4-data wire hookup of the display, rather than all 8. Quoting from that page:

 

There is also a way to talk to the LCD using only 4 data pins instead of 8. This saves us 4 pins! Why would you ever want to use 8 when you could use 4? We're not 100% sure but we think that in some cases its faster to use 8 - it takes twice as long to use 4 - and that speed is important. For us, the speed isn't so important so we'll save some pins!

 

I did try hooking up all 8 data lines (since we are testing whether LCD speed might be a culprit) and used the full 8 dataline constructor for the LCDLibrary

 

LiquidCrystal(rs, enable, d0, d1, d2, d3, d4, d5, d6, d7)

 

That however did not work at all (nothing shows up on the LCD) So I assume there is a bug in the library and left that experiment alone. Just FYI.

 

 

-------------

 

As per Ian's suggestion, modified Arduino code that collects telemetry as usual but only updates the LCD when a MetadataEnd packet (0xfffe) is encountered (which by design should be about every 30ms).

See onDcsBiosWrite() and updateLCDDIsplay() below.

 

 

#include <DcsBios.h>

#include <Servo.h>

#include <LiquidCrystal.h>

 

#define TACAN_TEST_BUTTON 2

#define TACAN_TEST_LED 3

 

LiquidCrystal lcd(7, 8, 9, 10,11,12);

 

unsigned int altMslFtValue;

unsigned int hdgDegValue;

 

// ------------------------------------------------------------------------------

 

DcsBios::LED tacanTest(0x10da, 0x0400, TACAN_TEST_LED);

DcsBios::Switch2Pos tacanTestBtn("TACAN_TEST_BTN", TACAN_TEST_BUTTON);

 

void onCmscTxtMwsChange(char* newValue) {}

DcsBios::StringBuffer<8> cmscTxtMwsBuffer(0x12b0, onCmscTxtMwsChange);

 

void onAcftNameChange(char* newValue) {}

DcsBios::StringBuffer<16> AcftNameBuffer( 0x0000, onAcftNameChange);

 

void onClockHhChange(char* newValue) {}

DcsBios::StringBuffer<2> clockHhBuffer(0x10fe, onClockHhChange);

void onClockMmChange(char* newValue) {}

DcsBios::StringBuffer<2> clockMmBuffer(0x1100, onClockMmChange);

void onClockSsChange(char* newValue) {}

DcsBios::StringBuffer<2> clockSsBuffer(0x1102, onClockSsChange);

void onClockEtcChange(char* newValue) {}

DcsBios::StringBuffer<3> clockEtcBuffer(0x1104, onClockEtcChange);

 

// ------------------------------------------------------------------------------

 

DcsBios:: ProtocolParser parser;

 

void setup() {

Serial.begin(500000);

 

lcd.begin(20,4);

lcd.clear();

}

 

void loop() {

while (Serial.available()) {

parser.processChar(Serial.read());

}

DcsBios:: PollingInput::pollInputs();

}

 

void sendDcsBiosMessage(const char* msg, const char* arg) {

Serial.write(msg);

Serial.write(' ');

Serial.write(arg);

Serial.write('\n');

}

 

 

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

 

// show heading and altitude on line 3 of LCD

if (address == 0x040a ) {

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

}

 

if (address == 0x0408 ) {

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

}

 

if (address == 0xfffe ) { // end of DCS BIOS update marker (~every 30ms)

updateLCDDisplay();

}

}

 

 

void updateLCDDisplay()

{

lcd.setCursor(0,0);

lcd.print( cmscTxtMwsBuffer.buffer );

 

lcd.setCursor(0,1);

lcd.print( String(AcftNameBuffer.buffer) + " " );

 

// assemble clock string here so we dont hammer LCD more than necessary

String c = String(clockHhBuffer.buffer) + ":" + String(clockMmBuffer.buffer) + ":" +

String(clockSsBuffer.buffer) + " " + String( clockEtcBuffer.buffer );

lcd.setCursor(0,2);

lcd.print©;

 

String s(hdgDegValue);

lcd.setCursor(0,3);

lcd.print( "Hdg:" + s + " " );

 

String s2(altMslFtValue);

lcd.setCursor(10,3);

lcd.print( "Alt:" + s2 + " " );

}

 

 

Soo I have been trying to a heading displayed on a 16x2 lcd through Arduino.

I have had it working for the CMSP panel but had to add the following into my code:

 

 

void onDcsBiosFrameSync() {
 }

 

I notice you don't have that anywhere in your example code and have a hunch that is why I can't get my version to work.

 

#include <DcsBios.h>
#include <Servo.h>
#include <LiquidCrystal.h>
LiquidCrystal lcd( 8, 13, 9, 4, 5, 6, 7);
unsigned int hdgDegValue;
/**** Make your changes after this line ****/

void onDcsBiosFrameSync() {
 }
/**** In most cases, you do not have to change anything below this line ****/

/* Instantiate a ProtocolParser object to parse the DCS-BIOS export stream */
DcsBios::ProtocolParser parser;

void setup() {
 Serial.begin(115200);
 lcd.begin(16, 2);
 lcd.clear();  
}

/*
Your main loop needs to pass data from the DCS-BIOS export
stream to the parser object you instantiated above.

It also needs to call DcsBios::PollingInput::pollInputs()
to detect changes in the state of connected controls and
pass them on to DCS.
*/
void loop() {
 // feed incoming data to the parser
 int data = Serial.read();
 while (data > -1) {
     parser.processChar(data);
     data = Serial.read();
 }
 
 // poll inputs
 DcsBios::PollingInput::pollInputs();
}

/*
You need to define
void sendDcsBiosMessage(const char* msg, const char* arg)
so that the string msg, followed by a space, the string arg
and a newline gets sent to the DCS-BIOS import stream.

In this example we send it to the serial port, so you need to
run socat to read the data from the serial port and send it
over UDP to DCS-BIOS.

If you are using an Ethernet Shield, you would probably want
to send a UDP packet from this subroutine.
*/
void sendDcsBiosMessage(const char* msg, const char* arg) {
 Serial.write(msg);
 Serial.write(' ');
 Serial.write(arg);
 Serial.write('\n');
}

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

// show heading and altitude on line 3 of LCD
if (address == 0x040a ) {
hdgDegValue = (value & 0x01ff) >> 0;
}

if (address == 0xfffe ) { // end of DCS BIOS update marker (~every 30ms)
updateLCDDisplay();
}
}


void updateLCDDisplay()
{

String s(hdgDegValue);
lcd.setCursor(0,3);
lcd.print( "Hdg:" + s + " " );

}

 

Any ideas?

 

Cheers

[FSFIan]

Soo I have been trying to a heading displayed on a 16x2 lcd through Arduino.

I have had it working for the CMSP panel but had to add the following into my code:

 

 

void onDcsBiosFrameSync() {
 }

 

I notice you don't have that anywhere in your example code and have a hunch that is why I can't get my version to work.

 

You shouldn't have to add this. Which version of the Arduino library are you using?

[mblackham]

https://github.com/dcs-bios/dcs-bios-arduino-library

 

The one from here. Did a fresh download of it an hour ago.

[mblackham]

onDcsBiosFrameSync()

 

Raised it as an issue on github and got to this point thanks to OlHAll:

 

void onDcsBiosFrameSync() {

if( cmsp1Buffer.isDirty()) {
lcd.setCursor(0, 0);
char* inChar = cmsp1Buffer.buffer;
 line1 += inChar;
 line1.remove(3,1);
 line1.remove(8,1);
 lcd.print(line1);
cmsp1Buffer.clearDirty();
line1 = "";

}
if( cmsp2Buffer.isDirty()) {
lcd.setCursor(0, 1);
char* inChar = cmsp2Buffer.buffer;
 line1 += inChar;
 line1.remove(3,1);
 line1.remove(8,1);
 line1.setCharAt(7, ' ');
 lcd.print(line1);
cmsp2Buffer.clearDirty();
line1 = "";
}
}

 

But then other inputs become unusable. And I cannot see how I could use it with the common data outputs in DCS-BIOS.

 

Great work by the way. This is amazing.

[FSFIan]

You are using the current development version, which may be broken at any time (and is undergoing some bigger changes right now).

 

If you want a version that works and matches the documentation, use a release version.