FSFIan

Yes, changing the baud rate is the only thing that would need to be modified about the com-handler. For new projects, I would recommend MAX487 chips. On the other hand, those modules with the MAX485 on it are all over eBay and AliExpress and this is the second or third time someone has posted that they couldn't get them to work, and it won't be the last. I just ordered a pair of those so I can figure out how to wire those up in a way that makes DCS-BIOS work.

Ok, I found a way to download the file without Windows Defender deleting it afterwards: Create a new folder somewhere, for example "Downloads/StuffFromTheScaryInternet" Open "Windows Defender Security Center" Got to "Virus & Threat Protection" > "Virus & threat protection settings" > "Add or remove exclusions" and add your new folder as an exclusion. Files downloaded to that folder won't be scanned by Windows Defender. Using right-click > "Save link as" in your browser, download the file into your new folder. Now you can remove the exclusion.

The same happens on my machine. Windows Defender will apparently complain about every DCS-BIOS release now (as they all use the same copy of socat). My guess is the behavioral engine goes "Oh no! It does network stuff, it must be evil!" or something. Socat is the swiss army knife of network connections, and some of the things it is capable of must upset Windows Defender. I don't know since when Windows Defender has complained about this. Usually I have no reason to download my own software from the internet, so Windows Defender has no reason to scan those files on my machine. None of the virus scanners used by VirusTotal can find anything wrong with the file. EDIT: Holy cow, Windows 10 is being a bitch and providing no obvious way to shut it up and download the file. Windows Defender just deletes it without even asking! When I go to the "Windows Defender Security Center", it claims "no threats found". Clicking on "Scan history", it lists "No threats" under "Quarantined threats". Only the third click ("See full details") reveals that it ever scanned and then deleted the downloaded file.

Try version 1.8.2 of the Arduino IDE: https://www.arduino.cc/en/Main/Software

What do you mean by "24-imp"? An imp is a mythical creature... If you want to increase the amount of movement caused by rotating your encoder one detent, change the "+3200" and "-3200" values.

"IRQSerial" is the template you should use (it was named "TemplateSketch" in older versions). I fixed that in the documentation a few weeks ago, but then apparently forgot to update the website (d'oh!). Here's a sketch that should work (it puts the "nose gear safe" light on pin 13, which is connected to the built-in LED on the Uno board): /* Tell DCS-BIOS to use a serial connection and use interrupt-driven communication. The main program will be interrupted to prioritize processing incoming data. This should work on any Arduino that has an ATMega328 controller (Uno, Pro Mini, many others). */ #define DCSBIOS_IRQ_SERIAL #include "DcsBios.h" /* paste code snippets from the reference documentation here */ DcsBios::LED gearNSafe(0x1026, 0x0800, 13); void setup() { DcsBios::setup(); } void loop() { DcsBios::loop(); } Note that I replaced the word "PIN" from the code snippet with the pin number. If you forget this step, the sketch won't compile because the compiler has no idea what "PIN" is. If this doesn't solve your problem, please post the sketch that does not compile here, along with the version of the DCS-BIOS Arduino library you are using and the version of your Arduino IDE.

Do you have a datasheet for the encoder you want to use? I am sure we can come up with a sketch to make it work.

Thanks for bringing this to my attention again, I had dropped the ball on this one. This issue should now finally be fixed in v0.5.3 of DCS-BIOS, which I just released. When "player export" (or "ownship export" as it is called internally) is turned off, the function LoGetSelfData() became unavailable. DCS-BIOS relies on this to determine the aircraft type. I contacted ED about this months ago, and they fixed it months ago (by making the aircraft type always available). I had assumed that would be all it takes to fix this issue. When I tried to set up my own multiplayer server with the tester version of DCS (because the fix had not arrived in the public build yet), the old PC I tried to run it on had a hard disk failure. Then life got in the way and I forgot about the whole thing. The remaining issue that I would have found if my test server had worked (and that I could now find in five minutes by testing against the 104th server) is that the CommonData exports still tried to access values that were disabled by setting allow_ownship_export to false, such as the current position and heading. So now everything but the CommonData exports should continue to work in multiplayer regardless of server settings.

Released DCS-BIOS v0.5.3. Turn off the CommonData exports on MP servers where allow_ownship_export is turned off to avoid crashing Please post comments in the DCS-BIOS Discussion Thread.

The com-handler still assumes a serial connection speed of 500000 bps. This was changed a while ago to 250000 bps and the com-handler was never updated by its author. I plan to integrate similar functionality into DCS-BIOS 2.0, but that is still several months away at this point. What issues did you have with RS-485? What transceiver chips did you use?

kadda: DCS-BIOS uses the same refresh rate (30 times per second) for all values. And before this thread gets to page 80... No matter how often I ask people to make separate threads for separate issues, new support requests seem to end up here and this thread grows and grows. I did not have time to answer questions for the last four days and three questions have been posted since my last post in here (one of which has been resolved by the original poster). If I were to start answering them, we'd have several concurrent conversations in one thread again. And if this keeps up and I want to refer to one of the answers a few months from now, finding it again in a megathread would be more effort than typing it all out. This megathread has turned something I enjoy (helping people learn about electronics and programming) into a frustrating experience that I subconsciously avoid. I don't know why this happens. Maybe I suck at communicating. Maybe people are afraid I won't see their new thread in the Home Cockpits forum. Maybe they see a "DCS-BIOS Discussion Thread', do not read the first post, do not read any of the last posts, and just post away. Frankly, at this point I am annoyed enough that I don't care. From now on, I will no longer answer questions about how to use or extend DCS-BIOS in this thread. If you want me to spend a few minutes to answer your question, you can spend a few seconds to find that "new thread" button and think of a meaningful subject line. I am subscribed to the Home Cockpits forum and while I don't follow every thread closely, I make sure to visit all of the posts about once a day so the forum gets marked as read and I do not miss any new threads. @Patriot, SirBunker, KetPot: if you open a new thread for your respective issues I will be happy to help. I am not annoyed with any one person in particular, this post is just me venting frustration that has built up over the last few months.

The solution is probably the same as described in this post (wrong path for devices.lua and command_defs.lua). You should have an error message in dcs.log that tells you it could not find one of those files. Like jazzymanserg, you probably started by copying Mig21.lua and did not notice that the file paths are different. As far as I know, the Mig-21 is the exception; most other aircraft will have those files under Cockpit/Scripts. PS: Please make new threads for each issue. This thread was meant for general comments and feedback, not support requests.

Was kosten dich eigentlich die CAN-Bus-Transceiver? Ich hatte den CAN-Bus für DCS-BIOS verworfen, weil die Arduino-Boards mit ATMega328 keinen Controller integriert haben und ich keine zwei Chips verdrahten wollte. Und die MAX487 RS485-Transceiver gibt's spottbillig für ca. 20 Cent das Stück. Dafür ist das halt nur 250 kbps halbduplex. Schickst du DCS-BIOS-Nachrichten und -Daten über den CAN-Bus oder übersetzt du am Mainboard zwischen DCS-BIOS und einem eigenen Protokoll? Für DCS-BIOS 2.0 plane ich übrigens, ein Binärprotokoll für die Eingaberichtung einzuführen, hauptsächlich um Speicher auf den Mikrocontrollern zu sparen (weil der GCC die String-Literale ja ins RAM legt). Damit könnte eine DCS-BIOS-Nachricht in 8 Bytes passen, so dass sie in ein Paket auf dem CAN-Bus passt.

You might be able to add a custom kneeboard page.

The following works: BIOS.protocol.beginModule("F-5E", 0x3000) BIOS.protocol.setExportModuleAircrafts({"F-5E-3"}) local inputProcessors = moduleBeingDefined.inputProcessors local documentation = moduleBeingDefined.documentation local document = BIOS.util.document local parse_indication = BIOS.util.parse_indication local defineIndicatorLight = BIOS.util.defineIndicatorLight local defineToggleSwitch = BIOS.util.defineToggleSwitch local definePushButton=BIOS.util.definePushButton defineIndicatorLight("MC_LIGHT", 169, "Warning, Caution and IndicatorLights","MasterCaution Lamp") definePushButton("MC_RESET_BTN", 12, 3011, 172,"Warning, Caution and IndicatorLights" , "MasterCaution reset") BIOS.protocol.endModule() I found two problems: (1) The aircraft name of the F-5E is not "F-5E" but "F-5E-3" (as you can see in the "_ACFT_NAME" value in the MetadataStart module as described by the Developer Guide). I changed the call to setExportModuleAircrafts() accordingly. If there are other internal names for other variants of the aircraft, add them to the list. (2) Command identifiers must not contain spaces. They also must be at most 20 characters long and should consist only of capital letters and underscores.

Try the Uno again, it may have been miswired the first time.

Please open a new thread (this thread is not meant for help requests) and post your schematic. I just checked, the LEDs show up correctly in the interactive control reference.

This project broke when the mission file format changed a few months ago and I haven't bothered to fix it. I wanted to get to a point where it would modify waypoints while the mission is running, but that turned out to be impossible, so I abandoned the project. I also have my hands full with DCS-BIOS development now. If you want to fix this, look at admintool.html. It has two <span> tags, one for the code that translates a DCS mission into a JSON data structure (id="load_mission_lua") and one that translates that JSON data structure back into a Lua mission data structure id="save_mission_lua"). You would have to modify those Lua functions to work with the current mission file format. They are executed in the web browser using weblua. The Lua functions are called from JavaScript in admintool.js. Look at the create_instance() function and the click handler for the save button. Sorry for the messy code, because it was a proof-of-concept I never got around to cleaning it up.

Looks correct (assuming you are using the correct argument numbers and device IDs, I'd have to look at clickabledata.lua to verify that). I don't have time to look at this in depth right now, so I suggest to just try if it works with the interactive control reference. The memory allocation stuff is all done for you by the functions in Util.lua. You will only have to deal with this "low-level" stuff yourself if you encounter a control that does not conform to one of the common patterns; there seem to be one or two in each aircraft. If it doesn't work let me know, I can download the F-5E later, grab a beta tester key, and figure this out on my own machine.

Helios will display the MFCD bezel complete with working buttons. It won't send the contents from one PC to another. You can use Helios in combination with MonitorSetup.lua to get an MFCD on a second monitor of your DCS machine. DCS will put the contents on that screen and Helios will draw working buttons around it. Then you can use VNC to remote control that screen from your laptop. It will lag slightly even over a local network, but it works. The second screen does not have to be an actual physical screen. If your graphics card has a VGA output, you can probably tell Windows to simply assume there is a screen connected to it. If that does not work (for example because all of your GPU outputs are already in use), I think there are "virtual screen" drivers that you could use. There is also UltraMFCD, but I don't know if that works over the network.

Zum Ausprobieren bietet sich der "Sweep"-Beispielsketch an (Datei > Beispiele > Servo > Sweep in der Arduino-IDE). Wenn du ein Netzteil hast (Labornetzteil oder ein altes Computernetzteil, das du einschaltest, indem du Grün und Schwarz am 20- oder 24-poligen Mainboardstecker verbindest), kannst du den Servo darüber versorgen und nachmessen was der verbraucht. Ansonsten einfach über USB versorgen und sehen ob es klappt. Kaputt gehen tut dabei nichts: die Arduino-Boards haben eine sich selbst rückstellende Sicherung ("Polyfuse"), die verhindert, dass zuviel Strom aus dem USB gezogen wird. Selbst wenn die versagen sollte, die USB-Spec sieht vor, dass ein Motherboard sogar aushalten muss, wenn es einen Kurzschluss gibt. Wenn die Polyfuse auslöst, sieht es erstmal so aus, als ob das Arduino-Board hinüber ist. Einfach ein paar Minuten warten, dann tut's wieder. Wenn der Servo nicht richtig oder gar nicht funktioniert, bekommt er wahrscheinlich nicht genug Strom oder der Kondensator fehlt. Falls die Teilekiste gerade keinen passenden Kondensator beinhaltet, aber ein altes, kaputtes Motherboard zur Hand ist, findet man in der Nähe der Spannungswandler einige große Elkos zum Ausschlachten. Ein einzelner Hobby-Servo braucht in der Regel weniger als 400 mA. Sobald man mehr als einen anschließen will, kommt man aber auch je nach Servo-Typ schnell darüber.

Der Kontrollpin des Servos zieht nicht viel Strom, den kannst du direkt an den Arduino hängen. Der Servo selbst wird sich wahrscheinlich ein paar hundert mA genehmigen. Wenn das weniger als ca. 400 mA sind, kannst du den mit über USB versorgen, sonst brauchst du ein externes Netzteil. Da der Servo vergleichsweise viel Strom zieht, empfiehlt sich auch ein Kondensator (200 bis 500 Mikrofarad) zwischen +5V und GND in der Nähe des Servos.

Mit DCS-BIOS würde der Arduino-Sketch dafür ungefähr so aussehen: #include <Servo.h> // muss vor DcsBios.h inkludiert werden, um ServoOutput zu ermoeglichen #define DCSBIOS_IRQ_SERIAL #include "DcsBios.h" // die 544 und 2400 in der naechsten Zeile sind die Limits des Servos und werden // unveraendert an die Arduino Servo-Library weitergegeben // die 10 ist der Arduino-Pin, an dem das Kontrollsignal fuer den Servo ausgegeben werden soll DcsBios::ServoOutput flapPos(0x10a0, 10, 544, 2400, [](unsigned int newValue) -> unsigned int { // diese Funktion muss den Wert, den DCS-BIOS sendet (zwischen 0 und 65535) // in die Pulsbreite fuer den Servo umrechnen return map(newValue, 0, 65535, 544, 2400); }); void setup() { DcsBios::setup(); } void loop() { DcsBios::loop(); } Bei DCS-BIOS musst du dich etwas in die Programierung einarbeiten. Arduino-Tutorials und Bücher gibt es genug, es macht auch Spaß, sowas zu lernen, aber es kostet natürlich Zeit. Der Vorteil ist dann, dass du alle Bauteile verwenden kannst, die sich mit einem Arduino-Board ansprechen lassen (also so gut wie alles, inklusive kleinen Grafik-Displays, Schrittmotoren, Hobby-Servos oder Dot Matrix Display im CMSP). Die Arduino-Klone aus China funktionieren super und sind sehr preiswert: ca. 3 Euro für einen Arduino Nano mit 12 nutzbaren digitalen I/O-Pins, 2 analogen und 6 die digital oder analog genutzt werden können, oder 8 Euro für den Arduino Mega 2560 mit 52 nutzbaren digitalen I/O-Pins und 16 digital/analog-Pins.

Look at how the functions in Util.lua are implemented. They call performClickableAction(). You have to implement your own versions of these functions that call LoSetCommand() instead.

I plan to include something like this in a later version of DCS-BIOS 2. The new command API will get a 'gratuitous' bit which signifies that the command reflects the current status but was not the result of the user actually flipping a switch. The new middleware software will then include some way to specify which controls should react to such commands. I'll also have to provide a way to tell all boards to send gratuitous updates for every input where that is applicable (it does not make sense for rotary encoders). It is important that such a feature can be configured on a per-control basis because there are some things (battery power switch, EAC, ...) where it can cause more harm than good if it switches something off when entering a hot-start cockpit. So DCS-BIOS will eventually get such a feature (several people have asked for this over the years), but I need to do more fundamental work (DCS-BIOS 2, new binary input protocol, event mechanism) before this feature can be added. Personally, I never understood why you'd want to have such a feature. It would flip switches in your cockpit without knowing what it is doing, so it can switch off systems, switch them on before they are ready (e.g. not waiting for alignment), etc. I switched off the DCS option to synchronize my HOTAS throttle because several times I hopped into a hot start aircraft and my engines switched off because my throttle was still in the cut-off position.