FSFIan

coord.LLtoLO takes latitude and longitute in (decimal) degrees. The display in the DCS map shows degrees and (decimal) minutes. latitude of 42.24 degrees: 42 degrees and (60 * 0.24) = 14.400 minutes longitude of 42.66 degrees: 42 degrees and (60 * 0.66) = 39.600 minutes To convert the other way, from coordinates displayed in the DCS map to parameters for coord.LLtoLO: latitude of 42 degrees and 14.4 minutes: (42 + (14.4/60)) = 42.24 longitude of 42 degrees and 39.6 minutes: (42 + (39.6/60)) = 42.66

In single player, you can probably grab the switch position with some trigger conditions. I don't think there is a way to do it in a multiplayer mission.

Read up on the difference between vec2 and vec3. Vec2.x = Vec3.x Vec2.y = Vec3.z Ground unit spawning uses 2D coordinates, so x = coordinate.x, y = coordinate.z!

Just use the normal Potentiometer code snnippet from the reference docs. You turn the pot, the Arduino sends the new position to DCS, in-game brightness changes, the new in-game brightness gets sent to the Arduino, and the Arduino changes the physical brightness.

If you switch the control reference to "Advanced" view, you will find a code snippet to react to changes in CMSP brightness: void onCmspBrtChange(unsigned int newValue) { /* your code here */ } DcsBios::IntegerBuffer cmspBrtBuffer(0x10e6, 0xffff, 0, onCmspBrtChange); newValue will be between 0 (lowest brightness) and 65535 (max. brightness). Since your four brightness levels go from 3 (lowest) to 0 (highest), you could try something like this: void onCmspBrtChange(unsigned int newValue) { vfd_brightness(map(newValue, 0, 65535, 3, 0)); } DcsBios::IntegerBuffer cmspBrtBuffer(0x10e6, 0xffff, 0, onCmspBrtChange); PS: use tags to make code snippets in forum posts more readable.

value_up needs to be 0 instead of 1. Right now, you enable the tail wheel lock when the button is pressed, then enable it again when the button is released.

So far, not a single line of code has been written, so it's too early to even make wild guesses. That said, I just finished moving to a new apartment, which will probably have a positive effect on my overall productivity and, by extension, the pace of DCS-BIOS development. Those of you who have been following the project may have noticed that there was very little progress over the last year. The drop in productivity coincided with me moving into the place I just left, which didn't get much sunlight and got water damage a few month ago. I can't say for sure whether it was the humidity, lack of sunlight, a combination of those or something else entirely, but I never got much sleep while I stayed there. Judging from my experiences with the new place so far, it looks like that is improving a lot.

Listened to it yesterday, and enjoyed it as always. By the way, at least in the A-10C, even the TISL panel, which isn't used anymore even in the real aircraft, is clickable and animated :) Don't worry, I also hated listening to myself in Episode 11, although I was more annoyed by the frequent grammatical errors I made than the unfamiliar sound of my voice (I like to think I speak better English when I am more awake).

I see nothing obviously wrong with this code, so the error is probably in the part you removed to make it shorter. It's hard to give a definite answer without seeing the whole file, or at least the complete for loop. Right now, this would throw a syntax error due to the missing 'end' statement. And the indentation looks suspicious (drops back a level without closing the block). Are you sure _tabletarget contains more than one element? (Have you tried dumping it with mist.uitls.tableShow?) Also, while this shouldn't make the code incorrect, opening and closing the file for each small bit of info to add is inefficient. It's faster to open it once, make all your calls to write(), then close it when you are done, because then the data can get written to the hard drive in one big chunk instead of lots of small ones.

(Disclaimer: the following is my understanding of how things work after having added the A-10C and UH-1H to DCS-BIOS; other modules might do some things differently for all I know. The following applies to actions that will be bound to a keyboard key or joysick button. Axis assignments are a bit different, because the concept of pushing and releasing a button is not applicable.) It doesn't. The 3001 (which I'll call "command id" from now on) is used together with the cockpit_device_id ("device ID") to identify the control in the virtual cockpit. Each entry in the default.lua file specifies an action in the virtual cockpit that you can map to a button on a physical input device. It can -- but does not have to -- also specify a button on a physical input device that is mapped to this action in the default configuration. Any changes you make to the default configuration in the DCS settings dialog will be stored in the .diff.lua files. An entry in a .diff.lua file that does not apply to any action defined in default.lua will be ignored. Here's two example entries from the A-10C's keyboard\default.lua file. The first example (Landing Gear lever) specifies a default mapping of the "G" key, the second one (Anti-Skid switch) doesn't: {combos = {{key = 'G'}}, down = iCommandPlaneGear, name = _('Landing Gear Up/Down'), category = _('Landing gear panel')}, {down = iCommandPlaneLGPAntiSkid, name = _('Anti-Skid ON/OFF'), category = _('Landing gear panel')}, Here's a breakdown of the entries of a command definition: category -- the category in the DCS options dialog name -- the name/description of the action combos -- a Lua table specifying which keys / joystick buttons should be mapped by default down -- id of the command to trigger when the assigned key as been pushed down pressed -- id of the command to trigger repeatedly while the assigned key is held down up -- id of the command to trigger when the assigned key has been released value_down -- command argument to use for the "down" command value_up -- command argument to use for the "up" command cockpit_device_id -- used with the performClickableAction method to identify the virtual cockpit control (see below) DCS has two different ways to issue commands to the simulator. I will call them "LoSetCommand" and "performClickableAction", after the names of the Lua functions that are used when triggering them from Export.lua. The two approaches use different pieces of information to identify a control in the virtual cockpit. LoSetCommand method This is the simplest method. It requires a command id and an optional argument. I suspect that the argument is only used for axis assignments. The command ids for the LoSetCommand method are identified by constants whose names start with "iCommand". Most of these toggle their respective switch (e.g. the AntiSkid example above). When key bindings exist to set a switch to a specific position, they seem to get their own command ids instead of using the argument: {down = iCommandPlaneLGPLandLight, name = _('Landing Lights On'), category = _('Landing gear panel')}, {down = iCommandPlaneLGPLightsOff, name = _('Landing/Taxi Lights Off'), category = _('Landing gear panel')}, {down = iCommandPlaneLGPTaxiLight, name = _('Taxi Lights On'), category = _('Landing gear panel')}, performClickableAction method The performClickableAction method uses command ids and arguments just like the LoSetCommand method. The differences are that the argument is actually used, and the command ids are not globally unique. Instead, the command ids are only unique within a particular "cockpit device". There tends to be a separate cockpit device for each subsystem of an aircraft (e.g. electrical, weapons, avionics...) and each cockpit device handles all inputs related to its subsystem. For actions that use the performClickableAction method, you have to specify the cockpit_device_id parameter so DCS knows which cockpit device should handle the command. For a given cockpit device, each control in the virtual cockpit that it is responsible for gets a different command id, starting from 3001 and counting up. Different positions (of a toggle switch, for example) share the same command id; they are identified by different argument values instead. For two-position toggle switches, those argument values tend to be 0 for off and 1 for on. Three-position switches tend to use 0.0, 0.1 and 0.2 or -1, 0 and 1. Hope this helps.

In RS485 mode, sendDcsBiosMessage can return false if the transmit buffer is full (i.e. when the board wants to transmit a message before the previous one has been fetched by the bus master). Please post your complete sketch. The Teensy 3.1 should work fine in DEFAULT_SERIAL mode. If you are using IRQ_SERIAL or RS485 on the Teensy 3.1, it's not going to work (in fact, I'd be surprised that it compiled at all).

That joystick handle is a work of art!

Take a look at the output of the Lua function 'list_cockpit_params()'. At least in the A-10C, it has some information about the TGP. You might find something useful. Another interesting function is 'list_indication(number)'. If the info you are interested in is displayed anywhere in the cockpit as text, chances are you can grab it with this function. It expects one argument -- an integer ID. Try it with different values (starting at 0 I think) and see what you get. Sometimes it does not return any text if a particular instrument is turned off, so only stop trying new numbers when you didn't get anything a few times in a row. If the information is represented by some kind of animation in the virtual cockpit (an indicator light, a needle on an analog gauge, a drum counter, etc) it will be represented by a cockpit argument. For example, in the A-10C, cockpit argument 404 represents the state of the Master Caution Light. To get the value of a cockpit argument, use GetDevice(0):get_argument_value(number), e.g. local a10cMasterCautionLightValue = GetDevice(0):get_argument_value(404) The best way to tell which cockpit argument number corresponds to a specific value is to read through the Gazelle's clickabledata.lua file. If you are familiar with the airframe, you should be able to make an educated guess about which entries correspond to which gauges in the cockpit.

Your code will only work if the listener application is already running when you enter the cockpit, otherwise the TCP connection attempt will fail. There are three ways around this: retry the TCP connection, put the TCP server inside DCS, or send data using UDP which doesn't care whether someone receives it or not. For an example of the "retry TCP connection" approach, look at the DCS Witchcraft source code. For a TCP server example and a UDP example, you can look at the DCS-BIOS source code (in ProtocolIO.lua). "host", "port" and "c" are global variables. This isn't a problem as long as you are the only user of your export script, but if you ever intend to publish this for other people to use, you should have at most one global table that includes the name of your project and put everything else under that. You can also use file-local variables. Another thing you need to do if you want your export script to play well with others (e.g. Helios, TARS or DCS-BIOS) is to save the previous value of the callback functions and call them from your own callbacks. See BIOS.lua from the DCS-BIOS source code for an example. I am not sure what you are trying to achieve with the "craft == gazelleM or gazelleMin or gazelleL" condition. A short description of what you are trying to achieve would be helpful. (I can't tell whether you'll get the results you expect if I don't know what your expectations are :) ) PS: if you haven't already, you should set up DCS Witchcraft (link in my sig). It includes a Lua Console that lets you quickly try pieces of Lua code inside the running simulation. See the comments at the beginning of WitchcraftExport.lua for instructions on how to set this up for the Export.lua environment instead of the missions scripting one.

Modify the code on the ATMega2560 to read commands from the serial port to control the LEDs. Modify the code on the ATMega16U2 to accept commands via USB control transfers and output the commands over its serial port. This blog post should get you started. Download the LUFA release from the official website and take a look at the included examples as well. Use the HID4java library to send control transfers to the ATMega16U2.

The answer is "it depends", and the full discussion is probably off topic for this thread. Your post contains very little information about your situation (and the term "steering wheel" suggests that you might not even be talking about DCS: World), so I can only give a vague answer. If you have more questions about this, I suggest to start a new thread with more information about what you want to build, what you already have, and what your background in electronics and programming is. The first step to modify any system is to understand how the system works. So start with the blog post linked in the first post of this thread. Understand how the ATMega16U2 and the ATMega2560 controllers work together. Read and understand the code that is running on each controller. Consult the LUFA documentation to learn about USB device descriptors, control endpoints, interrupt endpoints, and other relevant USB internals. Then you would need to modify the code on the ATMega16U2 to accept data over USB (either via the existing HID device or by turning it into a compound device that presents both a HID and a serial port to the PC), and then make it send that data over the serial port to the ATMega328. ...or you could just grab an Arduino Nano clone for $3, plug it into a second USB port, and use its built-in USB-to-serial converter (i.e. handle all your outputs on a separate Arduino board). Finally, you need to write software on the host PC that grabs the data you want and sends it to the ATMega16U2 over USB (either using raw HID or a serial port).

iCommand stuff is done via LoSetCommand(iCommandID, argument) instead of GetDevice(deviceID):performClickableAction(command, argument). I can't check right now, but I assume the UI layer commands are handled by the same mechanism. To find out, look at the Lua files for the default keyboard bindings. Currently, DCS-BIOS does not support anything that's not in clickabledata.lua, since that's the only file I looked at when I added the A-10C and Huey modules. I plan to expand the scope to "everything that's possible to get to from Lua" in DCS-BIOS 2.0.

#define DCSBIOS_IRQ_SERIAL #include <AccelStepper.h> #include "DcsBios.h" struct StepperConfig { unsigned int maxSteps; unsigned int acceleration; unsigned int maxSpeed; }; class Vid29Stepper : public DcsBios::Int16Buffer { private: AccelStepper& stepper; StepperConfig& stepperConfig; unsigned int (*map_function)(unsigned int); unsigned char initState; public: Vid29Stepper(unsigned int address, AccelStepper& stepper, StepperConfig& stepperConfig, unsigned int (*map_function)(unsigned int)) : Int16Buffer(address), stepper(stepper), stepperConfig(stepperConfig), map_function(map_function), initState(0) { } virtual void loop() { if (initState == 0) { // not initialized yet stepper.setMaxSpeed(stepperConfig.maxSpeed); stepper.setAcceleration(stepperConfig.acceleration); stepper.moveTo(-((long)stepperConfig.maxSteps)); initState = 1; } if (initState == 1) { // zeroing stepper.run(); if (stepper.currentPosition() <= -((long)stepperConfig.maxSteps)) { stepper.setCurrentPosition(0); initState = 2; stepper.moveTo(stepperConfig.maxSteps/2); } } if (initState == 2) { // running normally if (hasUpdatedData()) { unsigned int newPosition = map_function(getData()); newPosition = constrain(newPosition, 0, stepperConfig.maxSteps); stepper.moveTo(newPosition); } stepper.run(); } } }; /* modify below this line */ /* define stepper parameters multiple Vid29Stepper instances can share the same StepperConfig object */ struct StepperConfig stepperConfig = { 1360, // maxSteps 1200, // maxSpeed 10000 // acceleration }; // define AccelStepper instance AccelStepper stepper(AccelStepper::DRIVER, 11, 10); // define Vid29Stepper class that uses the AccelStepper instance defined in the line above // +-- arbitrary name // | +-- Address of stepper data (from control reference) // | | +-- name of AccelStepper instance // v v v v-- StepperConfig struct instance Vid29Stepper vvi(0x106e, stepper, stepperConfig, [](unsigned int newValue) -> unsigned int { /* this function needs to map newValue to the correct number of steps */ return map(newValue, 0, 65535, 0, stepperConfig.maxSteps); }); void setup() { DcsBios::setup(); } void loop() { DcsBios::loop(); } The interesting lines to modify (without comments) are these: struct StepperConfig stepperConfig = { 1360, // maxSteps 1200, // maxSpeed 10000 // acceleration }; AccelStepper stepper(AccelStepper::DRIVER, 11, 10); Vid29Stepper vvi(0x106e, stepper, stepperConfig, [](unsigned int newValue) -> unsigned int { return map(newValue, 0, 65535, 0, stepperConfig.maxSteps); }); Here's what you'd need to add for a second stepper of the same model (i.e. same number of steps, max speed and acceleration): AccelStepper flapPosStepper(AccelStepper::DRIVER, 13, 12); Vid29Stepper flapPos(0x10a0, flapPosStepper, stepperConfig, [](unsigned int newValue) -> unsigned int { return map(newValue, 0, 65535, 0, stepperConfig.maxSteps); });

The map data was exported by calling land.getSurfaceType() for every single pixel in every single tile. Took about a week of running the export script whenever I was not otherwise using my desktop PC to get all of the zoom levels finished. Buildings were located with world.searchObjects(). I exported a list of all their anti-collision bounding boxes to a JSON file, then used some kind of GIS software (can't recall the name right now) to convert the vector data to bitmap tiles, as drawing a few thousand rectangles at once from vector data is too much for a browser to handle.

Warhog and I have created a Vid29Stepper class that handles most of the logic required to control the Vid29 / Switec X27.168 motors. When the sketch starts up, it will zero the stepper by driving it against its end-stop. After that, it will calculate a new stepper position and instruct the stepper to move there whenever new data comes in from DCS. It takes a reference to a configuration struct for general attributes of the stepper (max. speed, acceleration and total number of steps), the address of the DCS-BIOS output, a mapping function that needs to translate the value from DCS-BIOS into the appropriate number of steps, and a reference to an AccelStepper object (provided by the AccelStepper Arduino library) that handles low-level stepper control for us. IIRC we finished it to the point where it is working reliably. I don't have access to my DCS machine right now, but I'll post it when I get back there if Warhog doesn't read this earlier and beats me to it :) We don't have detailed documentation yet, but the comments in the sketch should contain enough information if you are already familiar with the general operation of stepper motors.

Hey Bluestream, if you want an improved map for your web-based UI, take a look at this thing I made a while ago: http://dcsmap.a10c.de It's using the excellent OpenLayers JavaScript library, but since the map data uses the same tile format as major map services (e.g. Google and Bing), it should be usable with most libraries that are meant to display a map on a web page. If I dig around a bit, I am sure I can find the code I used to export the data and make one for NTTR as well eventually. I'd love to get in touch with you on TS or Skype some time (PM me if you are interested). Two years ago, I spent a lot of time exploring the feasibility of something that went in a similar direction (dynamic air-to-ground campaign). In fact, that is what got me into DCS scripting in the first place (one of the first things I built was DCS Witchcraft). Then I started building DCS-BIOS and that took up all of my DCS tinkering time. A dynamic air-to-ground campaign is still something I desperately want to exist. While I can't commit a lot of time, I'll gladly contribute in whatever way I can.

There will also be a significant difference in price for otherwise identical switches depending on whether the manufacturer guarantees that a switch will survive for some tens of thousands or a million switching cycles.

Of course you can use DCS-BIOS for "input-only" boards as well. It includes almost any control in the cockpit of supported aircraft. The notable exception are things that you can't click with the mouse, such as the primary flight control axes or some HOTAS buttons. I'll probably add the HOTAS buttons at some point in the future when I get around to it.

This page on the Lua wiki should have a serialization function that fits your needs: http://lua-users.org/wiki/TableSerialization

Not as is. It assumes it is running on a Mega 2560 and expects those 64+ I/O pins (and their associated internal registers) to be there. As far as I know, you could use the same principle with the Uno (the Uno also uses an ATMega16U2 for the USB to serial conversion), but you would have to rewrite the sketch to only access I/O pins that are present on the Uno.