FSFIan

This warning is normal on Windows 10 and does not affect the correct operation of DCS-BIOS. Your issue must be somewhere else. Please create a new thread (this one is not meant for support requests) and include your Arduino sketch and a detailed description of what you tried, what behavior you expected, and what happened instead.

Yes and no. No, there is no support for a key matrix in the DCS-BIOS Arduino Library. That means you can't expect to copy and paste a code snippet and have things work out of the box. Yes, you can use DCS-BIOS with anything you can connect to an Arduino board, if you know or are willing to learn C++. For example, to push down the master caution reset button in the A-10C, you can use the following code in your Arduino sketch: sendDcsBiosMessage("UFC_MASTER_CAUTION 1\n"); And to release it again: sendDcsBiosMessage("UFC_MASTER_CAUTION 0\n"); For more information, consult the "import protocol" section of the Developer Guide and the "input interfaces" section of the user guide. You can also read through the source code of the DCS-BIOS Arduino Library, for example Switches.h. (Those classes use a different function, tryToSendDcsBiosMessage, that won't block if it cannot send the message right away; if it returns false, it means the message has not actually been sent.) @Everyone: please excuse the long response times. I am dealing with a tinnitus right now that is preventing me from getting a good night's sleep on a regular basis.

You should also get a readable command, such as "TACAN_TEST". Can you post a screenshot of that situation (connect-serial-port.cmd window after button press on the Arduino, without DCS running)?

Sorry, I am out of ideas. From your description, I would guess that something is blocking socat from connecting with DCS, but not Chrome, so it sounds like a firewall issue. But you already disabled that for testing. The Arduino sketch must be correct because it works on the Windows 7 machine.

If some indicator does not have any interaction with the mouse (not even a tooltip), its argument number may not appear in any Lua file at all. If that is the case with this indicator, post a screenshot where the offending indicator is pointed out. I have found an efficient way to find argument numbers with the ED Model Viewer a while ago. I could then make a video tutorial about that method using this indicator as an example.

I didn't know people were still using this, it's been broken for quite a while now because I can't find the time and interest to adapt it to the new mission file format. I lost interest when I found out that I wouldn't be able to upload new waypoints into a running mission. If you PM me one of the other URLs for your instance, I can look up the admin URL. But it probably won't be of any use to you as the export function does not work with current DCS versions anymore...

If you want to mimic the real thing, Leo Bodnar offers ELMA E37 stacked rotary encoders and matching knobs, which you'll have to wire up to a suitable interface board (I think you can DIY that with a $3.60 Arduino Pro Micro and MMJoy). The off-the-shelf stacked encoders are quite expensive considering you can get normal ones as a bag of 10 for $6 from China, but apparently they are almost exclusively found in avionics and other markets where high reliability is important, so no one makes a low-quality cheap alternative. Warhog did a DIY solution with nested brass tubing and some gears for the A-10C TACAN panel: http://s221.photobucket.com/user/MRAR15/library/A10%20Cockpit%20Panels?sort=3&page=11

You are on the right track. You can use an Arduino with ATMega32u4 controller (Pro Micro, Leonardo) to send Ctrl+E or a joystick button three times. Pro Micro clones from China are about $3.60.

When I added the A-10C to DCS-BIOS, I added everything from the clickabledata.lua file. Since the eject handle is not clickable in the cockpit, it's not in DCS-BIOS.

Released DCS-BIOS v0.6.0. Changes from 0.5.5: Contributions by ArturDCS: support for Mi-8, F-86F and FW-190 For comments and general feedback use the DCS-BIOS Discussion Thread. If you need help or have found a bug, please open a new thread in the Home Cockpits forum.

@Chapman: please open a separate thread for further troubleshooting (this thread has gotten confusing in the past when several conversations were going on at once). Try the interactive control reference (see youtube video) and if that works, try using TCP instead of UDP (edit connect-serial-port.cmd and use "set PROTOCOL=TCP").

If you cannot get UDP to work, you can also edit connect-serial-port.cmd to sue TCP instead ("set PROTOCOL=TCP") as a workaround. If you do that, you will have to wait until the mission is loaded and unpaused until you start the script. If connect-serial-port.cmd works with TCP but not with UDP, you have a known workaround and can continue to look for the problem that prevents UDP from working. If it does not work with TCP either, the problem is probably not with the network communication towards DCS but with the serial communication towards the Arduino.

It's probably something simple caused by one of the dependencies chancing since I wrote the code over a year ago. I couldn't reproduce this on the first try, but I'll look at it again later this week when I have the time to do a clean install.

You can get the same result by mapping the circuit breaker bar to a joystick button and clicking a switch to the OFF position while the joystick button (or toggle switch) is held in the ON position.

Assuming the switch starts in the OFF position, if you click the "toggle" button in the control reference once, it will toggle the state of the switch from OFF to ON. It will stay in that position until you send another command. There is nothing "unnatural" about this, the same thing happens if you click and hold the mouse button in the cockpit. Once you send a second "toggle" command (or an "off" command), the switch returns to the OFF position. In the virtual cockpit, this happens as soon as you release the mouse button.

In general, argument values are somewhere in the range of -1.0 to 1.0 (inclusive). So far I haven't seen an argument value outside of this range. If you have 11 possible values and they start at 0, the range would be {0, 1}: 0.0, 0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9, 1.0 If you are not sure what values are used by the sim, you can execute "return GetDevice(0):get_argument_value(n)" where n in the argument number. That will return the current value of that cockpit argument; you just have to manually set the switch to a few different positions and call that function again. I don't know what "Tumb" stands for, it's just a term I adopted from ED's Lua files. Might be shorthand for something in Russian for all I know. It seems to refer to a control with several discrete positions. To reload your Mi-8 Lua file, all you need to do is to execute the dofile(...) line that you added to BIOS.lua. That will work in most cases. You may still run into the occasional situation where you need to reload the sim, for example if you introduce an error in an inconvenient place and things only partially load, or if the state of the simulator gets confused because you tried to send commands to the simulator that it did not expect, but this is quite rare. To execute Lua snippets in the sim, you can use the Lua console feature in DCS Witchcraft.

You don't have to open source your app just because it's talking to someting GPL-licensed over the network. Otherwse you couldn't use Microsoft Edge to talk to a GPL-licensed web server. That said, I have no problems with changing the license to MIT. I do plan to continue work on DCS-BIOS (version 2.x will be based on DCS Export Core). Development progress has slowed to a crawl right now as I am studying to get a CCNA and looking for a new job, but I hope to pick up speed again in a few months. For DCS Export Core, here is what I want to add to get to a stage where aircraft with clickable cockpits are fully supported: An action to call LoSetCommand(x) or LoSetCommand(x, y) An action to call GetDevice(id):performClickableAction(command, arg) Export keys to get the output of list_indication(i), e.g. "i7" would be list_indication(7) I haven't thought about FC3 aircraft that much yet. One option would be to add a key type beginning with "f" to call a function and get the resuts (e.g. "fLoGetIndicatedAirspeed") and then have a whitelist of allowed functions. The design goal here is that DCS export core should contain only as much knowledge about DCS internals as it absolutely needs to have and should do a minimum amount of processing or interpretation of data. When a new clickable cockpit aircraft is released, it should not require an update to DCS Export Core. We also have to think about how to distribute the DCS Export Core. We need an installer that can be bundled with other applications that depend on DCS Export Core, that will not install over a newer, already existing version, and that allows the user to select one or multiple DCS installations to install to. This means we also need a detection mechanism to find DCS installations. Looking for folders that match the pattern %USERPROFILE%\Saved Games\DCS(\..*)? and checking if they look like a DCS user data folder (e.g. have "Missions" and "Logs" subfolders) is probably good enough. At least with the new GameGui* mechanism, the installer won't have to edit any files, it only has to copy them to the right place (and to uninstall, just delete DcsExportCoreGameGui.lua and the DcsExportCore subfolder). Note that I am also planning to drop support for UDP. It's a great idea in theory and has the advantage that the order of starting DCS and the client application does not matter, but in practice it caused too many problems with firewalls. Also, with the JSON data format, an update that includes the complete state (such as after jumping into a new aircraft) will be too large to fit into a single UDP packet. If a client application has been started before DCS, it will just have to periodically try to reconnect.

As far as I know, they do not exist. FC3 aircraft handle a lot more stuff in binary DLLs instead of easily moddable Lua scripts. The two MFCD exports (LEFT_MFCD and RIGHT_MFCD, mapped to different things for different aircraft) are the only indicators that DCS can export for FC3 aircraft. Your best bet is probably UltraMFCD, which grabs the indicators by injecting itself between DCS and DirectX. I have not used it, but I think it supports FC3 aircraft.

You should update your version of the Arduino library. Starting with v0.2.10 (v0.2.11 is the current one), the Potentiometer class uses an EWMA filter and a threshold. If the default values (which I determined experimentally with three random old pots from my junk bin) do not work well for you, you can use the PotentiometerEWMA class directly: DcsBios::PotentiometerEWMA<pollInterval, hysteresis, ewma_divisor> instanceName("COMMAND", PIN_NUMBER); The defaults for pollInterval, hysteresis and ewma_divisor are 5 (milliseconds), 128 and 5. These are the ones you get if you just use the plain Potentiometer class. The pollInterval is the amount of milliseconds between polls. Any changes that are less than the hysteresis value are not sent to the PC. This value should be a multiple of 64, because a 16-bit value is reported to DCS (and checked against the hysteresis value) but the ADC is only 10 bit (65536 / 1024 = 64). The default hysteresis value of 128 gives a final resolution of about 65536 / 128 = 512 steps, which should still be enough to control a dial with a 360 degree scale. For something simple like a volume knob, the hysteresis can be increased to 256 or 512 if necessary. The ewma_divisor value determines the "dampening". Increasing this value will mitigate stutter but it will also increase the time the pot takes to respond. PS: Sorry for the late answer, I have been busy applying for jobs.

The current version of DCS-BIOS does not officially support multi-function panels. That does not mean that they are impossible to get working though (i.e. it doesn't actively prevent you from building one either). Adding several controls to the Arduino sketch that reference the same pin numbers but listen to data from different planes will work for LEDs and the generic StringBuffer and IntegerBuffer examples because currently, the address space used by different aircraft modules do not overlap. Things might break if you try to use this approach with ServoOutput though. For inputs, the same approach will work in most cases (the Arduino board will simply send both commands). It might have side effects if several aircraft use the same command names (I haven't checked, but there is no guarantee that they won't). In general, this method wastes CPU cycles and time on the serial bus. It might work for two or maybe three aircraft, but add more and you'll probably run into issues at some point. I do have plans to implement remapping of commands on the PC side in the future.

If you hardwire the MAX487 RO --> Arduino RXI connection, you won't be able to upload a new sketch without unplugging the entire Arduino Nano from your board. On the Mega and Nano, the internal USB-to-serial converter is connected to the ATMega328 RX and TX pins through 1K series resistors. This means anything you connect to those pins will take precedence, which is exactly what you want in normal operation (especially since you can't disconnect the built-in USB-serial chip). This also means that when you want to upload a new sketch through the built-in USB-serial converter, you need to ensure that the MAX487 does not interfere with it. While in the bootloader, all of the normal I/O pins will be configured as inputs, so nothing is driving your TX_ENABLE signal. This means it picks up random noise and the receiver in the MAX487 might be enabled and override the signal from the USB-serial converter. One way to prevent this would be a jumper that allows you to disconnect the MAX487 RO pin from the Arduino RXI pin. If you want to prevent interfering with the RS-485 bus when resetting the board or uploading a new sketch, you can also add a pull-down resistor to the TX_ENABLE pin to put the MAX487 into receive mode whenever the Arduino is not actively driving the signal. An alternative solution would be a pull-up resistor on the TX_ENABLE line, which would make the MAX487 default to transmit mode. This would guarantee interference with the RS-485 bus while uploading a new sketch, but it would not require you to mess with a jumper. The RS-485 bus will recover quickly and any piece of data that was interfered with or messed up should fix itself within about 10 seconds as the DCS-BIOS protocol is designed to re-send everything once in a while even if there was no change.

I have no way to tell. I don't have access to a copy of standalone Black Shark and I don't even know if the Export.lua mechanism existed back then. If you want to try adapting it, you'll have to learn Lua and maintain your own patches on top of DCS-BIOS. I'd start by looking at dcs.log and seeing which places in the code cause errors because they try to use features that didn't exist in BS1. One example would be the calls to LoIsOwnshipExportAllowed() in the CommonData module, as those settings were only introduced in later versions of DCS: World. If you are really lucky, those checks might be the only thing you have to remove.

Yes, the pinouts are compatible.

Many toggle switches and push buttons are available with screw terminals. Just search for "screw terminal toggle switch" on eBay and AliExpress, or use the filter functions in the catalog of one of the large electronics distributors such as DigiKey, Farnell and RS Components. For a solderless connection to the board side, you'll need to crimp matching connectors to your wires: EDIT: And here's a comparison of a bad and a good crimping tool: Note: I have never done this myself, as I do all my experiments on breadboards (and in the event I do want to build something permanent, I use my soldering iron instead of investing into a crimping tool). Maybe some other forum members can chime in here with actual practical experience.

Technically, it's not a new feature. I simply defined the new class in the sketch itself without having to modify the DCS-BIOS Arduino Library. This is a great way to experiment with new functionality. If this works for you, I'll consider documenting it and including it in a future release. In general, if something can talk to a 3.3V or 5V Arduino board, you can use it with DCS-BIOS. If it doesn't have a code snippet in the reference docs, you'll have to write a bit of code that reads your input device and translates that into DCS-BIOS commands, or use the generic IntegerBuffer / StringBuffer code snippet to get the data and control your indicator. The great thing about the Arduino ecosystem is that in many cases, some of this work has already been done for you and someone has written an Arduino library to talk to your device. A good example are the dot matrix displays that some poeple use for the A-10C's CMSC and CMSP displays. If something doesn't have a 3.3V or 5V digital interface, design a bit of circuitry to adapt it. In some cases, you can simply buy an existing breakout board. If the ATMega controllers are too slow (e.g. large graphic displays), other Arduino-compatible boards with faster processors are available. Those will only work in DEFAULT_SERIAL mode, but on the other hand, they can mitigate the disadvantages of DEFAULT_SERIAL mode through sheer processing power and/or a bigger receive buffer. You won't be able to use those boards as a RS-485 slave, but I don't think a typical cockpit will need more than one or two of these, so this shouldn't be an issue.