FSFIan

Die Warnmeldung ("Couldn't compute FAST_CWD pointer") ist normal unter Windows 10. Sollte aber trotzdem funktionieren (hab selbst Windows 10). Sobald du DCS startest und in einem Ka-50 sitzt (und das Spiel nicht pausiert ist), sollten Daten übertragen werden -- sieht man einerseits im Konsolenfenster, andererseits an der blinkenden RX Led auf dem Arduino-Board (und hoffentlich auch daran, dass das Display die Werte vom UV-26 anzeigt).

Um beliebige Hardware (in diesem Fall den MAX7219) mit DCS-BIOS zu verwenden, ist der erste Schritt im Allgemeinen, die Hardware erstmal ohne DCS-BIOS zum Laufen zu bringen. Danach hat man verstanden, wie man die benutzt, und weiß, dass die Schaltung richtig aufgebaut ist. Um den MAX7219 mit Arduino-Boards anzusteuern, gibt es die LedControl-Library. Da die in der offiziellen Liste eingetragen ist, kannst du die einfach über "Sketch -> Include Library... -> Manage Libraries..." in der Arduino-IDE installieren. Mit der Dokumentation und den mit der LedControl-Library mitgelieferten Beispielen kann man dann erstmal ein einfaches Testprogramm bauen: https://gist.github.com/jboecker/e2d3a1972a8ac442f923955c79858c3c Das zeigt eine Sekunde lang "88888888" an, und zeigt danach an, welche Ziffer welche interne Nummer hat: Mit dem Wissen, welchen Initialisierungscode man in setup() braucht und wie man mit setChar() ein Zeichen auf das Display platzieren kann, lässt sich das jetzt mit DCS-BIOS kombinieren: https://gist.github.com/jboecker/298e471192bc3f9425acb817eb359057 5OKPht_tpME

Ich hätte Interesse an ein oder zwei VID60-02 Schrittmotoren, damit ich die mit DCS-BIOS testen kann. Leider finde ich die nur im Zehnerpack für ca. $70 inklusive Versand. Ich bin zusammen mit Warhog dabei, Code für die Ansteuerung dieser Motoren zu schreiben. Leider sind da wohl noch Bugs drin, und ich würde das Setup gerne selbst nachbauen damit ich das ans Oszilloskop hängen kann. Sobald das stabil läuft, werden wir den Code selbstverständlich veröffentlichen. Wenn ihr Interesse an einer kleinen Stückzahl dieser Motoren habt (für ca. 6,63 € pro Stück), schreibt das doch mal hier rein. Ich würde die dann bestellen und per Warensendung (schätze mal so 3 Euro für Verpackungsmaterial und Porto) innerhalb Deutschlands weitersenden. Der VID60 hat keine mechanische Begrenzung und bietet sich damit für den Höhenmesser, Air Speed Indicator und die HSI Compass Card an. Im Gegensatz zu den meisten erhältlichen Schrittmotoren ist bereits ein IR-Sensor und entsprechende Mechanik integriert, die man nur noch von außen mit einer IR-LED beleuchten muss, um festzustellen, ob der Motor an der Nullposition steht. Ein weiterer Kandidat für eine Sammelbestellung wäre der VID-28. Das sind im Prinzip zwei VID29 in einem Gehäuse, die je einen Zeiger auf einer gemeinsamen Achse steuern. Warhog hat den in seinem Fuel Indicator verbaut. Wenn sich da genug Leute für interessieren, würde ich den auch bestellen und weiterverteilen.

Because IRQ_SERIAL mode and the RS-485 stuff requires either an ATMega328 or an ATMega2560 processor, your choices boil down to the following list of boards (which ignores boards with ATMega32u4 or ARM processors): Mega 2560 Uno Nano Pro Mini First, we can eliminate the Uno from that list, because for the purposes of building a simpit, the Nano only has advantages compared to it. The Uno has 20 digital I/O pins, 6 of which can be used as analog inputs. The Nano has the same, but in addition it has two extra analog-only pins. Due to its smaller form factor, the Nano is cheaper to produce and easier to tuck away behind a panel. Compared to the Nano and Pro Mini, the Uno has the advantage that you can connect shields to it and that it has a DC power jack, but I think both of these are irrelevant for the purpose of building a simpit. I can't imagine a situation where you'd use a shield in a panel, and you can power the Nano either over USB or through the V_IN pin. The Pro Mini is a slightly smaller Nano that lacks the onboard USB-to-Serial converter. It costs about $0.40 less than the Nano. This could save some money when using it for RS-485 slave devices, where you only need the USB-to-Serial converter once to upload the firmware, but IMO saving $0.40 is not worth the hassle. The Pro Mini can be plugged into a breadboard, but some pins (notably A4, A5, A6, A7) are not in breadboard-friendly locations (and not even in on the 0.1" grid relative to the other pins). I used to recommend the Pro Mini when I hadn't learned of AliExpress prices and thought the price difference to the Nano was larger, but now I recommend the Nano over the Pro Mini. In conclusion, two boards stand out for use with DCS-BIOS: Use Arduino Mega 2560s for the RS-485 master, to do quick prototyping with Arduino Shields, or for panels that require lots of I/O pins. I'd use Arduino Nanos for everything else. The choice between one Mega or several Nanos is mostly one of personal preference. The cost per usable I/O pin is about the same. For CPU-heavy applications (stepper motor control comes to mind), spreading the load out over multiple Nanos has an advantage. Using all of the Mega's I/O pins for outputs might lead to a situation where the CPU isn't fast enough to process all of the incoming data; I haven't tried to push one to its limits yet, but I also haven't received any reports of problems so far. Using a Mega to serve multiple panels increases the length of wiring between the panels and the MCU but decreases the number of devices on the RS-485 bus. If you are not building a full cockpit, using a Mega vs. several Nanos might be the difference between needing an RS-485 bus or not.

Keep in mind that LoGetSelfData() will return nil in certain situations when there is no active aircraft, such as in spectator mode. Make sure your code handles that case without crashing.

The baud rate is fixed at 250000 bps in newer versions. Anything else won't work. I think this is a problem that can happen with the Mega when starting the script after DCS. I first ran into this while developing the RS-485 master code and was thoroughly confused for a while, because I suspected my new code. When the connect-serial-port.cmd script executes the "mode" command to set the baud rate, it resets the Mega as a side effect. After a reset, the bootloader runs and waits for a new program to be uploaded via the serial port. It receives the data from DCS. While the bootloaders on ATMega328P-based boards seem to go "this is not a valid program, let's go start the sketch!", the bootloader on the Mega gets stuck instead. Workaround 1: pause DCS press the reset button on your Mega wait for the pin 13 LED to flash twice once the LED has turned off, unpause DCS Workaround 2 (if this works for you as well I'll add this to the next release): Edit your connect-serial-port.cmd script. Between the "mode" and the "socat" commands, add this line: timeout 1 This adds a one second delay to wait for the bootloader to time out.

Your work looks amazing! (When I watch that CMSC video, my brain adds the audio all on its own -- "beeep, beeep, beeep, BOOM!". I love how the chaff/flare display just switches to "FAIL"!) That UHF display looks like another OLED. Does it display all the segments when you press the display test button on the UHF radio? (If not, you can fix that by replacing the the '*' character in your font.) Also, I am curious: how much experience did you have with electronics and programming before you started building? What did your very first test setup look like?

I don't think you can access FFB info through Export.lua. There might be another way (either through software or by building your own USB FFB device, e.g. based on adapt-ffb-joy), but it's not something that will be supported by DCS-BIOS.

Aktuelle Versionen von DCS-BIOS benutzen immer 250000 bps. Wenn was anderes in der connect-serial-port.cmd steht, kann das gar nicht funktionieren. Die Einstellungen im Gerätemanager sind egal, weil die connect-serial-port.cmd mit dem "mode"-Befehl die passende Bitrate setzt. Poste hier mal den Code, der auf dem Uno funktioniert, und den, der dann auf dem Mega nicht funktioniert. Normalerweise musst du den Code nicht ändern, es reicht, in der Arduino-IDE das Board auf "Mega 2560" zu setzen und den COM-Port auszuwählen, an dem der Mega dranhängt. Es könnte eine von diesen Fehlerquellen sein: Irgendwas ist beim Upload auf den Mega schiefgegangen (unwahrscheinlich, da ja zumindest Müll auf den Displays ankommt) Wenn du auf dem Mega gleich die Rotary Encoder hinzugefügt hast, könnte es an dem neuen Code liegen (sollte im DCSBIOS_IRQ_SERIAL-Modus nicht passieren, mit DCSBIOS_DEFAULT_SERIAL ist das durchaus möglich) Beim Umbau auf den Mega irgendwelche Leitungen vom MAX7219 vertauscht (z.B. CLOCK und DATA)

I am not sure. You could try to monitor the aircraft name from the MetadataStart module: void onAcftNameChange(char* newValue) { if (strcmp(newValue, "A-10C")) { // not in an A-10C, turn off light here } } DcsBios::StringBuffer<16> AcftNameBuffer(0x0000, onAcftNameChange); I don't remember when the aircraft type changes (probably as soon as you go back to spectator mode in multiplayer / select another aircraft in single player mode). Before including DcsBios.h, you have to tell DCS-BIOS how it should communicate with the PC by #defining one of DCSBIOS_IRQ_SERIAL, DCSBIOS_DEFAULT_SERIAL or DCSBIOS_RS485_SLAVE (see example sketches). On the Leonardo, only DCSBIOS_DEFAULT_SERIAL will work, which is not optimal but should work for a single character display. I suggest you start with the DefaultSerial example sketch and then add your code to it. You should not mess with the serial port at all, so make sure not to add these lines: Serial.begin(112500); // don't do this in setup() while (Serial.available()) { // and don't do this lcd.print(Serial.read()); // in loop() either } (Early versions of the Arduino library handled this differently, you probably found an example that was written a while ago.) You will notice that the 19-character string you get from DCS-BIOS, which includes spaces, won't fit on your 16-character line. See this post for code snippets that will skip the spaces when writing to the display.

You could also write a Lua script that checks the loadout every few seconds. If they are still on the ground, give them a warning message, once they are in the air with an invalid loadout, kick them back to spectator mode.

The Lua console still works. The moving units around part broke when the mission file format changed.

Should be fixed in the new v0.2.6 release of the Arduino library. You can now also set the number of steps per detent for rotary encoders with a new optional argument like this: DcsBios::RotaryEncoder tacan1("TACAN_1", "DEC", "INC", 3, 4, DcsBios::TWO_STEPS_PER_DETENT); Use one of DcsBios::ONE_STEP_PER_DETENT DcsBios::TWO_STEPS_PER_DETENT DcsBios::FOUR_STEPS_PER_DETENT

Released v0.2.6 of the Arduino Library. make IntegerBuffer::hasUpdatedData() public fix undefined behavior in DCSBIOS_DEFAULT_SERIAL mode add optional argument to select number of steps per detent to DcsBios::RotaryEncoder Please post comments in the DCS-BIOS Discussion Thread.

Unfortunately, the only way to learn about those right now is to read the code. I don't think I documented them anywhere so far. The short version: each IntegerBuffer or StringBuffer sets a flag (the "dirty bit") whenever it receives new data. The hasUpdatedData() method returns the status of the dirty bit. The getData() method always returns the last received value (or 0 respectively the empty string if the sketch just started up and no data has been received yet). Calling getData() will also clear the dirty bit. Think of the dirty bit as the little flag on a US mailbox that the postman sets when new mail has arrived and that is reset when the mailbox is emptied. If you supply your own callback function, this is the logic that the class will do for you: if (hasUpdatedData()) { if (callback) { callback(getData()); } } Every time DcsBios::loop() is called, the dirty bit is checked. When it is set, getData() is called -- clearing the dirty bit -- and the value is passed to your callback function. That logic works for most cases. If you need anything else (such as in this example), you should pass no callback function (to avoid clearing the dirty bit before your own code checks for it) and implement whatever logic you need in your loop() function.

This requires a slightly different approach to get it right for all of the edge cases. Note that the contents of your display now depend on two pieces of cockpit state info: the selected TACAN channel and the state of the TACAN mode dial. Your sketch needs to monitor both of these values and update the display whenever one of the two changes. The code examples from the control reference pass a callback function to the StringBuffer or IntegerBuffer class that gets called whenever the monitored value changes. However, you can also choose not to pass a callback function at all and manually check for changes in your loop() function. That is the most elegant way to monitor two different values at once. Here's an example that should get you started. My usual disclaimer applies -- I didn't bother to grab all the libraries and see if it compiles. #define DCSBIOS_IRQ_SERIAL #include "DcsBios.h" #include <Wire.h> // this library is needed to drive i2C #include "Adafruit_LEDBackpack.h" // vendor custom library #include "Adafruit_GFX.h" // vendor custom library Adafruit_AlphaNum4 alpha4 = Adafruit_AlphaNum4(); // we need to monitor both the TACAN channel: DcsBios::StringBuffer<4> tacanChannelBuffer(0x1162, NULL); // and the mode switch: DcsBios::IntegerBuffer tacanModeBuffer(0x1168, 0x000e, 1, NULL); void setup() { alpha4.begin(...) // or whatever else you need to do to initialize that display DcsBios::setup(); } void loop() { DcsBios::loop(); if (tacanChannelBuffer.hasUpdatedData() || tacanModeBuffer.hasUpdatedData()) { // if either of those values has been updated, update the display if (tacanModeBuffer.getData() == 0) { // mode dial in OFF position alpha4.writeDigitAscii(0, ' '); // Blank Display if Mode knob is set to Off. alpha4.writeDigitAscii(1, ' '); // 0 is left most display, 3 is right most display alpha4.writeDigitAscii(2, ' '); alpha4.writeDigitAscii(3, ' '); } else { char* channelStr = tacanChannelBuffer.getData(); alpha4.writeDigitAscii(0, channelStr[0]); alpha4.writeDigitAscii(1, channelStr[1]); alpha4.writeDigitAscii(2, channelStr[2]); alpha4.writeDigitAscii(3, channelStr[3]); } } }

Reverse the order of your #include statements. You need to include Servo.h before you include DcsBios.h. Also, no idea why you have the "Servo Myservo" and "int PIN_Myservo" lines, they seem to be unrelated to the rest of the program?

For DCS-BIOS, you can't go wrong with a Nano or a Mega 2560, since those are the two boards I use for development. Anything else with the same microcontroller (ATMega328 or ATMega2560) will work just as well, for example the Uno or Pro Mini. Avoid boards with different microcontrollers (Leonardo, Due, etc) unless you have a specific reason, as they are not supported in IRQ_SERIAL or RS485_SLAVE mode. They will need to use the inefficient DEFAULT_SERIAL mode, which can lead to problems. My recommendation would be the Nano, which is about $2.20 for the board (remember to add a $0.80 USB cable; most Nanos use Mini-USB, but I have seen some sellers offer a Micro-USB variant). I prefer the Nano over the Mega because I can just stick it on a breadboard.

Well, what do you want to build? How many I/O pins do you need, how do you want to interface to DCS (build a joystick, use Helios or DCS-BIOS, roll your own solution)? Do you want to start small or are you already planning to build a complete pit?

Hook it up to the master as the only connected slave device. Use another MAX487 chip that has RE and DE pulled low and is connected to a USB-to-Serial adapter to view the data on the RS-485 bus. Then see which device ID gets polled over and over again. If you have a logic analyzer, you can also watch the TX pin on the master and the TXENABLE on the slave, find a time when the slave transmits a reply, and see which address was polled by the master immediately before that. That will even work on a bus that has several devices connected to it. Assuming the slave address is 42 and it has been running for a second, you'd see something like the following byte sequence on the RS-485 bus: 1 // target address 0 // message type 0 // payload length 0 // reply payload length 42 // target address 0 // message type 0 // payload length 0 // reply payload length 2 // target address 0 // message type 0 // payload length 0 // reply payload length 42 // target address 0 // message type 0 // payload length 0 // reply payload length 3 // target address 0 // message type 0 // payload length 0 // reply payload length 42 // target address 0 // message type 0 // payload length 0 // reply payload length etc.You get the idea. The master will poll a device by sending a zero-byte message. The device responds with the length of its reply, which is zero if it doesn't have anything to say. After polling all devices it knows about, the master will poll one unknown device. That device won't answer (unless you plugged it in in the meantime), so after a small timeout (two milliseconds IIRC) the master will send the 'zero payload length' reply byte itself to avoid confusing the other devices on the bus and then start polling its list of known devices again.

Don't worry, I didn't spend any time investigating yet. Now that we know the cause though, I wonder if I can make DCS-BIOS 2.0 detect that pattern (or more general, anything that goes wrong on the RS-485 bus) and warn the user. Setting two slave devices to the same ID is an error that is easy to make (especially when "flashing a known good sketch" during testing), but can potentially cause intermittent, hard to debug problems.

That syntax error (missing 'e' and lower case 'float' in 'definefloat', should be 'defineFloat') might be what caused your earlier problem. I meant that you could copy the syntax for that <script> tag from the other existing tags. You don't have to create the JSON files; they are written whenever DCS-BIOS starts (assuming it gets to that point and doesn't crash beforehand). Curious. I don't even know where to start debugging that... does it happen without any slave devices attached? I wonder if there is a slave device that sends an empty message (i.e. just a newline) every few seconds, or if it is some thing the master does by itself.

I don't know where you got the idea that you need to mess with that autogenerated file. Have you followed along the DCS-BIOS Developer's Guide? If so, where did you get stuck?

local selfData = LoGetSelfData() -- todo: handle case where LoGetSelfData() returns nil (happens in spectator mode, when crashed, etc) -- todo: handle case where LoGetSelfData() does not return ownship position (MP server with allow_ownship_export ("Allow Player's Export") turned off) local alt = selfData["LatLongAlt"]["Alt"] local lat = selfData["LatLongAlt"]["Lat"] local long = selfData["LatLongAlt"]["Long"]

Works for me in DCS: World OpenBeta 1.5.4.57288. Is anyone else seeing this?