FSFIan

Unlike the UHF radio knobs and most other multiposition switches, the radio knobs in the A-10C only support commands for relative movement. Because DCS animates those knobs, I cannot send several of those in a single frame, so I can't fake a "set absolute position" command either. Later, I learned that there is also the set_frequency function on the radio device, which can be used to instantly set a radio frequency, but that only works for frequencies in the supported range of the radio (e.g. it does not support setting the VHF AM radio to "31.000", which you can do when manipulating the knobs manually to get the "out of frequency range" warning tone). Since I wanted DCS-BIOS to mimic the actual cockpit controls as close as possible, I did not use that. If it helps, I could add a hack to call set_frequency() for the VHF AM and FM radios, which would only work for frequencies inside the supported range of the radio.

Ich habe keine Ahnung, wie du darauf kommst, dass das Verändern des "if(digit<0 || digit>7)"-Teils irgendetwas mit deinem Problem zu tun hat. Ich habe in beiden meiner Posts gesagt, du solltest dir mal for-Schleifen ansehen. Das hast du offensichtlich nicht (gründlich genug) getan, sonst hättest du verstanden, warum die beiden Ziffern falsch herum angezeigt werden (und wüsstest, wie du es fixt). Ich bekomme den Eindruck, dass du kein Interesse daran hast, C++ zu lernen, sondern einfach nur Ergebnisse haben willst. Dagegen ist nichts einzuwenden, aber mit dieser Einstellung ist DCS-BIOS bei allem, was über Kopieren aus der Dokumentation hinausgeht, das falsche Produkt für dich. So wie ich das sehe, habe ich zwei Möglichkeiten: 1) Ich beantworte Anfängerfragen mit einem Stück Code, was ohne es zu verstehen direkt übernommen werden kann. Das muss ich dann fairerweise bei jedem so machen, und das kostet eine Menge Zeit, insbesondere weil ich mir ziemlich sicher sein muss, dass der Code auch funktioniert, da ich den ja i.d.R. ohne die Schaltung auf dem Schreibtisch nicht testen kann. Dazu kommt, dass man durch Copy+Paste nicht Programmieren lernt. Anfänger bleiben also Anfänger und die nächste Frage lässt nicht lange auf sich warten (und ist auch nicht komplexer als die erste). 2) Ich beantworte Anfängerfragen mit Hinweisen, die dem Fragesteller dabei helfen, das Problem selbst zu lösen. Das kostet mich deutlich weniger Zeit. Der Fragesteller hat nachher verstanden, wie der Fehler entstanden ist, wird den gleichen Fehler nicht wieder machen und kann anderen helfen, die ähnliche Probleme haben. Langfristig sinkt also die Anzahl der Fragen, die gestellt werden, und die Anzahl der Leute, die Fragen beantworten können, steigt. Ich habe mich für Option 2) entschieden, da ich einerseites für 1) keine Zeit habe und andererseits Option 2) auch aus Sicht der Community für die bessere Wahl halte.

Du schreibst die fehlenden Zahlen nie auf das Display. Guck dir nochmal an, was eine for-Schleife macht. Wenn du die for-Schleifen weiter behalten willst, dann musst du auch die Laufvariable i für die Position verwenden und die Schleife so anpassen, dass der Zähler über die richtigen Werte läuft. Alternativ kannst du die Schleifen entfernen und für jede Stelle einen eigenen lc.setChar()-Aufruf einfügen.

Der Sketch nimmt an, dass die Ziffern von links nach rechts durchnummeriert sind. Deine Platine nummeriert die aber von rechts nach links (d.h. "digit 0" ist ganz rechts). Da musst du nicht an der Platine rumlöten, du musst nur den Sketch so anpassen, dass er die richtige Ziffer an die richtige Stelle schreibt. Anhand der LedControl-Dokumentation (der Abschnitt über "setChar()") kannst du nachvollziehen, warum der folgende Befehl das zweite Zeichen aus dem String "newValue" an die vierte Stelle von rechts auf deiner Anzeige setzen würde: lc.setChar(0,3,newValue[1],false); Dann sollte auch klar sein, wie du den Code anpassen musst (und wie du den Dezimalpunkt an die richtige Stelle setzt).

Wenn dein Display das ganze spiegelverkehrt anzeigt, ist es vielleicht einfach anders verdrahtet, als die LedControl-Library es erwartet. (Meinst du eigentlich spiegelverkehrt, also "ES" statt "32", oder rückwärts, also "23" statt "32"?) Hier ist mal eine Liste von Konzepten, die man braucht, um den Code zu verstehen: C++-Kontrollstrukturen (for-Schleife) Arrays, Repräsentation von Strings als nullterminierte Character-Arrays was lc.setChar() macht, steht in der Dokumentation der LedControl-Arduino-Library Deine Frage hat eigentlich nichts mit DCS-BIOS an sich zu tun, es läuft eher auf "kannst du mir C++ erklären" heraus. Dazu existieren bereits viele kostenlose Ressourcen, die besser sind, als alles, was ich je schreiben könnte. Eine Google-Suche nach "Einführung in C++" bringt schon einige Treffer. Manche Unis stellen ihre Vorlesungsfolien online, es gibt Bücher, die sich auf den Arduino spezialisieren, etc. Wenn du eine Frage hast, die spezifisch genug ist, dass ich die Antwort dazu in ein paar Minuten aufschreiben kann, dann helfe ich dir gerne, aber wenn die Frage so allgemein ist, dass ich ein halbes C++-Tutorial als Antwort schreiben müsste, fehlt mir einfach die Zeit dazu.

The code is at the "theoretically, this should work" stage. It still needs a good look at the timing on a logic analyzer to see if it can work reliably, figure out its limitations (how many different outputs can a single Arduino support?) and I need to test over distances of more than 10 centimeters. I also have not written any documentation on it yet. The problem is that in this semester, as part of my computer science curriculum I am part of a "project group" where we try to build a solar-powered electronic doorplate. That means another 14+ hours a week of programming embedded systems. It's fun to do, but after I have spent several hours at uni chasing down some hard-to-find bug, I usually lack the energy and motivation to hack on DCS-BIOS in the evening. My plan is to get things to a publishable state at the end of the year. From December 27th to December 30th, I will be in my dorm room to watch the video streams from the 32nd Chaos Communication Congress. I will not be distracted by family or university, so in between talks I hope to make significant progress on DCS-BIOS. Note that this does not mean there will definitely be a release this year. I don't want to release any code unless I am convinced it is reliable, because once I release anything, I will probably have to deal with several reports of "It doesn't work", to which I want to be able to answer "check your wiring" with some confidence.

This change is not new to 1.5, is has been in 1.2 for quite some time now. The files in the "Saved Games" folder will only store the differences to the default configuration so your key bindings survive DCS updates better. You can edit the default configuration file for your aircraft instead, for example as mentioned in this post (on the pages before that post, you can see how everyone else in that thread figured that out, my post was just a summary of that and most of it deals with how to find the correct argument numbers and device IDs).

How many positions does your switch have and what switch did you use to test? If I understand your code correctly, I'd expect it to always be set to the last position that changed state, e.g. if you switch from position 4 to 3, pin 4 changed from low to high, pin 3 changed from high to low, so 3 and 4 changed state, your code would send "YOUR_SWITCH 3" and "YOUR_SWITCH 4" in sequence and the switch would end up in position 4. Without the rest of your code and the schematic it is almost impossible for someone else to properly debug this. A proper bug report always needs these three things: - What did you do? (including links to source code and schematics) - What did you expect to happen? (This catches errors in the documentation and/or the user's mental model of how things should work) - What happened instead? ("It didn't work" only tells us that it didn't do what you thought it should do. But did the Arduino work at all (e.g. other inputs/outputs still work), hang completely, ...) Even if you provide all that, there's still the possibility that your schematic does not match the hardware on your desk, e.g. loose wires, flaky power supply, etc, but if you get these three points right you get the best chance that someone is able to help you. EDIT: A second after hitting submit (while viewing my submitted message) I spotted something: you are sending the "state" variable, which will be 1 or 0 depending on whether the pin is high or low. I'd still expect it to switch between the first and second position depending on the direction you move your switch in.

The Lua environment for mission scripts is limited by design (to prevent malicious mission scripts from messing with your files, turning your PC into a spam bot, etc). You can get around that by editing Scripts\MissionScripting.lua in your DCS installation directory (sometimes referred to as the "sanitation module"). If you publish anything that requires editing that file, make sure to warn your users about the increased risk or keep the existing sanitation code intact, load your own code before that and make sure that nothing you expose to the global namespace can be used to cause harm (e.g. keep a file-local copy of the "require" function etc. and expose a global function that only lets you write to a predetermined file / network port / whatever). I'd suggest posting any follow-up questions in a new thread, as this is not a MiST-specific issue. Edit: On a completely unrelated note, I just noticed that my post count is my phone number (without area code) right now *g*

An den I2C-Master kannst du keine Eingabegeräte anschließen. Wenn die auf dem Uno mit dem gleichen Sketch funktioniert haben, würde mich das sehr wundern. Das I2C-Beispiel hab ich damals relativ schnell zusammengefrickelt, weil die Frage, wie man denn nun mehrere Boards gleichzeitig verwenden kann, so oft kam. I2C ist allerdings nur für kurze Distanzen gedacht, deshalb arbeite ich an dem Code auch nicht mehr weiter, sondern bin dabei, Kommunikation über einen RS-485-Bus zu implementieren.

Der Arduino-Sketch tut was er soll und die Kommunikation über den seriellen Port tut auch. DCS-BIOS läuft auch ohne Fehlermeldungen. Die einzige plausible Erklärung, die ich noch habe, ist eine seltsam konfigurierte Firewall, die das Paket zwischen socat und DCS abfängt, ohne socat am Senden oder DCS am öffnen des Ports zu hindern. Welches Firewall / Antivirus-Produkt benutzt du und hast du das mal testweise abgeschaltet?

So langsam gehen mir die Ideen aus. Irgendwelche Fehlermeldungen in der dcs.log? Die Kommunikation mit dem Arduino funktioniert ja offensichtlich. Wenn du den Taster drückst, müsstest du auch im socat-Fenster was sehen. Du sagst, das Skript mit TCP-Verbindung "ging auch nicht". Hat das denn genau so reagiert wie das andere (DCS -> Arduino geht, Arduino -> DCS nicht) oder ging da gar nichts? Hast du es testweise mal ganz ohne Firewall versucht?

Die Meldung ist eine Compilerwarnung, es sollte aber trotzdem funktionieren. Kann es sein, dass deine Firewall/Antivirus DCS.exe daran hindert, auf UDP-Port 7777 nach eingehenden Paketen zu lauschen? Funktioniert die interactive control reference documentation? Du kannst mal das connect-to-serial-port.cmd aus diesem Post hier versuchen, das nimmt TCP statt UDP.

Ich hab mir das nochmal angeschaut. Vergiss alles, was ich in meinem letzten Post gesagt habe, dein Encoder funktioniert wie jeder andere auch. Ich war nur durch die Bezeichnungen "clock" und "direction" verwirrt. Die Bezeichnungen ergeben durchaus Sinn, wenn man mal drüber nachdenkt... Dein Code kompiliert nicht. Wenn ich die Zeile "#include <Encoder.h>" entferne, funktioniert es bei mir mit der aktuellen Release-Version (DCS-BIOS v0.4.1, DCS-BIOS Arduino Library v0.1.3).

Das Encoder-Modul, was du da verlinkt hast, hat als Ausgang "clock" und "direction"-Signale. Wusste gar nicht, dass sowas existiert, ist aber nicht weiter überraschend im Zeitalter von güstigen Arduino-Breakout-Boards für alles mögliche. Die RotaryEncoder-Klasse in DCS-BIOS geht davon aus, dass da ein Encoder ohne weitere Elektronik dranhängt, z.B. diese hier. Normalerweise ist so ein Encoder eine rein mechanische Komponente. In dem im letzten Absatz verlinkten Beispiel sind die zwei Pins an der einen Seite für den integrierten Schalter. Von den drei Pins an der anderen Seite wird abwechselnd der linke oder der rechte mit dem mittleren verbunden, und das passiert je nach Drehrichtung in einer anderen Reihenfolge. Wenn man einen Schritt in die eine Richtung geht, dann machen die zwei äußeren Pins das hier ("1" = verbunden, "0" = nicht verbunden): 11 -> 10 -> 00 -> 01 -> 11 in die andere Richtung ist es natürlich genau andersherun: 11 -> 01 -> 00 -> 10 -> 11 Das wird auch als "2-bit Gray Code" bezeichnet (bei einem Gray Code ändert sich zwischen zwei aufeinanderfolgenden Zuständen immer genau ein Bit). Manchmal liest man auch von einem "quadrature encoder", damit ist das gleiche gemeint. Daran kann ein Mikrocontroller dann erkennen, in welche Richtung du den Encoder drehst. Auf dem Modul, was du gekauft hast, sitzt wohl schon Elektronik drauf, die das in "Richtung" und "Takt" übersetzt. Damit rechnet DCS-BIOS nicht. Du hast jetzt mehrere Möglichkeiten: Bestelle dir "normale" rotary encoder Schreibe eine modifizierte RotaryEncoder-Klasse für DCS-BIOS, die die Signale deines Encoder-Moduls richtig interpretiert Löte den Encoder von deinem Modul runter (in der Annahme, dass sich der Rest der Schaltung zwischen Encoder und Platine versteckt und nicht im Encoder selbst eingebaut ist)

Du hast ja an der Stelle in newValue einen String stehen, z.B. "225.000". Damit kannst du machen, was du willst, also auch auf 7-Segment-Anzeigen darstellen. An die einzelnen Zeichen kommst du wie bei allen C-Strings durch Array-Notation dran (z.B. newValue[2] für das dritte Zeichen, die '5'). Der von DCS-BIOS exportierte String hat immer 7 Zeichen. Beim UHF-Repeater musst du natürlich auch bedenken, dass ein Zeichen auch 'A' (als Teil der Frequenz) oder '*' (wenn der UHF-Repeater "bootet") oder " " (Leerzeichen, wenn das Display aus ist) sein kann, d.h. dein Code sollte damit klarkommen und nicht annehmen, dass es immer zwischen '0' und '9' ist. Den Punkt in der Mitte wirst du auch ignorieren wollen und stattdessen für deine 7-Segment-Anzeigen das "decimal point"-Segment beim dritten Zeichen einschalten. Wie genau du jetzt deine 7-Segment-Anzeigen ansteuerst, kann ich dir nicht sagen, das hängt davon ab, welche Library und Schaltung du benutzt (Zuordnung Segmente zu Bits im Shift-Register, Multiplexing ja oder nein, etc).

Hast du für 1.5 auch die Export.lua nach %USERPROFILE%\Saved Games\DCS.OpenBeta\Scripts kopiert? Die Open Beta hat ihr eigenes Verzeichis für Benutzerdaten.

Bei mir läuft DCS-BIOS unter 1.5 unverändert. Was genau funktioniert denn nicht? (Was hast du getan, was ist passiert, was hätte stattdessen passieren sollen?)

The current DCS-BIOS Arduino Library uses the default Serial library that comes with the Arduino IDE. When data comes in, it is written to a receive buffer. Data is read from that buffer in the loop() function. If you have lots of outputs or an output that takes a long time to update (such as a graphical display), the buffer may not be large enough, so data gets corrupted. The "UUU" you are seeing is the beginning of the next DCS-BIOS update packet. As a workaround you can try to decrease the baud rate so the buffer does not fill as fast (change it in the Serial.begin() line and the connect-to-serial-port script, e.g. from 500000 to 115200). You could also increase the receive buffer size (IIRC that requires editing some files in your Arduino IDE install, Google is your friend). Another thing you could do is to ignore the StringBuffer class and instead write to the display in the onDcsBiosWrite function to update it two characters at a time (but that only works if the display library you are using does not update the entire display when you change only a small area). The problem can only be fixed by a significant redesign of the way the Arduino library handles communication. I am working on that as part of implementing RS-485 support, but I have no ETA on it (although I hope to get it working and published before the end of the year). PS: In the future, it might help to include more information when asking for help. This happened to be an already known and easily identifiable problem, but if it had not been, coming up with possible causes would be very difficult with just a screenshot.

Yes, although you could also use "landingaircraft.groupname" and "landingaircraft.unit", which is a bit less verbose.

Nach meinen Erfahrungen startet DCS in einem verschiebbaren Fenster, wenn (a) Vollbild aus ist und (b) die eingestellte Auflösung kleiner als deine Desktop-Auflösung ist.

Yes, this is possible. I assume you want the mission scripting environment, in that case take a look at Scripts\MissionScripting.lua in your DCS: World installation directory. Have it execute a script file before all the fun stuff (require, lfs, io, etc.) gets removed from the environment to protect the user from malicious mission files. In your script file you can use LuaSocket to spin up a server that accepts lua snippets to execute. Make sure that your script does not expose any fun stuff to the global mission environment (grab what you need and stuff it into file-local variables). The source code of DCS: Witchcraft (link in my sig) provides an example. In Witchcraft, I have DCS connect as a client to the external program that provides the server because I didn't want to think about concurrent connections in Lua when I wrote it. For an example of a TCP server in Lua, look at the DCS-BIOS source code. What does your external service do?

The following code snippet would not change the table: for unitName, landingaircraft in pairs(landingaircraftsING) do landingaircraft = nil -- this line would not delete anything from the table, landingaircraft is just another local variable that points to the same object as the table entry end This code snippet would delete all entries from the table: for unitName, landingaircraft in pairs(landingaircraftsING) do landingaircraftsING[unitName] = nil -- set table entry to nil end If you see "_" used in a for loop, it is just a variable like any other -- the convention is to use it in place of a descriptive name when you do not care about that part of the key-value pair, i.e. the "_" variable should never be used inside the body of the loop.

I always use the ready-made "Free Flight - Runway Start" mission that comes with the A-10C. Start up hot lined up on the runway and nothing else in the mission that wants to kill me.

DCS-BIOS sendet die Werte an 192.168.55.51:7777, aber socat lauscht immer noch auf der Multicast-IP. Ersetze die socat-Zeile durch folgende, dann sollte es gehen: C:\Users\rocco\DCS_Place\dcs-bios\socat\socat -v UDP4-RECV:7777,reuseaddr!!udp-sendto:192.168.50.44:7778 /dev/ttyS%TTYNUM%