FSFIan

Skorak: Try testing it without your physical switch. Take a wire and connect one end to ground. Touch the other end to pin 7 -- the switch should go up. Break the contact, the switch should go to the middle position. Touch pin 9, the switch should go down. If that works, your switch was not wired correctly. If it does not work, post your code here so I can take a look.

Yes, it is. This solution connects a PS/2 keyboard to an Arduino board which talks to the PC over a serial port. With DCS-BIOS, you can then use it to control the A-10C and UH-1H (and any other aircraft that gets supported in the future). You could also write another piece of software that talks to your Arduino and does something else with the information like feeding vJoy or simulating key presses. The problem with the obvious solution -- plugging in a second USB keyboard -- is that this keyboard will automatically be snatched up by the Windows HID driver. Writing software to make that work requires knowledge of windows device driver development, which I do not have, so I can't even say if this would be possible with any reasonable amount of effort.

Yes. For the Caution Lights panel, you should look into a separate LED matrix driver chip like the MAX7219. These have an integrated, software-controllable constant current drive, so you can have programmable display brightness.

Yes. See Wikipedia: Keyboard Matrix Circuit. You won't need a diode for each button because none of these will be pressed simultaneously anyway. There are existing Arduino libraries that make it easier to work with a keyboard matrix. You will need to write some code to send the right command to DCS-BIOS when you get a key pressed or key released event. The DCS-BIOS Developer Guide describes how the import protocol works (i.e. what strings you have to send over the serial port). You can also look at this example of connecting a PS/2 keyboard to the CDU for inspiration.

You can export the CDU as a viewport, just like you can with the MFCDs. To make that work, you need a display connected to a video port on your computer. There may be a way to optimize your existing Arduino sketch and make it work, but without seeing the code I can't even take a guess. If you only redraw what has actually changed, an Arduino could be powerful enough to do an adequate job. Or you can replace the Arduino with something more powerful, like a Raspberry Pi.

I don't know if there is a way to do it in the mission editor. Because .miz files are ZIP archives, you could automate the task with a batch file. Look at 7-zip's "u" (update) command. Try something like this: 7z u mymission.miz myscript.lua You will have to test what happens if you do this while the mission editor is running (it may overwrite it again with the old version when you save). But I guess that clicking File -> Save in the ME, running your batch file, then clicking File -> Load in the ME is still more convenient than deleting and recreating your trigger action(s), especially if you are updating multiple script files at once.

I haven't tested the potentiometer code much at all (only threw it in because the naive implementation was quick to do, tested it with a single pot without any other controls connected). The problem with the current approach is that even a slightly jittery pot will constantly send data, so it may make other controls unresponsive -- but the expected effect is that the pot itself should continue to react. Merging in this pull request may already improve things somewhat (I need to find time to prepare, test and release a new version of the Arduino library). If they used to work and there are problems now, the obvious question is: what has changed? Did you add more controls to your sketch? Did you update the Arduino library or DCS-BIOS? Does it work again after you reset the Arduino?

You won't. Maybe someone else will develop a separate Arduino library that makes it easy to use a specific type of stepper motor or continuous rotation servo with DCS-BIOS. The DCS-BIOS Arduino library does what I want it to do: it makes simple things simple (buttons, switches, LEDs) and complex things possible (by giving you the raw data to send to a display/stepper/whatever using a third-party Arduino library of your choice). The internals need an overhaul to make it more reliable when handling a lot of controls and I want to have a standard way of connecting multiple Arduinos over an RS-485 bus. After that, while I will continue to maintain DCS-BIOS and fix bugs in the A-10C and UH-1H export modules, I plan to focus my attention on building a DCS Witchcraft-powered mission. The target audience of DCS-BIOS (when used for powering physical panels) was always "people who can or are learning to program Arduino code".

There is no support for stepper motors in the DCS-BIOS Arduino library. Using steppers is like using displays: you need to add another Arduino library that knows how to talk to your stepper motor and write a few lines of glue code.

DCS-BIOS uses the string "UUUU" as a synchronization sequence. If you get that in your output, it means there are performance problems in your sketch, i.e. it is too much for your Arduino to handle (while writing data to the display, the serial receive buffer is getting full, new incoming data is ignored and the parser becomes confused). The current DCS-BIOS Arduino library is based on the default Serial library, which is not as optimized as it could be, so there is room for some improvement in the future.

Right, that's because you had to disable the TCPServer part of DCS-BIOS. One more thing you could try is to run the TCP server on a different port (if port 7778 is already in use by something else). In BIOSConfig.lua, specify the port for the TCPServer like this: BIOS.protocol_io.connections = { BIOS.protocol_io.DefaultMulticastSender:create(), --BIOS.protocol_io.TCPServer:create({ port = 10123 }), BIOS.protocol_io.UDPListener:create({ port = 7778 }) } If that works, you can change the port that the control reference docs tries to connect to in line 109 of doc/js/dcs-bios-connection.js.

The command numbers for the HARS_HDG and HARS_PTS controls were swapped, which led to the weird behavior you described. It's now fixed in the current master branch. BTW, if you encounter something similar again, first test with the interactive control reference documentation. If you can reproduce the error with that, you know that it's not a fault in your Arduino code or hardware :) The Switch2Pos class is used for both push buttons and toggle switches, because electrically and logically they look exactly the same -- the only difference is in the latching behavior of the mechanical construction.

It's possible with the right USB descriptor. The current implementation here is a composite device consisting of two 128-button joysticks. It could be changed to show up as four 32-button joysticks instead. That way you can get more than 32 buttons to applications that use the Windows Multimedia API instead of DirectInput. However, any such devices will be limited to a maximum of 16 joysticks. I tried, once you have 16 game controllers connected, new ones just don't show up in the Control Panel. In my USB Rotaries experiment (which used V-USB), I programmed the ATMega168 microcontroller to appear as an arbitrary number of 32-button, 8-axis joysticks.

While executing Lua code, the simulation is frozen, so the simulation time does not advance while your loop is executing so it becomes an infinite loop. Check out mist.scheduleFunction().

In general, you can use every pin you have and all analog pins can also be used for digital I/O. There are a few exceptions: Pins 0 and 1 (RXI, TXO) are already used for the serial connection to talk to the PC Pin 13 has the built-in LED connected to it. You can use it for an output (but don't draw the full 40 mA, as the built-in LED will consume some of that), but if you want to use it as an input, you will have to disconnect that LED by cutting the trace to avoid problems. On some Arduino boards that use the ATMega328 in a small surface-mount TQFP package, pins A6 and A7 can only be used for analog input (e.g. on the Arduino Pro Mini) SCL and SDA are the pins for the I2C bus. If you don't plan to use I2C (e.g. to communicate with an I2C character display), you can use them for regular I/O.

Yes, that's how the options menu works. Find the row of the function you want to assign, double-click it in the column of the input device you want to use, then click the button / move the axis you want. Look in the "Axis Assignments" (or was it "Axis Commands"?) category, there should be entriees for left and right toe brake. For the Pro Flight pedals, you will also have to click the "Axis Tune" button at the bottom and invert the axis with the checkbox provided.

I am also interested. Right now I live in a dorm room where the desk is not mine to modify, but I will be moving out of the dorms within the next few months and will have a desk I can mount things to.

Cargo is still broken in 1.2.15.37241

Still broken in 1.2.15.37241 Can we please get at least some acknowledgement that this is being worked on? This bug breaks existing missions.

You found a bug. Fixed and released together with some other minor improvements as v0.2.5.

If your physical switch starts out in the opposite position from your virtual cockpit switch, the first flick will tell DCS-BIOS to switch the virtual switch to a position it is already in -- so there is no observable effect.

Most of the work of adding an aircraft module does not require programming experience -- it's mostly pattern matching (which human brains are really good at) combined with a few educated guesses ("which control am I looking at?") that requires knowledge of the aircraft involved. Usually, once you have seen one toggle switch or indicator light, you have seen them all. For example, you would see this in mainpanel_init.lua: LWS_LampReady = CreateGauge() LWS_LampReady.arg_number = 582 LWS_LampReady.input = {0.0, 1.0} LWS_LampReady.output = {0.0, 1.0} LWS_LampReady.controller = controllers.LWS_LampReady Because you know the Ka-50, you can guess that this is the ready lamp for the laser warning system, which is an indicator light that can be on or off. You would translate it to this: defineIndicatorLight("LWS_READY", 582, "Laser Warning System", "Ready Light") Another example: elements["ENERG-AKK1-PTR"] = {class = {class_type.TUMB,class_type.TUMB}, hint = LOCALIZE("Battery 1"), device = devices.ELEC_INTERFACE, action = {device_commands.Button_5,device_commands.Button_5}, arg = {264,264}, arg_value = {-direction*1.0,direction*1.0}, arg_lim = {{0, 1.0},{0, 1.0}}, use_OBB = true, updatable = true} elements["ENERG-COVER-AKK1-PTR"] = {class = {class_type.TUMB,class_type.TUMB}, hint = LOCALIZE("Battery 1"), device = devices.ELEC_INTERFACE, action = {device_commands.Button_6,device_commands.Button_6}, arg = {265,265}, arg_value = {-direction*1.0,direction*1.0}, arg_lim = {{0, 1.0},{0, 1.0}}, use_OBB = true, updatable = true} becomes defineToggleSwitch("BAT_1_SW", 2, 3005, 264, "Electrical Panel", "Battery 1 Switch") defineToggleSwitch("BAT_1_COVER", 2, 265, "Electrical Panel", "Battery 1 Switch Cover") In this case, you have to know that Button_X constants are defined as 3000+X and you have to look up devices.ELEC_INTERFACE=2 from the Ka-50's devices.lua. "BAT_1_SW" is a short identifier that you choose, "Electrical Panel" is the category and "Battery 1 Switch" is the description. If you are interested, I could get you started with a "skeleton" Ka-50 module. I did not plan to add more modules myself, but in case of the Ka-50 I have the module and have started flying it, so I have a basic familiarity with how the aircraft works. That means that I could take a look at things when you get stuck and add support for those controls that are not covered by the existing define... functions in DCS-BIOS. Regarding what hardware you should buy: Here's a work-in-progress long answer. The short answer is: get one of these and one of these. Or get an Arduino Nano for $2.88 instead (you will also need a mini-USB cable).

I was not talking about the last line. Comment out (or remove) the TCPServer line. I think that the failing TCPServer is preventing the UDPListener from working properly.

DCS-BIOS cannot bind to TCP port 7778 and proceeds to shit its pants because there is no appropriate error handling right now. Either a firewall is preventing DCS.exe from listening to TCP port 7778 or another process is already listening on that port. Try disabling the TCP server by editing BIOSConfig.lua in Notepad++ and commenting out line 3 (add "--" to the beginning) 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 }) } The only thing that uses the TCP server right now is the interactive control reference documentation.

DCS-BIOS does not have Ka-50 support right now. If you want to contribute Ka-50 support to DCS-BIOS, I would be happy to help you get started over Skype or TS. Look at the UH1H.lua file -- if you think "yeah, that doesn't look too complicated", you should consider this as an option. The work you put into adding Ka-50 support to DCS-BIOS would save you (and others!) a lot of configuration hassle down the road (and a lot of money in commercial interface boards -- Arduino clones are inexpensive, because they are mass-produced). The major disadvantage of DCS-BIOS right now is that the panel you build will only be useful for the Ka-50. If you want to use it with other aircraft modules or other sims, there is no solution right now. It would be possible to write a piece of software that talks to a DCS-BIOS compatible panel and translates that e.g. to key presses, but that does not exist yet, although Gadroc has entertained the idea of adding DCS-BIOS support to Helios. As the author of DCS-BIOS I am obviously biased. But from what little I know about OpenCockpits cards and SIOC (I never found official documentation that was actually readable), I get the impression that simply using it is at least as complicated as extending DCS-BIOS would be. PS: If anyone has a link to OpenCockpits / SIOC documentation, especially in the context of DCS, please PM me. All I found was either so badly translated to English that I gave up reading it or it talked about FSX. I still have no idea about the extent to which SIOC supports DCS: World modules.