zerO_crash

It doesn´t find a valid firmware-file to update, which is somewhat weird, but no problem. It does detect your stick obviously, thus I´d get right to opening a ticket. Go to Brunner´s website, and at the bottom-right of your screen, you´ll see a blue support icon. Through that, open a ticket. Brunner is usually quick at responding, so I imagine that they´ll solve it quickly. Attach the log_(date).txt file from the "log" folder (The one you posted a screenshot of) when you create the ticket. I imagine they might send you an updated firmware. https://forum.brunner-innovation.swiss/forums/topic/firmware-yoke-joystick-rudder/ EDIT: Reconnect the stick to a different USB (and power-cycle it - disconnect/reconnect). If that doesn´t work, then I imagine it´s the units library not recognizing any valid firmware. In that case, Brunner will send you the proper files to deal with that.

No worries, all good brother. Not all the issues are listed in that thread. I did help a couple forum members with setting up their Brunner-hardware outside (email correspondence) and not all had the same issues. First and foremost, the "official" software worked splendid, absolutely carefree. You installed CLS2Sim, made the tuning that you so desireed and off you went. However, there were no FFB-effects in the sim and trimming of the actual stick was handled by CLS2Sim. As such, there was a discrepancy between the trimmed aircraft and its autopilot vs. the actual physical position of the stick. Those two would simply not overlay properly. Furthermore, there were no FFB-effects such as rumble, increasing control stiffness relative to speed (WWII prop, and other non articulated aircraft (Hydraulics/FBW). The obvious solution then, was to somehow get a software that would translate DCS's DirectX FFB-output to the stick by the use of CLS2Sim (only interface to the stick and it did not support DirectX). Therefore, the solution with Arduino (thanks to Chuls), acting as a translator to get those effects, and correct trimming with regards to the simulator output of each specific module. Digression - because of lacking native interface (back then) between Brunner's CLS2Sim and DCS, using the trim in DCS (without the Arduino-solution), you would trim the aircraft in DCS, however the stick wouldn't move. If you used CLS2Sim, then you also had to use its keybindings for so-called "physical trimming". That meant that CLS2Sim would actually move the center of the stick, instead of DCS. Now, even if you bound the same buttons inside DCS and CLS2Sim to the same trimming-scheme, CLS2Sim would either move too fast or too slow, depending on the aircraft. Furthermore, aircraft with heavy autopilot reliance did not recieve proper autopilot input, and as such, excessive amounts of trimming-errors were accumulated (unacceptable). Arduino, came and fixed that by, as mentioned; allowing DCS's DirectX to interface with, and affect, Brunner through the CLS2Sim (For the record, the sheer amount of software and basic understanding of why you needed it, is what threw most people off - esp. considering the price of the product. When you pay a melon for hardware, you expect it to work plug-and-play.). While the solution was perfect in essence, some minor imperfections remained: - You couldn't let go of the stick quickly, or touch it accidentally (bump into it), as that would bring a perfectly trimmed stick into an ever expanding oscillation, resulting in violent pendulum-like motion hitting the opposite walls of the base. Not everyone seemed to have this problem, but some, me included, had it. As such, you always had to "delicately" (by my standards, that is hairline-fine) let go of the stick, so as not to induce the oscillation. - Upon ejection or crash-landing, the stick could lock up in a maximum force condition. This was not serious though as typically going back to main menu or even selecting a new aircraft (from my testing), would fix it. There were some other smaller ones, however they mostly got fixed with later iterations of the BrunnerDX-build. To be quite honest, Chuls is the man! The fact that he managed to build such a universal and well working app (nevermind the small quirks), is insane. It was simple in use, it was simple in maintenance and generally simple in installation, with the only "if" being reserved to windows and its buggy nature. Now however, you don't need the Arduino and BrunnerDX anymore. As Brunner has recognized, DCS-community is generally a dedicated community which is willing to shell out for hardware in the name of science, and aviation. As such, DirectX is now natively supported by Brunner-hardware. It fixes all of the aforementioned issues, also those not mentioned (due to their inconsistent nature), and makes the Brunner the ultimate base. If you are serious about flying, this is the way. Now, you use a Brunner tool which is called "Brunner USB Config" to put the base either in a DirectX-compliant mode, or CLS2Sim one (XPForce, etc...) (This changes the HID-number of the device; keybindings and settings of it will have to be reassigned). Once the base is set in either mode, the onboard controller "remembers" it, as such, you only have to put in the specific mode once, and you are done. No need for the tool anymore per se, unless you fly other sims than DCS. For DCS, you don't need the CLS2Sim anymore either. It's complementary at most, but you won't use it. In the tool, you can alter different FFB values, however from my experience, it's plug-and-play. It gives splendid results right "out of the box". No need for any tweaking, its cosmetic as such. Here is the page for both the newest firmware, as well as the tool (use the hyperlinks): https://forum.brunner-innovation.swiss 1. Update the firmware of your device. 2. Use the USB-tool to set it in the desired mode. 3. Enjoy proper trimming and FFB in DCS.

I’ll try it, although I already lowered the OpenXR resolution to 50% to accommodate the 1.0 Pixel Density in DCS. Essentially, I did it in the app, instead of DCS. The problem persisted. I’ll reverse it, and see if it helps.

I expect so, still, changing the overall settings yields very little fps-difference. I can add 2x MSAA at the cost of 1-2 fps for example. Changing coulds from Ultra to low, results in no change, same as turning off absolutely all shadows. That’s why I attribute the issue to the one thing I cannot avoid using - OpenXR. Furthermore, I’ve been using purely SteamVR before, and never had a problem. I can increase fps by lowering the initial resolution, however at a very bad rate (gain few fps for halving the total amount of pixels). There is something bugged with VR, more specifically, OpenXR. It might be even something else, but in 2D, this is not a problem. Also, it affects both ST and MT performance-wise. I’ll have to wait for an update, but quite a few people with HP Reverb G2 are getting the same results as me. For me, MT runs equally bad as ST. I’ve been wondering why ST of all things runs bad as well, but I imagine it has to do with the implementation of MT (we are talking about VR all the time, 2D is working splendid). Let’s not the derail the thread. I presume that the reason why OpenXR targets a much greater resolution at 1oo% setting, is the same as SteamVR - the first generations of VR headsets had so bad resolutions, that in order to have any decent image fidelity, it was common to upscale. As to why a HP-employee would claim that it’s recommended with upscaled resolution, that’s beyond me. HP Reverb G2 is quality-wise on the level of Varjo Aero, when looking at the sweetspot. It is absolutely fantastic, even at default resolution.

Blurred shadows was one of the things introduced in 2.8 that initally lowered fps without anyone knowing about it, however soon after, it was separated and is now a separate setting. What else changed, I´m not sure (been afk for half a year - travelling), but I certainly get less than half of the fps that I used to get. I see the primary reason in the CPU-bound "bug" that occurs only when DCS is run in VR. Not really sure what happened, but this needs to be fixed. You are indeed upscaling, the pixel resolution of the two displays in the HP Reverb G2 is indeed 2160x2160. How the lens warps the image and what HP recommends is another topic, but on purely technical level, anything above 2160x2160 are "rendered" pixels, as you are producing more pixels than the panels physically have. Beyond that, I am very satisfied with the default resolution of HP Reverb G2, if only the framerate was back to the early 2.7. I hope the devs can really chime in on this and give a couple of definite answers on the follwing: - Is the CPU-bound flickering (only in VR) recognised as a "bug", and if so, will it be fixed? - Is there anything added graphics-wise (beside "Blurred shadows") that has impacted performance in any significant way and is there to stay? Or is this a matter of time and optimization? Any idea?

Before the later iterations of 2.7, I was running the same settings at framerates between 50-75fps. I will be getting a new pc in the nearest future, however there is no explanation for why the performance has degraded in this manner. Again, in the initial couple of seconds, I get really good performance, that until the CPU bug kicks in and throttles me back. This only happens in VR. In 2D, the CPU works as intended. Due to my build, I often get better framerate than many people with with newer pc´s and unoptimized systems. There is a problem with the VR implementation. As to resolution, I am capable, and have been running the HP Reverb G2 at "native" resolution. That is 2160x2160 (approximately 50%). You are upscaling the default resolution. That is not needed. You are better off with native resolution and add 2 or 4 times MSAA. Trust me, you will have much better visuals, without jagged edges. Mind you, I used SteamVR up until now, which is not the most efficient, yet has yielded great results.

Ok, this is interesting. Especially since I get superb 2D performance. It´s possible the issue is not a persistent one then, but still there. My system: - Asus ROG Z370-E - Intel i7-8700k (OC´ed to stable 4.7GHz) - Nvidia 1080Ti OC (Evga OC3) - 64GB G.skill 3200MHz RAM - M.2 SSD Samsung 980 Pro Evo - XFX 850W PSU - Secondary M.2 Samsung 980 Pro Evo (only for DCS) As to the map and module, I´m doing the simplest test, Ka-50 BSIII at Senaki-Kolkhi. Clouds, weather-effects, otherwise empty. Again, great performance in 2D, however terrible in VR. Also, that CPU-bound flickering bug (I presume). I am aware of that, but as a supplement to a previous thread, I have lowered the projected resolution and I barely get a difference in framerate. Furthermore, as observed, the difference between headsets that natively use WMR + OpenXR, vs ones that don´t. That´s the point of the comparison, not the resolution.

After having issues with DCS in VR since 2.7, and having planned to upgrade from Windows 10 Pro to Windows 11 Pro, I finally decided to migrate. I have reinstalled a clean installation of Windows 11, with the most recent updates as per 30.03.2023. I have all drivers updated to the most recent revisions. I have went through BIOS and system, and changed everything to performance (in case of the CPU, an XMP-overclock - 4.7GHz). HAGS is disabled, Nvidia has "maximum performance" and "Shader buffer - 10GB" set, and more. All settings are set globally, so everything affects DCS as well. Here are my observations from the current MT-version: Using my settings (mix of highest and lower for best framerate and visuals) in 2D (non-VR), I get 80-90fps in the most complex cockpits. In F2-view, I get anywhere from 110-160fps, sometimes more. My CPU-load is appropriate, my GPU is maxed out. Using the framerate-checker tool within DCS, I get overall really good performance-metrics, and a message that I´m GPU-bound (i.e. GPU is the limiting factor of my system). So far, so good. When connecting the HP Reverb G2, and enabling the VR-option in DCS, it´s a whole different story. While everything in the main menu works smooth, as soon as I start an empty mission, I get problems right away. During the first 2-3 seconds (while the textures load, and shortly thereafter), I get high CPU-/GPU-load, with low frametimes on the GPU and good fps. However, as soon as those first few seconds pass, my CPU-load goes down, and my GPU-frametimes surge up to +-50 microseconds. This happens instantaneously! I have tried running DCS MT as a standalone, with native OpenXR on HP Reverb G2. I have also added the DCS-shortcut to the Steam library, and run it through SteamVR. There are no differences, I am down to 18-20fps! (SteamVR & OpenXR tweaked for performance). From my observations then, I infer the following: - The fault is not at my end, as 2D gives me superb performance. - The problem occurs when DCS is put in VR, and attempted run with a HP Reverb G2 (could affect other HMD´s as well, not sure). - A clan member of mine has an Nvidia 1080 (non-ti, weaker than mine), a 7th generation intel CPU (one generation older than mine) and the original HTC Vive (as opposed to my HP Reverb G2). He has splendid performance, better than he had before. For me, it´s the exact opposite. As such, I am at this point sure, that the problem is in your integration of the OpenXR. This is the one constant I cannot remove from the equation, so as to eliminate it as a probable cause. A HP Reverb G2 cannot be run without OpenXR. I can change between WMR and SteamVR, but OpenXR will always be used by HP Reverb G2. I have checked every setting within DCS individually, I have made sure that my Windows 11 Pro is geared for maximum performance. The team must check the OpenXR-integration, as that is where the problem lies. (At first, I thought it might be a general DCS VR issue, however as mentioned, my friend with a similar setup, but HTC Vive, runs DCS silkysmooth. He also doesn´t get the "CPU-bound" flickering-message. Everything points clearly at OpenXR from stand, and that is having tested it with two different operating systems, a multitude of drivers, 2D vs VR, etc...) @Flappie @BIGNEWY @NineLine

I have never killed, nor tried to do an engine in DCS, thus I haven't checked what DCS will permit you in terms of engine durability. Again, depending on how long a mission is, what engine wear is set to (default is 90%, though you can set it manually lower in the mission editor), I wouldn't be surprised if it could be broken nowadays. Updates on singular components and damage modelling is beingn pushed through without concrete feedback through patch-notes. Remember that engine model being identical, does can, and will IRL be geared different. With such complex machines, being hand made and tuned before leaving factories, you will absolutely never have the exact same feedback. Never. There will be nuances and some aircraft will be able to withstand more whereas others will not. The specification calls for minnimum demands, but what is normal in what aircraft will be somewhat different. This applies within a specific aircraft make, the difference is even greater when you start comparing different types of aircraft. I don't see anything here that is outside of what different tuning could result in (pure metrics). Actually, EPR is more than just for reference, as EPR actually counts in the specific atmospheric difference, thus showing you what pressure is being built up within the engine. In a sense, if you exert too high pressures in the engine, you will stress the materials to a higher degree than the limits permit. That's why you have the EPR-limits to go by. In Russian helicopters you have three instruments to control with regards to engine limitations in order to maintain within specified control. It's more than just a reference-indicator mate I cannot really fly DCS atm. due to the sim performance having been altered since 2.8.0 (will need to get a new PC), however from the very little testing I did (2-3 hrs), I was able to attain TAS (as per editor metrics) of 275-280 km/h with a pure Ka-50 BSIII (two-pylon wing) and approximately 50% fuel. It was standard atmospheric conditions (default editor setting, again, need a new PC for anything specific) with no wind and between 10-20m ASL. I cannot see anything wrong. I might have reached close to 300 km/h if it was even lower on fuel, and less amunition, although 280 km/h is still really fast for this helicopter. The discussion of the qualitative anatomy of Ka-50 vs Mi-8MTV2 is a completely different one, and I have stated earlier why. Mi-8 will simply never attain the speeds and flight dynamic (turns, loops, instant change of bearing, etc...) that Ka-50 will do. One other should be stated, accelerating up to a max speed is one thing, attaining a top speed (e.g. dive), and then attempting to keep it as best as one can. Ka-50 has favourable qualities when it comes to maintaining the attained speed at a lower power setting once it has achieved the speed. It ought to be considered as well.

If you mean the terrain engine designation, then from here: As to the map being spherical, I seem to remember reading it years ago being explained as the reason for PVI-800 lacking the BS1-functionality when BS2 shipped. EDIT: I actually found an answer (not the one I was looking for, but nevertheless), and the answer is intermediate. While DCS doesn´t seem to be built on spherical terrain, the math done for Coordinates/LOS/INS/radars/weapons seem to be done for a spherical world. Grimes states however that he believes this was implemented for DCS world from 1.5 (EDGE). I am not sure if he means AI-units though, as I seem to remember that Ka-50 had this issue since BS2 introduction and onwards. I suppose there is a distinction between simulated units (user), vs AI (mechanics). Check Grime´s answer in this thread: On a side note, there are still many things in the sim which are halfways done. For example, while doppler radars have a minnimum altitude for detecting other objects, that altitude is currently counted from the ground, not other ground-objects. For example, a TOR will not see you (due to doppler filters) if you hover below 10m above the ground with a helicopter. However, if you hover 2m above the roof of a multi-story building, he will see you. That, considering trees have a collision-model. Again, the sim has gotten far, incredibly far, but there is stil much to do.

That is exactly how a simulator is used by e.g. military pilots. I haven´t went down in more than a year, the missions are chosen, but tasks are often preset, you get to fly much as this is afterall a simulator, one uses the best control-setup that one has at hand (I have practically always had FFB). I´ve never ever used curves or reduced saturation (never - better learn to microcontrol and steady your hand). No problem, aim small - miss small. It´s mindset, a perfectionist, nothing else! Everything can be undone, it´s only a matter of will. MiG-21Bis 2.0 will hopefully finally introduce fixes, and improve working of systems that it never got right, sight to mention one. Ka-50 BS1 used to have a working drift implemented for the PVI-800, that got removed in Ka-50 BS2 due to the new caucasus T3 version, which introduced the terrain as a sphere (as opposed to a flat map). Finally, Ka-50 BS3 brought PVI-800 functionality back from BS1. Don´t worry, we´ll get there. NVGs are yet another example. Hopefully, when the technology matures, and NVG´s recieve proper modelling, it will prove the point of how pointless it is to attempt using NVG in a cockpit not adjusted for it. I am following what´s going on at the Russian side, and I sure like what I see. Let´s assume those were but hiccups.

Negative, no luck. Power settings set to "Maximum Performance" have already been enabled system-wide by me. Forcing exceptions doesn't help either.

Well I prefer something more specific, than having a button meant for pedals, to be added to the HOTAS, or even keyboard. It's a function that is going to be engaged by me anyways, until I get proper FFB-pedals. If one stands between chosing to have full control of the aircraft at all times, at the expense of reduced AP functionality when in longitudnal flight, then so be it. It is more logical to have it that way, than to seek the relief of AP, and at the same time have the AP in in some cases interfere with the pilot's input. And even if you use the an additional button for microswitches, it is wrong to have it on HOTAS, as opposed to feet. Adds an extra step, which is unnecessary. Not something that you want in combat. That's ny current issue with the system. While in some cases it won't retrim your pedals, it will otherwise do it if you happen to perform a combat-maneuver. I might work for some, as mentioned above, you trade heading-hold functionality (relief to the pilot on long flights), for an aircraft that will require you to hold heading, but with the advantage of constant control of the aircraft. One of the biggest problems with the current system, are situations where you need to diverge from your current flight-plan by performing combat-maneuvers, resulting in a shortest possible time to hover (e.g.). Do that without retrimming, and you will most likely not have pedal-range to counter main rotor torque. This is not the way to do it.

I prefer not to use the microswitch-button at all. Since I have no microswitches on my Crosswinds (with dampener mod), it's far better in general to have the option of having them constantly depressed. Reason is, coming out of stable flight with heading hold, you need to retrim the pedals, otherwise they will remain offset. That kills the flight-dynamic in a combat scenario. Furthermore, while theoretically the switches are there in the aircraft, pilots keep their feet practically all the time on the pedals. Thus, until I get my Brunner FFB-pedals (to complement my CLS-E), flight-dynamic wise, it's better to have them engaged at all times. IRL, pilots practically never take their feet off the pedals, and considering the fact that the sim must be adjusted to the hardware used, it makes all sense to have such an option. Having your feet on the pedals all the time (even with the microswitch depressed by default), represents a more realistic approach, than using a bound button to retrim the pedals, resulting in reduced control, effectiveness, rapid actions, etc... I am more for realism than anyone else, however this one mechanic, needs a function to be adjustable for pedals without springs and FFB (even with springs), because as mentioned earlier, pilots rarely, if ever, take their feet off the pedals.

@Flappie I checked further, and upon using OpenXR (through WMR, not SteamVR) and I get between 0-10fps more, depending on module. Additionally, when I am in a mission, I still get the low fps and "CPU Bound"-message with 1/3 - 1/4 CPU workload. However, when I am in the main menu, it's at 90fps and 2/3- 1/2 CPU load... The CPU is utilized more in the main menu, then it is in the mission... Any ideas?

That's really the problem, that the virtual pedals offset due to YAW AP, you cannot correct this, unless you use the pedal-trim button. With a "microswitch always on"-function, you can have the YAW AP engaged, without it offsetting their virtual position. You lose heading-hold functionality, but for any practical purpose, have full control over the pedals. Sadly, it's either or, since we don't have FFB-pedals (yet for me). Currently, I cannot engage YAW AP, as it offsets my virtual pedals. Been meaning to ask about this some time now, but was afk. It's literally a matter of having the option of "Microswtiches always on". Thanks again!

@BIGNEWY Any chance you could forward this to the team, and ask them about a rudder trim option for us with pedals without springs and FFB - "Microswitch always on/pressed in"? This is a must.

Yes, I have repaired multiple times after trying different solutions, just to keep the integrity clear. No luck. EDIT: For reference Flappie, come to think of it, when I first fired up DCS after being AFK due to travelling, I noticed a decrease in FPS with 2D as well (before setting DCS for VR). Same settings, but whereas I was around 160-180fps in 2.7.x, after I started up now (2.8.x) I was down 70-80fps in-cockpit across modules, and around 90-120fps F2-view. This is 2D, but nevertheless weird. At the same time, I´m getting lack of utilization from CPU. There is something with the core...

Ok, so I tried it and still no luck, incredibly low fps. It created a fresh DCS-folder by default upon startup, so I assume this was the idea. Again, no luck. I did some more testing, and here are the following results with "my" settings: - Main menu - 90fps (MT as well) - Looking around in the main menu with G2, it´s smooth (MT is somewhat jittery, not as smooth) - Starting a plain Caucasus mission with a couple of player-modules (only one active at a time, and primarily testing Ka-50 BSIII) some basic weather and wind: - Inside cockpit -> 31fps - F2-view -> 40-47fps - MT inside cockpit -> 25-28fps - MT F2-view -> 40-42fps I went on and set all settings to "Low" with the following results: - Main menu - 90fps (MT as well) - Looking around in the main menu with G2, it´s smooth (MT is jittery) - Starting a plain Caucasus mission with a couple of player-modules (only one active at a time, and primarily testing Ka-50 BSIII) some basic weather and wind: - Inside cockpit -> 42fps - F2-view -> 60-65fps - MT inside cockpit -> 37fps - MT F2-view -> 55-59fps The conclusion is that between my "high" settings, and absolutely lowest, I get barely 15-20fps difference, which makes little sense. The framerate should differ way more. Furthermore, I notice high frametimes (as expected, between 30-50μs). However the CPU is working around 1/4th the total scale. This occurs as weird to me, I would expect it to be maxed out. I will add that besides G2, I use Jetseat and Ultraleap (have tried with both disabled to no effect). I have also tried with Motion Smoothing set to "OFF" and Super Sampling "OFF" (SteamVR setting), again, to no avail. Besides this, I have SteamVR at custom resolution (52%, meaning just above G2 native resolution), everything else is standard. In Nvidia Control Panel (most recent driver), I have everything on default besides; "Prefer maximum performance", "10GB" caching space (wil go back to 100GB again) and V-sync controlled by app (tried "Fast" as well, with no effect other than slightly more jitter with G2). General observation and feeling is that ST runs smoother and better than MT, however they both perform bad. Should you need any files, give me a heads-up. Also, great to hear about Brunner running without issues, good stuff!

I am using the Brunner CLS-E with a 20cm extension and Virpil T-50CM2. Don´t worry about those claiming that it´s not strong enough, it´s not true. I´m using mine with an extension, and it works superb. The extension can be longer if need be. It´s the best base you can get, a complete game changer (coming from MSFFB2, through Virpil base and Brunner CLS-E last two/three years). It´s worth every penny. Fantastic setup, and now that it supports DirectX FFB without any adjusting (plug and play) and Arduino, is simply beyond words. There were some issues with the Arduino solution, which are gone now. It cannot get better, let me put it this way. Shoot for it, you won´t regret it!

I have posted before a similar suggestion, as a final solution, such that you could besides "game mode", also chose "realistic" and a mix of system´s modelling + physics and "fantasy" loadouts. With that said, I doubt ED sees this as an issue significant enough to grant a rework/update of the simulator options.

There is too much to ask about, without being able to see the track-file. The one final section of the manual, that you can check before eventually opening a bug report, is to check pages 142 and further (engine overheating). It´s possible that you are pushing the engine too hard for too long at too low speed, or any of the other listed reasons there.

Sadly, I cannot check the track-files atm. (bad performance after recent patches). I am not talking about the temperatures, I am asking specifically if you are doing the engine warm-up prescribed in the manual? Check the BF-109K4 manual on pages 123-124. If you haven´t done this, try it, follow the exact warm-up procedure, and check again.

Are you heating up the engine properly pre-flight?

@Flappie Just curious, you have a running bug with WinWing, I however have a Brunner CLS-E base. I wonder, you don´t have any reported issues with that? Again, seems weird to me, I tried pretty much anything, even lowering settings , where I get 3-5 fps at most, (textures all down, shadows all off, +++). If it was a problem on my side, I would imagine gaining way more fps than aforementioned. At this point, I´m waiting for the new update to fix the performance, as I can not see it being anything on my side. G2 works flawless outside of DCS btw. (framerate, tracking, etc.).