CodeToad

SkateZilla: SOLVED thank you Turns out VR mode was turned on but I wasnt using the Oculus Rift (which itself still needs some debugging) I must have had VR mode turned on in DCS previously. My bad ! Thank you and hopefully that solves Aegers issue too !

Hey all - thanks for your ideas ! Unfortunately the log file (also attached to this post) was not much use, seems pretty ok - except one line: UIBASERENDERER: Cannot load font [C:\Program Files\Eagle Dynamics\DCS World\dxgui\skins\fonts\]! That directory exists, and fonts are in there and they are readable as far as I can tell. Not sure that alone would keep the screen black... I did notice that Aeger in his post describing the same problem has the same font error - can someone check whether their successful boot log has this error also ? If not, perhaps thats the place to dig deeper next... Second, I ran the repair and no weirdness reported. Current versions: installed version 2.5.5.41371.1 DCS updater 2.9.16.18 I have no mods running (also told repair it could remove any if it found any). Tacview 1.8.2 is installed though. Log file says it successfully loaded the Tacview files. GPU is a NVidia GTX 1080Ti driver 445.87 (4/15/2020) Like Aeger said in his post, Task Manager reports low CPU/GPU/Memory once DCS is loaded and displaying black, suggesting maybe it is just in the main menu, not unsuccessfully trying to do any heavy lifting. snap attached dcs.log.txt

Asking for advice: after updating my DCS (after a longish break) to 2 9 16 18 updater 2.5.5 dcs on windows 10, latest NVidia drivers everything *else* seems to work fine, ie windows, other apps etc. but on starting DCS, I get the logo screen to pop up and after that it is just a black screen, not the typical main app screen w the modules list below etc. No network or disk or CPU activity out of the ordinary, DCS is just "sitting there" in the dark. I have restarted, renamed my "Saved Games" folder to see whether some incompatible preferences / configs caused this, but nothing seems to help. Can anybody suggest how I debug this further (short of a complete reinstall which given how many modules I have may take a week of downloading....) Thanks in advance !

Just donated as well. Good project - thank you Andre !

See this thread on the Gametrix KW-908 Jetseat from Russia. It has 8 vibro motors (4 for each side left/right located 4 on your seat and 4 on your back) controlled by USB controller (ie allowing digital control rather than just analog audio) A russian guy named Andre makes software for it that drives it digitally from DCS telemetry (using Export.lua) called ibaEffects. There is also software called SimShaker from the same website. Not sure what the difference is. I asked Andre about using his digital output (and custom vibration patterns) drive a ButtKicker instead of a Gametrix seat. You can see his answer here (Spoiler it is "Yes, but") Here is what SimShaker can do with DCS: Andre points out that the $175 Gametrix seat can provide neighbor friendly QUIET haptic feedback to your body (vs the ground shaking Buttkicker) And in multiple places on your body no less :)

Hello Andre - question: looks like you have already done the hard work of exporting the necessary event data from DCS to trigger the right sound/vibration effects at the right time. And you have the vibration data files. Any chance you could emit those to a single channel of a sound card so we could connect that to a Buttkicker ? Kind of like what SimVibe does for many car racing sims and Xplane ? Outside Russia, these Buttkickers are likely easier to get than the Gametrix Jetseat (I never even got a response to my email enquiry to the company, so I bought a buttkicker instead.) Based on for racing games, having the transducer driven by specific events - from game metadata like Export.lua - is much better than just using game sound to drive it.

rocketeer: Indeed "Mega" usually means "Mega 2560 R3" at least for now (Sparkfun - link below - also has some other Mega variants) The Mega has 54 digital I/O pins (15 of which can be used for PWM) and 16 analog pins. You may find this chart useful for more comparisons between different Arduino boards #digital, analog ,PWM pins: http://arduino.cc/en/Products.Compare https://learn.sparkfun.com/tutorials/arduino-comparison-guide The next best (#pins wise) is the Arduino Leonardo (or Yun, or Micro) with 20 pins Most of the other ones (Uno, Pro Mini) have 14 or fewer

I am just working on a radio panel (pretty ghetto compared to other panelists) and I'm happy to share my arduino code, although it is work in progress (but perhaps you find it useful for your experiments already) I have it working with adafruit rotary encoders so far (24 step per rotation + push button) but I am also getting sparkfun encoders which have an RGB LED lit shaft/button. The basic hookup and rotation detection is fairly trivial. For the adafruit encoder: Connect the center pin on the rotary side and one of the pins on the pushbutton side to ground. The rotary side left and right pins are called A and B in the code below. The other pushbutton pin is called push. You can connect these directly to 3 digital pins on the Arduino. No need for pull up resistors since we use internal pullups (see lines with INPUT_PULLUP) This does mean the logic is inverted ie push button pressed == LOW Anyway heres the Arduino code (for brevity this is generic rotary encoder sample not DCSBIOS specific yet but that will be easy extension given DCSBIOS clean design) int value = 120; // init to whatever const int pin_A = 2; const int pin_B = 3; const int push = 4; unsigned char encoder_A; unsigned char encoder_B; unsigned char encoder_A_prev = 0; // http://www.hobbytronics.co.uk/arduino-tutorial6-rotary-encoder void setup() { pinMode(pin_A, INPUT_PULLUP); pinMode(pin_B, INPUT_PULLUP); pinMode(push, INPUT_PULLUP); Serial.begin( 115000 ); } void loop() { encoder_A = digitalRead(pin_A); // Read encoder pins encoder_B = digitalRead(pin_B); if ((!encoder_A) && (encoder_A_prev)) // A has gone from high to low { value += encoder_B ? 1 : -1; // see diagram on linked page: B hi=red=clockwise, B lo=blue=ccw Serial.println( value ); } encoder_A_prev = encoder_A; // Store value of A for next time // push button on encoder resets (optional obviously) if ( digitalRead(push) == LOW ) value = 0; } I have not personally needed debouncing capacitors between pin_A and ground and pin_B and ground respectively, but if you see a lot of "noise" while turning the knob, put a .1 uF (104 package) capacitor each there. For my actual panel, I will get a little more advanced and use the RGB LEDs for feedback. I will try to get 3 rotaries (UHF, VHF FM, VHF AM) and one 16x2 or 20x4 LCD display . Just so all the analog tuning stuff in DCS can be done with physical twiddles instead of the somewhat tedious rotation mode onscreen. I am also implementing a "push for menu" capability where menu selection might be something like - Frequency - Volume - Preset - Mode with each having an integer, float or set of strings to choose from. While selecting the menu, the LED will light up in some color for feedback. You select a menu item by rotating the knob. With a push of the knob you pick the currently selected menu item and can change the value. Functionally similar to but much simpler code. I am also implementing "turn acceleration" for large range, high precision variables like frequencies. Whereas in a real A-10 cockpit for example you might have multiple dials, for the various digits of a frequency, I want a single rotary encoder for each radio. Slow turns will be high precision. Fast turns will move in much larger increments, allowing zipping from 80.0 Mhz to 103.5 Mhz for example while maintaining precision of 0.1 Mhz with slow turns. (Otherwise each turn would only yield 24 * 0.1 = 2.4 Mhz and that would get old fast) That code I am still cleaning up and documenting (and wrapping into a object oriented library so you dont have to see the guts and can use multiple rotaries from a single arduino sketch) I will post it here, probably next week as I am traveling this week/end. References just in case you want different approaches (I ended up not needing Arduino interrupts or bounce delays etc. and I like to keep code as short as possible, but your mileage may vary): http://www.hobbytronics.co.uk/arduino-tutorial6-rotary-encoder http://dev.tetrastyle.net/2012/08/blog-post.html https://github.com/medecau/QuadEncoder PS: the sparkfun encoder has 5 pins on the RGB LED side (R,G,B, pushbutton, ground) and these are NOT the standard 0.1" separation but around 0.08", so they will not plug into a breadboard or protoboard nor will female jumpers connect (too tight). Grrr. Sparkfun sells a breakout board, but it is so big, that it makes breadboarding hard (see comments section on their product page) Still the LED is nice for signalling and price is good.

If you do not know Spintires: it is a physics simulation/tech demo/game (available on Steam) of heavy vehicle tires interacting with the mud/water/soil underneath (soil deforms, leaves tracks, mud flies around etc.). It is really well done and kind of unique. So particularly interesting for off road/cross country terrain one would encounter with CA vehicles, Shilkas, tanks etc. For some spintires demo videos, check out ChristineItr's youtube channel. Warthunder will include some of these effects as well (see (In Development) Enhanced vehicle to surface interaction) for ground combat. Not sure whether this is at all SpinTire related or whether the physics engine is now licensable ? Wouldn't this be awesome for Combined Arms, 2018 edition ? You kind of have to see it in action, but all the tracks, grass, mud deformations below are created dynamically while driving: there are lots more examples via Google

I would suggest you look at Touchscreens Gadroc's Helios (if you want to make touchscreen UI's) now open source ! of his very popular A10 Helios Profile Lately, Capt Zeen has been making some very nice Helios profiles for F15, Su25, Ka50. Helios Lives ! Panels for cockpits and if you want to hook up physical hardware (buttons, rotary switches etc with Arduinos), may I recommend the excellent DCS BIOS from [FSF]Ian. It is well written, well documented and well supported. Generic UI variable export Both of these work by shoveling data out of DCS World (into files, other processes, your local network etc.) while it is running through an Export.lua script. The basic process is described here but you can find plenty more documentation by googling around and reading forum posts.

Don't see why not - as long as you have the code to drive the display from the Arduino. Here are a couple of potentially useful Arduino libraries to drive character displays: LiquidCrystal I have used this one, for the displays that commonly use the HD44780 chipset LCDi2c for serial i2c displays If you are new to character displays, you may find this general tutorial from Adafruit NYC about hooking them up to Arduinos useful. Beyond that, connecting up to DCS BIOS is trivially easy thanks to Ian and you will find instructions for that both in his documentation and in this thread.

Felm - any chance you are running into the same issue I did (USB overwhelmed, reduce speed, captain !) see http://forums.eagle.ru/showpost.php?p=2294113&postcount=101 how to set back baudrate to 115K or 250K (which still worked for me, but 500K which is the default in DCSBIOS did not)

Naîve question: could the slew switch operation be improved with "just" a better (longer offset) 3D printed switch cover/hat or does the actual switch itself really have to be replaced ? (Analogously to: the TM Joystick operation can be improved for some by adding in an extender)

@Ian: Thank you, problem solved, indeed it was baud rate related. Everything working to spec now. For the benefit of anyone not reading the whole thread: IF you use the DCS-BIOS library unmodified AND you are seeing weird characters, irregular update rates etc. in Arduino app AND shows the correct live data THEN reduce your baudrate from 500000 to 115000 in: 1. the Arduino setup() code: Serial.begin(115000); and in the 2. connect-serial-port.cmd script: ...mode COM%COMPORT% BAUD=115000 PARITY=N DATA=8 STOP=1 TO=off DTR=on... I love it. Thank you Ian ! Your library really makes building cockpit panels very straightforward (once I got the bug squashed :) Next, I will research how to get the stream of data into a mobile browser (Android, iOS, likely Chrome) so I can show a plane icon and some telematics on an iPad/Nexus kneepad app. Maybe websockets... Oh sigh, no UDP support :( And WebRTC with a raw data channel & UDP might work, but support still pretty sketchy on mobile. Maybe I need to write something like Ian's node server (which would update/keep current state data on the PC and allow http access to it, polled from a web page's js) Also looking forward to the extra information which might be exposed by DCS-BIOS in the future.

@Ian: Tried using your suggestion to only update LCD when MetadataEnd (0xfffe) gets encountered. Did not fix the problem. Still seeing junk bytes, strings too short (like empty HH/MM/SS), very rare updates (possibly due to corrupted stream => missing MetadataEnd packets) and likewise TACAN test light on wrong (which is independent of LCD mechanics, pointing to a software rather than hw updating issue) Code pasted below. Tricky to debug because I can't use Serial.print because the serial port is obviously being used by the socat cmd. Is there a way to "debug dump" what is being sent over the serial port by socat ? Additional info: I verified again that your chrome extension with live data display shows the data coming from your DCS BIOS export correctly, so the issue is likely downstream of that. Curiously I noticed that when I put the A10 into autopilot flying straight, things start looking better on the LCD soon after: updates happen more frequently and the text looks more correct ! Could it be that if I fly manually that causes more cockpit display data changes and thus more required updates and that may flood socat or my serial interface ? This is reversible: if I go out of autopilot, I once again get more garbage chars, fewer updates. ---------- Second, following up on your suggestion that the LCD might be overwhelmed w too many updates, I also looked into that a little bit, and to save others this particular trip down debugging lane: My LCD display, a 20x4 liner (http://www.adafruit.com/products/198) is based on the HD44780 chip which is also used by many other character displays. They all have similar pinouts: VSS, VDD, V0, RS, RW, E, D0, D1, D2, D3, D4, D5, D6, D7, LED+, LED- General info and hookup instructions can be found here. The tutorials all show a wire & pin conserving 4-data wire hookup of the display, rather than all 8. Quoting from that page: There is also a way to talk to the LCD using only 4 data pins instead of 8. This saves us 4 pins! Why would you ever want to use 8 when you could use 4? We're not 100% sure but we think that in some cases its faster to use 8 - it takes twice as long to use 4 - and that speed is important. For us, the speed isn't so important so we'll save some pins! I did try hooking up all 8 data lines (since we are testing whether LCD speed might be a culprit) and used the full 8 dataline constructor for the LCDLibrary LiquidCrystal(rs, enable, d0, d1, d2, d3, d4, d5, d6, d7) That however did not work at all (nothing shows up on the LCD) So I assume there is a bug in the library and left that experiment alone. Just FYI. ------------- As per Ian's suggestion, modified Arduino code that collects telemetry as usual but only updates the LCD when a MetadataEnd packet (0xfffe) is encountered (which by design should be about every 30ms). See onDcsBiosWrite() and updateLCDDIsplay() below. #include <DcsBios.h> #include <Servo.h> #include <LiquidCrystal.h> #define TACAN_TEST_BUTTON 2 #define TACAN_TEST_LED 3 LiquidCrystal lcd(7, 8, 9, 10,11,12); unsigned int altMslFtValue; unsigned int hdgDegValue; // ------------------------------------------------------------------------------ DcsBios::LED tacanTest(0x10da, 0x0400, TACAN_TEST_LED); DcsBios::Switch2Pos tacanTestBtn("TACAN_TEST_BTN", TACAN_TEST_BUTTON); void onCmscTxtMwsChange(char* newValue) {} DcsBios::StringBuffer<8> cmscTxtMwsBuffer(0x12b0, onCmscTxtMwsChange); void onAcftNameChange(char* newValue) {} DcsBios::StringBuffer<16> AcftNameBuffer( 0x0000, onAcftNameChange); void onClockHhChange(char* newValue) {} DcsBios::StringBuffer<2> clockHhBuffer(0x10fe, onClockHhChange); void onClockMmChange(char* newValue) {} DcsBios::StringBuffer<2> clockMmBuffer(0x1100, onClockMmChange); void onClockSsChange(char* newValue) {} DcsBios::StringBuffer<2> clockSsBuffer(0x1102, onClockSsChange); void onClockEtcChange(char* newValue) {} DcsBios::StringBuffer<3> clockEtcBuffer(0x1104, onClockEtcChange); // ------------------------------------------------------------------------------ DcsBios:: ProtocolParser parser; void setup() { Serial.begin(500000); lcd.begin(20,4); lcd.clear(); } void loop() { while (Serial.available()) { parser.processChar(Serial.read()); } DcsBios:: PollingInput::pollInputs(); } void sendDcsBiosMessage(const char* msg, const char* arg) { Serial.write(msg); Serial.write(' '); Serial.write(arg); Serial.write('\n'); } void onDcsBiosWrite(unsigned int address, unsigned int value) { // show heading and altitude on line 3 of LCD if (address == 0x040a ) { hdgDegValue = (value & 0x01ff) >> 0; } if (address == 0x0408 ) { altMslFtValue = (value & 0xffff) >> 0; } if (address == 0xfffe ) { // end of DCS BIOS update marker (~every 30ms) updateLCDDisplay(); } } void updateLCDDisplay() { lcd.setCursor(0,0); lcd.print( cmscTxtMwsBuffer.buffer ); lcd.setCursor(0,1); lcd.print( String(AcftNameBuffer.buffer) + " " ); // assemble clock string here so we dont hammer LCD more than necessary String c = String(clockHhBuffer.buffer) + ":" + String(clockMmBuffer.buffer) + ":" + String(clockSsBuffer.buffer) + " " + String( clockEtcBuffer.buffer ); lcd.setCursor(0,2); lcd.print©; String s(hdgDegValue); lcd.setCursor(0,3); lcd.print( "Hdg:" + s + " " ); String s2(altMslFtValue); lcd.setCursor(10,3); lcd.print( "Alt:" + s2 + " " ); }