FSFIan

My idea of doing this simply is exactly what you have done: find a library that does the work for you and use it. It doesn't get any simpler than that (other than getting other people to program your sketch for you). Without more information about what you tried and what went wrong, I don't really know what questions you need an answer to. If you tried using the C++ version but it did not compile, try the C version of the library instead. According to their documentation, "This is a self-contained library (requiring only the standard C math library)", so it should not use any advanced features (e.g. C++ exceptions) that may be problematic on embedded systems. You say you are "not a C++ guy" yet you don't want to involve "another software layer". So I assume that you want to learn C++. Where did you get stuck?

Here is a python script that displays the CDU using DCS-BIOS. It's only a display, though, adding the OSBs would need additional programming (or Helios).

Du darfst nur ca. 10 Sekunden auf dem Kopf fliegen, danach kommt die Treibstoffpumpe nicht mehr hinterher und die Triebwerke gehen aus. Mit genug Höhe oder Geschwindigkeit ist es aber kein Problem, alles in der Luft wieder anzuwerfen, denn es ist ja nichts kaputt gegangen. Möglichkeit 1: APU wieder anwerfen, Schubhebel auf OFF (über den indent heben) und dann wieder auf IDLE, um das Triebwerk zu starten. Möglichkeit 2: "Windmill-Restart" -- den MOTOR/NORM/IGN Schalter (über dem APU START-Schalter) in der IGN-Position festhalten, bis das vom Fahrtwind angetriebene Triebwerk anspringt (ggf. in den Sturzflug gehen, damit das auf die passende Drehzahl kommt).

The value for R_SET is independent of the number of used segments. (If you use the "segment limit" register to reduce the number of segments that the MAX7219 controls to three or less, the maximum output current you are allowed to set will be lower than 40 mA to prevent overheating the digit drivers, but the relationship between R_SET and the current through each LED is still the same.) From the datasheet: Let's do an example. Say we have these green 5050 LEDs which are rated for 30 mA and have a forward voltage of 2.0 V. To get each segment driver to output 30 mA, we want the current going into the I_SET pin to be 30/100 mA = 0.3 mA, so R_SET would be: R_SET = 5 V / 0.3 mA = 16666 ohm, so about 17 kOhm. Table 11 in the datasheet confirms this: for V_LED = 2.0V and I_SEG = 30 mA it tells us to use R_SET = 17.1 kOhm. Now what happens if we use these LEDs instead, which still want 30 mA but have a forward voltage of 3.4 V? Our calculation does not involve V_LED at all, so we still arrive at R_SET = 17 kOhm. However, Table 11 in the datasheet tells us to use 14 kOhm (for V_LED = 3.5 V). Take a look at the "SEGMENT DRIVER OUTPUT CURRENT vs. OUTPUT VOLTAGE" diagram on page 4. In an ideal world, those lines would all be parallel to the X axis, but whatever piece of black magic they use in each segment driver that looks at the I_SET current and makes the output current be 100 times as much does not behave that way (in other words: its amplification factor depends on the output load). Exercises: 1) Try to pick a few combinations of I_SEG and V_LED from table 11, look them up in this diagram and then see how close you got to the value that is listed in the table. 2) Why is table 11 limited to V_LED values from 1.5 to 3.5 V?

Ich weiß, dass airtom damit angefangen hat, Ka-50-Support in DCS-BIOS einzubauen (ich habe dazu ein paar Fragen per PM beantwortet), und zwei weitere Leute hatten mich per PM kontaktiert und Interesse an der Mitarbeit bei der Ka-50-Unterstützung angeboten. Ich habe denen gesagt, sie sollen sich untereinander mal absprechen, damit da jetzt nicht die gleiche Arbeit mehrfach gemacht wird, habe aber bisher nichts weiteres gehört. Von daher: Es kann gut sein, dass wir Ka-50-Unterstützung bekommen, ich kann es nur weder garantieren noch irgendeinen Zeitrahmen angeben. Der Aufwand, alles auf Deutsch zu übersetzen und dann auch zukünftig aktuell zu halten lohnt sich glaube ich nicht. Es ist einfacher, jeweils im Einzelfall Fragen zu beantworten, die dann auch relativ allgemein ausfallen dürfen, z.B. "Wie baue ich mir mit DCS-BIOS ein AHCP?" oder sowas. Das skaliert zwar nicht auf viele User hoch, aber erst einmal gehe ich davon aus dass man die potentiellen DCS-BIOS-Benutzer, die nicht genug Englisch können um die vorhandene Dokumentation zu verstehen, an einer Hand abzählen kann. Es gibt relativ wenige Menschen, die das PC-Flugsimulator-Hobby teilen. Davon spielt nur ein Teil DCS. Von denen baut nur ein sehr kleiner Teil eigene Panels. Und wiederum nur ein Teil davon sind DCS-BIOS-Benutzer. Diese Benutzergruppe ist einfach zu klein, um zwei (oder mehr) Unterabteilungen für verschiedene Sprachen am Leben zu erhalten. Von daher würde ich folgende Vorgehensweise vorschlagen: Wenn möglich, benutzt das englische Forum zum Nachfragen und für den allgemeinen Informationsaustausch. Das hat den Vorteil, dass möglichst viele andere Benutzer auch was davon haben. Wenn ihr eure Frage mit den englischen Resourcen nicht beantworten könnt (was ja gerade bei einem Thema, in das man sich gerade erst reinliest und was einen stellenweise noch verwirrt auch deshalb vorkommen kann, weil man gar nicht genau weiß, wie man die Frage -- dann auch noch auf Englisch -- überhaupt formulieren soll), dann fragt gerne hier nach. Sollten es dann doch so viele sich wiederholende Fragen werden, dass es sich lohnt, die Dokumentation (zumindest teilweise) auch in einer deutschen Version zu pflegen, lasst ich mich gerne eines besseren belehren.

Was ist DCS-BIOS? DCS-BIOS besteht aus einer Export.lua-Datei für DCS: World und einer Arduino-Library. Damit kann man für unterstützte Flugzeugmodule (im Moment A-10C, UH-1H und Mig-21bis) ganz einfach Panels auf Basis der einsteigerfreundlichen und kostengünstigen Arduino-Mikrocontrollerplatform bauen. Für Taster, Kippschalter, Drehschalter, Inkrementalgeber oder einzelne LEDs braucht man keine weiteren Kenntnisse (ok, ihr solltet aus der Schulphysik noch in Erinnerung haben, was ein Stromkreis ist, was ein Kurzschluss ist und wie man ihn vermeidet). Wer ein bisschen programmieren lernt, der kann auch LEDs, Displays, Hobby-Servos, Schrittmotoren oder eine ganze LED-Matrix (z.B. Caution Lights Panel) ansteuern. Einführungsvideo Dieses Video, welches ich jetzt auch mit deutschen und englischen Untertiteln versehen habe, zeigt wie einfach das geht: 8vI_W0j_3uY Mehr Informationen (Englisch) Auf der DCS-BIOS-Webseite unter http://dcs-bios.a10c.de findet Ihr Download-Links zur jeweils aktuellen Version und eine Online-Version des Benutzerhandbuchs. Weitere Links (z.B. auf den DCS-BIOS YouTube-Channel) gibt's im DCS-BIOS Overview-Thread im Home Cockpits-Forum. Warum jetzt dieser Thread? Anfang des Jahres hab ich zusammen mit WarHog die erste Version veröffentlicht. Ich hab das bisher im deutschen Forum nicht erwähnt, weil ich davon ausging, dass jeder potentiell Interessierte sowieso regelmäßig ins englische Home Cockpits-Forum schaut. Dieser Thread soll eine Anlaufstelle sein, um Support auf Deutsch zu erhalten. Ein Ziel von DCS-BIOS ist es, Leute zum Basteln zu ermutigen, die sonst vielleicht nie damit angefangen hätten. Hiermit sind jetzt "ich kann kein Englisch" und "ich hatte ja keine Ahnung, dass das so einfach sein kann!" hoffentlich keine gültigen Ausreden mehr. :)

You might be interested in agrasyuk's Raspberry Pi-powered CDU build.

That would explain it. Update to the latest release (currently v0.3.0) and it should work with the version that is on GitHub.

The only significant difference I see between your latest version and mine (besides LedControl pin numbers, row/column maps and whitespace) is that my version updates the MAX7219 once after an update from DCS-BIOS has been received (on write access to address 0xfffe), while your version updates the MAX7219 up to three times per update (once for each data word that is received). Are you maybe using a very old version of DCS-BIOS (older than v0.2.2, which was released on January 13)? Versions before v0.2.2 did not have the update counter at 0xfffe, so the sketch would wait forever for the "this update has ended, you now have lots of time to update stuff" signal.

That is great to hear! The CLP (and the signal lights test button) is the thing that can cause the greatest number of indicators to change rapidly in a way where latency issues are easily noticed by humans. It was what made me switch to a binary export protocol. It's a relief to know that this works well in the real world (i.e. not only is the data exported correctly and 30 samples per second are enough, but you also don't have noticeable jitter coming from buffering in the USB drivers for example). Can you post the complete working sketch you have (link to pastebin or something)? I'll run a diff against my latest version to see where I missed something. Also, does it work at 250000 bps?

We want to calculate the row on the physical caution lights panel in which the 16 data bits we received begin to apply. "address - 0x10d4" gives us the offset as a number of bytes. Each 8-bit byte covers two rows of 4 LEDs, hence multiply by 2. But you made me look in the right place! The error is on the next line, where I multiply by 16 (bits in a data word) when I should multiply by 4 (bits in a row) :music_whistling: I have updated the sketch to correct that error (and also renamed the row variable to clp_row to make it clear it refers to rows on the physical CLP instead of the MAX7219).

Here is the sketch. Note that it is a bit more complicated than it absolutely needs to be because it includes a layer of indirection so you can make it work with any conceivable LED matrix arrangement. If you set the correct pin numbers in line 9 and you have your LED matrix wired up, every caution light in your virtual cockpit should correspond to one on your physical panel. You can then edit the "cl_row_map" and "cl_mask_map" arrays (lines 61 and 83) to get the locations right (the visual layout of the arrays in the code matches the physical layout of the CLP). If it does not work out of the box, I can be available tomorrow or Friday night to troubleshoot things (from about 19:00 GMT).

The code will be the easiest part, because I already wrote it for WarHog's CLP. We didn't get it to work but suspect it's a hardware issue. The MAX7219 is definitely the way to go for the Caution Lights Panel. It's just so much less work. It saddens me when I see people go for the overcomplicated solution of one pin per LED just to avoid learning basic programming skills. Just because the DCS-BIOS Arduino library does not include a premade class for a specific situation does not mean it is impossible to do with DCS-BIOS. How about we meet up on Skype or TeamSpeak and get this working? I'd love a chance to confirm that the sketch works. I am not at my gaming rig right now, will post a link to the code later.

You can also use https://github.com/mrSkortch/MissionScriptingTools/releases/latest which will automatically redirect you to the latest release.

You can map the panels connected to your Leo Bodnar board through Helios. Setting up the bindings in your Helios profile can be annoying, but you only have to do it once. You can also use DCS-BIOS, which is quicker to set up, but currently has no way to interface with USB joysticks, so it's probably a better fit for new panels if you don't want to mess around with (and buy Arduino boards for) the existing ones. I would not go the route of editing the input Lua files, because that way you may have to constantly react to changes in DCS: World. You'd also have to look at the A-10C's clickabledata.lua file for each switch to find out the correct command IDs and arguments, because internally, some switches work differently from others.

IMO point three should be qualified by "WHEN APPROPRIATE". Yes, a realistic and authentic mission can be more immersive, which is a good thing. But most people don't want a multi-hour long ingress flight. Otherwise, full ack on all points.

Connect a wire to ground and touch pin 8 with the other end. If that switches the virtual cockpit switch to position 2, there is something wrong with how your switch is wired up (double-check with a multimeter that the switch connects the pins the way you think it does and/or take another look at the switches datasheet if you have one). EDIT: Sorry, I didn't watch closely enough the first time. I have reproduced the bug here, will take a closer look with the Lua Console. Update (02:43): Found the bug, too tired to fix it properly right now. Of course they had to make a variant of rocker switches that uses 0.0, 0.1 and 0.2 for the argument value instead of -1, 0 and 1 like all the other ones, so I will have to add an option to defineRockerSwitch() to specify the range and change all the places where it is currently used.

You start with an unordered set of points. To make those into a line, I would find a starting point and then subsequently add the closest point that is not already on the list. To find a suitable starting point, you could just sort by X, then Y coordinate (i.e. take the top-left one). Note that for a given set of points there can be several polyline interpretations that "look plausible" to the human eye (example). Once you have an actual polyline (i.e. an ordered list of points), point (2) should be easy to solve with the vector math functions provided by MiST. To solve (4), you can do something like this (untested): function getPointOnPolyline(polyline, distance) local i = 1 while distance > 0 do local a = polyline[i] local b = polyline[i+1] local ab_diff = mist.vec.sub(b, a) local ab_dist = mist.vec.mag(ab_diff) if distance > ab_dist then distance = distance - ab_dist i = i + 1 continue end local direction = mist.vec.getUnitVec(ab_diff) return mist.vec.add(a, mist.vec.scalar_mult(direction, distance)) end end I don't know if all the MiSt vector functions work with vec2's, you may have to convert to vec3's first.

For a line (untested): function getRandomPointOnLine(start, end) -- start and end are Vec3's local diff = mist.vec.sub(end, start) local length = mist.vec.mag(diff) local direction = mist.vec.getUnitVec(diff) return mist.vec.add(start, mist.vec.scalar_mult(direction, mist.random(length))) end For a random point in a polygon, I would repeatedly calculate a random point in a bounding box until you get a hit with mist.pointInPolygon().

The DcsBios::Switch3Pos class in the Arduino library assumes ON-OFF-ON switches, because they are the most common type. Pin A goes to the "zero" position (down or left), pin B goes to the "two" position (right or up). If your switch is not ON-OFF-ON, you can make it work with the more general DcsBios::SwitchMultiPos. Where did you get the impression you needed OFF-ON-ON switches? Sounds like an opportunity to remove a possible source of confusion from the User Guide.

I have no idea. DCS-BIOS does not limit the number of concurrent connections. The most I have ever actually tested with was probably two or three (the python script and one or two instances of the control reference docs), so I can't say if you'd need dozens, hundreds or thousands of connections before you'd start to see performance problems. Somewhere above several hundreds you might also run into limitations of LuaSocket or your operating system. So I guess the practical answer to your question is "as many as any remotely sane setup needs."

Here's a DCS-BIOS-powered solution written in Python: http://forums.eagle.ru/showthread.php?p=2312247#post2312247

The only radio-related displays I am aware of that are affected by the availability of electrical power are the UHF repeater and the UHF preset display. DCS-BIOS uses list_indication() to get those values, so it reflects changes due to power loss and shows "***.***" on the UHF repeater when the radio is initializing after power-up and when the DISPLAY TEST button is held down. The VHF AM and FM radio frequencies as well as ILS and TACAN channel are painted onto the physical selectors so their visibility is not affected by the electrical system. I don't know what you are referring to with regards to the intercom, as far as I know that does not have any displays?

Both work fine at the same time for me. Any errors in DCS.log?

With DCS-BIOS, you can also use another computer (such as a Raspberry Pi) to render the CDU display.