FSFIan

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). 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.

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.

I have updated the version of MiST in me-3d-view.miz to the current 4.1.61 one and pushed it to GitHub. That makes it work on 1.5.3 for me.

With enough determination, you might find a way to mess up the mission in a way that trips up the mission editor but not the actual game. But any method you can possibly come up with can be countered by an equally determined attacker. In the end, all of the data you need to play the mission needs to be there, and that means that you can use it to recreate all of the data you need to edit the mission. Say the trick mentioned in the post above still worked -- yes, it would prevent people from casually editing your mission file, but it's easy enough to inject a small script into the running mission and use the DCS scripting engine to reconstruct that information. Even if you do not publish the mission but instead only host it on your own MP server, anyone who joins that mission can save a track file and easily recover the mission data from that. The best you could do is to implement a significant portion of your mission (e.g. spawning of key units) as a Lua script and obfuscate the hell out of that code. My recommendation would be not to bother with it and allow other mission designers look at how you did things and learn from it.

Ich hab's gerade mit 1.5.3 getestet und mit dem in diesem Post beschriebenen Verfahren klappt das ohne Probleme für CMSP, CMSC und Uhr (und wahrscheinlich auch für alles andere, hab meine alte MonitorSetup.lua nicht wiedergefunden und deshalb jetzt erstmal nur die Dinge selbst getestet, die bei dir nicht funktioniert haben).

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. 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).

I had never tried it with DCS: World 2.0 because I thought trying to load two instances of Nevada was hopeless with the 8 GB of RAM I had at the time (and because this is only a proof of concept anyway). Now that I have upgraded to 24 GB, I gave it a try. Turns out it works with the 2.0 Open Alpha if we use a current version of MiST. I have created a me-3d-view-nevada.miz and pushed it to GitHub. I won't add it, as all of my DCS tinkering time is taken up by DCS-BIOS nowadays. The script is released under GPLv3 though, so feel free to fork it and give it a try. This is also something that I wouldn't want to spend too much time polishing, as it depends on implementation details of the DCS: World mission editor. It wraps a few internal functions to grab their parameters and send them out in a UDP packet before calling the original function, so it may break with each update of DCS.

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 :)

Works for me running two instances of the current release version, 1.5.2.49392. Sorry for the delay, it took a while to find the time to set this up again after my recent clean install of Windows 10.

Take another look at post #194. It explains the change in the rs-485 branch. onDcsBiosWrite() is gone, instead you would use code like this: void onLcpAuxInstChange(unsigned int alt) { // your code here } DcsBios::IntegerBuffer lcpAuxInst(0x114c, 0xffff, 0, onLcpAuxInstChange); The change was made to adapt to some internal changes and to make accessing integer values more consistent with how string values (i.e. the StringBuffer class) work.

It will emit a warning ("cannot compute FAST_CWD pointer"), but it will still work just fine. I upgraded to Windows 10 on the weekend (did a clean install), and it works despite the warning. When I was writing post #294 I was looking at the third screenshot in post #293, where the error message is "The system could not find the path specified." Note that we have seen two different messages so far. The first is "The system cannot find the path specified." This is an error, probably caused by running the script in some unexpected way (e.g. directly from the command prompt without changing the working directory first, or directly from a ZIP file). The other message, seen in the second and fourth screenshots in post #293, is "cannot compute FAST_CWD pointer". This is only a warning, probably about some cygwin internals that the socat program does not even use. Socat is working as intended in those screenshots. If there is still no data being displayed in the console window, this could be caused by a missing "-v" option to socat (but to cause that you would require you to edit the script file), DCS not sending data (not running, DCS-BIOS not installed, mission paused, active pause enabled), or a firewall interfering. If you want to, we can meet up on Skype or TeamViewer to troubleshoot this. Just PM me a time that is convenient for you. I have a very flexible schedule right now because lectures have ended for this semester, so I can probably be there no matter what your time zone is.

You need to extract the ZIP file before you can run the script. Navigate to the ZIP file, then click "Extract all" in the "Extract" tab. Alternatively, install 7-zip (http://7-zip.org) to be able to extract just about any archive type via the right-click context menu. 7-zip is one of those programs I install immediately after reinstalling Windows, along with VLC, Notepad++, Google Chrome, Firefox, Dropbox, GIMP, Inkscape and Steam. In their infinite wisdom, in recent Windows versions (I think starting from Windows 8) Microsoft has decided to call ZIP files "compressed folders" and hide the differences from regular folders from the user. When you double-click the script inside the ZIP file, Windows will extract the script file to a temporary location and run it from there, where it won't be able to find the rest of the files. I'd recommend to go to "View -> Options -> Change folder and search options", select the "View" tab and uncheck "Hide extensions for known file types" -- another change I make immediately after installing Windows. PS: Thanks for the detailed report! I would never have thought of this without being able to spot it in the first screenshot.

You need to run the script from the original location. It expects the "socat" directory to be in its working directory. You are running the script with "C:\Windows\system32" as the current directory, so it is looking for "C:\Windows\system32\socat\socat.exe", which does not exist. If you simply double click the script in Windows Explorer, it should just work. Are you trying to run it from a command line prompt without first using "cd" to change to the script's directory? Even if you create a shortcut, the working directory will be set correctly by default.

The error is ERR_CONNECTION_REFUSED, which means that no program is listening on port 7778. That means something must go wrong when DCS-BIOS attempts to start the TCP server or it does not even try. I just noticed that BIOSConfig.lua in your post #276 had the TCPServer commented out, which is not the default. Please double check that your BIOSConfig.lua has the following contents (as seen in post #277): BIOS.protocol_io.connections = { -- BIOS.protocol_io.DefaultMulticastSender:create(), BIOS.protocol_io.TCPServer:create(), -- BIOS.protocol_io.UDPSender:create({ port = 7777, host = "192.168.1.177" }), BIOS.protocol_io.UDPListener:create({ port = 7778 }) } If you have verified that the TCP server line is not commented out and it still does not work, post the contents of dcs.log again.

Check dcs-bios.log for errors again. Before you try the Chrome application or the script below, make sure DCS is running and the mission is unpaused. Once the control reference app is open in Google Chrome, press Ctrl+Shift+C to open the developer console, switch to the "console" tab and post a screenshot. If the chrome extension fails to open the TCP connection, the error message will be printed to the console. Save the following as "tcp-console.cmd" in the same folder as connect-serial-port.cmd and run it: socat\socat -v TCP4:localhost:7778 - It should connect to DCS-BIOS and print any data it receives to the console window. The data is not plain text so it will look like a bunch of garbage. Check that no other program is already listening on TCP port 7778 (I assume Windows 10 still comes with a Resource Monitor program). The only plausible explanation I have at this point is that some firewall / antivirus / malware / strange Windows 10 quirk interferes with the TCP connection. I have not changed the way DCS-BIOS communicates with the network in over a year and I know there are people who are using it successfully on Windows 10. My own development and testing is on Windows 7 at the moment, I still have to upgrade.

No, you don't. Is it still not working even after disabling multicast UDP?

If you followed the User Guide and downloaded the latest DCS-BIOS release version, you have that file. It's in the top level of the ZIP file, next to the "socat" and "Scripts" folders. It is the script you need to run when you have connected your Arduino over USB; it forwards data between the (virtual) COM port and DCS-BIOS.

My bad, it's called connect-serial-port.cmd.

I haven't seen that one before. What OS, firewall and/or antivirus are you running? You can try to disable multicast UDP and use TCP instead. Edit BIOSConfig.lua and comment out the MulticastUDPSender line so it looks like this: BIOS.protocol_io.connections = { -- BIOS.protocol_io.DefaultMulticastSender:create(), BIOS.protocol_io.TCPServer:create(), -- BIOS.protocol_io.UDPSender:create({ port = 7777, host = "192.168.1.177" }), BIOS.protocol_io.UDPListener:create({ port = 7778 }) } Then use the following connect-to-serial-port.cmd script instead: REM Specify the number of the COM port your Arduino is connected to: set COMPORT=5 set /A TTYNUM=%COMPORT%-1 mode COM%COMPORT% BAUD=500000 PARITY=N DATA=8 STOP=1 TO=off DTR=on socat\socat -v TCP4:localhost:7778 /dev/ttyS%TTYNUM% pause

You'd need to use software that can talk to several serial ports at the same time, such as ArturDCS's ComHandler. With 40 ports that can and will be randomly assigned new names by Windows whenever it feels like it, that sounds like a nightmare to manage. People have run into problems with more than 20 USB devices before (depends on what your USB root controllers and USB hubs can support) Cable management gets easier with a daisy-chained RS-485 bus compared to a tree of USB hubs It's hard to say which solution is the most expensive. Assuming you want to connect 40 Arduinos via USB using 7-port hubs for 9 EUR each, you need 7 hubs, which cost 63 EUR and give you 6*7+1=43 ports, for a cost of 1,46 EUR per port (assuming the combination of those cheap hubs would even work reliably). For a 43-panel RS-485 setup, you'd need one Arduino Mega and 45 RS-485 transceivers, which you can get for about 17 EUR total (40 cents per connected panel). If you want to use Ethernet cable, you need 2 Rj45 sockets per panel (an additional 30 cents per panel). Since Rj45 sockets do not fit on standard veroboard, you also need a custom PCB. If you are doing one anyway for each panel, you can just add the footprint for the socket to that. Otherwise, add another 1 to 2 EUR per panel, or use another type of connector. None of these back-of-the-envelope calculations include the cost of USB or Ethernet cables.

Das geht mit der ActionButton-Klasse: DcsBios::ActionButton vhfamFreq1Dec("VHFAM_FREQ1", "DEC", 5); DcsBios::ActionButton vhfamFreq1Inc("VHFAM_FREQ1", "INC", 6); Wenn du mit diesem Code einen Taster zwischen Pin 5 und GND und einen zwischen Pin 6 und GND schaltest, sollten die den ersten Frequenzknopf vom VHF AM-Radio bedienen. PS: Bitte in Zukunft nur an einer Stelle nachfragen, das führt sonst nur zu unnötigem Mehraufwand (da ich nicht den Eindruck erwecken will, dass Fragen irgendwo unbeantwortet bleiben). Wobei das jetzt noch nicht so schlimm war, den Rekord hält der Typ, der innerhalb von einer Stunde hier im öffentlichen Forum, bei mir per PM, bei GitHub und als YouTube-Kommentar gefragt hat...

The following should let you change the first VHF AM frequency selector with push buttons connected to pins 5 and 6: DcsBios::ActionButton vhfamFreq1Dec("VHFAM_FREQ1", "DEC", 5); DcsBios::ActionButton vhfamFreq1Inc("VHFAM_FREQ1", "INC", 6); The button should connect the Arduino pin to GND when pushed down.

With the Saitek pedals, you will also have to invert the toe break axes (click "axis tune" and check the "invert axis" checkbox). Once in the cockpit, use the controls indicator (Ctrl+Enter) to verify that the binding is working as intended.

The simplest way is a second Arduino board connected over a second USB cable. The RS-485 solution is only slightly more complex to use software-wise (but you need to wire up a Mega and the RS-485 transceiver chips). At this time, RS-485 also has not been tested very much, so there might be occasional errors I have overlooked. The most cost effective solution would be to use one or more serial-in, parallel-out shift registers (e.g. 74HC595). To make that work, you need to know or learn some C++. Not with the current version of DCS-BIOS. The wingtip lights are part of the external model, so there are no corresponding cockpit arguments for DCS-BIOS to export. I do know of a possible way to get that information, so when I eventually find the time to make a DCS-BIOS 2.0 I will add it if I can.

As long as the Export.lua code that you use for OpenCockpits gets the basics right (preserving existing callback functions), it will work alongside other software like Helios, TARS or DCS-BIOS, so you can continue to use it. That question is pretty off-topic for this thread. It's also pretty much impossible to answer without more information (e.g. the complete code in question). I don't think it's the receive() function though, AFAIK both Helios and DCS-BIOS call that once per frame without a drastic performance impact.