FSFIan

Any errors in dcs.log? Anything else that is using Export.lua? (Helios and TacView are known to behave, but there are several Export.lua scripts written by beginners that don't play nice with other scripts) Are you using the correct Saved Games\DCS folder? (DCS 1.5 uses "Saved Games/DCS", DCS 2.0 uses "Saved Games\DCS.openalpha")?

Bei mir geht alles außer Dienstag (und wenns nicht anders geht dann auch das).

It's a very reasonable price considering the PCBs are produced in low quantities, it's plug and play, and the PS Cockpits software allows you to configure the pit for several different simulators and aircraft. For something to be "way overpriced", there has to be an alternative that achieves the same result for a lower price. DCS-BIOS may be cheaper hardware-wise, but it's by no means plug and play, there is no commercial support, and it's still in a proof-of-concept stage. If you build an A-10C pit with DCS-BIOS right now (v0.5.0 / Arduino lib v0.2.3), you won't be able to use it with any other aircraft. You also need to learn a little C++ if you want to go beyond toggle switches and LEDs. The one clear advantage that DCS-BIOS has is the flexibility. Because you are writing the firmware for your panels yourself, you can make them talk to any electronic component that you can get the datasheet for. It's a trade-off between the hardware cost and your time spent learning programming and electronics. Although I'd argue that spending time learning is more fun than spending time working to earn more money (depends on your day job I guess).

Ich hab mir mal den Code der SevenSeg-Library angesehen, insbesondere, was in display.interruptAction() passiert. Die Library ist einfach zu ineffizient programmiert. Der Arduino muss für die Kommunikation mit dem PC 25000 Zeichen pro Sekunde verarbeiten. Damit hat er für jedes Zeichen nur 1/25000 s Zeit, was bei 16 MHz 640 CPU-Takten entspricht. Wenn ein angekommenes Zeichen also innerhalb von 640 CPU-Takten nicht verarbeitet (also mindestens in den Empfangspuffer geschrieben) wird, geht es verloren und nichts funktioniert mehr. Die SevenSeg-Library benutzt wie viele andere Arduino-Libraries auch digitalWrite(), und das braucht zwischen 50 und 100 CPU-Takte pro Aufruf, je nach dem, welchem Blog-Artikel man glauben will (ich hab selbst noch nicht nachgemessen). Das eigentliche Umschalten des Pins braucht nur zwei Takte, aber digitalWrite() muss erstmal nachsehen, welches Hardwareregister denn jetzt zu "Pin 5" gehört und hat noch ein paar andere Checks drin. Wenn du display.interruptAction() aufrufst, passiert folgendes: 1. ein bisschen Verwaltungslogik sieht nach, ob das Display gerade an oder aus sein soll (wegen der Helligkeitssteuerung durch PWM). Die nächsten Schritte passieren, wenn das Display gerade an sein soll. 2. changeDigit() wird aufgerufen, um den richtigen Digit-Pin einzuschalten. Das ruft erstmal clearDisp() auf, um alle Segment-Pins (7x digitalWrite()) und alle Digit-Pins (2x) abzuschalten. Das verhindert, dass die aktuelle Ziffer auf der nächsten "durchscheint". Dann setzt es den passenden Digit-Pin für die aktuelle Ziffer (1x). => 10x digitalWrite() für Schritt 2 3. Die aktuelle Ziffer wird aufs Display geschrieben, dafür wird writeDigit() aufgerufen. Da wir einen String schreiben, wird die Character-Variante writeDigit(char digit) genommen. Erste Amtshandlung: alle Segment-Pins ausschalten (7x). Dann stellt writeDigit(char digit) fest, dass es sich um eine Ziffer (und keinen Buchstaben) handelt, und delegiert an writeDigit(int digit), das wiederum erstmal alle Segment-Pins abschaltet (14x) und dann noch die richtigen Segmente wieder anschalten muss... => mindestens 14x digitalWrite() für Schritt 3 Selbst wenn wir annehmen, dass digitalWrite() nur 30 Takte braucht, benötigt ein Aufruf von display.interruptAction() also mindestens 720 CPU-Takte. Während ein Interrupt abgearbeitet wird, müssen alle anderen warten. Wenn jetzt gerade Daten vom PC reinkommen, gehen Zeichen verloren, weil alle 640 CPU-Takte das nächste Zeichen da ist, es aber nicht in den Empfangspuffer geschrieben wird, weil der Mikrocontroller immer noch mit display.interruptAction() beschäftigt ist. Du musst entweder eine besser optimierte Library finden oder den SevenSeg-Code nur aus dem Hauptprogramm aus aufrufen. Versuch mal das hier (ungetestet): #include <SevenSeg.h> #define DCSBIOS_IRQ_SERIAL #include "DcsBios.h" /* paste code snippets from the reference documentation here */ SevenSeg disp(11, 10, 9, 8, 7, 6, 5); const int numOfDigits = 2; int digitPins[numOfDigits] = {4, 3}; DcsBios::StringBuffer<2> uhfPresetBuffer(0x1188, NULL); void setup() { DcsBios::setup(); disp.setDigitPins(numOfDigits, digitPins); disp.setCommonCathode(); } void loop() { DcsBios::loop(); disp.write(uhfPresetBuffer.getData()); }

Your sketch was written for an older version (before v0.2.0) of the Arduino library. You'll have to remove any code belonging to the old template, then copy what's left into the new one (Examples -> DcsBios -> IRQSerial). You should arrive at something like this (untested): #define DCSBIOS_IRQ_SERIAL #include <DcsBios.h> #include <LiquidCrystal.h> LiquidCrystal lcd(2, 3, 4, 5, 6, 7); void onCmsp1Change(char* newValue) { lcd.setCursor(0, 0); lcd.print(newValue); } DcsBios::StringBuffer<16> cmsp1Buffer(0x1000, onCmsp1Change); void onCmsp2Change(char* newValue) { lcd.setCursor(0, 1); lcd.print(newValue); } DcsBios::StringBuffer<16> cmsp2Buffer(0x1014, onCmsp2Change); void setup() { DcsBios::setup(); lcd.begin(16, 2); lcd.clear(); } void loop() { DcsBios::loop(); } PS: Please make a new thread for things like this in the future. Troubleshooting often requires several back-and-forth posts and it becomes confusing when two of those conversations are going on in the same thread at the same time. It also makes it easier to find the answer again in the future.

Wenn du am Ende deiner setup()-Funktion ein display.write("42") einfügst, zeigt das Display dann die 42 an? Sicherheitshalber kannst du auch nochmal testen, ob die Kommunikation nach dem Upgrade auf v0.5.0 / v0.2.3 noch funktioniert, indem du irgendeine Signallampe auf die an Pin 13 angeschlossene LED des Arduinos legst, z.B. die hier: DcsBios::LED nmspIlsLed(0x1112, 0x0020, 13); und dann nachsiehst, ob die angeht, wenn du den SIGNAL LAMP TEST Button in der A-10C benutzt. Ich kenn mich zwar mit der SevenSeg-Library nicht aus, aber nach meinem Verständnis der Dokumentation sollte dein Sketch eigentlich funktionieren. Wenn ich nächste Woche etwas Zeit finde, werd ich mir das mal auf nen Pro Mini flashen und damit rumspielen.

Mach mal das #include <Servo.h> weg, vielleicht belegt die Servo-Library den Timer, den die SevSeg-Library benutzen will. Außerdem solltest du auf die aktuelle Version von DCS-BIOS (v0.5) und der Arduino Library (v0.2.3) umsteigen und das IRQSerial-Template benutzen. Ab v0.2.3 wurde der Code für die Kommunikation auf dem Arduino deutlich verbessert, so dass es bei Ausgabeelementen wie (Text)displays, deren Ansteuerung einige Zeit dauern kann, nicht mehr zu Problemen kommt.

Ja, das funktioniert (jeder Arduino braucht eine eigene Kopie von connect-serial-port.cmd, in der der passende COM-Port eingetragen ist). Für mehr als zwei oder drei Panels wird das aber viel zu nervig, wenn Windows sich mal wieder entschließt, die COM-Ports neu zu nummerieren. Ich hab auch schon von Leuten gelesen, die ab ca. 20 USB-Geräten (Joysticks, Leo Bodnar Boards, etc) Probleme bekommen haben und eine weitere USB-Karte in den Rechner stecken mussten, obwohl USB theoretisch bis zu 127 Geräte pro Host Controller erlaubt. Kurz gesagt: das wird mit einem kompletten Cockpit mit geschätzt 40 bis 60 Arduino-Boards nicht gut funktionieren. Deshalb unterstützt die DCS-BIOS Arduino Library ab Version 0.2 auf dem Arduino Mega 2560 sowie auf Unos, Pro Minis, Nanos und anderen Boards mit ATMega328-Controller die Kommunikation über einen RS-485 Bus. Jedes Arduino-Board wird mit einem RS-485 Transceiver-Chip verbunden. Meine Empfehlung ist der MAX487, den bekommt man im DIP-8-Gehäuse für ca. 20 Cent das Stück. Die Transceiver-Chips werden dann hintereinandergeschaltet (der Bus besteht aus zwei Leitungen, die "A" und "B" genannt werden). Ein als "Master" programmierter Arduino Mega 2560 kann bis zu zwei (oder drei, wir sind uns noch nicht sicher) RS-485-Busse mit dem PC verbinden. An jeden RS-485-Bus können mit dem MAX487 bis zu 126 Boards angeschlossen werden. Wenn der Bus länger als ca. 10 Meter wird, braucht man Abschlusswiderstände und die Zahl der möglichen Geräte am Bus sinkt auf ca. 20 bis 24. Leider ist das Ganze noch nicht im User Guide dokumentiert -- die einzige Doku sind die kurzen Kommentare in den RS485Master und RS485Slave Beispielsketchen. Hauptsächlich deshalb, weil die ganzen Angaben in diesem Post auf meinem theoretischen Verständnis beruhen, ich hab selbst bisher nicht mit mehr als drei Boards und ein paar Zentimeter Leitungslänge getestet. Der Code funktioniert zwar, bevor ich das aber "offiziell" dokumentiere (und damit auch supporte), möchte ich die Grenzen besser verstehen (z.B. mit dem Oszilloskop mal nachmessen, wie das Signal bei 30 m Leitungslänge ohne Abschlusswiderstände denn aussieht) und etwas bessere Diagnosemöglichkeiten schaffen.

Here is a version of that Caution Lights Panel sketch that works with the current version of the DCS-BIOS Arduino Library.

Ich studiere in Dortmund. Seit gut zwei Jahren (seitdem WarHog sein Simpit baut) beschäftige ich mich mit der Elektronik und Programmierung von DCS-Simpits. Aus dieser Zusammenarbeit ist auch DCS-BIOS entstanden. Um selbst ein Simpit zu bauen fehlen mir gerade leider das Geld, der Platz und die Zeit.

The way that question is asked, you may get a "yes" from someone who has tried it before (unlikely), but no one can answer "no" because they can't rule out the possibility that there is someone else out there that did try it. I assume you want to know if it is possible and if so, how to do it. We are going to need more information to be able to answer that question. Is the script running inside a mission, in another Lua environment inside DCS (e.g. server), or as a standalone Lua script? Is the mission running when you want to make that modification? Is it a single player mission (might be possible) or a multiplayer mission (probably won't work because the DCS.exe process has that file open)? Has the sanitation module been disabled (whether this is required depends on where the script is running)? And the most important one -- what are you trying to achieve with that in the first place? (There might be an easier solution.)

Das von dir verlinkte Tutorial ist ganz ok, wenn du verstehen willst, wie Multiplexing funktioniert. Der Code ist sehr einfach gehalten, so dass du direkt ablesen kannst, was wann an den Arduino-Pins passiert. Das macht den Code aber auch ungeeignet für eine praktische Anwendung, weil die Details der Ansteuerung nicht vernünftig gekapselt wurden. Eine gut gemachte Library sollte die Details vor dem Benutzer verstecken, so dass nur eine Handvoll Codezeilen übrig bleiben, die abstraktere Dinge wie "das Display hängt an diesen Arduino-Pins" oder "zeige 02 an" ausdrücken -- um das Multiplexing soll sich die Library im Hintergrund selbst kümmern. Die ersten beiden Treffer, die mir Google für "arduino 7 segment multiplexing library" ausspuckt, sehen beide ganz brauchbar aus: Arduino Playground: SevenSeg v1.2 Arduino Playground: SevSeg Library Beiden Libraries liegen Beispiele und Dokumentation bei, die zeigen, wie man sie benutzt. Die SevenSeg-Library (erster Link) hat sogar eine "write"-Methode, die einen nullterminierten String als Parameter akzeptiert, so dass du einfach "disp.write(newValue);" schreiben kannst. Es spricht erstmal nichts dagegen, das Display per Multiplexing anzusprechen. Wenn du deutlich mehr 7-Segment-Anzeigen oder anderes Zeugs an den gleichen Arduino hängen willst, gehen dir irgendwann die Arduino-Pins aus oder der Stromverbrauch wird zu hoch, um alles vom Mikrocontroller selbst zu versorgen. Irgendwann wirst du auch an die Grenzen des 16 MHz-Prozessors stoßen. Ich vermute, dass die ersten beiden Limits zuerst greifen, bin mir da aber nicht sicher. Es gibt auch externe Chips, die speziell zum Ansteuern von 7-Segment-Anzeigen gebaut sind und sich um das Multiplexing und die Stromversorgung kümmern. Ein recht bekannter Vertreter ist der MAX7219. Wenn du mit sowas mal rumspielen willst, kann ich dieses Modul empfehlen. Die Arduino-Library "LedControl" macht es recht einfach, die Dinger anzusteuern. Kommunikation mit dem Mikrocontroller erfolgt per SPI, du brauchst also nur drei Arduino-Pins, um mit einem (oder mehreren, die Dinger kann man hintereinanderschalten) MAX7219 zu reden. Ein MAX7219 steuert bis zu acht 7-Segment-Anzeigen an.

I just listened to the lastest one on the train, learned many interesting things and had a great laugh at all of the anecdotes. Great stuff as always!

Stimmt genau. Das hab ich beim Schreiben des Posts doch glatt aus den Augen verloren :doh: Also einfach Kabel rauslöten und gut ist.

Die Schaltung sieht vermutlich so ähnlich wie das hier aus: VCC ---- R1 ---- Analogeingang ---- Sensor ---- GND oder VCC ---- Sensor ---- Analogeingang ---- R1 ---- GND R1 ist ein Widerstand, der Analogeingang sitzt entweder an einem Mikrocontroller mit integriertem ADC oder an einem externen ADC-Chip. Der Lichtsensor ist entweder ein lichtempfindlicher Widerstand (mehr Licht -> Widerstand sinkt) oder ein Fototransistor (mehr Licht -> mehr Strom). In beiden Fällen würde ein Kurzschließen des Lichtsensors maximalen Lichteinfall signalisieren. Dann muss aber R1 groß genug sein, um den Strom soweit zu begrenzen, dass nichts kaputt geht. Das ist höchstwahrscheinlich der Fall, aber einmal nachmessen kann nicht schaden. Unter Umständen kann R1 auch ein interner Pullup- oder Pulldown-Widerstand im Mikrocontroller sein, allerdings sind die oft zu hochohmig dafür.

Mit normalen USB-zu-Gameport-Adaptern "von der Stange" wird das nicht funktionieren, weil die den Force Feedback-Teil ignorieren. Außerdem benutzt der MSFFB-Treiber den Gameport in einer unkonventionellen Weise, um mit dem Joystick ein digitales Protokoll zu sprechen. Das funktioniert nur mit genauem Timing, und das wird durch die generischen USB-Adapter zunichte gemacht. Es gibt eine Open Source Firmware, mit der man sich einen speziellen USB-Adapter für den MSFFB Pro aus einem Teensy-Board (ca. 22 €) und einer Gameport-Buchse selbst bauen kann. Mein erster Versuch damit ist fehlgeschlagen, ich hatte das aber auch mit einem Arduino Pro Micro (ca. 3,50 €, basiert auf dem gleichen Mikrocontroller) statt nem Teensy probiert und vielleicht ist mir da beim Anpassen des Codes ein Fehler unterlaufen. Ich hab noch keine Zeit in die Fehlersuche gesteckt. Mein persönliches Ziel damit ist nicht den Adapter zu bauen (dafür hab ich nen MSFFB2), sondern einen Schubregler mit programmierbaren Detents.

Das müssten Dioden sein, zwei pro Package, mit einem gemeinsamen Pin. Damit kommt man auf acht Dioden, eine für jeden Schalter am Griff. Die Funktion der Dioden in einer Tastaturmatrix ist, dass auch mehrere gleichzeitig gedrückte Tasten korrekt ausgelesen werden können. Die Schaltung ist wohl entweder eine 2x4 oder 3x3 Matrix. Damit ist dann auch die Anzahl von sechs Anschlussdrähten erklärt. Du kannst in deinem Ersatzgriff entweder die Matrixschaltung nachbauen oder einfach die Taster im Ersatzgriff parallel zu den Tastern auf der Platine schalten.

Wenn du in C++ zwei Strings mit dem Operator == vergleichst, vergleichst du nur die Speicheradressen. Um den Inhalt zu vergleichen, musst du die strcmp-Funktion verwenden. Die gibt 0 zurück, wenn die Strings gleich sind, ansonsten einen Wert kleiner oder größer als 0, je nachdem, welcher String lexikographisch nach ASCII-Werten sortiert zuerst kommt. Versuch mal folgendes: void onUhfPresetChange(char* newValue) { if(!strcmp(newValue, "02")){ digitalWrite(12,HIGH); delay(1000); digitalWrite(12,LOW); } }

Try the new v0.2.3 release of the Arduino library, that should fix your issue.

Released v0.2.3 of the Arduino library. This fixes a bug that would lead to some outputs not working when combined with certain other outputs in the same sketch.

I am aware of this and am looking into it. See also: https://github.com/dcs-bios/dcs-bios/issues/87

Um ServoOutput benutzen zu können, muss vor dem "#include <DcsBios.h>" ein "#include <Servo.h>" stehen. Ich sehe gerade, dass das in den aktuellen Beispielen nicht drin steht, das hab ich wohl beim Wechsel auf v0.2 verbockt. Der technische Hintergrund ist der, dass ich vermeiden wollte, den Nutzer zu zwingen, die Servo-Library reinzukompilieren -- die belegt nämlich einen Hardware-Timer, den man vielleicht für was anderes benutzen will. Deshalb wird die von der Servo-Library abhängige ServoOutput-Klasse nur reinkompiliert, wenn die Servo-Library bereits explizit eingebunden wurde, anstatt in der DCS-BIOS Arduino Library das "#include <Servo.h>" zu setzen.

Bei allem, was ich von Dortmund aus mit dem ÖPNV erreichen kann, wäre ich auch gelegentlich dabei. EDLB ist nur 15 km von zu Hause entfernt. Wenn ich das ne Woche vorher weiß, kann ich planen, dann zu Hause zu sein und das per Auto erreichen.

Lua table entries do not have any defined order. The mist.utils.serialize function uses pairs() to iterate over the table entries, which returns the items in whatever order they happen to be in memory (which might depend on the order they were inserted and/or on some internal hash function). You could make a copy of the mist.utils.serialize function and replace the call to pairs() with ipairs(). That would output numeric keys in order, but skip non-numeric keys. To make it work with arbitrary tables, which may include non-numeric keys, you would have to first build a list of all keys and sort it. This wiki page has more information on ways to serialize tables in Lua, but at a quick glance I could not see a solution that (a) sorted keys, (b) produced machine-readable data (i.e. valid Lua) and © was written in pure Lua code.

Released v0.2.2 of the Arduino library. fix a bug with the dirty bit logic in Int16Buffer. If no previous updates had been received (e.g. when the Arduino had just started up), a data update from DCS-BIOS that tried to set the value to zero would not mark the data as dirty, so getUpdatedData() would still return false.