bojote

Update on DCS-Anywhere Following up on my original announcement of DCS-Anywhere, I’d like to share the progress made since release and address some of the common questions raised in this thread. Major Improvements Headless/Console Mode: The HID Manager can now run entirely without a GUI, making it ideal for headless systems such as Raspberry Pi panel hubs or dedicated Linux boxes. Statistics (frame rate, bandwidth, average UDP frame size) are continuously updated in the console. Parallelized I/O Path: The architecture was refactored so USB HID reads and writes are handled by independent threads. This eliminates contention and ensures deterministic throughput even under high load. Each connected device has its own dedicated TX worker, allowing true parallel fan-out of DCS-Bios traffic to multiple devices. Proven Scaling on Raspberry Pi: In stress tests with 9 simultaneous CockpitOS devices on a Raspberry Pi 4, the system operated without CPU saturation and DCS itself kept pace flawlessly. This validates the approach for large multi-panel rigs where traditional COM-port methods struggle. Device Discovery and Multi-Board Support: The HID Manager automatically enumerates all ESP32 devices sharing the configured VID/PID. Distinct serial numbers allow unique identification and reconnection tracking. No per-device configuration is required. VID/PID Consistency: One recurring question was why some ESP32-S3 boards did not appear in the devices table. The root cause was mismatched VID/PID values (e.g. boards with dual USB ports or external bridges such as CH340). This has been clarified in the docs: simply ensure that the values in settings.ini match those defined in your sketch’s Config.h. Cross-Platform Validation: The Python HID Manager has been exercised on Windows, Linux, macOS, and multiple Raspberry Pi variants. CPU load remains negligible (<1% on ARM), and the HID/UDP bridge operates identically on all platforms. Frequently Asked Scenarios Mixed Arduinos and ESP32s: Confirmed to work without conflict. DCS-Bios multicasts its data; any component (Arduino serial, ESP32 HID, or even custom listeners) can subscribe simultaneously. Raspberry Pi as a “Panel Hub”: Fully supported. Plug ESP32-based panels into a Pi via USB, run the HID Manager, and the Pi bridges UDP traffic to DCS. No drivers, no COM ports. The Pi itself is not a cockpit device; it acts purely as a host/bridge. Headless Operation (previously requested): Now implemented. You can run the HID Manager in console mode (--console or --headless) with full statistics and logging, suitable for daily unattended use on embedded hosts. Relation to CockpitOS Some of you noted in this thread that CockpitOS was mentioned alongside DCS-Anywhere. To clarify: DCS-Anywhere is the lightweight, transport-layer bridge. It demonstrates how to run ESP32-based panels anywhere on your network using HID + UDP. CockpitOS Firmware Project (link) is the full avionics-style framework built on top of the same HID manager. It is a comprehensive firmware suite designed for ESP32-S2/S3-based panels and supports: Auto-generated mappings for selectors, rotaries, LEDs, and displays directly from DCS-Bios JSON. Unified LED control (GPIO, PCA9555, WS2812, TM1637, HT1622, etc.) under a single API. Deterministic, real-time input handling with exclusive-selector group logic and USB HID/DCS command throttling. Data-driven panel definitions that minimize the amount of C++ a user needs to write—ideal for non-programmers wiring hardware panels. High-reliability engineering practices: static memory allocation, deterministic loop execution, zero dynamic heap usage, and O(1) lookup systems. In short: DCS-Anywhere is the bridge, CockpitOS is the full aircraft-grade panel firmware environment. If you’re interested in scaling beyond a handful of devices into entire cockpits, CockpitOS is worth exploring. Closing The updated DCS-Anywhere release is available here: https://github.com/BojoteX/DCS-Anywhere Thanks to everyone who tested, asked questions, and pointed out corner cases. The feedback directly shaped the new features. I’ll continue to refine both DCS-Anywhere and the broader CockpitOS framework based on real-world use in pits. Happy flying, and keep building. —bojote

The HID Manager will look for ALL of your devices with the same PID/VID. Serial Number is how you setup the custom name for each device. There is really nothing you need to do, its already meant to be used with multiple devices

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.