Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by FSFIan

  1. "ATMega2560-16AU" has nothing to do with the "ATMega16U2". Part numbers can be tricky. According to the datasheet pg. 410: "ATMega2560-16AU" = ATMega2560 processor rated for 16 MHz, packaging code AU (100-pin TQFP package) And yes, the CH340 variant is fine for use with DCS-BIOS.
  2. I don't know enough about the different commercial offerings and DIY variants of USB HID interface cards to recommend one over the other based on features. My recommendation would be any DIY solution (most of them seem to be Arduino-based). Overpro's 2x128-button firmware is a good start. The market for (clones of) Arduino boards is much larger than the one for joystick interface boards, so no commercial offering will come close to the price of a DIY solution. If you want to buy an Arduino Mega clone for use with overpro's firmware, make sure it actually uses an ATMega16U2 for the USB interface (and not the cheaper CH340 chip). Both ebay.com and AliExpress have offerings with an ATMega16U2, which is usually specified in the title. If an offer does not explicitly mention the ATMega16U2 chip, assume it has the CH340 and avoid it. The choice of converter chip does not matter for most Arduino projects, but using a Mega as a HID device involves reprogramming the ATMega16U2, so it won't work with the CH340 which is a dedicated USB-to-serial converter chip.
  3. It does not. You would have to add support for your aircraft to DCS-BIOS (which requires knowing the Lua programming language and familiarizing yourself with the Export.lua environment). The FLAMING_CLIFFS_AIRCRAFT constant is not used anywhere in DCS-BIOS yet. It was meant as a convenient way to define an export module that handles things that work the same way in all FC3 aircraft, but are not general enough to work in all the clickable cockpit aircraft as well (in which case it would go into the CommonData module, which is active for all aircraft and exports a few general things like the current position, altitude and heading). If you were targeting an aircraft with a clickable cockpit, I'd probably recommend DCS-BIOS, so you can properly interface toggle switches, multiposition switches and rotary encoders. For FC3 aircraft, even Export.lua cannot overcome the limitation of only having a "toggle" command available for most things, so adding a FC3 aircraft to DCS-BIOS does not give you any more power or flexibility.
  4. Yes, all variants need to be declared in AircraftList.lua, otherwise the CommonData module won't be activated for them.
  5. You can make one module that has everything that is shared between all models. That module would pass a list of several aircraft names to BIOS.protocol.setExportModuleAircrafts, e.g. BIOS.protocol.setExportModuleAircrafts({"342M", "342L", "342Mistral"}) For each of the different weapon panels, make another DCS-BIOS module that only applies to that aircraft and that has a base address that does not collide with anything in the "common" module. DCS-BIOS supports activating several "export modules" for one aircraft module. This functionality is already used to activate the MetadataStart, CommonData and MetadataEnd modules in all aircraft.
  6. Seems to work fine here. Are you by chance trying this in a situation where the switch refuses to engage when you click it in the virtual cockpit as well, such as in a cold and dark pit? Try the "Free Flight - Runway Start" mission and see if it works there. If it does not work in a hot start situation, let me know the version numbers of DCS, DCS-BIOS and the Arduino library (I am assuming that other switches work so we can rule out a general communication problem).
  7. That's what I meant by "monitor the switch state and use that to drive the coil". I wanted to point out that this is information about the switch position, not about whether the coil is on or off the switch being in the ON position does not always mean that the coil is energized (for example when the switch is being held in the ON position against the spring force that wants to push it back, and the computer has decided not to engage the coil because it thinks the switch should be off) ...so anything we build based on this limited information can only be an approximation to the real thing (although probably one that's close enough)
  8. The function is still there, it's in Util.lua now. Electrically held switches are implemented, but there is no separate output that tells you when to power the coil -- from the Export.lua viewpoint, the state of an electrically held switch looks like any other toggle switch. It just happens to be changed by the sim on its own from time to time. Most users will use normal toggle switches for these and can treat them like any other toggle switch (DcsBios::Switch2Pos). If you actually have an electrically held switch, you can monitor the switch state (check the control reference in Advanced view for the IntegerBuffer code examples). You'll have to figure out the exact logic yourself -- I have never done it because I don't have such a switch to test with. It might be sufficient to have a normal DcsBios::Switch2Pos monitoring the toggle switch and just turn the coil on whenever the switch in the virtual cockpit is in the on position. No matter what you do, there will be some edge cases that won't behave like the real thing. For example, when you push and hold the physical switch, the switch in the virtual cockpit will always be in the ON position and your coil will engage. Export.lua cannot tell the difference between the coil being on or off while the switch is being held in the on position, because the only info we get is the switch position (which is the only thing the rendering engine cares about).
  9. As a TM Warthog owner, I wouldn't say you get what you pay for. Don't get me wrong, the metal grip is amazing, but unfortunately they made the gimbal out of plastic... (google "stiction"). The hall sensors are really precise, but the stiction is starting to prevent me from making use of that precision. And after three years of moderate use, the paint is starting to come off at some of the edges on mine. I'll have to swap out the grease on my stick soon -- something I shouldn't have to do because on a stick this expensive, I'd expect better build quality. I guess I wouldn't mind having to do regular maintenance if they at least designed these things to be easy to disassemble, but from the pictures I have seen so far, this is not a thing I am looking forward to (lots of tiny wires I'll have to be careful not to break). If I were in the market for a high quality, reliable joystick today, I'd take the VKB products into serious consideration.
  10. The connections are correct. If you haven't already, you should include a jumper on the RO->RX connection so you can disconnect the MAX487 when uploading a new program to the Nano. Otherwise you'd have to unplug the entire Nano board whenever you want to upload new software. Whenever the MAX487 chip is connected and its RE pin is low, it will output a signal to the Arduino's RX pin. The on-board USB-to-serial converter will also always try to drive that pin. To resolve that conflict, the on-board converter is connected via a 1K series resistor, so it will lose whenever something else (with a direct connection to the RX pin) wants to drive that pin. This is exactly what you want in normal operation, but when uploading a program, you obviously want the USB-to-serial converter to win. The disconnect circuitry would have to be more complex if you also wanted to ensure that the MAX487 is disconnected from the RS-485 bus, but that won't be an issue. Even if the MAX487 puts garbage data on the bus, the logical protocol should recover within a few milliseconds (it resets after a timeout if it sees unexpected data). Any export data that was messed up as a result will be fixed by the auto-retransmit mechanism within about 10 seconds. The short-circuit protection in the transceiver chips will prevent damage if two devices try to drive the RS-485 bus at the same time.
  11. Ruahatu: I have no idea why it does not work on your system. The same code works here with current versions of DCS: World. I do not have Helios or TacView installed, but I don't see how that would make any difference. If you post your dcs.log I'll see if I spot any error messages that might be related.
  12. On the DCS-BIOS YouTube channel there is a step-by-step guide to making the interactive control reference work:
  13. Released DCS-BIOS v0.5.1. A-10C: update TACAN panel to work with DCS Please post comments in the DCS-BIOS Discussion Thread.
  14. I compared the Lua files, only the TACAN panel is affected. I'll try to build, test and release a fix on Sunday or Monday.
  15. Witchcraft cannot be used to edit mission files with current versions of DCS. It has been obsoleted by this experiment (which Pikey already linked to above), which probably still works. This has the advantage of never having to leave the mission editor and it supports Nevada as well. The long-term plan is to abandon Witchcraft altogether and integrate its Lua Console into DCS-BIOS 2.x.
  16. Looks like the TACAN control panel got its own device ID in those versions: devices["TACAN_CTRL_PANEL"] = counter()--74 -- TACAN AN/ARN-118 Control Panel I'll see if I can come up with a patch to DCS-BIOS that checks the DCS version before defining the TACAN switch data, so it works with both the stable and the beta version.
  17. That is correct. With the current version of DCS-BIOS, it is even limited to the specific aircraft it was built for. I'd like to fix that in the future, but it could take years until I get around to it. I should have been more specific by what I mean by "flexible" -- I meant that you can adapt it to almost anything you can wire up to an Arduino board, such as a specific type of dot matrix display that is used on the CMSP in the A-10C, or a small . @DavidOC: You can use any type of toggle switch. XPadder can probably handle things like "every time this switch changes state, press this hotkey to toggle the state in DCS". This is one way of getting around editing Lua files, but it has the disadvantage that the toggle switch can become out of sync with the simulation, so you have to make sure that all switches are in the correct position before you unpause the sim.
  18. First, you need to get the mechanical part out of the way: Choose a panel to start with. Get the electromechanical components you need -- switches, push buttons, rotary encoders, servos or stepper motors for any analog gauges, displays, LEDs, etc. Make a faceplate. Depending on your budget, available tools, and skills, there are many possible approaches -- a piece of cardboard with hastly scribbled on labels, a laminated printout of the panel, a plastic project box, engraving plastic with CNC-engraved lettering on top of an acrylic lightplate with LEDs behind it for backlighting... Mount your components on the faceplate If the faceplate does not come with its own box, plan and build a cockpit frame to mount your individual faceplates to Then there is the electronics part, which is mostly independent of the mechanical part. There are two generally different approaches to this. No matter which one you choose, you will also need a way to wire everything up, which usually means soldering. The first one is to build a USB joystick and map the functions through the DCS options menu. There are several interface boards available, for example Leo Bodnar boards, the GP-Wiz 40, or one of the free USB HID firmwares that target some sort of Arduino board (EasyJoy 32, MMJoy and others). You don't have to know anything about programming to do this. This method is limited to input devices that can be communicated in terms of buttons and axis, such as switches and potentiometers. You also need to be able to map the control through the DCS: World options menu, which sometimes requires manual changes to some Lua files that have to be reapplied after every DCS update. The second approach is to ignore the DCS options menu and use Export.lua instead. This is a facility of DCS: World that allows one to execute a program written in the Lua scripting language inside DCS. This program can imitate almost everything you can do with the mouse (i.e. manipulate switches and dials) and it also has access to a lot of information about the position of analog gauges, the state of indicator lights and the contents of some displays. Such a program can then communicate with other software or with custom-built hardware, which is often based on Arduino boards. DCS-BIOS is one of several projects that build on top of the Export.lua interface. If your project works within the limitations of the first approach, it is the fastest way to success. If your project requires the second approach anyway at some point (for example because you want to have physical indicator lights, analog gauges and displays instead of mounting a monitor behind your panel), you might as well start learning now and build everything with it, as it tends to be cheaper and more flexible. Disclaimer: I am the developer of DCS-BIOS, but I don't have enough experience with all the alternatives to make a good comparison. Take everything I said about the limitations of the USB joystick approach with a grain of salt, as my knowledge about that mostly comes from reading a few forum threads here and there, not from first-hand experience. This should give you a rough idea of what is involved in the construction of a simpit. Many details depend on your available space, time and money, the skills you have or are willing to learn, and how close to the original you require your simpit to look and feel. If you are going with DCS-BIOS, you will have to learn a bit about programming, but it should make the learning curve shallow enough that you can start without any prior experience. To get an idea of what is involved, grab an Arduino Nano for $3.32 and make its built-in LED into some indicator light from your virtual cockpit (e.g. with the MasterCaution example that comes with DCS-BIOS).
  19. What situation does the diamond appear in? Can you get it to appear on the ground (hot start on runway) or do you have to take off and/or fire countermeasures?
  20. What diamond character on which display are you referring to? Can you post a screenshot? The underlined character between the amount of flares and chaff on the CMSC, which indicates the position of the Master CMS Mode Select, is either ' ', 'x', 's', 'm', or 'a'.
  21. The code you posted works fine on my Mega 2560 board. (I only tested the LED output and did not bother to hook up a button.) PS: When posting code, use tags instead of
  22. Just {0, 1}, since the defineFloat parameter only ever accesses limits[1] and limits[2]. A quick look at the Util.lua file would have told you that. Use {-1, 1} if the cockpit argument can go negative, {0, 1} otherwise. ...and now your altimeter in the virtual cockpit is slightly off. You should not modify any file that comes with DCS. Interpretation of the value should be handled in the Arduino sketch.
  23. Yeah, DcsBios::Potentiometer is still the same naive get-the-example-done-in-five-minutes implementation that I originally crammed in. I'll take a look at the links Gadroc posted and add a version with supersampling, EWMA and rate-limiting. I might have to order some 10K pots to test with, the ones I have in my junk bin are all from old audio equipment with values between 80K and 170K and generate a lot of noise. On the other hand, if I can get the 80K pot to behave with some filtering, we'll know this is the way to go. Your description of the Signal Lights BRT - DIM switch sounds like it's time to write a DcsBios::RepeatingActionButton class as well.
  24. Danke für den Hinweis, da hab ich beim Fix für v0.2.7 wohl ein paar Stellen übersehen. Sollte in der neuen v0.2.9 jetzt repariert sein.
  • Create New...