FSFIan

ED provides the Export.lua interface as the official way for third-party software to interact with the simulator. That interface is pretty stable. DCS-BIOS has existed for more than two years now, and I can think of only two occasions where something broke in DCS-BIOS because ED changed something. When the multiplayer integrity check was added (which came with more fine-grained export options), disabling ownship_export ("Allow Player's Export") would break DCS-BIOS because it also disabled the function that tells you the current aircraft type; I filed a bug with ED and they made the current aircraft type available regardless of the export settings. Two months ago, the internals of how the TACAN panel in the A-10C works were changed; this required a minor adjustment to the A10C.lua file in DCS-BIOS. In that sense, ED does support DCS-BIOS and other third-party software by providing a stable foundation to build on. I don't think DCS-BIOS will ever be considered an "official utility", whatever that might mean. ED certainly does not have the time and man power to help people write and debug Arduino sketches. If you want more modules to be supported in DCS-BIOS, the solution is to make it easier to add a module to DCS-BIOS, which is something I am working on for DCS-BIOS 2.0. Right now the process is a mess that requires knowledge of Lua and DCS internals and does not provide good debugging tools -- mostly because I was still figuring everything out and had no idea what I was doing when I created DCS-BIOS two years ago.

It's on the roadmap for DCS-BIOS 2.0. The list_indication function returns a string, so 'list_indication(5)["UHF_Freq"]' does not make sense. Try using BIOS.util.parse_indication instead: local function getUHFFrequency() local ind = BIOS.util.parse_indication(5) if ind == nil then return " " end local freqStatus = ind["UHF_Freq"] -- e.g. "251.000" return freqStatus end defineString("UHF_FREQUENCY", getUHFFrequency, 7, "UHF RADIO", "UHF Frequency Display")

I doubt that you will find an off-the-shelf solution that comes with the exact software you need. Your use case is one that does not happen frequently enough to build a commercial product around: most people who want to control a relay through a button will simply hook up the relay directly to the button (and might use a double-pole switch if the switch value needs to be read by another application as well). In your case, changing the button itself would be a major hassle. If you want to minimize the programming effort, you could try this product. It seems to come with sample code for a lot of different programming languages. You'd have to build a program to read a joystick button and control the relay accordingly (AutoHotkey would probably require the least amount of learning to solve this particular problem). If you want to minimize cost, you could use a $3 Arduino clone and a $1 relay breakout board to achieve the same thing that the Numato product does (I am not familiar with the Numato board, it was just the first thing I found when googling "AutoHotkey relay board"). Which option you go with will depend on your personal trade-off between time and money, and whether learning how to program is something that interests or frustrates you.

The normal code examples pass a callback function to the IntegerBuffer or Int16Buffer class. You can also choose to pass NULL for the callback parameter and use the buffer classes "hasUpdatedData()" and "getData()" methods in your loop() function. Here's a sketch to display the A-10C's altimeter pressure setting on an OLED display. It is a good example of this technique. Lines 30 to 33 define the IntegerBuffer instances (note that we pass NULL to the last argument). In the loop() function, we check in line 52 if any of the integer buffers got new data. If so, we get the value from all of them and draw it to the display. Some background on how this works: when new data comes in, the IntegerBuffer will set an internal "dirty" flag. The hasUpdatedData() method returns that flag. The flag is reset whenever you call getData(). If you pass a callback function, every time loop() runs, the IntegerBuffer will do this: if (hasUpdatedData()) callback(getData()); So if you want to handle the flag yourself, you must not pass a callback function. This way of structuring the code comes in handy whenever you have to treat multiple values as a unit, for example because they get written to the same display and updating parts of the display is as slow as updating the complete display. Note that this helps with the performance of display updates (e.g. for SSD1306 OLEDs or MAX7219 chips), but it does not guarantee atomicity. There is still a tiny chance that there will be a ~30 millisecond age difference between some of the data. The only thing in the DCS-BIOS Arduino library that cares about atomicity is the StringBuffer (it does double buffering). It was the only case where I thought it was worth spending the extra RAM. If you want to absolutely guarantee that all of your RSBN distance digits come from the exact same frame in DCS: World, you'll either have to "misuse" a StringBuffer (if all of your data values have adjacent addresses) or you will have to implement your own class that inherits from ExportStreamListener and implements a onConsistentData() method that disables interrupts and copies the data to a second buffer. Note that onConsistentData() should do as little work as possible; any work that may take some time (e.g. digitalWrite() or display updates) should be called from the loop() method.

Mich erkennt man am hellblauen T-Shirt und dem Wuschelkopf :)

In MiG-15bis.lua, the path for the devices.lua and command_defs.lua files is wrong. They are located in mods/aircraft/MiG-15bis/Cockpit/Scripts. Since the Scripts part is missing from the path in your file, success1 and success2 will be false so the rest of the file never executes.

The MetadataStart module will tell you the name of any aircraft, whether it has DCS-BIOS support or not. If you do not have a MiG-15bis.json file despite not having any errors in dcs.log, your Mig15.lua file was never loaded. Did you edit BIOS.lua to load your Mig15.lua with dofile()? If you do, you should get an error message in dcs.log about the missing 'end' statements for the 'if' statement at the top of your file (unless you did not post your entire file). The list in Device Manager only goes up to 128000. That does not mean that your USB-to-serial chip can't support more than that. The connect-serial-port.cmd script configures the port for 250000 bps, you don't have to configure that yourself. I have only ever seen two variants of the Arduino Mega 2560, they either use an ATMega16U2 for the USB connection (as intended in the original design) or they use the cheaper CH340 chip. Both variants handle 250000 bps without issues on Windows 7 and Windows 10. It isn't. Export.lua only talks to the network. The connect-serial-port.cmd script runs socat, which talks to your Arduino over the serial port and to Export.lua over the network and sends data back and forth between the two.

Sorry, I did not notice that when I first read your post. Why are you trying to run the COM port at 9600 bps? DCS-BIOS uses 250000 bps everywhere. If the PC and Arduino use different baud rates, the RX and TX LEDs will still blink, but the data will be misinterpreted and arrive as garbage. Even if you'd get the PC and Arduino to agree on 9600 bps, it would be too slow for all the export data. On the other hand, you said everything works with the A-10C, so why would the serial comms work with the A-10C and not with the Mig-15? Can you operate the Mig-15 switch through the interactive control reference?

The aircraft name is case-sensitive. It has to be "MiG-15bis".

You are correct, you need to use 3001 for the button number. ...but it seems you are using 3000 instead. Try changing that to 3001, that should do it. If that does not work, let me know and I'll grab a Mig-15 beta key and take a closer look.

Here is a sketch that WarHog and I have written for the Vid 60 series of stepper motors. It is built on top of the AccelStepper library. Something like this will eventually be added to the DCS-BIOS Arduino library (when I get around to write proper documentation for it, etc), but right now I am concentrating on writing DCS-BIOS 2.0 so I am not concentrating on the Arduino library. In the mean time, simply copying the Vid60Stepper class to the top of the sketch will do the trick. (If it's ugly but it works...)

However many you need to. You can run several copies of the connect-serial-port.cmd script to handle multiple boards connected to separate USB ports (DCS-BIOS 2.0 will make this a bit easier to handle). If you have more than two or three boards, you should consider using an RS-485 bus. In that setup, only one Arduino (the "bus master", which has to be an Arduino Mega 2560) is connected to the PC. It is also connected to up to three RS-485 transceivers (MAX487 chips), each of which is the start of an RS-485 bus. With the MAX487, each RS-485 bus can theoretically connect up to 126 other Arduino boards (each of which needs a MAX487 chip and one free I/O pin to control the TX_ENABLE signal for that chip). The RS-485 bus support is a relatively new addition to DCS-BIOS. Several people have gotten it to work, but no one knows where the practical limits are yet (the practical limit for the number of devices on a bus might be closer to a few dozen devices instead of the theoretical max. of 126). One bus master can theoretically talk to three RS-485 buses, but I am not sure if I need to limit that number to two to guarantee reliable operation. That said, RS-485 is definitely the way to go if you are planning to build a full cockpit. If you want to play around with RS-485, buy some MAX487 chips (search for MAX487CPA, should be about $0.15 to $0.20 per chip), read its datasheet and the comments in the RS485 example sketches. For best results and to be able to use the RS-485 support, you need a board with either the ATMega328 processor (Uno, Nano, Pro Mini, several other variants) or an ATMega2560 processor (Arduino Mega 2560). I recommend the Nano for most applications: compared to the Uno, it is cheaper, smaller (easier to hide behind the panel), and it can be plugged into a solderless breadboard. Due to its smaller form factor you cannot plug a shield into it, but you won't need that for cockpit panels anyway. The Pro Mini is even cheaper and smaller, but is slightly more annoying to program (you need a separate USB-to-serial converter board). The Arduino Mega 2560 shines if you need an RS-485 bus master (which needs the 4 UARTs that the Mega provides) or you have a panel that needs more I/O pins. Some people go with Megas for everything so they need less Arduino boards. Warhog and I decided to build each panel as an independent module, so he uses mostly Nanos and Pro Minis. This allows each panel to be built and tested in independently and reduces the number of wires across panel boundaries. Multiple small Arduinos are slightly more expensive (mostly because you need a few more MAX487 chips), but you get a more modular setup and more processing power (the ATMega2560 has more I/O pins and more RAM than the ATMegea328 but it does not run faster). The 16 MHz processor on the microcontroller won't be an issue for switches and LEDs, but it becomes a relevant factor if you do timing critical things like stepper motor control.

You can (and should) use 10K or even 1K for every potentiometer. A 10K pot will only draw 0.5 mA (given the 5V supply voltage of the Leo Bodnar board), a 1K pot will draw 5 mA. As long as you stay below 500 mA for the entire board (not allowed to draw more than that from USB), you should be fine.

Ich wäre am 30.3. auch dabei, damit sind's wieder 7 :)

I went through the same lines of thought with DCS-BIOS and eventually settled for RS-485 instead of I2C. To handle multiple Arduino boards, I considered four alternatives: Connect each board directly via USB Cost: the cost of the USB cables and hubs This is fine for a few boards, but quickly runs into problems. One USB root controller can theoretically handle up to 128 devices (each hub counts as a device). In practice, some pit builders have already experienced problems at 20 devices total and had to install another USB card. For DCS-BIOS, which uses serial ports to communicate, there is also the problem that Windows likes to renumber them for various reasons and dozens of those would be very annoying to handle The Windows control panel seems to have a limit of 16 HID devices. I ran into this with my first project, which showed up as a huge composite device. I don't know if this limitation applies to DirectX or not. Use I2C Cost: free, it's already integrated into the microcontroller I had planned to use I2C as well because it is easy to wire up and does not need any additional components. After some discussion with Gadroc and others, I decided against I2C. I2C was designed for communication within the same circuit board assembly. When running it over larger distances, due to the open drain design, the possible number of devices decreases as the added wiring adds capacitance to the bus. The single-ended open drain signalling will also become susceptible to pick up interference on longer wires. There are circuits and transceiver chips that can mitigate these problems, but at that point, I2C loses its complexity and cost advantage over other solutions. CAN bus The CAN bus looks quite attractive from a software developers point of view. The hardware handles a lot of the details for you and the bus is fast enough that you will never have to worry about bus contention. Differential signalling makes it robust against interference (it was designed to work in a car, which is a very electrically noisy environment -- e.g. ignition coils). I ruled out the CAN bus for several reasons: The CAN bus needs two pieces of hardware to function: a CAN controller and a CAN transceiver. The AVR processors on most Arduino boards do not include a CAN controller, so you'd have to wire up two additional chips. CAN is a relatively complex protocol, so there are no dirt-cheap transceiver chips (the combination of a controller and a transceiver chip could be more expensive than the Arduino Nano clone they get attached to) RS-485 RS-485 has been used in industrial automation for decades. Transceiver chips are available dirt cheap on eBay and AliExpress ($0.15 to $0.20 a pop), they might be clones, surplus stock or the stuff that got rejected in QA, but most of them work fine (WarHog has encountered one batch of bad chips that did not work at all). RS-485 uses differential signalling as well (it was designed to run next to huge industrial machines and their motors). If you want to use the cheap half-duplex transceiver chips, you will need one I/O pin to switch it between transmit and receive operation. TL;DR: USB is impractical, I2C is too unreliable. CAN bus is what I might use on a commercial product where I didn't care about an extra $2 per board, could choose a microcontroller with an integrated CAN controller peripheral, and cared about time-to-market and the cost of developer time. RS-485 is what I chose for DCS-BIOS because of low cost and because the Arduino boards that are most suited for simpit panels (small size, low cost) do not have a CAN controller.

In that case, forget everything I said about clickable cockpits and cockpit arguments, you don't need those. All you need is the LoGetWorldObjects function. In multiplayer, the allow_object_export server setting needs to be on (or your Export.lua has to run on the server). I don't think that you can access any datalink from Export.lua. You might want to look at the Export.lua file that TacView installs.

There is no single document that will teach you everything you need to know about Export.lua. You will have to piece together information from several sources and do some trial and error. Start with the developer blog post that introduced Export.lua (it is no longer online, but the Internet Archive has you covered): https://web.archive.org/web/20141130081345/http://www.digitalcombatsimulator.com/en/dev_journal/lua-export/ To learn the Lua programming language (DCS uses version 5.1): https://www.lua.org/manual/5.1/ To make trial and error easier, you can use the Lua Console in my "DCS Witchcraft" project (link in my sig). Open the comments in the "WitchcraftExport.lua" file to set it up for the Export.lua environment. To manipulate controls and get data out of the sim, you will need to understand how a clickable cockpit works internally. To learn more about the concepts of device IDs, command IDs, and argument numbers, refer to the Beginners Guide to DCS World Aircraft Mods (chapter 10 IIRC). To find out which argument numbers, device IDs, and command IDs your aircraft uses, look at the files under "mods/aircraft/YOUR_ACFT/Cockpit/Scripts", especially "clickabledata.lua", "mainpanel_init.lua" and "devices.lua". To visually understand cockpit arguments, use the ED Model Viewer. It allows you to load a cockpit model and manipulate cockpit arguments to see their effect on the model. To see how it all fits together, it helps to read other people's Export.lua files, for example the ones from Helios or DCS-BIOS. Finally, here's a very quick guide to clickable cockpits as I understand it: A device is a controller that handles a certain subsystem, such as the ILS or the Altimeter. Each device is identified by a device ID. You can get the device object from Export.lua with the "GetDevice" function. You can send commands to a device by using the "performClickableAction" method of the device object. It expects two parameters. The first one is a command, which is usually looks like "device_commands.Button1" in clickabledata.lua. That translates to 3000 + button number. The second one is an "argument". Exactly how that second parameter is interpreted depends on which switch we are talking about, but often it corresponds to a cockpit argument value. Most gauges and instruments are attached directly to the 3D cockpit model. Every moving element (for example, a gauge needle) has an animation attached to it in 3DS Max. A "cockpit argument" (which is a floating point number somewhere between -1 and 1) controls which frame of the animation is shown. Cockpit arguments are numbered. For example, cockpit argument 404 in the A-10C controls the Master Caution indicator light. If its value is 0, the light is off, if its value is 1, the light is on. You can get the value of a cockpit argument from Export.lua with "GetDevice(0):get_argument_value(number)". Some displays in the cockpit are drawn to seperate textures and then plastered onto the cockpit wall. They can be exported to another monitor by editing some Lua files and using MonitorSetup.lua. For some of those displays, the list_indication function can be used to get their text contents. If you tell me what you want to accomplish with Export.lua, I may be able to provide some more specific advice.

If you want a computer to behave a certain way that is within the capabilities of its hardware (not mind reading) and you can change the software it is running (no stupid DRM), the answer to "is this possible?" is always "yes". The question you should ask is "how can it be done with the least amount of effort" and "do I have or am I willing to learn the knowledge needed to pull this off". As far as I know, VoiceAttack can switch to another profile, send key presses or launch an external application in response to a voice command. I am assuming that VoiceAttack cannot read your rotary encoder, so switching profiles won't help you. You need another program that does the following: read your rotary encoder (which could be connected to a joystick interface board so it shows up as a HID controller, or you could connect it to an Arduino board and talk to it through a serial port) send commands to DCS when the rotary encoder is turned (you can send key presses, write a custom Export.lua file, or use DCS-BIOS) provide a way for VoiceAttack to change what commands the rotary encoder sends, either through sending key combinations or through launching a second instance of the program with certain parameters (which would send a message to the first instance of the program and then exit) You could write such a program in just about any programming language. The ideal choice would depend on what you already know and what methods you choose to connect your rotary encoder and talk to DCS. If your rotary encoder shows up as two joystick buttons and you use key presses for everything else, you may be able to pull this off with an AutoHotkey script.

Looks like the function I used to open the app in a new tab was removed in Chrome 57. I changed it to open in a new window instead and released it as DCS-BIOS v0.5.2. While browsing the docs, I also noticed that Google will remove Chrome apps from the desktop browser next year. Their migration guide includes this passage: Looks like I'll have to finish the first version of DCS-BIOS 2.0 before 2018 :)

Released DCS-BIOS v0.5.2. quick fix to make interactive control reference compatible with Chrome 57 user guide: change "TemplateSketch" to "IRQSerial" (fixes #103) Please post comments in the DCS-BIOS Discussion Thread.

Thanks for the report, I can reproduce this after nudging my Chrome to update to version 57. Unfortunately, so far none of the logs I checked show any kind of error message, so this might take a while to find and fix.

I took a quick look. As an example, the C-101 and the Hawk are both listed as "For DCS World" and as far as I know both have clickable cockpits and we should be able to get to the gauge data from Export.lua. Which aircraft module are you referring to?

If you connect your panel after you are already sitting in the aircraft, you have to either wait about 10 seconds or cause the display contents to change to see it on your panel. DCS-BIOS only sends data when it has changed. Each update also includes a small bit of data that did not change, so everything gets re-sent once about every 10 seconds.

You have to copy the DCS-BIOS files to your "Saved Games\DCS\Scripts" folder, edit connect-serial-port.cmd to use the serial port that your Arduino is connected to, and then run the connect-serial-port.cmd script. The process is described in the User Guide. If you need more specific instructions, let me know at which point you got stuck.

Note down the coordinates of the desired map object. In your mission script, use world.searchObjects to enumerate all map objects within 1 meter of that point and take the first (and hopefully only) result. You now have a reference to that object and should be able to check how much damage it has taken.