FSFIan

I agree that you want a dedicated microcontroller to handle the waveform generation. Any other significant time-sensitive processing you make that controller do (like, say, listening and responding to the RS-485 bus) will increase the worst-case interrupt latency for the waveform code, which reduces the signal quality you are able to guarantee. Did you choose the PIC for any specific hardware features or is that just the microcontroller architecture that you are most familiar with? If we can port the firmware to an ATMega328 later, it would make it possible for someone to replicate the project without having to build a PIC programmer. The Arduino IDE comes with an ArduinoISP sketch that can turn any Arduino board into an in-circuit programmer for ATMega chips.

Great project, I will be following this. I had started to read up on synchro motors because WarHog plans to use a real ADI and HSI, but analog stuff still confuses me. Glad to see this handled by someone who knows what he is doing! For the use case of driving it from an Arduino board, a version of the firmware with a SPI or I2C interface would come in handy so the Arduino can use its UART to talk to the PC. That would make integration into an existing RS-485 setup that uses Helios or DCS-BIOS easier.

Correct, the role of limiting the acceleration in the Arduino side is mostly to protect the motor (because to drive it at maximum speed safely -- without negatively affecting the usable lifetime of the part -- may require adhering to some maximum acceleration). Keep in mind that while DCS simulates the acceleration, we don't get that data from DCS. Instead, we get the current pointer position (but no information about whether it is speeding up or slowing down). In an ideal case, we would get 30 updates per second from DCS, which would be 33 ms apart. In the real world, at least on my PC that barely manages 27 FPS, the updates can be 33 to 80 ms apart. I assume that the Arduino-side acceleration profile also helps to mitigate the negative influence of this non-constant sample rate.

A rotary encoder has two outputs that go 00 -> 01 -> 11 -> 10 -> 00... when you rotate in one direction and 00 -> 10 -> 11 -> 01 -> 00... in the other direction. I don't have any experience with the boards or that software, but I assume that this setting sets how many of these steps the encoder produces if you move it by one detent. The only value I have seen so far (granted, a sample size of two different encoder types is pretty small :P) is 1:4 (so when the encoder is resting in a detent position, the output is always the same no matter what detent it is in). Start with that and if you have to move it by two or four detents to get an effect, switch the setting to 1:2 or 1:1 respectively.

Yes, each different Arduino will need a separate copy of the batch file. You can also try ArthurDCS's ComHandler program, although with my Mega I had the problem that the board would reset when the program opened the serial port and then would be stuck in the bootloader because it was immediately bombarded with data -- workaround: pause the simulation when you click the button to connect the serial port. The official solution to connect multiple board will be an RS-485 bus. I got the first prototype working about two hours ago, but error handling still needs a significant amount of work. On the new machine, the boards will probably get assigned different COM port numbers. You can change the COM port that is assigned to a serial interface in the Windows device manager, but whether that change persists depends on whether Windows can recognize the device again later (a lot of Arduino boards and serial-to-USB adapters don't bother to specify a unique serial number).

That should be easy enough to add if you copy the SwitchMultiPos class and modify the readState() method to read from an analog pin instead. DCS-BIOS supports anything that you can get your Arduino board to talk to. The "import protocol" is documented in the Developer Guide -- in the Arduino library, it boils down to calling sendDcsBiosMessage("CONTROL_INDENTIFIER", "ARGUMENT"). The accepted arguments depend on what input interfaces your control supports (those are listed in the control reference docs in "advanced view"). For multiposition switches, the argument is "0", "1", "2", etc. to select a specific position.

When you are talking about total desynchronization, do you mean that the physical pointer starts to lag behind the sim but eventually catches up again if you resume level flight or does it stay out of sync until you reset the Arduino? If it does catch up again, the software does what it is supposed to do and you simply need to increase the maximum stepper speed (change the number in the stepper.setMaxSpeed(1000) line). If it does not catch up again, it's either a hardware or a software problem. In that case, please decrease the max. speed until the problem happens at slow descents / climbs that have worked flawlessly before and see if you get a permanent desync or if it catches up again given enough time. If the pointer catches up eventually at lower max. speed values but goes out of sync when you increase that value, the most likely cause is that your pointer is either too heavy for the stepper or mounted in a way that can slip during acceleration.

The EGI, STR PT and ANCHR buttons have a double triangle when lit up, the others have a single one: The symbol is always the same for each button as far as I know. Internally each of these lights is defined just like any other indicator light in the A-10C's Lua files. If there were a case where the symbol was different, I'd be very surprised (and would have to fix DCS-BIOS).

I am slightly confused by your question -- the difference is obvious (communication is wireless, but your panel still needs power) and whether that is an advantage depends on your individual situation, so you are in a much better position to answer that question than anyone else. If one of your panels happens to be in a location where power is available (i.e. from a wall socket next to it) but routing a cable from your PC to it is inconvenient for some reason (maybe you are building a door into your simpit?), then a wireless solution might be advantageous. Otherwise, I don't think it would make any noticeable difference, assuming you are not in an area where the wifi frequency spectrum is very congested or your wifi module is designed to sacrifice latency for low energy consumption.

It's definitely not any cockpit argument. I played around with the Lua Console: capturing all argument values (up to an arbitrary max. argument number of 12000), moving the speedbrake, then displaying all arg values that changed and eliminating irrelevant "jittering" ones like the enigine instruments. Kind of makes sense, because the value is only needed to correctly render the external model. There is nothing in the A-10C cockpit that depends on that value. This may be something that ED has to help you with.

This should be easy enough to adapt: http://forums.eagle.ru/showthread.php?p=2312247#post2312247 EDIT: You should also modify your Export.lua to play nice with others. Your current version simply replaces any pre-existing callback functions, so it will break anything that was loaded before it. Before defining a callback function such as LuaExportStart, you need to save a reference to the old LuaExportStart and then call it from your callback function: local prevLuaExportStart = LuaExportStart function LuaExportStart() if prevLuaExportStart then prevLuaExportStart() end -- your code here end

Gremlin: with 128+ I/O pins per Arduino, did you run into any performance problems? If so, a future version of the Arduino library should improve things (I am implementing interrupt-based communication as part of the RS-485 support). If you run all 128 wires that go to a single Arduino's port expanders to one central location, I2C will be a reliable solution. If you go with one I2C port expander per panel so they are spread out and the total length of your I2C bus increases, you may run into problems at some point, and it is very hard to predict where exactly that point is. Here's a quick back-of-the-envelope calculation: Cost of a MCP23016: about $1.05, that's $0.06 per I/O pin Cost of a Pro Mini and MAX487 chip: $2.08 + $0.40 = $2.48, that's $0.14 per useable I/O pin So going RS-485 all the way is roughly twice as expensive as the I2C solution (not including the cost of an Arduino Mega for the bus master). There are two main reasons I am going with RS-485 over I2C as the "officially recommended" solution: It is more modular: you can remove a panel and test it in isolation. Each panel is a self-contained unit. That would make it possible to offer DCS-BIOS compatible panels for sale that would almost be "plug and play" (you'd still have to assign them a unique address somehow). Any solution I endorse will result in questions from beginners when something does not work. RS-485 has a much lower risk to develop intermittent, hard-to-debug issues compared to I2C (as Mike Powell aptly put it, "it can cover a multitude of sins"). Both I2C and RS-485 are viable options. Know the trade-offs and go with what works best in your situation. The big disadvantage of RS-485 is that the software is not done yet, but I finally have everything I need to work on it. Now the heat has to go away to get my brain working again... Note: You can mix-and-match RS-485 and I2C There are also I2C A/D converters available if you need analog inputs

If you want the inputs to work with any DCS module, you'll want to make them into a USB joystick (MMjoy, Leo Bodnar board or similar) and configure through the DCS: World options. For the outputs, there is no option that will work with all DCS modules. If you don't want to roll your own Export.lua file, you will have to choose either Helios (and the EOS protocol) or DCS-BIOS. I'd recommend DCS-BIOS because the process of adding support for new aircraft modules is documented better (but I am obviously biased). In theory, because DCS-BIOS exports the name of the currently used aircraft, it is possible to write an Arduino sketch that automatically changes its configuration when you switch to another aircraft. The DCS-BIOS Arduino library does not support this however (because it is designed to be as simple as possible), so you'd have to roll your own. But for LED outputs, I think you could simply define two DcsBios::LED instances that refer to the same Arduino pin. The state of the output pin will only be updated when new data is arriving. Because DCS-BIOS uses different export address ranges for different aircraft and only sends data for the currently active aircraft, a DcsBios::LED instance that refers to an export address outside of the current aircraft's address space will never get any data so the two won't step on each other's feet. In the long term, the proper solution to this problem would be DCS-BIOS support in Helios. I do plan to implement that at some point if no one else gives it a try, but I probably won't find time to work on that for the next few months or years.

I suspect you may just have a bad USB-to-serial converter (or connection from the converter to the Pro Mini board). You can try using the Uno board as an USB-to-serial converter for the Pro Mini: remove the ATMega328 chip from the socket on your Uno board. Between the Uno board and the Pro Mini, make the following connections: GND to GND, Pin RX to RX, TX to TX Now try uploading the sketch to your Pro Mini board and test it with DCS-BIOS. If that works, order another USB-to-serial converter. PS: Please create a new thread for each question in the future. If your question results in answers that are useful for someone else in the future, it can be a lot of work to find them again if they are buried on page 38 of a thread that deals with lots of other things as well.

If you have several Arduino boards connected at the same time, you need to make sure that the Arduino software is set to the correct port before clicking "Upload". The currently selected board and serial port appear in the status bar in the bottom right corner. The setting applies to all open IDE windows, so if you change it in one, it changes in all the others too. If you connect an Arduino, program it, disconnect it, and connect another board, it may or may not appear on the same COM port number as the first one. Depends on whether the board supplies a serial number, whether you use the same USB port or not, and on the phase of the moon.

Try reducing the serial speed from 500000 bps to 250000 bps. You need to change it both in the .cmd file (replace "BAUD=500000" with "BAUD=250000") and in your sketch ("Serial.begin(500000)" -> "Serial.begin(250000)"). If that does not solve the problem, please tell us which version of the Arduino library you are using. In your last picture, you should actually see human-readable strings, e.g. switching the emergency flood lights switch to on should send "EPP_EMER_FLOOD 1". 250000 bps will become the standard speed in future versions of the library. 500k was picked not because it was a good idea, but because I had to pick something so I just went for the fastest speed supported by the ATMega328 found on most Arduino boards.

RS-485 will be the way to go. Ethernet is several times more expensive in hardware, and some insightful discussion in the original DCS-BIOS announcement thread has convinced me that I2C is too error-prone, especially considering the low price of MAX487 chips. RS-485 was designed for bus lengths that far exceed anything you will ever need in a simpit and the differential signalling makes it robust against interference (e.g. from PWM-dimmed backlights). I have started working on the RS-485 implementation. Early tests have shown that I won't get the accurate timing I want (5 millisecond timeout) with a USB-to-RS-485 adapter connected to a desktop PC, so I plan to make a sketch that turns an Arduino Mega 2560 into an adapter that connects three RS-485 buses to the computer. The Mega 2560 has four hardware UARTs, one to talk to the PC and three for the RS-485 buses. I am waiting for my Mega to be delivered. It should arrive in time for me to start tinkering this weekend, but it may be delayed due to a strike of the german postal service.

If cargo objects are returned by world.searchObjects(), you could try to get the initial locations from the env.mission data structure and then search for the actual object in a sphere of, say, 1 m radius around them. I don't have access to my DCS rig right now so I can't test if this can actually work though.

MiST development has moved to GitHub. You can always get the current stable release (and also any previous one) from the "releases" page. If it says something like "10 commits to master since this release" next to a release, it means the current development version has changes that are not included in that release. If that is the case for the latest release and you want to try the bleeding-edge development version instead, you can click the "Download ZIP" button on the main page. In general, use the latest release version. When reporting a bug, also test with the latest development version if possible (obviously, you only need to do that when it is actually different from the latest release).

Für den Stick hab ich mir eine Halterung aus Holz gebaut auf der auch die Pedale stehen. Das lässt sich allerdings nicht wirklich platzsparend wegräumen. Besser/platzsparender ist es wahrscheinlich, den Stick entweder am Stuhl oder am Schreibtisch zu befestigen -- kommt für mich nicht in Frage da beides zur gemieteten Einrichtung des Studentenwohnheimzimmers gehört. Der Schubregler steht auf einem alten Computergehäuse. Hat genau die richtige Höhe und lässt sich, da das Gehäuse ja nicht in Betrieb ist und deshalb nicht zig Kabel hinten dranhängen, nach Gebrauch einfach unter dem Schreibtisch verstauen.

Ich kenne keine Software, die das kann, aber es ist wohl möglich, sowas zu programmieren: http://www.codeproject.com/Articles/716591/Combining-Raw-Input-and-keyboard-Hook-to-selective Den von McMicha angesprochenen virtuellen Joystick gibt es, der heißt vJoy und kann über eine API von eigener Software gesteuert werden. Falls es nur um DCS geht und das Numpad einen PS/2-Anschluss hat, gibt es natürlich noch die Hardware-Lösung :)

Yes, that is possible. Just add the dofile(...) line to your existing (Helios) Export.lua file as described in the DCS-BIOS User Guide.

That information is found in a component's datasheet. Here's the MAX7219 datasheet available at maximintegrated.com. Look at the schematic labelled "typical application circuit" on the first page. Note how they simplified the drawing by using only one line for the digit and the segment lines. All "segment A" lines get connected to SEG A, all "segment B" lines to SEG B, etc. The common cathode line of the first digit goes to the DIG 0 pin, the common cathode line of the next one to DIG 1, etc. Also look at Table 11 in the datasheet to determine the I_set resistor value (in kiloohms) depending on the forward voltage and current rating of your 7-segment LED modules. Datasheets may look confusing and it can be easier to find a build log on someone's blog that you only have to exactly replicate, but I recommend you always try to understand what you can from the datasheet before looking for more information elsewhere. This way, after a while, you will have learned how to read a datasheet. It's a very useful skill to have, as it allows you to figure out how to use almost any arbitrary component. When WarHog ordered a small OLED display for his altimeter, he was able to get it running all by himself using the supplied datasheets (all I told him was which parts he could entirely ignore because they applied to modes of operation that we weren't going to use, such as the 8-bit parallel or the I2C interface :music_whistling: ). You use the LedControl library. If you wanted to write your own library (i.e. for a chip or module where nobody has written a library for yet), the datasheet contains all the information you need. If you ever find yourself writing library code to talk to a new chip and it's not working, get a logic analyzer. Having a convenient way to actually look what is happening on the communication lines between the microcontroller and the chip is an invaluable debugging tool in these situations. Ignorance is no problem at all. We all start out totally ignorant about everything. I enjoy answering questions from people who actually want to learn, because after a while, they come back with new questions (which they arrived at after gaining a better understanding of their problem or making progress with their build) and eventually, they succeed. What I can't stand are questions that are so broad and offer so little context that the only way to answer them would be to write a whole book on the subject. Trying to answer those anyway (with a broad overview and lots of requests for more information) is an exercise in frustration. You also tend to get useless complaints of "I don't understand!" instead of specific follow-up questions like "Can you explain X again?", "Where can I find out more about Y" or "Would this also work if I did Z" which result in actual progress.

If you can get your Arduino to talk to it (to which the answer seems to be yes), you can use it with DCS-BIOS.

Du musst die neuen IDs rausfinden (also das Spiel einmal starten, so dass Dateien mit den neuen IDs erzeugt werden). Dann alle alten IDs (sowohl in Dateinamen als auch in den -inhalten) durch die jeweils dazugehörigen neuen ersetzen. Ist bei mir einige Monate her, aber so hat der Umstieg von Festplatte auf SSD (mit Windows-Neuinstallation) problemlos geklappt. Ich glaube, ich musste danach noch in den DCS-Optionen die Modifiers neu einrichten, vielleicht habe ich aber auch eine Datei übersehen damals.