DCS-BIOS Discussion Thread

Unfortunately, post #194 is the only documentation there is right now for the rs485 branch.

For the latest stable release, the User Guide should have you covered.

For the RS-485 branch, right now you need to read the User Guide, post #194 (which covers the differences in the Arduino library between the rs485 branch and v0.1.4 of the Arduino library), and the MAX487 datasheet (for pinouts).

I have not tackled the task of properly updating the documentation for the rs485 branch yet -- I only want to document things when I know they won't change much in the future, and to know that I need to run a few more tests. Over the last few weeks, components for a ten board test setup have started arriving; once I get the PCBs themselves and the RJ45 sockets, I can start assembling all of that.

That said, keep asking questions, however stupid you think they may be. Because another way to get some of that documentation written is to make answering all the questions more work than writing the documentation :)

That means, my "code" will work?

Ian;2682353']...once I get the PCBs themselves and the RJ45 sockets, I can start assembling all of that. ...

Edit: (31th of March)

Sorry for my sudden dissapearance. I had urgent OffTopic things to solve aside.

Meanwhile my Backlight code works. It isn't worth a new post so I set it here (maybe someone finds it sometime :)

....
void loop() {
 DcsBios::loop();
}

// Backlighting
void onLcpConsoleChange(unsigned int alt) {
  analogWrite(PWM_Pin, alt/1024); // this value under slash is subject to try-and-error
} 
DcsBios::IntegerBuffer lcpConsole(0x1150, 0xffff, 0, onLcpConsoleChange);
                // value 0x1150 (or other Lights) you get from control-reference.html

Good day all. Regarding my previous post, I remembered that I had the Saitek PZ55 flight switch panel plugged into my computer which also uses DCS-Bios to operate. Even though I wasn't running the ProUsbPanel application, the fact that I had it plugged into the computer was causing problems.

So I unplugged all my usb devices except for the mouse, keyboard, webcam, and arduino Mega2560.

The problem I am having now is that I get an error message when I compile the MasterCaution sketch from the dcs-bios-arduino-library-0.1.4. Please see attached pic for error message.

So I commented out the push button and only tried to use the built in LED on pin 13 for master caution. And that part as well is not working for me. The LED just turns on and stays on as soon as the socat file is executed. The A-10C cockpit is powered off on the ramp so the LED should have remained off.

If I run default Blink sketch from Arduino, that part works so I know the board is communicating.

Any suggestions?? Thanks.

The message you are seeing is just a warning, not an error (I'll fix that once I get back to my DCS computer). You can safely ignore it.

The LED just turns on and stays on as soon as the socat file is executed. The A-10C cockpit is powered off on the ramp so the LED should have remained off.

Are you sure you are looking at the Pin 13 LED and not at the RX LED?

Try turning on the battery switch in the A-10C and then provoke a master caution (e.g. by turning the radar altimeter on and back off again) and see if you get a blinking pin 13 LED.

You can also add the push button again and see if that works (as I said, you can ignore the compiler warning).

Can I listen to 239.255.50.10:5010 from an other computer on the same network or is it only computer local?

Can I listen to 239.255.50.10:5010 from an other computer on the same network or is it only computer local?

In theory, yes. In practice it will depend on the configuration of any routers and (managed) switches on the network.

For connecting from other computers, I'd use TCP. You should re-try establishing the TCP connection (once every second or so) until you succeed so the user can start your application before starting DCS.

I plan on phasing out multicast UDP in whatever becomes DCS-BIOS 2.0 because it just does not seem to work with some firewall/antivirus setups. I may keep the option of configuring unicast UDP if requested to accomodate use cases where repeatedly trying to establish a TCP connection is really inconvenient, such as Arduino Ethernet shields.

OK thanks for the info. I will add TCP functionality to Flightpanels for using several computers.

Ian;2687842']In theory, yes. In practice it will depend on the configuration of any routers and (managed) switches on the network.

 

For connecting from other computers, I'd use TCP. You should re-try establishing the TCP connection (once every second or so) until you succeed so the user can start your application before starting DCS.

 

I plan on phasing out multicast UDP in whatever becomes DCS-BIOS 2.0 because it just does not seem to work with some firewall/antivirus setups. I may keep the option of configuring unicast UDP if requested to accomodate use cases where repeatedly trying to establish a TCP connection is really inconvenient, such as Arduino Ethernet shields.

Can I use socat for sending DCS-BIOS data to two computers on the same network using TCP?

OK thanks for the info. I will add TCP functionality to Flightpanels for using several computers.

OK.

Now I have my hardware running (just at a test bed cause my good look'n Boards aren't working :music_whistling:).

RS-485 Communication between DCS-BIOS <---> MEGA <---> NANO seems running.

But nothing happens. Neither in Virtual Cockpit nor in AAP (NANO).

On both boards (MEGA and NANO) is a flickering light (TX - maybe), communication in cmd.exe runs upwards. Looks fine.

To see, what happen if I actuate a switch on AAP I paused DCS.

Attached pic shows at red line when I paused DCS.

Below the red line is with every switch command an extra line (or two?) appeared.

Where can I start to look for the fault.

I have no idea, what the shown code means.

Is there some hardware broken or is this an DCS-BIOS issue?

Thank you.

Can I use socat for sending DCS-BIOS data to two computers on the same network using TCP?

Probably, it's a network swiss army knife. Check its documentation.

I don't quite understand what problem you are trying to solve here, though. If you want your Flightpanels application to run on another computer, simply have it establish a TCP connection to the TCP server that is already built-in to DCS-BIOS (running on port 7778).

Where can I start to look for the fault.

I have no idea, what the shown code means.

 

Is there some hardware broken or is this an DCS-BIOS issue?

If everything were working as intended, you would get a line of human-readable text (such as "AAP_CDUPWR 1") whenever you actuate a switch on your panel. The data you are receiving is not correct, so my first guess would be communication problems on the RS-485 bus. However, if that were the case, it's a miracle that whenever you flip a switch, you get exactly the same garbage -- because the length byte in the protocol would also get messed up regularly.

Please open a new thread and post or link to the code that each Arduino board is running. This sounds like a problem that might need a lot of back-and-forth communication to solve, especially because this is the first time I am thinking about how to debug this stuff without an oscilloscope or logic analyzer at hand.

My guess is a hardware problem, but as the software is fairly new, I don't want to rule that out either.

It might be easier and less frustrating to use Skype or TeamSpeak+TeamViewer for some live troubleshooting. PM me if you are interested, my schedule is pretty flexible right now (no lectures until next semester) and we are on the same time zone anyway.

You can't send the same TCP stream to two computers. Each will have to have it's own connection and DCS-BIOS will have to send data to each client. I think phasing out UDP is a bad idea for this reason. TCP has significantly more overhead and then your are adding additional overhead per client. While this overhead is small in the grand scheme of a big computer, it does add up when you are talking milliseconds between transmissions. The overhead is huge when dealing with low power micro-controllers.

You can do UDP without multi-casting, which is what Helios export was setup to do by default. Default to just sending UDP packets to localhost or default to TCP, but don't remove the UDP capability.

You can't send the same TCP stream to two computers. Each will have to have it's own connection and DCS-BIOS will have to send data to each client. I think phasing out UDP is a bad idea for this reason.

You can't send the same unicast UDP stream to two computers either, so what's your point here? Multicast UDP is nice in theory, but it's a nightmare to support in practice. There were several people who just couldn't get it to work, and the fix was to switch to TCP.

You can send to the broadcast address, but I wouldn't be surprised if that approach would yield the same amount of firewall issues (and thus "support calls") as multicast UDP does. And then there will be that one guy who has a network setup where his wireless is on a different broadcast domain to the wired ethernet and he'll wonder why he can't connect to DCS-BIOS from his tablet/smartwatch/fridge/whatever.

TCP has significantly more overhead and then your are adding additional overhead per client. While this overhead is small in the grand scheme of a big computer, it does add up when you are talking milliseconds between transmissions. The overhead is huge when dealing with low power micro-controllers.

The context is important here.

I agree with you when talking about microcontrollers, which is why I said I will keep the option to configure unicast UDP streams if people are actually using Ethernet shields. But IMO, on a microcontroller you'd want to use either a direct serial connection or RS-485, because both of those have a lot less overhead than parsing raw Ethernet frames, let alone UDP or TCP.

If we are talking about a PC, smartphone or tablet on your local network, then yes, TCP does have more overhead than UDP, but it's not significant. TCP probably needs a few kilobytes more RAM -- insignificant when you measure the amount of system memory in hundreds of megabytes. It will also need a few more CPU cycles to maintain its state, but I would be very surprised if you could even measure that.

If a TCP packet gets lost, it will need to be retransmitted and it may increase the latency of a few subsequent packets which may have to wait for it. We are on a local network, so the common case is that no retransmissions occur. If you do have retransmissions using TCP, that means that you'd have packet loss if using UDP, which would be even worse.

The one big advantage of UDP over TCP is that the order in which you start DCS and the client application does not matter. But it's not that hard to implement some "retry connecting once a second" logic into the client application.

You can do UDP without multi-casting, which is what Helios export was setup to do by default.

Correct me if I am wrong, but that only allows one application (Helios) to connect at a time. Which means the next application does not only establish its own connection to DCS, but comes with its own Export.lua file, so the data is not only sent twice, but also calculated twice.

TL;DR: A properly implemented TCP solution is easier to support, more flexible, and creates no difference in user experience. Network-connected microcontrollers are the exception, and if enough people are actually using those instead of RS-485 or USB-serial connections, I'll keep the option to configure unicast UDP streams for those. If DCS-BIOS 2.0 drops UDP support, you can still run "socat tcp-connect:localhost:PORT udp-recv:LISTENPORT!!udp-send:ip:port" to bridge between the two.

I am stumped trying to figure out how to get DCS BIOS installed correctly. I have gone through the installation steps multiple times and I'm fairly certain I've done it correctly each time (just copy/pasting into the Saved Games/DCS/Scripts (or something similar - I'm reciting from memory right now). I'm positive that I did not duplicate the Scripts folder (.../Scripts/Scripts/DCSBIOS). *EDIT* - I have only copied and pasted the file into the Scripts folder and edited the Export.lua with the one line of code, also via copy/paste in Notepad++. I am only reasonably confident I have done these two steps correctly, but if there is anything else I have forgotten to do aside from those two I am not aware.

When I run the Chrome extension to get live updates it doesn't seem to be connected to DCS at all. It does not know any values, and it cannot change any values.

I'm trying to get DCS BIOS running to support the Flight Panels mod to run a Saitek switch panel. I've verified that the Flight Panels mod is working by assigning the switches to basic keyboard commands and using them in-game. The problem seems to be with DCS BIOS not working in order to use all of its wonderful features in conjunction with Flight Panels.

I'm sorry I don't have more information. I haven't been presented with any actual errors to post. I am running DCS through Steam, and I'm on Windows 8.

Any and all help is appreciated. Thanks!

UPDATE! I seem to have it working by getting rid of the old Export.lua and using the one that was provided with DCS BIOS. I don't know why it took me 3 hours to try that, and I'm not sure it wasn't working by editing in the line of code with Notepad++ because I'm pretty bad at this sort of thing. At any rate, I think this should only render one or two other unrelated things inoperable, and that's acceptable for now at least.

Thanks again!

here's my latest MiG-21bis Main powerpanel, featuring RS-485 integration.

its a custommade Arduino shield :D :D

I made design error.. the USB is pointed to right, interfering with the RJ-45 (to be soldered).

my dcs-bios shield has got;

* I2C-ports, for expansions

* 2x dualpurpose (analog) expansion ports

* Custommade silkscreen logo.

It was made by http://DirtyPCBs.com

Nice pappavis.

I have chosen another concept, with generic communication boards and external breakout boards for input and output.

I have chosen another concept, with generic communication boards and external breakout boards for input and output.

I like that idea. What external breakout boards have you already built?

I like that idea. What external breakout boards have you already built?

None yet, but I'm more or less done with the design. Just have to order them...

Ian;2690083']Not going to happen' date=' unless you can show me a piece of Lua code that can get the airspeed in any aircraft. The CommonData module is only for those pieces of data that can be reliably retrieved independent of the aircraft type.[/quote']

 

of course. if i can find lua code related to airspeed, can we have airspeed in commondata?

MEGA RS485 Slave

Hi Ian,

is it possible to use Mega 2560 at RS485 Slave ?

i have try to upload the exemple RS485 Slave sketch from the Arduino librarie 0.1.4 or 0.2 in a MEGA 2560 and i have many compilation errors..

In file included from C:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino/Arduino.h:30:0,

                from sketch\RS485Slave.ino.cpp:1:

C:\Users\M2000C\Documents\Arduino\libraries\dcs-bios-arduino-library-0.2.0/DcsBiosNgRS485Slave.cpp.inc: In function 'void DcsBios::USART_RX_vect()':

C:\Users\M2000C\Documents\Arduino\libraries\dcs-bios-arduino-library-0.2.0/DcsBiosNgRS485Slave.cpp.inc:187:6: warning: 'USART_RX_vect' appears to be a misspelled signal handler [enabled by default]

 ISR(USART_RX_vect) { rs485slave.rxISR(); }

     ^

C:\Users\M2000C\Documents\Arduino\libraries\dcs-bios-arduino-library-0.2.0/DcsBiosNgRS485Slave.cpp.inc: In function 'void DcsBios::USART_TX_vect()':

C:\Users\M2000C\Documents\Arduino\libraries\dcs-bios-arduino-library-0.2.0/DcsBiosNgRS485Slave.cpp.inc:188:6: warning: 'USART_TX_vect' appears to be a misspelled signal handler [enabled by default]

 ISR(USART_TX_vect) { rs485slave.txcISR(); }

     ^

C:\Users\M2000C\Documents\Arduino\libraries\dcs-bios-arduino-library-0.2.0/DcsBiosNgRS485Slave.cpp.inc: In function 'void DcsBios::USART_UDRE_vect()':

C:\Users\M2000C\Documents\Arduino\libraries\dcs-bios-arduino-library-0.2.0/DcsBiosNgRS485Slave.cpp.inc:189:6: warning: 'USART_UDRE_vect' appears to be a misspelled signal handler [enabled by default]

 ISR(USART_UDRE_vect) { rs485slave.udreISR(); }

     ^

In file included from C:\Users\M2000C\Documents\Arduino\libraries\dcs-bios-arduino-library-0.2.0/DcsBios.h:28:0,

                from C:\Users\M2000C\Documents\Arduino\libraries\dcs-bios-arduino-library-0.2.0\examples\RS485Slave\RS485Slave.ino:14:

C:\Users\M2000C\Documents\Arduino\libraries\dcs-bios-arduino-library-0.2.0/DcsBiosNgRS485Slave.cpp.inc: In function 'void DcsBios::setup()':

C:\Users\M2000C\Documents\Arduino\libraries\dcs-bios-arduino-library-0.2.0/DcsBiosNgRS485Slave.cpp.inc:195:3: error: 'PRR' was not declared in this scope

  PRR &= ~(1<<PRUSART0);

  ^

exit status 1
Erreur lors de la compilation.

no problem with Nano or Uno...

Thanks for your help

Exo7

Nice job there Pappavis

CDU Display works!

Thanks to the new release of DCS-BIOS, I finally got the CDU Display working with an Arduino UNO and a cheap 3.95 inch LCD from Aliexpress. Almost give up and go for the python pygame with raspberry pi approach. Big thanks to Ian and whoever contributed. :thumbup:

I found some small discrepancies in two CDU pages, not sure if Ian want to look into it. I know the issue was not from my side of implementation because I tried pygame code and got same result.

I think I know how to look into this and fix it.

In Export.lua, you don't get the CDU text as a single string. Instead, you get a table of key-value pairs, where parts like the "FPMENU" page title and the "D5/B1" label in the top right are separate entries. You then have to piece the complete display contents back together from these snippets, so you have to know where they go based on their key in the table.

I extracted most of the mapping of keys to display locations from the CDU indicator Lua files with a Python script, but the results did need a few manual corrections. Guess I just need to add a few more.

Can you post your code and a mini build log (e.g. the type of display used) in a separate thread? I'd be interested to see which graphics library you are using and which process you used to get from the in-game texture to a font that your graphics library can use. Is that a 320x240 display? Looks great!

@Exo7: I will add support to use the Mega as an RS-485 slave in the future. It's not a big change, I just need to find the time to test it. I am a bit busy with university right now.

Thanks for the quick reply, I will post some detail tomorrow.

Thank you Ian, this is quite normal , priority is your studies.

@++

Exo7

Good day. I'm using DCS Bios v0.5.0 with arduino-library-0.2.1(master). I'm interested in setting the debounce delay time for switches. For example on my home made CMSP panel, if I rotate the mode knob between the difference positions, it reads it as an off state moving between say position 3 and 4. This happens even though the off state is tied to the PIN_0 position. I think if I put a delay of say 25ms I could pass from position 2 to 3 without triggering the off position.

I saw once piece of code by Gadroc on github dealing with action buttons, but I don't think it will work with the latest version of DCS Bios.

Has anyone been using debounce code in their sketches that you can share? Thanks.

const byte cmspModePins[5] = {PIN_0, PIN_1, PIN_2, PIN_3, PIN_4};

DcsBios::SwitchMultiPos cmspMode("CMSP_MODE", cmspModePins, 5);