FSFIan

I get the impression that something is not right with your Export.lua setup. Do you get the spew of text Puma mentioned (seen at 03:10 in )? Are there any errors in dcs.log? Are you using another piece of software that relies on Export.lua (Helios and TacView are known to work)? What is the content of your Export.lua file?

I have never seen that before. It appears to be related to using applications based on an older version of cygwin (like the version of socat distributed with DCS-BIOS) on Windows 8.1. I have no idea what that message means and I don't know if it prevents socat from doing its job. Things you can try: make sure that any local firewall or antivirus that might interfere is temporarily disabled make sure that DCS is unpaused when testing (DCS-BIOS does not work in active pause mode) try ArturDCS's ComHandler program instead of connect-serial-port.cmd check if the works

There's CARGO IN ZONE, but it's bugged right now.

I agree with agrasyuk, for a 320x240 display I would look into something with more processing power and memory. The framebuffer for a 320x240 display will need at least 9600 bytes, which is too much for the 2048 bytes of RAM in the Arduino. This means you would probably not be able to use most of the display libraries out there. I don't want to claim that it is impossible to do with an Arduino, but it would require a lot of work and may still end up being too slow in the end. The SPI or 8-bit parallel interface is not a problem in itself, it is the low processing power of the Arduino that is the problem. It can't drive those interfaces fast enough.

The DCS warehouse system is not accessible by Lua. You can get the amount of stuff that was available at mission start from the warehouse table, but you cannot add new supplies or get the amount that are currently available (AFAIK there is no getAmmo() for airbases). A possible workaround is to implement such a system entirely in Lua. Keep track of the amount of ammo that leaves an airbase and returns to it (S_EVENT_TAKEOFF, S_EVENT_LAND, getAmmo()) and despawn any client that tries to cheat by leaving with more stuff than would be available. I plan to implement such a system for a mission of mine at some point in the future and have already confirmed that it is possible to do.

Yes, it is possible. This one uses DCS-BIOS, so it would only work with DCS. If you are using the Raspberry Pi 2, you may even get Helios running on it at some point, because you can run Windows 10 on it -- that may help with the "compatible with all sims" idea. You could also write software that runs on the DCS PC, listens for input over the network and simulates key presses.

Nothing outside of your computer is relevant for this, we are talking about connections to localhost here. This is really strange -- the export works (but only via UDP), everything that requires connecting to DCS does not. Is there anything in dcs.log? I think the only thing that can interfere here (beyond a seriously ****ed up windows install in general) is firewall or antivirus software. The DCS-BIOS code in question has been unchanged since v0.1.0.

rcmodels: it sounds to me like something is preventing DCS.exe from starting a network server (either TCP or UDP), so it cannot listen for commands via UDP or accept TCP connections. It can send data via UDP, so we know it is running. Try to temporarily deactivate any firewalls and/or add a firewall exception for DCS.exe (port 7778, TCP and UDP).

That's strange. Any firewall that could interfere? Does the work? (That uses TCP instead of UDP). Any errors in dcs.log? You could also try a modified version of connect-to-serial-port.cmd that uses TCP instead of UDP: REM Specify the number of the COM port your Arduino is connected to: set COMPORT=5 set /A TTYNUM=%COMPORT%-1 mode COM%COMPORT% BAUD=500000 PARITY=N DATA=8 STOP=1 TO=off DTR=on socat\socat -v TCP4:localhost:7778 /dev/ttyS%TTYNUM% pause

You are using the current development version, which may be broken at any time (and is undergoing some bigger changes right now). If you want a version that works and matches the documentation, use a release version.

You shouldn't have to add this. Which version of the Arduino library are you using?

Check the "mission planner" link in my sig :) It's not that nice because the map is an earlier version (and in EPSG:4326 projection, so circles become ellipses), but it works now. Eventually, I'd like to put similar functionality on dcsmap.a10c.de, but as you said, that is more work than adding some static data.

The streets are definitely off. To see this, go to dcsmap.a10c.de, open the JavaScript console (F12 should work in all major browsers), paste in the following and press enter: map.addLayer(new ol.layer.Tile({ source: new ol.source.OSM(), opacity: 0.5 })) This adds a half-transparent OpenStreetMap layer on top of the map. I verified that it's not a problem with the way I export data -- a Ka-50 landed on an intersection will display the same coordinates that the map shows. It looks like the terrain data (at least the coastlines) suffer from the same problem. I agree. That would be cool, but I feel like I am already in over my head with all this GIS stuff (it's fun to learn though). There is one other problem to solve. There are about 800,000 buildings in the current DCS: World map. Asking a browser to render them all does not work (that's why the building layer is raster data right now). I had to split the data up into several GeoJSON files to avoid crashing TileMill (maybe I should have set up a proper PostGIS database). I think this can be solved with vector tiles, I'll have to look into that. I would really like to know more about the format of those .rn3 files. I tried to reverse-engineer them once but did not get very far. (All I managed to do is change the color of the roads on the zoomed-out DCS Mission Editor overview map.) For this map, we could do the same thing that I assume was done for TacView and export it pixel by pixel using land.getHeight(). That would take some work on my export code and a few hours or days of computation, so I have not bothered with that so far. Finding a way to transform between DCS: World lat/lon and real-world lat/lon would be a much cleaner solution.

For some ideas I am toying with, I needed a decent map of DCS: World in a browser. Here's the result: dcsmap.a10c.de Drag to pan around Mousewheel or Shift+Drag to zoom Alt+Shift+Drag to rotate The approximate scale is given in the bottom-left corner. In the top-right corner, the position of the mouse pointer is displayed both with decimal degrees and in degrees/minutes/seconds format. The map shows roads, rivers, airports and buildings exported from DCS: World on top of real-world terrain data. This could be useful for VFR navigation (navigating by real-world maps can be difficult if you don't know whether that landmark you want to follow is represented in DCS or not). Power lines can be identified by lines of small buildings (the actual power poles). Future Development Due to the awesome OpenLayers 3 JavaScript library, it is relatively easy to add additional layers to the map, for example from .kml files. This could be used to display additional information on the map, such as airport frequencies, locations of navaids, etc. If you have any data sources or ideas, please post them here. Right now, this is a side project that I don't have much time to work on, but I will try to make small improvements from time to time. If you are a web developer and are interested to help out, please contact me.

It can be done with a character LCD (but most people choose a graphical one because there are no 24x10 character LCDs on the market). IIRC the controllers in those character displays have a way to define custom symbols. Google "hd44780 custom characters".

You can't. That's the point of this thread -- to tell ED that these functions are broken right now.

Have you read the first post in this thread? Have you watched the That shows you hands-on what DCS-BIOS can do. After that, have you checked the website and clicked the link to the latest version of the User Guide? If, after that, you have an actual question that can be answered, feel free to ask away. http://www.arduino.cc http://en.wikipedia.org/wiki/Arduino If you have to ask that question, you may be in the wrong subforum. Scroll through the various build threads on this forum. If, after that, your first reaction (before you have thought about money, time, or other constraints) is not "wow!", followed by "I want to have something like this, too", you are beyond help. If you are implying that to understand the existing documentation you need to know math, please show me the location where that documentation confronts you with any math at all. Sorry, but until you start asking actual questions, I can't help you. At this point, I can't tell if you are (a) trolling, (b) there is a language barrier, or © you didn't even try to understand the existing documentation and google things for yourself. If (a), go back under your bridge! If (b), instead of saying "there should be better/more documentation", ask actual questions so we know which ones the current docs don't answer. If ©, I can tell you now that DCS-BIOS may not be for you. If the Leo Bodnar boards are the helicopter ride to the top of the mountain, DCS-BIOS is the hiking trail that allows people without rock climbing experience who can't afford the helicopter to also reach the summit. But no matter how shallow we make the slopes on that path, you will still have to walk it yourself.

Right now it cannot. That was a deliberate design decision: If you join a "hot start" plane with the switch in the wrong position, you may for example inadvertently turn off your battery power switch. If the switches are not synced at startup, you can simply switch your physical battery power switch to ON after the fact -- from that point on, it is synced to the game. It would have added more complexity to the Arduino library. One of the design goals was to avoid complexity where feasible to make a system that can be explained to and understood by someone with no programming experience and a minimal background in electronics. If you know C++, you can program a modified version of the Arduino library that checks the exported switch state from DCS-BIOS and sends a command to correct it if it is out-of-sync with the real switch.

I don't know if it is possible with the trigger system (I assume not, but I am not familiar enough with triggers to say for sure). It should be possible with a custom Lua script. You can define an event handler to be notified when a weapon hits. AFAIK at that point you also get the information about who shot that weapon, so you can detect which unit killed your target. If it was an enemy aircraft, set a flag that causes the mission to fail.

Well, I have never heard of those, so DCS-BIOS has never heard of those, so that's a no. You would have to write a piece of software that translates between the two.

You need to invert the axis in the game. In the DCS options, go to "Axis Settings", select your axis and click the "Axis Tune" button. There should be a checkbox to invert it.

I appreciate the effort you put into this! Getting advice from someone who has actually built some of this is invaluable. One reason for starting DCS-BIOS was that I saw that the existing software approaches wouldn't scale up to a full simpit (that's why I created the binary export protocol). I had ruled out Helios at the time because it wasn't open source yet. I thought my simple "shared serial TX for export, I2C for import" approach would be (a) sufficient to scale the hardware side of things to a full pit and (b) reliability issues could be avoided with the "once you have problems, start a new I2C bus" approach and it would be justified by the decrease in costs. I now realize that this argument is fundamentally flawed, because it does not take intermittent errors into account. Also, RS-485 transceivers are a lot less expensive than I thought :) Let's come up with a "DCS-BIOS over half-duplex RS-485" standard. In that context, the TI Tiva C Connected Launchpad looks very interesting. With its Ethernet port and 8 UARTs, once you add RS-485 transceivers, it could easily connect up to eight RS-485 buses to DCS-BIOS. (I always wanted an excuse to buy one, now I have it.) Other less expensive candidates (when you only need to connecting a single RS-485 bus): Any Arduino with an Ethernet shield Arduino Mega or Leonardo (both have two UARTs, so one can talk to the PC and one can talk to the RS-485 bus) A RS-485 transceiver connected to a USB-to-serial converter, with suitable PC software (could you control the output enable on the transceiver with one of the extra RS-232 signals?)

Peter: thanks for sharing. You have a good point: just because the spec says 128 doesn't mean your specific hardware combination can do it. Reality trumps theory once again! I don't know if the USB-IF requires an actual test with 128 devices to be certified. (I assume you were using powered hubs all the way, so it couldn't have been a power issue.) You say UDP requires address management -- have you tried simply sending to the broadcast address and having your devices get an IP address through DHCP? In that case, the only address to manage is the static IP of your DCS computer. PS: I have released v0.2.4, which fixes the FLAPS_SWITCH in the A-10C and some indicator lights in the UH-1H.

The DCSBiosCOMHandler that ArturDCS made should take care of that. Another solution would be to throw a Raspberry Pi into the mix (or any other Linux machine) and script it so that any USB-to-serial converter that is plugged in will automatically be connected to DCS-BIOS. The maximum number of USB devices is 128 per USB controller (each hub also counts as a device). On a motherboard, I think there is typically one USB controller per one or two USB ports. Don't think of the USB solution as the final design -- think of it as a stopgap measure that allows you to start building and learning while a RS-485 based solution is being developed.

The advantage of the I2C solution is that it's the cheapest and the code for it exists now. The huge disadvantage is that nobody knows for sure how reliable it will be (i.e. how many boards / how much wire length one I2C bus can take in practice). The reliability will also depend on the quality and type of wiring (shielded Cat5 recommended) and the amount of electrical interference. A reliable solution that works right now is to use one USB connection per Arduino. Cost is about $3 per Arduino board (including the cost of cables and hubs). The current discussion aims to come up with a solution that is easier to manage and less expensive than the USB one, but just as reliable. The half-duplex RS-485 bus is a good candidate because it has been around for decades and there are inexpensive transceiver chips available, but to use it, new software will need to be written. Because it uses differential signaling, RS-485 is a lot more robust in the presence of electrical interference and can operate reliably over bus length that are many times longer than what you would encounter in a simpit. If you are new to the Arduino platform and programming, start out with one USB connection per Arduino board. Once someone comes up with an improved design for handling multiple panels, you can switch to that for new panels and possibly even adapt existing ones.