FSFIan

Released v0.2.9 of the Arduino Library. I forgot to post an announcement here for v0.2.8, so here's the changelog for both versions: New in v0.2.8: add ability to pass a custom map function to the ServoOutput class provide DcsBios::piecewiseMap template function adopt recommended file structure for Arduino libraries and add metadata file New in v0.2.9: fix more (const) char* related compiler warnings (ActionButton, Potentiometer) Please post comments in the DCS-BIOS Discussion Thread.

Versuch mal das Script aus diesem Post, das benutzt TCP statt UDP. Da die interactive control reference geht (die benutzt auch TCP), sollte es damit dann laufen.

Du musst vor dem #include "DcsBios.h" noch ein #include "Servo.h" setzen, um die Servo-Library mit einzubauen. DCS-BIOS macht das nicht von sich aus, weil die einen der Timer vom Arduino belegt. Ich hab gerade nochmal in der Doku geguckt, da steht das gar nicht drin... ich glaube ich hatte das früher in den Template-Sketches drin und das ist dann bei der Einführung von IRQ_SERIAL rausgeflogen. Ich werd das in Zukunft wahrscheinlich so machen, dass alles was von anderen Libraries abhängt (Servos und demnächst mal auch Stepper) in ganz eigenen Header-Files liegt, dann muss ich nur noch einen Mechanismus in die Referenzdoku einbauen, so dass bei entsprechenden Code Snippets ein Hinweis eingeblendet wird oder so.

Nein. Selbst wenn da noch I/O-Pins frei sein sollten, um die neuen Taster anzuschließen, hast du ja keine Möglichkeit die Firmware zu ändern so dass die neuen Taster auch abgefragt werden und der Stick sich bei Windows mit mehr als 8 Tasten meldet.

Stimmt genau. Hab ich beim nochmal Durchlesen gerade auch gemerkt :doh:

Du brauchst: ein Stück Abflussrohr mit 40 mm Durchmesser. Das Rohr sollte an einer Seite dicker werden, so dass es auf ein baugleiches Rohr aufgesteckt werden kann. (unter 2 Euro für 25 cm Länge) Meine Empfehlung: gleich zwei davon mitnehmen. Dann hast du genug Baumaterial, um nachher alles nochmal in Schön zu bauen, und musst beim Finden der passenden Länge nicht Angst davor haben, das Rohr zu kurz zu sägen. Eine Schlauchverlängerung für 3/4 Zoll-Schläuche von Gardena. Kostet ca. 5 Euro. Ich war zuerst im toom Baumarkt und hab die Gardena-Variante nicht gefunden oder übersehen, und deshalb das gleiche Produkt von toom (unter 2 Euro) mitgenommen. Leider passt da das Rohr nicht richtig drauf, weil die beiden Außenstücke anders geformt sind. Ein Verlängerungskabel für PS/2 Tastaturen. Damit das passt, musst du mit einer Spitzzange vorsichtig ein Plastikteil und einen Pin rausbrechen. Es sollte außerdem nicht sehr viel länger als die geplante Extension sein, sonst hast du nachher zu wenig Platz, um den Rest des Kabels im 40mm-Rohr zu verstauen. Ich hab bei meinem Kabel ein Stück rausgeschnitten und die zwei Teile wieder zusammengelötet. Ein paar kleine Schrauben mit selbstschneidendem Gewinde Die Schlauchverlängerung besteht aus einem Mittelstück und zwei Befestigungsstücken. Um das Mittelstück vorzubereiten, musst du auf einer Seite alles bis auf das eigentliche Gewinde entfernen. Das geht ganz gut mit einer Rohrzange. Die Gummidichtung hab ich aus dem Abflussrohr rausgenommen. Damit mein Befestigungsstück in das Abflussrohr passte, musste ich an der Oberseite einen Grat etwas abschleifen, danach passte das perfekt. Jetzt musst du das Befestigungsstück so in dem Abflussrohr befestigen, dass es einigermaßen gerade drinsitzt. Dazu hab ich das Ding auf das Mittelstück der Schlauchverlängerung geschraubt und dann in das Rohr gesteckt. Dadurch wird das in der passenden Position gehalten. Dann hab ich das mit sieben kleinen Schrauben (jeweils mit Vorbohren) befestigt. Die Schrauben sollten so weit oben sitzen, dass sie nachher nicht die Basis vom Stick berühren (da ist etwas Luft, da das Gewinde der Stick-Basis nicht so hoch ist wie das vom Gardena-Befestigungsstück, einfach vorher mal nachmessen). An diesem Punkt kannst du schon mal die neue Extension ausprobieren. Das Abflussrohr mit angeschraubtem Befestigungsstück kann auf die Basis geschraubt werden. Der Joystick kann auf das Mittelstück geschraubt werden und dann einfach in die andere Seite vom Abflussrohr gesteckt werden. Jetzt kannst du das Rohr schrittweise kürzer sägen und sehen, wie sich das anfühlt. Du wirst feststellen, dass die Extension nicht sehr fest auf der Basis sitzt. Das liegt daran, dass die ganze Kraft auf dem Gewinde liegt. Das Ziel ist es, dass die Kraft auf die Oberseite der Basis übertragen wird. Dazu hab ich eine Rolle Tesafilm auf halbe Breite geschnitten, auf passenden Durchmesser abgewickelt (fast leer) und in das Befestigungsstück, was auf die Stick-Basis geschraubt wird, mit rein gelegt. Wenn die passende Länge erreicht ist, kommt noch das Verlängerungskabel dazu. Ich musste von den Steckern die Isolation abschnitzen, damit die durch das Mittelstück der Schlauchverlängerung passten. Am Ende kannst du noch das Mittelstück, das am Joystick drangeschraubt ist, mit drei Schrauben an der Oberseite vom Abflussrohr befestigen, so dass es sich nicht verdreht. Disclaimer: die hier beschriebene Vorgehensweise war mein erster Versuch, sowas zu bauen. Ich hab das ganze noch nicht länger in der Praxis verwendet, weil ich jetzt auch den Rest meines Aufbaus (Abstand zu Pedalen, Sitzhöhe etc.) anpassen muss, damit ergonomisch wieder alles passt. Aber zumindest die Einkaufsliste am Anfang sollte ein guter Start sein.

For 20 km of altitude, the in-game pointer does exactly one rotation (I am assuming you are talking about cockpit argument 52 -- you didn't link your DCS-BIOS modifications so I have to guess). That means you should use a max step value of 2048, so 1 revolution in the virtual cockpit = one revolution on your stepper. You should map(newValue , 0 , 65535, 0, 2048); I don't know why the initial value you get from DCS-BIOS is 65498. That would correspond to an argument value of about 0.9994, so it's just a little to the left of the zero on the scale. It's either an internal rounding error within DCS or it may be the altimeter's way of indicating a negative altitude. While there is no terrain below sea level in DCS, if you are at 0 ft MSL you can get a negative altitude indication if the barometric pressure setting is slightly off.

We need a lot more information. What do you mean by "starting value"? What sketch and circuit? What instrument in what aircraft are we talking about? It might just be an implementation detail of that particular control. If it's L-39 related, you also need to include a link to the additions you made to DCS-BIOS so others have a chance to replicate the behavior.

Seit v0.2.8 der Arduino-Library hat die ServoOutput-Klasse auch einen Konstruktor, dem man eine beliebige Funktion zum Umrechnen von DCS-BIOS-Werten auf Servo-Mikrosekunden mitgeben kann. Das ganze ist leider noch völlig undokumentiert, weil ich noch dabei bin, den gleichen Mechanismus überall einzubauen und die Doku sowieso mal komplett zu überarbeiten. Das ganze lässt sich so benutzen: unsigned int mapServoValue(unsigned int newValue) { return map(newValue, 0, 65535, 2400, 544); } DcsBios::ServoOutput engLEngPress(0x195a, PIN, 544, 2400, mapServoValue); Wichtig ist, dass die 2400 und 544 nur in mapServoValue() vertauscht werden, die 544 und 2400, die der ServoOutput-Konstruktor übergeben bekommt werden so an die Servo-Library weitergereicht und bestimmen den Bereich, auf den die Werte beschränkt werden (d.h. selbst wenn myServoValue der Meinung wäre, da sollten 2577 Mikrosekunden rauskommen, würde das auf 2400 begrenzt). Wenn man sich für die mapServoValue()-Funktion nicht für jede ServoOuput-Instanz einen Namen ausdenken will, kann man das auch alles als lambda-Funktion schreiben (neues Feature im C++11-Standard), das sieht dann so aus: DcsBios::ServoOutput engLEngPress(0x195a, PIN, 544, 2400, [](unsigned int newValue) -> unsigned int { return map(newValue, 0, 65535, 2400, 544); });

Try a very simple sketch (e.g. the MasterCaution example) and see if it works. Yes. Sorry, I missed that post of yours because it's the last on its page, so when I got back to this thread I only saw the one after that. You are not calling Motor1.run() from loop(), so the only time the AccelStepper library ever gets the chance to move the motor for one step in any direction is when the value from DCS has just changed. DCSBIOS_DEFAULT_SERIAL mode should be avoided if possible, use IRQ_SERIAL instead. I can't tell which value you are monitoring, 0x3200 does not seem to be a valid address for any of the aircraft currently supported by DCS-BIOS. Your calculation of newValue will probably run into an integer overflow issue because the result of multiplying 65535 by 40960 is too large to fit into a 32-bit unsigned integer variable. Take a look at the Vid29Stepper class that WhoMadeWho posted (which started as an answer to this question). It is known to work, but stepper motors can be tricky. If there are any problems, you should run some tests without DCS-BIOS (e.g. modified example sketches from the AccelStepper library) to make sure there are no problems with the hardware itself (something wired incorrectly? needle too heavy for the motor? etc...). @All: if I missed anything else in the past two weeks or so, feel free to remind me via PM. I had to deal with frequent headaches for a few days after a dentist appointment, so I might have marked something as read and forgot to reply later.

Das muss zwingend ein Mega sein. Der Uno hat nur einen seriellen Port, der Bus-Master braucht aber mindestens zwei, da der ja sowohl mit dem RS-485-Bus als auch mit dem PC reden muss. Der Mega hat vier serielle Ports (UARTs), so dass der theoretisch bis zu drei RS-485-Busse ansteuern kann. Ich bin mir noch nicht sicher, dass drei in der Praxis auch in allen Situationen zuverlässig funktionieren, aber zwei gleichzeitig sollten kein Problem sein.

I don't understand what you mean. What problem are you trying to solve?

Zwei kleine Fehler sind da noch drin (ich hatte den Code nicht getestet, sondern auf Verdacht am Laptop geschrieben): zum Einen ist bei dir wohl Ziffer 1 links, Ziffer 0 rechts davon, also müssen die Positionen getauscht werden. Zum anderen meinte ich value < 10 statt value < 0. Das hier sollte funktionieren: /* set R828 Frequenz 2.MAX7219 */ void onR828ChannelChange(unsigned int newValue) { unsigned int value = newValue+1; lc.setChar(1, 1, value < 10 ? ' ' : '1', false); lc.setDigit(1, 0, value%10, false); } DcsBios::IntegerBuffer r828ChannelBuffer(0x194a, 0x003c, 2, onR828ChannelChange); Hab das wieder nicht auf Arduinos getestet, aber die Ausgabe des folgenden kleinen Testprogramms sieht vielversprechend aus: [b]$ cat test.cc[/b] #include <iostream> using namespace std; int main() { for (unsigned short value = 1; value < 11; value++) { cout << value << ":\t"; cout << (value < 10 ? ' ' : '1'); cout << ( (char)('0'+ (value%10) )); cout << endl; } cout << endl; return 0; } [b]$ g++ test.cc && ./a.out[/b] 1: 1 2: 2 3: 3 4: 4 5: 5 6: 6 7: 7 8: 8 9: 9 10: 10

Du programmierst in C++, rechne dir die Werte einfach aus: /* set R828 Frequenz 2.MAX7219 */ void onR828ChannelChange(unsigned int newValue) { unsigned int value = newValue+1; lc.setChar(1, 0, value < 0 ? ' ' : '1', false); lc.setDigit(1, 1, value%10, false); } DcsBios::IntegerBuffer r828ChannelBuffer(0x194a, 0x003c, 2, onR828ChannelChange); Die erste Stelle ist '1' bei Kanal 10 und sonst ein Leerzeichen, die zweite Stelle ist der Rest, der bei Division durch 10 übrig bleibt.

Have you tried simply setting the timeout to zero? And how are you noticing a hang of a tenth of a millisecond anyway? I can't tell why that doesn't work without looking at your complete script, but you should be aware that coroutines have nothing to do with multithreading. At any given time, at most one coroutine is executing.

Seit DCS-BIOS 0.5.0 sollten die auch als Switch2Pos funktionieren. Warum das in der Control Reference nicht drinsteht, muss ich mir nochmal ansehen, wenn ich wieder an meinem Desktop-Computer sitze. Versuch mal folgendes: DcsBios::Switch2Pos saspYawSasL("SASP_YAW_SAS_L", PIN); Das besondere an diesen Schaltern ist, dass die magnetisch in Position gehalten werden, d.h. der Bordcomputer kann die bei Bedarf wieder abschalten. In der A-10C gibt es sowas beim SAS-Panel, beim EAC Ein/Aus-Schalter, dem Anti-Skid-Switch und dem Schalter für die Anticollision Lights. @Oldcooltronix: Wenn du die Control Reference auf "Advanced" schaltest, dann sollten da auch Teile der Frequenzselektoren als Strings auftauchen.

This post includes detailed information about what is disabled by each of the three export server settings. The only reason I see for disabling ownship export ("Disable Player's Export" option) is on servers that turn off showing your own position on the F10 map. Even then, I'd argue that turning it off disables too much other functionality to be worth the gain. As long as the F10 map allows you to see your own position, the only cheats I can come up with that turning off ownship export would prevent would be adding some basic instruments to aircraft that don't have them (radar altimeter, a decent ADI and ILS in a P-51, anyone?), keeping exported instruments functional when your virtual cockpit has an instrument failure, and establishing a side channel to your teammates (i.e. several players using the same cheat program) to display a map that shows you and your squadmates' position. Disclaimer: I am not very familiar with PvP, if I am missing something here I'd welcome any corrections and clarifications.

@Marcin_B: While looking at the code again I noticed that your problem is not caused by what I thought it was. The behavior I described can only happen in RS-485 mode, because the transmit code in IRQ_SERIAL mode is still blocking. I recreated your setup as close as I could (same sketch, went back to Arduino library v0.2.3, had to use a Nano instead of an Uno) and it worked for me. Does the same potentiometer connected to the same pin (A2) work if you only define a single pot in the sketch like this? #define DCSBIOS_IRQ_SERIAL #include <DcsBios.h> DcsBios::Potentiometer cmscRwrVol("CMSC_RWR_VOL", A2); //example 2 void setup() { DcsBios::setup(); } void loop() { DcsBios::loop(); } You could also try the AnalogInOutSerial example that comes with the Arduino IDE (File -> Examples -> Analog) for a test that works independently of DCS-BIOS. I suspect that your physical connections may be at fault here. Sticking solid core wire into a female header (which is designed for square pins) as shown on your photo does not make a reliable contact. Try soldering those wires to square pin headers or use jumper wires (with square pins) and a solderless breadboard (those spring contacts make a good connection to almost anything). You could also try using a different analog pin.

There are two bugs here. One is in DCS-BIOS: the first potentiometer will always get the chance to fill the transmit buffer first, and because there isn't any rate limiting or hysteresis in the DcsBios::Potentiometer class yet, it will always queue up a message to send. The second potentiometer will never get to send a message, because the TX buffer is already full when it is polled. The second bug is in my brain, because I was aware of that problem, devised a solution which would make sure that every defined input would get a chance to transmit, and was convinced I had already implemented that. Turns out I haven't. I'll grab a few pots and get to work. Expect a new release of the Arduino library within the next day or two.

...which pin? A potentiometer requires an analog pin. Assuming the cause is not a bug in DCS-BIOS, there is only one answer I can give to a problem description that only consists of "It doesn't work!": "Yes, it does!" Like the problem description, that answer is short, correct, and lacks useful information. Of course, bugs in DCS-BIOS do happen (and have happened in the past); either because I missed something during development or because an update to DCS included a change that broke something (I think that only happened once, the Export.lua API is pretty stable). But even if it is a bug in DCS-BIOS, I have to reproduce it on my machine, and most bugs only happen under specific circumstances (those that happen all the time are likely to be caught during initial development), so I need to match your setup as close as possible. Include your complete sketch and a schematic of your circuit. You also need to describe what happens. "It does not work" only tells me that something that you expect to happen did not happen. I need to know what you did (including your code and schematic), what you expected to happen (though this is often obvious from the context of the question, or from a sentence like "I turned the physical potentiometer but the knob in the virtual cockpit did not turn"), and what happened instead! Did the socat script connect or was there an error message? Do any other inputs or outputs that are connected to the same Arduino board work (assuming there are any)? Every detail can be important. In general, more information is better, but any first post should include the sketch and a description of the circuit.

Das ist Absicht. Wenn physikalischer Schalter und Simulation nicht im gleichen Zustand sind, hast du zwei Möglichkeiten: (1) passe die Simulation an den Schalter an oder (2) passe den Schalter an die Simulation an. (1) hat den Vorteil, dass du als Mensch nichts tun musst. Allerdings würde es in der von dir beschriebenen Situation erstmal ungefragt den Bordcomputer ausschalten und könnte je nach dem, um welchen Schalter es sich genau handelt, dazu führen, dass z.B. das Navigationssystem das Alignment verliert. Deshalb habe ich bei DCS-BIOS auf (2) gesetzt, so dass niemals ein Schalter in der Simulation ohne menschliches Zutun bewegt wird. Im Prinzip könnte man den Arduino so programmieren, dass er den Zustand des Schalters in der Simulation überwacht und bei Bedarf angleicht, das würde aber etwas sinnlos Ressourcen fressen. Da die Anfrage nach diesem Feature mehrmals kam, habe ich vor, in DCS-BIOS 2.0 im Protokoll ein "gratuitous"-Flag vorzusehen, das anzeigt, dass ein Befehl nicht durch das physikalische Umschalten eines Schalters ausgelöst wurde. Befehle mit diesem Flag würden dann standardmäßig ignoriert, und man könnte das in der Software auf dem PC für jeden Schalter einzeln einstellen. Dann fehlt noch ein Event-Mechanismus, der bei einem Flugzeugwechsel die Hardware dazu auffordert, doch mal den kompletten Zustand zu schicken (normalerweise melden sich die Arduinos nur, wenn sich was geändert hat). Sieht so aus. Soweit ich weiß gibt es auch im virtuellen Cockpit keine Funktion, um den Schalter zu bedienen. Du könntest natürlich den Arduino so programmieren, dass das physikalische Poti nicht zwischen 0% und 100% sondern z.B. zwischen 10% und 100% regelt und der Regler im virtuellen Cockpit erst bei Abschalten des Schalters auf 0% gedreht wird.

Du musst an den Stellen, wo die Kommentare stehen, auch noch den richtigen Code einfügen... Ich hab leider nicht die Zeit, das alles selber aufzubauen und zu testen, zumal ich mich dann auch erstmal wieder in die Bedienung eines Ka-50 einarbeiten müsste. Für jeden Wert, der nicht richtig angezeigt wird, musst du folgendes tun: herausfinden, wie du den (ohne DCS-BIOS) auf dem Display anzeigst herausfinden, welcher Wert aus DCS-BIOS rausfällt, wenn das angezeigt wird ( ) ein zusätzliches if-statement einfügen, um den Fall zu behandeln Das ist der Teil von DCS-BIOS, bei dem du selbst programmieren musst. Es gibt zu viele mögliche Displaytypen, so dass ich die nicht alle selbst implementieren und testen kann. Bau mal folgendes in einen Test-Sketch ein: lc.setRow(0, 0, B01111110); Das müsste ein 'A' ausgeben. Jede 1 oder 0 kontrolliert dabei ein Segment. Damit kannst du beliebige Kombinationen von Segmenten setzen. Es ist nicht schwierig, du musst nur verstehen, wie die Hardware, die du benutzt, funktioniert. Ressourcen dazu gibt es eine Menge -- das Datasheet des MAX7219, Wikipedia, den Quellcode der LedControl-Library...

Joystick Controller wie Leo Bodnar, GP-Wiz 40 sind ein anderer Ansatz. Die stellen ein paar digitale Eingänge für Schalter und Taster bereit sowie ein paar analoge Eingänge für Achsen und melden sich dann am Computer als ganz normaler USB-Joystick, so dass du angeschlossene Knöpfe ganz normal in den DCS-Optionen den Funktionen im virtuellen Cockpit zuweisen kannst. An manche dieser Boards kannst du auch Rotary Encoder (Inkrementaldrehgeber) anschließen, die lösen dann einen Button aus, wenn sie nach links gedreht werden und einen anderen, wenn sie nach rechts gedreht werden. Vorteil: funktioniert mit jedem Spiel und mit jedem Modul in DCS. Nachteil: keine Ausgabe (LEDs, Servos, Schrittmotoren, Displays), Der andere Ansatz ist, eine eigene Software zu schreiben, die vollen Zugriff auf das virtuelle Cockpit hat und irgendwie mit der selbstgebauten oder gekauften Hardware redet. DCS: World stellt dafür eine Schnittstelle bereit (Stichwort Export.lua). Dieser Ansatz hat den Vorteil, dass man auch Daten vom PC zur eigenen Hardware senden kann. Der Nachteil ist im Allgemeinen, dass dieser Ansatz nur mit DCS: World funktioniert und die Software für jedes neue Flugzeugmodul angepasst werden muss. Mir sind vier Projekte bekannt, die den Export.lua-Ansatz mit dem Ziel verfolgen, eigene Hardware anzusteuern: Helios kann nicht nur virtuelle Touchscreen-Panels anzeigen, sondern auch über sein EOS-Protokoll mit eigener Hardware reden. Es unterstützt wohl auch Phidgets USB Interfaces. PSCockpits kann wohl auch DCS: World Die Simpit-Software von SDA kann mit dem Arcaze USB Interface reden, welches für Leute designt wurden, die Arcade-Maschinen emulieren wollen. Soweit ich weiß, unterstützt die Software sehr viele Flugzeugmodule in DCS: World und das Arcaze-Interface kann Schalter, Taster, Rotary Encoder, LEDs und 7-Segment-Anzeigen ansteuern. DCS-BIOS redet über ein eigenes Protokoll mit Hardware, die an einem (über USB emulierten) seriellen Port hängt. Die DCS-BIOS Arduino Library macht es relativ einfach, solche Hardware auf Basis der Arduino-Mikrocontrollerboards selbst zu bauen. Ich weiß jetzt über die anderen Systeme nicht genug, um da einen fairen Vergleich zu machen. Der größte Nachteil an DCS-BIOS ist, dass es im Moment nur vier Flugzeugmodule (A-10C, Ka-50, UH-1H und Mig-21) unterstützt. Das soll sich in Zukunft ändern, kann aber noch viele Monate dauern, weil ich schwer vorhersagen kann, wieviel Zeit ich in das Projekt stecken kann. Bei DCS-BIOS musst du die Software für das Arduino-Board selber schreiben. Für Taster, Kippschalter, Rotary Encoder und LEDs geht das einfach per Copy&Paste ohne Programmiererfahrung. Für Displays, Servos und Schrittmotoren muss man schon ein bisschen Programmieren lernen. Das ist aufwändiger als bei manch anderem System, macht einen aber auch unabhängig von irgendeinem bestimmten System. Wenn du z.B. in deinem CMSP Displays verbauen willst, die genau so wie das Original aussehen, dann kannst du das mit genug Programmierkenntnissen, DCS-BIOS und einem Arduino-Board machen. (Ähnliches gilt für Helios und EOS.) Die Idee ist, dass man nur einen (oder ggf. zwei bis drei) Arduinos an den PC anschließt und der Rest der Boards über einen RS-485-Bus untereinander kommuniziert. Damit braucht man für ein komplettes Cockpit keine 20 bis 40 USB-Anschlüsse. Die RS-485-Unterstützung ist zwar schon in DCS-BIOS drin, aber noch nicht dokumentiert, weil wir da noch ein paar Sachen testen müssen. Solange du aber einen I/O-Pin pro Arduino frei lässt, um später das TX_ENABLE-Signal zu steuern, ist es relativ unkompliziert, ein Board von USB auf RS-485-Bus umzustellen. DCS-BIOS sollte mit jedem erhältlichen Typ von Taster oder Kippschalter funktionieren, ein einfacher EIN-AUS-Schalter (SPST) tut es also auch. Wenn du noch Fragen hast, beantworte ich die gerne so gut ich kann. Es wäre hilfreich, wenn du mal kurz beschreibst, welches Vorwissen in Programmierung und Elektronik ggf. schon vorhanden ist. Wenn du DCS-BIOS einfach mal ausprobieren willst, würde ich dir den Arduino Nano (klein und günstig, du solltest aber schon einen Lötkolben besitzen um die Pin-Header dranzulöten) oder einen Arduino Mega 2560 (mehr I/O-Pins, du kannst auch mit Arduino Shields rumspielen) empfehlen. Den Uno kannst du auch verwenden, aber der Nano bietet genau das gleiche (außer dass du keine Shields draufstecken kannst) bei deutlich geringerem Preis ud kleinerem Formfaktor (leichter hinter dem Panel zu verstecken). Außerdem lässt sich der Nano einfach auf ein Steckbrett stecken, wie z.B. in diesem Bild. Den Mega bekommst du für ca. 12 Euro ($6.00 aus China ohne USB-Kabel), der Nano kostet ca. 4,40 bei eBay (Artikelstandort: Deutschland) oder $2.15 aus China bei AliExpress.

Ich hab mir das mal mit der interaktiven control reference angesehen. Die Werte, die da aus DCS-BIOS herausfallen, sind entweder " " (zwei Leerzeichen, bei leerem Display), "AT" wenn das Display "NC" anzeigt oder "RT" wenn das Display "HP" anzeigt. Warum, das weiß nur ED. Hat vielleicht was damit zu tun, dass das eigentlich kyrillische Zeichen sein sollen. Die LedControl-Library kann mit 'R' oder 'T' nichts anfangen. Du musst die beiden Fälle also extra abfragen: void onWeaponsDisplayStoreTypeChange(char* newValue) { if (!strcmp(newValue, "AT")) { // zeige "NC" an } else if (!strcmp(newValue, "RT")) { // zeige "HP" an } else { /* set digit 4 to first character (newValue[0]) */ lc.setChar(0, 7, newValue[0], false); /* set digit 3 to second character */ lc.setChar(0, 6, newValue[1], false); } } DcsBios::StringBuffer<2> weaponsDisplayStoreTypeBuffer(0x1888, onWeaponsDisplayStoreTypeChange); "HP" sollte mit setChar() darstellbar sein, das C auch. Mit "N" kann die LedControl-Library nichts anfangen, da musst du wahrscheinlich setRow() aufrufen und eine Zahl übergeben, die geau die richtigen Segmente anschaltet, damit sich das N ergibt.

Passiert immer das gleiche oder ist das Verhalten jedesmal anders? Treten die Fehler bei jeder einzelnen Änderung auf oder nur machmal? Das Ganze klingt erstmal nach einem Problem mit der Verkabelung (dann sollte es aber auch am Anfang auftreten, wenn man den Arduino nur oft genug neu startet). Was für Kabel benutzt du, um deinen Arduino Mega mit den MAX7219-Chips zu verbinden? Hast du an den MAX7219 auch den 100 nf-Kondensator zwischen VCC und GND eingebaut? Steckbrett oder Platine?