FSFIan

Aesthetics, mostly. I like the idea of a scope that reacts immediately to any change in settings, no menus to get through, dedicated mechanical switches for everything. I also want to have a second scope to use when I am at home over the weekend, even if it is not as full-featured as the one in my dorm room. I agree that there is nothing a sub-100€ used analog scope will do better than my DS1054Z, except maybe (the beginning of the video shows an analog scope, at 4:40 we see it displayed on a DS1074Z).

Wow, it's impressive what a little analog circuitry can do! How many stages does your filter have? Also, I think I need to get an analog scope (even though I just bought a Rigol DS1054Z). That screen looks beautiful!

If both Export.lua files are written in a way that plays nice with others (i.e. check for previous callback functions, save them in a variable, and call them from your own callback functions instead of simply redefining the callback function), this should work. The Export.lua file from DCSTAD looks like it does this, so I assume that the A-10C CDU thing does not play nice (I couldn't locate its Export.lua file to check since I don't speak whatever language that site is written in and Google Translate was no help either). Try putting the Export.lua code for the A-10C CDU first and the DCSTAD code after that. That way, the A-10C CDU does not overwrite any existing callbacks and the DCSTAD code will notice and remember the A-10C CDU callbacks and make sure they get called. In other words, you can have a single Export.lua file that does not play nice as long as it gets to go first.

Das Datasheet ist ein bisschen komplizierter zu lesen, weil die LED für Fernbedienungen gedacht sind, in denen die LEDs i.d.R. nur kurz gepulst werden. Daher gelten einige Angaben nur für eine bestimmte Betriebsdauer ("t_p = 20 ms" heißt, dass die Angabe nur die ersten 20 ms nach dem Einschalten gilt). Die Antworten zu dieser Frage auf electronics.stackexchange.com erklären, was man beachten muss. (Disclaimer: ich berechne sowas auch gerade zum ersten mal.) Relevante Werte aus dem Datasheet: Aus den "maximum ratings": (Max. ) forward current I_F = 100 mA (Max.) power dissipation = 200 mA Wärmewiderstand: 375 K/W (Achtung: gilt nur, wenn der Abstand zur Leiterplatte weniger als 1 cm ist, damit die Wärme über die Beinchen an die Leiterplatte abgegeben werden kann) Max. junction temperature: 100 °C Aus den "characteristics": Forward voltage (I_F = 100mA, t_p = 20ms): typ. 1.5V, max. 1.8V Wir wollen die LED dauerhaft betreiben. Erste Einschränkung: max. forward current = 100 mA. Bei der dafür maximal möglichen V_F von 1.8V würden in der LED 1.8V*100mA = 180 mA in Wärme umgesetzt. Das ist weniger als die max. power dissipation von 200 mA, also macht die uns keine Probleme. Bei 180 mA erwärmt sich die LED um 180mA*375K/W = 67.5 °C. Das ist 32.5° unter der max. junction temperature, die Raumtemperatur darf dann also nicht über 32.5 °C sein. Sollte kein Problem sein, besonders weil wir hier vom Worst Case (dem Einschaltzeitpunkt) ausgehen und die forward voltage (und damit die umgesetzte Leistung) noch etwas abnimmt, wenn sich die LED erwärmt. Da die LEDs einzeln platziert sind, müssen wir uns keine Sorgen machen, dass andere Schaltungskomponenten die Umgebungsluft der LED weiter aufheizen. Wir haben jetzt also festgestellt, dass wir die LED mit 100 mA dauerhaft betreiben können. Jetzt brauchen wir nur noch eine 100 mA Konstantstromquelle. Normalerweise baut man sich die mit dem Vorwiderstand aus seiner festen Versorgungsspannung. Problem: unsere Versorgnungsspannung ist variabel -- 3V bei vollen Batterien, ca. 2V bei fast leeren. Für 3V berechnet sich der Vorwiderstand für eine LED zu 12 Ohm, für 2V wären es nur noch 2 Ohm! Die Lösung mit dem LM317 funktioniert leider auch nicht -- ich hab nochmal ins Datasheet geschaut. Der LM317 hat bei 100 mA eine "dropout voltage" zwischen 1.5 und 2 V, d.h. die Ausgangsspannung ist entsprechend kleiner als die Eingangsspannung. Damit leuchtet die LED nicht mehr bei 3V Versorgungsspannung. Die einfachste Lösung ist, als Versorgungsspannung 5V zu nehmen (über USB-Kabel oder "drahtlos" vom Notfall-Handy-Ladegerät) und dann die LEDs parallel zu schalten (mit jeweils einem 33 ohm Vorwiderstand). Wenn bei der Gleichung ein negativer Widerstand rauskommt, heißt das, dass deine Versorgungsspannung für die geplante Anzahl LEDs in Reihe nicht ausreicht. Auch ein sehr kleiner Widerstandswert ist problematisch, da dann geringe Streuung der LED-Eigenschaften zu relativ hoher Schwankung des eingestellten Stroms führt. Außerdem ist (3V - (3*3V)) / 100 mA = -60 ohm, nicht -0,06 :)

After reading through some websites, I have learned that I won't have to pay annual fees to the trade association (because disability insurance is optional for the owner of a business) and the chamber of commerce (because I won't make more than 5200 €/yr). The next step is to contact the tax office and my health insurance to find out what paperwork is required. I'll get started with that after I have moved out of the dorms (they kick you out after six years, so I have to leave by September 31st) -- I don't want my mailing address to change in the middle of all this. There is a 410 Euro cutoff below which you are not required to file a tax return ("Einkommensteuererklärung"). But I don't know whether the income from my student job counts towards that or not and I suspect that even if you don't have to declare the amount below 410 Euro, you still have to tell the tax office that you are starting a business or something.

Ja, du brauchst einen Vorwiderstand. Eine Batterie kann mehrere Ampere liefern, deine LED möchte i.d.R. nur 20 Milliampere (steht im Datasheet). Die LED wird nicht unbedingt sofort durchbrennen, wenn du den Vorwiderstand weglässt, aber es wird ihre "Lebenszeit" deutlich verkürzen. Außerdem würden die Batterien sehr schnell leergezogen. Die Situation ohne Vorwiderstand kommt auch einem Kurzschluss sehr nahe, und Batterien mögen es gar nicht, kurzgeschlossen zu werden. Um den Wert eines Vorwiderstands zu berechnen, brauchst du die folgenden Werte: Versorgungsspannung Vcc Vorwärtsspannung V_f ("forward voltage") der LED (Datasheet) Den Vorwärtsstrom I_f ("continuous forward current"), für den die LED ausgelegt ist Wenn du kein Datasheet hast, kannst du die Werte auch messen. Der Widerstandswert berechnet sich dann so: R = (Vcc - V_f) / I_f Die Versorgungsspannung ist für zwei voll geladene AA-Batterien 2x 1.5V = 3V, für zwei Akkus wäre es 2x 1.2V = 2.4V. Dein Problem ist jetzt, dass die Spannung abnimmt, wenn sich die Batterien entladen. Um das Problem zu lösen, gibt es viele Möglichkeiten. Eine Möglichkeit wäre, sich mit einem LM317 und einem Widerstand eine Konstantstromquelle zu bauen (google "lm317 constant current circuit"). Eine andere Idee ist, die Spannung zuerst mit einem billigen Notfall-Handy-Ladegerät (2xAA auf USB 5V) auf einen festen Wert zu bringen (etwas ineffizienter, aber ein Bauteil weniger einzulöten und der Batteriehalter ist auch integriert). EDIT / PS: Wenn du mehr als eine LED versorgen willst, gibt es zwei Möglichkeiten: (1) Parallelschaltung, dann braucht jede LED einen eigenen Vorwiderstand (oder Konstantstromquelle)! (2) Reihenschaltung, dann berechnet sich der Vorwiderstand für n gleiche in Reihe geschaltete LEDs als R = (Vcc - (n*V_f)) / I_f. Das ist die bessere Option, weil so weniger Energie im Widerstand oder LM317 verheizt wird. PS2: Wenn du nicht gerade öfter mit Elektronik bastelst oder ein komplettes Simpit bauen willst, musst du auch keine 50 bis 100 Euro für eine Lötstation ausgeben, der ungeregelte 30 Watt-Kolben aus dem 12 € Starter-Set tut's auch. Das Ding benutze ich hier seit mehreren Jahren. Es kann kein bleifreies Lötzinn verarbeiten (nicht heiß genug) und ist nerviger zu benutzen als eine gute Lötstation (längere Anheizphase, das Kabel ist nicht so flexibel, etc), aber am Ende sind die Drähte genauso zusammengelötet, auch wenn's zwei Minuten länger gedauert hat.

In multiplayer, there are times when you are not in any aircraft, so GetDevice(0) returns nil because there is no main panel. (This may also apply to FC3 aircraft, I am not sure about that.) If LoGetSelfData() returns nil, there is no active aircraft. Otherwise, check LoGetSelfData()["Name"] to see if you are in an A-10C. Here's the relevant part of the DCS-BIOS source code.

To those asking for a donation button: I am looking into it. But I live in Germany, and we love our bureaucracy! I just called our equivalent of the IRS to ask them some questions. It's pretty clear that for tax purposes, money I get through a donation button counts as income (in that it is not a tax-deductible donation), because (a) helping others hook up electronics to their flight sims does not count as charity and (b) it's an exchange of money vs. goods (DCS-BIOS), it does not matter that you can also choose to exchange no money for the same thing. It's also pretty clear that any income I can expect through a donation button will be low enough so I won't end up having to pay taxes on it. Things get complicated because German law distinguishes between trades ("Gewerbe") and freelancers ("freie Berufe") and the law does not clearly specify whether programming counts as a trade or as freelancing. The tax office would make that decision after I'd file my first tax return based on individual circumstances. From what I gathered, my local tax office does not make that decision, so they could not give me any indication of whether making DCS-BIOS would count as a trade or as freelancing. If they declare it as a trade (and maybe even if it's freelancing, I am not clear on that yet), I am forced to become a member of the trade association ("Berufsgenossenschaft") and the chamber of industry and commerce ("Industrie- und Handelskammer"). These organisations, which trace their roots to the medieval guilds, have mandatory annual fees, which may or may not be waived for members in certain trades or who make profit below a certain threshold. In the worst case, I could end up having to pay more in member fees than I'd ever realistically make through donations. In the best case, there would be no members fees, and I'd have my own business which would mean being able to order from any of the major distributors of electronic components. Due to our strict consumer protection laws, the big distributors only deal with businesses (although one of them makes an exception for students). I need to gather more information. I'll keep you posted once I either set up a means to donate or decide it's definitely not worth the hassle.

Those instructions were written in 2011 and no longer apply to current versions of DCS: World. Follow the instructions linked in my signature, they work with the current version. Before you do that, you will have to restore the indicator Lua files you already replaced with out-of-date versions to original condition.

Dimensions of the center viewport and the resolution specified in the DCS options are two different things. The fact that the menu text appears on the bottom monitor (and that the whole monitor gets a black background) shows that the vertical resolution is set correctly. I am running two monitors (top monitor 1920x1200, bottom one has 1920x1080) and this is my monitor setup file (in the DCS options, I have to set a resolution of 1920x2280): _ = function(p) return p; end; name = _('More fish!'); Description = 'Left and Right MFCD positioned under Helios.' Viewports = { Center = { x = 0; y = 0; width = 1920; height = 1200; viewDx = 0; viewDy = 0; aspect = 1920/1200; } } LEFT_MFCD = { x = 0; y = 1200 + 135; width = 1080; height = 810; } RIGHT_MFCD = { x = 1920 - 810; y = 1200; width = 810; height = 1080; } ED_A10C_RIGHT_MFCD = { x = 1412; y = 1327; width = 433; height = 433; } ED_A10C_LEFT_MFCD = { x = 73; y = 1326; width = 433; height = 433; } ED_A10C_CLOCK = { x = 474; y = 2024; width = 133; height = 133; } ED_A10C_CMSC = { x = 858; y = 1341; width = 175; height = 49; } ED_A10C_RWR = { x = 599; y = 1360; width = 179; height = 179; } ED_A10C_CMSP = { x = 1074; y = 1393; width = 267; height = 60; } UIMainView = Viewports.Center

You probably need to grab the Export.lua file that Helios wrote to your DCS installation directory and move it to the %USERPROFILE%\Saved Games\DCS\Scripts folder (you may have to create the "Scripts" folder). The location of Export.lua changed a while ago (I think around 1.2.12-ish?).

You mean after editing and saving a mission with witchcraft that already had client aircraft in it? Could be a bug with how the mission data is passed around between Lua and JavaScript (the javascript side cannot deal with tables that have both numeric and string keys, so the Lua functions "witchcraft.luaMissionToJSONable" and "witchcraft.JSONableMissionToLua" deal with an edge case -- maybe I missed one). Or maybe my code breaks the mission data structure in some other way. I probably won't fix this, as EDGE is right around the corner and will include a proper preview mode in the mission editor. And although I do look forward to focusing on mission scripting again in the future, nowadays all of my DCS hacking time is spent on DCS-BIOS.

Go for a single graphics card. Two reasons: (a) I am not aware of any modern graphics card that does not support at least two monitors (most support three, some even up to six) (b) According to my understanding of how DCS and DirectX work, if you combine a more powerful GPU with a less powerful one and export the MFCDs to a monitor connected to your less powerful GPU, the more powerful GPU will do all the work and then you have an extra step of copying the MFCD image from the video memory of one card to the video memory of the other card, so you will not gain performance with two cards compared to one

Try swapping the coordinates of your left MFCD and center viewport: _ = function(p) return p; end; name = _('4 monitors in row'); Description = '4 monitor configuration' Viewports = { Center = { x = 5760; y = 0; width = 400; height = 400; viewDx = 0; viewDy = 0; aspect = 5.333333333333; } } LEFT_MFCD = { x = 0; y = 0; width = 5760; height = 1080; } RIGHT_MFCD = { x = 5760 + 1680 - 400; y = 0; width = 400; height = 400; } GUI = { x = 5760; y = 0; width = 1680; height = 1050; } UIMainView = GUI If the left MFCD appears on the top monitor but the 3D view is gone, it's something with your graphics setup, i.e. DCS somehow has problems placing output on your other screen or the coordinates on your monitor arrangement do not work like you think they do. If the 3D view appears where you currently expect the left MFCD to show up but the left MFCD does not appear on the top monitor, your MonitorSetup.lua is fine but you have probably messed up your MFCD's Lua files. Reinstall DCS and try again.

Note: I am obviously not an ED developer, so the following is just my mental model of how DCS works internally. There are two different types of indicators in DCS. The first type is computed as an image and then displayed on a flat surface somewhere in the cockpit (i.e. drawn to a texture). In the A-10C, examples include the MFCDs, the CMSP and RWR display, and the digital clock. Using the MonitorSetup.lua file, DCS: World can be instructed to display a copy of those indicators on an external monitor. The MFCDs are supported out of the box, to get other indicators working requires editing Lua files. The second type of indicators are those that are actually part of the 3D cockpit. This applies to most aircraft instruments. DCS: World computes one or more numeric values ("cockpit arguments"), which are tied to parameters of the virtual cockpit's 3D model, such as the angle of rotation of a pointer in an analog gauge. Technically, I guess you could get DCS: World to display a copy on an external monitor through MonitorSetup.lua by defining separate camera and positioning it in front of that instrument, but that would be a pretty big performance hit. Instead, we can take advantage of the fact that DCS: World allows us to access the cockpit arguments by writing an Export.lua file (for FC3 aircraft, only basic info like airspeed, heading and altitude is available), which can send these values to another piece of software (Helios, iControl DCS, ...) that uses the value to draw a 2D image of the gauge. You should take a look at Helios. It has built-in support for the A-10C and Black Shark 2 modules. For some other aircraft modules, I have seen that people have posted modified Export.lua files that can make them work (P-51D, maybe others), but I have not taken a closer look at those.

You are right, the polarity is reversed here. Your circuit uses a pull-down resistor to make the Arduino pin default to logic low and your push button connects it to +5V to make it logic high. It should be the other way around -- have a pull-up resistor to +5V to make the Arduino pin default to logic high and have the push button connect it to ground. Why are we doing it this way (obviously you can write the software to work with either arrangement)? Because the AVR chip has the pull-up resistor already built in, so you don't need to add it as separate component. All you need is the DcsBios::Switch2Pos line and your push button between the Arduino pin and ground. By the way, the LED on the button is lacking a current limiting resistor.

Other than the dev blog post on Export.lua and the mission scripting documentation, I am not aware of any documentation from ED about "lua files for modders" (besides the occasional few comments sprinkled throughout the Lua files themselves). However, as far as I know the post linked in my signature, How to export CMSP, RWR, etc. through MonitorSetup.lua, is still up-to-date.

To get that switch to work, all you need is this line (and the rest of the TemplateSketch): // DCS: MiG-21bis DcsBios::Switch2Pos engStart("ENG_START", BUTTON1); You do not need to write any calls to sendDcsBiosMessage() unless you are dealing with something that the Arduino library does not support out of the box, like a button matrix or shift register. (People in the future (a few months from now): this information applies to the v0.1.x of the Arduino library. If by the time you read this v0.2 or later is out, there will be a better abstraction for those cases and the behavior of sendDcsBiosMessage() will have changed slightly.)

Yes. It is already possible. You are programming an Arduino, so you are free to do whatever you want with the values you get. You will need to write the code to draw a fuel panel to the display. The more interesting question is: is an Arduino powerful enough to write a reasonable number of frames per second to your display or do you need something faster like one of those ARM-powered TI Launchpads or a Raspberry Pi?

If the delay is caused by missed incoming data, the next version of the Arduino library (coming soon, but probably not for the next two months) may improve things here with interrupt-based communication. For now, you can try to vastly increase the default 64-byte serial receive buffer by editing the Arduino core files (Google should find a howto).

Step 1: Note the tooltip text of the switch you want, in this case "Weapon mode switch - Burst Length" Step 2: Locate your aircraft's clickabledata.lua file and open it in a text editor (I use Notepad++). It is located in C:\Program Files\Eagle Dynamics\DCS World\Mods\aircraft\Ka-50\Cockpit\Scripts. Step 3: Search for the tooltip text to find your switch, it will look something like this: elements["SR-PTR"]= {class = {class_type.TUMB,class_type.TUMB}, hint = LOCALIZE("Weapon mode switch - Burst Length"), device = devices.WEAP_INTERFACE, action = {device_commands.Button_4,device_commands.Button_4} , stop_action = {}, arg = {400,400}, arg_value = {-direction*0.1,direction*0.1}, arg_lim = {{0.0, 0.2},{0.0, 0.2}}, use_OBB = true, updatable = true} Note "arg_lim" from 0.0 to 0.2, and "arg_value" has has a 0.1 multiplier. You don't have to understand every detail of what is going on here (I don't), but it is enough to guess that the values you want are 0.0, 0.1 and 0.2 (0.0 to 0.2 in 0.1 steps). Three-position buttons use 0.0, 0.1 and 0.2 -- except when they don't and it's -1, 0 and 1 instead: elements["PTR_HUD-TMB-SETKA02"] = { class = {class_type.TUMB, class_type.TUMB}, hint = LOCALIZE("HUD Modes Reticle/Night/Day"), device = devices.HUD, action = {device_commands.Button_2, device_commands.Button_2}, arg = {9, 9}, arg_value = {-direction*1.0, direction*1.0}, arg_lim = {{-1,1}, {-1,1}} } You get the idea. So far, we have established that the values for the switch positions are 0.0, 0.1 and 0.2. We also need a command number. In clickabledata.lua, those are usually written as "device_commands.Button_X", where "Button_X" means 3000+X. For our switch, we want command number 3004. We also need to know the device ID to send the command to. Note "device = devices.WEAP_INTERFACE". In your aircraft's "devices.lua" file, you can learn that WEAP_INTERFACE is device ID 12. We have gathered the following information: Device ID: 12 Command: 3004 Argument values: 0.0, 0.1, 0.2 Now we can write entries to add to the Ka-50's "default.lua" input config file (C:\Program Files\Eagle Dynamics\DCS World\Mods\aircraft\Ka-50\Input\ka-50\default.lua): {down = 3004, value_down = 0.2, up = 3004, value_up = 0.1, cockpit_device_id = 12, name = " Weapon mode switch center/up", category = "Ins Weapons Status and Control Panel PUI-800"}, {down = 3004, value_down = 0.0, up = 3004, value_up = 0.1, cockpit_device_id = 12, name = " Weapon mode switch down/center", category = "Ins Weapons Status and Control Panel PUI-800"}, As suggested by Yurgon, I have prepended a space to the name to make the command show up at the top of the list. The first entry is for the "up" direction of the Warthog Throttle's toggle switch (button 27): when it is pushed down (the switch is moved up), we send command 3004 with an argument of 0.2 to device 12. When it is released (switch back to center), we send command 3004 with an argument of 0.1 to device 12. The second entry is for the "down" direction of the Warhog Throttle's toggle switch (button 28): when it is pushed down (the switch is moved down), we send command 3004 with an argument of 0.0 to device 12. When it is released (switch back to center), we send command 3004 with an argument of 0.1 to device 12. After you have edited default.lua, save the file, restart DCS and assign your key bindings in the options. This should work for any aircraft with a clickable cockpit. Note that sometimes, the "devices.lua" file can be tricky. For example, here's the start of the "devices.lua" file for the UH-1H: local count = 0 local function counter() count = count + 1 return count end -------DEVICE ID------- devices = {} -- moved forward for correct initialization of another devices -- do not changed folowing sequence for sim devices["ELEC_INTERFACE"] = counter() -- 1 devices["FUELSYS_INTERFACE"] = counter() -- 2 devices["ENGINE_INTERFACE"] = counter() -- 3 devices["HYDRO_SYS_INTERFACE"] = counter() -- 4 devices["ADI_PILOT"] = counter() -- 6 devices["ADI_OPERATOR"] = counter() -- 7 devices["NAVLIGHT_SYSTEM"] = counter() -- 8 devices["SOUND_SYSTEM"] = counter() -- 9 devices["WEAPON_SYS"] = counter() -- 10 Note that device IDs are not assigned directly. Instead, the file defines a function called "counter" that returns the next higher value whenever it is called, so the first device (ELEC_INTERFACE) gets 1, FUELSYS_INTERFACE gets 2, etc. Also note the helpful comments that have been provided. Can you spot the trap? (What is the device ID for SOUND_SYSTEM?)

Because there hasn't been a new release for quite a while, here's a quick update. I am working on the next version of the DCS-BIOS Arduino library, which involves rewriting the majority of it. It will be released as v0.2.0 when it is done. The following new features are planned for v0.2.x: (1) RS-485 support. You will be able to turn an Arduino Mega into a hub that connects up to three RS-485 buses to the PC. Because of processing time limitations, this board will be dedicated to the hub function and you won't be able to use its remaining I/O pins to connect panels (I may add the ability to use those for inputs only at a later date). (2) Support for I/O expanders, shift registers, etc. All classes that accept pin numbers (Switch2Pos, LED, etc.) will actually be class templates that accept a template parameter that allows you to supply your own versions of pinMode(), digitalRead(), digitalWrite() and analogRead(). With that feature, it will get easier to use I/O pins on I2C port expanders or shift registers. (3) Standardization of the serial communication speed at 250000 bps. (4) Interrupt-driven communication handling. Currently, defining lots of controls or having several outputs that take a while to update (such as LCDs) can cause the serial receive buffer to fill up. That causes incoming data to be lost, which results in no updates at all or garbage data being displayed. The current workaround is to reduce the serial communication speed and hope for the best. In v0.2.x of the library, all communication will be handled in interrupt service routines, so that a long display update can be interrupted to process a new incoming byte. That should guarantee reliable operation at 250000 bps. (1), (2) and (3) are mostly implemented and I have a pretty good idea of the algorithms and data structures I want to use to implement (4) now. I won't name any release date, because I don't want to make promises I can't keep. It's very hard for me to predict progress because the amount of time I have to work on this varies a lot. And then there's varying levels of productivity -- sometimes I spend an hour trying and failing to implement something, and then there are days where suddenly everything is going well and 12 hours later I have ignored everything else and bidirectional communication over RS-485 is working. However, those of you who are interested in the RS-485 solution might want to order a bunch of MAX487 chips and one Arduino Mega now. You will need up to three MAX487 chips for the Mega acting as the hub and one per slave device. If I understand this correctly, as long as the cable length is less than 10 meter, up to 126 MAX487 transceivers could be used on each RS-485 bus. This relies on the internal fail-safe biasing of the transceivers. For longer cable length and/or better noise margin, termination and biasing resistors can be added. Given Cat5 cable (characteristic impedance of 100 ohm) and selecting R_T1 = 100 ohm, R_T2 = 110 ohm and R_FS = 470 ohm would result in a noise margin of 50 mV and permit up to 25 MAX487 transceivers per bus (for a total of 25*3-3 = 72 slave devices connected to one Arduino Mega). After v0.2.0 of the Arduino library is done, the next step will be to adapt the documentation and to finish a work-in-progress tool that can help with calibrating stepper and servo motors (i.e. finding out how to translate the value we get from DCS to the number of steps or pulse width in microseconds).

Good job! A few suggestions: a) calling map(lEngFuelFlowValue, 0, 5000, 0, 5000) is a no-op: it won't change the value at all. The actual scaling happens in your print statement instead, where you divide by 1.3, so you end up with values from 0 to 50000. You can do this instead for the same result: void onDcsBiosWrite(unsigned int address, unsigned int value) { if (address == 0x10ae) { unsigned int lEngFuelFlowValue = (value & 0xffff) >> 0; unsigned int valueL = map(lEngFuelFlowValue, 0, 65535, 0, 50000); lcd.setCursor(3,1); lcd.print(valueL); lcd.setCursor(7,1); lcd.write(" "); if (valueL <= 9999) { lcd.setCursor(6,1); lcd.write(" "); } else { lcd.setCursor(7,1); lcd.write(" "); } } } b) The gauge in the A-10C pit actually reads "PPH x 100", so an indication of "50" on the scale would be 5000, not 50000 PPH. To get that, use map(lEngFuelFlowValue, 0, 65535, 0, 5000); instead. c) There is a more convenient way to print the number right-aligned: void onDcsBiosWrite(unsigned int address, unsigned int value) { if (address == 0x10ae) { unsigned int lEngFuelFlowValue = (value & 0xffff) >> 0; unsigned int valueL = map(lEngFuelFlowValue, 0, 65535, 0, 50000); char buffer[6]; // the size of the buffer must be one more than the largest number of digits we expect ("50000" has 5 digits) snprintf(buffer, sizeof(buffer), "%5d", valueL); // "%5d" means to pad with spaces until we have 5 characters. If you want leading zeroes instead, you can use "%05d". lcd.setCursor(7,1); lcd.print(buffer); } } EDIT: Here's a version for both values on one display, using values from 0 to 5000 (also note that I didn't even try to compile any code in this post): void onDcsBiosWrite(unsigned int address, unsigned int value) { if (address == 0x10ae) { unsigned int lEngFuelFlowValue = (value & 0xffff) >> 0; unsigned int valueL = map(lEngFuelFlowValue, 0, 65535, 0, 5000); char buffer[5]; snprintf(buffer, sizeof(buffer), "%4d", valueL); lcd.setCursor(0,1); lcd.print(buffer); } if (address == 0x10b0) { unsigned int rEngFuelFlowValue = (value & 0xffff) >> 0; unsigned int valueR = map(rEngFuelFlowValue, 0, 65535, 0, 5000); char buffer[5]; snprintf(buffer, sizeof(buffer), "%4d", valueR); lcd.setCursor(6,1); lcd.print(buffer); } }

Take a close look at 1:14. The pointer has completed several successful rotations at the same speed before, but in that one the motor stutters and is visibly missing steps. Check the wiring. Make sure that all connections are soldered securely and that no wire is longer than it needs to be. Make sure the Arduino has a good power supply (verify it is between 4.75 and 5.25 V, some USB ports provide less!) and that you have decoupling capacitors. See if you can provoke the error by wiggling the wires around. You can also try to move the needle so it is glued on in the middle, to rule out problems with an unbalanced load.

Yes. You can program your Arduino to do whatever you want it to with the data that it receives. You will probably have to write some code to convert the angle that we get out of DCS to the value you would read from the instrument's scale, though. For some instruments, this will be as easy as calling the map() function that is supplied with the Arduino IDE. Other instuments require a bit more complex code because the angle of the pointer is not proportional to the numeric value or because you have to evaluate multiple export values to get the numeric value (e.g. the altitude as displayed on the altimeter).