FSFIan

Welchen denn? Ohne Problembeschreibung (Was hast du gemacht? also Code und Schaltung; Was ist passiert?; Was hast du stattdessen erwartet?) kann ich nicht einmal raten, wo das Problem liegt.

Der erste Parameter von setDigit bzw. setChar gibt an, welchen MAX7219 du ansprechen willst. 0 ist der erste, 1 der zweite usw. lc.setDigit(0, 7, 9, false); // Ziffer 7 auf dem ersten MAX7219 auf '9' setzen lc.setChar(1, 4, '3', false); // Ziffer 4 auf dem zweiten MAX7219 auf '3' setzen

Richtig kann's schonmal nicht sein, weil es nicht kompiliert :P Das hier sollte funktionieren: #include <Servo.h> #define DCSBIOS_IRQ_SERIAL #include "DcsBios.h" DcsBios::Switch2Pos r800EmerRcvr("R800_EMER_RCVR", 5); DcsBios::Switch2Pos r800Adf("R800_ADF", 4); DcsBios::Switch2Pos abrisPower("ABRIS_POWER", 11); DcsBios::Switch2Pos hsiDhDtaManualAuto("HSI_DH_DTA_MANUAL_AUTO", 9); DcsBios::Switch2Pos laserMode("LASER_MODE", 8); DcsBios::Switch2Pos opPitotPortHeat("OP_PITOT_PORT_HEAT", 7); DcsBios::Switch2Pos opPitotRamHeat("OP_PITOT_RAM_HEAT", 6); DcsBios::Switch2Pos scRotorRpmBtn("SC_ROTOR_RPM_BTN", 3); DcsBios::ServoOutput apuTemp(0x191c, 2, 540, 2550); DcsBios::LED raltSafeAltLamp(0x184c, 0x1000, 12); const byte engSelectorPins[4] = {53, 51, 49, 47}; DcsBios::SwitchMultiPos engSelector("ENG_SELECTOR", engSelectorPins, 4); const byte opNavLightsPins[5] = {45, 43, 41, 39}; DcsBios::SwitchMultiPos opNavLights("OP_NAV_LIGHTS", opNavLightsPins, 4); DcsBios::Switch3Pos engStartupMode("ENG_STARTUP_MODE", 50, 52); DcsBios::Switch2Pos r800AmFm("R800_AM_RM", 4, 8); #include "LedControl.h" LedControl lc=LedControl(2,3,4,1); void onUv26DisplayChange(char* newValue) { /* set digit 4 to first character (newValue[0]) */ lc.setChar(0, 4, newValue[0], false); /* set digit 3 to second character */ lc.setChar(0, 3, newValue[1], false); /* set digit 2 to third character */ lc.setChar(0, 2, newValue[2], false); } DcsBios::StringBuffer<3> uv26DisplayBuffer(0x1812, onUv26DisplayChange); void setup() { lc.shutdown(0,false); /* Set the brightness to a medium values */ lc.setIntensity(0,8); /* and clear the display */ lc.clearDisplay(0); DcsBios::setup(); } void loop() { DcsBios::loop(); } Copy&Paste funktioniert gut für die einfachen Sachen, aber sobald es um etwas komplexere Dinge geht (wie z.B. Displays), wo man auch in setup() passenden Initialisierungscode braucht, sollte man schon ein paar Grundkenntnisse in C++ mitbringen (was sind Funktionen, Klassen, Variablen, globale vs. lokale Variablen). Leider kann ich dir keine deutschen Tutorials empfehlen, weil ich mich da überhaupt nicht auskenne. Wenn Englisch kein Problem ist, gibt es auf arduino.cc ein paar Einführungen in C++ (die reden von der "Arduino Language" und meinen damit die Untermenge von C++, die auf Mikrocontrollern sinnvoll ist, zusammen mit der Wiring-Library (digitalWrite() und co.) und der Arduino-IDE). Ich kann auch schlecht sagen, was der einfachste oder schnellste Weg ist, sich solche Kenntnisse von Grund auf anzueignen. Ich selbst hab das Programmieren über mehrere Jahre und Programmiersprachen hinweg durch viel Herumspielen und Trial & Error gelernt (in der Grundschule hatte ich viel Zeit und keinen Internetanschluss), bin also ganz klein angefangen (Batch-Dateien unter DOS) und hab mich langsam zu komplexeren Sachen vorgearbeitet, wobei ich immer einen Teil der Konzepte der neuen Sprache bereits kannte. Vielleicht gibt es hier ja jemanden, der selbst in letzter Zeit mit dem Thema neu angefangen hat und ein gutes Buch und/oder Online-Ressourcen auf Deutsch empfehlen kann. Egal welche Informationsquelle man benutzt, selber Fehler machen, suchen und beheben gehört auf jeden Fall dazu. Irgendwann lernt man dann automatisch, die manchmal kryptischen Fehlermeldungen des Compilers zu lesen, den Fehler auch in der Zeile davor zu suchen, und viele Fehler innerhalb von Sekunden zu beheben, weil man sie schon dreimal selber gemacht hat. Meiner Erfahrung nach braucht man auch ein konkretes Projekt, das man in der jeweiligen Sprache umsetzen will, aber das ist bei Dir ja vorhanden. Ich hab noch keine Programmiersprache gelernt, ohne dass ich gerade ein Projekt hatte, was in dieser Programmiersprache einfacher umzusetzen war, als in denen, die ich vorher schon kannte. PS: Codebeispiele sollten in -Tags gesetzt werden, das macht es lesbarer und schaltet die Smileys aus. Es hilft außerdem für die Lesbarkeit von Code enorm, wenn der eingerückt ist (entweder gleich selbst einrücken, was man sich sowieso angewöhnen sollte, oder in der Arduino-IDE: Tools -> Auto Format bzw. Ctrl+T).

Die Reihenfolge ist ziemlich egal, weil die meisten Elemente sich nicht gegenseitig referenzieren. In C++-Code müsste normalerweise die Definition der Callback-Funktionen (z.B. "void onUv26DisplayChange(..){...}") vor der Instanziierung des Stringbuffers kommen, der sie verwendet ("DcsBios::StringBuffer<3> uv26DisplayBuffer..."), aber die Arduino-IDE fügt hinter den Kulissen automatisch forward declarations ein, bevor der Code compiliert wird, so dass selbst das egal ist. Wenn du die folgenden Randbedingungen beachtest, müsste alles klappen: Alle #include-Zeilen müssen noch vor der ersten Zeile auftauchen, die etwas daraus verwendet (also z.B. "#include <LedControl.h>" vor "LedControl lc=..."). Deshalb schreibt man die normalerweise alle an den Anfang der Datei. Die Zeilen "#include <Servo.h>" und "#define DCSBIOS_IRQ_SERIAL" müssen vor dem "#include <DcsBios.h>" stehen, weil DCS-BIOS davon sonst nichts mitbekommt. Natürlich kannst du die setup()- und die loop()-Funktion nicht zweimal definieren, also einfach beide zusammenfügen (und nur einen Aufruf von DcsBios::setup() bzw. DcsBios::loop() behalten :) )

I also buy from China. I had no problems with bad chips, but I only bought two lots, so my sample size is pretty small. That said, buying from a big distributor is about ten times as expensive, so it's still cheaper to buy from China until you get working chips. The test sketch was written while on Skype with Warhog. My theories were getting increasingly paranoid because we both had the same circuit and code, which worked for me, but didn't behave for him. Could there be some stupid bug in the code that depended on the exact timing the USB driver used to send the data? After at least an hour or so of Warhog swapping out every single component (different MAX487 chips, different Arduino Mega, different Arduino Pro Mini, ...) I wrote the sketch to verify basic functionality in a context that did not involve DCS-BIOS code at all. I recommend the MAX487 for use with DCS-BIOS. Page 15 in the datasheet lists the differences between the CSA, ESA, etc. variants. The first letter is either 'C' or 'E' and specifies the temperature range that the device is guaranteed to work in (consumer = +0 to +70 C, extended = -40 to +85 C, military = -55 to +125 C). The last two letters specify the package, You probably want 'PA' for the through-hole DIP-8 package. If you make your own circuit boards, you may also be interested in the 'SA' variant for the SO-8 surface mount package. The other packages (except 'JA', which is the ceramic DIP-8 package designed to handle the military temperature range) are inconvenient (uMax) to impossible (bare die) to solder by hand. To make a long story short, all you care about is that the last two letters are 'PA' if you want the DIP-8 package to use with a breadboard or prototype board, and 'SA' if you make a custom circuit board and want the advantages of the surface mount package (uses less space, no need to drill holes).

Found it. As mentioned in the comments at the top, the sketch is meant to be connected to two MAX487 chips and will put them through a basic test cycle (i.e. send a logic 0 and a logic 1 in both directions). It won't catch all errors and it will transmit data slower than the 250000 bps that is used by DCS-BIOS, so passing the test does not mean everything is perfect, but failing the test is a pretty clear indication of a broken and/or fake chip. The pin numbers are laid out in such a way that the sketch is convenient to build on a breadboard (assuming you are using an Arduino Nano) as shown in the image below. Instead of jumper wires, I used resistors (anything between 150 ohm and 10k should work) to limit the possible current with the intent of protecting the Arduino board in the event that a broken chip tries to apply a voltage to one of the Arduino's outputs. To be fair, when ordering them from China for $1.50 per lot of 10, there is a chance of getting fake chips, chips from a production run that failed internal quality control, or old chips that were (improperly) stored for a while. // Basic test sketch for MAX487 transceiver chips // Connect to two MAX487 chips. // If the test fails, the LED will start to do a double flash // once a second. // As long as the test runs correctly, the LED will be on // and turn off briefly every 200 completed test cycles, // causing the LED to flicker. // pin numbers of first MAX487: #define RO1 12 #define RE1 11 #define DE1 10 #define DI1 9 // pin numbers of second MAX487: #define RO2 5 #define RE2 4 #define DE2 3 #define DI2 2 void setup() { pinMode(RO1, INPUT_PULLUP); pinMode(RE1, OUTPUT); pinMode(DE1, OUTPUT); pinMode(DI1, OUTPUT); pinMode(RO2, INPUT_PULLUP); pinMode(RE2, OUTPUT); pinMode(DE2, OUTPUT); pinMode(DI2, OUTPUT); pinMode(13, OUTPUT); digitalWrite(13, 1); } void fail() { while(1) { digitalWrite(13, 1); delay(50); digitalWrite(13, 0); delay(100); digitalWrite(13, 1); delay(50); digitalWrite(13, 0); delay(800); } } void check_pin(unsigned char pin, unsigned char state) { if (digitalRead(pin) != state) fail(); } void loop() { unsigned int test_cycles = 200; while (test_cycles > 0) { test_cycles--; // turn off all outputs digitalWrite(RE1, 1); digitalWrite(DE1, 0); digitalWrite(RE2, 1); digitalWrite(DE2, 0); digitalWrite(DI1, 0); digitalWrite(DI2, 0); // send from 1 to 2 digitalWrite(RE2, 0); check_pin(RO2, 1); // test internal bias resistor digitalWrite(DE1, 1); digitalWrite(DI1, 0); check_pin(RO2, 0); digitalWrite(DI1, 1); check_pin(RO2, 1); digitalWrite(DI1, 0); digitalWrite(RE2, 1); digitalWrite(DE1, 0); // send from 2 to 1 digitalWrite(RE1, 0); check_pin(RO1, 1); // test internal bias resistor digitalWrite(DE2, 1); digitalWrite(DI2, 0); check_pin(RO1, 0); digitalWrite(DI2, 1); check_pin(RO1, 1); digitalWrite(DI2, 0); digitalWrite(RE1, 1); digitalWrite(DE2, 0); } // toggle LED digitalWrite(13, 0); delay(20); digitalWrite(13, 1); }

As far as I can tell, your circuit is correct. You can try to add 100 nf capacitors between GND and VCC next to each MAX487 chip for good measure. If you are starting the connect-serial-port.cmd script after DCS is already running, try the workaround in this post (start script, pause DCS, press reset button on Arduino Mega, wait two seconds, unpause DCS). Otherwise, it could be a bad connection somewhere or a batch of broken MAX487 chips. I'll see if I can dig up the test sketch we used to identify Warhog's batch of bad transceivers. Unfortunately, right now there is not much you can do to debug RS-485 problems without a logic analyzer and an understanding of the protocol. That is also the reason that the RS-485 support is not officially documented yet -- I want to add some diagnostics first (such as attaching an LCD to the Mega and have it print some statistics).

Should be fixed now in v0.2.7 of the Arduino Library. The issue has always been there, but I think that only version 1.6.13 or higher of the Arduino IDE actually issues a warning for it (it compiles with 1.6.12 on my machine). Anyways, specifying the always_inline attribute without also making the function inline doesn't make sense, so I corrected the code.

Released v0.2.7 of the Arduino Library. fix compiler warning when compiling the RS-485 master sketch Please post comments in the DCS-BIOS Discussion Thread.

The FAST_CWD_POINTER warning is normal under Windows 10, but it doesn't break anything. Did you give up after seeing that message or did you actually run DCS, enter a mission and unpause it? I don't see any problems with your Export.lua, but to make sure the problem is not caused by any interaction with TacView, SimpleRadio, etc., try with just the Export.lua that comes with DCS-BIOS. If these steps do not solve the problem, post your dcs.log.

See that bold line? It is set up for a stepper driver board connected to pins 11 and 10. Just replace it with one that works for your stepper motor. The AccelStepper documentation (and the code you used previously) should tell you the parameters to pass to the AccelStepper constructor. Afterwards, make sure that you adjust the maxSteps value in the StepperConfig struct accordingly (IIRC the original sketch was set up for a driver board that was configured for 2x microstepping). PS: Even when the code is included, an error description of "It does not work now" is not very helpful. I need to know what changes you made, what you expected to happen, and what happened instead. And unless the code does not even compile, I also need a description of how everything is wired up. In your second post, I learned that your stepper motor is directly connected to the Arduino, so I could answer your question, but your first post did not have enough details. Your problem is not caused by incorrect code, it is caused by correct code that does not match the hardware it is deployed to.

Performance wise I see no reason why this shouldn't work. However, you will likely run into some limitations with that many USB devices. bnepethomas has mentioned before that he ran into problems with 'only' 20 devices and had to install another USB controller card. Handling 40 concurrent instances of socat is also very, very annoying. This will eventually get less annoying when I get around to write DCS-BIOS 2.0, but you will still have to configure a list of 40 COM ports to use. Which might change from time to time just because Windows feels like it (i.e. it thinks the USB-to-serial converter is plugged in somewhere else, doesn't recognize it because it does not have a unique serial number, and then assigns it a new COM port number). Before I switched to Windows 10, the COM port numbers that my Windows 7 install assigned to the three Arduino boards I used for testing had gotten up to COM 46... The official solution to that is to use an RS-485 bus. That way, you will only need one or two COM ports to talk to the RS-485 bus masters and maybe a few more if you have panels that cannot use the RS-485 bus for some reason (for example because you used a Arduino-compatible board with a fast ARM CPU, where IRQ_SERIAL mode is not supported, to drive a graphic display for the CDU). The RS-485 code is in DCS-BIOS, although there is no official documentation yet. Several people have gotten it to work, but the whole thing is still in beta status and we don't have a good set of troubleshooting steps yet. Switching a sketch from IRQ_SERIAL mode to RS-485 is easy, as long as you have one free digital I/O pin to use for the TX_ENABLE signal.

RS-485 will be slower than a direct USB connection, but not by a significant amount. The Arduino cannot send a message to the PC whenever it wants to -- it has to wait until the RS-485 bus master polls the bus for it ("device 42, do you have anything to say?"). As long as no other device is "hogging" the bus all the time, the difference is probably less than 5 ms. Here's what happens when you push the physical SIGNAL LAMP TEST button: The Arduino pin goes from HIGH to LOW On its next loop(), the Arduino sketch detects the change and sends a 16-byte message ("LAMP_TEST_BUTTON 1\n") to the PC. At 250000 bps, that takes 0.64 ms to transmit. On a RS-485 bus, add a typical wait time of about 2 ms. As soon as DCS starts to render the next frame. the Export.lua part of DCS-BIOS will receive the message and tell DCS to push that button DCS will take some time to simulate that button being pushed and to turn on the indicator light. I haven't looked into how long this step takes in the best case (might happen immediately for all I know), but for some controls it can take a long time (my first latency test was to measure the time from pushing the MASTER CAUTION RESET button until DCS-BIOS was reporting that the button was in the "down" position. I measured very long delays and was about to tear my hair out until I noticed that the same delay happened between clicking the button in the virtual cockpit and seeing the button animation.) Now we wait until DCS-BIOS decides to send a new update. This happens 30 times per second, so this step can take between 0 and 33 ms. In practice, the "worst case" time will be more than 30 ms, because if DCS-BIOS decides not to send an update because it has only been 32.9 ms since the last one, the next update will be delayed by the time it takes to render the next frame (which is 16 ms even at a great framerate of 60 fps). DCS-BIOS will send the update to your Arduino board, which will act upon it. A typical 120-byte update takes 5 ms to transmit. In practice, the latency you observe will probably be dominated by steps 4 and 5. The list does not account for any delays due to buffering in the network stack, socat, USB drivers, or your USB-to-serial chip, but I doubt those are large enough to measure in a meaningful way anyway. It also assumes that the loop() in your Arduino sketch executes reasonably fast. This is always the case unless some output takes a significant time to update (a few character LCDs are fine, a 320x240 graphic display is probably noticeable).

It should work in DCSBIOS_DEFAULT_SERIAL mode (make sure to use v0.2.6 or later of the Arduino library, earlier versions had a nasty bug that affected DEFAULT_SERIAL mode). I don't think I have properly explained the trade-offs of DEFAULT_SERIAL vs. IRQ_SERIAL anywhere, so I'll do it here by explaining the reason IRQ_SERIAL was introduced. In the beginning, there was only DEFAULT_SERIAL mode. In that mode, all communication is done using Serial.read() and Serial.write(). The control flow inside loop() looked like the following pseudocode: (1) while(Serial.available()) { process(Serial.read() } (2) for each input: if it has changed, use Serial.write() to send a command to the PC Outputs would be updated inside that process() call as soon as new information for them had been received. To understand the problems with this approach, it is important to understand what happens when a new byte of data comes in from the PC. Incoming data is put into a receive buffer. In step (1), the data in that buffer is processed until the buffer is empty. By default, that buffer is only 64 bytes long on devices with 2K RAM. Which means that if more than 64 bytes arrive during step (2) or while outputs are updated during step (1), all hell breaks loose because incoming data is being dropped on the floor. DCS-BIOS will try to send 30 updates per second, sending every piece of information that has changed since the last update. For the A-10C, each update will result in a data burst of about 120 bytes in length; the very first data burst is about 700 bytes long. Step (2) usually executes very fast, as it only involves a few digitalRead() calls. Sometimes a short message has to be sent to the PC, but that's fine as well -- in the time it takes to send, say, 20 bytes to the PC, a maximum of 20 bytes can be received, and they fit in the receive buffer. So unless there are lots of inputs that need to be checked or there is a high likelyhood that two or three inputs have changed at the same time (*cough* jittery potentiometers *cough*), even a 64-byte buffer is enough to handle step (2). For most people, the problems started when they had outputs that took a long time to update because their drivers deliberately included calls to delayMicroseconds() to wait for the hardware to catch up. The usual culprit were (multiple) displays using the LiquidCrystal library. So how can we fix that problem? One solution would be a receive buffer that is large enough to hold the largest expected update. But a 700-byte receive buffer is not a good idea on a device with only 2048 bytes of RAM total. Another solution (the one implemented in IRQ_SERIAL mode) is to implement the serial communication ourselves. When the program is interrupted because a new byte of data has arrived, that byte is not only put into a receive buffer, but everything in that buffer is processed before control is handed back to the main program. Also, "processing" no longer means "write the data to a display"; instead, it only means "ignore all data that no output is interested in; store every interesting peace of info and update any connected LEDs, displays, etc. later". Also, IRQ_SERIAL mode can send and receive data at the same time. On the Teensy 3.1, you have 64K of RAM, so if you can figure out how to increase the size of the receive buffer of the standard Serial library to, say, 1024 bytes, you should be fine. Or you could implement IRQ_SERIAL mode for the Teensy's ARM processor (instantiate a ProtocolParser, set up the UART; when a byte is received, pass it to parser.processCharISR() from your interrupt service routine; implement DcsBios::sendDcsBiosMessage() to send data to the PC). Increasing the RX buffer size should be easy enough (maybe the Teensy even uses a larger one by default?). Implementing IRQ_SERIAL would involve delving into the datasheet of whatever ARM CPU the Teensy uses (but you could look at the code of the HardwareSerial implementation on the Teensy to get an idea of how to do it).

Tekkx: If I understand you correctly, you want to override the state of an indicator light in the virtual cockpit. That is not possible with DCS-BIOS. You might be able to do something like this from a custom Export.lua script with set_argument_value(), but you'd have to do it every single frame to avoid your change being overwritten by DCS. I am pretty sure there is no way to change any text on the CDU or HUD (there might be a tiny chance to do this by modifying the A-10C's Lua files, but most of the logic is implemented in the DLL's and not in Lua). You could press the SIGNAL LAMP TEST button to make the whole cockpit light up like a Christmas tree and have the master caution alarm sound at the same time... If you need to display a message, I think there was a way to do that from Export.lua, but it's probably out of the scope for DCS-BIOS. And you could probably figure out some way to play a sound from Export.lua (if there isn't some way to doit through the API, you could always resort to run an external program).

The front pin header has RX and TX, but you still need a TX_ENABLE pin (unless your panel has no inputs at all and does not have to send data to the PC).

Some of the parts on the market are probably components that are obsolete or known to be defective, so there is no point in keeping them around so they are sold off. I once bought a lab power supply that used to belong to the German army. At the time, there were lots of those on ebay.de for around 100 EUR, but there was one for 50 EUR from a seller who offered local pick-up only. The pick-up location was still within the coverage area of my student train ticket, so I grabbed a podcast to listen to and took a free two-hour train ride to Düsseldorf. I arrived at a small two-storey warehouse that was crammed to the brim with old electronics equipment. Entire shelves of power supplies, cathode ray oscilloscopes, frequency analysers, frequency counters, signal generators, you name it. The shop was run by an older man and his apprentice. Since I had seen an A-10C oxygen regulator panel in their eBay shop, I asked them about it. They said that they got a lot of their inventory from the German and US military. "See that large console on the back shelf there? That was once mounted in an AWACS. Had lots of nice switches we could re-sell." One of them wondered about what kind of people would buy things like that oxygen regulator panel, at which point I showed them some build threads on the ED boards and explained the concept of a simpit to them. While looking through those posts, the apprentice seemed to recognize some of the panels. "Hey boss, this looks a lot like all those aluminum faceplates we sold to the scrap dealer by the kilogram!" MFW: :cry: I told them that if they ever get their hands on something similar to check the DCS: World manuals first and put anything they recognize up on eBay.

Just get the DIP-8 version and mount it on a piece of prototype board. The only external component you need is the 100nf capacitor between VCC and GND. Those modules use MAX485 chips instead of the MAX487 that we recommend. The MAX485 will only handle up to 32 devices instead of 128, but more importantly, the MAX485 is not slew-rate limited, which means you probably will have to terminate the bus. If the various schematics I found online for those modules are correct, they also include termination and bias resistors on every module. If you are using termination resistors at all, you only want those at the start and end of the bus, so you'll have to modify any module you use in the middle. As far as we know, when using the slew-rate limited MAX487 and keeping the bus length below 10 meters, biasing and termination resistors are not required. (Termination is not required if the bus is short enough, and without external termination resistors, the internal biasing resistors in the MAX487 should be enough -- this is the "fail-safe feature" that is mentioned in the datasheet.) If you use MAX485 chips, the necessary termination and biasing resistors will further reduce the amount of devices you can have on the bus. (see also: http://dcs-bios.a10c.de/rs485-resistors.html)

To handle multiple COM ports right now, you need to run multiple copies of connect-serial-port.cmd. DCS-BIOS 2.0 will do all of that from a single application eventually, to make it more convenient. Usually, when you plug in a new USB-to-Serial adapter, Windows will assign it a COM port number. When you unplug the device and plug it in again later, it will get assigned the same COM port, but only if Windows recognizes it as the same device. If the device does not have a unique serial number in its USB descriptor (and most adapters don't, because it complicates the manufacturing process), then the COM port number it is assigned will change from time to time. Now imagine having to change dozens of COM port numbers in a settings dialog somewhere every time Windows decides to do this... If you prefer to connect everything directly through USB, you can certainly do it. If you have a free PCI Express (x1) slot, you can add another USB controller for about $15. DCS-BIOS will always support multiple USB-to-serial connections, but it will be designed for about five, not 30+, so I think RS-485 is the less annoying way to go in the long term.

Definitely go with RS-485. Even if you wait for DCS-BIOS 2.0, which will talk to multiple COM ports at once, it will still be a huge annoyance dealing with 30 USB-to-Serial adapters. Especially when Windows renumbers them at will because they don't have proper serial numbers. Even though in theory, one USB controller can handle up to 127 devices (hubs count as well), I have heard that you can run into problems with more than 20 already and would need to install another USB controller (on a PCI-E Card). DEFAULT_SERIAL mode is problematic as soon as many outputs (or a few that take a long time to update, like character displays) are involved. It's kept around as a compatibility mode because it works on any Arduino-compatible board. That makes it possible to get started with whatever Arduino board you happen to already have and it enables the use of faster, ARM-powered boards for special cases like the CDU display. Those faster boards also tend to have enough RAM and CPU power to mitigate the problems of DEFAULT_SERIAL mode (they can afford a larger receive buffer).

Many issues with an RS-485 bus can be diagnosed equally well with either a digital storage oscilloscope or a logic analyzer. The DSO shines when the problem is with analog signal integrity, because you can use it to look at the voltage difference between the A and B lines. A logic analyzer obviously can't do that. The scope is also quicker to set up and less annoying to use (no need to start/stop the capture manually). In general, I prefer to use the oscilloscope whenever feasible (I have the DS1054Z as well). The logic analyzer is the preferable choice when the problem is difficult to trigger on with the oscilloscope and occurs so infrequently that you can't find it in single-shot mode. Using protocol decoders to look at the transmitted data is also a lot easier to do on a PC compared to the DS1054Z with its smaller screen and slower CPU. Due to its 8 channels, the logic analyzer can also be used to look at all relevant digital signals (DI, /RE, DE, RO) for both the master and a slave device at the same time. In general, the oscilloscope is better for finding problems with signal integrity and the logic analyzer is better for finding software problems. If you don't have a logic analyzer, you can grab one for less than $10 on eBay. Those are cheap clones of the early Saleae Logic 8 models. They work reasonably well with sigrok and are fast enough for any digital signal you will ever deal with on a 16 MHz microcontroller. Because they stream the data to the PC over USB 2.0, capture duration is theoretically only limited by available hard drive space. In practice, the sample rate that can be reliably sustained depends on the USB drivers and what other hardware is connected to the same USB port.

Hast du die connect-serial-port.cmd editiert und die richtige COM-Port-Nummer eingetragen? Benutzt außer DCS-BIOS noch irgendwas anderes (Helios, TacView, etc.) die Export.lua? Die connect-serial-port.cmd musst du nicht als Admin starten. Ansonsten poste mal deine dcs.log.

Die entscheidende Zeile ist die hier: LedControl lc=LedControl(2,3,4,1); Die erste Zahl (2) gibt den DATA_IN pin an, die zweite (3) den CLOCK pin und die dritte (4) ist der LOAD/CS pin. Die vierte Zahl (1) ist die Anzahl der hintereinandergeschalteten MAX7219-Chips. Siehe auch: http://playground.arduino.cc/Main/LedControl#Setup Auf dem 8-stelligen MAX7219-Modul, was auf eBay und AliExpress gängig ist, sind die Pins wie folgt bezeichnet: DATA_IN: "DIN" CLK: "CLK" LOAD/CS: "CS" EDIT: Für das Schaltbild in deinem Post müsste die Zeile so aussehen: LedControl lc=LedControl(22, 26, 24, 1); EDIT 2: Solange du "VCC" mit 5V und "GND" mit Masse verbindest, kann da bei diesem Modul nichts kaputt gehen, egal an welche Arduino-Pins du die anderen Kabel hängst. Es kann nur die Daten falsch interpretieren.

There is nothing obviously wrong with the sketch. You can double check the following: Is pin 2 (TX_ENABLE) connected to both /RE and DE on the MAX487? No duplicate slave address on the bus? (does it work with a single slave device on the bus?) If it's not one of those, you'd need a logic analyzer for further debugging. I plan to add some better RS-485 debugging capabilities in DCS-BIOS 2.0, but unfortunately that's still some time away.

Pixar: sorry für die späte Reaktion. Ich hab deinen Sketch gerade mal auf einem Mega ausprobiert, funktioniert einwandfrei (kleiner Bug: du überschreibst Ziffer 0 nie, so dass z.B. 125,125 MHz als "125.1258" angezeigt wird). Entweder ist an deinem Mega was kaputt oder die Kabel, die bei deinem Uno guten Kontakt bekommen, haben mit der Buchse auf dem Mega Probleme. Du kannst ja mal versuchen, andere Pins auf dem Mega zu benutzen (vielleicht haben die Kabel an anderen Stellen besseren Kontakt). Als Test würde ich einen der Beispiele von der LedControl-Library nehmen, dann musst du zum Testen nicht erst DCS starten. Diese Buchsenleisten haben meiner Erfahrung nach nie so richtig guten Kontakt mit den typischen Jumper Wires ("DuPont-Kabel"), die man so auf eBay bekommt. Die passenden Stiftleisten (sowas hier) funktionieren dagegen zuverlässig. Was relativ gut funktioniert, ist das Plastikteil in die Mitte der Stiftleiste zu schieben, so dass beide Enden ungefähr gleich lang sind. Dann die Stiftleiste in die Buchsenleiste des Mega stecken, und ein DuPont-Kabel mit Buchse oben drauf. Oder einfach direkt einen Draht per Lötverbindung oder Wire Wrap an die Stiftleiste anschließen.