FSFIan

You defined an empty aircraft module. The next step is to tell DCS-BIOS what switches, indicators, etc. exist in your aircraft by adding code to the F-5E.lua file between the calls to beginModule() and endModule(). This is described with the example of a toggle switch in the Developer Guide (in the section "The Export Module API"). To understand that documentation, you will need to learn the Lua programming language, otherwise it won't make much sense to you. You can try to read the existing files (e.g. A-10C.lua) and mimic the patterns you see, and that might work for a while, but at some point you will add a syntax error by mistake and then you need to understand how to find the error message in dcs.log, navigate to the offending line in your Lua file, and recognize and fix the error. There will also be a few controls that are not covered by the BIOS.Util.* functions, so you will need to write custom Lua code to get the complete module working.

The Developer Guide has the step-by-step instructions. And from your post it sounds like you followed them. If the JSON files are created, then you have successfully added an aircraft module. Please elaborate on the following points: 1. What did you do? (Include the files you created, especially your F-5E.lua file) 2. What did you expect to happen? 3. What happened instead? I have no idea what the problem is, because from your post it sounds like everything that I expected to happen did happen. So I need to know what you expected to happen before I can help you.

Something I forgot to mention in my post above: you will also need a soldering iron, as most of the boards you order from China (e.g. an Arduino Nano or the 7-segment display) will not have the pin headers soldered on. It saves them some production cost (through-hole parts generally require hand soldering, while all the surface mount stuff can be placed by a machine) and makes the boards easier to ship in a padded envelope. As you seem to be serious about building more than a few panels, I strongly recommend that you do not skimp on your soldering station. Get a temperature-controlled soldering station from a good brand. In the US, the Hakko FX888D) seem to be popular among hobbyists. Don't buy these from eBay, there are lots of fakes around. Make sure you get a small chisel tip (between 1.2 and 2 mm), the cone shaped ones that most irons come with are crap. If your station does not come with one, get one of those metal-wool tip cleaners. They work better than sponges and you don't have to wet your sponge every time you want to use the iron. If you spend $10 on a cheap mains-connected iron, you will wait minutes for the iron to heat up, have difficulty if you want to use lead free solder, and have a big, heavy iron in your hand that's trying to drag an inflexible mains cable behind it. The stand it comes with will be too light for that iron and you'll have to balance it 'just so'. It's fine if all you want to build is one or two panels, but on a larger project it will slowly drive you insane. Spend around $100 on a good soldering station, and you start to think differently about soldering. The thing heats up within 30 seconds, so you can turn it off after every use. It won't fall out of its stand. The iron itself is small and light, so it is easy to work with. Because the temperature regulation is decent, you can solder different joints back to back without having to wait for the iron to heat up again. The Hakko FX888D seems to cover all the must-have features of an iron for you: Heats up within half a minute. Temperature is adjustable (analog or digital doesn't matter). Has a way to tell when it has reached the set temperature (digital readout in this case, on analog stations this can be a light that tells you when the heater is on). Good temperature regulation. Availability of different tips, and you can be confident that you can still find replacement tips for that iron ten years from now. If you spend more money, you will find stations with the following nice-to-have features: Sleep mode -- the station will lower the temperature when the iron is placed in the stand. This makes your tips last longer. Auto power off. If you are not using the iron for some amount of time, it will automatically switch off. A great feature for peace of mind. On the other hand, given a decent stand, a soldering iron is unlikely to burn down your house even if you do forget to turn it off. Some more expensive stations have the heating element integrated into the tip. This can provide even faster temperature regulation, although the tips are a bit more expensive. Some stations let you change tips while the iron is hot. Personally, I got a used JBC AD2950 soldering station for 240 € from eBay. It has all of the nice-to-have features I listed above. I would have gone with the Hakko, but IIRC I could not find it around 100 € in Germany and I didn't want to order one from eBay because of the fakes. Ersa and Weller (the two brands that seem to be prevalent in Germany) didn't seem to have anything decent below 300 €. If you buy a decent quality iron and you are not soldering boards on an industrial scale, a soldering station will last you for decades.

The JSON files are generated when DCS-BIOS is loaded. After you have written your Lua file, you have to make DCS-BIOS reload your aircraft module. To do that, you can either jump into a new misson, or use the Lua Console from my Witchcraft project to execute a dofile(...) statement that loads your Lua file. After that, your newly defined controls should be visible in the control reference. If you have more questions, please create a new thread and post your Lua file. This thread is meant for general feedback, not help requests.

Great video! This is definitely the way to go if you are developing a mission script. The Lua console in DCS Witchcraft was not designed for larger scripts (it does not even have a save function). It works well with small, ephemeral code snippets, for example to inspect the contents of global variables without running your script again or to interactively figure out how to use a single function in the DCS: World API. Don't worry about formal training, it does not matter. I have a BSc in Computer Science, but that does not mean I know how to program anything more complex than a reference implementation of an algorithm without any error handling. (Maybe I should have studied Software Engineering instead.) I did not learn much about error handling, debugging, using a version control system, and writing maintainable software in lectures. I learned about these things because I was programming in my student jobs and as a hobby. For most software, the hard part in creating it is not figuring out new algorithms. It's managing complexity. It's structuring the code in a way that will be maintainable in the future. I wrote my first lines of code 20 years ago and have been programming as a hobby ever since. I still feel like I don't know what I am doing. I also think that no amount of formal training will help with that; I'll just have to get a job and gain more experience, one mistake at a time.

EDIT: The following assumes you are going to use Arduino boards (see http://arduino.cc). They are the most cost-effective way to do this. My recommendation would be to just start experimenting with electronics. Once you understand a few basic concepts, you know enough to interface with a lot of different types of devices. Here's a minimum equipment list to get started: Solderless breadboard Jumper wires Multimeter (I can recommend the UT136B) An Arduino board You will need things to connect to your Arduino board so you can play around with it. A few suggestions: A few LEDs (you'll need a 250 ohm resistor for each LED to limit the current to 20 mA) Assorted switches, potentiometers, and rotary encoders (you can use the ones on your panels if you can figure out which pins they connect to) A 16x2 character display A small 128x64 pixel graphic display A module with 7-segment displays connected to a MAX7219 driver chip For recommendations on what tools to choose, watch the EEVblog episodes and . The first one focuses on quality, the second one on price. You don't need everything mentioned in those videos, but it's a good list of things to consider buying and what to watch out for when you do. Absolutely get one of these ultra-cheap Logic Analyzers and a set of test clips. Those analyzers copy the hardware design of the original Saleae Logic. They work with the open source sigrok software. A logic analyzer allows you to record several digital signals at once and display them on a computer. It can be an extremely useful debugging tool. For example, you can toggle certain I/O pins at specific places in your program and record that with the logic analyzer (you can't use the serial port if you are already using it to talk to DCS, and can't set breakpoints because there are no reasonably-priced debug interfaces for AVR chips). It is also a great tool to troubleshoot timing issues. To interface panels to DCS, you don't need an oscilloscope. I spent $400 on a Rigol DS1054Z a while ago and I am very happy with it, but most of the things I use it for can also be accomplished with a logic analyzer and a multimeter (which is exactly what I did before I had the scope). Until you get into more advanced analog circuits, the oscilloscope is optional. So what concepts should you learn? My computer science curriculum included a class on the basics of digital electronic circuits. We were shown one particular diagram that helped me a lot. Look at page 10 (slide 19) of this PDF (not my university, but the diagram is the one I was looking for). The diagram shows the different 'logic states' that a wire can have and what happens when you connect any two of them. 1 is a "strong logic high": a direct connection to the supply voltage (5V in case of most Arduino boards). It counts as a logic one. 0 is a "strong logic low": a direct connection to ground. It counts as a logic zero. X is a short circuit. Avoid unless you like magic smoke. H is a "weak logic high": some point in the circuit that is connected to the supply voltage through a resistor (called a "pull-up resistor"). It counts as a logic one. L is a "weak logic low": some point in the circuit that is connected to ground through a resistor (a "pull-down resistor"). It counts as a logic zero. W is what happens when you connect L and H. The voltage will be somewhere between supply and ground, depending on the exact values of the resistors. For our purposes, it's an undefined state and should be avoided. Z is "high impedance": a wire that is not connected to anything (or is connected to supply voltage or ground through a very high resistance). Like "W", the logic level is undefined. Using these six states, you can reason about digital circuits without ever caring about the precise quantity of any voltage or resistance. For example, let's hook up a switch and explain how it works with these logic states. ---+-------- +5V | (1) | +-+ | | pull-up | | resistor +-+ | | (2) +-------- I/O pin | | / / switch / | | (3) ---+-------- GND Node (1) is easy, it's directly connected to +5V so it's 1. Node (3) is 0. When the switch is open as shown, node (2) is H and the I/O pin will read as a logic one. If you close the switch, you connect H to 0. We can consult the diagram to find the new state that we get: X 0 1 W L H Z Look at 'H' and '0', and notice that '0' is higher in the diagram. So the new value we get is 0 and the I/O pin will read as a logic zero. You can reverse this and use a pull down resistor instead, and some Arduino tutorials do that. Using a pull up resistor makes more sense on an Arduino, because the microcontroller has a built-in pull up resistor on each pin that you can enable in software ("pinMode(pin_number, INPUT_PULLUP);" in an Arduino sketch). Which Arduino board should you buy? I like the Arduino Nano because it's small and can be plugged into a breadboard. The Arduino Uno is the same thing in a bigger form factor that allows you to plug in "Arduino shield" modules, but you won't use those anyway because there is no "AN/ARC 131 shield". The Arduino Mega 2560 is also worth a look if you want more I/O pins. If you can live with a few weeks of delivery time, buy the Chinese clones from eBay.com or AliExpress. Finally, have a look at my DCS-BIOS project (link in my sig). It is still in a proof-of-concept stage (only comes with support for A-10C, Huey, Mig 21 and Ka50, no GUI, etc.) but it works. If you have programmed before, you will probably quickly pick it up. If you have any more questions, let me know. If you want to chat on Skype or TeamSpeak, send me a PM, I love helping people get started with this hobby.

If the schematic on this page matches your board, the value of the bias resistors is probably too high. Measure R5 (resistance between B and GND) and R6 (resistance between A and VCC) on your board. If they are higher than 560 ohm, this is likely the problem. If the bias resistors are the problem, you can try removing the 120 ohm termination resistors (marked "121") from both boards. Without the termination resistors, the bus should then work reliably over very short distances. EDIT: ...or simply add the external 470 ohm bias resistors shown in the schematic on that page. If you use more than one slave device, only the last slave device on the bus should have a termination resistor on the board. Here's a calculator to determine the value of bias and termination resistors. It implements the formulas given in the TI app note linked in the first paragraph. The job of the bias resistors is to make sure that the bus is in a defined state when no chip is driving the bus. This happens when the master is asking a slave device "do you have something to say?". The master then releases the bus and a short amount of time passes before the slave starts driving the bus. During that time, the two 120 ohm termination resistors essentially short the bus (so there is no voltage difference between A and B and thus no defined logic level) unless there are two sufficiently strong (i.e. low value) bias resistors to counter this. If the bus is not properly biased, the devices might read a logic 0 for a short amount of time, which signals the start of a new UART transmission. That will cause data that is sent afterwards to be misinterpreted and come out as garbage. Eventually, DCS-BIOS will notice that no one has transmitted for a while and reset the bus, so the process can start over again. I recommend the MAX487 transceiver chip. Due to its slew-rate limiting, it should work without termination resistors over distances of up to 10 meters. It also supports more devices on one bus (1/4 unit load). With the MAX485, you need termination and bias resistors if your bus is more than a few centimeters long, and with proper termination and biasing you should be able to use 10 devices (1 master, 9 slaves) per bus. With the MAX487, as long as the bus is not longer than 10 meters, you can skip termination and bias resistors and use up to 126 devices on one bus. With termination and bias resistors, the MAX487 would allow about 40 devices on one bus. Note: the information in this post is based on my understanding of RS-485, which is mostly theoretical (from reading datasheets and application notes). My tests were limited to three MAX487 chips on one bus over maybe 20 centimeter of wiring. I did not test other transceiver chips, longer bus lengths, or more devices on one bus. This is the main reason that the whole RS-485 thing is not officially documented yet.

Does the same behavior happen in IRQ_SERIAL mode? If it works fine with IRQ_SERIAL and does not work over RS-485, your RS-485 bus might be unreliable; check your wiring. If the same behavior happens in IRQ_SERIAL mode with a direct USB connection, updating the displays and MAX219 chips takes too long. You should be using setDigit() instead of multiple calls to setLed() to optimize performance, but I don't think this would account for a lag of several seconds. A lag of several seconds usually indicates that an update has been missed entirely (either due to a transmission error or due to an overworked microcontroller where some Arduino library is blocking interrupts for too long). Another thing to look out for is if the lag is consistent. If it is always there, talking to the displays might take too long. If it sometimes reacts instantly, it's probably transmission problems over the RS-485 bus.

I released v0.2.11 which fixes the compile error. You are right, your command is too long. Command names have to be short enough that the complete message (such as "WEAPONS_FORWARD_HEMI_TARGET_BTN 0\n") fits in 31 characters. I suggest to keep them below 20 characters. In the future, please open a separate new thread for each issue.

Released v0.2.11 of the Arduino Library. fix RS-485 Master compile error Please post general comments and feedback in the DCS-BIOS Discussion Thread. If you have questions or bug reports, please start a new thread.

The last update was three years ago, but the Lua Console part of Witchcraft still works with current versions of DCS. For my 3D preview mission editor thing that replaced the unit moving functionality of Witchcraft, the README describes how you can set up a second installation of DCS: World so you can run two instances on the same computer. I don't know if that still works with current versions as I am not using it myself, but so far I have not received any reports that it won't.

lancer2000: I have released a new version of the Arduino library (v0.2.10) that should fix your problem. jazzymanserg: You'd have to play around with that switch in the Lua Console and understand which commands you have to send in which state. Maybe your problem is similar to the CMSP switches in the A-10C, which require different command sequences to go to a certain state depending on which state they are currently in. @Everyone: ...and we had two simultaneous topics in here again. In the future, please do not use this thread to request help with bugs or compile errors. This was meant for general feedback ("I just started with DCS-BIOS, here's what worked, here's where I was confused"), feature requests, etc. The answer to any question answered in here is likely to be buried within a multi-dozen page thread, and will be very difficult to dig up again with the search function.

Released v0.2.10 of the Arduino Library. Added EWMA filter to DcsBios::Potentiometer. This should finally stop potentiometers from spamming the serial port. To tweak the filter parameters, use the DcsBios:otentiometerEWMA template instead (see Potentiometers.h for its definition). provide both sendDcsBiosMessage and DcsBios::sendDcsBiosMessage. Both of these functions will now block again until the message has been transmitted successfully. The non-blocking variant has been renamed to DcsBios::tryToSendDcsBiosMessage. fixed a bunch of compiler warnings (now compiles with -Wall -Werror in the Arduino IDE 1.8.2) tried to improve the order in which inputs get the chance to send a message Please post general comments and feedback in the DCS-BIOS Discussion Thread. If you have questions or bug reports, please start a new thread.

lancer2000: I'll need to know your complete sketch, the version of the DCS-BIOS Arduino library you are using, and the version of the Arduino IDE you are trying to compile it with.

llancer2000: Declare the parameters of your Switch2Pos function as "const char*" instead of "char*". The "const" modifier is a promise to the compiler that you won't modify the parameter value. Newer versions of DCS-BIOS use "const char*" for all the message parameters to fix compiler warnings. Anyone: In case you have posted in the past two weeks and have not received an answer, please post again in a new thread. I have not kept up with this thread as frequently as usual and now there are several intertwined conversations going on and I have lost track. I have tried to encourage people to open new threads for anything that might require troubleshooting (and that other people might want to find in the future with the search function), but the vast majority of people still post here for everything. I have had cases where I knew I had answered a question before, but spent twenty minutes writing out another answer because that was faster than trying to find the old answer that was buried deep within a thread that's 70+ pages long. So here's a question for all of you: what motivates people to post here instead of opening a new thread? Is it the impression that I won't notice a new thread? (Don't worry about that, I am subscribed to the Home Cockpits forum.) Is it just the convenience of not having to think of a thread title? How can I get people to start opening new threads for each issue without flat out refusing to do any support in this thread?

Sorry, I noticed your edit now and it's months later... The problem was fixed in DCS-BIOS v0.5.2.

In DCS 1.5.6.1938, the implementation details of the TACAN panel in the A-10C were changed. Here's the commit that fixed it in DCS-BIOS (the diff shows what values changed): https://github.com/dcs-bios/dcs-bios/commit/768109b9eaf1420c10ec03bc3f938b0fcaf29078 The TACAN controls now have their own device ID and different button numbers than before.

The Lua 5.1 Reference Manual has documentation on every language construct and standard library function, including string.format and string.sub. some_string_variable:sub(n) simply returns everything from the third character onwards and is used to transform something like "0.25" to "25".

No, it's not. (Unless all you need is position, altitude and heading information.) That said, adding Viggen support to DCS-BIOS is probably easier than writing your own middleware from scratch. I hope to make that process even easier in DCS-BIOS 2.0, but that's still a few months or more away. The 74HC595 is a serial-in, parallel-out shift register. SIPO shift registers are a popular method to control many outputs with only three I/O lines (data, clock and latch). The first thing you should read up on is how shift registers work. I'd suggest looking for an Arduino-focused tutorial on the topic. The datasheet for the 74HC595 might be worth a look too, but it's mostly relevant when you are designing the circuit to look up pin locations and electrical characteristics (such as supply voltage or if the shift register can supply enough current to drive the display). Next, read up on 7-segment displays and figure out whether your display is a common-anode or common-cathode setup. Then read up on multiplexing 7-segment displays (my guess would be that your board is set up to light up one digit at a time). Once you understand shift registers and 7-segment displays, you will need to know which signal from your display connects to which shift register pin. If you don't have a schematic of your board, use the continuity buzzer on a multimeter (together with the datasheets for the 74HC595 and your 7-segment modules to look up pin locations) to figure it out. Now you should be able to write a simple sketch that lights up a single digit on your display. At that point, you can look for a library that does the multiplexing for you. The following links look like they might match your use case: https://github.com/Qtechknow/Arduino-Libraries/tree/master/Pineapple https://github.com/ArduinoHannover/Shift7Segment If you want an easier way to control 7-segment displays with an Arduino, look into a module with a MAX7219 chip and the LedControl library. The MAX7219 chip takes care of multiplexing up to 8 7-segment digits. Like shift registers, multiple MAX7219 chips can be daisy-chained.

The control reference generates the same variable name for both the switch and the LED output ("lcpAnticollision"). Rename one of them and it will compile.

The LED backlights of small character LCDs come in different variants. 1) Some displays might have two pins that expect a certain voltage to turn on the backlight (i.e. the board includes some form of current limiting, either a resistor or a constant current source). 2) These units have two pins labelled "LED" that can be connected with a jumper to turn on the backlight (one is VCC, the other goes through a built-in current limiting resistor to the backlight). If you want an adjustable backlight, you can connect a potentiometer to the pins instead. 3) Some displays just have the LED pins exposed directly and you are responsible for limiting the current. Confusing one variant for another can lead to short circuits or fried components. Even if the backlight works, check the current with a multimeter. I connected 5V directly to a variant 3) once, so I was powering the LEDs without current limiting. After a few hours of experimenting, the wall wart I was using to power the whole setup broke. I switched over to my lab power supply. A few minutes later the fan of my power supply turned on -- I was startled because I didn't even know it had one. That finally made me check the current going through the backlight. It was close to 1 amp. I facepalmed and added a resistor to get it down to 20 mA. The lifetime of that poor LED is probably significantly reduced now :D

The "msg" parameter is just an identifier for DCS-BIOS, you can pick whatever you like (keep it below about 20 characters and use all caps and underscores to follow the existing convention). You use the "defineIndicatorLight" function (with the identifier you came up with for the "msg' parameter and the argument number you got from somewhere in your cockpit's Lua files) to add the lamp to DCS-BIOS. Then you have to hop into a Mig-15 in DCS so DCS-BIOS updates the metadata for your module. Now your new lamp should show up in the interactive control reference. The control reference will show you the code snippet that includes the address and bitmask that were assigned to your new lamp (these are assigned sequentially in the order that your controls are defined in the Lua file for your DCS-BIOS module).

Ruhatu: Are you adding the display code at the end of your file? If you add it in the middle, the addresses of anything after it will change, so you'd have to adjust your Arduino sketches accordingly.

Look at the other Lua files next to clickable_data.lua, especially mainpanel_init.lua and everything that gets included via dofile() calls. For the MiG-15, it looks like Devices_specs\MainPanel\lamps.lua might be interesting (included via line 566 in mainpanel_init.lua).

I need more information. Which LED? What were the contents of your Lua file when it worked, and what are the contents of the 'broken' file? How did you assert that the LEDs worked (i.e. where is the LED in the cockpit and what buttons do I have to push to make it turn on or off)? Remember, I can't see your files (unless you post them somewhere) and I have no idea how to fly the Gazelle :)