FSFIan

You need a separate resistor for each LED. The single resistor in your schematic sets the current for all LEDs combined, but you want that current to be different depending on the amount of LEDs that are on at the same time. It also won't be distributed evenly between LEDs due to manufacturing tolerances. Assuming a forward voltage of 2.4 V, with a 1 ohm resistor you should get a current of 2.6 ampere (2600 mA). Either something is already broken, or your circuit does not match your schematic. To get the 13 mA you are measuring with a single LED, you'd need a 200 ohm resistor (again assuming a forward voltage of 2.4 V).

Throw in a salvaged PS/2 connector from a dead motherboard and a $5 Arduino clone and you can do it without the modifier.

Just wanted to post a quick update because it has been quiet for a while. I currently have master caution LEDs blinking on two Arduino boards that are connected over RS-485 to a USB-to-RS-485 adapter (only because I don't have one of those yet, I have programmed a TI Launchpad with a connected RS-485 transceiver to act like one instead). The next step is to implement a protocol in the Arduino library and on the PC side that coordinates which board is allowed to transmit when, so I can get inputs working. I am also reading up on the electrical design of RS-485 buses. So far, my test setup is working without termination (because my total bus length is maybe 10 cm) and without any biasing (which confuses me a little, maybe I am just lucky).

Don't omit that resistor! It is there to limit the maximum current. Without it, you are essentially creating a short circuit, which will not only affect the lifetime of your LED, but also the rest of your circuit (although if you are powering from a USB port, those are supposed to survive a short according to the specification, so after a while the polyfuse on your mainboard would trip). Anecdotal evidence: I once forgot to hook up a resistor for the LED backlight of a display (because I mistakenly assumed there was one integrated into the module). The backlight survived, it killed the wall wart I used to power the thing instead. I plugged it into my beefy lab supply afterwards, which startled me by switching on its cooling fan (up to that point I didn't even know it had one). At that point I noticed that the whole thing was drawing a lot more current than it should have...

The current version of the DCS-BIOS Arduino library works with any Arduino-compatible board (it only depends on pinMode/digitalRead/digitalWrite, the Serial library and the Servo library, which work everywhere, even on some Texas Instruments boards using Energia). The next version will include some optimizations which will be targeted at ATMega328-based boards (Uno, Nano, Pro Mini, and most of the others) at first, but I plan to add support for the Mega 2560 later (won't be much work, I just need to order a Mega board for testing). It will still work on other boards, just without that optimized code (interrupt-based handling of serial communication) which is intended to solve the current reliability issues that arise when a lot of outputs are added, especially "slow" ones like displays.

Yes, WarHog does all his PCBs in AutoCAD. I am always fascinated when looking at the results because to someone who is used to look at PCBs that come out of software like Eagle, they look a bit strange (and sometimes just beautiful) because the geometry is not what you'd expect. If you are using dedicated PCB layout software and want to reduce the amount of copper that gets removed, add a ground plane. The same is done on boards that get produced with an etching process, both to reduce sensitivity to EMI and to reduce the amount of copper that ends up in the etching solution, meaning that solution can be used to make a greater number of boards before it needs to be replaced.

If you are using the twist rudder on the X52, my guess would be that on the XBox controller it is easier to control cyclic pitch and rudder independently.

Without knowing anything about the software that drives your motion platform, it is impossible to even guess where the problem may be. Have you checked dcs.log for error messages? Have you tried contacting the vendor?

According to this thread, the A-10C can go up to 45,000 feet. Good luck designing a way to attach the needle that is snug enough not to slip during normal operation, light enough to allow the stepper to rotate while the needle hits the end-stop, and is still at that "optimal snugness" after the gauge was started up a few 100 times, doing 46 full rotations against the end-stop for each startup. Your proposed design also complicates the software a lot. You need to figure out how to translate the values you get out of DCS (rotation of each digit on the numeric readouts, rotation of the pointer needle) into a target position for your stepper and make sure you don't miss any edge cases (watch what happens when you are at 0 ft MSL and adjust your pressure setting so the altitude being indicated on your altimeter is actually negative).

You can't develop the hardware completely independently of the software. For your altimeter, the zero-setting is not trivial -- you can't use a mechanical stop because it needs multiple revolutions, so you need a way to detect the zero position and you need to write at least a simple test program to be able to verify that it works reliably. You will also need to get displays for the pressure setting and the numeric readout, which should have a display controller that is supported by an existing Arduino library. It's not an insurmountable problem, my point here is that you can't build a prototype without thinking about the software that will drive it and then expect someone else to be able to "make it work". If you post a schematic for a specific panel (I suggest starting a new thread for this) with a list of parts you plan to use, I can tell you whether I see any difficulties writing the software for it. It is possible to export data from LoGetSelfData() and friends, which (at least for basic flight parameters -- position, airspeed, altitude, bank/pitch/roll) are available in any aircraft and are independent of any cockpit instrument. So far, I have only exported those parameters in the CommonData module that I needed for a moving map experiment. If there is a use case for other parameters, I will consider adding them as needed/available.

In multiplayer, LoGetSelfData() will return nil when you are in spectator mode. For reference, here is the part of DCS-BIOS that deals with this.

Are you running anything Export.lua-related besides Helios? Check dcs.log for errors. By default, a server setting removes "LoGetWorldObjects()" from the export environment. Maybe one of your add-ons that uses Export.lua stumbles over this and takes the rest with it.

There is no such thing as "simply implementing steppers in DCS-BIOS". Just like with character displays, there are different stepper motors and driver chips out there which require different ways to drive them. I do plan to add a class (and example code generation) for the VID29xx series of steppers at some point, because they seem to be inexpensive, widely used in car dashboard applications, and can be driven directly from a microcontroller. Those steppers have a mechanical end-stop and are designed not to take damage when driven against it, so zeroing them on startup is trivial. However, that is low on my priority list right now; I want to finish v0.2 of the Arduino library first to get support for connecting multiple boards over RS-485 and handle incoming data in interrupt service routines to prevent the receive buffer filling up when a lot of "slow" outputs like displays are connected. Keep in mind that just because there is no class that abstracts away stepper usage in the DCS-BIOS Arduino library does not mean that you can't use stepper motors with DCS-BIOS right now. If you are using steppers without a mechanical end-stop (e.g. for the altimeter pointer), you will also have to implement some mechanism to detect when the needle is at the zero position. The only stepper I know of that has this built in is the VID60-02. That one is intended for analog clocks, so I don't know if it provides accurate resolution (I couldn't find a proper datasheet; clocks only require 6 degree steps). I am also not clear on how the zero detection works exactly (i.e. whether you get a digital output or an analog voltage that you still have to interpret). If you are planning to commercially produce your boards, you will have to provide customer support. That means you need to understand how every part of your product works anyway. I don't think you can avoid learning basic Arduino programming. Also, what is your background in electronics? If you want to get your per-unit cost as low as possible, you want to design and populate your own circuit board to save time assembling and integrate everything neatly. Once you are doing that, you might as well ignore commercially available Arduino boards and select the cheapest microcontroller that still has enough program flash and SRAM to run your panel. I would suggest that you get an Arduino board and spend a few hours experimenting with DCS-BIOS to get a better idea of its capabilities. For example, the data you would need for your force-loading algorithm is not exported by DCS-BIOS right now. Except for the altitude, where the "true" value is exported as part of the "CommonData" module, airspeed and "other instrument related parameters" are only exported as shown on the actual cockpit instrument. With the current version of DCS-BIOS, your force-loading would stop working when those instruments become damaged. Writing the software is not as much work as you think. Once you have finished selecting your stepper motors, circuit design, and have a prototype assembled, we can probably get it up and running in an evening (assuming there is an existing Arduino library to talk to your stepper motor or driver). The hard part is getting the hardware design right -- selecting a suitable stepper motor, making sure your voltage regulator can handle the maximum expected total current, implementing zero-detection (if applicable), selecting components that get the job done reliably for the lowest per-unit cost (i.e. avoid paying for features you don't need). EDIT: you also want to integrate a RS-485 transceiver chip (and a jumper to disconnect it from the Arduino for reprogramming) into your design to be prepared for the next version of the DCS-BIOS Arduino library.

Do you know of any way at all to interact with the weather system from Lua code?

That still won't make the DIY way more expensive than buying that board, even if you count the complete one-time cost of the soldering iron against it. While I would strongly recommend getting a temperature-controlled soldering station if you plan to build an entire simpit, you can get away with one of those basic soldering irons that plug directly into mains (I do). I bought one as part of a "starter kit" for 10 bucks when I needed to solder a new barrel connector to a wall wart (it came with a plastic "solder sucker" and a small amount of solder) and have been using it ever since. Also, even if you buy this board, you would probably need a soldering iron anyway to connect your 7-segment display.

The site has conflicting information. The video and pictures show a board with one MAX7219 chip that can handle 8 digits. The text talks about a board with two MAX7219 chips that can handle 16 digits. I don't think they are charging too much (I couldn't offer something like that in low quantities at a lower price), but I do think the price is way too high. All that board saves you is connecting a single resistor. You are better off building your own on strip board (the MAX7219 is available in the larger DIP package). Depending on your application, you may even be able to use a module like this that integrates the MAX7219 chip and the 7-segment display on a single PCB.

Yes. You can add multiple DO SCRIPT FILE actions to your MISSION START trigger.

I have created a new thread where I will post announcements of new releases. The first post will become a constantly updated overview of DCS-BIOS and related resources. Once I have fleshed that out a bit, I will ask a moderator to sticky that new thread instead of this one. I would like to retire this thread, because too much useful information has become buried deep inside this 35-page monster. It does not help much to remember that the answer was "somewhere in the DCS-BIOS thread", especially when discussion of multiple different issues is interleaved from time to time. Let's try to have one thread per separate issue or question from now on. To take over the general discussion and feedback from this thread, I have created the DCS-BIOS Discussion Thread.

Released DCS-BIOS v0.3.0. Thanks to wraith444, we now have Mig-21 support!

To find out what you can do with DCS-BIOS, look at the intro video and the About DCS-BIOS section below. The latest release and documentation is always available from dcs-bios.a10c.de If you want to be notified when a new version of DCS-BIOS or related software is released, you can subscribe to this thread (and optionally enable e-mail notification). What to post where This thread is for the announcement of new software releases only. If you want to announce a new version of your DCS-BIOS-related software, post in this thread, including a link to your project's discussion thread. The preferred way to report bugs is to open a new issue on GitHub. Questions belong in a new thread. Let's avoid creating another 35-page monster. For anything else, you can use the DCS-BIOS Discussion Thread. Please do not PM me with DCS-BIOS-related questions. If the answer might also be useful to someone else (which is the case for most "how can I do X" questions), it belongs in a public thread where it can be discovered using the search function. I am subscribed to "Mission Builder's Corner", "Input and Output" and "Home Cockpits" and read at least the subject line of every thread that gets posted to one of those boards. Introduction Video 8vI_W0j_3uY About DCS-BIOS DCS-BIOS is an Export.lua file for DCS that provides a stable and documented interface for external hardware and software to interact with the clickable cockpit of a DCS: World aircraft. It comes with a software library for the popular Arduino microcontroller platform. Currently supported aircraft modules: A-10C, UH-1H, Mig-21Bis, Ka-50 If you would like to contribute support for another module, please get in touch! Without any programming experience, you can use DCS-BIOS and a $5 Arduino board to connect the following types of controls: momentary push buttons two- or three-position toggle switches multi-position rotary switches rotary encoders LED indicator lights If you have basic programming skills, you can also use the following: character displays (for example for the A-10C's CMSP display) 7-segment displays driven by the MAX7219 chip servo or stepper motors and anything else that can be controlled by an Arduino board Resources Downloads and documentation are available at dcs-bios.a10c.de Development takes place on GitHub original announcement post Related Projects If you have something to add to this list, PM me. BrassEm's VRi2DCSBIOS.exe allows you to use VRInsight devices such as the VRInsight CDU II as input devices for DCS: World The Flightpanels software by ArturDCS connects Saitek Pro Flight panels to DCS In this thread, agrasyuk describes a Raspberry Pi-powered A-10C CDU display How to display the fuel flow on a character LCD (this thread should have enough info to be applicable to other values that are exported by DCS-BIOS)

Please post general feedback and ideas or requests for new features here. If you just started using DCS-BIOS, it would be helpful to know your previous experience in electronics and programming, what you have built with DCS-BIOS, and which parts of the documentation confused you the most while figuring out how to do it. Questions about how to use DCS-BIOS should go into their own thread, for bug reports I prefer GitHub but I also accept them via PM.

You can make it work again by renaming the files and search-and-replacing their contents to change the old USB ID to the new one.

The cause is probably that the data is buffered somewhere, either by the driver for your virtual COM port or by the USB-to-serial converter on the Uno. If you look at the , there is an "Update Counter" which increases with every export data update. DCS-BIOS aims for 30 updates per second. Take a look at the Master Caution light data in the interactive control reference. It should also "blink" steady, confirming that the stutter is introduced on the way from the PC to the Arduino board.

Take a look at my new map project: dcsmap.a10c.de It lacks the integration of the A10-C TAD map, but it has the positions of all buildings marked, which makes it easier to recognize settlements. It is also based on the current version of OpenLayers 3, so all you need to add it to a Joomla page is to include jQuery and OpenLayers 3 in the page, create a div with id="map", and copy the JavaScript code (sorry for the messy indentation, it's in its early stages right now).

Your call to Object.getPosition looks strange. Object.getPosition only expects one parameter, which should be an object (a unit or static object). "vehicleA" is an undefined variable here (unless you did not post your complete code) mist.teleportInZone expects the name of a zone, not a position. I think you want mist.teleportToPoint instead. Try something like this: mist.teleportToPoint({groupName="infantry", point=Group.getByName("vehicleA"):getUnit(1):getPosition().p, action="respawn"}) Also, your logic of "I don't know Lua, so I need to use triggers" is flawed. IMO it should be "I don't know Lua, so I need to learn Lua". Scripting is much more powerful than trigger logic, more maintainable as your missions get more complex and you can test and debug a lot faster with the DCS Witchcraft Lua Console by trying out snippets of Lua code without restarting the mission.