bojote

Totally agree with you, most people still stick with the “tried and true” Nanos and Megas, but the ESP32, especially the S2/S3 versions with USB-C, are a big step up if you want more flexibility. Once you try DCS-Anywhere’s USB HID setup, it really opens up new ways to build and connect panels, especially if you want to get away from the serial/COM port headaches. About running on a headless Pi: yeah, that would be really useful. Right now the CockpitOS HID Manager only runs with a GUI (Tkinter), so you need a desktop environment. There’s no official CLI mode yet, but I’m definitely considering it for the future. Would just need to strip out the GUI bits and let the network/HID bridge run in the background, maybe with logs to the terminal or a file. It’s kind of funny how much inertia there still is around Arduino Nanos/Megas, even though the newer options (like ESP32-S2/S3 with native HID and multi-platform support) are just so much better for this kind of stuff. I think as more people look for driver-free, network-connected panels, projects like this will eventually get more attention. One quick note for anyone curious: “CockpitOS” and DCS-Anywhere aren’t the same thing. CockpitOS is actually a full-featured firmware that supports most TEKCreation panels—it’s what I use for my home cockpit setup. DCS-Anywhere is more like a lightweight example or starter template. If you want to check it out, here’s the link: https://github.com/BojoteX/CockpitOS

Good! keep in mind I created a custom trained "GPT" that is better than me for answering technical or even implementation questions. I edited the original post with a link to it. Glad you you could make it work. Remember you can use that Python script on a Linux computer, MAC, Windows, Raspberry Pi with the panels connected locally, you don;t need to use the DCS computer to connect the panels! this will allow you to run them "remotely" and it scales nicely with almost 0% CPU usage even on a raspberry!

Here's how you fix it: 1) Check the directory where CockpitOS_HID_Manager.py is located. Notice the settings.ini file? open it. take note of the vid and pid values, should look something like: [USB] vid = 0xCAFE pid = 0xCAF3 2) Now Open Arduino IDE or notepad editor and open the sketch "Config.h" file. It should be located in the same directory where DCS-Anywhere.ino is. File should contain something like: // USB VID/PID #define MY_DEVICE_VID 0xCAFE #define MY_DEVICE_PID 0xCAF3 If vid and pid dont match, then HID Manager will not work. You definitely have different values there. Post both full files if still having issues or RE-download and without modifying a single line of code try to compile again. It will and should definitely work

While I have not tried the S3 with DCS Anywere I do have one that I use for the full stack ‘CockpitOS’ without issues. What I would do later today is download the latest version I uploaded, compile and test it. Give me until later today to test

What Arduino Core version you compiled the firmware with?

Yes, you can use a Raspberry Pi as the "host PC" for the DCS-Anywhere solution, but the cockpit hardware must still be ESP32 (S2/S3) running the supplied Arduino-based firmware. How it works: The Python HID Manager runs on any OS: Windows, Linux (including Raspberry Pi OS), or Mac. Just pip install hidapi, then run the Python script with your ESP32 cockpit panel(s) plugged into the Pi via USB. The Pi listens for DCS-BIOS UDP data and bridges it to your panel(s) over USB HID. No serial, no drivers, no COM ports! Your Pi and DCS computer must be on the same LAN (UDP multicast enabled). Limitations: Only ESP32/ESP32-S2/S3 boards (with Arduino framework) are supported as cockpit devices. Raspberry Pi cannot directly emulate a cockpit device (i.e., you can't plug a Pi into another PC as if it's a panel), but it is perfect as a network "panel hub." Example workflow: Flash the ESP32 panel with the supplied firmware. Plug it into your Pi. On the Pi: pip install hidapi python CockpitOS_HID_Manager.py Your ESP32 panel will now receive DCS-BIOS data anywhere on your network! Display support: You can use the ESP32's USB HID protocol to build an HSI or artificial horizon on your cockpit panel, with the Pi acting as the bridge. Docs: GitHub CockpitOS (full cross-platform support) All features work on Raspberry Pi as long as it runs Python 3.7+ and has HIDAPI Probably the only "concern" would be performance as I have no idea how the ARM CPU compares to my home Ubuntu/Linux intel mini-pc in terms of speed, but I'm confident this will work great

Got it. I probably misunderstood the original question. yes, both Arduino's and ESP32s (one using Serial and the other USB) will work perfectly fine. Part of the "beauty" of how DCSBIOS works is that it pushes the DCS data stream to a multicast IP address, *ANY* software component that joins this multicast group will be able to access that data and do whatever it wants with it, so there will be no conflicts of any kind in your proposed setup. In fact, if you wanted, you could even use one of those cheap amazon small mini-pc with Ubuntu, plug your ESP32 to it and they will literelly just work without you doing anything. The python script will run just fine on Linux and has almost 0% CPU usage. Its a cool test/experiment. Now, I imagine you are planning to do this on a SEPARATE Hub right? as the power requirements I don't think will change that much. 25 Arduinos vs (e.g 20 Arduinos + 5 ESP32 on same hub) will not make much difference.

The DCSBIOS part is "standard" both the actual library and interaction with the incoming DCS data stream. Whats really 'unique' about this code is how the transport layer works. It completely bypasses Serial (socat) and uses the ESP32 device USB bus for bidirectional communication with the Python script, which in turns acts as a "bridge" between your device and the "network" where DCSBIOS sends and receives data from DCS. Keep in mind what DCSBIOS does is simply "convert" DCS World data to "network data streams" you just happen to use them locally on your computer and have "socat" forward them to your device via Serial. I do exactly the same, I just dont forward this info to the device via Com ports, I use the Python script to push it via native USB. Now, to your original question: Arduino's are meant to be used and optimized for Serial comunication. Their native USB stack is not as robust as the one in the ESP32's, so even if you ported this to work in native USB's arduino's (technically possible) you'll have to modify how you instantiate USB HID. Keep in mind what I shared is a basic, simplistic template/reference which you can fork/modify as you wish. I'm pretty sure there are Arduino experts here that can take a look at the code and figure out how to implement. You need NATIVE USB in order for this to work, 100% HID protocol compatible at USB 2.0 speeds, if not, it will not work. If you tell me which Arduino's support this I could take a look and try to implement as an experiment and in that case you could mix this with a "normal" DCS-BIOS/Arduino setup

EDIT: A new GPT assistant was created to help users migrate code and help with general questions, you can try it here -- Hey all, Just sharing a little project I put together for my own home cockpit setup, but figured it might be useful for others building custom panels. DCS-Anywhere is a lightweight framework for running DCSBIOS-enabled panels on ESP32 hardware (including S2/S3 variants), but with a twist—you’re no longer tied to serial COM ports or to having panels physically connected to your DCS PC. With this, you can plug your ESP32-based panels into any computer on your network (Windows, Linux, Mac), and use USB HID to get panel inputs/outputs working seamlessly with DCS-BIOS. No drivers, no COM ports, just standard USB or network. Once connected via USB to that computer, the "HID Manager" can forward and receive all UDP DCS traffic to/from the device. Uses the official DCS-BIOS Arduino Library (so your existing panel code works, no need to rewrite for “lite”/custom forks) Supports ESP32, ESP32-S2, ESP32-S3 (Arduino framework) Network bridge (Python) lets you run panels from any PC, not just your sim rig Cross-platform: you can use Linux or Mac as a panel hub, not just Windows How it works: DCS World (with the DCS-BIOS Skunkworks fork) exports cockpit data via UDP on your network. A lightweight Python script bridges your panels (over USB HID) and the DCS PC. Your ESP32 panels communicate with the Python script via USB or UDP—no COM port headaches. All the details, code, and usage notes are here: https://github.com/BojoteX/DCS-Anywhere It’s basic and meant as a starting point, but if you’re looking for a simple way to get DCSBIOS panels working over the network (or on a non-Windows PC), give it a try. Read the README for setup and compatibility notes. If anyone gives it a go or has suggestions, let me know. Happy flying!

And thats still the case. I can confirm that Kneeboard builder (when using custom positioning profiles) does overwrite a lua file in the core folder. This change breaks IC for servers with the Pure client *SCRIPT* option (which few servers use). There is no way around this.

if you use it just to 'build' a Kneeboard, then yes, you are 100% correct. Thats why I stated in my message that my assumption is that this is due to the custom positioning via profiles in Kneeboard builder which is not a feature everyone uses. You know what feature I'm referring to?

Great software! being using it since last year, really good! I just noticed that I get a Pure Client Script IC check error when using some servers. I assume this is due to the Kneeboard custom positioning. I ask because I was under the impression (I read somewhere) that Kneeboard Builder passed IC checks. is it me doing something wrong or its just a limitation? thanks!

thanks!! yes, fully aware I can designate both members and donors, I was simply puzzled they were not assigned and other package elements were not showing on the SA page. As Baltic mentioned its probably a DCS Core issue. Not a big deal, as I said, I consider this an "in-flight system failure" for entertainement purposes.

No worries. Its one of those things that add complexity and challenge. As if it was an in-flight failure scheduled to finish Mission 15 today and will later check your new rampagers campaign. Thanks for your great work!

DCS-BIOS and Helios REQUIRE to run as Administrator. If for any reason, you have DCS *NOT* to run as Admin BUT you have, say, process control in Helios automatically launch DCS for you it will inherit the original process priviliges (Administrator). So, EVEN if you don't have DCS to run as administrator this problem is something you could experience.

Check your DCS shortcut, go to properties and make sure it is NOT set to run as administrator. Make 100% sure this option is not checked (remember, there are TWO options, system wide and local) ensure NONE is selected. Now try running DCS. If you run Helios AND you have automated DCS launching using Process Control then you will experience this issue EVEN if you did the step above as Helios Control Center runs as administrator and all child processes launched will inherit the parent app privileges (Administrator) so do not auto launch DCS for within Helios, do so manually as non admin

I think I might have fixed it. Can you confim that your shortcut or DCS.exe file is NOT flagged/checked to run as administrator? If DCS is run as administrator (option checked in the shortcut for ALL users or in the exe) DCS goes crazy. If unchecked everything works great. Please test when you have a chance. This might explain why some users do not experience the problem (they simply don't run DCS as administrator) and will also explain why full repairs or re-installs wont fix it. As that option sticks and stays over updates. Also, for those running Helios, you might have noticed Control Center runs as Administrator. This is not an issue UNLESS you use Helios Process Contorl to launch DCS automatically. Why? because any child processes launched by Control Center will inherit the privileges and DCS will RUN as administrator and cause the problems we are seeing. Can the developers check why running as administrator creates the issue? (fairly easy to replicate on their end)

How many winwing screens you have, 2 or 3 screens? Are you running latest DisplayLink and nvidia drivers? is Windows 11 completely up to date as of today? can you share your options.lua file? Do you use HAGS? Nvidia Inspector specific settings? You might be the key to solving this. Are you also 100% positive you are running DCS version 2.9.14.8222?

@MeatServo I assume you have your USB Displays connected to a HUB, as well as controllers. (I have virpil Stick+HOTAS) have you tried connecting ONLY the USB displays and disconnecting your controllers from the hub? I will try that next in my experiments as I can toggle the USB ports on off. What I find hard to believe is that there is people running USB Displays and have no issues. Only explanation is either an OLD NVIDIA or DisplayLink driver that lacks a feature that does not conflicts with this. I;m running latest drivers for pretty much everything in a vanilla DCS install

I basically did EVERYTHING @MeatServo just said and some: 1) Did a Full repair (Slow option) but also selected the option to check for aditional files. At the end of the repair it shows you WHAT FILES are not part of a default install so I choose the option to Move and Backup (They were mostly renamed log files and renamed files, but still, choose to MOVED them out for my testing) 2) Did a CLEAN install of Nvidia Drivers using NVClean and removed all profiles 3) Updated DisplayLink drivers to the newest ones (Feb 25) I had the Nov 24 version. 4) Removed the ENTIRE Saved Games DCS folder so that it will be rebuilt from scratch. tried running DCS standalone, NO background software or apps (and since Saved Games/DCS folder is brand new there is absolutely not a single add-on). I tried with my displays connected but choosing a resolution in DCS to match ONLY my physical monitor (3840x1080) and It works, but if I change the DCS resolution to ALSO include my USB Displays (3840x2104) so that I can use viewports and export screens then hell breaks loose. My guess, is that somewhere in the lines of code of this complex program a programmer incuded a feature that was supposed to be LOCAL to the GPU accelerated viewport or physical screen but forgot to constraint it and when applied to the USB screens it messes up things. Perhaps post-processing, transparency, or depth layers related to the heatblur setting in the hud? it would be nice if one of the beta testers would point the developer to this post so we all work constructively in fixing the issue. While I understand MOST of the problems you see reported in this forums are user error and misconfigurations, I can assure you thats NOT my case, I know my PC, config and DCS inside out. DCS is probably one of the most (if not the most) stable software program I run. I probably have not see a SINGLE stutter or hitch like in the past year, so when something is off, I can spot it immediatly.

Here's a ChatGPT analysis of BOTH log files (also attached to this post) Here’s the deep-dive analysis comparing your bad (extended resolution) and good (center-only resolution) DCS logs. The core DCS build and hardware are identical — the only changes lie in resolution, aspect ratio, and DLSS settings. Here’s what stands out: Key Differences in Graphics Config Setting Good Log Bad Log Resolution 3840 x 1080 3840 x 2104 (ultrawide/stacked) Aspect Ratio 1.33 (standard 16:9) 1.825 (ultrawide 32:9 or multi-screen) DLSS_PerfQuality 0 (Off) 1 (Likely “Quality” or “Balanced”) Probable Cause: DLSS + Extended Resolution Conflict The combination of: High horizontal resolution (3840x2104) + DLSS enabled (DLSS_PerfQuality = 1) + NVIDIA RTX 4090 on new drivers …is likely triggering a render pipeline crash. DLSS introduces a temporal reconstruction step based on resolution scaling, and with non-standard aspect ratios and multi-monitor setups, it can break badly — resulting in: Black screens UI render target errors (render target 'uiTargetColor' not found) GPU driver timeouts (which would not show in the log but matches your symptoms) Additional Supporting Evidence Both logs include this: ERROR_ONCE DX11BACKEND: render target 'mainDepthBuffer' not found However, the bad log shows more unusual texture-related errors later and several rendering target misses — indicating a more severe GPU-side failure in that config. Recommendation / Fix Plan Turn off DLSS: Set DLSS_PerfQuality = 0 in options.lua Disable Upscaling and Sharpening: ['Upscaling'] = 'OFF'; ['Sharpening'] = 0; Test with standard aspect = 1.33 — try locking this manually, even if running extended resolution. Run with multiMonitorSetup = "1camera" only, avoid custom configs unless absolutely needed. dcs-bad.log dcs-good.log

Let's figure this out together. My setup is admittedly complex — I'm running Helios, Winwing, DCS-BIOS, and a multi-screen environment — but I have a firm grasp on my system's behavior. I avoid using mods, aside from those external interfacing apps, and I never touch the core DCS files. If I ever tweak something, it's limited to the Saved Games\DCS directory, which I can easily reset to test a clean vanilla setup. I’ve already done this — wiped the Saved Games folder, ran DCS vanilla — and the issue persisted. That points away from mods and strongly toward a driver, OS setting, or deeper GPU interaction conflict. Next steps: I’ll reinstall the new update and wipe the Saved Games folder again. I’ll run tests in two configurations: standard resolution (just the center monitor), and extended (full-screen spanned across all displays). I’ll submit both log files for analysis (previous vs current DCS version). Right now, I suspect the issue might stem from a combination of: DisplayLink drivers (I use them for extended displays) NVIDIA settings, particularly DLSS or G-SYNC modes A bug in the rendering pipeline of the latest DCS update Release notes from the patch mention: Fixes to model element visibility through dust for ground units HUD symbology distortion from engine heat blur A black screen issue tied to manual fog settings These hint that something changed in how the engine handles post-processing, transparency, or depth layers — all of which can severely impact multi-monitor, high-resolution, or mixed driver setups. Will report back in the next hour or so

If you are using winwing then you are using multiple viewports, Center is the 'main' one for the cockpit, the MFDs use the following: CENTER_MFCD LEFT_MFCD RIGHT_MFCD When you setup your winwing you either create a layout to the to the right or BELOW your main 'viewport'. Thats's an interesting detail. My screens are set BELOW the main viewport, yours are set to the SIDE. You can tell this layout by checking windows (see image). Then you 'match' the total resolution of your combined monitors and set that in DCS. New update might have an issue with screen 'height'. I have an Ultrawide (3840x1080) but with the Winwings is 3840x2104. Notice WIDTH stays the same, as my layout of Winwings is BELOW the Center viewport. The DCS new update is having issues with this, no idea why, if I set the resolution in DCS to match my CENTER viewport everything works perfect. I don't think this is an Issue with Helios or Winwing, but something with drawcalls and D3D11 and height. null

nullAlready updated to the latest Helios two weeks ago. I even tried the new DCS update but WITHOUT Helios or any viewports. As long as I use a resolution that matches the main viewport everything works. Problem is when your resolution is HIGHER than the 'CENTER' (main) viewport, thats when the new update starts freezing, going black screen in a very erratic way. I rolled back to the DCS previous update and everything works perfect again.null

Using a single viewport? Or exporting MFDs as well?